5.2 Docker 容器化部署生产实践

预计阅读时间：14 分钟

学习目标

学完本章后，你将能够：

• 编写生产级 Dockerfile（多阶段构建、非 root 运行、健康检查）
• 配置 Docker Compose 的生产环境参数
• 实施容器安全最佳实践（权限降级、资源限制、镜像扫描）
• 管理容器日志轮转和数据卷备份
• 使用 Docker 原生监控和健康检查机制

核心知识

• 多阶段构建（Multi-stage Build）——在单一 Dockerfile 中使用多个 FROM 指令，构建阶段包含所有编译工具，最终阶段只复制产物，大幅减小镜像体积
• 根文件系统只读（Read-only Root FS）——容器启动时设置 --read-only，阻止向文件系统写入，提升安全性
• capability 降级——Linux capability 机制将 root 权限拆分为细粒度单元，应删除所有非必需 capability
• HEALTHCHECK——Docker 原生健康检查指令，Docker Engine 定期执行探测，自动重启不健康容器
• 资源限制（Resource Limits）——通过 --memory 和 --cpus 限制容器资源使用，防止单容器耗尽宿主机
• 日志驱动（Log Driver）——Docker 支持多种日志驱动，生产推荐 json-file 配合轮转或 journald
• 镜像安全扫描——通过 Trivy、Clair 等工具扫描镜像中的已知漏洞（CVE）
• 数据卷备份——用临时容器挂载数据卷打包归档

知识关联

• 前置知识：3.1：Docker 容器入门 Docker 容器入门（基本命令与概念）
• 后续影响：本章实践是 6.2：Kubernetes 入门 Kubernetes 和 4.9：CI/CD 持续部署 CI/CD 流水线的基础
• 配套工具：3.12：系统监控与告警 系统监控（容器监控指标）、4.8：集中式日志管理 集中式日志（容器日志聚合）

原理讲解

镜像体积为什么重要

镜像体积直接影响部署速度、磁盘占用和安全面。以 Go 应用为例：golang:1.22 镜像约 1.1GB，而 alpine:3.20 仅约 8MB。多阶段构建使最终镜像只包含编译产物和运行时依赖，从 GB 级降至数十 MB。更小的镜像意味着更快的拉取（尤其在大规模集群中）、更小的攻击面（仅包含必要包）和更少的磁盘开销。

Root 容器的风险

默认情况下，容器内以 root 运行。如果攻击者通过应用漏洞获得容器内 shell，即拥有主机级别的 root 权限（尽管受 namespace 限制）。真正的风险在于容器逃逸——如果存在内核漏洞或配置不当（如 --privileged 或挂载 /proc 等敏感路径），容器内 root 可直接获得主机 root。因此生产容器应始终以非 root 用户运行。

Docker 日志机制

Docker 默认将容器的 stdout/stderr 写入 /var/lib/docker/containers/<id>/<id>-json.log。不做轮转管理时，这个文件会无限增长，最终填满磁盘。生产环境必须配置日志轮转（max-size + max-file），或将日志转发到集中式日志系统（如 4.8：集中式日志管理 Elastic Stack）。

镜像分层与构建缓存

Docker 镜像由只读层（layer）堆叠而成，每一条 Dockerfile 指令对应一层，层之间共享复用。构建时 Docker 会按层对比缓存：如果某条指令及其上下文未变化，该层直接复用缓存，这就是"把 COPY go.mod go.sum 放在 COPY . 之前"能显著加速构建的原因——依赖层固定了，只有源码变更时才重新编译。

层是共享的：同一宿主机上两个镜像如果基础层相同，磁盘上只存一份。这也是为什么要避免把频繁变化的内容放在基础层——每次变更都会让该层之后的所有层缓存失效。生产实践中建议：apt/yum 安装与 源码拷贝分开，npm ci 与 COPY . 分开，让依赖安装层尽量稳定。

镜像标签与版本管理

