5.1 容器化：Docker 把环境变成可移植

5.1 容器化：Docker 把环境变成可移植

摘要：微服务部署的第一个硬道理是环境一致——"在我机器上好的"在运维那里不该坏。Docker 把应用连同运行时一起打包成镜像，实现"环境即代码、处处能跑一样"。本文讲容器解决了什么、镜像怎么分层的、仓库/版本这些绕不开的细节，以及什么场景别急着上容器。

先给一个真实得不能再真实的场景：开发小哥打包好订单服务，跑到测试机上一跑——崩了，报错信息是"环境变量缺失"。查半天，原来他本地缺了一个环境变量没人知道。这种"我这好的你那坏"在微服务里会无限放大：二十个服务，二十次环境漂移。Docker 就是为根治"环境漂移"而生的。

容器解决的核心问题：环境即代码

Docker 把"应用 + 它需要的运行时/依赖/配置"一起打进一个镜像（Image），运行时就从这个镜像新建一个容器（Container）。镜像本身可复制、可版本化、可传到仓库。于是"部署"从"在一个环境里手工配齐一堆东西"，变成了"把同一个镜像放到哪都跑得一模一样"。

关键点在最后一段：同一个镜像，到哪都一个样。测试通过的那个镜像，就是上生产的那个镜像，中间没有任何"重装依赖"的步骤，环境漂移被从根上掐断了。

概念第一课：镜像、容器、仓库

三个词常被混，先钉死：

• 镜像（Image）：一个只读的、构建好的"模板"，像一张蓝晒底片。
• 容器（Container）：从镜像"烤"出来的运行中的进程实例，可起可停，改它不污染镜像。
• 仓库（Registry）：镜像的"寄存处"，好比存放底片的档案柜，负责镜像的分发和版本管理。

容器 vs 虚拟机的差异也值得记住：虚拟机虚拟化的是整台机器（带内核），开销大、启动慢；容器虚拟化的是用户空间层面的隔离（共享宿主机内核），更轻更快启动，但也意味着隔离性弱于虚拟机——一个容器逃逸理论上可以影响同宿主机其他容器，安全隔离要求高的场景要留意这一点。

走进镜像：一条构建文件的要点

下面是一个最小但完整的构建文件，注释把每一步讲清楚：

# 基于一个带了运行时的镜像作为底子
FROM node:20-alpine

# 先拷依赖清单，能利用缓存减少重复下载
COPY package.json ./
RUN npm install

# 拷贝应用代码
COPY . .

# 可选：非 root 用户降低权限风险
USER node

# 对外暴露的端口
EXPOSE 8080

# 容器启动时运行的命令
CMD ["node", "server.js"]
​

构建文件揭示的镜像机制叫分层：Dockerfile 的每条指令会生成一层只读层，共用底层层的镜像可以复用。好处是构建快、存储省——大多数服务共用同一个 node 底层，升级只 rebuild 上层。坏处也很实在：如果每一层之间塞了不该有的密钥，那这个密钥会残留在镜像的历史层里。

两个必须养成的习惯

其一，明确版本，别用漂移镜像。 镜像打出来要带明确的 tag（或不可变的摘要），后端部署用精确版本，而不是"最新版"。你迟早会踩"昨天最新版还是好的，今天最新版带了 bug"的坑。

其二，仓库要收好，别把密钥打进镜像。 镜像会被到处分发，一旦里面写死了数据库密码，就等于把密码发给了全世界。秘。密信息运行时通过环境变量、卷或密钥管理注入，绝不进构建文件。这和前面"每层都会留痕"呼应：密钥进了镜像层就再也擦不干净。

陷阱：容器不是"把系统镜像化"就完事

最容易踩的是"为了容器而容器"：把整个单体包一个大容器，里面又是 SSH 又是 init，跑起来像个"睡在容器里的虚拟机"。正确的方向是一个进程一个容器、一个容器一件事，日志写标准输出而非藏在文件里（第 5.3 的可观测性会要求这样），挂载点、数据、配置都要想清楚要不要进镜像。容器化不是把应用"塞进 docker run 就完事"，而是把"运维约定"重新设计一遍。

一个冷静的边界：什么时候别急着容器化

容器不是没成本：它要求团队要有镜像/仓库/编排的基建与运维能力。如果你只是几个服务、没有多环境部署难题、也没有规模化伸缩需求，那硬上 Docker 就是给"简单问题"硬套了一个"编排复杂度"。判断标准不是"潮流"，而是**"你的部署是否因为环境不一致或伸缩困难而真正存在痛点"**。有痛点，容器是解药；没痛点，它就是新支出的运维债。

容器化迁移时最容易漏掉的"三处改姿"

把已有服务迁进容器，最常出的问题不是写不出 Dockerfile，而是"容器写好了、行为却和以前不一样"。三处最容易被忽略的改姿先摆出来：

1. 日志不再写文件，走标准输出。容器里的文件随时会被销毁，"写日志到 /var/log 再半夜 grep"在容器里行不通。让日志打向 stdout/stderr 收集到统一日志平台，否则可观测性那一步直接抓瞎。
2. 只认环境变量和挂载卷，不认写死在代码里的配置。IP、端口、账号密码全部运行时注入，别让"部署了一个就改一次镜像"的坏习惯再生。环境不同靠同一镜像 + 不同配置就够。
3. 进程必须是前台主进程。容器里跑一个"后台 daemon + 脚本来管理"的模式会和编排平台打架。让容器就是应用一个前台进程，"挂了调度层自然重启"，比容器里套个进程管理要省心得多。

这三处理顺，"容器化"才不是把老一套换个壳，而是一套真正面向编排的新运维习惯。

本节要点

• 一节收束：容器把"环境"装进镜像，让"测试通过的镜像就是上线的镜像"

• 容器解决环境漂移："同一个镜像到处跑得一样"，根除"我这好你那坏"

• 镜像=只读模板，容器=运行实例，仓库=版本与分发

• Dockerfile 分层构建，共享底层快、但密钥会残留历史层

• 明确版本 tag、密钥运行时注入，别把敏感信息打进镜像

• 一进程一容器、日志走标准输出；没有痛点就别硬容器化