容器管理如何安全重启异常崩溃的容器服务

安全重启异常崩溃的容器服务需先定位原因再恢复：查退出码、日志、资源限制及依赖健康；按服务类型选策略（unless-stopped/on-failure/no）；配合HEALTHCHECK与外部卷挂载保障状态可恢复。

安全重启异常崩溃的容器服务，关键不是“强行拉起”，而是先确认崩溃原因、避免重复失败、再按需恢复。盲目用 --restart=always 可能掩盖问题，甚至导致日志刷屏、资源耗尽或数据错乱。

先查清为什么崩了

重启前必须定位根本原因，否则只是循环踩坑：

1. 看退出状态码：docker ps -a 查看 STATUS 列，如 Exited (137) 2 minutes ago 表示被 OOMKilled（内存超限）；Exited (1) 多为应用内部 panic 或启动失败
2. 查崩溃前日志：docker logs --previous <container-name>，重点看最后一段错误堆栈
3. 检查资源限制：docker inspect <container-name> | jq '.HostConfig.Memory, .HostConfig.CpuPeriod'，比对实际使用是否长期接近上限
4. 验证依赖健康：比如数据库连不上、配置中心超时，会导致应用启动阶段就退出

选对重启策略，不硬刚也不放任

根据服务类型和崩溃性质匹配策略，避免“一策通用”：

1. Web/API/数据库等常驻服务：用 unless-stopped —— 宿主机重启后自动恢复，但允许你手动 docker stop 做维护，生产环境最稳妥
2. 批处理、训练任务、脚本类服务：用 on-failure:3 —— 只在非零退出时重试，且限制次数，防无限重启掩盖逻辑错误
3. 调试中或数据敏感任务：显式设 no —— 崩了就停住，人工介入排查，避免误操作写坏数据
4. 慎用 always：它连 exit 0（正常退出）都重启，容易干扰运维节奏，仅适用于极简无状态守护进程

配合健康检查，让重启更智能

光靠退出码不够，加一层运行时判断，避免“活着但不可用”的假象：

1. 在 Dockerfile 中定义 HEALTHCHECK，例如检测 HTTP 接口或端口连通性
2. 搭配 on-failure 策略：容器被健康检查标记为 unhealthy 后，若最终退出，就会触发重启
3. 合理设置探针参数：initialDelaySeconds: 15（等应用真正就绪）、failureThreshold: 3（容忍短暂抖动）

重启前确保状态可恢复

尤其对有状态服务（如训练、数据库、消息队列），重启不是“重新开始”，而是“接着跑”：

1. 挂载外部卷（-v /host/data:/app/data）：保证模型检查点、数据库文件、日志不丢
2. 避免写死临时路径：容器内生成的中间文件若存在 /tmp 或镜像层，重启即丢失
3. PyTorch/TensorFlow 训练任务：确认代码支持从 checkpoint.pth 恢复，并在入口脚本中加入加载逻辑
4. 数据库类容器：用 postgres 最新镜像时，/var/lib/postgresql/data 必须挂载，否则每次重启都是空库