Docker容器重启策略详解：保障应用持续运行的利器

大家好！在现代应用部署中，容器化技术（尤其是 Docker）已成为主流。然而，即使是最健壮的应用，也可能因为各种原因（如资源耗尽、内部错误、依赖服务故障等）意外退出。如果容器退出后不能自动恢复，就会导致服务中断，影响用户体验甚至业务运行。幸运的是，Docker 提供了强大的重启策略（Restart Policies）机制，能够让容器在退出时自动尝试重启，大大提高了应用的可用性和韧性。

今天，我们就来深入探讨 Docker 的几种重启策略，并通过实战案例了解它们的工作方式和适用场景，助你为生产环境的应用选择最合适的“保命符”。

1. 重启策略概述：四种模式，按需选择

Docker 提供了四种主要的重启策略，通过 docker run 命令的 --restart 标志来指定：

no
- 行为：这是默认策略。无论容器以何种状态退出（正常或异常），Docker 都不会自动重启该容器。
- 适用场景：一次性任务、测试运行、手动调试、或者你有更高级的外部编排工具（如 Kubernetes、Docker Swarm）来管理容器生命周期时。
- 命令示例：docker run -d --name my-app --restart no my-image
always
- 行为：无论容器退出状态码是什么（是正常退出还是异常崩溃），Docker 都会始终尝试重启它。需要注意的是，如果容器被手动停止（例如使用 docker stop），则在 Docker 守护进程重启后，该容器也会被自动启动。
- 适用场景：需要保证始终运行的关键服务，即使是计划内的正常退出（虽然这种情况较少见）也希望它能立即重启。但要小心，如果应用启动即失败，这可能导致无限重启循环，消耗系统资源。
- 命令示例：docker run -d --name critical-service --restart always my-image
on-failure[:max-retries]
- 行为：只有当容器以非零退出状态码（通常表示错误或异常）退出时，Docker 才会尝试重启它。如果容器是正常退出（退出状态码为 0），则不会重启。
- 你可以选择性地附加一个最大重启次数（:max-retries）。例如，on-failure:3 表示 Docker 最多会尝试重启 3 次。如果达到次数限制后容器仍然失败退出，Docker 将放弃重启。
- 若不指定次数（即 on-failure），Docker 会无限次尝试重启（只要是异常退出）。
- 适用场景：这是最常用的策略之一。适用于那些期望持续运行，但可能会遇到临时性错误的服务。它允许容器在完成预期工作后正常停止（例如批处理任务），并且在出现问题时自动恢复。限制重启次数可以防止故障应用耗尽资源。
- 命令示例（最多重启3次）：docker run -d --name web-app --restart on-failure:3 my-image
- 命令示例（无限次重启）：docker run -d --name worker --restart on-failure my-image
unless-stopped
- 行为：与 always 类似，无论容器以何种状态退出（正常或异常），Docker 都会尝试重启它。关键区别在于：如果容器被明确地手动停止（使用 docker stop 或类似命令），即使之后 Docker 守护进程重启，该容器也不会被自动启动。只有当容器是因为其他原因（如内部错误崩溃）退出时，它才会被自动重启（包括 Docker 守护进程重启后）。
- 适用场景：这是生产环境中最推荐、最常用的策略。它兼顾了高可用（异常时自动重启）和可管理性（尊重管理员的手动停止操作）。适用于绝大多数需要长时间运行的后台服务（Web 服务器、数据库、消息队列等）。
- 命令示例：docker run -d --name backend-api --restart unless-stopped my-image

小结：

策略	退出原因	手动停止后，Docker重启是否启动	推荐场景
`no`	任何	否	一次性任务、测试、外部编排管理
`always`	任何	是	极少数需要无条件运行的服务，需谨慎使用
`on-failure[:max]`	异常退出 (非0)	否	常用，容忍临时错误，可完成任务，可限制次数
`unless-stopped`	任何	否	生产环境首选，兼顾高可用与手动控制

2. 实战案例：眼见为实

