排查容器里的环境问题时，docker exec 比重启更有价值

2020年10月23日 · 阅读需 3 分钟

全栈开发者 / 技术写作者

有些容器问题并不是“起不来”，而是明明已经在运行，表现却和预期不一样。比如环境变量没生效、工作目录不对、配置文件路径错了、依赖包实际没有安装完整。这个时候如果只会不停重启容器，排查会非常低效。对这类问题来说，docker exec 往往比“再试一次”更有价值，因为它让你直接进入现场。

先确认容器里看到的世界到底是什么样

本地开发时，我们很容易用宿主机视角想问题，觉得某个文件就在当前目录、某个环境变量明明已经配了、某个命令在本机能跑那容器里也应该能跑。可容器本来就是隔离环境，这些直觉不一定成立。

用 docker exec 进去后，先看几件最关键的事：当前目录是不是你以为的那个目录，配置文件有没有挂进去，环境变量值对不对，进程真正使用的是哪份配置。很多问题到这一步其实就已经能定位七八成。

我不太喜欢把 docker exec 当成一个机械动作。真正有效的方式是带着问题进去，比如我要验证某个环境变量是否存在、某个端口是否在监听、某个目录是否真的挂载成功。这样每次进容器都有明确目的，不会在里面漫无目的地翻半天。

当你把这个动作变成“验证假设”，调试效率会明显提高。因为你不是在碰运气，而是在逐个排除错误前提。

如果问题更偏向运行时网络、日志、启动顺序，可能日志和 Compose 配置更关键；但如果问题集中在路径、权限、文件、环境变量这些层面，进入容器往往是最快的。比如应用一直找不到模板文件，或者连接配置读出来不对，这类问题只靠外部观察通常不够直接。

需要注意的是，docker exec 很适合排查，但不适合长期修补。你在容器里临时改了一次文件、手动执行了一条命令，问题暂时消失，不代表工作流已经正确。真正稳的做法还是回到 Dockerfile、Compose 或启动脚本里，把根因修好。

否则下次容器一重建，问题还会回来，而且你可能已经忘记自己当时在里面动过什么。

容器调试最怕的是“看都没看，就先改配置、删镜像、重建环境”。这些动作都不便宜。先用 docker exec 把现场看清楚，很多排查会更像工程判断，而不是不断试错。

本地 Docker 工作流要顺，除了会起容器，也得会进容器看问题。这一步不复杂，但非常值。