Docker容器自动恢复需重启策略、健康检查与外部监控协同：restart策略应对进程退出，HEALTHCHECK探测服务假死，配合Prometheus告警实现闭环。
Docker 容器故障自动恢复不是靠“一键开启”，而是通过重启策略、健康检查和外部协同三者配合实现的。核心目标是：容器挂了能拉起来，服务假死了能发现，反复失败能预警。
重启策略是基础防线
这是 Docker 原生支持的最直接手段，通过 --restart 参数或 Compose 中的 restart 字段配置：
-
unless-stopped：推荐用于大多数生产服务。容器随 Docker 守护进程启动，手动执行docker stop后才停止，其他所有异常退出（崩溃、OOM、信号终止）都会自动重启。 -
on-failure:3：适合批处理或有明确成功/失败语义的任务。只在非零退出码时重启，最多试 3 次，避免死循环。 -
always：适用于必须长期存活的核心组件（如反向代理、日志采集器），但要注意可能掩盖程序缺陷——比如代码一启动就 panic，它会无限重启。 -
no：调试或一次性任务用，不参与自愈。
健康检查让恢复更精准
重启策略只看进程是否退出，但很多故障是“进程活着，服务瘫了”（比如卡死、线程阻塞、端口监听失效）。这时需要 HEALTHCHECK 主动探测：
- 在 Dockerfile 中定义：
HEALTHCHECK --interval=30s --timeout=5s --start-period=40s --retries=3 \ CMD curl -f http://localhost:8080/health || exit 1
- 关键参数含义：
-
--start-period=40s：容器启动后前 40 秒不计入失败，给应用冷启动留时间； -
--retries=3：连续 3 次失败才标记为unhealthy； -
curl -f：只接受 HTTP 2xx/3xx 响应，4xx/5xx 或超时都算失败。
-
启用后，docker inspect <container> 能看到 "Status": "healthy" 或 "unhealthy"，这是编排工具（如 Swarm、K8s）触发重建的依据。
组合使用才能闭环
单用重启策略 → 只能应对进程退出；单用健康检查 → 不自动动作。两者结合才有意义：
-
在 Docker Compose 中同时配置：
Docker Image Puller下载使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
services: api: image: my-api:v1 restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://localhost:3000/health"] interval: 30s timeout: 5s retries: 3 start_period: 60s 效果是：健康检查失败 → 容器状态变
unhealthy→ Docker 判定“服务不可用”，配合restart: unless-stopped就会触发重启（注意：Docker Engine 本身不会因unhealthy自动重启，但 Swarm 或 K8s 会基于该状态做调度决策；纯 Docker 环境下，需搭配脚本监听docker events或定期docker inspect来补足）。
别忘了监控与告警
自动恢复不是“修好就完事”。频繁重启或长期 unhealthy 是系统隐患信号：
- 用
cAdvisor + Prometheus采集容器退出次数、CPU/内存突增、健康检查失败率； - 设置 Alertmanager 规则：
rate(container_restarts_total[1h]) > 3或container_health_status == 0； - 告警内容应包含容器名、最近一次退出码、日志尾行（
docker logs --tail 20 <name>），方便快速定位根因。
不复杂但容易忽略。
