Docker restart策略

Docker

类型：虚拟化技术

简介：基于操作系统层级的虚拟化技术，将软件与其依赖项打包为容器。

百科词条 访问网站

一个 example-job 容器少写了一项环境变量，应用启动后几秒就会退出。如果给它配 restart: always，Docker会一遍一遍拉起，日志里全是同一段报错，真正的第一行错误反而很难找。restart策略不是保险，用错了只是把失败放大。

配置前先看退出原因：

docker ps -a
docker logs 容器名

退出码0是正常结束，非0才算异常。配置错误、端口冲突、依赖服务没起来，都先处理，不要急着改策略。

always适合长期在线服务

Nginx、API服务、常驻后台进程可以用：

docker run -d --name demo --restart always nginx

Compose里写成：

services:
  web:
    image: nginx
    restart: always

这条策略的特点是机器重启、Docker服务重启后都会尝试恢复。维护窗口期要特别小心，管理员停掉以后，有些场景下它还会回来。

unless-stopped更贴近常规项目

多数网站和内部系统可以优先考虑这个：

docker run -d --name demo --restart unless-stopped nginx

异常退出会拉起，管理员明确停止后，Docker服务重启不会把它抢回来。控制权和自动恢复比较均衡。

on-failure别无限重试

任务型容器建议加次数：

docker run --name job --restart on-failure:5 example-job

临时网络抖动可以靠重试扛过去，配置错误重试100次也没用。5次通常足够观察问题。

验证时看三件事

正常退出、异常退出、手动停止各测一次。再执行：

docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' 容器名

同时看 docker ps -a 和日志时间。日志每隔几秒重复同一条错误，多半是应用循环失败，不是Docker本身的问题。

常见问题

生产环境推荐哪个策略？长期服务优先 unless-stopped。

容器一直重启怎么办？先停止并看日志，不要只调restart。

on-failure适合网站吗？不适合，网站更常用always或unless-stopped。