为什么会秒退
容器的生命周期跟随主进程：容器内的 1 号进程一退出，容器随之结束。因此在后台模式启动一个交互式 shell、脚本执行完之后没有前台进程、或者应用启动即失败，都会看到容器立即退出。排查重点是确认退出码与最后几行输出，再判断这是任务正常结束还是启动失败。
基本信息
| 机制 | 1 号进程退出，容器即停止 |
|---|---|
| 验证方式 | 查看容器状态与退出码 |
| 常见原因 | 缺少前台进程、启动命令错误、应用初始化失败 |
| 修复方式 | 改用常驻前台进程、以交互模式启动、更正启动命令 |
| 区分要点 | 退出码为 0 多为任务正常结束 |
典型使用场景
- 后台启动容器后立刻发现状态已是退出
- 自写入口脚本在后台拉起服务后脚本结束，容器跟着停
- 应用启动即失败，需要看最后几行输出定位原因
- 交互式排障容器需要保持运行
- 区分任务型容器与应用型容器的预期行为
观察与修复
观察与修复
docker run -d alpine echo hello # 输出后立即退出，退出码为 0
docker ps -a --format '{{.Names}} {{.Status}}' # 查看状态与退出码
docker logs <容器名> --tail=50 # 看最后几行输出
docker run -dit --name shell alpine sh # 交互式容器保持运行
docker run -d --name api app/api:1.4.2 # 应用需要自己以前台方式常驻状态与含义
| 现象 | 含义 | 处理 |
|---|---|---|
| Exited (0) | 主进程正常结束 | 先判断该场景是否需要常驻 |
| Exited (非 0) | 启动或运行失败 | 查看日志与退出码定位 |
| 启动后立即退出 | 启动命令本身有问题 | 核对入口命令与参数 |
| 持续处于运行状态 | 前台进程常驻 | 属于应用型容器的预期状态 |
后台型服务本身以前台方式运行没有问题，问题多出在自写脚本把服务转到后台后脚本自己退出。
判断容器属于任务型还是应用型很关键：任务型容器退出是正常行为，应用型容器的退出才需要修复。