latest 标签在生产环境是反模式：它指向的镜像随时会变，无法保证两次拉取内容一致，也就无法精确回滚。正确的做法是使用不可变标签：myapp:1.4.2 或带 Git 提交哈希的 myapp:8f31a2e。镜像仓库应同时保留多个版本（常见策略：保留最近 5 个版本），配合 CI 流水线在构建时自动打上版本标签，并同步更新 Compose 文件中的镜像引用。回滚时只需把 Compose 中的 tag 改回上一版本重新部署，无需重新构建。

示例代码

1. 生产级 Dockerfile

# Dockerfile.prod —— 生产级多阶段构建
FROM golang:1.25-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app/server

FROM alpine:3.20
RUN apk add --no-cache ca-certificates tzdata && \
    addgroup -S appgroup && adduser -S appuser -G appgroup

COPY --from=builder /app/server /usr/local/bin/server
COPY --from=builder /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

USER appuser
WORKDIR /home/appuser
EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
    CMD wget -qO- http://localhost:8080/health || exit 1

CMD ["server"]

# 构建命令
# docker build -t myapp:latest -f Dockerfile.prod .
# 查看镜像大小
# docker images myapp
# 输出: myapp    latest    3a4b5c6d7e8f    2 minutes ago   24.7MB

2. Docker Compose 生产配置

# docker-compose.prod.yml（Docker Compose v2+ 已废弃 version 字段，直接定义 services）
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile.prod
    restart: always
    ports:
      - "127.0.0.1:8080:8080"   # 仅绑本地，前面用 Nginx 反代
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
        reservations:
          memory: 128M
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    read_only: true
    tmpfs:
      - /tmp

  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - redis_data:/data
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  redis_data:

# 启动
# docker compose -f docker-compose.prod.yml up -d
# 查看状态
# docker compose -f docker-compose.prod.yml ps

3. 容器安全最佳实践

# 非 root 运行 + 只读文件系统 + 临时目录
docker run -d \
  --user 1000:1000 \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt=no-new-privileges:true \
  --memory=256m \
  --cpus=0.5 \
  myapp:latest

# 镜像安全扫描
# 安装 Trivy
sudo apt install trivy -y

# 扫描镜像漏洞
trivy image myapp:latest
# 输出: (列出 CRITICAL/HIGH/MEDIUM 级别 CVE)

# 扫描文件系统
trivy filesystem --severity CRITICAL,HIGH /path/to/project

# Docker Bench Security（一键安全审计）
docker run --rm --net host --pid host \
  -v /etc:/etc:ro \
  -v /var:/var:ro \
  -v $(which docker):/usr/bin/docker \
  docker/docker-bench-security

4. 日志管理与轮转

# Docker Daemon 全局日志配置
# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true
}

# 重启 Docker 使配置生效
sudo systemctl restart docker

# 查看容器日志
docker logs --tail 50 myapp          # 最近 50 行
docker logs --tail 100 --follow myapp # 持续追踪

