Docker Compose中的restart详解：什么情况下容器会自动重启？

第一章：Docker Compose中restart策略概述

在使用 Docker Compose 编排多容器应用时，restart 策略是确保服务高可用性的关键配置之一。该策略定义了容器在退出或系统重启后是否以及如何自动重新启动，适用于生产环境中对服务连续性有严格要求的场景。

restart策略的常用取值

• no：默认值，不自动重启容器
• on-failure：仅在容器以非零退出码退出时重启，可指定重试次数，如 on-failure:3
• always：无论退出原因如何，始终重启容器
• unless-stopped：总是重启容器，除非容器被手动停止

在docker-compose.yml中的配置示例

version: '3.8'
services:
  web:
    image: nginx:latest
    restart: always
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: example
    restart: on-failure:5

上述配置中，web 服务将始终重启，而 db 服务仅在失败时最多尝试重启5次。

不同策略的应用场景对比

策略	适用场景	注意事项
no	开发调试、一次性任务	需手动干预恢复服务
on-failure	批处理作业、可能临时出错的服务	避免无限循环重启
always	长期运行的Web服务	即使手动停止也会在Docker守护进程重启后启动
unless-stopped	生产环境核心服务	最推荐用于需要持久运行的服务

第二章：常见的restart策略类型及其行为

2.1 no策略：容器退出时不进行重启（理论解析与使用场景）

策略定义与核心机制

no 是 Docker 容器重启策略中最基础的一种，表示无论容器因何种原因退出，Docker 守护进程都不会自动重启该容器。该策略适用于一次性任务或需要人工干预的调试场景。

典型应用场景

• 执行批处理脚本，如数据备份、日志归档等短期任务
• 开发阶段的容器调试，避免异常退出后无限循环启动
• 需手动检查失败原因的关键操作，防止自动化掩盖问题

配置示例与参数说明

docker run -d --restart=no ubuntu:20.04 /bin/bash -c "echo 'Hello'; exit 1"

上述命令中，--restart=no 明确指定不重启策略。即使容器内部命令返回非零退出码，Docker 也不会重新拉起容器实例，保障了运行的可控性。

2.2 always策略：无论退出状态如何都重启容器（配置示例与实际应用）

always 重启策略确保容器在任何退出状态下都会被自动重启，适用于需要长期运行的关键服务。

配置示例

version: '3'
services:
  web:
    image: nginx
    restart: always

上述 docker-compose.yml 配置中，restart: always 表示无论容器因何原因退出（包括手动停止或崩溃），Docker 都会重新启动该容器。此行为由 Docker 守护进程监控并触发。

实际应用场景

• 生产环境中的 Web 服务器，要求高可用性
• 后台任务守护进程，防止意外中断导致服务不可用
• 日志收集代理，需持续运行以保障可观测性

该策略与 on-failure 不同，不依赖退出码，适用于必须始终处于运行状态的容器化服务。

2.3 on-failure策略：仅在非零退出码时重启（错误处理机制剖析）

策略触发条件解析

on-failure 重启策略仅在容器以非零退出码终止时触发，适用于预期可恢复的临时性故障。该策略不会响应正常退出（退出码0），避免不必要的重启。

典型应用场景

• 批处理任务执行失败需重试
• 依赖服务短暂不可达
• 网络抖动导致的初始化失败

services:
  worker:
    image: my-worker:latest
    restart: on-failure
    restart_policy:
      max_attempts: 3
      delay: 5s

上述配置表示：任务失败后最多重试3次，每次间隔5秒。max_attempts 防止无限循环，delay 提供恢复窗口。

2.4 unless-stopped策略：持久化运行的守护模式（适用于生产环境的实践）

在Docker容器编排中，restart: unless-stopped 是生产环境中推荐的重启策略之一。它确保容器在异常退出时自动重启，同时尊重管理员的主动停止操作。

策略行为解析

• 容器正常启动后，即使宿主机重启也会重新运行
• 仅当管理员手动执行 docker stop 时，才不再重启
• 意外崩溃、系统重启等场景下自动恢复服务

典型配置示例

version: '3.8'
services:
  app:
    image: myapp:v1
    restart: unless-stopped

上述配置中，restart: unless-stopped 表明除非被显式停止，否则 Docker 守护进程会在启动时自动拉起该容器，实现服务的持久化守护。 该策略平衡了可用性与运维控制权，特别适用于需要长期稳定运行的关键业务组件。

