Docker Compose 服务自动重启策略的配置与验证步骤

Docker Compose 的自动重启不是把所有服务都改成 always。更稳妥的做法是：长期运行的 Web 或 worker 通常选择 unless-stopped，只希望异常退出后重试的任务使用 on-failure:3，一次性任务保留 no。策略必须写在具体服务下面，再用配置展开和容器状态确认结果。

官方地址：https://docs.docker.com/reference/compose-file/services/

先按服务职责选择 restart 策略

Compose 服务的 restart 是服务级配置。官方规范列出了 no、always、on-failure[:max-retries] 和 unless-stopped。它们解决的是容器退出后的处理，不等于健康检查，也不会替应用修复连接串、挂载路径或启动命令。

把策略写在目标服务节点

例如 Web 服务需要在 Docker 引擎重启后恢复，而 worker 只允许失败重试三次，可以这样写：

services:
  web:
    image: example/web:1.4
    # 常驻服务允许在引擎恢复后自动拉起，人工 stop 的场景另行处理
    restart: unless-stopped
  worker:
    image: example/worker:1.4
    # 只对非零退出重试三次，避免配置错误造成无限重启
    restart: on-failure:3

不要把 restart 写到 services 旁边，也不要把 deploy.restart_policy 当成同一字段。本文只讨论本地 Compose 服务的 restart；Swarm 的部署策略属于另一套语义。

# 先展开 Compose 文件，确认目标服务读到了 restart 字段
docker compose config

# 只查看服务状态，不把 exited 误判成配置解析失败
docker compose ps -a

# 查看容器实际保存的重启策略；先从服务名得到容器 ID
docker inspect "$(docker compose ps -q web)" \
  --format '{{.HostConfig.RestartPolicy.Name}} {{.HostConfig.RestartPolicy.MaximumRetryCount}}'

从状态结果排查“重启后没有拉起”

如果 docker compose ps -a 显示 exited，先看退出码和日志；如果容器从未创建，再检查 Compose 项目是否真的执行过 up -d。配置写对不代表应用启动命令一定成功。

# 查看退出原因和最后一段日志，区分应用失败与策略未生效
docker compose ps -a
docker compose logs --tail=80 web

# 重新应用当前 compose.yaml；只启动指定服务及其依赖
docker compose up -d web

# 只做一次重启后的状态确认，避免用 restart 命令制造额外变量
docker compose ps

常见误区有三个：手动执行 docker compose stop web 后期待 unless-stopped 立即恢复；只改了文件却没有重新创建服务；把依赖未就绪当成重启策略问题。服务启动顺序要单独用 depends_on 和健康检查设计。

常见问题

always 和 unless-stopped 怎么选？

需要长期自动恢复且不把人工停机作为持久意图时选 always；希望运维明确停止后保持停止，通常选 unless-stopped。

on-failure:3 会在正常退出后重启吗？

不会。它只针对非零退出码，并且最多按设置次数重试；正常退出的任务应按业务决定是否需要外部调度。

为什么文件里有 restart，容器实际还是 no？

先用 docker compose config 看解析结果，再确认执行的是同一个项目目录和文件；已有容器还可能需要重新创建后才体现变更。