1. 问题背景为什么你的容器总是秒退先聊一个真实案例。之前组里有个新人第一次用 Docker 部署 Nginxdocker run -d -p 8080:80 nginx执行完docker ps一看容器已经退出了。他第一反应是镜像出了问题于是重新 pull又是docker run还是秒退。折腾了一个下午最后发现只是少写了一个参数。这不是个例我在社区看到太多人卡在同一个地方——容器启动后立刻退出docker ps列表里根本没有它只有加-a参数才看得到那个 Exited 状态的残留容器。先说结论容器不是虚拟机它本身没有常驻系统的概念。虚拟机里面跑了一个完整的操作系统各种系统服务自动启动所以虚拟机一开机就能一直运行下去。而容器只是宿主机上的一个进程这个进程执行完自己的任务或者执行失败退出容器就结束了。这是一个思维转变你不是在启动一台机器你是在启动一个进程。那什么情况下容器会一直活着什么情况下它会退出这是理解这个问题的核心。简单说只要容器里的主进程没有退出容器就不会退出。如果主进程很快就跑完了容器自然就 Exited 了如果主进程启动时报错容器也会退出。所以容器启动就退出这个问题本质上就是两个子问题一是主进程跑完退出了二是主进程启动时崩溃了。这篇文章我会把新手最容易踩的三个场景全部拆开揉碎前台进程 vs 后台进程的区别、有没有终端分配-it的影响、以及真正意义上的启动失败报错退出。每一个场景我都会给你完整的排查步骤、解决方法和背后的原理照着做基本不会再出问题。2. 场景一前台进程缺失——你启动了一个空壳这个场景占了新手踩坑的七成以上而且它有个迷惑性很强的地方docker ps -a看到的容器状态是Exited (0)退出码是 0说明进程正常结束了——这恰恰是最容易忽略的线索。2.1 问题现象与根因拆解先看一个典型操作docker run -d ubuntu执行完用docker ps -a查看结果是这样的CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3f8a1b2c9d4e ubuntu bash 5 seconds ago Exited (0) 4 seconds ago keen_hoover退出码是 0说明没有任何错误容器就是正常地退出去了。这个现象背后的逻辑非常简单Ubuntu 镜像的默认命令是bash而bash在没有终端、没有任何输入的情况下会立刻读到 EOF然后退出。进程退出了容器作为一个进程包装器自然也就结束了。这就像你开了一个终端窗口什么命令都没输入直接敲exit关掉窗口一样。终端关了里面跑的进程自然也没了。很多新手觉得Ubuntu 镜像就应该是一个完整的操作系统启动之后应该一直待在那边等你进去操作——但实际上 Docker 镜像只是一个文件系统的快照外加一个默认启动命令。没有任务跑的容器就是个空壳启动即灭亡。2.2 核心原理PID 1 与容器生命周期这里必须引入容器里 PID 1 的概念。在 Linux 系统中PID 1 是 init 进程是所有进程的祖先。在容器里PID 1 就是你指定的那个启动命令进程。Docker 容器的生命周期完全由 PID 1 决定容器启动时Docker 会执行你指定的命令或者镜像默认的CMD/ENTRYPOINT这个命令进程成为容器内的 PID 1。PID 1 进程在运行容器就是Up状态。PID 1 进程退出容器立刻进入Exited状态无论容器里还有没有其他子进程。理解了这一点你就明白了要让容器持续运行必须让 PID 1 进程持续运行。而这个 PID 1 必须是一个前台进程——不是被nohup抛到后台的不是被放到后台的就是实实在在挂在当前终端会话里的那个进程。2.3 解决方案让主进程赖着不走的三种常规做法方法一使用交互式终端 保持前台运行docker run -it ubuntu bash-i是保持标准输入打开interactive-t是分配一个伪终端tty。两个参数配合使用bash就不会读到 EOF它会一直等待你的输入所以容器就能一直活着。这是最直观、最适合新手理解容器生命周期的方式。方法二使用能长期运行的命令比如你要跑一个 Nginxdocker run -d nginxNginx 镜像的默认命令是nginx -g daemon off;这个daemon off是关键——它让 Nginx 以前台模式运行不脱离终端。如果你自己写 Dockerfile 装 Nginx千万不要图省事直接CMD [nginx]因为 Nginx 默认行为是 fork 出 worker 进程后主进程以 daemon 模式后台运行然后容器里 PID 1 就退出了容器也会跟着退出。方法三用tail -f /dev/null之类的挂起命令做占位这只适合临时调试不适合生产环境docker run -d ubuntu tail -f /dev/nulltail -f /dev/null会一直监听一个永远不会产生新内容的文件所以进程永远不会退出。这是很多新手用来制造一个常驻容器的标准做法调试的时候挺好用但如果你的服务本身能以前台模式跑起来没必要用这个野路子。2.4 实操心得如何快速判断是正常退出还是报错退出拿到一个 Exited 的容器第一步先看退出码退出码 0进程主动正常退出或者跑完了任务不是崩溃。退出码 137容器被强制杀掉通常是内存超限OOM或者被人为docker kill。退出码 139段错误程序自己崩了。退出码 125Docker daemon 自身的错误比如启动参数不合法。退出码 126/127命令不存在或者命令存在但没有执行权限。其中 127 特别常见——比如你写 Dockerfile 时CMD [/app/start.sh]但 start.sh 没有chmod x容器一启动就会报 127。至于排查方法看日志永远是最快的路径docker logs container_id如果日志里没有任何输出退出码又是 0那大概率就是场景一——主进程前台任务缺失。注意docker logs只能看到容器的标准输出和标准错误也就是 PID 1 进程打印到 stdout/stderr 的内容。如果你的服务把日志写到了文件而不是 stdout那docker logs是看不到的。3. 场景二交互式参数缺失——-d与-it的博弈第二个高频场景和第一个容易混淆但成因完全不同。场景一是容器里没有前台进程场景二是你想要的交互式进程因为参数不对而退出了。3.1 问题现象为什么 -d 和 -it 不能随便混用新手常见的操作之一是docker run -d ubuntu /bin/bash然后发现容器秒退。这跟场景一的原理是一模一样的吗不完全是。这里你要看到虽然结果都是 Exited (0)但原因有两个层次如果你不指定-it/bin/bash没有可用的终端stdin 是关闭状态bash启动后立刻发现没有输入源直接退出。即使你加了-i而没加-tbash的行为也可能因为不是交互模式而直接读取脚本逻辑或者直接退出。再来看一个经常被误解的参数组合docker run -d -it ubuntu bash。这个组合没问题-d是后台运行-it是给容器一个伪终端bash获得了终端之后会持续等待命令所以容器不会退出。但问题来了——很多新手以为有了-d就能后台运行所有东西然后不加-it结果命令跑完就退出。3.2 原理解读stdin、stdout 与 tty 的角色我把这几个参数拆开讲你以后就能自己推断了参数作用类比不用的后果-i保持标准输入打开一直往话筒里吹气程序读不到输入可能直接退出-t分配一个伪终端给你一个虚拟屏幕程序可能以为自己在非交互环境行为不同-d后台运行容器把窗口最小化到任务栏不搭配-it时很多交互程序直接用不了-t和-i都涉及一个概念进程的会话环境。很多程序在启动时会检测自己是否连接了一个终端tty。如果检测到就进入交互模式比如bash会显示提示符、等待命令如果检测不到就认为是非交互模式bash会选择读取脚本或直接退出。这就是为什么docker run ubuntu bash秒退而docker run -it ubuntu bash可以一直运行——不是镜像有问题是bash的启动方式变了。3.3 常见反例为什么你的 MySQL/Redis 容器能跑Ubuntu 容器不能跑这个困惑很多新手都有为什么docker run -d mysql能一直运行docker run -d ubuntu就不行原因在于MySQL 的官方镜像把它自己的服务写成了前台启动。我在前文提到容器是否存活只看 PID 1 是否在运行。MySQL 镜像是典型的数据库服务镜像它的主进程是mysqld而官方镜像把mysqld配成了前台运行模式并不是说它真的前台而是它作为 PID 1 不会退出。Ubuntu 镜像则不同它只是一个基础文件系统默认命令是bash没有任何服务在跑。所以容器退出不是Ubuntu 镜像有问题只是它的设计初衷不是作为一个常驻服务镜像存在。如果你需要让 Ubuntu 容器持续运行你有两种思路思路 A启动一个可交互的 shell然后你在里面手动做事——适合调试和学习。思路 B在 Ubuntu 镜像里安装并前台启动你自己的服务——适合准备上线一个自定义服务。3.4 实操建议调试容器时推荐的启动姿势如果你正在折腾一个自定义脚本或者想进容器里看文件、装依赖、跑命令我给你一个无脑保活的组合docker run -d -it --name debug ubuntu bash命令执行完容器乖乖待在Up状态。想进去就docker exec -it debug bash这里面有个考点docker exec -it debug bash和docker attach debug的区别。exec是在容器里新起一个进程attach是连接到容器 PID 1 的终端上。如果 PID 1 是bash用attach会直接连到那个bash的标准输入输出上两者体验很接近但exec更常用因为它不影响主进程的运行方式。注意如果你docker run -d -it --name debug ubuntu bash之后发现容器还是退出了请先执行docker logs debug看有没有输出。如果完全没输出且退出码是 0可能是你的 Docker 版本太老或者宿主机的 tty 分配出了问题。这种情况比较少见但我确实遇到过在极简 Linux 环境比如没有 devpts 挂载的容器宿主机上-t参数无法正常工作的情况。4. 场景三启动失败——报错退出不能裸奔前两个场景中容器退出时退出码是 0代表进程主动结束了。但第三个场景完全不同容器启动时发生了真正的错误进程 crash 掉了退出码非 0。这类问题排查起来依赖日志和系统状态新手第一次遇到往往会一头雾水。4.1 问题现象退出码 1、137、139 各自代表什么我用三个最常见的案例来演示。案例一配置错误导致应用启动失败比如你用 Docker 跑一个 Java 应用docker run -d -p 8080:8080 -e JAVA_OPTS-Xmx512m my-java-app容器秒退docker logs打出来的日志是 Unrecognized VM option 或者 Error occurred during initialization of VM退出码是 1。这就是典型的启动参数错误。Java 的JAVA_OPTS环境变量拼写错了或者值不合法JVM 还没起来就死了。案例二权限问题导致数据库无法写数据比如 MySQL 容器挂载了宿主机目录docker run -d -v /data/mysql:/var/lib/mysql mysql:8.0容器退出了docker logs显示 Permission denied。这是因为宿主机/data/mysql目录的所有者不是 MySQL 容器内的mysql用户MySQL 进程没有权限在这个目录里创建文件。这个问题的本质是 UID/GID 映射问题跟 Windows 上经常遇到的应用程序容器权限或者不可用的 SID错误是一类思路——容器内进程的身份和宿主机目录的权限对不上。案例三内存超限导致 OOM Killed你在一个只有 2GB 内存的小机器上同时跑了好几个 Java 容器其中一个容器退出了docker inspect里能看到退出码是 137并且docker logs里没有任何异常输出。此时你需要查看系统日志dmesg | grep -i oom大概率能看到Out of memory: Kill process的记录。这是因为宿主机内存不够内核的 OOM Killer 把容器进程杀了。137 128 9128 是 Linux 信号退出的基数偏移9 是 SIGKILL 的信号编号。凡是退出码等于 128 信号编号的都表示进程是被信号杀死的。退出码含义常见场景首要排查动作0正常退出前台任务结束检查是否缺少常驻进程1一般性错误应用启动失败/配置错误docker logs看报错126命令存在但无法执行权限不足或缺少可执行位ls -l检查脚本权限127命令不存在路径错误或未安装命令docker logs里会给出 command not found137SIGKILL内存超限被 OOM Killer 杀dmesg看系统日志139SIGSEGV段错误程序本身崩了检查代码/依赖库4.2 排查方法论先看日志再看状态最后看系统我给新手一条通用的三步排查法按顺序执行90% 的问题都能定位第一步看启动日志docker logs container_iddocker logs是这个环节最重要的利器容器 PID 1 进程输出到 stdout/stderr 的内容都在这里。如果你的应用有日志文件但不写 stdout那就需要先想办法让它输出到 stdout或者在容器外部挂载目录读取日志文件。第二步检查容器配置和挂载docker inspect container_iddocker inspect会输出一大段 JSON 格式的容器信息里面有几个字段值得关注State.Status当前状态是 running 还是 exited。State.ExitCode退出码。State.Error如果 Docker 启动过程本身有错误这里会记录。Mounts当前挂载的卷和目录方便检查权限问题。Config.Env容器启动时的环境变量检查参数拼写。NetworkSettings.IPAddress容器的 IP 地址排查网络问题时用。第三步查宿主机系统状态如果退出码是 137或者日志里什么都看不到那大概率不是应用本身的问题而是宿主机的资源限制。检查dmesg | tail -100 free -h df -h分别是查 OOM 记录、查内存、查磁盘空间。资料不足的时候df -h的结果也值得一看——MySQL 容器如果挂载的磁盘满了写不进去数据也可能启动失败直接退出。4.3 典型问题目录权限、环境变量、端口冲突我把实际工作中遇到频率最高的三个启动失败原因单独拎出来讲。目录读写权限问题Docker 容器默认以 root 身份运行除非镜像里指定了 USER。但如果你挂载的是宿主机目录目录本身的所有者可能是另一个 UID。很多镜像比如 MySQL、Nginx会显式或隐式地降权运行——比如 MySQL 镜像内部用mysql用户UID 999运行服务。宿主机目录是 root 所有、权限是 755那容器内的 mysql 用户就写不进去。解决方案有三种宿主机目录直接改成容器内用户所需的权限chown -R 999:999 /data/mysql挂载时使用:Z或:z标签SELinux 环境下或者使用--privileged绕过权限限制不推荐安全风险大。最简单粗暴但安全的方式不要挂载到宿主机目录改用 Docker 命名卷named volumedocker run -d -v mysql_data:/var/lib/mysql mysql:8.0Docker 命名卷会由 Docker 自己初始化目录权限通常能自动解决 UID/GID 不一致的问题。环境变量配置错误很多官方镜像通过环境变量来控制启动行为比如 MySQL 镜像必须设置MYSQL_ROOT_PASSWORD否则会启动失败并提示Database is uninitialized and password option is not specified You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD这种错误信息已经写得很清楚了直接按提示操作即可。还有一类环境变量问题是拼写错误比如MYSQL_ROOT_PASSORD123456镜像不会识别这个变量MySQL 继续因为没有 root 密码而退出。遇到这种问题认真看docker logs的输出通常都有提示。端口冲突导致启动失败还有一类比较隐蔽的问题容器启动时绑定端口结果宿主机上已经有别的进程占用了同样端口。docker run -d -p 8080:80 nginx如果宿主机 8080 已经被一个 Tomcat 占了Docker 会报错Bind for 0.0.0.0:8080 failed: port is already allocated这种错误通常在启动阶段就会暴露容器根本不会进入运行状态。排查方式很简单docker ps -a看不到容器docker logs也没有输出直接检查端口占用netstat -tlnp | grep 8080 ss -tlnp | grep 8080然后把冲突的进程关掉或者改映射端口。4.4 实操记录一次 MySQL 容器启动退出的完整排查过程我拿一个真实的故障案例演示完整排查流程。环境是 Ubuntu 宿主机Docker 版本是 24.0.x。第一步启动 MySQLdocker run -d --name mysql-test -p 3306:3306 -v /opt/mysql-data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD123456 mysql:8.0第二步容器秒退docker ps -a显示状态是 Exited (1)。第三步查看日志docker logs mysql-test输出关键片段[Entrypoint] Database directory is not empty. It contains: - lostfound ... 2024-01-15T08:30:21.123456Z 0 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server (2) and data dictionary (0). 2024-01-15T08:30:21.123456Z 0 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine这是一个 MySQL 8.0 的经典坑宿主机挂载到容器的数据目录之前已经初始化过但初始化时的配置跟现在的配置不一致比如lower_case_table_names参数变了MySQL 拒绝启动。解决方案是清理数据目录重新初始化或者在首次初始化时就把想要的配置写进my.cnf之后不要改。如果是全新环境这个报错不会出现。所以这个案例更想强调的是复用数据卷时别忽视初始化配置一致性这个问题。4.5 避坑心得如何正确阅读 docker logs 的输出再补一个细节很多人看docker logs时只盯最后几行这是不对的。启动失败往往发生在启动早期报错信息可能在日志的中部。建议先把日志完整拉下来docker logs container_id 21 | tail -100因为应用打日志的顺序不一定是从上到下有些日志框架会在启动成功时打一堆 banner然后把失败的栈信息打在最前面。我遇到过一次 Java 应用启动失败日志尾部全是 Spring Boot 的启动 banner真正的错误Nested exception is java.sql.SQLException: Access denied在日志中间位置如果不往上翻页第一眼看过去还以为启动成功了呢。还有应用自身的启动日志如果又臭又长可以先过滤关键错误关键字docker logs container_id 21 | grep -Ei error|exception|fatal|panic5. 实战加固构建不会随便退出的容器镜像前面三个场景解决的是运行容器时怎么避免秒退但如果你自己写 Dockerfile 构建镜像还有一批专门针对 PID 1 的自杀式写法需要避免。我把它单独拎出来是因为很多新手在生产环境部署时写了 Dockerfile结果镜像一构建出来就是跑不起来的状态排查半天发现是 Dockerfile 本身的缺陷。5.1 Dockerfile 中常见的自杀式写法死法一CMD 用了后台运行方式CMD [nginx]Nginx 镜像官方提供的默认 CMD 是CMD [nginx, -g, daemon off;]没有daemon offNginx 会进入 daemon 模式主进程 fork 出 worker 之后自己退到后台。容器 PID 1 是那个已经决定退出的主进程于是一瞬间容器就 Exited 了。同理如果你在容器里跑某个服务而这个服务自己支持-d或者--daemonize之类的参数千万不要在 Dockerfile 的 CMD 里写它因为它会把进程 fork 到后台然后 PID 1 退出容器跟着退出。Dockerfile 里写的所有启动命令必须保证它是前台运行的。死法二shell 脚本没有 exec 关键字很多新手会把启动脚本写成一个 shell 脚本CMD [/usr/local/bin/start.sh]而 start.sh 的内容是#!/bin/bash java -jar /app/app.jar这个写法有个隐蔽的问题java进程是 shell 脚本的子进程shell 会先启动java然后等待它结束java退出之后 shell 也退出。表面上看起来没问题但如果java进程收到信号比如docker stop信号是发给 PID 1 的也就是 shell 进程而 shell 默认不会把信号转发给子进程java结果java没有优雅退出可能产生数据不一致或者清理不完整的问题。更稳妥的写法是用exec让子进程取代 shell#!/bin/bash exec java -jar /app/app.jar这样java进程就成为了新的 PID 1信号可以直接到达容器的生命周期和 Java 进程的声明周期完全一致。死法三ENTRYPOINT 和 CMD 互相理解错误ENTRYPOINT [nginx] CMD [-g, daemon off;]很多人以为这样写等于nginx -g daemon off;但实际行为是如果 CMD 是-g daemon off;那么 ENTRYPOINT 是nginx最终启动的命令是nginx -g daemon off;看起来没问题。可一旦你在docker run的时候追加了其他参数这些参数会覆盖 CMD导致 ENTRYPOINT 变成裸参数docker run -d my-nginx -v此刻实际启动的命令是nginx -v输出版本号后退出。这就是为什么很多镜像设计成ENTRYPOINT [/entrypoint.sh]然后让CMD作为默认参数因为ENTRYPOINT不会被docker run后面的参数覆盖而CMD会被覆盖。5.2 如何设计一个健壮的启动流程我现在写服务镜像的标准模板大概是这样的FROM ubuntu:22.04 # 安装依赖 RUN apt-get update apt-get install -y --no-install-recommends curl ca-certificates \ rm -rf /var/lib/apt/lists/* # 拷贝应用 COPY app /opt/app RUN chmod x /opt/app/start.sh # 暴露端口 EXPOSE 8080 # 启动 ENTRYPOINT [/opt/app/start.sh]其中 start.sh 的要点#!/bin/bash set -e # 前置检查比如等待数据库就绪 /opt/app/wait-for-db.sh echo Service starting... exec /opt/app/my-serviceset -e任何一个命令失败了整个脚本退出避免带病启动。前置检查确保依赖的其他服务已经就绪否则容器照样启动失败。exec让主程序取代 shell 成为 PID 1信号和处理逻辑都干净。5.3 健康检查给容器加一道保险丝加了 HEALTHCHECK 之后容器是否健康就变得可观测了这在编排系统比如 Docker Compose、Kubernetes里有实际意义——调度器可以用健康状态来决定是否重启容器。比如HEALTHCHECK --interval30s --timeout3s --start-period5s --retries3 \ CMD curl -f http://localhost:8080/health || exit 1--interval30s是每 30 秒检查一次--timeout3s是单次检查最长等 3 秒--start-period5s是容器启动后 5 秒内不算失败给应用启动留出缓冲--retries3是连续 3 次失败判定容器不健康。有了 HEALTHCHECK配合 Docker 主机的自动重启策略docker run -d --restartalways --health-cmdcurl -f http://localhost:8080/health || exit 1 --health-interval30s my-app这样即使容器因为偶发故障退出了Docker 也会自动把它拉起来对新手来说是一个非常实用的保险丝。5.4 推荐启动参数清单最后我给所有跑服务的容器总结一套新手友好的参数组合docker run -d \ --name web \ --restartalways \ -p 8080:80 \ -e TZAsia/Shanghai \ --memory512m \ --cpus0.5 \ nginx参数解读--restartalways容器异常退出后自动重启解决秒退造成的服务中断问题。-e TZAsia/Shanghai设置时区很多应用默认 UTC 时间日志跟本地时间对不上很痛苦。--memory512m、--cpus0.5限制容器使用的资源避免一个容器把宿主机内存吃光导致其他容器 OOM。注意--restartalways适合真正的服务进程对于你手动调试的临时容器比如docker run -it ubuntu bash不要加这个参数否则你退出容器之后它还会反复重启烦得很。6. 进阶定位日志之外的五个排查维度到这里三个核心场景已经讲完了。但说实话真实生产环境里的容器启动就退出往往不会这么单纯可能是多个因素叠加。我建议你把排查手段再拓宽一些不要只盯着docker logs和退出码。6.1 检查容器的详细配置docker inspect 使用技巧docker inspect返回的 JSON 很长如果不想看全部可以用 Go 模板语法直接提取字段。比如docker inspect --format{{.State.ExitCode}} container_id提取容器的启动命令docker inspect --format{{.Config.Cmd}} container_id提取容器的入口点docker inspect --format{{.Config.Entrypoint}} container_id提取挂载信息docker inspect --format{{json .Mounts}} container_id | python3 -m json.tool有一次我在排查一个 Redis 容器不断重启的问题用docker inspect发现它的RestartCount已经达到了几十次而每次退出码都是 1。结合docker logs看到的权限报错几分钟就定位了。如果只看docker ps的输出只能看到一个正在运行的容器根本意识不到它已经在后台反复重启几十回了。6.2 容器退出码与 OOM、信号的关系我再深入讲一下信号与退出码的关系。Linux 进程被信号杀死时shell 拿到的退出码是 128 信号编号。常见的信号编号信号编号退出码128编号含义SIGINT2130用户 CtrlC 中断SIGTERM15143正常终止docker stop 默认发这个SIGKILL9137强制杀死OOM Killer 或 docker killSIGSEGV11139段错误看到 137 就知道进程是被强制杀死的如果你没有手动执行过docker kill那大概率是被系统 OOM Killer 杀了。看到 143 就知道是容器收到了 SIGTERM 信号通常是docker stop触发此时进程收到了优雅关闭的机会但它可能因为没能及时清理而直接退出了这不一定是 bug也可能是你的服务没做优雅停机处理。6.3 处理容器自重启与异常循环Restart Count 观测如果你用了--restartalways容器会在崩溃后自动重启。问题是如果镜像里有个 bug容器可能进入启动 1 秒、退出、再重启、再退出的死循环。此时看docker ps是看不出问题的因为容器状态一直显示 Up但实际在反复横跳。我会用下面的命令看容器已经重启了几次docker inspect --format{{.RestartCount}} container_id结合每次的退出时间docker inspect --format{{.State.StartedAt}} container_id docker inspect --format{{.State.FinishedAt}} container_id如果StartedAt和FinishedAt相差只有一两秒而且 RestartCount 不断增加那可以断定这是一个启动即失败的重启循环。6.4 善用 Docker 事件流还有一个比较冷门但好用的命令docker events --filter。它会实时输出 Docker 的事件流包括容器启动、退出、OOM、重启等。排查反复重启问题时特别好用docker events --filter eventdie --since10m这个命令会打印过去 10 分钟内所有容器退出的事件并附带退出码。如果退出码是 137你在这个事件流里会看到 OOM 相关的信息。6.5 使用 docker top 排查运行时状态如果容器已经跑起来了但你想确认它是否真的在正常服务可以用docker top container_id它会列出容器内的进程列表和宿主机的进程 ID 映射。这个命令在排查容器是 Up 状态但服务完全无响应的时候比较有用——有时候容器里 PID 1 还活着但实际上它已经 fork 的子进程全死了docker top可以帮你快速看清进程树是否完整。6.6 系统级排查资源不足导致启动失败前面反复提到了资源限制。如果容器启动就退出且退出码是 137或者在docker run阶段直接报 Cannot allocate memory那是宿主机内存不够了。free -h可以看剩余内存df -h可以看磁盘余量。还有一个容易被忽略的资源是 inodedf -i如果 inode 用完了容器里创建文件也会失败应用可能出现各种莫名其妙的异常最终导致进程退出。7. 系统化预防几条让你少踩坑的发布前检查清单写到这里我想把整套经验沉淀成一份清单。每次构建镜像或部署容器之前照着过一遍能省掉大量无意义的排查时间。7.1 镜像层检查镜像的默认命令是什么它是不是一个前台运行的服务用docker inspect image --format{{.Config.Cmd}}可以查ENTRYPOINT和CMD的搭配是否正确追加参数的场景下会不会失控镜像内是否设置了正确的USER权限是否满足运行目录的写入要求7.2 运行层检查容器启动命令中是否有明确的常驻进程如果没有是不是应该加-it或者改用tail -f /dev/null环境变量是否都拼写正确、值是否合法尤其是数据库类镜像的密码、时区、JVM 参数这类端口映射是否与宿主机已占用的端口冲突挂载目录的权限是否与容器内运行用户的 UID/GID 匹配7.3 策略层检查是否设置了--restart重启策略是 always 还是 on-failure是否符合预期是否设置了资源限制一个 512MB 的容器会不会因为-Xmx1024m直接启动失败是否设置了健康检查HEALTHCHECK的探测接口是否真的存在这些检查项听起来多但实际每一条只需要 1 分钟就能验证。真正费时间的不是检查本身而是一开始没有概念、出了问题后瞎猜乱试。7.4 一些实用的别名和脚本最后分享几个我日常高频使用的小工具命令适合放在 shell 配置里提升效率# 查看所有容器的状态和退出码 alias dpsdocker ps -a --format table {{.Names}}\t{{.Status}}\t{{.ExitCode}} # 查看容器日志的最后 50 行 alias dlogsdocker logs --tail50 -f # 删除所有退出的容器 alias dcleandocker rm $(docker ps -aq --filter statusexited)dclean这条命令尤其适合新手因为调试过程中会产生大量 Exited 状态的残留容器堆着不删不仅看着乱还可能因为容器名冲突导致后续docker run --name报错。8. 最后再分享一点实际排查经验我个人在实际操作中的体会是容器启动退出这个问题写代码写得越少反而越容易定位。真正的高手排查思路大概就是三步先想清楚这个容器的 PID 1 应该是谁然后看他是不是在跑最后看他在退出之前说了什么。大部分问题docker logs一行就能告诉你答案只是有人在慌乱中根本不去看日志直接删容器重来删完还不知道为什么。我建议每个新手在遇到容器启动就退出的时候不要急着docker rm先执行这几个命令docker ps -a docker logs container_id docker inspect container_id --format{{.State.ExitCode}}把这几个输出截图保存或者认真读一遍再决定下一步操作。90% 的情况下答案就在这些输出里。剩下的 10%属于系统级资源问题、甚至 docker daemon 本身的问题这时候再往上查宿主机和 Docker daemon 日志也不迟。这个内容后续还可以这样扩展如果你想深入理解容器的进程模型可以试着用docker stats观察不同容器启动时的资源消耗如果你想走向编排方向可以研究 Docker Compose 里的restart策略和健康检查如何配合调度。但不管怎么扩展容器生命周期的核心就一句话PID 1 活着容器就活着PID 1 没了容器就没了。把这句话刻在脑子里你就能绕开这个坑里最深的那个坎。