docker compose 的正确用法：从单容器到可维护编排

把 docker run 改写成 compose 之后，很多人只是把命令搬进 yaml，结果还是「一套环境一份配置」，改一次要动五个文件。

compose 的价值在于「声明式」：把镜像版本、依赖关系、健康检查、数据卷都写清楚，换机器只需要 git clone + docker compose up。

先说结论

镜像固定 tag、依赖用 healthcheck、配置走 .env，数据走具名卷。 这四条做到，compose 才算用对。

• 镜像不要用 latest，固定到具体版本
• depends_on 配 condition: service_healthy
• 配置用 .env + environment，别写死在 yaml
• 数据用具名卷或绑定挂载，明确备份路径

先把问题说清楚

compose 文件本质是一份「期望状态」描述。它应该能表达：这个服务依赖谁、暴露什么端口、数据放哪、挂了怎么重启。

常见的反模式是把所有服务塞进一个 compose 文件却互相耦合，最后只能整体重启，失去了容器的隔离价值。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 给每个镜像固定版本 tag，升级时显式改版本号
• 为有状态服务加 healthcheck，并让依赖方用 condition: service_healthy
• 把可变配置抽到 .env，敏感值用 secrets 或环境变量注入
• 数据目录用具名卷，并在文档里写清备份命令
• 设置 restart: unless-stopped 与 logging 的 max-size，防止日志吃满盘

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 用 latest：某天自动拉新版本，行为变了却找不到原因
• 依赖只写 depends_on 不写健康检查：顺序对了但服务还没就绪
• 把密码写在 yaml 里提交到 git
• 数据不挂卷：容器一删数据全没

最后补两句

compose 文件应该能当文档读：任何人打开它，就知道这套服务怎么起、数据在哪、怎么备份。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。