docker镜像ci的核心是将构建、测试、验证自动嵌入代码提交流程，实现“一提交就构建、一构建就验证”，强调可重复、可审计、环境一致；需用ci工具触发构建、带版本与缓存优化、构建后验证、推送前确认仓库权限与网络可达。
Docker 镜像持续集成（CI）的核心，是把镜像构建、测试、验证等环节自动嵌入代码提交流程中，做到“一提交就构建、一构建就验证”。它不是单纯运行 docker build，而是围绕可重复、可审计、环境一致这三点设计自动化闭环。
用 CI 工具触发镜像构建
每次 Git 提交（如推送到 main 分支）应自动触发流水线。主流平台支持方式不同：
-
GitHub Actions：在项目根目录添加
.github/workflows/ci.yml，用container指定构建环境（如node:18-alpine），再执行docker build和docker run测试 -
GitLab CI：配置
.gitlab-ci.yml，启用docker:dind服务，确保 Runner 支持嵌套容器构建 - Jenkins：通过 Pipeline 脚本定义 stage，调用 shell 执行构建命令，并利用插件管理 Docker 守护进程连接
构建过程必须带版本与缓存优化
镜像不能总打 latest 标签，否则无法追溯和回滚。推荐做法：
- 使用 Git 提交哈希（
$GIT_COMMIT）、分支名（$CI_COMMIT_REF_SLUG）或语义化版本（来自package.json或标签）作为镜像 tag - Dockerfile 中按变更频率分层：先
COPY package*.json再RUN npm install，保证依赖层缓存复用 - 对多阶段构建的前端项目，用
builder阶段装依赖+打包，nginx:alpine阶段只放静态文件，最终镜像体积可压到 100MB 以内
构建后必须验证，不能只看 build 成功
构建成功 ≠ 镜像可用。需在容器内真实运行检查：
- 启动容器并探测健康端点：
docker run -d --rm --name test-app -p 3000:3000 myapp:v1.2.0 && sleep 3 && curl -f http://localhost:3000/health || exit 1 - 运行单元测试（若应用支持）：
docker run --rm myapp:v1.2.0 npm test - 扫描安全漏洞（如集成 Trivy）：
trivy image --severity HIGH,CRITICAL myapp:v1.2.0，发现高危漏洞则中断流水线
推送前确认镜像仓库权限与网络可达
本地能构建不等于 CI 环境能推送。关键检查点：
- CI 环境已登录镜像仓库（Docker Hub / 私有 Harbor），凭证通过 secret 注入，不硬编码
- 镜像 tag 命名符合仓库命名规范（如
registry.example.com/myorg/myapp:v1.2.0） - 网络策略允许 CI runner 访问 registry（尤其私有仓库需开通防火墙或代理）
