企业官网建设流程全解析

Docker 装好之后，很多人第一反应是敲docker ps看看跑起来没有，紧接着就会卡在下一个问题上：容器明明在跑，可我想进去看看里面长什么样、配置文件在哪、为什么日志没输出。这时候就需要"进入容器"这个动作。这篇是小白实操入门系列的第五篇，专门讲 Docker 容器到底怎么进、用哪条命令进、进去之后能干什么、进不去又该怎么办。容器（Container）本质上是被人为隔离起来的一组进程，不是一台可以随手远程登录的虚拟机，这个认知差直接决定了进入容器的全部操作逻辑。不管你是在 Windows 上刚装完 Docker Desktop，还是在 Linux 服务器上已经跑着几个服务，只要碰到过docker exec报错、attach之后手一抖把容器弄挂的情况，下面的内容都能给你一套可以直接照抄的答案。

1. 进入容器前，先把观念掰正

1.1 容器不是小号虚拟机，别拿登录服务器的思维套它

新手最容易掉进的坑，是把容器当成一台缩小版服务器，觉得它跟云主机一样，有独立的系统内核、有开机自启的服务、有可以随便改的 root 密码。实际完全不是这么回事。容器共享宿主机的内核，镜像里只有一小撮被裁剪过的用户空间文件，一个典型的alpine镜像解压出来也就五六兆，里面连netstat、vim这些常用工具都未必有。你在容器里ps aux看到的进程数量往往个位数，因为绝大多数系统级的守护进程压根不存在。

这个差异带来的直接后果是：进入容器之后能做的事情，比你在虚拟机上做的事情少得多。没有 systemd 就没有systemctl，没有包管理器镜像源就装不了软件，没有 shell 的镜像（比如某些只放了二进制的 distroless 镜像）你连"进去"这个动作都做不了。所以判断一个容器能不能进，第一件事是看它的镜像里有没有一个可用的 shell。有/bin/bash、/bin/sh、/bin/ash其中之一，基本就稳了；只有二进制的镜像，那就得换思路，后面会讲到。

另一个常见误解是"进去改完配置就永久生效了"。容器是分层的，你在运行中的容器里改文件，写的是容器自己的可写层，容器一删这层就没了，基于同一个镜像重新跑一个新容器，改动全消失。真要持久化，要么挂载卷，要么改 Dockerfile 重新构建镜像。我见过不少人兴冲冲进容器改了半天配置文件，重启容器后发现全部回到原样，白忙一场。把这一点刻进脑子里，能省下大量无意义的重复劳动。

1.2 三种进入方式，能力边界差别很大

能进容器的方式主要有三类，它们看上去都是"打开一个终端",但底层机制和适用场景完全不同。

第一类是docker exec，在已经运行的容器里额外启动一个新进程，通常是启动一个 shell。它是目前唯一推荐的日常交互方式，因为进去、退出都不影响容器主进程，也不会破坏容器的运行状态。你在里面开的 shell 是容器内的第 N 个进程，跟容器主进程是"同事"关系，不是"父子"关系。

第二类是docker attach，把宿主机的终端直接接上容器主进程的标准输入输出流。听起来很直接，问题在于它接的是主进程本身，你在终端里敲的字符会被送到主进程的 stdin，你按Ctrl+C发的是中断信号，很可能直接把主进程干掉了，容器跟着退出。所以attach只适合那些本来就以交互为主、需要你实时喂输入的容器，比如临时跑个 Python 交互式解释器。

第三类是通过 Linux 命名空间直接切入，典型代表是nsenter。它绕过了 Docker 客户端和守护进程，直接拿着容器的进程 ID 去进它的 namespace。这条路的优势是即使容器极度精简、连 shell 都没有，只要宿主机上有工具，你依然能"钻"进去看看网络、挂载点、进程。代价是命令长、依赖宿主机权限、容易误操作，属于排障兜底手段。

把这三条路记成一棵决策树：日常调试走exec，需要接管主进程交互走attach，命令都执行不了时用nsenter兜底。

2. docker exec 全参数拆解与选型逻辑

2.1 基本语法和几个改变体验的参数

docker exec的核心语法就一句：docker exec [选项] 容器名或容器ID 要执行的命令。乍看简单，但选项写不写、怎么写，直接决定你是"敲一次就通"还是"反复报错"。

最常打交道的三个参数是-i、-t和-d。-i表示保持标准输入打开，没有它你没法往容器里输入任何字符；-t表示分配一个伪终端，没有它命令虽然能跑，但提示符不会出现，输出格式也会乱掉；-d表示把命令放到后台执行，不占用当前终端。日常最常用的组合是-it，也就是同时开启交互和终端。

