unless-stopped到底何时生效？揭开Docker Compose重启条件的神秘面纱

第一章：unless-stopped到底何时生效？揭开Docker Compose重启条件的神秘面纱

在使用 Docker Compose 编排容器时，`restart` 策略是控制服务容器在异常退出或系统重启后是否自动恢复运行的关键配置。其中 `unless-stopped` 是最常被误解的选项之一。它既不像 `always` 那样无条件重启，也不像 `no` 完全不重启，其行为依赖于容器的“停止”状态是否由用户显式触发。

理解 unless-stopped 的触发逻辑

当容器因崩溃、进程退出或宿主机重启而中断时，若其 `restart` 策略设置为 `unless-stopped`，Docker 会自动将其重新启动。但前提是该容器**未被用户通过 `docker stop` 或 `docker-compose stop` 显式停止**。一旦执行过停止命令，即使宿主机重启，该容器也不会自动启动。

Docker restart 策略对比

策略	容器异常退出	宿主机重启	用户 stop 后宿主机重启
no	不重启	不重启	不重启
always	重启	重启	重启
unless-stopped	重启	重启	不重启

实际配置示例

version: '3.8'
services:
  web:
    image: nginx
    restart: unless-stopped  # 容器将在多数故障场景下自动重启，除非被手动停止

上述配置中，`web` 服务会在系统重启后自动启动，前提是用户未曾执行 `docker-compose stop`。若已停止，则需手动执行 `docker-compose start` 恢复。

• 使用 docker inspect <container_id> 可查看容器当前的重启策略和状态。
• 策略在容器创建时生效，修改需重建容器。
• 生产环境中推荐使用 unless-stopped 以平衡自动化与可控性。

第二章：Docker容器重启策略的核心机制

2.1 理解restart策略的四种类型及其设计初衷

在分布式系统与容器编排中，任务失败后的恢复机制至关重要。Restart策略定义了容器或作业在异常终止后是否以及如何重启，其设计初衷在于平衡系统稳定性、资源利用率与故障恢复能力。

四种核心Restart策略

• Never：从不重启，适用于一次性任务或调试场景；
• OnFailure：仅在容器非零退出码时重启，适合批处理任务；
• Always：无论退出状态均重启，保障服务持续运行；
• UnlessCompleted：除非成功完成，否则始终重启，多用于关键工作流。

典型配置示例

restartPolicy: OnFailure
restartAttempts: 3
backoffSeconds: 10

上述配置表示：仅在失败时重启，最多尝试3次，每次间隔10秒。该机制通过指数退避减少系统震荡，提升恢复成功率。

2.2 unless-stopped策略的行为逻辑与适用场景分析

行为机制解析

`unless-stopped` 是 Docker 容器重启策略中的一种，其核心逻辑在于：除非容器被手动停止，否则在 Docker 守护进程重启或系统重启后，容器将自动恢复运行。

• 容器在正常运行时崩溃：自动重启
• Docker 服务重启：容器自动启动
• 手动执行 docker stop：容器不再重启

典型应用场景

该策略适用于需长期运行且高可用要求的服务，如数据库、消息队列等。例如：

docker run -d --restart unless-stopped mysql:8.0

上述命令确保 MySQL 容器在异常退出后自动拉起，但若运维人员主动停用，则尊重操作意图，不再重启。

与其他策略对比

策略	异常退出	系统重启	手动停止后
no	不重启	不启动	—
always	重启	启动	仍重启
unless-stopped	重启	启动	不重启

2.3 实验验证：容器异常退出时unless-stopped的实际响应

在Docker容器生命周期管理中，`restart=unless-stopped`策略的行为常被误解。该策略允许容器在守护进程启动时自动重启，除非其曾被手动停止。

实验设计

通过模拟容器崩溃场景，观察其重启行为：

1. 启动一个配置了unless-stopped的Nginx容器
2. 使用kill -9强制终止容器进程
3. 重启Docker服务并监控容器状态

docker run -d \
  --name test-web \
  --restart unless-stopped \
  -p 8080:80 \
  nginx:alpine

上述命令创建容器并应用重启策略。参数--restart unless-stopped确保除非人为停止，否则总会在守护进程恢复后重启。

