企业官网建设流程全解析

我叫它"容器黑洞"——就是那个docker exec -it进去之后，ls命令没有，vim命令没有，连curl都不认识，唯一能用的工具是一个精简到极致的sh或者压根没有 shell。第10章把这部分内容单独拿出来讲，我认为非常有必要，因为现代 DevOps 和微服务开发里，容器交互与调试已经不再是"知道几个命令"就能应付过去的技能，它是一套完整的"如何在一个隔离进程里安全、精准、高效地定位问题"的思维方式。

这篇文章，我会围绕容器交互与调试的完整实操链路展开——从 "为什么 docker attach 容易踩坑" 这种基础直觉，一路讲到 "为什么在容器里装 vim 是一种罪恶"、"为什么 tcpdump 都要精简着用"，最后还会聊一聊调试容器网络时最常见的谜之现象。这篇文章既是给刚入容器坑的初学者掰开揉碎讲原理，也是给有几年经验的工程师当作"排查手册"来翻的。所有内容，我都会用我实际敲过的命令、实际翻过的车来佐证。

1. 容器交互的两条主线：docker exec 与 docker attach 的底层逻辑差异

1.1 docker exec 是"另起炉灶"，docker attach 是"接入现场"

很多初学者有一个根深蒂固的误解：以为docker exec和docker attach差不多，都是"进到容器里操作"。但实际用起来，这两个命令的行为差异会让你栽很多跟头。我用一句话概括它们的关系：exec 是另起炉灶，attach 是接入现场。

docker exec的本质，是在一个已经处于运行状态的容器里，通过 Docker 守护进程的 API 调用，创建一个新的进程，并且把新的进程加入到容器的进程命名空间（PID namespace）、网络命名空间（Network namespace）、挂载命名空间（Mount namespace）等里面去。它不是一个"进入容器"的操作，而是一个"在容器环境中启动一个新程序"的操作。所以当你执行docker exec -it <container_id> /bin/bash的时候，你实际上是让 Docker 在这个容器里跑了一个新的 bash 进程，并且把这个进程的标准输入、标准输出、标准错误跟你当前终端绑在了一起。好处非常明显：这个 bash 进程跟容器原来的 PID 1（即主进程）无关，你在这个 bash 里做的任何操作，包括设置环境变量、启动临时进程、安装临时工具，都不会影响容器本身的主进程状态——除非你主动去 kill 它。

而docker attach呢？它是把当前的终端直接接到容器的主进程（PID 1）的三个标准流上。也就是说，你 attach 进去之后看到的输出，是主进程 stdout/stderr 的输出；你键入的内容，是直接喂给主进程 stdin 的。这就有个致命的问题：如果你在 attach 状态下按了 Ctrl+C，这个信号会直接发送给容器的主进程，而很多容器主进程并不优雅地处理 SIGINT，于是容器直接退出。我见过太多朋友在生产环境里把跑了好几个月的容器给 attach 挂了，就是这个原因。如果你只是想去"看一眼"容器里的情况，永远优先用docker exec，这是我要强调的第一条血泪经验。

进一步拆解的话，docker exec还有一个隐藏的参数设计值得注意：-i和-t是彼此独立的语义。-i（interactive）保持标准输入打开，这样你才能往里面敲命令；-t（tty）则分配一个伪终端（pseudo-TTY），这样命令的输出才会按终端格式排版，比如ls会用多列展示，vim这类依赖终端交互的程序才能跑。如果不加-t，你会发现ls的输出是一行行的裸文件名，颜色、对齐全部丢失，因为进程不知道自己在终端里。检测一个程序是否运行在伪终端下，几乎全靠这个 TTY 标志——很多 CI/CD 系统里跑 docker exec 时经常遇到 "the input device is not a TTY" 的报错，根源就是忘了加-t或者-i。

1.2 进入容器后，环境变量如何继承：注意 exec 的清理机制