还有几个偏进阶但很实用的参数。-u指定以哪个用户身份执行命令，默认是镜像里配置的 USER，很多时候是 root 也可能是某个普通用户，进去发现没权限改文件，往往就是这里的问题。-w指定工作目录，等同于进去之后先cd到某个路径。-e用来临时注入环境变量，只在这一次 exec 里生效，不污染容器本身的环境。--privileged会给进程加上特权模式，能访问宿主机设备，除非在做底层排查，否则不要随手加。

这里有个容易忽略的顺序问题：所有选项必须写在容器名或 ID 之前，容器名之后的部分全部被当作"要在容器里执行的命令"。写成docker exec 容器名 -it bash会报错，因为 Docker 会把-it当成容器里要执行的命令去找，自然找不到。这个报错信息一般比较直白，但新手不知道原因时会反复试，记住"选项在前，容器在中，命令在后"这条线就不会错。

2.2 -it 这两个字母到底在干什么

很多人天天敲-it，但从没想过它为什么必须成对出现。拆开看，-i的作用是让容器内的进程和你的终端之间保持一条输入通道。没有-i，Docker 会把标准输入接到 /dev/null，你敲的字符根本传不进去，shell 启动后会立刻发现读不到输入而退出。

-t的作用是分配一个伪终端设备（pseudo-TTY）。终端这东西在操作系统里是有具体数据结构的，它负责处理回显、行缓冲、控制字符（比如退格键、上下方向键）。少了-t，你敲命令可能看不到自己输的字符，输出的表格也会挤成一团，vi、top这类全屏交互程序会直接罢工。

两个参数各自的定位就是这么清晰：-i管输入能不能进去，-t管界面好不好用。想验证也很简单，只加-i不加-t，你会看到一个能输入但没有任何提示符的诡异画面；只加-t不加-i，提示符出现了但敲什么都没反应。这两个我都在早期踩过，确认过才明白为什么标准写法永远是-it。

有一点要说明：-it组合虽然通用，但并非所有场景都需要。如果你只是要在容器里跑一条命令然后把结果打出来，比如docker exec 容器名 cat /etc/hosts，不需要交互也不需要终端外观，不加-it反而更干净，输出可以直接被脚本解析。

2.3 换用户、换目录、带环境变量再进去

真正干活的时候，默认的docker exec -it 容器名 bash往往不够用，下面这三种变招要熟。

第一种是切用户。有些官方镜像默认用非 root 的用户跑，进去之后想在/etc下改文件会被拒绝。这时可以显式指定用户：docker exec -it -u root 容器名 bash。反过来，如果你以 root 进去想验证普通用户视角的权限问题，也可以-u 1000换成 UID 1000 的用户。以 UID 而不是用户名来指定，在镜像里没有配置/etc/passwd条目时尤其有用。

第二种是直接定位到工作目录。服务类容器的配置文件通常散在/app、/opt、/usr/src这类路径下，每次进去都要cd好几层实在麻烦。用-w一步到位：docker exec -it -w /app 容器名 sh。进去就已经在目标目录，配合ls立刻就能看文件。

第三种是注入临时环境变量。调试程序对某个变量的反应时，没必要去重建容器，直接docker exec -it -e DEBUG=1 -e LOG_LEVEL=debug 容器名 sh，然后在这个 shell 里启动你的程序，它会继承这两个变量。这个技巧我用来排查配置读取顺序的问题特别顺手，因为改动只影响当前这一次执行，验证完退出即可，不留下任何痕迹。

需要注意，-e注入的变量只对这次 exec 启动的进程及其子进程有效。如果你在 shell 里再sudo切换用户，环境变量有可能被重置，这一点跟 Linux 本身的 sudo 行为一致，不属于 Docker 的坑。

3. 手把手实操：从起容器到进容器

3.1 准备一个干净的测试容器

下面这套流程我在好几台机器上跑过，一步一步来就行。先拉一个带完整 shell 的镜像，alpine体积小、有/bin/sh，非常适合练习：

docker pull alpine:3.19 docker run -d --name demo-box -p 8080:80 alpine:3.19 sleep 3600

这里特意用了sleep 3600作为主进程，原因是容器的生命周期完全绑定在主进程上，主进程一结束容器就退出。如果直接跑alpine不加任何命令，它会立刻退出，你根本来不及进。用一个长睡眠把容器"钉"在运行状态，是新手练习时最常见也最实用的手法，很多教程demo都用这一招。

