3、容器化基础：Docker 镜像构建、容器生命周期管理、常用命令与最佳实践

容器化是云原生架构的基石，而 Docker 作为目前应用最广泛的容器引擎，其核心价值在于通过“镜像”实现应用与运行环境的标准化打包，并通过“容器”提供隔离、可移植的运行实例。理解 Docker 的镜像分层机制、容器生命周期状态机以及日常操作命令，是构建、交付和运维云原生应用的前提。本章将深入剖析 Docker 镜像构建的底层原理、容器从创建到销毁的完整流程，并结合实战场景给出可落地的操作规范与排障方法。

上图展示了 Docker 工作流的三条主线：左侧为镜像构建链路（Dockerfile → 镜像层 → 仓库），中间为容器生命周期状态机（Created → Running → Exited），右侧为贯穿始终的最佳实践。这三者并非孤立，镜像构建质量直接决定容器运行时的安全与效率，而生命周期管理则是对镜像价值的动态兑现。下面我们将逐一展开。

3.1 核心原理：镜像分层与容器可写层

Docker 镜像采用分层（Layer）存储架构，这是理解镜像构建与容器运行的关键。每个 Dockerfile 指令（如 FROM、RUN、COPY）都会生成一个只读层，多个层叠加形成完整的镜像文件系统。当使用 docker run 创建容器时，Docker 会在镜像层之上挂载一个可写层（Container Layer），所有对文件系统的修改（写入、删除、修改）都发生在该层，而底层镜像层保持不变。这种设计带来了三个核心优势：

• 存储效率：多个容器共享同一镜像的只读层，每个容器仅增加一个轻量可写层，显著节省磁盘空间。
• 构建缓存：构建新镜像时，若某层未发生变化，Docker 可直接复用缓存层，大幅加速构建过程。
• 版本管理：镜像层具有内容寻址特性，可通过层 ID 追溯历史变更，便于回滚与审计。

然而，分层机制也带来一个常见陷阱：层数过多或单层体积过大会导致镜像臃肿。例如，在同一个 RUN 指令中执行 apt-get update 与 apt-get install 后，若不清理 /var/lib/apt/lists 缓存，这些临时文件会永久保存在该层中，无法在后续层中删除（因为层是只读的）。因此，最佳实践是合并相关命令并清理临时产物。

3.2 镜像构建：Dockerfile 编写与多阶段构建

镜像构建的核心是编写高质量的 Dockerfile。一个典型的 Node.js 应用 Dockerfile 如下：

# 阶段一：构建依赖
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# 阶段二：运行环境
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

上述 Dockerfile 体现了三个关键实践：

1. 多阶段构建：第一阶段安装编译依赖，第二阶段仅复制产物，最终镜像不包含构建工具链，体积可减少 50% 以上。
2. 依赖清单先行：先复制 package*.json 再执行 npm ci，利用层缓存机制——只要依赖文件不变，后续构建可直接复用该层，无需重新下载依赖。
3. 非 root 运行：通过 USER node 切换至普通用户，降低容器逃逸风险。

构建命令 docker build -t myapp:1.0 . 会逐条执行 Dockerfile 指令并生成镜像层。若需指定平台或使用 BuildKit 增强缓存，可添加 --platform=linux/amd64 或设置环境变量 DOCKER_BUILDKIT=1。

3.3 容器生命周期管理：状态机与操作命令

容器的生命周期可抽象为五个核心状态：Created（已创建未启动）、Running（运行中）、Paused（暂停，进程挂起）、Exited（已停止）和 Dead（异常状态）。下表总结了状态转换的关键命令：

在实际运维中，docker run 是最常用的命令，其参数组合决定了容器的资源限制、网络模式与存储挂载。例如：

docker run -d --name web \
  -p 8080:80 \
  --memory="512m" \
  --cpus="1.5" \
  --restart=always \
  -v /host/data:/app/data \
  myapp:1.0

上述命令启动了名为 web 的容器，映射端口、限制内存与 CPU、设置重启策略并挂载数据卷。--restart=always 确保容器异常退出后由 Docker 守护进程自动拉起，这是生产环境的基本要求。

3.4 实战案例：构建并运行一个高可用 Nginx 容器

下面通过一个完整案例，演示从镜像构建到容器生命周期管理的闭环。假设我们需要部署一个带自定义配置的 Nginx 反向代理，要求镜像体积小、配置可热更新、容器异常自动恢复。

背景与约束：生产环境为 CentOS 7 主机，Docker 版本 24.0，需部署 3 个 Nginx 实例组成集群，每个实例限制 256MB 内存、1 个 CPU 核心，配置目录需持久化。

步骤一：编写 Dockerfile

FROM nginx:1.25-alpine
COPY nginx.conf /etc/nginx/nginx.conf
COPY ssl/ /etc/nginx/ssl/
RUN chown -R nginx:nginx /etc/nginx/ssl && \
    chmod 600 /etc/nginx/ssl/*.key
EXPOSE 443
CMD ["nginx", "-g", "daemon off;"]

步骤二：构建镜像

docker build -t nginx-proxy:1.0 .

步骤三：启动容器并验证

docker run -d --name nginx-1 \
  -p 8443:443 \
  --memory="256m" --cpus="1" \
  --restart=always \
  -v /opt/nginx/conf:/etc/nginx/conf.d:ro \
  nginx-proxy:1.0

# 验证容器状态
docker ps --filter "name=nginx-1"
# 输出 STATUS 为 "Up 5 seconds (healthy)" 表示健康

# 测试访问
curl -k https://localhost:8443/health

步骤四：模拟故障与恢复

# 强制杀掉容器主进程
docker kill nginx-1
# 等待 3 秒后查看状态
docker ps --filter "name=nginx-1"
# 由于 --restart=always，容器会自动重启，STATUS 显示 "Up 2 seconds"

结果对比与复盘：通过 docker stats 观察，容器内存稳定在 180MB 左右，符合预期。该方案的关键收益在于：镜像仅 45MB（基础镜像精简）、配置通过挂载卷热更新（无需重建镜像）、异常自动恢复（减少人工干预）。风险点在于 --restart=always 可能导致容器频繁重启时资源耗尽，需配合 --restart=on-failure:5 限制重启次数。

3.5 常用命令速查与排障思路

除生命周期命令外，以下命令在诊断与调试中高频使用：

• docker logs -f <container>：跟踪容器日志，排查应用错误。
• docker exec -it <container> /bin/sh：进入容器内部，检查进程与文件系统。
• docker inspect <container>：查看容器详细配置（IP、挂载、环境变量）。
• docker stats：实时监控容器资源占用。
• docker top <container>：查看容器内进程列表。

当容器启动失败时，建议按以下顺序排查：

1. 执行 docker logs <container> 查看应用日志，定位启动报错。
2. 执行 docker inspect 检查挂载卷权限、端口映射是否冲突。
3. 若日志为空，尝试 docker run --entrypoint /bin/sh 覆盖入口点，手动执行启动命令。
4. 检查宿主机 dmesg 是否有 OOM（内存溢出）记录，确认资源限制是否过小。

3.6 常见误区与总结复盘

在 Docker 使用中，以下误区极易导致生产事故，需特别警惕：