Argo CD E2E 测试 Git 服务器基于固定密钥与 Nginx 代理的可复现测试环境剖析【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cdArgo CD 的端到端E2E测试依赖一个在本地运行的测试 Git 服务器通过 SSH、HTTP、HTTPS 三种协议暴露测试仓库。本文基于 test/fixture/testrepos/README.md 及其同目录下的 Procfile、start-git.sh、nginx.conf 等真实文件完整讲解该测试 Git 服务器的进程组成、端口布局、SSH 固定密钥设计原理、Helm 镜像仓库的启动方式以及重新生成 SSH 主机密钥的完整操作流程帮助读者理解 Argo CD 如何为 GitOps 同步链路构造可复现的端到端测试基础设施。一、测试 Git 服务器总览该目录test/fixture/testrepos/存放运行 E2E 测试 Git 服务器所需的配置文件与加密密钥。该服务器运行在 Docker 容器镜像argoproj/argo-cd-ci-builder:v1.0.0中使用 goreman 进程管理器同时拉起三个进程进程端口作用sshd2222提供 SSH 协议的 Git 访问nginx9080HTTP、9443/9444/9445HTTPS提供 HTTP/HTTPS 的 Git 访问与 Helm 仓库访问fcgiwrapUnix 套接字Git HTTP 后端的 FastCGI 包装器从根目录的 E2E 编排文件 Procfile 可以看到这个 Git 服务器并不是孤立运行的而是与 Argo CD 的完整组件栈api-server、repo-server、controller、redis、dex、ui 等一起被拉起git-server: test/fixture/testrepos/start-git.sh helm-registry: test/fixture/testrepos/start-helm-registry.sh oci-registry: test/fixture/testrepos/start-authenticated-helm-registry.sh也就是说本地跑 E2E 时Goreman 会把本地 Git 服务器、匿名 Helm 仓库、带认证的 OCI 仓库作为整个测试环境的一部分启动供 Argo CD 的仓库同步功能真实地拉取 Git 仓库与 Helm Chart。二、start-git.shDocker 容器的启动与挂载start-git.sh 负责启动承载测试 Git 服务器的 Docker 容器其核心逻辑如下# ARGOCD_E2E_DIR can be set to customize the e2e test data directory on the host # This is useful on macOS where Docker doesnt share /tmp with the host # The host directory is mounted to /tmp/argo-e2e inside the container ARGOCD_E2E_DIR${ARGOCD_E2E_DIR:-/tmp/argo-e2e} docker run --name e2e-git --rm -i \ -p 2222:2222 -p 9080:9080 -p 9443:9443 -p 9444:9444 -p 9445:9445 \ -w /go/src/github.com/argoproj/argo-cd \ -v /tmp:/tmp \ -v $ARGOCD_E2E_DIR:/tmp/argo-e2e \ -v $(pwd):/go/src/github.com/argoproj/argo-cd \ docker.io/argoproj/argo-cd-ci-builder:v1.0.0 \ bash -c goreman -f ./test/fixture/testrepos/Procfile start关键要点端口映射宿主机 2222/9080/9443/9444/9445 一一对应到容器内同名端口分别承载 SSH、HTTP、三个 HTTPS 端点双挂载仓库目录被挂载到容器内的/go/src/github.com/argoproj/argo-cd因此容器内 nginx 可以直接读取宿主机上的本目录配置nginx.conf中使用相对路径../certs/...引用证书ARGOCD_E2E_DIR默认/tmp/argo-e2e被挂载到容器内/tmp/argo-e2e这是存放动态生成测试仓库的数据目录跨平台考虑脚本注释明确说明ARGOCD_E2E_DIR可自定义正是为了 macOS 上 Docker 不共享宿主机/tmp的场景入口命令容器内通过 goreman 加载本目录的 Procfile 启动三个进程。三、Procfile三个进程如何被拉起Procfile 中定义了 goreman 管理的三个进程其中 sshd 一行包含了多个关键工程细节sshd: mkdir -p /var/run/sshd mkdir -p ~/.ssh cat ./test/fixture/testrepos/id_rsa.pub ~/.ssh/authorized_keys cp ./test/fixture/testrepos/ssh_host_*_key /etc/ssh/ cp ./test/fixture/testrepos/ssh_host_*_key.pub /etc/ssh/ chmod 600 /etc/ssh/ssh_host_*_key /usr/sbin/sshd -p 2222 -D -e -o KexAlgorithmsdiffie-hellman-group-exchange-sha256 fcgiwrap: fcgiwrap -s unix:/var/run/fcgiwrap.socket sleep 1 chmod 777 /var/run/fcgiwrap.socket wait nginx: nginx -prefix$(pwd) -g daemon off; -c $(pwd)/test/fixture/testrepos/nginx.conf三个值得注意的设计固定 SSH 主机密钥sshd 启动前把仓库中预生成的ssh_host_*_key拷贝到/etc/ssh/并chmod 600。这样每次重启容器都使用同一组密钥ssh_known_hosts文件始终有效客户端无需交互式确认主机指纹。这是整个 E2E 体系密钥固化思路的根基。公钥授权id_rsa.pub被写入容器内~/.ssh/authorized_keys使 E2E 测试客户端可以免密 SSH 登录。强制旧版 Kex 算法sshd 显式加上-o KexAlgorithmsdiffie-hellman-group-exchange-sha256。文件注释写明这是为了防止 https://github.com/argoproj/argo-cd/pull/6253 引入的行为回归——测试服务器需要模拟只支持较旧密钥交换算法的 SSH 服务端以覆盖兼容性问题。fcgiwrap 套接字权限fcgiwrap 监听unix:/var/run/fcgiwrap.socket随后chmod 777让 nginx worker 进程可以访问该 Unix 套接字将 Git HTTP 请求转发给git-http-backend。四、nginx.conf三类访问入口与 Git HTTP 后端代理nginx.conf 定义了三个 server 块覆盖 E2E 测试需要验证的各种仓库访问认证组合4.1 端口 9081无认证入口硬编码 REMOTE_USERserver { listen 0.0.0.0:9081; root /tmp/argo-e2e; ... location ~ /argo-e2e(/.*) { fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; include /etc/nginx/fastcgi_params; fastcgi_param GIT_HTTP_EXPORT_ALL ; fastcgi_param GIT_PROJECT_ROOT /tmp/argo-e2e; fastcgi_param PATH_INFO $1; # Hard-coded credentials for Git in this case fastcgi_param REMOTE_USER admin; fastcgi_pass unix:/var/run/fcgiwrap.socket; } }注意 README 摘要中写的是 HTTP (9080)而实际文件中 9081 是无认证入口、9080 是带 Basic Auth 入口——两者都通过 fcgiwrap 代理到git-http-backend。9081 这个入口直接硬编码REMOTE_USER admin用于测试已认证但凭证由服务端固定注入的场景。4.2 端口 9080 / 9443Basic Auth 的 HTTP 与 HTTPS 入口server { listen 9080; listen 0.0.0.0:9443 ssl http2; auth_basic Restricted; auth_basic_user_file .htpasswd; root /tmp/argo-e2e; ssl_certificate ../certs/argocd-test-server.crt; ssl_certificate_key ../certs/argocd-test-server.key; ... # Forward REMOTE_USER as we want to know when we are authenticated fastcgi_param REMOTE_USER $remote_user; ... }该入口启用auth_basic用户表.htpasswd并把真实的$remote_user转发给 Git HTTP 后端用于测试Basic Auth 认证成功与否对 Git 访问的影响。HTTPS 证书来自 test/fixture/certs/ 目录——注意nginx.conf用的是相对路径../certs/argocd-test-server.crt因此 nginx 必须以仓库根目录为 prefix 启动对应 Procfile 中的nginx -prefix$(pwd)。4.3 端口 9444强制客户端证书校验server { listen 0.0.0.0:9444 ssl http2; ... ssl_client_certificate ../certs/argocd-test-ca.crt; ssl_verify_client on; }这是一个开启双向 TLSmTLS的独立入口ssl_verify_client on要求客户端出示由测试 CAargocd-test-ca.crt签发的证书。对应地test/fixture/certs/ 目录中存放测试用的 CA、服务端证书与客户端证书该目录有独立文档 test/fixture/certs/README.md。4.4 Helm 仓库路径三个 server 块中都包含针对 Helm 仓库的 locationlocation ~ ^/helm-repo/(.*) { client_max_body_size 0; # bodies can be huge alias /app/config/testdata/helm-repo/$1; }client_max_body_size 0表示取消请求体大小限制Helm 仓库的index.yaml可能很大。另有/argo-e2e/testdata.git/helm-repo/(.*)路径用于直接服务动态生成的测试仓库中的 Helm 仓库目录。4.5 Git HTTP 代理链路小结综合以上一次 HTTPS Git 请求的链路是Argo CD (git clone/fetch) → nginx (9443/9444, TLS 终结 可选 Basic/mTLS 认证) → fcgiwrap (unix:/var/run/fcgiwrap.socket) → git-http-backend (GIT_PROJECT_ROOT/tmp/argo-e2e) → /tmp/argo-e2e 下的动态测试仓库五、SSH 密钥体系主机密钥、known_hosts 与客户端公钥5.1 固定主机密钥目录中预置了三组 SSH 主机密钥各带.pub文件ssh_host_rsa_keyRSAssh_host_ecdsa_keyECDSAssh_host_ed25519_keyEd25519正如 README 所述在启动 sshd 之前拷贝这份预生成的密钥保证每次重启容器后ssh_known_hosts依然有效。如果密钥是容器每次启动时随机生成的known_hosts 中的指纹就会失效E2E 测试会因主机密钥校验失败而不稳定。5.2 ssh_known_hosts双主机条目ssh_known_hosts 同时包含两类条目[localhost]:2222—— 本地开发/测试场景E2E 客户端在宿主机上访问本地端口转发[argocd-e2e-server]:2222—— 远程/集群内测试场景E2E 环境跑在 Kubernetes 集群中Git 服务器以服务名argocd-e2e-server暴露。由于两者使用的是同一组固定密钥所以两种条目的指纹完全相同一个文件即可同时服务本地和集群内两种拓扑。该文件正是 E2E 测试注入 Argo CD 的 known hosts 来源test/e2e/fixture/certs/certs.go 中的AddCustomSSHKnownHostsKeys以../fixture/testrepos/ssh_known_hosts为默认源通过argocd cert add-ssh --upsert --batch --from file注册到被测的 Argo CD 实例并在本地模式下直接写入app/config/ssh/ssh_known_hosts供 dev-mounter 挂载。这也解释了为何文件中两个主机名条目必须共存。5.3 id_rsa.pub客户端认证密钥id_rsa.pub配对私钥为同目录id_rsa在容器启动时被追加进~/.ssh/authorized_keysE2E 测试客户端即以此密钥对完成 SSH 认证。六、Helm / OCI 镜像仓库另外两个启动脚本除 Git 服务器外本目录还有两个用于测试 Helm 功能的轻量脚本start-helm-registry.shdocker run -p 5000:5000 --rm --name registry registry——启动一个无认证、映射到宿主机 5000 端口的 registry供匿名 Helm/OCI 拉取测试使用start-authenticated-helm-registry.shdocker run -p 5001:5000 --rm --name authed-registry \ -v $(pwd)/test/fixture/testrepos/.oci-htpasswd:/etc/docker/registry/auth.htpasswd \ -e REGISTRY_AUTH{htpasswd: {realm: localhost, path: /etc/docker/registry/auth.htpasswd}} \ registry该脚本挂载.oci-htpasswd文件并通过REGISTRY_AUTH环境变量启用 htpasswd 认证realm 为localhost映射到宿主机 5001 端口用于测试带凭证的 Helm/OCI 仓库访问。七、sudoers.conf 的作用sudoers.conf 是一个测试用户可用的 sudo 配置模板核心内容为default ALL(ALL:ALL) NOPASSWD: ALL即允许非 root 用户免密提权执行命令——这为需要在非 root 环境下启动 sshd 等服务如 macOS 上本地运行测试的开发者提供了权限基础。八、重新生成 SSH 主机密钥的完整流程当需要更换主机密钥时例如密钥轮换README 给出了三步操作这里完整继承并说明。8.1 生成新密钥cd test/fixture/testrepos # Generate RSA key ssh-keygen -t rsa -b 2048 -f ssh_host_rsa_key -N -C rootargocd-e2e # Generate ECDSA key ssh-keygen -t ecdsa -f ssh_host_ecdsa_key -N -C rootargocd-e2e # Generate Ed25519 key ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N -C rootargocd-e2e-N 表示空 passphrasesshd 启动主机密钥时不做交互式输入-C注释统一为rootargocd-e2e保持与 E2E 服务端身份一致。8.2 用新密钥刷新 ssh_known_hosts思路是临时起一个加载新密钥的 sshd用ssh-keyscan抓取新指纹再拼出同时含localhost与argocd-e2e-server两组条目的新文件# Start temporary sshd with new keys sudo mkdir -p /tmp/test-sshd sudo cp ssh_host_*_key* /tmp/test-sshd/ sudo chmod 600 /tmp/test-sshd/ssh_host_*_key sudo /usr/sbin/sshd -p 2222 \ -h /tmp/test-sshd/ssh_host_rsa_key \ -h /tmp/test-sshd/ssh_host_ecdsa_key \ -h /tmp/test-sshd/ssh_host_ed25519_key \ -D SSHD_PID$! # Scan to get new fingerprints ssh-keyscan -p 2222 localhost ssh_known_hosts.tmp # Stop temporary sshd sudo kill $SSHD_PID sudo rm -rf /tmp/test-sshd # Create new ssh_known_hosts with both localhost and argocd-e2e-server entries cat ssh_known_hosts EOF # localhost:2222 SSH-2.0-OpenSSH_X.Xp1 EOF cat ssh_known_hosts.tmp ssh_known_hosts echo # For in-cluster tests ssh_known_hosts sed s/\[localhost\]/[argocd-e2e-server]/g ssh_known_hosts.tmp ssh_known_hosts rm ssh_known_hosts.tmp注意sed s/\[localhost\]/[argocd-e2e-server]/g一步即完成第二组条目因为密钥相同指纹不变只需替换主机名。这正是第五节中两条目指纹一致结论的另一面。8.3 验证# Start the test server ./test/fixture/testrepos/start-git.sh # In another terminal, test SSH connection ssh -p 2222 -o UserKnownHostsFiletest/fixture/testrepos/ssh_known_hosts rootlocalhost-o UserKnownHostsFile...显式指定刚更新的文件能验证指纹匹配且无交互式主机密钥确认提示说明新密钥与 known_hosts 已对齐。九、小结这套 fixture 支撑了哪些 E2E 能力从源码结构看本目录与 Argo CD E2E 体系的衔接点有Git 仓库访问的协议全覆盖sshd 提供 SSHnginx 三个 server 块分别覆盖无认证 硬编码用户Basic Auth HTTP/HTTPSBasic Auth mTLS 双向 TLS三种认证组合Argo CD 的仓库凭证功能SSH 公钥、TLS 证书、Basic Auth在 E2E 中都能得到真实验证密钥固化保证测试确定性固定主机密钥 双主机名 known_hosts 文件使同一份 fixture 同时支撑本地与集群内两种 E2E 拓扑且重启容器后不漂移test/e2e/fixture/certs/certs.go 是该文件的消费方Helm/OCI 仓库成对覆盖匿名5000与认证5001registry 与 nginx 的/helm-repo静态路径共同覆盖 Helm 仓库的匿名与带凭证场景。若需进一步了解相关设施可参阅同仓库的 TLS 证书说明HTTPS 证书与 SSH 密钥相互独立与 远程测试说明针对远程集群运行测试的方法。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
