Dockerfile无法定义容器内业务的自动化重启逻辑，真正的自动恢复需结合HEALTHCHECK指令与--restart策略：前者通过健康端点检测服务可用性，后者在健康失败时触发重启，且业务需实现真实健康检查逻辑并验证生效。
Dockerfile 本身不能定义“容器内业务的自动化重启逻辑”，它只负责构建镜像、设定启动命令和基础环境。真正的业务级自动恢复，靠的是 健康检查（HEALTHCHECK） + 容器重启策略（--restart） 的组合，而不是在 Dockerfile 里写个 while 循环或后台守护进程——那既不标准，也容易失控。
HEALTHCHECK 是业务自愈的核心
业务是否“活着”，不能只看进程是否存在，而要看服务是否可响应。Docker 的 HEALTHCHECK 指令就是为此设计的，它让容器具备主动上报健康状态的能力。
- 在 Dockerfile 中添加类似以下配置：
HEALTHCHECK --interval=20s --timeout=5s --start-period=40s --retries=3 \
CMD curl -f http://localhost:3000/health || exit 1
- --start-period=40s：给应用留出足够启动时间，避免刚起来就被判“失败”
- --retries=3：连续 3 次失败才标记为 unhealthy，防止偶发网络抖动误判
- curl -f：只接受 HTTP 2xx/3xx 响应，4xx/5xx 或超时都会触发 exit 1 → 不健康
重启策略必须配合 HEALTHCHECK 才有意义
光有健康检查还不够——Docker 不会因为 HEALTHCHECK 失败就自动重启容器。你需要显式设置 restart 策略，且推荐使用 unless-stopped。
- 新建容器时指定：
docker run -d --restart unless-stopped -p 3000:3000 myapp - 已有容器更新：
docker update --restart unless-stopped myapp - 注意：on-failure 只响应进程退出码，对 HEALTHCHECK 失败无反应；always/unless-stopped 才能结合健康状态实现“业务不可用→重启”闭环
业务代码需暴露真实健康端点
HEALTHCHECK 的 CMD 本质是调用你自己的 /health 接口，这个接口必须做实质校验，不能只是 return { "status": "up" }。
- 例如 Node.js 应用中，/health 应检查数据库连接、缓存连通性、关键依赖服务可达性
- Python Flask 示例：
@app.route('/health')
def health():
try:
db.engine.execute('SELECT 1')
return jsonify({'status': 'healthy', 'db': 'ok'}), 200
except Exception as e:
return jsonify({'status': 'unhealthy', 'error': str(e)}), 503
验证与观察才是落地关键
配置完别忘了验证是否真正生效：
- 查看健康状态：
docker inspect myapp | jq '.[0].State.Health' - 模拟故障：手动 kill 应用进程（如
docker exec myapp pkill node），观察是否自动拉起 - 检查重启次数：
docker inspect myapp | jq '.[0].RestartCount'—— 健康检查失败不会增加该计数，但容器崩溃退出会
