背景
最近偶然聽了幾堂極客時間的云原生免費公開課程，首次接觸到了Linux namespace技術，并了解到這正是現在風頭正勁的容器技識訓石，引起了自己探究一二的興趣，結合課程+網路搜索+實踐操作，也算有了一些初步的了解，這里記錄、總結一些學習程序，
Linux namespace簡介
namespace技術網上的介紹已經很多了，這里不做過多贅述，簡單總結namespace是Linux 內核提供的支持內核資源隔離的關鍵技術，目前包含以下7類namespace:
Namespace 變數 隔離資源
Cgroup CLONE_NEWCGROUP Cgroup 根目錄
IPC CLONE_NEWIPC System V IPC, POSIX 訊息佇列等
Network CLONE_NEWNET 網路設備，協議堆疊、埠等
Mount CLONE_NEWNS 掛載點
PID CLONE_NEWPID 行程ID
User CLONE_NEWUSER 用戶和group ID
UTS CLONE_NEWUTS Hostname和NIS域名
本文中主要涉及到的是Network+PID+Mount三個namespace，
容器運行時缺少必要命令問題與解決方案
下載使用docker官方提供的基礎作業系統鏡像-本例中為deiban--時會發現很多命令都默認沒有安裝--比如網路抓包tcpdump、甚至行程資訊查看ps/top等，直覺上的辦法只能進入容器內部逐個安裝，然而如果每次運行新容器都需要安裝一遍相關工具包的話未免有些繁瑣，另外如果只是啟動初期臨時使用一下這些工具除錯，之后便不再需要，額外安裝這些工具其實也不必要的增大了容器本身的復雜度，
針對這一問題，其實linux提供了nsenter、unshare命令用于進入容器行程所屬Network、PID、Mount 等namespace執行宿主機命令，從而達到無需在容器中安裝命令，直接使用宿主機相應命令的目的，以下以tcpdump/ps/top三個命令的執行為例進行進行介紹，
利用宿主機tcpdump命令對docker容器進行抓包
利用nsenter命令可以指定目標namespace，并在其中執行對應命令，
以下命令先運行一個debian基礎鏡像的容器，而后在其中執行ip addr命令查看網路配置，并嘗試執行tcpdump命令抓包
~# docker run -it --name ns_test_net -d debian:stretch
d221b13a5fbcbf23a981a3067847b743081fff20ae05e6892b8744546cb1b148
~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d221b13a5fbc debian:stretch "bash" 9 seconds ago Up 6 seconds ns_test_net
~# docker exec -it ns_test_net bash
root@d221b13a5fbc:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
root@d221b13a5fbc:/# tcpdump dump -i any -nvv
bash: tcpdump: command not found
可以看到報錯command not found，此時可以簡單通過nsenter使用宿主機命令進入容器所屬namespace執行相關命令:
通過ip addr 查看容器網路配置，通過tcpdump 嘗試抓包
~# docker inspect -f {{.State.Pid}} ns_test_net # 獲取容器行程在宿主機上的pid
9164
nsenter -t 9164 -n ip addr # -t指定容器行程pid，-n指定使用對應pid的Network namespace， 執行ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
~# nsenter -t 9164 -n tcpdump -nvv -i any # 使用宿主機tcpdump命令對容器所屬Network namespace抓包，注意需要同時在宿主機上執行：ping 172.17.0.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
17:07:50.290707 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.0.3 tell 172.17.0.1, length 28
17:07:50.290743 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.17.0.3 is-at 02:42:ac:11:00:03, length 28
17:07:50.290761 IP (tos 0x0, ttl 64, id 22629, offset 0, flags [none], proto ICMP (1), length 84)
172.17.0.1 > 172.17.0.3: ICMP echo request, id 10895, seq 1, length 64
17:07:50.290777 IP (tos 0x0, ttl 64, id 9364, offset 0, flags [none], proto ICMP (1), length 84)
172.17.0.3 > 172.17.0.1: ICMP echo reply, id 10895, seq 1, length 64
17:07:51.307360 IP (tos 0x0, ttl 64, id 22696, offset 0, flags [none], proto ICMP (1), length 84)
172.17.0.1 > 172.17.0.3: ICMP echo request, id 10895, seq 2, length 64
17:07:51.307397 IP (tos 0x0, ttl 64, id 9365, offset 0, flags [none], proto ICMP (1), length 84)
172.17.0.3 > 172.17.0.1: ICMP echo reply, id 10895, seq 2, length 64
17:07:52.331317 IP (tos 0x0, ttl 64, id 22867, offset 0, flags [none], proto ICMP (1), length 84)
172.17.0.1 > 172.17.0.3: ICMP echo request, id 10895, seq 3, length 64
17:07:52.331352 IP (tos 0x0, ttl 64, id 9564, offset 0, flags [none], proto ICMP (1), length 84)
172.17.0.3 > 172.17.0.1: ICMP echo reply, id 10895, seq 3, length 64
17:07:53.355311 IP (tos 0x0, ttl 64, id 22927, offset 0, flags [none], proto ICMP (1), length 84)
利用宿主機ps/top工具對docker容器內運行行程進行狀態監控
首次嘗試
根據前面使用nsenter進入Network namespace執行網路相關命令的經驗，很容易得出使用nsenter進入PID namespace空間執行ps/top等命令即可獲取容器內行程狀態的想法，然而實際執行后會發現：
~# nsenter -t 9164 -p ps -elf
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S root 1 0 0 80 0 - 34783 SyS_ep 2021 ? 00:20:18 /sbin/init
1 S root 2 0 0 80 0 - 0 - 2021 ? 00:00:02 [kthreadd]
1 S root 3 2 0 80 0 - 0 - 2021 ? 00:04:39 [ksoftirqd/0]
1 S root 5 2 0 60 -20 - 0 - 2021 ? 00:00:00 [kworker/0:0H]
1 S root 7 2 0 80 0 - 0 rcu_gp 2021 ? 01:46:22 [rcu_sched]
1 S root 8 2 0 80 0 - 0 - 2021 ? 00:00:00 [rcu_bh]
1 S root 9 2 0 -40 - - 0 - 2021 ? 00:03:31 [migration/0]
1 S root 10 2 0 60 -20 - 0 - 2021 ? 00:00:00 [lru-add-drain]
ps 實際顯示的還是宿主機當前的行程資訊(1號行程為/sbin/init)，而非容器內部的行程資訊，top也是一樣的效果，這是為什么呢？
失敗原因分析
https://github.com/util-linux/util-linux/issues/660 解釋到：
The command nsenter just enters the namespace(s), and nothing else. The behaviour of the utils like ps(1) depend on environment in the namespace. It's out of nsenter business to setup the environment (for example mount /proc). Maybe docker also uses mount namespace in the container, in this care you also need to enter --mount namespace etc.
大意是nsenter實際做的只是進入對應的namespace，而ps這些行程監控工具實際上依賴namespace中的環境設定--如/proc檔案系統，nsenter并不會負責這些環境設定作業，所以需要使用者自己負責--比如mount /proc系統等，
在 man ps中實際也可以找到：
This ps works by reading the virtual files in /proc. This ps does not need to be setuid kmem or have any privileges to run. Do not give this ps any special permissions.
明確說明了ps依賴于/proc檔案系統執行實際作業，
通過man proc 簡單看一下什么是proc filesystem:
The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures. It is commonly mounted at /proc. Most of it is read-only, but some files allow kernel variables to be changed.
這是一個提供內核資料結構訪問介面的偽檔案系統，一般掛載在/proc路徑下，那么之前使用nsenter -t 9164 -p 實際只是進入了PID namespace，但是使用的Mount namespace依然屬于宿主機，所以ps/top這些工具依然讀取的是宿主機的/proc檔案，所以其輸出的內容自然也就是宿主機行程執行資訊了，為了解決這個問題我們需要讓ps能夠讀取到容器擁有的proc檔案系統，
同時進入PID+Mount namespace
第一個直覺反應是直接使用nsenter同時進入PID+Mount namespace，想當然既然都已經進入了容器的Mount namespace， 那ps命令自然讀取的就是容器的/proc路徑了，執行以下命令：
~# nsenter -t 9164 -p -m ps -elf
nsenter: failed to execute ps: No such file or directory
發現報 No such file or directory，思考后得出結論，既然都是用容器的 Mount namespace了，那ps命令的執行路徑也就變成了容器內的檔案系統了，而容器本身并沒有安裝ps命令，自然也就會報找不到檔案了，所以同時掛載Mount namespace執行命令成功的前提是容器內部本來也已經安裝了對應命令--這很明顯無法滿足我們的需求，
使用nsenter重新單獨掛載proc檔案系統
退一步考慮，只重新掛載proc檔案系統可否呢，嘗試通過 nsenter進入容器namespace 后先mount proc而后執行ps：
:~# nsenter -t 9164 -p
~# ps -lf # 輸出結果為宿主機上行程狀態
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S root 8742 8719 0 80 0 - 5306 - 16:50 pts/2 00:00:00 -bash
4 S root 18449 8742 0 80 0 - 3694 - 18:10 pts/2 00:00:00 nsenter -t 9164 -p
0 S root 18450 18449 0 80 0 - 5305 - 18:10 pts/2 00:00:00 -bash
0 R root 18462 18450 0 80 0 - 9576 - 18:10 pts/2 00:00:00 ps -lf
~# mount -t proc proc /proc
~# ps -lf # 重新mount proc后執行結果為容器內行程狀態
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
0 S root 40 0 0 80 0 - 5305 - 18:10 pts/2 00:00:00 -bash
0 R root 50 40 0 80 0 - 9576 - 18:10 pts/2 00:00:00 ps -lf
~# top # top執行結果類似
top - 18:10:21 up 279 days, 3:47, 7 users, load average: 0.00, 0.00, 0.00
Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 0.0 sy, 0.0 ni, 98.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 12355128 total, 1187052 free, 5869104 used, 5298972 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6130300 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 18120 3100 2672 S 0.0 0.0 0:00.03 bash
40 root 20 0 21220 5044 3140 S 0.0 0.0 0:00.02 bash
51 root 20 0 44824 3540 3028 R 0.0 0.0 0:00.00 top
咋一看，通過nsenter進入PID namespace且重新mount proc檔案系統后，ps與top輸出的都已經是容器內的行程資訊了，一切問題好像都解決了？
但是此時如果回到宿主機中執行ps與top會發現出問題了：
~# ps
Error, do this: mount -t proc proc /proc
~# top
Error, do this: mount -t proc proc /proc
這是因為nsenter中用的依然是宿主機的Mount namespace，這種情況下重新mount proc改變的是宿主機Mount namespace的狀態，于是在nsenter內部使用容器的PID namespace+容器的proc系統作業正常，但是在宿主機上使用宿主機的PID namespace+容器的proc系統就會出錯了，
通過 findmnt -o+PROPAGATION 命令可以查看當前mount狀態，正常的proc狀態如下：
~# findmnt -o+PROPAGATION
而nsenter 重新mount proc系統，宿主機再次mount proc后會變成這樣
~# findmnt -o+PROPAGATION
于是直接通過nsenter 進入容器PID namespace 并重新mount proc的方法能夠正常執行容器內的ps/top等命令，但是卻有影響宿主機正常行為的副作用，不可取，
看起來需要探究一個既能在容器中正確執行宿主機的ps、top命令而又不能有影響宿主機狀態副作用的方法，在網上查了不少資料還真沒找到一個明確的方案，忍不住思考、摸索了數日，終于自己想出了一個目前看來能正確work的方案--引入unshare，
使用unshare+nsenter單獨掛載proc檔案系統
通過 unshare 命令可以在原行程上進行 namespace 隔離，也就是創建并加入新的 namespace，我們考慮先通過unshare命令將宿主機Mount namespace進行隔離，而后在隔離后行程中再次執行nsenter 進入容器的PID namespace，并重新掛載proc檔案系統，這樣新掛載的proc系統只會影響unshare的子行程，而不會穿透到宿主機之上，
具體在宿主機上執行以下命令：
~# unshare -fm
~# nsenter -t 9164 -p
~# mount -t proc proc /proc
~# ps -elf
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S root 1 0 0 80 0 - 4530 core_s 16:53 pts/0 00:00:00 bash
0 S root 72 0 0 80 0 - 5305 - 18:48 pts/2 00:00:00 -bash
0 R root 81 72 0 80 0 - 9576 - 18:48 pts/2 00:00:00 ps -elf
~# top
top - 18:49:17 up 279 days, 4:26, 7 users, load average: 0.00, 0.04, 0.06
Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 0.2 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 12355128 total, 1036408 free, 5898532 used, 5420188 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6100836 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 18120 3100 2672 S 0.0 0.0 0:00.03 bash
72 root 20 0 21220 5064 3160 S 0.0 0.0 0:00.02 -bash
82 root 20 0 44824 3496 2992 R 0.0 0.0 0:00.00 top
~# findmnt -o+PROPAGATION
可以看到ps/top輸出的正是容器內的行程資訊，同時findmnt結果中可以看到proc系統的PROPAGATION已經變成了private，表明mount變更不會影響其他namespace的狀態，
回過來在宿主機上執行以下命令驗證其proc系統不受影響：
~# ps -elf | head
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S root 1 0 0 80 0 - 34783 SyS_ep 2021 ? 00:20:18 /sbin/init
1 S root 2 0 0 80 0 - 0 - 2021 ? 00:00:02 [kthreadd]
1 S root 3 2 0 80 0 - 0 - 2021 ? 00:04:39 [ksoftirqd/0]
1 S root 5 2 0 60 -20 - 0 - 2021 ? 00:00:00 [kworker/0:0H]
1 S root 7 2 0 80 0 - 0 rcu_gp 2021 ? 01:46:24 [rcu_sched]
1 S root 8 2 0 80 0 - 0 - 2021 ? 00:00:00 [rcu_bh]
1 S root 9 2 0 -40 - - 0 - 2021 ? 00:03:31 [migration/0]
1 S root 10 2 0 60 -20 - 0 - 2021 ? 00:00:00 [lru-add-drain]
5 S root 11 2 0 -40 - - 0 - 2021 ? 00:00:36 [watchdog/0]
~# findmnt -o+PROPAGATION
轉載請注明出處，原文地址：https://www.cnblogs.com/AcAc-t/p/host_command_execution_in_linux_container.html
參考
https://zhuanlan.zhihu.com/p/73248894
https://unix.stackexchange.com/questions/124162/reliable-way-to-jail-child-processes-using-nsenter/124194#124194
https://www.cnblogs.com/mrhelloworld/p/docker11.html
https://www.zhihu.com/question/24964878
https://github.com/util-linux/util-linux/issues/660
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/484046.html
標籤：其他