很多时候我们exec进去之后发现，"咦，SPRING_PROFILES_ACTIVE 环境变量怎么没生效？"或者 "为什么 /etc/profile 里的 alias 没加载？"这里面其实藏着一个容易被忽略的细节：docker exec里的新进程并不是通过 login shell 启动的，而是继承容器的初始环境变量，并叠加你在 exec 命令中显式指定的环境变量。它不会去读取 /etc/profile、~/.bashrc 这类 shell 配置文件——除非你显式地以交互式登录 shell（比如bash -l）来启动。

所以当你在容器里执行env时看到的变量，其实就是容器被创建时通过docker run -e或者 Dockerfile 里ENV指令注入的那份环境配置；你在 exec 里export的变量，只会对当前这个 exec 会话存在，够不着容器主进程。这一点在调试分布式配置中心、链路追踪 Agent（比如 SkyWalking、Pinpoint）初始化失败的问题时经常会遇到。我曾经排查过一个 Java 应用内存参数老是不生效的问题，后来发现是因为运维同学在docker exec进去后用命令行启动了一个子进程做测试，子进程自己读到了正确变量，但应用主进程根本没收到，因为主进程是容器启动时直接由 CMD 拉起来的。容器进程的环境变量拓扑，是"主进程一份、exec 子进程一份"的平行关系，绝不会自动同步。

2. 调试一个容器的完整排查链路：从 docker logs 到进程级观测

2.1 docker logs 的底层实现与 docker attach 的微妙关系

排查容器问题，第一步永远是看日志。但这个环节，也藏着不少"只知道用、不知道原理"的争议点。docker logs <container_id>输出的是什么？是容器主进程关联的标准输出（stdout）和标准错误（stderr）的内容。关键点在于，Docker 的日志驱动（logging driver）会在进程写出这些流时截获并重定向到宿主机上的日志文件中（默认是 json-file，位于/var/lib/docker/containers/<container_id>/<container_id>-json.log），这就是为什么你docker exec进去看 /var/log/ 下老是没有动静的根源——容器应用如果直接把日志写进了文件，而不是 stdout/stderr，那么 docker logs 什么都看不到。

这一点在调试运行在 Kubernetes 里的容器时尤其重要，因为kubectl logs调用的底层机制和docker logs完全一样，只跟随容器主进程的 stdout/stderr。如果你在代码里用了 Log4j2 的 File Appender，或者输出到文件系统的 Nginx access_log，在紧急排查的时候会误以为"容器没日志"，实际上日志都在磁盘里。所以设计一个"符合容器哲学"的应用，第一件事就是把所有日志打到 stdout 和 stderr 去。