让我们通过你提供的镜像 registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v1（我们假设这个镜像默认运行一个像 Nginx 一样的、会持续运行的 Web 服务）来实际操作一下。

场景一：模拟长时运行服务

我们将创建四个容器，分别应用不同的重启策略（为了清晰，我们稍微修改了容器名称，并明确了 on-failure 的两种形式）：

# 策略: no (不重启)
docker run -d --name service-no --restart no registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v1

# 策略: always (始终重启)
docker run -d --name service-always --restart always registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v1

# 策略: on-failure:3 (异常退出时最多重启3次)
docker run -d --name service-on-failure-3 --restart on-failure:3 registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v1

# 策略: unless-stopped (推荐，异常时重启，尊重手动停止)
docker run -d --name service-unless-stopped --restart unless-stopped registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v1

现在，所有容器应该都处于 Up 状态。

场景二：模拟异常退出（强制杀死进程）

这是一种模拟容器内主进程意外崩溃的有效方法。我们获取正在运行的容器的进程 ID (PID)，然后使用 kill -9 发送 SIGKILL 信号强制终止它们。

# 查看所有容器状态
docker ps -a

# 获取所有运行中容器的主进程 PID
PIDS=$(docker ps -q | xargs docker inspect -f '{{.State.Pid}}' | grep -v '^0$') # 使用 xargs 和 inspect 获取 PID，并过滤掉已停止容器的 PID 0
echo "Killing PIDs: $PIDS"

# 强制杀死这些进程 (需要 root 权限或相应能力)
# 注意：直接在宿主机 kill 容器内 PID 是模拟极端崩溃场景，更推荐使用 docker kill
# 为了复现你的测试，我们继续用 kill -9
echo "$PIDS" | xargs sudo kill -9 # 或者 docker kill $(docker ps -q)

# 等待几秒钟让 Docker 响应
sleep 5

# 再次查看容器状态
echo "--- Status after first kill ---"
docker ps -a

结果分析 (第一次 Kill 后)：

service-no: 状态变为 Exited (137)。因为策略是 no，它不会被重启。（Exit code 137 通常表示进程被 SIGKILL 信号终止）
service-always: 状态应该会短暂变为 Exited，然后迅速回到 Up。因为它总是会被重启。
service-on-failure-3: 状态短暂 Exited 后回到 Up。因为它是异常退出（非 0 状态码），且重启次数未达上限。
service-unless-stopped: 状态短暂 Exited 后回到 Up。因为它是异常退出，会被重启。

场景三：测试 on-failure 的次数限制

让我们连续杀死 service-on-failure-3 容器的进程，观察达到 3 次限制后的行为。

# 连续杀死 service-on-failure-3 三次以上
for i in {1..4}; do
  echo "--- Killing service-on-failure-3 attempt #$i ---"
  PID_ON_FAILURE_3=$(docker inspect -f '{{.State.Pid}}' service-on-failure-3)
  if [ "$PID_ON_FAILURE_3" != "0" ]; then
    sudo kill -9 "$PID_ON_FAILURE_3"
    sleep 3 # 给 Docker 一点时间响应和重启
    docker ps -a --filter name=service-on-failure-3
  else
    echo "Container already stopped."
    break
  fi
done

# 最终状态
echo "--- Final status after multiple kills ---"
docker ps -a

结果分析 (on-failure:3 测试)：

你会观察到 service-on-failure-3 在前三次被 kill 后都能成功重启（状态短暂 Exited 后变回 Up）。但在第四次（或之后）被 kill 后，它的状态将停留在 Exited (137)，因为已经达到了 on-failure:3 设置的 3 次重启上限。同时，service-always 和 service-unless-stopped 仍然会被持续重启。

场景四：测试 unless-stopped 对手动停止的响应

# 查看状态，确认 service-unless-stopped 是运行状态 (Up)
docker ps -a --filter name=service-unless-stopped

# 手动停止容器
echo "--- Stopping service-unless-stopped manually ---"
docker stop service-unless-stopped

