docker镜像与容器是ci的可靠载体而非执行工具：镜像通过分层存储和确定性构建保障环境一致性，容器在隔离环境中运行测试确保验证真实性，二者协同产出不可变、可追溯的交付制品。
docker 镜像与容器不是“实现”持续集成的工具，而是让持续集成（ci）更可靠、可重复、环境一致的关键载体。它们本身不执行 ci 流程，但为 ci 提供了标准化的运行单元和交付产物。
镜像解决“在哪跑都一样”的问题
镜像是只读模板，打包了应用代码、运行时、依赖库和配置。它通过分层存储和确定性构建（如 Dockerfile 指令顺序、缓存机制），确保：
- 同一份源码 + 同一份 Dockerfile → 在任何 CI 服务器上构建出完全一致的镜像
- 开发本地构建的镜像，和 Jenkins/GitHub Actions 构建的镜像哈希值相同（若基础环境可控）
- 避免因 CI 机器装了不同版本 Node、Python 或系统库导致测试通过/失败不一致
容器解决“怎么验才真实”的问题
CI 中的测试环节，不再依赖宿主机环境，而是启动一个基于该镜像的临时容器来运行：
-
docker run --rm myapp:abc123 npm test—— 测试在干净、隔离、与生产一致的环境中执行 - 可并行启动多个容器做接口测试、数据库迁移验证、端到端检查，互不干扰
- 容器秒级启停，大幅缩短单次 CI 执行时间，尤其适合高频提交场景
CI 流水线里镜像与容器的实际协作方式
- 每次 Git 提交触发流水线后，第一件事是
docker build -t myapp:${{ github.sha }} . - 接着用这个镜像启动容器，运行单元测试、静态检查、安全扫描（如
trivy image myapp:${{ github.sha }}） - 测试通过，才执行
docker push myapp:${{ github.sha }}到镜像仓库 - 整个过程不碰宿主机的全局 Node/npm/Java 环境，所有依赖由镜像内部封装
关键点在于“不可变性”和“契约化”
CI 的输出不再是模糊的“构建成功”，而是明确的：
- 一个带唯一 tag（如 commit SHA 或语义化版本）的镜像地址
- 该镜像已通过全部自动化测试
- 下游 CD 环节只需拉取这个地址，就能部署——无需再编译、安装或配置
这使得 CI 不再是“跑通脚本”，而是产出一个可验证、可追溯、可跨环境交付的软件制品。
