迁移前的准备别偷懒
公司最近要换服务器，原来的那台老旧的物理机撑不住了。最头疼的是跑在上面的十几个容器服务，从数据库到前端网关全在里面，一个弄不好整个业务就得停摆。
很多人觉得容器天生轻量，搬起来容易。但真动手才发现，镜像版本、网络配置、存储挂载、环境变量这些细节一出问题，服务就起不来。所以迁移前先列个清单：当前容器列表、依赖关系、端口映射、数据卷路径，一样都不能少。
镜像同步是第一步
本地构建的镜像得推到私有仓库或者新主机上直接导出导入。用 docker save 和 load 最稳妥：
docker save -o app.tar myapp:latest然后把 tar 包拷到新机器：
docker load -i app.tar这招适合没有私仓的小团队，虽然慢点，但稳当。
网络模式别乱动
原来用 bridge 模式的容器，迁过去之后默认网络可能不一样。特别是多个容器之间靠自定义 bridge 通信的，得提前在新主机上创建同名网络：
docker network create mynet不然启动后互相 ping 不通，查半天才发现是网络隔离了。还有那些用了 host 网络模式的服务，记得新宿主得开放对应端口，防火墙也得调。
数据卷迁移要小心
数据库容器最怕丢数据。用 bind mount 的还好办，直接 rsync 同步目录就行：
rsync -avz /var/lib/mysql/ user@newhost:/var/lib/mysql/要是用的是 named volume，就得进容器里打包导出，或者用工具如 docker-volume-rsync，不然数据根本带不过去。
批量启动用脚本省事
一个个手动 run 容器太累，写个 shell 脚本或者用 docker-compose.yml 统一管理更靠谱。比如把所有服务写进 compose 文件：
version: '3'\nservices:\n web:\n image: myweb:latest\n ports:\n - \"80:80\"\n networks:\n - mynet\n db:\n image: mysql:5.7\n environment:\n MYSQL_ROOT_PASSWORD: example\n volumes:\n - dbdata:/var/lib/mysql\n networks:\n - mynet\nnetworks:\n mynet:\n driver: bridge\nvolumes:\n dbdata:到了新机器一键 up 就行：
docker-compose up -d中间如果报错，看日志定位问题比盲人摸象强多了。
别忘了验证和监控
服务起来了不代表没问题。登录后台看看接口能不能调通，数据库有没有连上，日志里有没有报错。最好有个简单的健康检查页面，或者用 curl 批量探测关键路径：
curl -f http://localhost/api/health确认无误后再切流量，别急着收工。
上次我就图快，刚启动完就改 DNS，结果缓存服务没连上 Redis，用户登录全失败，半夜被叫起来回滚。教训啊。