Docker 镜像构建如何编写健壮的集成测试验证镜像

健壮的集成测试需在真实容器环境中验证 Docker 镜像行为，通过 docker run 启动独立容器、端口暴露、健康检查、日志/文件观察及 docker exec 验证内部状态，覆盖 Web/CLI/数据库等典型场景，使用原生命令断言，绑定 CI 流水线强制执行。

编写健壮的集成测试来验证 Docker 镜像，核心是模拟真实运行环境、覆盖关键行为路径，并确保测试可重复、可隔离、不依赖外部状态。

用容器运行时直接测试镜像行为

避免在宿主机上安装服务或依赖本地环境，始终以 docker run 启动待测镜像为独立容器，通过端口暴露、健康检查、日志输出或文件挂载等方式观察其实际表现。

1. 启动后等待服务就绪（如轮询 curl -f http://localhost:8080/health 或用 wait-for-it.sh）
2. 使用 --rm 和随机端口（-p 0:8080）保证每次测试干净隔离
3. 通过 docker exec 进入容器验证内部状态（如配置文件内容、二进制版本、用户权限）

覆盖典型集成场景而非单元逻辑

测试重点不是代码是否编译通过，而是镜像交付后能否完成预期集成任务。例如：

1. Web 应用镜像：HTTP 响应状态码、返回体包含预期文本、静态资源可访问
2. CLI 工具镜像：执行命令后退出码为 0、标准输出含指定字符串、能正确解析输入参数
3. 数据库镜像：连接成功、能执行简单 SQL、初始化脚本已生效（如预建库/表）

用轻量级断言工具保持测试简洁可靠

优先选用 Shell 原生命令组合（grep、jq、curl、timeout），避免引入复杂测试框架增加维护成本。

1. 用 timeout 30s docker run ... 防止挂起阻塞 CI
2. 用 curl -sSf http://... | grep -q "OK" 判断接口可用性
3. 对 JSON 响应用 jq -e '.status == "running"' >/dev/null 精确校验结构

把测试作为构建流水线的必经环节

将集成测试脚本绑定到 docker build 后立即执行，或在 CI 中作为独立步骤运行，失败即中断发布流程。

1. 在 Dockerfile 末尾添加 ONBUILD RUN ./test-integration.sh（仅用于开发调试，生产慎用）
2. CI 中先 docker build -t myapp:test .，再 ./test/integration.sh myapp:test
3. 测试脚本中显式清理资源：docker rm -f $(docker ps -aq --filter ancestor=myapp:test)

关键是让测试跑在和生产一致的容器上下文中，验证“镜像交付物”本身是否可用，而不是验证源码或构建过程。