结果分析

操作	容器行为
异常退出 + 服务重启	自动启动
手动docker stop + 服务重启	保持停止

实验证实：该策略精准区分故障退出与人工干预，适用于生产环境的高可用保障。

2.4 实践对比：no、always、on-failure与unless-stopped的差异测试

Docker容器的重启策略直接影响服务的可用性与资源管理。通过实际部署可清晰观察不同策略的行为差异。

策略类型说明

• no：容器退出后不重启
• always：无论退出状态如何，始终重启
• on-failure：仅在非零退出码时重启（可设最大重试次数）
• unless-stopped：始终重启，除非被手动停止

测试示例配置

docker run -d --restart=on-failure:3 nginx

该命令设置容器仅在失败时最多重试3次。适用于批处理任务，避免无限循环崩溃。

行为对比表

策略	正常退出(0)	异常退出(1)	手动停止后
no	不重启	不重启	—
always	重启	重启	重启
on-failure	不重启	重启	不重启
unless-stopped	重启	重启	不重启

2.5 Docker守护进程重启后容器恢复行为实测

在默认配置下，Docker守护进程意外重启后，运行中的容器不会自动恢复。为验证实际行为，通过 systemctl 重启 docker 服务进行测试。

测试环境准备

启动一个带有健康检查的 Nginx 容器：

docker run -d --name web \
  -p 8080:80 \
  --restart=unless-stopped \
  nginx:alpine

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

恢复策略对比

策略	行为
no	不自动重启
on-failure	仅失败时重启
always	始终重启
unless-stopped	排除手动停止场景

实测表明，仅当设置重启策略时，容器才能在守护进程恢复后自动运行。

第三章：Docker Compose中配置重启策略的方法

3.1 在docker-compose.yml中正确声明restart字段

在 Docker Compose 中，`restart` 字段用于定义容器退出时的重启策略。合理配置该字段可提升服务的可用性与容错能力。

常用重启策略

• no：不自动重启（默认行为）
• always：无论退出状态如何，始终重启
• on-failure[:max-retries]：仅在非零退出码时重启，可选重试次数
• unless-stopped：总是重启，除非被手动停止

配置示例

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

上述配置确保容器在系统重启后仍能自动启动，适用于生产环境中的关键服务。`unless-stopped` 是推荐策略，避免因人为干预导致意外重启。

3.2 不同Compose版本对restart支持的兼容性解析

Docker Compose 的 `restart` 策略在不同版本中存在显著差异，尤其在从 v1 到 v2/v3 的演进过程中。

Compose 文件格式版本对比

• v1（docker-compose.yml 无显式 version）：支持 restart，但仅作用于顶层服务
• v2.4+：增强对 restart_policy 的支持，适用于 swarm 模式
• v3.x：弃用简单 restart 字段，推荐使用 deploy.restart_policy

典型配置示例

version: '3.8'
services:
  web:
    image: nginx
    deploy:
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3

该配置仅在 Swarm 模式下生效。若使用非 Swarm 模式，应改用：

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

前者适用于编排集群，后者适用于单机部署，体现了版本与运行环境的强关联性。

3.3 实践演示：构建包含unless-stopped的服务并观察启动行为

服务定义与配置

在 Docker Compose 中，通过 restart: unless-stopped 可实现容器的智能重启策略。以下为典型服务配置示例：

version: '3.8'
services:
  web:
    image: nginx:alpine
    restart: unless-stopped
    ports:
      - "8080:80"

该配置表示：除非手动执行 docker stop，否则容器将在宿主机重启或Docker守护进程恢复后自动启动。

启动行为分析

• 宿主机重启后，Docker 服务启动时自动拉起该容器；
• 执行 docker stop web 后，即使系统重启，容器也不会启动；
• 使用 docker start web 可重新启用自动重启策略。

此机制适用于生产环境中的关键服务，保障高可用性同时保留手动控制权。

第四章：生产环境中重启策略的选择与优化

4.1 数据持久化与重启策略的协同设计考量

在分布式系统中，数据持久化与重启策略的协同设计直接影响系统的可靠性与恢复效率。若持久化频率过低，重启后可能丢失大量状态；若过高，则增加I/O开销。

