通常来说，使用 gdb 等工具调试测试或生产环境的进程，是非常好的查找 Bug 的方式。但是当我们步入容器时代后，使用 gdb 工具却会遇到一些麻烦。

当我们进入容器内，尝试使用 gdb attach 的方式开始调试已运行的进程时，会得到这样的报错：

Attaching to process 123
ptrace: Operation not permitted.

通过简单的搜索我们可以发现，这是因为容器内为了安全，默认没有给 SYS_PTRACE 权限的原因。于是，很多教程告诉我们，用这个命令启动容器解决这个问题：

docker run xxx --cap-add=SYS_PTRACE

然而，在生产环境授予容器 SYS_PTRACE 权限是很危险的，有可能造成容器逃逸。因此，如果需要启用该权限，建议慎重考虑。

那么，有没有办法避开这个权限呢？由于容器本身其实就是主机上的一个进程，所以我们自然会想到，能否直接从主机找到对应的进程，然后在主机上执行 gdb attach 呢？

事实上我们可以这样操作，但是由于容器内的二进制文件在主机上并没有，所以 gdb attach 之后会报 No such file，并不能正常工作。就算我们把二进制拷贝出来，放在对应的位置上，gdb 还是会有 warning：

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.

这个 warning 就是告诉我们，正在运行的 gdb 进程的 PID namespace 与想要调试的进程的不同，这会导致我们的线程列表等数据出现偏差，可能会影响调试。

考虑到容器的实现原理就是在不同的 namespace 中运行程序，因此如果我们能以容器进程的 namespace 启动一个调试器，那就能解决这个问题了。经过一番搜索，发现 Linux 提供了一个叫 nsenter 的工具来做这件事。我们只需要这样操作：

nsenter -m -u -i -n -p --target ${PID} bash

就可以启动一个跟容器内进程共用同一个 namespace 的 bash，并且该 bash 并没有 SYS_PTRACE 权限的限制，可以非常方便的使用 gdb 了。

安全的调试容器内的进程 by 桔子小窝 is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.