怎么利用 Dockerfile 定义镜像启动前的检查脚本实现自愈实战

可在Dockerfile中通过ENTRYPOINT封装自愈型entrypoint.sh脚本，实现启动前依赖检查、重试、降级与告警，并配合HEALTHCHECK提供运行时健康探测。

可以在 Dockerfile 中通过 ENTRYPOINT 或 CMD 包裹启动逻辑，将健康检查与服务启动合并为一个可重试、带自愈能力的入口脚本。核心不是“启动前检查”，而是让容器启动流程本身具备失败重试、依赖等待、状态校验和自动恢复能力。

把检查逻辑写进启动脚本

不要依赖外部探针倒推修复，而是在容器真正启动服务前主动验证必要条件。例如：数据库连通性、配置文件完整性、端口可用性、依赖服务就绪等。

• 编写一个 shell 脚本（如 entrypoint.sh），开头做环境校验、依赖探测、配置预检
• 用 curl -f http://localhost:8080/health 或 nc -z db 5432 等命令确认依赖就绪
• 失败时 sleep + retry，避免因依赖启动慢导致容器直接退出
• 校验失败可触发降级（如生成默认配置）、告警（写日志或调用 webhook）甚至自我终止

用 ENTRYPOINT 封装可执行链

Dockerfile 中用 ENTRYPOINT 指向你的自愈脚本，再由它调用真实 CMD。这样所有启动都经过统一入口，便于注入通用逻辑。

• COPY entrypoint.sh /usr/local/bin/entrypoint.sh
• RUN chmod +x /usr/local/bin/entrypoint.sh
• ENTRYPOINT ["entrypoint.sh"]
• CMD ["node", "app.js"] —— 这个会被传给 entrypoint.sh 作为参数

entrypoint.sh 内部用 exec "$@" 启动原命令，既保留 CMD 可覆盖性，又确保每次启动都走检查流程。

结合 HEALTHCHECK 做运行时延续

启动检查只是第一道防线。容器运行后还需持续探测，配合编排平台（如 Docker Swarm 或 Kubernetes）实现故障隔离与重建。

• 在 Dockerfile 中添加 HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 CMD curl -f http://localhost:3000/health || exit 1
• 健康检查失败不会自动重启容器，但能触发上层调度器（如 k8s 的 liveness probe）重建 Pod
• 建议 /health 接口返回应用真实状态（DB 连接、缓存连通、关键队列积压等），而非仅进程存活

实战中注意的关键细节

自愈不是万能的，设计不当反而掩盖问题或引发雪崩。

• 重试要有上限（如最多 5 次），避免无限等待阻塞部署
• 检查超时要合理（依赖服务冷启动可能需 10–20 秒），避免误判
• 日志必须清晰输出每一步结果（“Waiting for Redis… attempt 3/5”），方便排查
• 敏感操作（如自动修复配置）应默认关闭，通过环境变量控制（AUTO_FIX_CONFIG=true）
• 不要在检查中修改宿主机或共享卷——容器应是无状态且可随时重建的

不复杂但容易忽略：真正的自愈能力来自启动流程的韧性设计，而不是某个 magic 指令。把检查变成启动的一部分，把失败变成可观察、可干预、可收敛的动作，才是落地关键。