Consul Envoy 集成测试的 Windows 支持：test-sds-server Docker 镜像构建与验证指南

Consul Envoy 集成测试的 Windows 支持test-sds-server Docker 镜像构建与验证指南【免费下载链接】consulConsul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.项目地址: https://gitcode.com/gh_mirrors/con/consul导读本文聚焦于 Consul 仓库中 Windows 平台 Envoy 集成测试的配套 Docker 构建文件 ——Dockerfile-test-sds-server-windows。它负责在 Windows 容器中通过 Go 工具链编译出test-sds-server可执行文件该程序是一个基于 Envoy go-control-plane 实现的 SDSSecret Discovery Service服务器用于向测试中的 Envoy 代理提供 TLS 证书。读完本文你将掌握该镜像的构建命令、底层实现原理、独立运行验证方法以及它如何被 run-tests.windows.sh 和go test -wintrue测试框架整体调度。背景为什么 Windows 上需要专门的测试镜像Consul 的 Envoy 集成测试位于 test/integration/connect/envoy 目录包含数十个测试用例如case-basic、case-badauthz、case-ingress-gateway-sds、case-wasm等每个用例目录下都有setup.sh、verify.bats等脚本用于编排 Consul 集群、注册服务、启动 Envoy sidecar 与网关并校验行为。在 Linux 上测试可以利用 Docker 的 Host 网络模式让所有容器共享宿主网络命名空间服务之间可通过 localhost 直接互通而 Windows 容器没有 Host 网络特性只能使用 NAT 网络每个容器拥有独立 IP必须依赖 Docker 内置 DNS 通过容器名通信。关于这一架构差异的详细说明可阅读 docs/windows-testing-architecture.md其中也介绍了 Windows 上采用的单容器测试架构把 Consul、Envoy、fortio、bats 等组件打进同一个镜像运行。正是这套 Windows 专用的测试矩阵派生出了多份 Dockerfile包括Dockerfile-consul-envoy-windows构建含 Consul 与 Envoy 的核心测试镜像对应windows/consul:localDockerfile-test-sds-server-windows构建 SDS 测试服务器镜像即本文主题Dockerfile-tcpdump-windows可选的数据包抓取镜像。前置条件预构建基础镜像原文档 docker-windows.md 明确强调在构建并运行这些镜像与容器之前必须先预构建这些 Dockerfile 所依赖的基础镜像。这一步由仓库外的build-support-windows/BUILD-IMAGES.md原文档中指向../../../../build-support-windows/BUILD-IMAGES.md换算为仓库根目录相对路径即build-support-windows/BUILD-IMAGES.md说明。同时WINDOWS-TEST.md 也把这份文档列为执行 Windows 集成测试前必须阅读的入口文档之一。说明build-support-windows目录属于构建支撑体系镜像仓库为只读状态此处仅作文档指引当前代码仓库内可确认的 Windows 测试相关配套文档还包括 WINDOWS-TEST.md 与 windows-troubleshooting.md。Dockerfile-test-sds-server-windows 逐行解析原文档指出该文件的唯一用途是用 Go 构建test-sds-server可执行文件其基础镜像选用 Docker Hub 官方 golang 镜像的 Windows nano server 变体。当前仓库中的实际文件内容如下Dockerfile-test-sds-server-windowsFROM docker.mirror.hashicorp.services/windows/golang:1809 WORKDIR /go/src COPY ./ . RUN go build -v -o test-sds-server.exe sds.go CMD [test-sds-server.exe]各指令含义指令说明FROM docker.mirror.hashicorp.services/windows/golang:1809以 HashiCorp 镜像代理提供的windows/golang:1809为基础镜像1809 对应 Windows Server 2019 / Nano Server 的容器版本LTSC自带 Go 工具链使用docker.mirror.hashicorp.services前缀是为了绕过 Docker Hub 在 CI 环境中的拉取限制WORKDIR /go/src将工作目录切换到 Go 源码目录COPY ./ .把构建上下文test-sds-server目录整体复制进容器包含sds.go、go.mod、go.sum与certs/证书目录RUN go build -v -o test-sds-server.exe sds.go以-v详细模式编译sds.go产出 Windows 可执行文件test-sds-server.exeCMD [test-sds-server.exe]容器启动时直接运行编译出的 SDS 服务器构建命令与测试框架中的实际调用构建该镜像的命令为与测试脚本 run-tests.windows.sh 中使用的命令一致docker build -t test-sds-server -f Dockerfile-test-sds-server-windows test-sds-server命令参数拆解-t test-sds-server给镜像打上test-sds-server标签供后续docker run与测试编排引用-f Dockerfile-test-sds-server-windows显式指定使用这份 Windows 专用 Dockerfiletest-sds-server构建上下文目录Docker 会把该目录下所有文件作为上下文发送给守护进程供COPY ./ .使用。从 run-tests.windows.sh 可以看到镜像构建发生在测试套件初始化阶段并且run_container_test-sds-server函数会在每个用例启动服务时在单容器架构的宿主容器内执行./test-sds-server.exefunction run_container_test-sds-server { echo Starting test-sds-server local DC${1:-primary} local CONTAINER_NAME$SINGLE_CONTAINER_BASE_NAME-$DC_1 docker.exe exec -d $CONTAINER_NAME bash -c cd /c/test-sds-server ./test-sds-server.exe }与之对照的 Linux 版 Dockerfile 位于 test-sds-server/Dockerfile差异仅在于基础镜像使用golang:latest、输出二进制不携带.exe后缀以及默认启动命令为/go/src/test-sds-server。源码级解析test-sds-server 到底做了什么要理解构建成功意味着什么需要看它编译的源码 test-sds-server/sds.go。它本质是一个极简的 Envoy Secret Discovery Service 服务器1. 启动流程run函数创建cache.NewLinearCache(sdsTypeURI)线性缓存sdsTypeURI为type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.Secret即只服务 TLS Secret 资源类型默认监听0.0.0.0:1234可通过环境变量SDS_BIND_ADDR覆盖默认证书目录为certs可通过环境变量SDS_CERT_PATH覆盖将 go-control-plane 的 xDS 服务器与 gRPC 服务器绑定并注册secretservice.RegisterSecretDiscoveryServiceServer监听 SIGINT/SIGTERM 信号以优雅退出。2. 证书加载loadCertsFromPath函数遍历certs目录跳过子目录与非.crt文件对每个*.crt文件按同名.key文件配对读取证书与私钥组装成tls.Secret资源TlsCertificate类型证书链与私钥以内联字节形式提供以去掉扩展名的文件名作为 Secret 名称写入线性缓存每加载一张证书打印一条Loaded cert from file日志。3. 可观测性通过hclog输出 Trace 级日志并在 gRPC 流回调StreamOpenFunc、StreamRequestFunc、StreamResponseFunc等中记录每次流与请求/响应便于在排障时确认 Envoy 是否成功拉取到证书。仓库自带的测试证书位于 test-sds-server/certs共四对证书每张*.crt配一张*.keyca-root根 CA 证书foo.example.com、www.example.com普通域名证书wildcard.ingress.consul通配符证书用于网关类用例。这些证书由 gen-certs.sh 生成。集成测试正是通过向 SDS 服务器发起请求并校验返回的证书是否为预期名称来验证 Envoy 的 TLS 配置是否正确——这解释了 windows-testing-architecture.md 中提到的使用 OpenSSL 验证测试期间下发的 TLS 证书是否正确。独立运行与输出验证构建完成后可以在本机独立运行镜像以验证产物是否正常docker run --rm -p 1234:1234 --name test-sds-server test-sds-server参数说明--rm容器退出后自动删除-p 1234:1234将宿主 1234 端口映射到容器内 1234 端口SDS 监听端口--name test-sds-server给容器命名便于管理test-sds-server上一步构建的镜像标签。如果一切正常控制台会输出四行证书加载日志与一行监听日志时间戳因运行时而异文档中用XX掩码占位20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: nameca-root 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: namefoo.example.com 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: namewildcard.ingress.consul 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: namewww.example.com 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] SDS listening: addr0.0.0.0:1234其中 SDS listening对应 sds.go 中log.Info( SDS listening, addr, addr)这行源码。此时可以用 Envoy 或 grpcurl 之类的客户端向127.0.0.1:1234发起 SDS 请求来进一步验证证书分发。与 Windows 测试框架的整体衔接要真正跑通 Windows 上的 Envoy 集成测试仅构建 SDS 镜像还不够还需要配合 WINDOWS-TEST.md 中描述的完整流程1. 预构建核心镜像按BUILD-IMAGES.md说明预构建测试所需的核心基础镜像如windows/consul:local。2. 运行全部用例go test -v -timeout30s -tags integration ./test/integration/connect/envoy -runTestEnvoy -wintrue3. 运行单个用例go test -v -timeout30m -tags integration ./test/integration/connect/envoy -runTestEnvoy/case-badauthz -wintrue注意-wintrue标志必须显式指定。它告知测试框架在 Windows 环境执行并自动将相关文件与脚本的换行符从 LF 转换为 CRLF这是 Windows 容器中脚本能否正确执行的关键。在套件初始化阶段run-tests.windows.sh 的suite_setup会依次完成清理残留环境、创建envoy-testsNAT 网络、创建envoy_workdir命名卷与占位容器、重建windows/consul:local镜像再通过docker build构建 SDS 服务器镜像。随后每个用例运行时init_workdir会把用例目录中的*.hcl配置、*.bats断言脚本、test-sds-server/certs/ca-root.crt等文件复制进 workdir最终由 bats 容器执行verify.bats完成断言。排障提示如果构建或运行过程中遇到问题可参考 windows-troubleshooting.md它整理了 Windows 容器化适配过程中对既有测试所做的全部修改与踩坑记录Windows 测试架构的动机与单容器方案细节则见 docs/windows-testing-architecture.md。常见排查点包括基础镜像是否已按BUILD-IMAGES.md预先构建缺少基础镜像会导致FROM阶段直接失败-wintrue标志是否遗漏遗漏会导致换行符未转换脚本在 Windows 容器中报错运行docker run验证时端口 1234 是否被占用或证书目录是否被SDS_CERT_PATH环境变量指向了其他路径证书加载日志数量是否与 certs 目录中的*.crt文件一一对应若少于四个说明证书文件缺失或命名不匹配。小结Dockerfile-test-sds-server-windows是 Consul Windows Envoy 集成测试链路中一块小而关键的拼图它把 Go 源码 sds.go 编译为可在 Nano Server 容器中运行的 SDS 服务器为 Envoy 提供证书分发能力并被 run-tests.windows.sh 与go test -wintrue测试框架在套件初始化时自动构建、用例运行时自动启动。掌握它的构建、运行与验证方式是本地复现或排查 Windows 平台 Envoy 集成测试的第一步。【免费下载链接】consulConsul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.项目地址: https://gitcode.com/gh_mirrors/con/consul创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考