跑起来之后确认状态：

docker ps

输出里能看到demo-box这一行，状态是Up，端口映射是0.0.0.0:8080->80/tcp。端口这块顺便说一句，-p 8080:80表示宿主机 8080 映射到容器内的 80，左边是宿主机，右边是容器，顺序千万别写反，写反了容器里的服务外面访问不到，排查半天会发现是这一步的问题。

3.2 进入容器做几件典型的事

现在正式进去：

docker exec -it demo-box sh

回车之后提示符会变成类似/ #的样子，说明已经进到容器内部了。先确认三件事：hostname看到的是容器 ID 的前 12 位；cat /etc/os-release显示 Alpine；ip addr或hostname -i能看到容器自己的内网地址。这几条命令能让你直观感受到"容器有自己的主机名、自己的网络栈"。

接着模拟几个日常调试动作。想确认容器内的服务有没有监听端口，用netstat -tlnp—— 但 Alpine 默认没装netstat，会提示 command not found。这正好印证前面说的"镜像很精简"。在 Alpine 里安装工具要执行apk add --no-cache net-tools，注意这需要容器能访问外网镜像源，装完只在当前容器生效，容器删了就没了。这个"装完即焚"的特性是很多人第一次感受到容器和虚拟机的区别的地方。

再试一个我经常用来演示解耦的操作：在容器里创建一个文件，退出容器后再确认它还在。

echo "hello from inside" > /tmp/notes.txt exit docker exec demo-box cat /tmp/notes.txt

第二行的cat会在容器里读出hello from inside。这说明exit退出的是交互式 shell，不是容器本身，容器依旧在运行。这是exec与attach最本质的区别，也是它成为日常首选的原因——进出自由，互不影响。

3.3 退出、保留与清理的正确姿势

退出容器内 shell 主要有两种方式。敲exit，或者按Ctrl+D，两者都表示结束当前 shell 进程，效果一样。它们都不会影响容器的主进程。如果你不小心用了Ctrl+C，绝大多数情况下也只是把当前这条前台命令中断，容器照样活着。

但也有例外需要留意。假如你在容器里执行的是docker exec -it 容器名 bash，那么Ctrl+C会中断 bash，退出效果和exit类似。真正危险的是对attach用Ctrl+C，那会把信号直接打给容器主进程，主进程不处理 SIGINT 就会退出，容器随之停止。这一点我在第四节会展开。

练习结束之后清理，命令就两行：

docker stop demo-box docker rm demo-box

stop是优雅停止，会先发 SIGTERM 给主进程，等一段时间（默认 10 秒）再发 SIGKILL；rm是删除容器及其可写层。这里有个好习惯值得养成：先用docker ps -a看清楚有哪些容器再删，别一个docker rm -f甩出去把还在用的开发容器误删了。我就干过一次，还好那是个临时测试容器，损失不大，但当时手心的汗是真的。

4. attach 与 nsenter：另外两条路什么时候走

4.1 docker attach 的真实行为与两个致命坑

docker attach demo-box的效果是把你的终端和容器主进程的 stdin/stdout/stderr 直接连起来。它在一件事上确实比 exec 强：你能看到主进程原始的输出流，而且是实时的，不会像docker logs那样有格式包装。所以当某个程序只往标准输出刷数据、需要你实时盯着看时，attach 是有价值的。

但它的两个坑非常致命。第一，Ctrl+C会被解释成中断信号送到主进程，很多程序收到这个信号就直接退出了。你本来只是想"退出 console"，结果把线上服务停了，这类事故几乎每个用 Docker 的人都听闻或亲历过。想安全脱离又不杀进程，标准做法是按Ctrl+P再按Ctrl+Q，注意是依次按、不是同时按住，第一次操作容易按错，多试两次就熟了。

第二，attach 是共享连接。如果容器主进程的标准输出同时被多个 attach 连着，大家看到的是同一份流，你在一个终端里能打字，其他终端会同步看到，但谁先谁后并不好控制。所以 attach 只适合单人、短时、以观察为主的场景。

一句话总结：能用 exec 就别用 attach，非要用 attach 就一定记住Ctrl+PCtrl+Q这个脱离组合。

4.2 nsenter：连 shell 都没有时的最后手段

有些镜像为了瘦身干脆不放 shell，比如只包含二进制和证书的 distroless 镜像。这类容器docker exec -it 容器名 sh会直接报找不到文件，因为容器里确实没有 sh 可执行。这种情况按常规手段是进不去的，但借助宿主机的命名空间操作，还是能窥探到它的运行环境。

