Docker Compose 常用写法：从一份文件管好多个容器

用 Docker 跑单个容器很简单，一条 docker run 命令就能启动。但服务一多，问题就来了：数据库、缓存、应用、反向代理要按顺序启动，端口、数据卷、环境变量散落在各条命令里，换台机器重建一次就要翻半天历史记录。Docker Compose 就是为了解决这个问题而生的：把多个容器的配置写进一份 YAML 文件，一条命令拉起整套服务，配置可版本管理，也方便复用和排错。

一份最常见的 compose.yml 从 services 开始。每个 service 就是一个容器，image 指定镜像，container_name 方便识别，ports 做端口映射，environment 传环境变量，volumes 挂载数据卷，restart 控制异常退出后的重启策略。比如一个 Web 应用加数据库的组合：应用依赖数据库，可以用 depends_on 声明启动顺序；数据库用命名卷保存数据，即使容器删除重建，数据也不会丢失；只把应用端口暴露给宿主机，数据库端口不对外映射，只在内部网络互通，更安全。

网络和数据卷建议显式声明。默认情况下，Compose 会为项目创建一个内部网络，同一项目内的服务可以用服务名直接互访，不需要写 IP 地址。命名卷则在文件顶部的 volumes 段统一声明，备份时只要知道卷名就能找到数据。环境变量敏感信息不要直接写进文件，可以用 env_file 引用一个不进版本库的 .env 文件，或者只在部署机器上通过环境变量注入，避免密钥随代码扩散。

日常操作记住几个常用命令就够了。docker compose up -d 以后台方式启动整套服务，docker compose ps 查看运行状态，docker compose logs -f 某个服务名可以实时看日志。docker compose down 停止并删除容器和网络，但默认不删命名卷，数据还在；如果确实要清理卷，必须显式加上 -v，这个参数要谨慎使用。更新镜像时先 docker compose pull，再 up -d，Compose 会只重建镜像变化的服务，不影响其他容器。

有几个常见坑值得提前避开。第一，ports 的写法是“宿主机端口:容器端口”，写反了服务就访问不通；第二，depends_on 只保证启动顺序，不保证数据库已经就绪，应用第一次启动连不上数据库时，可以靠 restart 或者应用自身的重试逻辑兜底；第三，数据卷路径用相对路径时是相对于 compose 文件所在目录，换目录执行命令路径就变了，尽量固定工作目录；第四，生产环境不要用 latest 标签，锁定具体版本号，升级才可控、可回滚。

Compose 的价值不在于语法多复杂，而在于把“这套服务由哪些容器组成、怎么连、数据放哪”写成一份人人能看懂的文档。新人接手不用猜命令，故障恢复不用凭记忆，备份迁移只要拷走 compose 文件和数据卷。下次部署多容器服务时，先写 compose 文件再谈优化。