在前面的系列中，我们已经完成了从 Docker 基础 → 镜像原理 → 网络与存储 → 容器编排 → CI/CD 自动化部署 的完整学习路径。
当 Docker 真正进入生产环境后，关注点会发生明显变化：
- ❌ 能跑起来不再是目标
- ✅ 安全、稳定、可观测、可审计 才是核心
本篇将从生产环境视角，系统讲清 Docker 的三大关键能力建设：
安全（Security） / 监控（Monitoring） / 日志（Logging）
一、为什么生产环境必须重视 Docker 安全？
在开发环境中，我们经常会看到这样的容器配置：
Bash
docker run -d -p 80:80 --privileged my-app
但在生产环境，这种方式风险极高：
- 容器逃逸风险
- 镜像被植入后门
- 敏感信息泄露
- 宿主机被完全控制
核心认知：
Docker 并不是“天然安全”的，安全是需要设计和约束出来的
二、Docker 生产安全体系建设
1️⃣ 最小权限原则（Least Privilege）
❌ 错误示例
Bash
docker run --privileged my-app
--privileged 会让容器几乎拥有宿主机全部权限。
✅ 正确做法
- 禁止
--privileged - 精细化控制 Linux Capability
Bash
docker run \
--cap-drop ALL \
--cap-add NET_BIND_SERVICE \
my-app
2️⃣ 非 root 用户运行容器（非常重要）
Dockerfile 规范写法
Dockerfile
FROM node:20-alpine
# 创建非 root 用户
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY . .
USER app
CMD ["node", "server.js"]
收益：
- 防止容器逃逸后直接获得 root 权限
- 极大降低安全事故等级
3️⃣ 镜像安全：漏洞扫描是刚需
生产环境必须引入镜像扫描流程。
常见工具
| 工具 | 特点 |
|---|---|
| Trivy | 轻量、主流、CI 友好 |
| Clair | Harbor 官方集成 |
| Snyk | 商业化，规则完善 |
示例：Trivy 扫描镜像
Bash
trivy image my-app:latest
可扫描内容：
- OS 漏洞
- 依赖漏洞（npm / pip / go mod）
- 高危 CVE
4️⃣ Docker Secret 管理敏感信息
❌ 错误方式
Dockerfile
ENV DB_PASSWORD=123456
✅ 正确方式（Swarm 示例）
Bash
docker secret create db_password -
YAML
services:
app:
secrets:
- db_password
容器内以文件形式挂载，避免明文暴露。
三、生产环境 Docker 监控体系
没有监控的系统 = 不可控系统
1️⃣ Docker 自带监控（基础）
Bash
docker stats
可查看：
- CPU
- 内存
- 网络 IO
- Block IO
👉 仅适合临时排查，不适合生产
2️⃣ Prometheus + Grafana（主流方案）
架构示意
Docker Host
├─ node-exporter
├─ cAdvisor
└─ Prometheus → Grafana
3️⃣ cAdvisor：容器监控核心组件
Bash
docker run -d \
--name=cadvisor \
-p 8080:8080 \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:ro \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker:/var/lib/docker:ro \
gcr.io/cadvisor/cadvisor
采集指标包括：
- 容器 CPU / 内存
- 文件系统
- 网络流量
- 容器生命周期
4️⃣ Grafana 常用监控维度
生产环境建议至少关注：
- 容器 CPU / 内存使用率
- OOM Kill 次数
- 容器重启次数
- 节点磁盘空间
- 服务响应时间（结合应用指标）
四、Docker 日志体系设计
1️⃣ Docker 日志驱动机制
Bash
docker info | grep Logging
常见驱动：
| 驱动 | 说明 |
|---|---|
| json-file | 默认，不适合生产 |
| syslog | 写入系统日志 |
| fluentd | 推荐 |
| gelf | 对接 Graylog |
2️⃣ 为什么 json-file 不适合生产？
- 日志无限增长
- 占满磁盘
- 无集中检索能力
3️⃣ 推荐日志架构（EFK）
Container
→ stdout/stderr
→ Fluent Bit / Fluentd
→ Elasticsearch
→ Kibana
4️⃣ Docker 配置日志驱动
JSON
{
"log-driver": "fluentd",
"log-opts": {
"fluentd-address": "localhost:24224",
"tag": "docker.{{.Name}}"
}
}
Bash
systemctl restart docker
5️⃣ 应用日志规范（非常关键）
❌ 错误
JavaScript
console.log("error happened");
✅ 推荐结构化日志
JavaScript
console.log(JSON.stringify({
level: "error",
service: "order-service",
traceId,
message: "create order failed"
}));
好处：
- 可检索
- 可聚合
- 可告警
五、告警体系：让问题主动找你
监控 + 日志 ≠ 完整体系
必须配合告警
常见告警规则
- CPU 使用率 > 80%
- 内存持续增长
- 容器频繁重启
- 日志 error 激增
- 服务无响应
常见告警渠道
- 飞书 / 钉钉
- Slack
- PagerDuty
六、生产环境 Docker 最佳实践清单
✅ 安全
- 非 root 用户运行
- 禁用 privileged
- 镜像漏洞扫描
- Secret 管理
✅ 监控
- Prometheus + Grafana
- 容器 + 节点双层监控
- 关注重启和 OOM
✅ 日志
- 不用 json-file
- 统一 stdout
- 集中式日志平台
- 结构化日志
七、小结
Docker 在生产环境中，早已不只是一个“打包工具”，而是：
一套需要安全、监控、日志共同支撑的运行时平台
真正成熟的 Docker 体系，关注的是：
- 系统是否可观测
- 风险是否可控
- 故障是否可快速定位
下一篇预告（终章）
👉 Docker 进阶（七）：容器化体系设计总结与生产落地经验复盘
将从架构层面，完整复盘 Docker 在真实业务中的落地方式、踩坑经验与演进路线。
文章评论