# 查看状态，应为 Exited (0) 或 Exited (137) (取决于停止方式)
docker ps -a --filter name=service-unless-stopped

# (模拟) 重启 Docker 守护进程
# 在实际操作中，你会执行类似 systemctl restart docker 的命令
echo "--- Simulating Docker daemon restart ---"
# (此处无需实际重启，只需理解行为即可)

# 再次查看状态，手动停止后，即使 Docker 重启，它也应该保持 Exited 状态
docker ps -a --filter name=service-unless-stopped
echo "Container should remain stopped because it was manually stopped."

# 如果我们手动启动它
docker start service-unless-stopped

# 现在，如果再次 (模拟) 重启 Docker 守护进程
echo "--- Simulating Docker daemon restart after manual start ---"
# (模拟)

# 查看状态，此时它应该会随 Docker 启动而自动启动，回到 Up 状态
sleep 2 # 等待启动
docker ps -a --filter name=service-unless-stopped
echo "Container should now auto-start after Docker restart because it was running before the simulated restart."

结果分析 (unless-stopped 测试)：

这个测试清晰地展示了 unless-stopped 的核心特性：它在容器异常退出时提供自动重启的保障，但完全尊重管理员的手动停止操作。这使得它成为管理生产服务的理想选择，你可以在需要维护或调试时安全地停止服务，而不必担心 Docker 重启后它又意外启动。

3. 如何选择合适的重启策略？（生产建议）

首选 unless-stopped：对于绝大多数需要长期运行的无状态或有状态服务（Web 应用、API、数据库代理、监控组件等），unless-stopped 是最稳妥、最灵活的选择。它保证了服务在意外崩溃后的自愈能力，同时允许运维人员在需要时进行可控的启停。
考虑 on-failure[:max]：
- 当你的服务执行的是有明确完成状态的任务（例如，一个处理队列消息的 Worker，处理完一批就正常退出），并且你希望它在失败时重试有限次数，on-failure:N 是个好选择。
- 如果服务可能会陷入快速失败重启循环（例如，配置错误导致启动即崩溃），设置一个合理的 max-retries (如 3 或 5) 可以防止 Docker 不断尝试重启，耗尽系统资源，并让你更容易诊断问题。
- 对于需要无限重试（只要异常退出）但不需要在正常退出后重启的服务，可以使用无次数限制的 on-failure。
谨慎使用 always：always 的行为比较“霸道”，它甚至会在容器正常退出后也重启。这在大多数场景下并非期望行为，且可能掩盖应用正常完成任务的事实或启动失败的问题。仅在有非常特殊的需求，确信服务任何时候停止都需要立即重启时才考虑。
no 用于特定场景：当你进行开发测试、运行一次性脚本、或者使用 Kubernetes 这类更高级的编排系统（它们有自己的 Pod 重启策略）时，no 是合适的，避免 Docker 的重启策略与外部管理冲突。

4. 如何应用和更新重启策略？

创建时指定：如上例所示，在 docker run 时使用 --restart <policy> 参数。
更新现有容器：对于已经创建的容器，可以使用 docker update 命令来修改其重启策略：
```
docker update --restart unless-stopped my_container_name_or_id
```
这对于调整线上服务的策略非常方便，无需删除和重建容器。

结语

Docker 的重启策略是保障容器化应用高可用的基础工具。理解 no, always, on-failure, 和 unless-stopped 这四种策略的细微差别和适用场景，能让你在部署应用时做出明智的选择。在大多数生产环境中，unless-stopped 是你的首选，而 on-failure 提供了更细粒度的控制。记住，选择正确的重启策略，结合良好的监控和日志，将大大提升你服务的稳定性和运维效率。

希望这篇博文对你和你的粉丝有所帮助！如果你有任何疑问或其他的 Docker 使用心得，欢迎在评论区交流！

posted on 2025-04-03 18:44 Leo-Yide 阅读(507) 评论(0) 收藏举报