很多团队做 CI/CD 的时候第一步想到的不是流水线本身而是环境。环境问题在所有关于交付的抱怨里排在头号本地能跑测试环境挂测试环境能跑生产环境又崩。我见过最夸张的一次团队排查了一下午发布事故最后发现是构建机上的一个全局依赖悄悄升了版而 Dockerfile 在项目里躺了半年没人看。既然这个系列讲的是 CI/CDDocker 这篇必须单独写。因为 Docker 在持续集成和持续交付里的位置不只是一种打包工具它解决的是整套交付流程中最根本的信任问题我们交付的东西和环境是绑在一起的而 Docker 把环境变成了可以构建、可以签名、可以回滚的版本化产物。这篇文章想跟你聊清楚几件事Docker 在 CI/CD 链路中到底扮演什么角色Dockerfile 怎么写才能让流水线更快在 Pipeline 里集成 Docker 有哪些绕不开的配置和坑以及团队从手动配环境走向镜像化交付时最容易忽略的管理问题。无论你是刚开始接触容器化的新人还是已经在流水线里用了一阵 Docker 但经常被各种诡异问题缠身的人这篇都值得往下看。1. 为什么CI/CD流程绕不开Docker1.1 传统交付的痛点环境和代码是分离的先回顾一下没有 Docker 的时候持续交付是怎么跑的。通常有一台构建服务器上面装好了各种运行时、构建工具、测试框架可能还有多个项目共用的全局依赖。这种情况下的流水线本质上是在一份会变的环境上执行固定脚本今天能过明天某个依赖升了版本可能就过不了A 项目升级了公共库B 项目的构建就被莫名其妙地拖垮。环境漂移这个词听起来很正式但说白了就是大家都在用同一个世界而这个世界总在被别人改变。这类问题在我实际接触过的团队里几乎是常态。我记得某团队每次发布前都要手工执行一遍环境校验清单确认构建机上的 Node 版本、Python 版本、系统级工具链没变化。这个清单本身没有错但它无法阻止任何一个人手动更新服务器上的一个包。真正的问题是环境没有进入版本控制。代码可以回滚到上一个 commit环境却说不清上次是什么状态——这种不确定恰恰是 CI/CD 最怕的东西。1.2 Docker 给 CI/CD 提供了三种能力Docker 解决这个问题的思路是把环境也当成代码来管理。具体来说它给 CI/CD 带来的核心价值可以拆成三块可复现性同一个 Dockerfile 加同一个基础镜像在任何机器上构建出的镜像行为是一致的。这相当于给环境打了快照消除了在我机器上是好的这类问题。隔离性流水线里跑的构建、测试、部署各自可以有独立的环境互不污染。构建环境和运行环境甚至可以完全不同互不影响。可分发性镜像构建完成后可以被推送到仓库被任何环境拉取执行。交付物从源码加环境说明文档变成了一个自带运行环境的产物。这三块能力对应到具体环节就是构建阶段用隔离的执行环境测试阶段用干净的测试容器部署阶段用同一份镜像跨越环境一致交付。后面所有内容基本都是在讲这三块能力如何落到实际流程。2. Docker在CI/CD链路中的角色镜像、仓库与流水线2.1 镜像的生命周期从源码到可运行产物在 CI/CD 语境下Docker 镜像是整个交付链路的中间产物。代码推送到仓库后流水线把它构建成一个镜像镜像推送到镜像仓库部署环境从仓库拉取镜像并运行容器。一次构建多环境复用这是 Docker 化交付的核心模型。关键点在于镜像构建必须是一次构建多环境复用。同一个源码加同一套构建参数得到的是相同的镜像这份产物被送到测试环境验证验证通过后再原样送到生产环境。我见过一些团队在流水线里使用latest标签来标记镜像这其实破坏了可复现性——因为latest这个标签是漂移的今天构建的最新和三个月前构建的最新很可能不是同一个东西。一旦生产环境出问题需要回滚你根本不知道三个月前的latest长什么样。2.2 镜像仓库交付物管理的中央仓库如果说代码仓库管的是源码那镜像仓库管的就是交付物。用 Docker 做 CI/CD镜像仓库的地位和 Git 仓库一样重要——要有权限控制、有操作审计、有保留策略。构建机坏了可以重装代码库丢了可以从 Git 恢复但如果镜像仓库里没有备份的交付物运维就只能抓瞎。我在实际项目里的做法是给每个服务建独立的命名空间tag 用提交的短哈希比如7f3a2c1。部署时附加带环境信息的自定义字符串例如app-7f3a2c1-prod-20250113。这样任何时候看到一个 tag都能直接对应到代码提交、对应到部署时间排查问题时少绕很多弯。镜像留在构建机本地是没有价值的——必须推到仓库生产环境才拉取得到。只要镜像在仓库里哪怕整台构建机被清空交付物也不会丢。2.3 Tag 策略版本信息从哪来镜像 tag 是流水线回滚的基础我强烈建议提前约定好规则。推荐的做法主标识使用代码提交的短 SHA例如7f3a2c1保证每个 commit 对应唯一镜像。需要发布时附加语义版本号例如v2.3.0-7f3a2c1方便对应版本记录和发布清单。latest只用于本地开发便利不作为部署标记。测试环境可以默认取最新但生产部署必须显式指定 tag而不是依赖latest。补充一个运维里遇到的细节有的同事习惯在部署配置里写死上一个版本的 tag但某次回滚后没把 tag 更新导致下一次部署又回到旧镜像。后来我们把部署镜像 tag 做成环境变量由发布流水线统一写入不允许手改部署配置字段类似的乌龙就很少再犯了。3. Dockerfile的编写实践影响整个流水线效率3.1 基础镜像选择体积和兼容性的平衡Dockerfile 的第一行是基础镜像这一行的影响范围被很多人低估。基础镜像选不好后面所有层都会跟着受影响体积大每个环境拉取镜像都多耗时流水线整体变慢基础镜像没人维护安全漏洞会一直渗透进交付物构建环境和运行环境混用一个镜像镜像里塞满用不到的编译工具链。个人推荐的做法是区分构建镜像和运行镜像。构建阶段用功能完整的镜像运行阶段用精简镜像。一个 Node 项目的典型 Dockerfile 大概是这样的# 第一阶段构建 FROM node:18-alpine AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build # 第二阶段运行 FROM node:18-alpine ENV NODE_ENVproduction WORKDIR /app COPY --frombuilder /app/dist ./dist COPY package.json ./ RUN npm ci --onlyproduction USER node EXPOSE 3000 CMD [node, dist/server.js]这里有个细节基础镜像 tag 不要只写node:18这种大版本 tag 后面会一直漂移。官方打了补丁后你 CI 里构建出的镜像行为可能在无声无息中改变。建议至少锁到小版本比如node:18.20.4-alpine更严谨的做法是直接锁 digest类似FROM node:18.20.4-alpinesha256:xxx这在需要严格可复现的发布流程里非常有用。3.2 多阶段构建把构建环境和运行环境分离为什么要把构建和运行分开一个前端项目需要 node 和 npm 来构建但运行的时候根本不需要 npm也不需要源码里的node_modules。如果你直接用构建镜像当运行镜像镜像里会带上全部开发依赖和几十万个小文件体积轻松超过 1GB还会额外增加攻击面。多阶段构建就是为此设计的第一阶段装依赖、构建产物第二阶段只把必要的产物复制过去。我在某项目上把一个 Node 服务的镜像从 1.5GB 优化到 80MB 左右靠的就是多阶段构建加精简运行镜像。镜像变小不只是看着舒服它的直接收益是推送和拉取时间大幅缩短CI 流水线整体提速生产环境扩容时也更快。Python 项目同理。一个典型的多阶段 Python Dockerfile 可以这样组织# 第一阶段安装依赖到虚拟环境 FROM python:3.11-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --prefix/install -r requirements.txt # 第二阶段精简运行环境 FROM python:3.11-slim WORKDIR /app COPY --frombuilder /install /usr/local COPY . . ENV PYTHONUNBUFFERED1 CMD [gunicorn, app:app, -b, 0.0.0.0:8000]3.3 层缓存与指令排序让流水线更快Docker 构建是有缓存的。每一层会基于指令字符串和上一层内容判断能不能直接用缓存指令没变且上一层内容没变这一层就直接延用。所以一个关键原则是变更频率低的放前面变更频率高的放后面。最常见的反例就是有人把COPY . .放在安装依赖之前。因为COPY . .会把整个目录内容的变化暴露给构建系统任何一行代码变动都会让下一个RUN层重新执行依赖安装等于每次白做。正确顺序是先把依赖清单文件复制进去安装完依赖再复制源码COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . .这个顺序问题的教训我在好几个项目里都见过属于 CI 变慢的高频原因。在构建日志里能看到如果某一步显示CACHED说明缓存命中如果显示Running说明那层重新执行了。检查缓存失效只需要看日志开头几步的标识一旦基础镜像下第一个 RUN 就失效那后面所有层都白干了。4. Pipeline中的Docker集成从构建到部署4.1 环境准备Runner/Agent侧需要注意什么在 CI 平台里要执行 docker build先得想清楚构建环境从哪来。通常有两种方式挂载宿主机 socket让 CI 任务容器继承宿主机 Docker 的控制权。实现简单性能好但缺点也很明显——任务拥有宿主机 root 权限适合信任所有流水线提交者的团队。Docker in DockerDinD每个任务启动一个独立的 Docker daemon。隔离效果更好适合多租户场景但资源开销大而且默认缓存不持久每次构建可能缓存全丢。多数中小团队我建议用挂载 socket 的方式把 CI 节点的访问权限控制好就够了。只有当你需要给多个团队提供隔离的 CI 能力时才需要认真考虑 DinD。注意无论哪种方式都要保证 CI 节点上的 Docker 版本和应用部署环境尽量一致。跨大版本的 docker build 有时行为会变尤其是涉及 BuildKit 新特性的时候。4.2 构建与推送CI平台中的具体配置以常见的 CI 平台配置为例一个典型的构建任务大概长这样build: stage: build image: docker:24 services: - docker:24-dind variables: DOCKER_HOST: tcp://docker:2375 IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA script: - docker build -t $IMAGE_TAG . - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker push $IMAGE_TAG这里几个容易踩的细节我说明一下。image: docker:24这个镜像里只带了 docker CLI没有运行 daemon所以需要services里的docker:24-dind来提供 daemonDOCKER_HOST环境变量告诉 CLI 去连这个 daemon。如果你用的是 socket 挂载方式这些 services 配置就不需要换成 volume 挂载即可。构建镜像之前最好加上一个docker login的环节镜像推送到私有仓库需要认证。这个认证信息应该来自 CI 平台的预置变量不要手写在流水线文件里。4.3 部署侧的常见做法构建出来的镜像最终要在部署环境跑起来。最朴素的方式是这样deploy: stage: deploy image: docker:24 services: - docker:24-dind script: - docker pull $IMAGE_TAG - docker rm -f my-service || true - docker run -d --name my-service -p 3000:3000 $IMAGE_TAG这种先删后跑只适合单机测试环境。生产环境一般会配合编排平台做滚动更新此时 CI 输出的核心信息就是镜像 tag 和部署清单具体的更新动作交给部署平台完成。部署侧有几件事必须注意容器启动后不会自动等应用就绪流水线里要增加健康探测比如轮询 HTTP 接口否则会出现容器起来了但服务不可用流水线还是绿的假象。环境变量注入要放在部署配置里不要写进镜像。我见过有人把数据库密码写进环境变量层然后整个镜像推到仓库里——这相当于把密钥直接交给所有能拉镜像的人是严重的线上事故隐患。5. 我在实际项目中踩过的坑与完整排查链路5.1 坑一镜像层缓存在一夜之间全部失效在某项目中流水线原本稳定 3 分钟完成构建某天突然变成 9 分钟而且持续了很长时间。第一次遇到我还以为是构建机负载高等了一天没恢复才开始认真查。完整的排查链路是这样的先看构建日志发现基础镜像拉取正常但后续层没有一个显示CACHED全部是重新执行。继续往上翻看到第一步FROM node:18-alpine后面没有缓存标志而且日志里出现了一次明显的镜像拉取操作。这就说明基础镜像本身变了——虽然 tag 还是node:18-alpine但官方维护者更新了这个大版本标签对应的 commit导致 tag 指向了新的 digest。Docker 缓存判断是逐层比较父层内容的基础镜像一变下面每一层的依赖顺序全部失效。处理方案分两步短期先锁定具体版本 tag比如node:18.20.4-alpine长期建议直接锁 digest并在升级基础镜像时走流水线参数来触发让基础镜像更新变成一次有记录的构建动作而不是官方悄悄改 tag 时被动受影响。5.2 坑二CI环境中Docker daemon内存耗尽另一个项目上用的是 DinD 模式并发构建一上来任务就出现OCI runtime create failed或 daemon 直接被杀的报错。我的排查链路是这样的先排除磁盘问题——docker system df显示磁盘还有空间。检查 daemon 容器日志发现不是用户态报错而是内核的 OOM killer 在干活。对比时间点正好是高并发构建时段多个任务同时拉取大镜像、同时解压。处理办法分三层第一层限流——控制 CI 平台的并发构建数避免瞬时内存峰值第二层清理——加docker system prune定时任务把 dangling 镜像和构建缓存定期清掉尤其是多阶段构建会留下大量中间层第三层换存储驱动——overlay2 在空间和性能上比 vfs 好很多如果你们还在用默认的 vfs值得改一下。5.3 坑三挂载socket的权限边界还有一个让我后怕的经历。某 CI 任务里写了一句docker run -v /:/host ...相当于把构建机整个文件系统挂载进了容器。虽然那次没有造成实际破坏但暴露了一个严重问题挂载 docker.sock 后任何能提交流水线的人就拥有了宿主机 root 级别的权限。如果某个开发者提交的代码被 CI 执行他完全可以借此访问宿主机上的所有文件、修改所有容器配置。我现在给 CI 权限边界定的几条约束是流水线来源必须受控跨团队权限隔离CI 使用的账号和密钥最小化不允许直接使用宿主机 root 凭证对不信任的代码运行环境优先用 DinD 隔离而不是挂载 socket。还有一个细节常规文档不会提buildx 默认会缓存大量中间层如果 CI 执行机的/var/lib/docker被整体清掉下次构建会慢得想骂人但长期不清理磁盘又会满。要么挂持久卷放缓存要么加定期清理任务二选一。6. 让Docker在CI/CD中跑得稳的落地经验6.1 建立团队级基础镜像统一底座当团队变大后每个服务的 Dockerfile 往往长得五花八门有人用 Ubuntu有人用 CentOS有人直接拿构建机当基础镜像。与其让每个人自己翻官方镜像不如由负责基础设施的同学维护一批团队基础镜像比如 base-python、base-node、base-java。这些镜像内置内网依赖源配置、时区、常用调试工具和健康检查组件。流水线里人人都用同一套底座出问题时排查范围会从环境差异缩小到应用代码本身。团队基础镜像的更新需要走版本流程。我建议不要直接在线上改同一个 tag而是打新版本号由各项目决定什么时候升级。基础镜像变了应用没验证就上生产的情况必须通过流程来避免。6.2 关注三个指标构建时长、镜像体积、流水线成功率Docker 化 CI 不是改完 Dockerfile 就结束了。我建议在流水线里持续采集三个指标它们能直接反映出镜像策略健不健康指标常见信号典型应对构建时长 P95一段时间内明显上升查依赖安装层缓存是否失效镜像体积单镜像超过 500MB多阶段构建、精简基础镜像流水线成功率Docker 层经常失败排查资源限制、权限、网络这几个指标不需要多复杂的监控系统流水线平台自带的数据就够用。定期看一次能发现很多没人主动报告但确实在变慢的问题。例如镜像体积持续膨胀往往意味着有人往 Dockerfile 里加了调试依赖但一直没清理。6.3 文档与约定告诉别人为什么比怎么做更重要最后想说的是团队真正把 Docker 用成 CI/CD 的基石靠的不是几个人写出几个漂亮的 Dockerfile而是所有人对几个核心约定有一致的理解为什么用多阶段构建、为什么不能手改部署 tag、为什么基础镜像不能挂latest。我在跟同事协作时最大的体会是给一份配置模板大家能抄但遇到问题不会改把为什么这么做讲清楚大家写出来的内容才可能保持方向一致。文档不需要写成长篇大论每隔一两周更新几条当季有效的约定比年终做一次大型培训有用得多。最后再分享一个小习惯。我每次修改团队基础镜像或 Dockerfile 规范时都会顺手在代码评审里写清楚这次变更对构建时长的影响。很多时候我们优化了 30 秒的构建时间但对所有微服务来说每次都省 30 秒累积起来就是实打实的一天时间。从 CI/CD 的视角看Docker 的价值不只是帮你把环境固定住它也是在帮你把每一次构建的时间成本降到最低。这个系列后面还有内容下一篇打算聊聊不同 CI 平台之间的流水线差异到时候再展开。