还在用一长串 docker run 部署服务？换成 Docker Compose 之后省心的几个地方

刚开始在云服务器上用 Docker 跑服务时，很多人都是从 docker run 入门的：一条命令拉起一个容器，端口、挂载目录、环境变量全写在命令行里。服务少的时候没问题，等手里有三五个容器、还要互相配合的时候，这种方式就开始难受了：命令记不住，重建容器时参数抄错一个，服务就起不来；想迁移到另一台机器，更是要把一堆命令逐条找齐。

Docker Compose 解决的就是这个问题：把一个服务怎么跑，全部声明在一个 compose 文件里。下面几个地方，是换过去之后最明显的省心之处。

一、配置在文件里，不在记忆和聊天记录里

用 docker run，容器的全部参数只存在于你当时敲的那条命令里，终端记录一清就没了。用 Compose，镜像、端口映射、挂载卷、环境变量、重启策略都写在文件里，文件可以进版本管理，改了什么、什么时候改的都有记录。下次重建，不用回忆，直接 docker compose up -d 就按文件里的声明重新拉起来。

这也让“换机器”变得简单：把 compose 文件和数据卷一起拷过去，一条命令就能在新机器上复原整套服务，而不是逐个容器拼命令。

二、服务之间用名字互访，不要写容器 IP

多个容器配合时最常见的坑，是在配置里写死另一个容器的 IP。容器一重建，IP 就可能变，服务之间的调用立刻断掉。Compose 会为同一个文件里的服务建一张内部网络，服务之间直接用服务名互相访问，相当于一个稳定的内置域名，容器重建多少次都不受影响。数据库连接地址里写服务名而不是 IP，是从 run 换到 Compose 后最值得先改的一处。

三、启停和日志都以“项目”为单位

一堆 docker run 起来的容器，停的时候要一个个找名字。Compose 是按项目整体管理的：docker compose down 一次停掉整组，docker compose ps 一眼看全组状态，docker compose logs 可以把一组服务的日志合在一起看。排故障时不用再开几个终端分别跟每个容器的日志。

再配合每个服务写好 restart 策略，比如 unless-stopped，机器重启之后服务能自己回来，不用人工逐个拉起。对个人维护的小服务器来说，这一项省掉的半夜操作最实在。

四、几个容易踩的小坑

一是环境变量和密码不要直接写死在 compose 文件里，用同目录的 .env 文件承载，compose 会自动读取，文件本身进版本管理时也不会把密码带出去。

二是数据一定要落在命名卷或者明确的宿主机目录上，不要指望容器可写层存数据，容器一删数据就没了。哪些目录是数据、哪些可以随便重建，写文件的时候就想清楚。

三是升级镜像时先改文件里的版本号再 up，不要在命令行里临时拉一个新标签就跑，否则文件记录和实际运行版本对不上，下次重建又会打回去。

小结

docker run 适合临时试一个容器，长期维护的服务还是交给 Compose：配置有文件可查、服务互访有稳定名字、启停日志按组管理、重启能自恢复。迁移的成本不高，把现有容器的参数逐项抄进一个文件就行，抄完这一次，往后每次部署都在省时间。

（本文为个人运维实践记录。）