Docker Compose 健康检查与依赖启动顺序
· 阅读需 2 分钟
做本地开发编排时,一个很常见的错觉是: 只要容器进程起来了,服务就算可用了。实际情况往往不是这样,尤其是数据库、消息队列和依赖初始化步骤比较多的时候。
做本地开发编排时,一个很常见的错觉是: 只要容器进程起来了,服务就算可用了。实际情况往往不是这样,尤其是数据库、消息队列和依赖初始化步骤比较多的时候。
Docker Compose 真正进入团队日常以后,最容易变乱的不是容器本身,而是环境变量。数据库地址、Redis 密码、第三方 key、功能开关,只要项目一多,.env 很快就会变成谁都不敢动的文件。
刚开始用 Docker Compose 做本地联调时,最容易犯的错误就是还在用宿主机思维理解容器之间的访问关系。比如 API 容器去连数据库时,配置里还写 127.0.0.1,结果明明数据库已经启动了,应用还是一直报连接失败。这个问题其实不是 Compose 配错了,而是没有建立起一个很关键的认知:同一个 Compose 网络里,服务名本身就是彼此访问时最方便的地址。