Docker Compose重启条件揭秘：如何选择always、no、on-failure、unless-stopped？

第一章：Docker Compose重启条件概述

Docker Compose 提供了灵活的容器生命周期管理能力，其中服务的自动重启策略是保障应用高可用性的关键机制。通过在 `docker-compose.yml` 文件中配置 `restart` 字段，可以定义容器在不同场景下的重启行为。这些策略不仅影响服务的稳定性，也决定了系统在异常中断或主机重启后的恢复能力。

重启策略类型

Docker Compose 支持多种重启策略，可根据实际需求选择：

• no：默认策略，容器不会自动重启。
• always：无论退出状态如何，始终重启容器。
• on-failure[:max-retries]：仅在容器以非零状态退出时重启，可选设置最大重试次数。
• unless-stopped：总是重启容器，除非被手动停止。

配置示例

以下是一个典型的 `docker-compose.yml` 片段，展示如何为服务设置重启策略：

version: '3.8'
services:
  web:
    image: nginx:alpine
    restart: always  # 容器退出后始终重启
  worker:
    image: my-worker-app
    restart: on-failure:5  # 最多重试5次

该配置中，`web` 服务将始终被重启，适用于长期运行的Web服务器；而 `worker` 服务仅在执行失败时尝试重启，最多五次，适合批处理任务。

重启触发条件

容器重启可能由以下情况触发：

1. 应用程序崩溃导致进程退出。
2. Docker 守护进程重启（如系统开机）。
3. 使用 docker-compose down && docker-compose up -d 重新部署服务。

策略	主机重启后启动	应用崩溃后重启	手动停止后是否重启
always	是	是	是
unless-stopped	是	是	否
on-failure	是	是（仅失败时）	否
no	否	否	否

第二章：重启策略核心机制解析

2.1 理解restart参数的运行时行为

在容器化环境中，`restart` 参数决定了容器在退出或系统重启后的生命周期策略。该参数由运行时（如Docker）解析并持久监控，直接影响服务的可用性。

常见取值与语义

• no：不自动重启容器
• on-failure[:max-retries]：仅在非零退出码时重启，可限制重试次数
• always：无论退出状态如何，始终重启
• unless-stopped：始终重启，除非被手动停止

配置示例

version: '3'
services:
  web:
    image: nginx
    restart: unless-stopped

上述配置确保容器在宿主机重启后自动恢复运行，适用于长期服务。`unless-stopped` 是生产环境推荐策略，避免因手动停机维护导致意外重启。

运行时行为差异

策略	异常退出	宿主重启	手动停止后
always	是	是	重启
unless-stopped	是	是	不重启

2.2 no策略：默认控制逻辑与适用场景

默认控制行为解析

在未显式配置控制策略时，系统自动启用 no策略，即不进行主动干预。该策略适用于环境稳定、变更频率低的场景，避免因过度控制引发副作用。

典型应用场景

• 测试环境中模拟原始系统行为
• 灰度发布前的基准对照组管理
• 资源密集型任务执行期间的临时禁用

// 示例：启用 no 策略的控制器配置
controller.SetStrategy(&NoOpStrategy{
    EnableAudit:   true,        // 启用操作审计
    GracePeriod:   time.Minute, // 宽限期设置
})

上述代码中，NoOpStrategy 不触发实际调度动作，但保留日志追踪能力。GracePeriod 参数用于定义状态观察窗口，确保异常可被及时捕获。

2.3 always策略：容器高可用保障原理

在容器编排系统中，always策略是确保服务持续运行的核心机制之一。该策略要求无论容器因何种原因退出，运行时都必须重新启动它，从而实现基础的高可用保障。

策略触发条件

• 容器进程异常退出（非0退出码）
• 节点系统重启后自动拉起
• 健康检查失败后的重建

典型配置示例

apiVersion: v1
kind: Pod
spec:
  restartPolicy: Always

上述配置中，restartPolicy: Always 表示Pod中所有容器在终止后都将被kubelet自动重启。该策略适用于长期运行的服务型应用，如Web服务器、数据库等。

与其它策略对比

策略类型	适用场景	重启条件
Always	常驻服务	任何退出均重启
OnFailure	批处理任务	仅失败时重启

