docker run与docker service容器自动重启机制差异咨询

很多技术资料提到的「编排机制自动重启容器」和docker run的--restart参数能力完全不在同一个技术层级，二者的管控逻辑、故障覆盖范围、行为目标有本质区别，根本不是同一种能力。

docker run --restart的能力边界 #

这个重启逻辑是单台宿主机上的Docker daemon在本地实现的，完全绑定容器最初启动的那台机器，能力边界非常有限：

• 仅能处理本地节点上的有限故障：容器内主进程退出、容器被本地daemon异常终止、宿主机重启后Docker daemon随系统启动时拉起对应容器
• 没有任何全局感知能力：如果宿主机硬件故障宕机、本地Docker daemon本身崩溃无法启动、容器被手动执行docker rm -f删除、宿主机被关机，--restart参数不会触发任何恢复动作
• 没有副本数校验逻辑：它只会尝试拉起本机上原来的那个容器实例，不会关心服务整体可用的副本数量是否符合预期

docker service编排层重启/重建的核心逻辑 #

docker service是Docker Swarm编排体系下的资源对象，它的自动恢复能力是由Swarm管理节点维护的全局期望状态机驱动的，校验目标是「用户声明的服务期望状态」，而非单台机器上某个容器进程是否存活，覆盖的故障场景远多于本地restart策略：

• 跨节点故障恢复：如果运行服务副本的工作节点宕机、失联、Docker daemon故障，管理节点会自动感知到节点异常，把丢失的服务副本调度到其他符合条件的健康工作节点上重新拉起，不会绑定单台宿主机
• 副本数恒定保障：不管是容器意外退出、还是被手动误删，只要管理节点检测到实际运行的副本数少于声明值，就会自动重建新副本补足数量，不会因为实例被删除就终止服务
• 调度约束适配：就算是单节点上的容器异常退出，编排层重建副本时也会重新校验节点是否满足服务的调度规则（比如CPU/内存资源是否充足、节点是否带有服务要求的标签、端口是否冲突），不会死板地在原节点强制拉起容器

常见认知误区 #

很多教程没有明确区分两层逻辑：docker service创建的容器默认也会配置本地Docker daemon的restart策略作为节点级兜底，但这只是它恢复能力的很小一部分。真正和docker run形成核心差异的，是编排层跨节点全局调度、维持服务期望状态的能力，而非简单的「进程退出就本地重启」。

内容的提问来源于stack exchange，提问作者John Smith