很多人在使用docker logs -f时一旦连接断开，会以为日志漏了。要纠正这个预期：docker logs 默认读的是日志文件，就算你的-f追踪断开了，重新连上再去读，之前的内容都还在。真正的问题是日志轮转——默认 json-file 日志驱动不会自动轮转，如果不加--log-opt max-size=10m --log-opt max-file=3这类参数，一个长时间运行的容器可能把宿主机的磁盘撑爆。我自己的服务器上就因一次漏配日志轮转，导致容器目录吃掉了70多G空间。排查方法也简单，用du -sh /var/lib/docker/containers/*/按目录大小排个序就一清二楚。

docker logs还有一个隐藏功能——--since和--until时间窗口过滤。我经常用它来追"昨晚3点到3点半到底发生了什么"，比 grep 整份日志高效得多。不过它依赖 json-file 驱动的时间戳字段，如果你的自定义日志每一行都没有时间戳，这个参数的意义会大打折扣。

2.2 docker top / docker stats：用宿主机视角看容器进程

登录到容器内部用ps命令，你会发现一个有趣的现象：ps显示的进程列表跟宿主机上的进程列表高度重合——这不是幻觉，而是因为 Linux 的 /proc 文件系统是挂载在 PID 命名空间里的，容器内的 PID 1 在宿主机上可能是一个几百甚至上千的编号。这样你就会面临一个问题：宿主机和容器内的 PID 对不上号，排查起来两头懵。

好在这个问题 Docker 官方已经给了解决工具，就是docker top <container_id>。它的原理是直接读取命名空间内的进程表，并把容器内 PID 和宿主机 PID 做一个双向映射展示。我曾经在一个容器里跑了一个 Node.js 应用，它 fork 出了8个子进程，其中一个子进程把 CPU 吃满了，但容器内我找不到它对应的宿主机线程，后来用docker top对照top -Hp才定位到具体线程 ID。我一直认为 docker top 是容器调试中性价比最高的命令，没有之一——你几乎不需要任何额外工具，就能拿到"容器内PID -> 宿主机PID -> 启动命令"的关键链路。

docker stats则更偏向资源占用观测。它会主动连接 cgroup 文件系统，读取容器的 CPU、内存、网络 I/O、块 I/O 数据。要注意的是，默认docker stats展示的内存使用量包括 page cache，所以某些内存型应用（如 Redis、MySQL）看起来内存占用奇高，不要急着下结论，先看缓存是否可回收。docker stats的实时刷新率也可以定制，默认是1秒，加--no-stream可以只取一次快照，这在脚本监控场景里比实时刷新更实用。

2.3 docker inspect：结构化地拆解容器的真实状态

如果说docker logs是"看症状"，docker inspect就是"看病例档案"。它会把容器的完整配置、状态、挂载、网络、资源限制等以 JSON 格式输出。我平时排查疑难杂症时，docker inspect几乎是必用的，下面几个字段是最常查的：

• .State.Status: 容器运行状态，注意区分running、restarting、paused、exited、dead。
• .State.ExitCode: 上一次退出码，0 是正常退出，137 代表被 SIGKILL 杀掉，143 代表被 SIGTERM 杀掉，130 则是 Ctrl+C（SIGINT）最常见。
• .RestartCount: 重启次数，如果这个数字在不停增长，说明容器在进入崩溃循环。
• .NetworkSettings.IPAddress: 容器当前的 IP 地址，不过需要注意的是，在用户自定义的 bridge 网络里，这个 IP 可能不是唯一入口，要结合网络别名和 service name 看。
• .Mounts: 挂载点的源路径、目标路径和读写权限，排查"为什么容器里改了文件宿主机没变"这类问题特别有效。
• .Config.Env: 启动时的环境变量快照，用于对比运行时是否传入了错误配置。
• .HostConfig.Privileged: 是否以特权模式运行，很多容器内权限报错都源于这个字段。

有人会问，docker inspect输出太冗长了，有没有办法只取我要的字段？有。用 Go template 语法，比如docker inspect -f '{{.State.Pid}}' <container_id>可以直接取到容器主进程在宿主机上的 PID。这是一个非常实用的小技巧，尤其在你要把"容器内的端口状态"和"宿主机的进程网络栈"做映射时。配合nsenter命令，甚至可以不用安装 nsenter 镜像，直接在宿主机进入某个容器的命名空间执行任意命令。这在容器里连/bin/sh都没有的场景（比如 distroless 镜像）下，简直是救命稻草。

3. 容器网络调试与端口排障：三个最容易忽视的坑

3.1 为什么在容器里 localhost 不通，以及 bridge 网络的原理

进入容器交互会话后，很多人的第一个网络测试就是curl http://localhost:8080。如果你的容器跑的是默认 bridge 网络，并且服务监听在0.0.0.0:8080或者127.0.0.1:8080，通常能通。但一旦你的服务监听在特定网卡（比如容器的 eth0 的 IP）上，localhost 就不通了。本质上，容器内观察到的 localhost 是容器自己的 lo 接口，和宿主机上的 lo 接口完全隔离，宿主机的监听端口不会镜像到容器内的 localhost 上。所以"我在宿主机上能 curl，进了容器反而不通"是非常正常的事情，别急着怀疑网络被防火墙拦截。

更常见的坑，是端口映射的代理地址。默认情况下docker run -p 8080:80会把宿主机的所有网卡（0.0.0.0）上的 8080 端口转发到容器的 80 端口，这是通过 docker-proxy（一个用户态进程）和 iptables DNAT 规则共同完成的。当你从宿主机 curl 127.0.0.1:8080 时，实际上流量经过了 docker-proxy 或 iptables，能不能通取决于内核参数和防火墙链的配置。很多人在宿主机上启用了 firewalld，但给 docker0 和容器网段的流量设置的规则是 DROP，导致从外部访问容器端口全失败。这个坑我踩过之后，就养成了一个习惯：排端口映射问题先看宿主机 iptables 的 FORWARD 链，再看容器内服务的监听地址，两个条件缺一不可。

3.2 容器内没有网络工具时，如何做最小化网络诊断

如果你exec进的是一个精简镜像，比如基于scratch或者alpine（未安装完整包），你会发现想跑curl、ping、telnet、nc全都提示 command not found。这种情况下，我有几个非常高效的替代方案：

• 查看/proc/net/tcp和/proc/net/udp来判断端口监听状态。这两份文件是内核直接导出的 TCP/UDP 连接表，我写过一个小脚本，用cat /proc/net/tcp加awk过滤，就能在完全没有 netstat 的情况下看到端口监听情况。注意里面 IP 和端口都是十六进制表示的，比如0100007F:1F90表示 127.0.0.1:8080。
• 用/dev/tcp这个 bash 内置特性做 TCP 连接测试。exec 3<>/dev/tcp/127.0.0.1/3306可以在一个文件描述符上建立 TCP 连接，echo >&3发送数据，cat <&3读取响应。这个技巧在容器里没有 nc 时非常好用，而且不需要任何额外工具。
• 如果你连 bash 也没有，那可以尝试在宿主机用nsenter进入容器的网络命名空间，然后用宿主机的网络工具（比如curl、ss、ip）来诊断。命令大致是nsenter -t $(docker inspect -f '{{.State.Pid}}' <cid>) -n ss -tlnp，这条命令能直接以容器网络的视角列出监听端口，对我来说已经属于日常操作级别。

另外要提一句，很多人一遇到容器网络问题就下意识 ping 一下，但容器里的 ping 依赖 ICMP 协议，而默认 bridge 网络下容器对外的 ICMP 可能被主机防火墙过滤。"ping 不通" 绝对不能等价于"网络不通"，尤其当你要连的是 3306、6379、9200 这类业务端口时，最直接的验证是 TCP 连接测试，而不是 ICMP。

3.3 调试容器间的域名解析：/etc/resolv.conf 与 Docker 内嵌 DNS

在一个自定义 bridge 网络中，Docker 会内嵌一个 127.0.0.11 的 DNS 服务，容器内的 /etc/resolv.conf 会被自动改写为指向这个地址。它的作用是做容器名的解析——通过同一个 docker network 里的别名（alias）或者--network-alias来互相访问。但你创建容器时如果用了--dns参数覆盖了默认 DNS，或者把新容器连接到一个已有网络，就会出现"明明在一个网络里，却解析不了对方容器名"的情况。

我自己遇到最经典的一次问题是：A 容器连接了 B 容器所在的 network，但 B 容器启动的时候并没有--network-alias配置，于是 A 容器里ping b_container_name怎么都不通。后来发现，自定义网络中 Docker 是将容器名解析为每个容器在该网络的 IP，但只有同时连接到这个网络的容器才具备这个解析能力。如果你用的是docker run --link这种旧式关联，在新版本 Docker 上虽然还在用，但已经被标记为遗留功能，很多 DNS 相关的行为会和自定义 network 不一致。所以我的建议是，调试跨容器访问之前，先确认两边都在同一个用户自定义网络里，并且用docker network inspect验证容器的 IP、别名和 DNS 配置是否如预期。

4. 在容器里做应用级交互调试：从环境变量到实时跟踪

4.1 环境变量注入的优先级：命令行、Compose、还是 Dockerfile？

容器交互调试时，最频繁的操作之一就是修环境变量。因为容器是典型的不可变基础设施，改配置文件不如改环境变量来得干净。但环境变量本身的注入来源和优先级，恐怕不是每个人都说得清楚。我按实际生效顺序总结如下：

1. 通过docker run -e或者 compose 文件的environment:段传入的变量，优先级最高，会直接覆盖 Dockerfile 里ENV指定的同名变量。
2. Dockerfile 里的ENV指令声明的变量，优先级其次。如果你在docker run里没给同名变量，就用这里的值。
3. 镜像构建时ARG声明的构建参数，只有在构建阶段暴露给 RUN 指令，对运行阶段完全不可见，除非你把它赋值给 ENV。

这个顺序的坑在于，许多人会在 Dockerfile 里写ENV JAVA_OPTS="-Xmx512m"，但忘记了运行时已经通过编译平台的默认参数注入了另一个 JAVA_OPTS，导致内存配置"看起来没生效"。排查这类问题时，最快的手段是docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}' <container_id>——一次性把所有运行时环境变量打出来，不用进容器。另一种更符合容器哲学的做法是，在docker run里临时覆盖变量并启动一个新容器，在相同镜像下做对比验证：比如docker run --rm -e JAVA_OPTS="-Xmx1g" -it my_image env | grep JAVA_OPTS，看到输出即刻关闭，绝不会污染你的原容器。

4.2 容器与宿主机之间的文件交互：拖文件进出的正确姿势

容器交互调试中，还有一个高频需求：把宿主机上的调试包、JAR 包、崩溃现场 dump 文件拷贝进容器，或者把容器里的日志、堆转储文件拉回宿主机分析。最直接的命令是docker cp。它支持从宿主机拷入容器：docker cp ./app.jar <container_id>:/tmp/，也支持从容器拷出：docker cp <container_id>:/var/log/app.log ./。

docker cp的机制比较朴素，直接通过 Docker API 在容器文件系统和宿主机文件系统之间复制文件，不需要容器里安装任何服务端工具。它的一个特性是，如果容器正在运行，你会拿到该文件此刻的瞬时状态，等于"活体取样"；如果容器已停止，你依然可以拷贝，因为文件系统层还存在。这个特性在做故障复现时特别好用——挂掉的容器我也可以把里面的配置拉出来看，不需要把它启动起来。要注意的是，docker cp默认的属主和权限处理有时候不那么符合直觉，拷入容器的文件经常变成 root:root 或保留原 uid，如果你在容器内用非 root 用户跑应用，还需要chown或者通过exec进去调整权限。

除了docker cp，还有一层比它更底层的交互逻辑：挂载卷（volume）和 bind mount。如果你在设计阶段就知道某个目录需要经常交换文件，那就直接把这个目录挂载到宿主机的一个指定路径，这是效率最高的做法。不过挂载卷有个双刃剑效应——权限映射问题。容器内 uid 和宿主机 uid 经常不一致，导致写文件时出现 "Permission denied"。处理办法是让容器内进程以宿主机的特定 uid（比如 1000）运行，或者在宿主机上 chown 对应目录归属。这属于容器设计层面的交互策略，而不是临时调试手段。

4.3 在跑起来的容器里临时装调试工具：合适吗？

很多人一遇到容器里缺工具，第一反应是apt-get update && apt-get install vim。我的观点很明确：在生产容器里，尽量不要这么干。原因有三：

1. 你安装的包会临时写到容器的可写层，增加容器的文件系统体积和配置漂移风险。下一次容器重建，这次安装的包就全部消失，这是一种"伪持久化"。
2. 很多生产容器镜像基于极简基座，比如 distroless、alpine 的瘦身版，根本没有 apt/dpkg 可用，你强行apt-get只会收获一行sh: apt-get: not found。
3. 容器的不可变性和审计要求决定了，临时安装工具会让运维同事在复盘时完全无法还原现场。

那调试需要工具怎么办？我有几套替代方案：

• 使用docker run --rm -it --network container:<target_container>启动一个带全套诊断工具的临时容器，连接目标容器的网络命名空间。这样你的临时容器可以共享对方的网络视角，用nmap扫端口、用curl发请求，而目标容器本身保持干净。
• 使用docker run --rm -it --pid container:<target_container>进入目标容器的 PID 命名空间，此时你可以用ps看对方进程，用strace -p附加到对方的进程做系统调用跟踪——这个操作亲测非常有用，尤其是在定位应用卡死、进程挂起这类疑难问题时。
• 利用nsenter在宿主机上直接进入容器的 mount namespace 和 PID namespace，借助宿主机的调试工具链来完成操作。

回想我自己的一次生产事故排查：一个 Java 服务在容器里频繁 Full GC，jstat 无法使用（容器里没装 JDK），我正是用上述第三种方式——在宿主机上用nsenter进入容器的 PID namespace，然后直接用宿主机的jmap（版本匹配）抓堆。整个过程没有对容器做任何一字节的写入，唯一记住的是，容器和宿主机之间，namespace 是一道墙，但这道墙的钥匙其实就在 Docker 命令行和 nsenter 里。

5. 容器生命周期与状态机：为什么容器会停下来、退出码告诉你什么

5.1 退出码背后的信号学：退出137与强制杀死，退出143与优雅停止

排查一个反复退出或者陷入 CrashLoopBackOff 状态的容器，退出码是第一手信息。这里我整理一份常用退出码对照表，它是我处理容器故障时反复查的表格：

137 这个退出码尤其要警惕。很多人看到 137 以为是 OOM（内存溢出）导致的，但 OOM 通常会在 dmesg 或者/sys/fs/cgroup/memory.events里留下记录，而且容器退出码确实是 137。但如果宿主机被调度器因为磁盘、CPU 或内存压力主动 kill，退出码同样是 137。所以一个稳妥的确认方式是docker inspect看.OOMKilled字段——如果为 true，基本可以断定是容器内存超限。如果为 false，再看宿主机的 system log 或者主机的 dmesg，确认是否有 cgroup 或节点层的回收动作。任何一个退出码，都要结合日志和宿主机状态综合分析，单看退码下结论极易误判。

5.2 负责任地停止一个容器：SIGTERM 宽限期与 SIGKILL 兜底

容器调试中，很多问题的根源其实是对"停止容器"这个动作的不理解。docker stop默认行为是：先向容器主进程发送 SIGTERM，然后等待容器退出；在指定的停止超时时间（默认10秒）之后，如果容器还没有退出，再发送 SIGKILL 强制杀死。这个超时时间可以用-t参数调，比如docker stop -t 30 <container_id>。

这就带来一个交互调试的经典难题：你的应用在收到 SIGTERM 后，有 10 秒时间做清理动作（比如关闭数据库连接池、持久化缓存、释放端口），但如果你的应用根本没实现信号监听，那 SIGTERM 就等于什么都没发生，直到超时被 SIGKILL。结果就是容器退出码变成 137，而不再是预期的 15 或 143。排查的时候，如果发现"我明明docker stop了为什么容器是 137"，先别怀疑 Docker，去查你应用有没有真正处理 SIGTERM。

从另一个角度，Kubernetes 里的 pod 删除也会经过类似流程：kubelet 先发 SIGTERM，宽限期（terminationGracePeriodSeconds，默认30秒）过了就 SIGKILL。所以容器交互调试的能力，直接决定了你能否让云原生环境里的服务做到"优雅停机"。我自己就见过不少服务因为没处理 SIGTERM，导致每次发布都出现短时间 5xx 错误——其实是在强制 kill 的瞬间，已有的请求还没来得及返回。

5.3 容器重启策略：docker restart 与 --restart 的差别

调试容器时，很多人会遇到"明明我 restart 了，为什么配置没生效"的困惑。这里要分清两个概念：docker restart <container_id>是停止容器再启动容器，宿主机上的容器配置（比如环境变量、挂载点）不会重新读取，它只会把同一个容器的文件系统、网络配置和启动命令重新执行一遍。

而--restart策略（比如--restart=always、--restart=on-failure:5、--restart=unless-stopped）是 Docker 守护进程级别的自动重启策略，它会根据退出原因决定是否拉起容器。这里有一个很多人踩过的坑：当你对正在运行的容器执行docker stop时，即使设置了--restart=always，容器也不会被自动重启，因为 Docker 将"手动 stop"视为主动操作，明确排除在自动重启之外。但是，如果容器是因为崩溃（非0退出码）退出的，--restart=always就会立刻拉起它。这个语义差异在容器交互调试时特别重要——如果你怀疑容器没有自动恢复是因为没配--restart，先看看是不是手动 stop 导致的"误判"。

6. 进阶调试姿势：从容器视角进入底层，把 Namespace 变成利器

6.1 利用 nsenter，在宿主机直接操作容器的 Namespace

前面多次提到 nsenter，这里我专门完整演示一下。nsenter 是一个 Linux 原生命令，作用是把当前进程加入到指定进程的命名空间里。结合 Docker 提供的容器 PID，我们可以在宿主机上直接对容器进行"降维打击"式调试，完全绕开容器内工具缺失的问题。

常用组合之一：进入容器的网络命名空间，查看监听端口和网络状态。

# 获取容器主进程在宿主机的 PID pid=$(docker inspect -f '{{.State.Pid}}' <container_id>) # 进入该容器的网络命名空间，执行 ss 命令 nsenter -t "$pid" -n ss -tlnp

-t指定目标 PID，-n指定进入网络命名空间。这样ss看到的就是容器网卡的监听情况。比如容器内服务端口是 8080，但你在宿主机上怎么都连不上，就可以先用这条命令确认容器内是否真的在监听，再排查端口映射。

常用组合之二：进入容器的 PID 命名空间，查看完整进程树。

nsenter -t "$pid" -p ps -ef

这在你需要确认容器内到底跑了几个进程、主进程是否还活着、有没有产生僵尸进程时非常有用。容器里的僵尸进程（Zombie）问题，是容器化应用最容易忽视的深水区，因为它不会直接导致宕机，但会积累出资源泄漏。很多 Java 程序 fork 出的子进程没有正确 reap，进入容器里ps一看全是<defunct>，这就是没有专门的 init 进程（比如 tini、dumb-init）来清理僵尸导致的。

常用组合之三：进入容器的挂载命名空间。不过这个操作对生产环境有风险，建议只在分析镜像内容时使用：

nsenter -t "$pid" -m ls /usr/local

挂载命名空间的切换意味着你可以看到容器视角的文件系统结构，但它不像 IPC、网络 namespace 那么"无害"——如果宿主机上的进程通过这种方式直接写容器文件系统的文件，可能会绕过容器镜像的层管理，打破"不可变容器"的假设。建议平时用docker exec就好，除非容器里完全没有 shell 才考虑这种方式。

6.2 镜像调试"死容器"：docker run --rm 启动一个临时副本

有时候我们拿到一个容器的状态是而已"退出"，想看看里面到底装了什么环境、有什么文件，但又不希望动到原容器。这时可以用docker run --rm -it --entrypoint /bin/sh <image_name>临时启动一个基于同一镜像的新容器做探索。

把这个技巧做进一步扩展，可以用它来做差异对比：比如 A 环境报错，B 环境正常，怀疑是镜像版本问题，分别基于两个镜像启动临时容器，对比里面的/etc/app/config.yml、/usr/local/lib的库文件列表，再用diff -r做差异分析。这种"临时副本"式的调试方式，干净、隔离、不产生遗留，非常适合在交互调试阶段频繁使用。

要注意的是，如果目标镜像的入口脚本本身包含了启动逻辑，并且你不想执行它，就一定要用--entrypoint覆盖默认入口，否则docker run还是会执行镜像的 CMD。一个我常用的覆盖写法是：

docker run -it --rm --entrypoint /bin/sh nginx:latest # 进去以后随便翻，nginx 进程不会起来，但 /usr/share/nginx/html 都能看到

这样调试静态资源配置文件的生效情况特别清晰。

6.3 构建与运行的交互鸿沟：为什么 Dockerfile 里能跑，容器起来就崩

最后一类非常典型的"容器交互与调试"难题，是镜像构建阶段（build）正常，运行阶段（run）却崩溃。这个阶段的知识基本上属于容器的"系统级别交互"。原因通常可以归为几类：

1. 构建时依赖了构建上下文或网络，比如RUN curl了一个动态版本号的文件，但运行时下载不到同一版本。也就是"构建态可重复性"没有保障。
2. 运行时依赖了宿主机资源，比如容器内的服务绑定 CPU 核心数，但宿主机 cpuset 只给了1个核心，应用初始化就失败。
3. 权限模型差异，比如容器内以非 root 用户运行，但尝试绑定 80 端口。小于 1024 的端口需要 root 权限，这在容器里同样适用。解决办法是加NET_BIND_SERVICE能力或者直接映射高端口。
4. 挂载目录覆盖问题，宿主机挂载了一个空目录到容器内的数据目录，导致容器启动时找不到数据文件。这种情况比较隐蔽，因为docker logs往往只会透出一点点错误，而docker inspect的 Mounts 字段能让你一眼看到"挂载源是宿主机空目录"。

也正因为这些问题，我养成了一个习惯：每次拿到新镜像，第一步不是docker run，而是docker history看构建记录，docker inspect看镜像暴露的端口、Entrypoint、CMD 和环境变量。把容器当成一个可以拆解的"电子设备"，读清文档再通电，能少踩很多雷。

7. 容器调试常用命令速查与习惯养成

7.1 几条值得刻进肌肉记忆的命令

指令集不在多，在精。我把自己常用的容器交互与调试命令整理成下面这份速查清单，覆盖了80%以上的场景：

把这张表存成笔记，日常调试基本可以脱离"现查百度/谷歌"的状态。

7.2 从"能连上"到"能定位"：建立一套属于自己的容器问题排查SOP

经验最值钱的部分，不是某个命令怎么用，而是排查问题的顺序。我个人的容器交互调试 SOP 大致是四步：

1. 定性：看状态、看退出码、看重启次数，用docker ps -a和docker inspect确定问题类型——是启动失败、运行崩溃，还是资源枯竭。
2. 看日志：用docker logs --tail=200看最近日志，如果有-f跟进持续观察。关注关键词，比如 "Exception"、"Error"、"panic"、"OutOfMemory"、"Connection refused"。
3. 查环境：确认环境变量、挂载目录、网络配置是不是和预期一致，利用docker inspect里的.Config、.HostConfig、.Mounts快速比对。
4. 进现场：如果前三步还不够，再用docker exec或nsenter进入容器查看进程列表、监听端口、文件系统内容，必要时借助临时调试容器、strace、tcpdump 做深层次分析。

这套流程我用了很多年，唯一一次翻车是在"看日志"这个环节——因为应用把日志同时写文件又打 stdout，而docker logs只提供了 stdout 的部分，导致我第一次误判进度。后来我在日志采集的源头就约定了一个规则：容器内应用只允许用 stdout/stderr 打日志，任何文件日志都要通过 stdout 重定向或者 sidecar 方式采集。这样做的收益在调试阶段是完全值得的。

7.3 容器交互调试的终极习惯：优先考虑不可变性与可复现性

如果让我总结这些年容器调试经历中最重要的一个认知转变，那就是：不要依赖"把容器改好"，而要追求"把容器重建好"。一个典型例子是，当你在容器里通过apt-get install装了个调试工具，确实解决了眼前的问题，但这个工具在下次重建容器后就会消失，如果当时没把修复方案沉淀到 Dockerfile 或启动脚本里，下次遇到同样问题还得再装一次，这是一种隐性技术债。更稳妥的方式是，把所有调试得到的修复措施，回写到代码、配置和镜像构建流程里，让"交互调试"成为"设计方案"的前置验证，而不是终点。

所以在每次完成容器交互与调试工作后，我会强制自己做一次记录：本次容器里改了什么、临时补了什么、最终哪条命令或配置是"治本"手段。这些记录积累下来，其实就是团队内部最能落地的容器运维知识库。毕竟，真正的高手不是能进容器，而是知道进了容器之后该做什么，以及做完了之后该怎么把现场还原成干净状态。