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你按CtrlC发的是中断信号很可能直接把主进程干掉了容器跟着退出。所以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的作用是让容器内的进程和你的终端之间保持一条输入通道。没有-iDocker 会把标准输入接到 /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 DEBUG1 -e LOG_LEVELdebug 容器名 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显示 Alpineip 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或者按CtrlD两者都表示结束当前 shell 进程效果一样。它们都不会影响容器的主进程。如果你不小心用了CtrlC绝大多数情况下也只是把当前这条前台命令中断容器照样活着。但也有例外需要留意。假如你在容器里执行的是docker exec -it 容器名 bash那么CtrlC会中断 bash退出效果和exit类似。真正危险的是对attach用CtrlC那会把信号直接打给容器主进程主进程不处理 SIGINT 就会退出容器随之停止。这一点我在第四节会展开。练习结束之后清理命令就两行docker stop demo-box docker rm demo-boxstop是优雅停止会先发 SIGTERM 给主进程等一段时间默认 10 秒再发 SIGKILLrm是删除容器及其可写层。这里有个好习惯值得养成先用docker ps -a看清楚有哪些容器再删别一个docker rm -f甩出去把还在用的开发容器误删了。我就干过一次还好那是个临时测试容器损失不大但当时手心的汗是真的。4. attach 与 nsenter另外两条路什么时候走4.1 docker attach 的真实行为与两个致命坑docker attach demo-box的效果是把你的终端和容器主进程的 stdin/stdout/stderr 直接连起来。它在一件事上确实比 exec 强你能看到主进程原始的输出流而且是实时的不会像docker logs那样有格式包装。所以当某个程序只往标准输出刷数据、需要你实时盯着看时attach 是有价值的。但它的两个坑非常致命。第一CtrlC会被解释成中断信号送到主进程很多程序收到这个信号就直接退出了。你本来只是想退出 console结果把线上服务停了这类事故几乎每个用 Docker 的人都听闻或亲历过。想安全脱离又不杀进程标准做法是按CtrlP再按CtrlQ注意是依次按、不是同时按住第一次操作容易按错多试两次就熟了。第二attach 是共享连接。如果容器主进程的标准输出同时被多个 attach 连着大家看到的是同一份流你在一个终端里能打字其他终端会同步看到但谁先谁后并不好控制。所以 attach 只适合单人、短时、以观察为主的场景。一句话总结能用 exec 就别用 attach非要用 attach 就一定记住CtrlPCtrlQ这个脱离组合。4.2 nsenter连 shell 都没有时的最后手段有些镜像为了瘦身干脆不放 shell比如只包含二进制和证书的 distroless 镜像。这类容器docker exec -it 容器名 sh会直接报找不到文件因为容器里确实没有 sh 可执行。这种情况按常规手段是进不去的但借助宿主机的命名空间操作还是能窥探到它的运行环境。思路是这样的先用docker inspect -f {{.State.Pid}} 容器名拿到容器主进程在宿主机上的 PID然后用nsenter带着这个 PID 进入它的网络、进程、挂载等命名空间。这样你看到的就不是容器镜像里那套文件系统而是宿主机的文件系统加上容器的隔离视图判断网络通不通、挂载对不对非常有效。这条路有几个前提必须满足宿主机上有nsenterutil-linux 包自带多数发行版都有执行用户有足够权限一般要 root 或加了相应能力以及你心里清楚自己在动宿主机上的东西别把宿主机的文件当容器里的改。坦白说日常开发基本用不到它但运维排障时它常常是唯一能用的手段所以值得知道有这么一条路。5. 进不去容器常见故障排查实录5.1 报错信息与对应处理速查表进容器失败时的报错五花八门下面这张表覆盖了我实际遇到过的绝大部分情况遇到问题先对号入座。报错或现象可能原因处理方式Error response from daemon: Container xxx is not running容器已经退出或从未成功启动先docker ps -a看状态再看docker logs 容器名找退出原因executable file not found in $PATH镜像里没有你指定的 shell 或命令换成sh、ash或确认容器内实际存在的可执行文件提示符不出现敲键盘无反应漏了-i或-t补全为-it再试注意选项写在容器名之前the input device is not a TTY在脚本、定时任务或管道里用了-it去掉-t或用-d后台执行不要在无终端环境强上交互Permission denied改不动文件当前 exec 用户非 root加-u root再进注意镜像是否真的允许提权Cannot connect to the Docker daemon守护进程没起或当前用户不在 docker 组检查服务状态Linux 上确认用户组配置命令能执行但看不到中文、表格错乱缺少终端宽度信息或字符集不匹配确保带-t必要时设置LANG环境变量这张表里最值得多说一句的是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的位置、容器名和命令的顺序、以及CtrlPCtrlQ这个脱离组合练熟就已经能应付绝大多数调试需求了。