我在生产环境踩过的坑：Docker 部署的甜与苦

大家好，我是33blog的运维老司机。今天想和大家聊聊 Docker 部署这个既让人爱又让人恨的技术。记得第一次用 Docker 部署生产环境时，那种”一行命令搞定所有依赖”的爽快感至今难忘。但后来遇到的坑，也让我掉了不少头发…

Docker 带来的三大爽点

先说优点吧，不然显得我太怨妇了。最让我惊喜的是 环境一致性。以前开发说”在我本地是好的啊”，现在直接把 Dockerfile 甩过去：”按这个 build 的镜像跑不起来？” 问题立刻明朗。

其次是 资源隔离。我们有个 Python 2.7 的老项目和新版 Python 3 服务要共存，以前用 virtualenv 都提心吊胆。现在？一个 --network=host 就解决了所有依赖冲突。

# 老项目的启动方式
docker run -d --name legacy-app python:2.7 app.py

# 新服务的启动方式
docker run -d --name new-service python:3.9 service.py

最后是 快速部署。有次凌晨三点线上服务崩了，用 Docker 配合 CI/CD，从修复到回滚只用了 8 分钟（包括我穿裤子的时间）。

那些年我们踩过的 Docker 坑

但 Docker 也不是银弹。最痛的一次是 存储卷权限问题。我们的日志收集服务突然不工作了，排查半天发现是 Docker 容器内用户对挂载目录没写权限。后来养成了习惯，所有挂载命令都加上 :Z 后缀：

# 血泪教训后的正确姿势
docker run -v /host/path:/container/path:Z your-image

还有 网络配置的玄学。有次两个容器明明在同一个网络，就是 ping 不通。最后发现是 iptables 规则被运维同学”优化”过。现在我们的 checklist 里多了条：”确认 firewalld 没在偷偷搞事情”。

性能与安全的平衡术

很多人以为容器没性能损耗，直到我们有个高频 IO 服务响应时间从 20ms 暴涨到 200ms。后来发现是默认的 overlay2 存储驱动不适合我们的场景，换成 devicemapper 才解决。

安全方面也有讲究。有次安全扫描发现我们的基础镜像有 CVE 漏洞，从此我们定下规矩：所有官方镜像必须指定完整版本号，绝不使用 latest tag。

# 错误示范
FROM nginx:latest

# 正确姿势
FROM nginx:1.21.6-alpine

我的 Docker 生存法则

经过这些教训，我总结了几条实战经验：

• 所有容器必须设置内存/CPU 限制，防止单个容器拖垮主机
• 生产环境永远用 docker-compose 或 K8s，拒绝手动 docker run
• 日志全部输出到 stdout/stderr，用 ELK 收集
• 镜像构建遵循最小化原则，一个服务一个容器

说到底，Docker 就像把瑞士军刀 – 用对了事半功倍，用错了可能伤到自己。你们在 Docker 化过程中遇到过什么有趣的问题？欢迎在评论区分享~