Docker容器重启策略验证需聚焦四类极端场景：宿主机断电、OOM崩溃、进程异常退出、daemon故障，并检查服务可用性、live-restore配置、退出码语义及状态时间戳，而非仅容器状态。
测试 docker 容器重启策略在极端环境下的表现，核心是模拟真实故障场景，并观察策略是否按预期触发、是否受干扰、是否引发副作用。不能只看“容器有没有重启”，而要看“什么时候重启、重启几次、为什么没重启、重启后是否真正可用”。
一、明确要验证的策略行为边界
不同策略对“退出原因”和“人为干预”的响应逻辑完全不同，需逐项确认： - no：手动 stop、kill -9、OOM 被杀、宿主机断电后，容器是否始终不自启？ - on-failure[:N]：exit 1 和 exit 137（OOMKilled）是否都被识别为“失败”？达到 N 次后是否彻底停止？exit 0 是否绝对不触发重启？ - always：手动 docker stop 后，Docker daemon 重启时是否拉起？容器内进程主动 exit 0 是否仍被重启？ - unless-stopped：手动 stop 后，daemon 重启是否跳过该容器？后续执行 docker start 是否恢复策略？二、构造四类典型极端场景并验证
每类测试建议单独运行容器，避免交叉影响，并用 docker inspect --format='{{.State.Status}} {{.State.ExitCode}} {{.State.StartedAt}} {{.State.FinishedAt}}' 记录关键状态。
宿主机级中断
关机前运行docker run --restart=always --name test-hostdown nginx:alpine；强制断电或systemctl reboot -f；开机后检查容器是否自动 running，且StartedAt时间是否为 reboot 后。资源耗尽型崩溃
启动一个内存泄漏容器：docker run --restart=on-failure:2 --memory=50m -it alpine sh -c 'dd if=/dev/zero | gzip -c > /dev/null'；等待 OOMKilled（docker inspect ... | jq '.State.OOMKilled'应为 true）；观察是否重启 2 次后永久停止。进程级异常退出
运行docker run --restart=on-failure:1 alpine sh -c 'echo crash; exit 126'（126 是命令不可调用）；确认重启一次；再运行exit 0版本，确认无重启。Docker daemon 故障
先启动--restart=unless-stopped容器；执行sudo systemctl kill --signal=SIGUSR1 docker（触发 daemon reload，非 restart）；确认容器持续运行；再sudo systemctl restart docker；确认容器未被拉起（因曾被手动 stop 过）。
三、关键观察点与易忽略细节
- 重启不是目的，**服务可用才是终点**：用curl -f http://localhost:port/health 或自定义健康检查脚本，在每次重启后 5 秒、30 秒、2 分钟分别探测，确认进程已就绪，而非仅“状态为 running”。
- live-restore 必须开启：若未在 /etc/docker/daemon.json 中配置 "live-restore": true，daemon 重启会导致所有容器强制 stop，此时任何 --restart 策略都失效——这是生产环境最常被遗漏的配置。
- 退出码语义必须匹配：Docker 将容器退出码等同于主进程退出码。若应用 fork 多进程但主进程提前 exit 0，而子进程崩溃，Docker 仍视为“正常退出”，不会触发 on-failure。
- 不要依赖 docker logs 判断重启次数：日志可能被覆盖；应以 docker ps -a 中的 “Up X seconds ago” 和 FinishedAt 时间戳为准。
四、自动化验证建议（轻量级）
写一个 shell 脚本循环执行以下动作：启动容器 → 等待 3 秒 → kill -9 主进程 → 等待 10 秒 → 检查是否重启 → 检查退出码 → 记录结果。连续跑 50 次，统计重启成功率、平均延迟、是否出现策略误判。比人工点按更可靠。不复杂但容易忽略
