容器能够自动重启，并不代表服务真正具备高可用性。如果应用因配置错误、依赖不可达或权限异常而持续退出，重启策略反而可能掩盖故障，形成“启动、崩溃、再启动”的无限循环。本文从策略选择、配置方法到排查步骤，系统说明如何正确处理 Docker 容器重启问题。🔧
一、理解 Docker 的四种重启策略
Docker 通过重启策略决定容器主进程退出后是否再次启动。常用策略包括以下四种，具体行为可参考 Docker 官方文档。citeturn1search1
- no：默认值。容器退出后不自动重启，适合临时任务、调试环境和一次性脚本。
- on-failure：仅当主进程以非零状态码退出时重启。可以设置最大重试次数，例如 on-failure:5，适合允许失败重试但不希望无限循环的任务。
- always：无论容器正常退出还是异常退出，都尝试重新启动。手动停止后，容器通常会保持停止，但 Docker 守护进程重新启动后可能再次拉起。
- unless-stopped：行为与 always 类似，但会记住人工停止状态。即使 Docker 服务或宿主机重启，被主动停止的容器也不会自动恢复。
对于需要长期运行的普通服务，unless-stopped通常更方便维护；对于批处理、迁移或数据同步任务，建议优先考虑on-failure并限制重试次数。不要为了“看起来稳定”而统一设置 always。⚠️
二、配置和修改重启策略
1. 创建容器时配置
使用 docker run 启动容器时，可以通过 --restart 参数指定策略。例如：
docker run -d --name web --restart unless-stopped nginx
如果希望容器异常退出后最多重试五次，可以使用：
docker run -d --name worker --restart on-failure:5 my-worker
2. 修改现有容器
已经创建的容器不需要删除重建，可以直接执行：
docker update --restart unless-stopped web
若要临时关闭自动重启，便于排查故障，可执行：
docker update --restart no web
3. 在 Compose 中配置
使用 Docker Compose 时，可在服务配置中加入 restart: unless-stopped。修改配置后应重新创建对应服务，确保新策略生效。需要注意，普通 Compose 项目中的 restart 与 Swarm 服务的重启配置不是同一套语义，不应混用。
三、识别无限重启循环
容器出现反复重启时，docker ps 通常会显示 Restarting，并可能附带最近一次退出状态。首先执行以下命令观察整体状态：
docker ps -a
docker inspect 容器名
重点检查 State、ExitCode、Error、OOMKilled 和 RestartCount。退出码只能提供方向，不能代替日志分析。例如，非零退出码表示程序异常结束，但具体原因仍可能是配置、权限、依赖或程序自身错误。
建议先保留现场，再调整策略。直接删除容器可能导致日志、临时文件和故障上下文一并丢失。
四、按顺序排查重启原因
- 查看最近日志：执行 docker logs --tail 200 容器名；如需持续观察，可使用 docker logs -f 容器名。重点关注启动参数、配置解析、端口绑定、数据库连接和文件权限错误。
- 确认启动命令：使用 docker inspect 检查镜像的 Entrypoint、Cmd 以及运行时覆盖参数。常见问题包括命令拼写错误、脚本缺少执行权限、前台进程立即结束。
- 检查挂载内容：确认配置文件路径、宿主机目录和数据卷是否存在，文件格式是否正确，容器内用户是否拥有读取或写入权限。
- 检查环境变量：核对必填变量是否缺失，变量名是否错误，密码或连接地址中是否包含未正确处理的特殊字符。
- 检查外部依赖：数据库、缓存、消息队列尚未就绪时，应用可能启动即退出。应在应用层加入合理的等待、退避和超时机制，而不是依赖无限重启。
- 检查资源限制：如果 inspect 结果显示 OOMKilled，应检查内存限制、程序峰值占用和宿主机资源，而不是简单提高重启频率。
- 检查网络与端口：确认容器网络、DNS、服务名和端口映射正确，同时排除宿主机端口被占用的问题。🌐
五、快速停止循环并进入调试
容器重启过快时，可先执行 docker update --restart no 容器名，再执行 docker stop 容器名。随后使用相同镜像覆盖原启动命令，以交互方式进入容器检查文件、变量和网络环境。
如果问题来自镜像默认命令，可以启动一个临时调试容器；如果问题只在原容器中出现，则应对比其挂载目录、环境变量、网络和用户身份。修复完成后，再恢复合适的重启策略并观察一段时间。
六、避免重启策略掩盖真实故障
- 为关键服务配置日志收集和告警，不要只观察容器是否处于运行状态。
- 为批处理任务设置最大重试次数，防止持续消耗 CPU、内存和外部接口配额。
- 区分“进程存活”和“服务可用”。健康检查失败不会天然等同于主进程退出，重启策略也不能替代完整的可用性监控。
- 发布前验证配置文件、依赖连通性、目录权限和资源限制。
- 避免在容器内部再使用进程管理器反复拉起同一应用，以免与 Docker 重启机制叠加。
总结
Docker 重启策略的核心作用是恢复意外退出的容器，而不是修复应用故障。实际配置时，应根据服务类型选择 no、on-failure、always 或 unless-stopped；遇到无限重启循环，则应先关闭自动重启、保留现场，再依次检查日志、退出状态、启动命令、挂载、环境变量、依赖、网络和资源限制。只有找到主进程退出的根因，容器的自动恢复能力才真正可靠。✅
