4 篇博文 含有标签「Docker Compose」

做本地开发编排时，一个很常见的错觉是: 只要容器进程起来了，服务就算可用了。实际情况往往不是这样，尤其是数据库、消息队列和依赖初始化步骤比较多的时候。

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

刚开始用 Docker Compose 做本地联调时，最容易犯的错误就是还在用宿主机思维理解容器之间的访问关系。比如 API 容器去连数据库时，配置里还写 127.0.0.1，结果明明数据库已经启动了，应用还是一直报连接失败。这个问题其实不是 Compose 配错了，而是没有建立起一个很关键的认知：同一个 Compose 网络里，服务名本身就是彼此访问时最方便的地址。

容器化本地开发有一个很常见的问题：服务虽然都起来了，但互相调用时用的地址特别随意。今天写死一个容器名，明天改成宿主机端口，后天又因为换了 compose 文件把连接地址全部推倒重来。结果是，本地联调环境虽然能跑，却总和线上长得不太一样。