Docker Compose 环境变量文件分层实践

Docker Compose 真正进入团队日常以后，最容易变乱的不是容器本身，而是环境变量。数据库地址、Redis 密码、第三方 key、功能开关，只要项目一多，.env 很快就会变成谁都不敢动的文件。

2021 年我越来越倾向于先把环境变量按用途分层，而不是把所有配置都堆进一份本地文件里。

先区分公共配置和个人配置

比较实用的一种分法是:

• 仓库里提交一份公共示例配置
• 本地机器再维护一份个人覆写配置
• CI 或部署环境走独立注入

这样团队成员至少能看到哪些变量是必须的，也不至于把个人密钥直接提交进仓库。

Compose 文件里只保留稳定接口

我不太喜欢在 docker-compose.yml 里写大量分支逻辑。更稳的方式是让 Compose 文件只表达稳定的服务拓扑，而把会变化的值交给 env file。

例如镜像版本、端口、数据库连接串、调试开关这些都更适合放到变量层。

命名约定比技巧更重要

一个项目里最怕的是同类变量命名到处不同，比如数据库主机有的叫 DB_HOST，有的叫 MYSQL_HOST，有的又叫 DATABASE_URL。短期似乎都能跑，长期维护非常痛苦。

我更倾向于尽量统一命名风格，并用注释说明哪些是 Compose 读取的，哪些是应用本身读取的。

本地依赖和线上配置不要互相污染

开发环境常常会临时打开调试端口、弱密码、mock 服务，这些都不应该直接沿用到测试或线上。env file 分层的真正价值，恰好就是把这些差异显式化。

一旦差异被放到明面上，切环境就不会靠口口相传。

小结

Docker Compose 的环境变量管理，说到底是在解决“同一套服务拓扑如何适配不同运行环境”。把公共配置、个人配置和部署配置先分层，团队协作会稳定很多。