持久化与重启的权衡

关键在于选择合适的快照间隔与日志记录机制。例如，在Kubernetes中配置Pod重启策略时，需结合持久卷（PersistentVolume）确保状态不丢失。

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: app
      image: nginx
  restartPolicy: Always
  volumes:
    - name: data
      persistentVolumeClaim: claim-example

上述配置中，restartPolicy: Always 确保容器异常后重启，而 persistentVolumeClaim 挂载外部存储，避免数据因重启丢失。

策略匹配建议

• 有状态服务应使用 StatefulSet 配合持久化存储
• 无状态服务可采用 restartPolicy: OnFailure 并依赖外部数据库

4.2 日志采集与监控系统对接中的重启影响规避

在日志采集系统与监控平台对接过程中，服务重启可能导致数据丢失或重复上报。为规避此类风险，需引入持久化缓冲与状态追踪机制。

数据持久化缓冲

采用本地磁盘队列作为临时存储，确保网络中断或进程重启时日志不丢失。以 Filebeat 为例：

filebeat.inputs:
  - type: log
    paths:
      - /var/log/app/*.log
    persistence.enabled: true
    queue.spool_size: 2048

该配置启用持久化队列，spool_size 控制内存中暂存的日志事件数，超出后写入磁盘，保障重启后可恢复未发送数据。

消费位点管理

通过记录文件读取偏移量（offset），实现断点续传。系统重启后依据 checkpoint 恢复采集位置，避免重复或遗漏。

• 使用文件 inode + offset 唯一标识读取位置
• 定期将位点信息刷写至磁盘数据库（如 LevelDB）
• 启动时优先加载最新 checkpoint 状态

4.3 容器编排升级时的策略调整实践

在容器化环境中，编排系统如 Kubernetes 的升级过程需精细控制，避免服务中断。滚动升级是最常见的策略，通过逐步替换旧实例确保可用性。

滚动更新配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

该配置中，maxSurge 控制额外创建的Pod数量，maxUnavailable 设为0确保升级期间所有副本始终可用，适用于对SLA要求严苛的服务。

金丝雀发布流程

• 降低上线风险，快速回滚
• 结合Prometheus实现自动熔断

4.4 避坑指南：常见误用场景及解决方案

并发写入导致数据覆盖

在分布式系统中，多个实例同时更新同一配置项是典型误用。缺乏乐观锁机制时，后写入者会无感知地覆盖前者变更。

{
  "config_key": "timeout",
  "value": 3000,
  "version": 12
}

通过引入 version 字段实现版本控制，每次更新需校验版本号，避免静默覆盖。

监听失效的三种情形

• 网络抖动未重连订阅通道
• 监听回调函数抛出异常中断事件循环
• 使用短生命周期对象作为监听器

应采用带自动重连机制的客户端，并将监听逻辑封装在守护进程中持续运行。

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

性能监控与调优策略

在高并发系统中，持续的性能监控是保障稳定性的关键。使用 Prometheus + Grafana 组合可实现对服务指标的实时采集与可视化展示。

# prometheus.yml 片段
scrape_configs:
  - job_name: 'go_service'
    static_configs:
      - targets: ['localhost:8080']  # 暴露 /metrics 端点

定期分析 GC 停顿、goroutine 数量和内存分配速率，有助于发现潜在瓶颈。

微服务间通信安全

服务间调用应强制启用 mTLS（双向传输层安全）。Istio 等服务网格可透明实现加密与身份验证，无需修改业务代码。

• 所有内部 API 必须通过 JWT 或 OAuth2 进行认证
• 敏感字段如 password、token 应在日志中脱敏
• 使用 Hashicorp Vault 动态管理数据库凭据

数据库连接池配置建议

不当的连接池设置会导致连接耗尽或资源浪费。以下为 PostgreSQL 在 Kubernetes 环境中的推荐配置：

参数	生产值	说明
max_open_conns	50	每实例最大连接数
max_idle_conns	10	保持空闲连接数
conn_max_lifetime	30m	防止连接过期僵死

CI/CD 流水线中的自动化测试

确保每次部署前执行覆盖率不低于 75% 的单元测试，并集成 SonarQube 进行静态代码分析。