Docker
如果经常使用容器,那么很有可能希望在某个时刻查看正在运行的容器的文件系统。也许容器无法正常运行,读取一些日志,也许想检查容器内部的一些配置文件…或者,想在该容器中的二进制文件上放置一些 eBPF 探针(稍后将详细介绍)。
介绍一些可以用来检查容器中的文件的方法。
从研究容器文件系统的简单和通常推荐的方法开始,并讨论为什么它们不能总是工作。接下来,对 Linux 内核如何管理容器文件系统有一个基本的了解,利用这一了解以不同但仍然简单的方式检查文件系统。

方法一:Exec 到容器中

如果快速搜索如何检查容器的文件系统,会发现一个常见的解决方案是使用 Docker 命令:

  1. docker exec -it mycontainer /bin/bash

这是一个很好的开始。如果它能满足所有需求,应该继续使用它。
然而,这种方法的一个缺点是,它需要在容器中存在一个 shell。如果容器中没有/bin/bash、/bin/sh 或其他 shell,那么这种方法将不起作用。例如,为 Pixie 项目构建的许多容器都是基于无 distroless 的,并且没有包含一个 shell 来保持镜像较小。在这些情况下,这种方法不起作用。
即使 shell 可用,也无法访问所有经常使用的工具。因此,如果容器中没有安装 grep,那么也不能访问 grep。这是另一个找更好工作的理由。

方法二:使用 nsenter

如果再深入一点,就会意识到容器进程与 Linux 主机上的其他进程一样,只是在命名空间中运行,以使它们与系统的其他部分隔离。
所以可以使用 nsenter 命令来输入目标容器的命名空间,使用类似这样的东西:

  1. # Get the host PID of the process in the container
  2. PID=$(docker container inspect mycontainer | jq '.[0].State.Pid')
  3. # Use nsenter to go into the container’s mount namespace.
  4. sudo nsenter -m -t $PID /bin/bash

它进入目标进程的挂载(-m)命名空间(-t $PID),并运行/bin/bash。进入挂载命名空间本质上意味着获得容器所看到的文件系统视图。
这种方法似乎比 docker 的 exec 方法更有前途,但也遇到了类似的问题:它要求目标容器中包含/bin/bash(或其他 shell)。如果输入的不是挂载命名空间,仍然可以访问主机上的文件,但是因为是在执行/bin/bash(或其他 shell)之前输入挂载命名空间,所以如果挂载命名空间中没有 shell,就不走运了。

方法三:使用 docker 复制

解决这个问题的另一种方法是简单地将相关文件复制到主机,然后使用复制的文件。
要从正在运行的容器中复制选定的文件,可以使用:

  1. docker cp mycontainer:/path/to/file file

也可以用以下方法来快照整个文件系统:

  1. docker export mycontainer -o container_fs.tar

这些命令能够检查文件,当容器可能没有 shell 或需要的工具时,这些命令比前两种方法有了很大的改进。

方法四:在主机上查找文件系统

复制方法解决了许多问题,但是如果试图监视日志文件呢?或者,如果试图将 eBPF 探针部署到容器中的文件中,又该怎么办呢?在这些情况下,复制是不起作用的。
希望直接从主机访问容器的文件系统。容器的文件应该在主机的文件系统中,但是在哪里呢?
Docker 的 inspect 命令给了一个线索:

  1. docker container inspect mycontainer | jq '.[0].GraphDriver'
  1. {
  2. "Data": {
  3. "LowerDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab-init/diff:/var/lib/docker/overlay2/524a0d000817a3c20c5d32b79c6153aea545ced8eed7b78ca25e0d74c97efc0d/diff",
  4. "MergedDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged",
  5. "UpperDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff",
  6. "WorkDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work"
  7. },
  8. "Name": "overlay2"
  9. }

来分析一下:

  • LowerDir:包含容器内所有层的文件系统,最后一层除外
  • UpperDir:容器最上层的文件系统。这也是反映任何运行时修改的地方。
  • MergedDir:文件系统所有层的组合视图。
  • WorkDir:用于管理文件系统的内部工作目录。

5 种快速查找容器文件系统中文件的方法 - 图1
基于 overlayfs 的容器文件系统结构。
因此,要查看容器中的文件,只需查看 MergedDir 路径。

  1. sudo ls /var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged

如果要了解文件系统工作的更多细节,可以查看 Martin Heinz 关于 overlay 文件系统的博客文章:https://martinheinz.dev/blog/44

方法五:/proc/<pid>/root

把最好的留到最后,还有一种从主机找到容器文件系统的更简单的方法。使用容器内进程的宿主 PID,可以简单地运行:

  1. sudo ls /proc/<pid>/root

Linux 已经提供了进程挂载命名空间的视图。

彩蛋:/proc/<pid>/mountinfo

出于好奇,方法四中讨论的关于容器 overlay 文件系统的所有信息也可以直接从 Linux /proc 文件系统中发现。如果查看/proc//mountinfo,会看到如下内容:

  1. 2363 1470 0:90 / / rw,relatime master:91 - overlay overlay rw,lowerdir=/var/lib/docker/overlay2/l/YZVAVZS6HYQHLGEPJHZSWTJ4ZU:/var/lib/docker/overlay2/l/ZYW5O24UWWKAUH6UW7K2DGV3PB,upperdir=/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff,workdir=/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work
  2. 2364 2363 0:93 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
  3. 2365 2363 0:94 / /dev rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755,inode64

在这里,可以看到容器已经挂载了一个覆盖文件系统作为它的根。它还报告与 docker inspect 报告相同类型的信息,包括容器文件系统的 LowerDir 和 UpperDir。它没有直接显示 MergedDir,但可以直接使用 UpperDir 并将 diff 改为 merged,这样就可以看到容器的文件系统了。

在 Pixie 怎么用这个

在开头提到了 Pixie 项目需要如何在容器上放置 eBPF 探针。为什么和如何?
Pixie 内部的 Stirling 模块负责收集可观察数据。由于是 k8s 原生的,所以收集的很多数据都来自于在容器中运行的应用程序。Stirling 还使用 eBPF 探针从它监视的进程中收集数据。例如,Stirling 在 OpenSSL 上部署 eBPF 探针来跟踪加密的消息(如果要了解更多有关这方面的细节,请参阅SSL 跟踪博客)。
由于每个容器都捆绑了自己的 OpenSSL 和其他库,因此 Stirling 部署的任何 eBPF 探针都必须位于容器内的文件上。因此,Stirling 使用本文中讨论的技术在 K8s 容器中找到感兴趣的库,然后从主机将 eBPF 探针部署到这些二进制文件上。
下图概述了在另一个容器中部署 eBPF 探针的工作方式。
5 种快速查找容器文件系统中文件的方法 - 图2
Stirling 通过挂载主机文件系统在其他容器上部署 eBPF 探针,然后在主机上找到目标容器文件系统。

总结

下次当需要检查容器中的文件时,可以尝试一下这些技巧。一旦体验到不再受容器有没有 shell 限制的自由,可能就再也不会回去了。只需要访问/proc/<pid>/root