# 查看日志文件占用
sudo du -sh /var/lib/docker/containers/*/*-json.log

# 手动清理（谨慎使用）
sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"

5. 数据卷备份与恢复

# 备份数据卷
docker run --rm \
  -v myapp_redis_data:/data \
  -v $(pwd):/backup \
  alpine tar -czf /backup/redis_$(date +%Y%m%d).tar.gz -C /data .

# 恢复数据卷
docker run --rm \
  -v myapp_redis_data:/data \
  -v $(pwd):/backup \
  alpine tar -xzf /backup/redis_20260730.tar.gz -C /data

# 镜像导出迁移（离线环境）
docker save -o myapp_image.tar myapp:latest
# 在目标主机导入
docker load -i myapp_image.tar

# 定期备份脚本（配合 cron）
# 0 3 * * * /usr/local/bin/backup-docker-volumes.sh

6. 容器资源监控

# 实时资源使用
docker stats
# 输出:
# CONTAINER ID   NAME      CPU %     MEM USAGE / LIMIT    MEM %     NET I/O
# a1b2c3d4e5f6   myapp     2.34%     48.2MiB / 256MiB    18.8%     1.2kB / 3.4kB

# 查看容器具体进程
docker top myapp

# 查看容器元数据（包括资源限制、挂载等）
docker inspect myapp

# 事件流监控
docker events --filter 'container=myapp'

# 容器内进程树
docker exec myapp ps aux

7. 私有镜像仓库

# 搭建 Docker Registry（带认证）
mkdir -p /opt/registry/{auth,data}
# 用 htpasswd 生成访问凭证
docker run --rm --entrypoint htpasswd registry:2 \
  -Bbn admin 'Str0ng-P@ss' > /opt/registry/auth/htpasswd

docker run -d --name registry \
  -p 5000:5000 \
  -v /opt/registry/data:/var/lib/registry \
  -v /opt/registry/auth:/auth \
  -e "REGISTRY_AUTH=htpasswd" \
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
  -e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd" \
  --restart=always \
  registry:2

# 推送镜像到私有仓库
docker login 10.0.0.10:5000
docker tag myapp:1.4.2 10.0.0.10:5000/myapp:1.4.2
docker push 10.0.0.10:5000/myapp:1.4.2

# 其他主机拉取（需配置 insecure-registries 或 HTTPS 证书）
docker pull 10.0.0.10:5000/myapp:1.4.2

# 清理仓库中没有被任何镜像引用的层（GC）
docker exec registry bin/registry garbage-collect /etc/docker/registry/config.yml

8. 更新与回滚

# 滚动更新：Compose 重建容器（单副本有短暂中断；多副本 + 上游 LB 才接近零停机）
docker compose -f docker-compose.prod.yml up -d --no-deps app

# 指定镜像版本部署（避免 latest）
docker compose -f docker-compose.prod.yml up -d \
  --no-deps --pull always app

# 回滚到上一版本（改回旧 tag 后重新创建）
docker compose -f docker-compose.prod.yml up -d \
  --no-deps --force-recreate app

# 单容器场景：先拉新镜像，再原子替换
docker pull myapp:1.4.2
docker stop myapp && docker rm myapp && \
docker run -d --name myapp ... myapp:1.4.2

# 部署前备份数据卷（数据库等有状态服务）
docker run --rm -v myapp_data:/data -v $(pwd):/backup \
  alpine tar -czf /backup/data_pre_1.4.2.tar.gz -C /data .

常见错误

最佳实践

练习题

1. （概念）为什么生产环境中应该以非 root 用户运行容器？列出至少两个安全风险。
2. （概念）多阶段构建如何减小镜像体积？COPY --from=builder 的作用是什么？
3. （实操）基于 node:20-alpine 编写一个 Node.js 应用的 Dockerfile，实现：多阶段构建（builder 阶段安装依赖 + 编译）、最终阶段使用 node:20-slim、以非 root 用户运行、暴露 3000 端口、添加 HEALTHCHECK。构建后查看镜像大小。
4. （实操）编写 docker-compose.prod.yml 包含两个服务：一个 Node.js 应用（上题的镜像）和一个 PostgreSQL 15 数据库。配置应用服务的内存限制为 256MB、CPU 限制为 0.5、日志轮转最大 5MB 保留 3 份、仅绑定本地 127.0.0.1:3000。
5. （🔍 挑战）使用 Trivy 扫描 nginx:latest 镜像，记录发现的 CRITICAL 级别 CVE。然后比较 nginx:alpine 和 nginx:alpine-slim 的扫描结果，分析不同变体的漏洞面差异。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

将 Docker 用于生产环境，远不止 docker run 那么简单。多阶段构建显著缩减镜像体积，非 root 用户和 capability 降级是容器安全的核心防线，HEALTHCHECK 和资源限制确保容器稳定运行。日志轮转防止磁盘溢出，数据卷备份和镜像导出保障数据安全。这些实践共同构成 Docker 生产级部署的基线——缺任何一项都可能在生产线上埋下隐患。

速查表

学习路径建议

• 学完本章后建议阅读 6.2：Kubernetes 入门 Kubernetes 入门（容器编排进阶）
• 继续深入学习可看 6.1：容器底层原理 容器底层原理（Namespace + Cgroups）
• CI/CD 集成可看 4.9：CI/CD 持续部署 CI/CD 持续部署（将 Docker 构建纳入流水线）

延伸阅读