如何使用 Dockerfile 定义容器内业务的自动化重启逻辑实战

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' —— 健康检查失败不会增加该计数，但容器崩溃退出会