Go语言docker-compose编排_Golang多服务容器协调部署-Golang-PHP中文网

depends_on 不能解决 Go 服务启动失败，因其仅等待依赖容器处于 running 状态，不验证服务是否真正就绪（如 MySQL 完成初始化、端口监听、数据库可连接），导致 Go 应用因连接超时而 panic 退出；必须配合 condition: service_healthy 和被依赖服务的 healthcheck 才能确保依赖真实可用。

go语言docker-compose编排_golang多服务容器协调部署

Go 微服务用 Docker Compose 编排，关键不是“能不能跑”，而是“依赖是否真就绪”——depends_on 只等容器启动，不等服务监听端口或数据库可连接，这点踩坑最多。

为什么 `depends_on` 不能解决 Go 服务启动失败？

Go 服务（比如 user-api）常在启动时立即尝试连接 etcd、mysql 或 mongodb。但 depends_on 默认只判断目标容器是否 running，而 MySQL 容器可能已运行，却还在初始化数据库、加载 schema，此时 Go 应用 connect timeout 就会直接 panic 退出。

depends_on 不触发健康检查，除非显式配置 condition: service_healthy
Go 应用自身没做重试或等待逻辑时，失败即终止，Docker 不会自动重启它（除非设了 restart: on-failure）
官方镜像如 mongo:latest 或 mysql:8.0 启动后需数秒才真正 ready，这个时间不可控

Go 服务必须配 `healthcheck` 的三个场景

不是所有服务都需要写 healthcheck，但 Go 微服务只要依赖外部中间件，就必须在 docker-compose.yml 中为被依赖服务定义它——否则你的 depends_on 就是摆设。

mysql：用 mysqladmin ping -h localhost -u root -p$$MYSQL_ROOT_PASSWORD --silent，注意密码需用双 $ 转义
etcd：用 curl -f http://localhost:2379/health || exit 1
mongodb：用 mongosh --eval "db.runCommand('ping')" --quiet 2>/dev/null | grep -q 'ok.*1'（需镜像含 mongosh）

然后在 Go 服务的 depends_on 里写死条件：

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

depends_on:
  mysql:
    condition: service_healthy

Go 服务镜像构建推荐用 `scratch` + 多阶段，但要注意证书和 DNS

Go 编译出的二进制是静态链接的，FROM scratch 最小最安全。但上线后常遇到两个隐性问题：

HTTPS 请求失败：因为 scratch 没有 CA 证书，得手动 COPY /etc/ssl/certs/ca-certificates.crt 进去
域名解析失败：scratch 缺少 /etc/resolv.conf 和 /etc/hosts，Docker 默认会挂载，但若自定义了 volumes 覆盖了 /etc，DNS 就断了
日志输出被截断：scratch 没有 sh，所以别写 command: sh -c "./main"，直接 command: ["/main"]

服务间通信必须用服务名，别写 `localhost` 或 IP

Go 代码里连数据库或下游 RPC，地址必须写成 mongodb://mongodb:27017、http://pathfinder:8080，而不是 localhost 或 127.0.0.1。Docker Compose 默认为每个 service 创建 DNS 记录，同网络下服务名就是 host。

所有服务默认在同一个自定义桥接网络（default 网络），无需额外声明 networks
如果用了 extra_hosts 或自定义 networks，要确认 Go 服务和依赖服务在同一个 networks 下
环境变量如 MONGODB_URL 应该在 docker-compose.yml 的 environment 里注入，而不是硬编码在 Go 代码中

复杂点在于健康检查与 Go 应用自身的启动探针容易重复——比如你既在 Compose 里写了 MySQL 的 healthcheck，又在 Go 服务里实现了 /healthz 检查数据库连通性。这两层得对齐超时和重试逻辑，否则本地 docker compose up 成功，K8s 里却反复 CrashLoopBackOff。