折腾Docker部署时总会遇到些让人挠头的问题，上周我就亲眼见到同事因为存储驱动配置不当，把整个测试环境的镜像全搞丢了。其实Docker部署看似简单，但容器化带来的复杂度转移常常让人措手不及。尤其是当项目从开发环境转向生产环境时，莫名其妙的容器退出、网络不通、权限拒绝等问题，能把部署变成一场灾难现场。
网络配置这个大麻烦
记得有次给客户部署微服务，七个容器中有三个死活连不上Redis。用docker inspect查了半天，才发现默认的bridge网络导致容器DNS解析失效。更坑的是，在不同宿主机上部署时会随机出现端口冲突，明明测试环境好好的，一到生产环境就出幺蛾子。后来逼得我们直接在Docker Compose里写死容器IP段，虽然土但确实解决了问题。
容器权限的隐形炸弹
用root用户跑容器绝对是新人杀手锏。有回我们用现成的Nginx镜像跑服务，结果被安全部门扫描出高危漏洞——就因为这个镜像默认用root启动进程。就算加了user: nobody配置项，挂载的宿主机文件又会出现权限不符的问题。现在我的团队铁律是必须做USER指定，还要特别注意SELinux的context配置，说真的这比容器编排还费神。
资源限制的玄学现象
你看主机监控显示内存充足，但容器就是不定期重启？这是我们某次故障复盘发现的真相：JVM应用没设置堆内存上限，而Docker给容器的内存限制是2G。结果JVM按物理机内存分配堆空间，直接触发了OOM Killer。更绝的是docker stats显示的内存使用量竟然和docker events里的OOM记录对不上号，这种玄学问题让运维同学差点崩溃。
镜像体积的死亡膨胀
初期我们的镜像大小是250MB，三个月后竟然膨胀到1.6GB！Dockerfile里那些apt-get install和npm install操作跟滚雪球似的积累临时文件。最讽刺的是，业务代码只有20MB，剩余的1.58GB全是依赖和缓存垃圾。后来引入多阶段构建才勉强控制到300MB以内，不过这又带来了新的调试难题——某些依赖项在构建阶段被丢弃了但运行时又需要。
经历过血的教训后，我现在但凡写Dockerfile必定设置非交互式环境变量（ENV DEBIAN_FRONTEND=noninteractive），构建镜像时绝对加上--no-cache参数。各位要是正在被Docker部署问题折磨，不妨先检查这几个重灾区。下次咱们可以聊聊Docker日志管理那些更抓狂的事，比如怎么在吞掉磁盘的json.log中精准定位异常请求。
评论