容器化迁移不是把代码丢进Docker就完事了

去年接手一个客户的容器化迁移项目，他们自己折腾了三个月，Dockerfile写好了，容器也能跑起来，但上线一周就rollback了。原因很简单：镜像1.8GB，每次部署拉镜像要6分钟；日志写在容器里，容器一重启全没了；配置硬编码在镜像里，换个环境就得重新打。

容器化迁移远不止写个Dockerfile把应用塞进去。这个坑不少团队都踩过。

坑一：镜像体积失控

很多团队的基础镜像用的就是ubuntu:latest，装完JDK、Maven、各种依赖后镜像膨胀到1.5GB以上。这不光浪费存储，更致命的是部署慢、扩容慢。

正确做法是用多阶段构建。第一阶段用完整镜像编译产物，第二阶段用alpine或者distroless基础镜像只拷贝最终产物。一个Spring Boot应用，用多阶段构建后镜像从1.6GB降到280MB左右，部署速度提升四倍。

坑二：数据写在容器层

容器重启后数据丢失，这个坑出现频率最高。任何需要持久化的数据——数据库文件、上传的文件、日志——都必须挂载到宿主机或者用外部分储。Dockerfile里用VOLUME指令声明挂载点，运行时通过-v映射到宿主机目录。如果是Kubernetes环境，用PersistentVolumeClaim管理存储。

坑三：配置耦合在镜像里

把数据库连接串、API密钥这些配置直接写进镜像，意味着每个环境都要打一个镜像。dev一个、staging一个、prod一个，维护噩梦。

规范做法是配置与镜像分离。环境相关的配置通过环境变量注入，Docker运行时用-e参数，K8s里用ConfigMap和Secret。镜像只打一次，到处运行。

坑四：没有健康检查

容器跑起来了不等于服务可用。必须配置健康检查。Dockerfile里写HEALTHCHECK指令，K8s里配livenessProbe和readinessProbe。livenessProbe探测失败容器会被重启，readinessProbe探测失败流量不会被路由过来。两个探针配合使用，才能实现真正的自愈。

容器化迁移的核心思路是：镜像要小、数据要外挂、配置要注入、健康要探测。做到这四点，迁移才算真正落地。