Docker DevOps指南

Docker 通过让环境可移植、可复现、可扩展，彻底改变了软件开发。到 2026 年，Docker 已是每一位开发者的必备工具——云原生计算基金会（CNCF）的年度调查显示，89% 的组织在用容器。可几乎每个 DevOps 工程师都经历过：镜像在自己的笔记本上构建得好好的，一到生产环境就报个晦涩的 exec format 错误，或者三天后才爆出来缺库。采用 Docker 的关键其实不在于会敲 docker run，而在于把容器工作流工程化，让「构建—交付—运行」在真实负载下保持可复现。2026 年，约 40% 跑容器的组织报告说他们一半的部署仍是手工完成，而「正经容器化」和「随便贴个 Dockerfile」的两类团队的差距，最终会体现在宕机、镜像臃肿和深夜回滚的账单上。

这份指南是一条决策路径而不是功能巡礼。你会从选基础镜像一路走到在真实 CI/CD 流水线里跑容器，附带具体命令、真实仓库定价，以及生产环境里最常见的坑。它和本站的cloud devops course（英文）互为表里，那份更偏系统课程，这篇更强调当下就上手的决策。

先决定基础镜像，这是最高杠杆的决定

绝大多数新手默认选全尺寸镜像就错了。一个典型的 ubuntu:latest 基础镜像在装任何东西之前就先垫进去 70–80MB，如果包集里再带上编译工具链，最终镜像很容易膨胀过 1GB。当你在 CI 里反复拉镜像、往按 GB 计费的仓库里存镜像时，每一个 MB 都算钱。实用的原则是：让基础镜像匹配你的运行时，而不是匹配你的构建机。

• Go、Rust 或静态编译二进制：用 scratch 或 distroless，最终能压到 5–20MB。
• Node.js：从官方 node:20-slim 或 alpine 变体起步，别用完整构建镜像。
• Python：优先 python:3.12-slim，把构建镜像留给需要头文件才能 pip 编译的场景。
• 如果必须跑 bash、curl 或 ps：用带调试工具的 distroless 变体，别往 alpine 里堆工具。

真正能瘦身的多元构建（Multi-stage）

多阶段构建是砍镜像体积最有效的一招，可很多 Dockerfile 还是把工具链整个拷进了最终镜像。模式很简单：用一个阶段去编译或装依赖，然后只把需要的产物拷进一个干净、精简的最终阶段。以 Node 应用为例：第一阶段（builder）用 npm ci --production=false 装依赖并构建应用；第二阶段（prod-deps）只装生产依赖；第三阶段（runtime）拷入编译产物和第 2 阶段的 node_modules，并以非 root 用户运行。结果经常是从 900MB 干到 150MB 以下且功能毫无变化，镜像也更安全——构建阶段的凭据和源码永远不会进仓库。

层缓存：构建速度的倍数放大器

很多团队在不自知的情况下每分钟都在丢构建时间。Docker 把每条指令当一层，并缓存未变化的层。技巧是把「经常变化」的文件放最后：先 COPY package.json 或 requirements.txt，跑依赖安装，最后再 COPY 其余源码。这样一次小的代码改动就不会使昂贵的依赖层失效。常见错误是在 npm install 之前用 COPY . . 把全量源码拷进去，这会让每次改文件都白费整个缓存。立刻补一份 .dockerignore，排除 node_modules、.git、本地日志和构建产物——跳过这一步的团队往往要含泪发现：一个 10KB 的代码改动触发了整整十分钟的依赖重装，而不是十秒。

怎么选容器仓库（Registry）

仓库决定你的拉取速度、存储账单，往往还有安全基线。各家在免费额度和每 GB 价格上差别很大，动手前值得先比一比。下表是 2026 年最常见的几家。

独立项目或创业早期，从 GHCR 或 Docker Hub 免费档起步最快。一旦上量，如果你已经跑在某朵云上，就选计算区离得最近的仓库——离得越近，出流费越低、拉取延迟越小。想看容器之外更多运维话题，可参考本站的 docker beginners guide（英文）。

编排：什么时候 Docker Compose 不够用

Docker Compose 应付本地多容器场景绰绰有余。当你开始关心自动故障转移、跨节点扩缩容、滚动发布，就得看 Kubernetes 这类编排器了。但别为了用而用：单机几个服务加个重启策略，比一个没人能运维的 K8s 集群靠谱得多。把「该不该上 K8s」的判断标准定成可验证的指标——比如「是否真的需要跨宿主机扩缩容」或「是否需要无缝滚动更新」，而不是「别人都在用」。想补齐 CI/CD 与流水线拼图，本站的 AI 办公自动化技巧讲了不少把重复操作自动化的思路，和容器化的精神一脉相承。

生产环境的常见坑

把基础镜像、多阶段、层缓存都做对了，生产里仍会踩坑。最常见的有：容器以 root 跑（一旦被打穿权限极大）、日志不落盘导致磁盘撑爆、时区/编码环境变量没配、健康检查没做导致编排器不知道该重启谁。挨个对着检查一遍，能省掉大部分半夜告警。更系统地梳理运维知识，建议配合 Python 自动化脚本看——脚本和容器都是把「一次性的手工操作」变成「可复现的自动化」。

常见问题

个人项目该用哪种基础镜像？

看你最终要跑什么。静态编译选 scratch/distroless，Node 选 slim，Python 选 -slim。别默认 ubuntu:latest——那是在给每个镜像垫砖。

多阶段构建会不会让 CI 变慢？

通常不会，反而更快。构建阶段照常完整运行，只是最终产物更薄、推送到仓库更快。配合层缓存把「经常变的放最后」，整体体验通常是净提升。

一定要用 Kubernetes 吗？

不。没有跨宿主机扩缩容或无缝滚动更新的硬需求时，Compose + 重启策略更省心。K8s 的运维成本很高，多数小团队根本摊不平。

私有仓库选 Docker Hub 还是本云？

先看拉取速度和账单。你在哪朵云跑计算，就优先选那家的仓库或云内镜像加速，出流费最低。Harbor 适合对数据主权或安全有硬性要求、且有人力运维的团队。

延伸阅读

把这套内容往工程纵深带：software testing basics（英文）补测试环节，数据分析基础帮你用数据驱动运维决策，则提供更多效率工具向的补充。