思路是这样的：先用docker inspect -f '{{.State.Pid}}' 容器名拿到容器主进程在宿主机上的 PID，然后用nsenter带着这个 PID 进入它的网络、进程、挂载等命名空间。这样你看到的就不是容器镜像里那套文件系统，而是宿主机的文件系统加上容器的隔离视图，判断网络通不通、挂载对不对非常有效。

这条路有几个前提必须满足：宿主机上有nsenter（util-linux 包自带，多数发行版都有），执行用户有足够权限（一般要 root 或加了相应能力），以及你心里清楚自己在动宿主机上的东西，别把宿主机的文件当容器里的改。坦白说，日常开发基本用不到它，但运维排障时它常常是唯一能用的手段，所以值得知道有这么一条路。

5. 进不去容器？常见故障排查实录

5.1 报错信息与对应处理速查表

进容器失败时的报错五花八门，下面这张表覆盖了我实际遇到过的绝大部分情况，遇到问题先对号入座。

这张表里最值得多说一句的是the input device is not a TTY。它出现的场景非常典型：你把docker exec -it写进了 Jenkins 流水线、GitHub Actions、或者一个while read循环里。这些环境根本没有交互式终端，-t申请不到 TTY 就会报错。解决办法是把-it换成-i或者干脆不要，让命令以非交互方式跑完。

5.2 容器已经挂了，还想看它里面长什么样

有一种情况比"进不去"更让人难受：容器已经退出了，docker exec必然失败，但你就是想知道它退出前文件系统里是什么状态。这时候有两个办法。

第一个是docker commit把已退出容器的可写层固化成新镜像，然后基于这个新镜像起一个临时容器进去看。命令大致是docker commit 容器名 debug-snapshot，接着用docker run -it debug-snapshot sh进到快照里。这个方法的优点是所见即所得，退出时的现场被完整保留；缺点是会多出一个镜像，用完记得清理。

第二个思路是先看日志和退出码，再判断要不要进去。docker logs 容器名能看到主进程最后的输出，docker inspect -f '{{.State.ExitCode}}' 容器名能看到退出码。退出码 0 通常是正常结束或没有前台进程，137 是被 SIGKILL 掉（常见于内存超限被系统干掉），143 是被 SIGTERM 优雅停止。多数"容器起不来"的问题，看完这两样心里就有数了，根本不用急着进容器。

这两种做法各有取舍，我的习惯是先看日志和退出码定方向，确认是文件系统层面的问题再 commit 快照深入看，避免每次都在那里建镜像删镜像来回折腾。

5.3 几个我踩过坑才记住的细节

第一个细节关于容器名前缀匹配。Docker 允许用容器 ID 的前几位来指代容器，只要不产生歧义。当机器上容器多起来，前几位很可能撞车，这时会报multiple IDs match或者更糟——你以为是 A，实际操作了 B。我的做法是养成用完整容器名而不是 ID 前缀的习惯，名字起得清晰一点，比如web-dev、db-test这种，比一串十六进制好记得多。

第二个细节是交互式命令和守护进程的冲突。有些以nginx、mysql这类守护进程为主进程的容器，本身并不期望你交互。你exec进去开个 shell 是没问题的，但别在里面手动kill主进程或者乱发信号，容器会因为主进程死亡而退出。判断当前进程树可以用ps -ef看一眼，找到 PID 1 是谁，它就是这个容器的命门。

第三个细节跟环境相关。在 Windows 上用 Docker Desktop 的时候，docker exec -it偶尔会遇到终端显示异常、方向键失灵，这通常跟终端模拟器和 TTY 的配合有关。换用 PowerShell 或者调整到 WSL 里的终端跑，体验会好很多。我也遇到过镜像里没有bash只有sh，习惯性敲 bash 报错，换成sh立刻就好。这类问题的共同点是：报错很明确，只是需要你知道排查方向，而不是怀疑 Docker 坏了。

把"进容器"这一件事从头到尾捋一遍，你会发现真正的门槛不在命令本身，而在于对容器本质的理解——它是被隔离的进程，不是一个完整的系统。理解了这一点，exec、attach、nsenter各自适合什么场景、为什么要有这些区别，都会顺理成章。我个人的经验是：日常九成场景只用docker exec -it 容器名 sh，剩下那一成交给日志和退出码先判断，实在需要直捣黄龙再考虑命名空间那套。刚开始不用把这些全记住，把-it的位置、容器名和命令的顺序、以及Ctrl+PCtrl+Q这个脱离组合练熟，就已经能应付绝大多数调试需求了。