2.4 on-failure策略：失败恢复机制深度剖析

在容器编排系统中，on-failure重启策略是保障服务可靠性的核心机制之一。该策略仅在容器以非零退出码终止时触发重启，适用于批处理任务或有明确失败语义的场景。

策略触发条件

以下情况会激活on-failure策略：

• 应用程序运行时异常崩溃
• 进程主动返回非零状态码
• 资源超限导致的退出（如OOM未启用单独策略）

配置示例与参数解析

restart: on-failure:3

上述配置表示容器仅在失败时重启，且最多尝试3次。数字参数控制重试上限，避免无限循环启动故障实例，适用于短暂依赖不可用的容错恢复。

重试间隔与退避机制

系统通常采用指数退避算法延迟重试，例如首次1秒后重试，第二次2秒，第三次4秒，减轻对底层服务的压力。

2.5 unless-stopped策略：持久化守护模式解析

在容器编排与服务自愈机制中，`unless-stopped` 是 Docker 容器重启策略中的关键模式之一。该策略确保容器在守护进程中持续运行，除非被手动停止。

行为特性

• 容器随宿主机启动自动恢复运行
• 仅当执行 docker stop 后，重启不再触发启动
• 适用于需长期运行但允许人工干预的生产服务

配置示例

{
  "RestartPolicy": {
    "Name": "unless-stopped",
    "MaximumRetryCount": 0
  }
}

上述配置表明容器将在非人为停止状态下无限次重启，MaximumRetryCount 在此策略下不生效，系统由守护进程全权管理生命周期。

策略对比

策略	自动重启	手动停止后是否重启
no	否	否
always	是	是
unless-stopped	是	否

第三章：重启策略配置实践指南

3.1 docker-compose.yml中配置restart参数

在 Docker Compose 中，`restart` 参数用于定义容器在退出或系统重启时的重启策略。该配置直接影响服务的可用性和故障恢复能力。

常用重启策略

• no：不自动重启容器（默认策略）
• always：无论退出状态如何，始终重启
• on-failure：仅在非0退出码时重启，可指定重试次数如 on-failure:3
• unless-stopped：始终重启，除非被手动停止

配置示例

version: '3.8'
services:
  web:
    image: nginx
    restart: always
  db:
    image: mysql:8.0
    restart: unless-stopped

上述配置中，`web` 服务将始终重启以保障服务连续性；`db` 使用 `unless-stopped`，适合持久化数据的服务，在主机重启后自动恢复运行，同时尊重管理员的停止意图。

3.2 不同策略下的容器生命周期观察

在 Kubernetes 中，容器的生命周期受多种策略影响，包括重启策略、探针配置和终止行为。不同的组合将直接影响应用的可用性与资源管理。

重启策略对比

• Always：容器崩溃或正常退出后始终重启，适用于长期运行的服务。
• OnFailure：仅在容器非零退出时重启，适合批处理任务。
• Never：从不自动重启，用于一次性调试任务。

存活与就绪探针配置

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

上述配置表示容器启动后15秒开始检测，每20秒发起一次健康检查。若探测失败，Kubelet 将重启容器，从而实现自我修复能力。

终止流程控制

当 Pod 被删除时，系统发送 SIGTERM 信号并等待 terminationGracePeriodSeconds（默认30秒）后强制终止，确保服务优雅下线。

3.3 结合日志分析策略执行效果

在评估安全策略执行效果时，系统日志是关键数据源。通过解析访问日志、审计日志和异常事件日志，可识别策略是否按预期生效。

日志采集与结构化处理

应用通常输出JSON格式日志，便于后续分析：

{
  "timestamp": "2023-10-01T08:22:10Z",
  "event_type": "auth_failure",
  "source_ip": "192.168.1.100",
  "user": "admin",
  "rule_triggered": "block_external_admin"
}

该日志表明外部IP尝试管理员登录被拦截，验证了“禁止外部管理员访问”策略已激活。

策略命中统计分析

使用ELK栈聚合日志后，生成如下命中统计：

策略名称	触发次数（24h）	关联风险等级
block_external_admin	47	高
limit_login_attempts	189	中

