五種快速查找容器文件系統中文件的方法
如果你經常使用容器，那么你很有可能希望在某個時刻查看正在運行的容器的文件系統。也許容器無法正常運行，你想讀取一些日志，也許你想檢查容器內部的一些配置文件…或者，你可能像我一樣，想在該容器中的二進制文件上放置一些 eBPF 探針（稍后將詳細介紹）。
不管原因是什么，在這篇文章中，我們將介紹一些可以用來檢查容器中的文件的方法。
我們將從研究容器文件系統的簡單和通常推薦的方法開始，并討論為什么它們不能總是工作。接下來，我們將對 Linux 內核如何管理容器文件系統有一個基本的了解，我們將利用這一了解以不同但仍然簡單的方式檢查文件系統。
方法一：Exec 到容器中
如果你快速搜索如何檢查容器的文件系統，你會發現一個常見的解決方案是使用 Docker 命令：
- docker exec -it mycontainer /bin/bash
這是一個很好的開始。如果它能滿足你的所有需求，你應該繼續使用它。
然而，這種方法的一個缺點是，它需要在容器中存在一個 shell。如果容器中沒有/bin/bash、/bin/sh 或其他 shell，那么這種方法將不起作用。例如，我們為 Pixie 項目構建的許多容器都是基于無 distroless 的，并且沒有包含一個 shell 來保持鏡像較小。在這些情況下，這種方法不起作用。
即使 shell 可用，你也無法訪問所有你習慣使用的工具。因此，如果容器中沒有安裝 grep，那么你也不能訪問 grep。這是另一個找更好工作的理由。
方法二：使用 nsenter
如果你再深入一點，就會意識到容器進程與 Linux 主機上的其他進程一樣，只是在命名空間中運行，以使它們與系統的其他部分隔離。
所以你可以使用 nsenter 命令來輸入目標容器的命名空間，使用類似這樣的東西：
- # Get the host PID of the process in the container
- PID=$(docker container inspect mycontainer | jq '.[0].State.Pid')
- # Use nsenter to go into the container’s mount namespace.
- sudo nsenter -m -t $PID /bin/bash
它進入目標進程的掛載（-m）命名空間（-t $PID），并運行/bin/bash。進入掛載命名空間本質上意味著我們獲得容器所看到的文件系統視圖。
這種方法似乎比 docker 的 exec 方法更有前途，但也遇到了類似的問題：它要求目標容器中包含/bin/bash（或其他 shell）。如果我們輸入的不是掛載命名空間，我們仍然可以訪問主機上的文件，但是因為我們是在執行/bin/bash（或其他 shell）之前輸入掛載命名空間，所以如果掛載命名空間中沒有 shell，我們就不走運了。
方法三：使用 docker 復制
解決這個問題的另一種方法是簡單地將相關文件復制到主機，然后使用復制的文件。
要從正在運行的容器中復制選定的文件，可以使用：
- docker cp mycontainer:/path/to/file file
也可以用以下方法來快照整個文件系統：
- docker export mycontainer -o container_fs.tar
這些命令使你能夠檢查文件，當容器可能沒有 shell 或你需要的工具時，這些命令比前兩種方法有了很大的改進。
方法四：在主機上查找文件系統
復制方法解決了我們的許多問題，但是如果你試圖監視日志文件呢？或者，如果你試圖將 eBPF 探針部署到容器中的文件中，又該怎么辦呢？在這些情況下，復制是不起作用的。
我們希望直接從主機訪問容器的文件系統。容器的文件應該在主機的文件系統中，但是在哪里呢？
Docker 的 inspect 命令給了我們一個線索：
- docker container inspect mycontainer | jq '.[0].GraphDriver'
這給我們：
- {
- "Data": {
- "LowerDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab-init/diff:/var/lib/docker/overlay2/524a0d000817a3c20c5d32b79c6153aea545ced8eed7b78ca25e0d74c97efc0d/diff",
- "MergedDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged",
- "UpperDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff",
- "WorkDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work"
- },
- "Name": "overlay2"
- }
讓我們來分析一下：
- LowerDir：包含容器內所有層的文件系統，最后一層除外
- UpperDir：容器最上層的文件系統。這也是反映任何運行時修改的地方。
- MergedDir：文件系統所有層的組合視圖。
- WorkDir：用于管理文件系統的內部工作目錄。
基于 overlayfs 的容器文件系統結構。
因此，要查看容器中的文件，只需查看 MergedDir 路徑。
- sudo ls /var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged
如果你想了解文件系統工作的更多細節，你可以查看 Martin Heinz 關于 overlay 文件系統的博客文章：https://martinheinz.dev/blog/44。
方法五：/proc/<pid>/root
把最好的留到最后，還有一種從主機找到容器文件系統的更簡單的方法。使用容器內進程的宿主 PID，你可以簡單地運行：
- sudo ls /proc/<pid>/root
Linux 已經為你提供了進程掛載命名空間的視圖。
此時，你可能會想：為什么我們不采用這種方法，并將其變成一篇只有一行字的博客文章呢？但這都是關于旅程，對吧？
彩蛋：/proc/<pid>/mountinfo
出于好奇，方法四中討論的關于容器 overlay 文件系統的所有信息也可以直接從 Linux /proc 文件系統中發現。如果你查看/proc/<pid>/mountinfo，你會看到如下內容：
- 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
- 2364 2363 0:93 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
- 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 跟蹤博客[1]）。
由于每個容器都捆綁了自己的 OpenSSL 和其他庫，因此 Stirling 部署的任何 eBPF 探針都必須位于容器內的文件上。因此，Stirling 使用本文中討論的技術在 K8s 容器中找到感興趣的庫，然后從主機將 eBPF 探針部署到這些二進制文件上。
下圖概述了在另一個容器中部署 eBPF 探針的工作方式。
Stirling 通過掛載主機文件系統在其他容器上部署 eBPF 探針，然后在主機上找到目標容器文件系統。
總結
下次當你需要檢查容器中的文件時，希望你能嘗試一下這些技巧。一旦你體驗到不再受容器有沒有 shell 限制的自由，你可能就再也不會回去了。只需要訪問/proc/<pid>/root！