2.5 各restart策略对比分析与选型建议（结合运维需求的决策指南）

在Kubernetes等平台中，常见的重启策略包括Always、OnFailure和Never，其适用场景因服务类型而异。

策略特性对比

策略	适用场景	自动重启
Always	长期运行的服务（如Web服务器）	容器退出即重启
OnFailure	批处理任务	仅失败时重启
Never	调试或手动控制场景	从不自动重启

典型配置示例

apiVersion: v1
kind: Pod
spec:
  restartPolicy: OnFailure # 适用于Job类任务，避免成功后无限重启

该配置确保任务失败时由控制器重新调度，而执行成功后不再重启，符合批处理逻辑。对于常驻服务，应选用Always以保障高可用性。运维团队需根据应用生命周期和故障容忍度进行精准选型。

第三章：影响容器重启的关键系统因素

3.1 Docker守护进程重启后容器的恢复行为（实验验证流程）

在默认配置下，Docker守护进程重启后不会自动重启正在运行的容器，除非设置了重启策略。为验证该行为，可通过以下步骤进行实验。

实验准备

启动一个带有名称标识的测试容器，并设置重启策略为 `unless-stopped`：

docker run -d --name test-container --restart unless-stopped ubuntu:20.04 sleep 3600

其中 `--restart unless-stopped` 表示除非容器被手动停止，否则守护进程重启后将重新启动该容器。

验证流程

• 执行 sudo systemctl restart docker 重启Docker服务
• 使用 docker ps 查看容器状态
• 观察容器是否自动恢复运行

结果分析

重启策略	守护进程重启后行为
no	不重启
always	自动重启
unless-stopped	若未手动停止则重启

3.2 主机系统重启对容器生命周期的影响（持久化部署策略）

当主机系统重启时，容器的生命周期将受到直接影响。默认情况下，Docker 容器不会随宿主机自动启动，导致服务中断。为实现持久化部署，必须采用合适的重启策略。

容器重启策略配置

通过设置 --restart 参数可定义容器在异常或系统重启后的恢复行为：

docker run -d --restart=unless-stopped \
  --name nginx-container \
  -v /data/nginx:/usr/share/nginx/html \
  nginx:latest

上述命令中，unless-stopped 策略确保容器在宿主机重启后自动启动，除非被手动停止。配合数据卷挂载（-v），实现配置与数据的持久化。

策略对比

• no：不自动重启，适用于临时任务；
• on-failure：仅在退出码非0时重启；
• always：无论退出状态均重启；
• unless-stopped：始终重启，除非被显式停止。

3.3 容器资源限制与OOM引发的重启机制（监控与规避方法）

资源限制配置与OOM关系

在Kubernetes中，容器可通过resources.limits设置内存上限。当容器内存使用超过该值时，内核会触发OOM（Out-of-Memory）终止进程，导致Pod重启。

resources:
  limits:
    memory: "512Mi"
  requests:
    memory: "256Mi"

上述配置表示容器最大使用512MiB内存。若超出，cgroup会触发OOM Killer，优先终止占用内存最多的进程。

监控与告警策略

为提前规避OOM，建议部署Prometheus监控容器内存使用率，并设置告警规则：

• 监控指标：container_memory_usage_bytes
• 告警阈值：接近memory limit的80%
• 通知方式：集成Alertmanager推送至企业微信或邮件

规避措施

合理设置资源限制、启用就绪探针、使用垂直Pod自动伸缩（VPA），可有效降低OOM发生概率。

第四章：服务依赖与健康检查对重启行为的影响

4.1 依赖服务启动失败导致的连锁重启问题（案例模拟与解决方案）

在微服务架构中，服务间依赖关系复杂，当核心依赖服务启动失败时，可能引发调用方频繁重试并触发健康检查失败，进而导致连锁重启。

典型场景模拟

假设订单服务启动时依赖用户服务获取权限信息，若用户服务未就绪，订单服务因连接超时而启动失败，容器平台自动重启实例，形成循环。

解决方案：优雅启动与重试控制

通过设置启动探针和初始延迟，避免过早判定失败：

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
startupProbe:
  httpGet:
    path: /ready
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

上述配置中，startupProbe 允许最长5分钟用于初始化，期间不进行存活检查，避免因依赖未就绪导致的误判。一旦通过，则交由 livenessProbe 管理。该机制有效切断了因启动风暴引发的连锁反应。

