容器生命周期不自动实现服务就绪依赖，需编排工具协调；depends_on仅控制启动顺序而非服务可用；推荐healthcheck+condition方案；应用层可用wait-for-it.sh等脚本兜底；k8s中宜用init container做前置校验。

容器生命周期本身不自动实现“服务就绪”级的依赖，它只管理单个容器的创建、运行、停止等状态。多容器之间的启动先后依赖，需要靠编排工具在生命周期之上叠加协调机制，而不是靠容器自身完成。

depends_on 只控制容器启动顺序，不保证服务可用

Docker Compose 的 depends_on 是最常用的基础手段，但它仅确保被依赖容器先 启动（running），并不等待其内部服务真正就绪。比如 PostgreSQL 容器可能已运行，但数据库初始化尚未完成，连接仍会失败。

• 写法示例：depends_on: [db] 或更明确的 depends_on: db: {condition: service_started}
• 本质是 Docker 引擎层面的启动排队，不涉及网络可达性或业务端口响应
• 适用于无状态、秒级就绪的服务（如 Nginx 静态服务），不适合数据库、消息队列等需初始化的组件

healthcheck + condition 实现真实就绪等待

这是目前 Docker Compose 中最推荐的方案：为被依赖服务定义健康检查，再让上游服务通过 condition: service_healthy 等待其通过检查。

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

• 数据库健康检查示例：test: ["CMD-SHELL", "pg_isready -U postgres"]
• Web 服务可暴露 /health 接口，用 curl -f http://localhost:8080/health 检查
• 必须配合 interval、timeout、retries 合理设置，避免过早判定失败或无限等待
• 注意：健康检查需在服务内部真正可用后才返回成功，不能仅靠端口通就认为就绪

启动脚本内嵌等待逻辑（应用层兜底）

当编排层无法满足精确控制时，可在应用容器启动命令中主动加入等待行为，属于“防御性编程”。

• 使用轻量脚本如 wait-for-it.sh：./wait-for-it.sh db:5432 --strict -- java -jar app.jar
• 自己写简单循环：until nc -z db 5432; do sleep 2; done
• 优势是兼容性强、逻辑可控；缺点是把基础设施逻辑混入应用启动流程，增加维护负担
• 适合遗留系统改造或 healthcheck 不易集成的场景

Kubernetes 中用 Init Container 做前置校验

在 K8s 环境下，Init Container 是更原生、更可靠的依赖前置方案。它会在主容器启动前按序执行，并且只有全部成功后，Pod 才进入 Ready 状态。

• Init Container 可以运行 nc、curl、pg_isready 等任意诊断命令
• 失败会重启整个 Pod（除非配置了 restartPolicy: Never），天然具备重试能力
• 与主容器镜像解耦，无需修改应用镜像即可添加依赖逻辑
• 注意：Init Container 不支持 readinessProbe，只用于启动前一次性检查