高频触发项需结合上下文判断是否为攻击行为，进而优化阈值配置。

第四章：典型应用场景与问题排查

4.1 使用always实现服务自愈系统

在构建高可用系统时，利用 `systemd` 的 `Restart=always` 策略可实现进程级的自愈能力。只要服务异常退出，系统将自动重启该进程，保障持续运行。

配置示例

[Unit]
Description=My Service
After=network.target

[Service]
ExecStart=/usr/bin/my-service
Restart=always
RestartSec=5s
User=myuser

[Install]
WantedBy=multi-user.target

上述配置中，Restart=always 表示无论退出原因如何均重启；RestartSec=5s 定义了重启前等待5秒，避免频繁启动冲击系统。

自愈机制对比

策略	触发条件	适用场景
no	从不重启	调试任务
on-failure	非零退出码、被信号终止	关键业务服务
always	任何退出	常驻守护进程

4.2 on-failure配合最大重试次数优化容错

在任务调度系统中，on-failure 策略结合最大重试次数可显著提升服务容错能力。当任务因临时性故障（如网络抖动、资源争用）失败时，系统自动触发重试机制，避免服务中断。

重试策略配置示例

retry_on_failure: true
max_retries: 3
backoff_delay: 5s

上述配置表示任务失败后最多重试3次，每次间隔5秒。指数退避可缓解服务雪崩，提升恢复概率。

重试机制优势对比

策略	是否自动恢复	资源消耗
无重试	否	低
on-failure + 最大重试	是	中

4.3 unless-stopped在生产环境中的稳定优势

容器自愈能力的增强

在生产环境中，服务的高可用性至关重要。使用 restart: unless-stopped 策略可确保容器在异常退出时自动重启，仅当手动停止时才不恢复。

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

该配置保证系统重启或Docker服务恢复后，关键应用能自动拉起，避免人为干预延迟上线时间。

与其它策略对比

• no：不自动重启，适用于一次性任务；
• always：无论是否手动停止都会重启；
• unless-stopped：尊重管理员意图，实现运维友好型自愈。

此策略在稳定性与可控性之间取得平衡，广泛应用于长期运行的服务部署中。

4.4 常见误配导致的重启循环问题诊断

在 Kubernetes 环境中，容器频繁重启常由配置错误引发。典型原因包括就绪探针（readinessProbe）与存活探针（livenessProbe）阈值设置不当。

探针配置误区

若存活探针失败次数过多，Pod 会被强制重启，形成循环。例如：

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3
  failureThreshold: 1

上述配置中，failureThreshold: 1 表示一次失败即触发重启，而 periodSeconds: 3 导致每3秒检查一次，在服务启动慢或瞬时负载高时极易误判。

常见错误对照表

配置项	风险配置	推荐配置
initialDelaySeconds	5	30+
failureThreshold	1	3

合理设置可有效避免因初始化延迟导致的误杀。

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

实施持续集成的自动化策略

在现代软件交付流程中，持续集成（CI）是保障代码质量的核心机制。通过自动化测试和构建流程，团队可以快速发现并修复问题。以下是一个典型的 GitHub Actions 配置示例：

name: CI Pipeline
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Go
        uses: actions/setup-go@v4
        with:
          go-version: '1.21'
      - name: Run tests
        run: go test -v ./...
      - name: Build binary
        run: go build -o myapp main.go

微服务架构下的可观测性建设

当系统拆分为多个服务时，日志、指标和链路追踪成为运维关键。建议统一采用 OpenTelemetry 标准收集数据，并集中到 Prometheus 与 Grafana 平台。

• 所有服务启用结构化日志输出（JSON 格式）
• 关键路径注入 trace ID，实现跨服务追踪
• 设置 SLI/SLO 监控告警，如延迟、错误率和饱和度
• 定期执行混沌工程演练，验证系统韧性

安全配置的最佳实践

风险项	推荐措施	工具示例
密钥硬编码	使用 Secrets Manager 管理凭证	AWS Secrets Manager, Hashicorp Vault
依赖漏洞	集成 SCA 工具进行依赖扫描	Snyk, Dependabot
不安全的 API 端点	强制启用身份认证与速率限制	OAuth2, Istio Rate Limiting