在Docker生产环境部署中，Docker run --restart=always自启动是一个将容器从“手动玩具”升级为“可靠服务”的关键策略参数。它指示Docker守护进程，无论容器因何原因退出（进程崩溃、手动误删除外），都要尽力将其重新启动。对于保障关键业务（如Web API、消息队列、数据库）的持续可用性，这行简单的配置提供了第一道也是最重要的自愈防线。然而，盲目使用`always`策略可能掩盖应用本身的设计缺陷，甚至引发重启风暴。理解其工作原理、不同策略的细微差别以及与健康检查的协同，是构建稳健容器化架构的必修课。作为鳄鱼Java的资深编辑，我将为你揭开这一策略的层层面纱。
一、重启策略的价值：从手动运维到自愈服务的跨越
在没有设置重启策略的默认场景下，一个以`docker run -d`启动的后台容器，如果其内部主进程崩溃（返回非0退出码）或宿主机发生资源竞争导致OOM Kill，容器将直接进入`Exited`状态并停留在那里，等待人工干预。在鳄鱼Java早期的运维监控中，我们常发现凌晨因偶发异常退出的服务容器，直到早上用户投诉才被察觉，造成了不必要的服务中断。
Docker run --restart=always自启动策略的核心价值在于，它将容器的生命周期管理责任，从管理员手中部分移交给了Docker引擎本身。Docker守护进程会持续监控容器的状态，一旦发现其非正常终止，便会根据预设策略尝试重启，这为服务恢复争取了宝贵时间，是实现高可用性的基石。它尤其适用于处理那些因底层依赖暂时不可用、瞬时内存溢出等可自恢复的故障场景。
二、四大策略详解：always, unless-stopped, on-failure, no
Docker提供了四种重启策略，精准匹配不同场景下的可靠性需求：
1. no （默认策略）
含义： 无论容器因何原因退出，都不自动重启。
适用场景： 一次性任务容器（如数据备份、批处理脚本）、需要完全手动控制的调试环境。
2. on-failure[:max-retries]
含义： 仅当容器以非0状态退出（即失败）时才自动重启。可以可选地指定最大重试次数（如 `on-failure:5`）。
适用场景： 这是非常实用的策略。适用于那些预期应该长期运行，但可能因外部依赖（如数据库连接）暂时中断而退出的服务。限制重试次数可以防止无限重启循环占用资源。
3. always
含义： 只要容器退出（无论退出码是什么），Docker守护进程都会无条件重启它。 这包括：
- 容器进程正常结束（退出码0）
- 进程崩溃（退出码非0）
- 宿主机重启后，Docker服务启动时
关键注意： 如果容器是被显式命令 `docker stop` 或 `docker rm -f` 停止的，则不会重启。这是策略生效的边界。
4. unless-stopped
含义： 与 `always` 行为几乎一致，但有一个关键区别：如果容器是被 `docker stop` 命令正常停止的，那么即使在宿主机重启、Docker服务重新运行后，该容器也不会被自动启动。它的状态将保持为`Stopped`。
适用场景： 这是生产环境最常用、最推荐的重启策略。它既能保证服务因意外退出或宿主机重启时自动恢复，又赋予了管理员通过`docker stop`永久停止服务的控制权，避免了在维护窗口期服务的“顽固”自启。
在鳄鱼Java的生产部署规范中，我们明确规定：所有核心业务服务容器必须使用 `--restart=unless-stopped` 策略。
三、always策略的实战场景与潜在陷阱
让我们通过具体场景，看看 `always` 策略如何工作，以及可能遇到的问题。
场景一：宿主机重启后的服务恢复
这是`always`和`unless-stopped`策略最直接的价值体现。假设服务器因内核安全更新需要重启。管理员执行`reboot`。当宿主机启动完毕，Docker服务（通常被配置为系统服务自动启动）运行后，它会自动检查所有标记了`always`或`unless-stopped`策略的容器，并将它们启动。这实现了服务与基础设施的同步恢复。
场景二：应用进程崩溃的快速自愈
一个Java应用因内存泄漏，最终触发OOM Killer被终止。容器退出。Docker守护进程检测到退出事件，并发现其重启策略为`always`，立即尝试重新创建和启动容器。如果问题是一次性的（如某次请求触发了未知bug），这次重启可能就让服务恢复了正常，避免了长时间的中断。
潜在陷阱：重启风暴与资源耗尽
这是滥用`always`策略最危险的情况。假设容器启动命令本身就有问题（例如错误的配置文件路径导致JVM无法启动），容器会在启动后立即退出（Exit 0或非0）。Docker会按照`always`策略立刻重启它，它又立刻退出，如此循环，形成“重启风暴”。在鳄鱼Java处理的一次线上事故中，一个有缺陷的镜像在短时间内创建了上千个“已退出”的容器副本，几乎拖垮了宿主机。此时，你需要使用`docker logs <容器名>`查看最近一次启动失败的日志来诊断，并用`docker stop`强制中断这个循环。
四、如何正确设置与管理重启策略
设置重启策略可以在容器运行时指定，也可以在创建后更新。
1. 运行容器时指定
这是最常用的方式，与`-d`、`--name`等参数一同使用。
docker run -d --name my-app --restart=unless-stopped -p 8080:8080 my-java-app:latest
2. 更新已运行容器的策略
如果容器已创建但未设置策略，可以使用`docker update`命令。
docker update --restart=unless-stopped my-app
注意： `docker update`对已停止的容器也生效，但不会立即启动它。需要配合`docker start`。
3. 查看容器的重启策略与状态
使用`docker inspect`命令可以查看详细信息：
docker inspect my-app --format=‘{{.HostConfig.RestartPolicy.Name}}’
更直观的方法是查看`docker ps`时关注状态栏：
- `Up 5 minutes` 表示运行正常。
- `Restarting (1) 10 seconds ago` 表示容器正在重启中（括号内是重启次数），这是一个危险信号，需要立刻查看日志。
五、与健康检查（HEALTHCHECK）协同工作
重启策略解决了“容器进程是否在运行”的问题，但无法判断“容器内的服务是否健康可用”。例如，一个Java应用进程虽在，但陷入了死锁，无法响应请求。此时，单纯的`--restart=always`无能为力，因为容器并未退出。
解决方案：定义HEALTHCHECK
在Dockerfile或`docker run`命令中定义健康检查指令，让Docker定期探测应用的健康端点（如Spring Boot Actuator的`/actuator/health`）。
# Dockerfile 示例 FROM openjdk:11 ... HEALTHCHECK --interval=30s --timeout=3s --start-period=60s --retries=3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1
当健康检查连续失败超过重试次数后，容器状态会变为`unhealthy`。虽然Docker默认不会因不健康而重启容器，但你可以：
1. 结合监控系统（如Prometheus）监控容器健康状态并告警。
2. 使用第三方工具（如`docker-autoheal`）或编排平台（Kubernetes），在容器不健康时触发重启或重建。
在鳄鱼Java的微服务架构中，我们强制要求所有业务镜像必须包含有效的`HEALTHCHECK`指令，并与`--restart=unless-stopped`策略结合，构建从进程到应用层的双重保障。
六、从单机到集群：在编排系统中的演进
在单机Docker环境中，Docker run --restart=always自启动是可靠性的核心。但在Swarm或Kubernetes等集群编排系统中，其角色被更强大的抽象所替代或增强。
1. Docker Swarm 服务
在Swarm中，你不再直接运行容器，而是定义“服务”（Service）。服务的重启策略通过`--restart-condition`和`--restart-delay`等参数控制，其逻辑与单机Docker类似但更集成化，并能在集群节点故障时在其它节点上重建容器。
2. Kubernetes Pod 与控制器
这是最根本的范式转变。在K8s中：
- **Pod重启策略（`restartPolicy`）**： 可以是`Always`、`OnFailure`、`Never`。它作用于Pod内的容器，与Docker的`--restart`概念相似。
- **更强大的控制器**： 真正的生产级自愈能力来自于Deployment、StatefulSet等控制器。 它们确保的是“期望的Pod副本数”。如果一个Pod崩溃，控制器会杀死它并根据重启策略可能重启；但如果Pod一直无法达到`Ready`状态，控制器会直接创建一个全新的Pod来替换它，这比单纯重启容器更彻底。K8s的探针（Liveness Probe、Readiness Probe）也远比Docker的健康检查功能丰富和强大。
演进建议：
- **学习/单服务测试**：使用 `docker run --restart=unless-stopped`。
- **生产单机/简单多服务**：使用Docker Compose，在其中定义服务的`restart`策略。
- **生产集群环境**：必须使用Kubernetes，并利用其控制器的副本管理和探针机制来实现高可用。
总结与思考
深入掌握Docker run --restart=always自启动及其相关策略，意味着你深刻理解了容器生命周期自动化管理的第一个关键维度。它不仅仅是让容器“自己爬起来”，更是构建服务韧性（Resilience）的基础思维。从选择`unless-stopped`作为生产标准以平衡自愈与控制权，到警惕“重启风暴”并学会用日志诊断根本原因，再到将进程级重启与应用级健康检查相结合，每一步都体现了运维的成熟度。
现在，请检查你的容器们：它们是否运行在默认的`no`策略下，暴露在单点故障风险中？你的关键服务是否已经正确配置了`unless-stopped`？你是否曾遭遇过重启风暴，当时是如何应对的？真正的可靠性，始于对这些基础配置的深思熟虑和正确应用。从今天起，为你负责的每一个服务容器都赋予合适的重启策略，并开始规划向更完善的健康检查和编排平台演进。如果你在向Kubernetes迁移的过程中对如何设计Pod生命周期有疑问，欢迎来到鳄鱼Java社区，我们一同探讨云原生的稳健之道。
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