4.2 健康检查未通过时的自动恢复机制（集成restart策略的最佳实践）

在容器化应用运行过程中，健康检查是保障服务稳定性的关键环节。当探针检测到应用异常时，结合合理的重启策略可实现故障自愈。

重启策略配置示例

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3
restartPolicy: Always

上述配置中，failureThreshold: 3 表示连续三次失败后触发重启；restartPolicy: Always 确保 Pod 在任何终止情况下均被重新拉起，适用于长期运行的服务。

策略选择建议

• Always：适用于无状态服务，保证始终运行；
• OnFailure：仅容器异常退出时重启，适合批处理任务；
• Never：不推荐用于生产环境中的长期服务。

4.3 应用崩溃与信号中断后的容器状态变化（日志分析与诊断技巧）

当容器内应用因未捕获异常或接收到终止信号而崩溃时，其状态会从“running”转变为“exited”，此时需结合日志与退出码进行诊断。

常见信号与退出码含义

• 137：容器被 SIGKILL 终止，通常因内存超限（OOM）
• 143：收到 SIGTERM，正常关闭流程被触发
• 139：SIGSEGV，程序发生段错误

日志提取与分析命令

docker logs --tail 50 --timestamps my-container

该命令获取最近50行日志并显示时间戳，便于定位崩溃时刻的输出信息。配合 --follow 可实时追踪日志流。

容器状态检查表

状态	含义	建议操作
exited (137)	OOM 被杀	检查内存限制与应用堆使用
exited (1)	应用异常退出	查看应用日志栈跟踪
restarting	持续重启	检查依赖与启动脚本

4.4 网络异常或存储挂载失败引发的重启场景（容错设计思路）

在分布式系统中，网络抖动或存储设备临时不可达常导致节点误判为故障，从而触发非必要重启。为提升系统稳定性，需引入容错机制。

重试与退避策略

采用指数退避重试可有效缓解瞬时故障。例如，在挂载存储失败时进行有限次重试：

func mountWithRetry(device, target string, maxRetries int) error {
    for i := 0; i < maxRetries; i++ {
        err := mountDevice(device, target)
        if err == nil {
            return nil
        }
        time.Sleep(time.Duration(1 << uint(i)) * time.Second) // 指数退避
    }
    return fmt.Errorf("failed to mount %s after %d retries", device, maxRetries)
}

上述代码通过指数级延迟重试，避免因短暂网络波动导致服务中断，降低误重启概率。

健康检查分级

• 轻度异常：如短暂丢包，仅记录日志并启动重试
• 严重异常：连续多次挂载失败，上报控制面介入

通过分级响应机制，系统可在保持可用性的同时精准识别真实故障。

第五章：总结与最佳实践建议

监控与日志的统一管理

在微服务架构中，分散的日志增加了故障排查难度。推荐使用 ELK（Elasticsearch, Logstash, Kibana）栈集中收集和分析日志。例如，在 Go 服务中集成 Zap 日志库并输出结构化日志：

logger, _ := zap.NewProduction()
defer logger.Sync()
logger.Info("user login attempted",
    zap.String("ip", "192.168.1.1"),
    zap.Bool("success", false))

自动化部署流程

持续集成/持续部署（CI/CD）是保障系统稳定迭代的核心。建议使用 GitLab CI 或 GitHub Actions 实现自动化测试与部署。以下为典型流水线阶段：

• 代码提交触发单元测试
• 构建 Docker 镜像并打标签
• 推送镜像至私有仓库
• 通过 Helm 更新 Kubernetes 部署

安全配置最佳实践

确保所有服务通信启用 TLS，并使用短期 JWT 令牌进行身份验证。避免在配置文件中硬编码密钥，应使用 Hashicorp Vault 或 Kubernetes Secrets 管理敏感信息。

实践项	推荐方案
认证机制	OAuth2 + JWT
密钥轮换周期	每7天自动更新
API 访问控制	基于角色的访问控制（RBAC）

性能压测常态化

使用

标签嵌入性能测试流程图结构，模拟真实用户负载：

[代码提交] → [触发 CI 流水线] → [启动 Locust 压测] → [生成 QPS 报告] → [异常则阻断发布]

定期执行全链路压测，识别瓶颈服务。某电商平台在大促前通过该机制发现数据库连接池不足，及时将连接数从 50 提升至 200，避免了服务雪崩。