Docker這麼火，喜歡技術的朋友可能也會想，如果要自己實現一個資源隔離的容器，應該從哪些方面下手呢？也許你第一反應可能就是chroot命令，這條命令給用戶最直觀的感覺就是使用後根目錄/的掛載點切換了，即文件系統被隔離了。然後，爲了在分佈式的環境下進行通信和定位，容器必然需要一個獨立的IP、端口、路由等等，自然就想到了網絡的隔離。同時，你的容器還需要一個獨立的主機名以便在網絡中標識自己。想到網絡，順其自然就想到通信，也就想到了進程間通信的隔離。可能你也想到了權限的問題，對用戶和用戶組的隔離就實現了用戶權限的隔離。最後，運行在容器中的應用需要有自己的PID,自然也需要與宿主機中的PID進行隔離。
由此，我們基本上完成了一個容器所需要做的六項隔離，Linux內核中就提供了這六種namespace隔離的系統調用，如下表所示。
|
Namespace |
系統調用參數 |
隔離內容 |
|
UTS |
CLONE_NEWUTS |
主機名與域名 |
|
IPC |
CLONE_NEWIPC |
信號量、消息隊列和共享內存 |
|
PID |
CLONE_NEWPID |
進程編號 |
|
Network |
CLONE_NEWNET |
網絡設備、網絡棧、端口等等 |
|
Mount |
CLONE_NEWNS |
掛載點（文件系統） |
|
User |
CLONE_NEWUSER |
用戶和用戶組 |
表 namespace六項隔離
實際上，Linux內核實現namespace的主要目的就是爲了實現輕量級虛擬化（容器）服務。在同一個namespace下的進程可以感知彼此的變化，而對外界的進程一無所知。這樣就可以讓容器中的進程產生錯覺，彷彿自己置身於一個獨立的系統環境中，以此達到獨立和隔離的目的。
需要說明的是，本文所討論的namespace實現針對的均是Linux內核3.8及其以後的版本。接下來，我們將首先介紹使用namespace的API，然後針對這六種namespace進行逐一講解，並通過程序讓你親身感受一下這些隔離效果（參考自http://lwn.net/Articles/531114/）。
1. 調用namespace的API
namespace的API包括clone()、setns()以及unshare()，還有/proc下的部分文件。爲了確定隔離的到底是哪種namespace，在使用這些API時，通常需要指定以下六個常數的一個或多個，通過|（位或）操作來實現。你可能已經在上面的表格中注意到，這六個參數分別是CLONE_NEWIPC、CLONE_NEWNS、CLONE_NEWNET、CLONE_NEWPID、CLONE_NEWUSER和CLONE_NEWUTS。
（1）通過clone()創建新進程的同時創建namespace
使用clone()來創建一個獨立namespace的進程是最常見做法，它的調用方式如下。
int clone(int (*child_func)(void *), void *child_stack, int flags, void *arg);
clone()實際上是傳統UNIX系統調用fork()的一種更通用的實現方式，它可以通過flags來控制使用多少功能。一共有二十多種CLONE_*的flag（標誌位）參數用來控制clone進程的方方面面（如是否與父進程共享虛擬內存等等），下面外面逐一講解clone函數傳入的參數。
- 參數child_func傳入子進程運行的程序主函數。
- 參數child_stack傳入子進程使用的棧空間
- 參數flags表示使用哪些CLONE_*標誌位
- 參數args則可用於傳入用戶參數
在後續的內容中將會有使用clone()的實際程序可供大家參考。
（2）查看/proc/[pid]/ns文件
從3.8版本的內核開始，用戶就可以在/proc/[pid]/ns文件下看到指向不同namespace號的文件，效果如下所示，形如[4026531839]者即爲namespace號。
$ ls -l /proc/$$/ns <<-- $$ 表示應用的PID total 0 lrwxrwxrwx. 1 mtk mtk 0 Jan 8 04:12 ipc -> ipc:[4026531839] lrwxrwxrwx. 1 mtk mtk 0 Jan 8 04:12 mnt -> mnt:[4026531840] lrwxrwxrwx. 1 mtk mtk 0 Jan 8 04:12 net -> net:[4026531956] lrwxrwxrwx. 1 mtk mtk 0 Jan 8 04:12 pid -> pid:[4026531836] lrwxrwxrwx. 1 mtk mtk 0 Jan 8 04:12 user->user:[4026531837] lrwxrwxrwx. 1 mtk mtk 0 Jan 8 04:12 uts -> uts:[4026531838]
如果兩個進程指向的namespace編號相同，就說明他們在同一個namespace下，否則則在不同namespace裏面。/proc/[pid]/ns的另外一個作用是，一旦文件被打開，只要打開的文件描述符（fd）存在，那麼就算PID所屬的所有進程都已經結束，創建的namespace就會一直存在。那如何打開文件描述符呢？把/proc/[pid]/ns目錄掛載起來就可以達到這個效果，命令如下。
# touch ~/uts # mount --bind /proc/27514/ns/uts ~/uts
如果你看到的內容與本文所描述的不符，那麼說明你使用的內核在3.8版本以前。該目錄下存在的只有ipc、net和uts，並且以硬鏈接存在。
（3）通過setns()加入一個已經存在的namespace
上文剛提到，在進程都結束的情況下，也可以通過掛載的形式把namespace保留下來，保留namespace的目的自然是爲以後有進程加入做準備。通過setns()系統調用，你的進程從原先的namespace加入我們準備好的新namespace，使用方法如下。
int setns(int fd, int nstype);
- 參數fd表示我們要加入的namespace的文件描述符。上文已經提到，它是一個指向/proc/[pid]/ns目錄的文件描述符，可以通過直接打開該目錄下的鏈接或者打開一個掛載了該目錄下鏈接的文件得到。
- 參數nstype讓調用者可以去檢查fd指向的namespace類型是否符合我們實際的要求。如果填0表示不檢查。
爲了把我們創建的namespace利用起來，我們需要引入execve()系列函數，這個函數可以執行用戶命令，最常用的就是調用/bin/bash並接受參數，運行起一個shell，用法如下。
fd = open(argv[1], O_RDONLY); /* 獲取namespace文件描述符 */ setns(fd, 0); /* 加入新的namespace */ execvp(argv[2], &argv[2]); /* 執行程序 */
假設編譯後的程序名稱爲setns。
# ./setns ~/uts /bin/bash # ~/uts 是綁定的/proc/27514/ns/uts
至此，你就可以在新的命名空間中執行shell命令了，在下文中會多次使用這種方式來演示隔離的效果。
（4）通過unshare()在原先進程上進行namespace隔離
最後要提的系統調用是unshare()，它跟clone()很像，不同的是，unshare()運行在原先的進程上，不需要啓動一個新進程，使用方法如下。
int unshare(int flags);
調用unshare()的主要作用就是不啓動一個新進程就可以起到隔離的效果，相當於跳出原先的namespace進行操作。這樣，你就可以在原進程進行一些需要隔離的操作。Linux中自帶的unshare命令，就是通過unshare()系統調用實現的，有興趣的讀者可以在網上搜索一下這個命令的作用。
（5）延伸閱讀：fork（）系統調用
系統調用函數fork()並不屬於namespace的API，所以這部分內容屬於延伸閱讀，如果讀者已經對fork()有足夠的瞭解，那大可跳過。
當程序調用fork（）函數時，系統會創建新的進程，爲其分配資源，例如存儲數據和代碼的空間。然後把原來的進程的所有值都複製到新的進程中，只有少量數值與原來的進程值不同，相當於克隆了一個自己。那麼程序的後續代碼邏輯要如何區分自己是新進程還是父進程呢？
fork()的神奇之處在於它僅僅被調用一次，卻能夠返回兩次（父進程與子進程各返回一次），通過返回值的不同就可以進行區分父進程與子進程。它可能有三種不同的返回值：
- 在父進程中，fork返回新創建子進程的進程ID
- 在子進程中，fork返回0
- 如果出現錯誤，fork返回一個負值
下面給出一段實例代碼，命名爲fork_example.c。
#include <unistd.h>
#include <stdio.h>
int main (){
pid_t fpid; //fpid表示fork函數返回的值
int count=0;
fpid=fork();
if (fpid < 0)printf("error in fork!");
else if (fpid == 0) {
printf("I am child. Process id is %d/n",getpid());
}
else {
printf("i am parent. Process id is %d/n",getpid());
}
return 0;
}
編譯並執行，結果如下。
root@local:~# gcc -Wall fork_example.c && ./a.out I am parent. Process id is 28365 I am child. Process id is 28366
使用fork()後，父進程有義務監控子進程的運行狀態，並在子進程退出後自己才能正常退出，否則子進程就會成爲“孤兒”進程。
下面我們將分別對六種namespace進行詳細解析。
2. UTS（UNIX Time-sharing System）namespace
UTS namespace提供了主機名和域名的隔離，這樣每個容器就可以擁有了獨立的主機名和域名，在網絡上可以被視作一個獨立的節點而非宿主機上的一個進程。
下面我們通過代碼來感受一下UTS隔離的效果，首先需要一個程序的骨架，如下所示。打開編輯器創建uts.c文件，輸入如下代碼。
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>
#define STACK_SIZE (1024 * 1024)
static char child_stack[STACK_SIZE];
char* const child_args[] = {
"/bin/bash",
NULL
};
int child_main(void* args) {
printf("在子進程中!\n");
execv(child_args[0], child_args);
return 1;
}
int main() {
printf("程序開始: \n");
int child_pid = clone(child_main, child_stack + STACK_SIZE, SIGCHLD, NULL);
waitpid(child_pid, NULL, 0);
printf("已退出\n");
return 0;
}
編譯並運行上述代碼，執行如下命令，效果如下。
root@local:~# gcc -Wall uts.c -o uts.o && ./uts.o 程序開始: 在子進程中! root@local:~# exit exit 已退出 root@local:~#
下面，我們將修改代碼，加入UTS隔離。運行代碼需要root權限，爲了防止普通用戶任意修改系統主機名導致set-user-ID相關的應用運行出錯。
//[...]
int child_main(void* arg) {
printf("在子進程中!\n");
sethostname("Changed Namespace", 12);
execv(child_args[0], child_args);
return 1;
}
int main() {
//[...]
int child_pid = clone(child_main, child_stack+STACK_SIZE,
CLONE_NEWUTS | SIGCHLD, NULL);
//[...]
}
再次運行可以看到hostname已經變化。
root@local:~# gcc -Wall namespace.c -o main.o && ./main.o 程序開始: 在子進程中! root@NewNamespace:~# exit exit 已退出 root@local:~# <- 回到原來的hostname
也許有讀者試着不加CLONE_NEWUTS參數運行上述代碼，發現主機名也變了，輸入exit以後主機名也會變回來，似乎沒什麼區別。實際上不加CLONE_NEWUTS參數進行隔離而使用sethostname已經把宿主機的主機名改掉了。你看到exit退出後還原只是因爲bash只在剛登錄的時候讀取一次UTS，當你重新登陸或者使用uname命令進行查看時，就會發現產生了變化。
Docker中，每個鏡像基本都以自己所提供的服務命名了自己的hostname而沒有對宿主機產生任何影響，用的就是這個原理。
3. IPC（Interprocess Communication）namespace
容器中進程間通信採用的方法包括常見的信號量、消息隊列和共享內存。然而與虛擬機不同的是，容器內部進程間通信對宿主機來說，實際上是具有相同PID namespace中的進程間通信，因此需要一個唯一的標識符來進行區別。申請IPC資源就申請了這樣一個全局唯一的32位ID，所以IPC namespace中實際上包含了系統IPC標識符以及實現POSIX消息隊列的文件系統。在同一個IPC namespace下的進程彼此可見，而與其他的IPC namespace下的進程則互相不可見。
IPC namespace在代碼上的變化與UTS namespace相似，只是標識位有所變化，需要加上CLONE_NEWIPC參數。主要改動如下，其他部位不變，程序名稱改爲ipc.c。（測試方法參考自：http://crosbymichael.com/creating-containers-part-1.html）
//[...]
int child_pid = clone(child_main, child_stack+STACK_SIZE,
CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD, NULL);
//[...]
我們首先在shell中使用ipcmk -Q命令創建一個message queue。
root@local:~# ipcmk -Q Message queue id: 32769
通過ipcs -q可以查看到已經開啓的message queue，序號爲32769。
root@local:~# ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x4cf5e29f 32769 root 644 0 0
然後我們可以編譯運行加入了IPC namespace隔離的ipc.c，在新建的子進程中調用的shell中執行ipcs -q查看message queue。
root@local:~# gcc -Wall ipc.c -o ipc.o && ./ipc.o 程序開始: 在子進程中! root@NewNamespace:~# ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages root@NewNamespace:~# exit exit 已退出
上面的結果顯示中可以發現，已經找不到原先聲明的message queue，實現了IPC的隔離。
目前使用IPC namespace機制的系統不多，其中比較有名的有PostgreSQL。Docker本身通過socket或tcp進行通信。
4. PID namespace
PID namespace隔離非常實用，它對進程PID重新標號，即兩個不同namespace下的進程可以有同一個PID。每個PID namespace都有自己的計數程序。內核爲所有的PID namespace維護了一個樹狀結構，最頂層的是系統初始時創建的，我們稱之爲root namespace。他創建的新PID namespace就稱之爲child namespace（樹的子節點），而原先的PID namespace就是新創建的PID namespace的parent namespace（樹的父節點）。通過這種方式，不同的PID namespaces會形成一個等級體系。所屬的父節點可以看到子節點中的進程，並可以通過信號等方式對子節點中的進程產生影響。反過來，子節點不能看到父節點PID namespace中的任何內容。由此產生如下結論（部分內容引自：http://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part）。
- 每個PID namespace中的第一個進程“PID 1“，都會像傳統Linux中的init進程一樣擁有特權，起特殊作用。
- 一個namespace中的進程，不可能通過kill或ptrace影響父節點或者兄弟節點中的進程，因爲其他節點的PID在這個namespace中沒有任何意義。
- 如果你在新的PID namespace中重新掛載/proc文件系統，會發現其下只顯示同屬一個PID namespace中的其他進程。
- 在root namespace中可以看到所有的進程，並且遞歸包含所有子節點中的進程。
到這裏，可能你已經聯想到一種在外部監控Docker中運行程序的方法了，就是監控Docker Daemon所在的PID namespace下的所有進程即其子進程，再進行刪選即可。
下面我們通過運行代碼來感受一下PID namespace的隔離效果。修改上文的代碼，加入PID namespace的標識位，並把程序命名爲pid.c。
//[...]
int child_pid = clone(child_main, child_stack+STACK_SIZE,
CLONE_NEWPID | CLONE_NEWIPC | CLONE_NEWUTS
| SIGCHLD, NULL);
//[...]
編譯運行可以看到如下結果。
root@local:~# gcc -Wall pid.c -o pid.o && ./pid.o 程序開始: 在子進程中! root@NewNamespace:~# echo $$ 1 <<--注意此處看到shell的PID變成了1 root@NewNamespace:~# exit exit 已退出
打印$$可以看到shell的PID，退出後如果再次執行可以看到效果如下。
root@local:~# echo $$ 17542
已經回到了正常狀態。可能有的讀者在子進程的shell中執行了ps aux/top之類的命令，發現還是可以看到所有父進程的PID，那是因爲我們還沒有對文件系統進行隔離，ps/top之類的命令調用的是真實系統下的/proc文件內容，看到的自然是所有的進程。
此外，與其他的namespace不同的是，爲了實現一個穩定安全的容器，PID namespace還需要進行一些額外的工作才能確保其中的進程運行順利。
（1）PID namespace中的init進程
當我們新建一個PID namespace時，默認啓動的進程PID爲1。我們知道，在傳統的UNIX系統中，PID爲1的進程是init，地位非常特殊。他作爲所有進程的父進程，維護一張進程表，不斷檢查進程的狀態，一旦有某個子進程因爲程序錯誤成爲了“孤兒”進程，init就會負責回收資源並結束這個子進程。所以在你要實現的容器中，啓動的第一個進程也需要實現類似init的功能，維護所有後續啓動進程的運行狀態。
看到這裏，可能讀者已經明白了內核設計的良苦用心。PID namespace維護這樣一個樹狀結構，非常有利於系統的資源監控與回收。Docker啓動時，第一個進程也是這樣，實現了進程監控和資源回收，它就是dockerinit。
（2）信號與init進程
PID namespace中的init進程如此特殊，自然內核也爲他賦予了特權——信號屏蔽。如果init中沒有寫處理某個信號的代碼邏輯，那麼與init在同一個PID namespace下的進程（即使有超級權限）發送給它的該信號都會被屏蔽。這個功能的主要作用是防止init進程被誤殺。
那麼其父節點PID namespace中的進程發送同樣的信號會被忽略嗎？父節點中的進程發送的信號，如果不是SIGKILL（銷燬進程）或SIGSTOP（暫停進程）也會被忽略。但如果發送SIGKILL或SIGSTOP，子節點的init會強制執行（無法通過代碼捕捉進行特殊處理），也就是說父節點中的進程有權終止子節點中的進程。
一旦init進程被銷燬，同一PID namespace中的其他進程也會隨之接收到SIGKILL信號而被銷燬。理論上，該PID namespace自然也就不復存在了。但是如果/proc/[pid]/ns/pid處於被掛載或者打開狀態，namespace就會被保留下來。然而，保留下來的namespace無法通過setns()或者fork()創建進程，所以實際上並沒有什麼作用。
我們常說，Docker一旦啓動就有進程在運行，不存在不包含任何進程的Docker，也就是這個道理。
（3）掛載proc文件系統
前文中已經提到，如果你在新的PID namespace中使用ps命令查看，看到的還是所有的進程，因爲與PID直接相關的/proc文件系統（procfs）沒有掛載到與原/proc不同的位置。所以如果你只想看到PID namespace本身應該看到的進程，需要重新掛載/proc，命令如下。
root@NewNamespace:~# mount -t proc proc /proc
root@NewNamespace:~# ps a
PID TTY STAT TIME COMMAND
1 pts/1 S 0:00 /bin/bash
12 pts/1 R+ 0:00 ps a
可以看到實際的PID namespace就只有兩個進程在運行。
注意：因爲此時我們沒有進行mount namespace的隔離，所以這一步操作實際上已經影響了 root namespace的文件系統，當你退出新建的PID namespace以後再執行ps a就會發現出錯，再次執行mount -t proc proc /proc可以修復錯誤。
（4）unshare()和setns()
在開篇我們就講到了unshare()和setns()這兩個API，而這兩個API在PID namespace中使用時，也有一些特別之處需要注意。
unshare()允許用戶在原有進程中建立namespace進行隔離。但是創建了PID namespace後，原先unshare()調用者進程並不進入新的PID namespace，接下來創建的子進程纔會進入新的namespace，這個子進程也就隨之成爲新namespace中的init進程。
類似的，調用setns()創建新PID namespace時，調用者進程也不進入新的PID namespace，而是隨後創建的子進程進入。
爲什麼創建其他namespace時unshare()和setns()會直接進入新的namespace而唯獨PID namespace不是如此呢？因爲調用getpid()函數得到的PID是根據調用者所在的PID namespace而決定返回哪個PID，進入新的PID namespace會導致PID產生變化。而對用戶態的程序和庫函數來說，他們都認爲進程的PID是一個常量，PID的變化會引起這些進程奔潰。
換句話說，一旦程序進程創建以後，那麼它的PID namespace的關係就確定下來了，進程不會變更他們對應的PID namespace。
5. Mount namespaces
Mount namespace通過隔離文件系統掛載點對隔離文件系統提供支持，它是歷史上第一個Linux namespace，所以它的標識位比較特殊，就是CLONE_NEWNS。隔離後，不同mount namespace中的文件結構發生變化也互不影響。你可以通過/proc/[pid]/mounts查看到所有掛載在當前namespace中的文件系統，還可以通過/proc/[pid]/mountstats看到mount namespace中文件設備的統計信息，包括掛載文件的名字、文件系統類型、掛載位置等等。
進程在創建mount namespace時，會把當前的文件結構複製給新的namespace。新namespace中的所有mount操作都隻影響自身的文件系統，而對外界不會產生任何影響。這樣做非常嚴格地實現了隔離，但是某些情況可能並不適用。比如父節點namespace中的進程掛載了一張CD-ROM，這時子節點namespace拷貝的目錄結構就無法自動掛載上這張CD-ROM，因爲這種操作會影響到父節點的文件系統。
2006 年引入的掛載傳播（mount propagation）解決了這個問題，掛載傳播定義了掛載對象（mount object）之間的關係，系統用這些關係決定任何掛載對象中的掛載事件如何傳播到其他掛載對象（參考自：http://www.ibm.com/developerworks/library/l-mount-namespaces/）。所謂傳播事件，是指由一個掛載對象的狀態變化導致的其它掛載對象的掛載與解除掛載動作的事件。
- 共享關係（share relationship）。如果兩個掛載對象具有共享關係，那麼一個掛載對象中的掛載事件會傳播到另一個掛載對象，反之亦然。
- 從屬關係（slave relationship）。如果兩個掛載對象形成從屬關係，那麼一個掛載對象中的掛載事件會傳播到另一個掛載對象，但是反過來不行；在這種關係中，從屬對象是事件的接收者。
一個掛載狀態可能爲如下的其中一種：
- 共享掛載（shared）
- 從屬掛載（slave）
- 共享/從屬掛載（shared and slave）
- 私有掛載（private）
- 不可綁定掛載（unbindable）
傳播事件的掛載對象稱爲共享掛載（shared mount）；接收傳播事件的掛載對象稱爲從屬掛載（slave mount）。既不傳播也不接收傳播事件的掛載對象稱爲私有掛載（private mount）。另一種特殊的掛載對象稱爲不可綁定的掛載（unbindable mount），它們與私有掛載相似，但是不允許執行綁定掛載，即創建mount namespace時這塊文件對象不可被複制。
圖1 mount各類掛載狀態示意圖
共享掛載的應用場景非常明顯，就是爲了文件數據的共享所必須存在的一種掛載方式；從屬掛載更大的意義在於某些“只讀”場景；私有掛載其實就是純粹的隔離，作爲一個獨立的個體而存在；不可綁定掛載則有助於防止沒有必要的文件拷貝，如某個用戶數據目錄，當根目錄被遞歸式的複製時，用戶目錄無論從隱私還是實際用途考慮都需要有一個不可被複制的選項。
默認情況下，所有掛載都是私有的。設置爲共享掛載的命令如下。
mount --make-shared <mount-object>
從共享掛載克隆的掛載對象也是共享的掛載；它們相互傳播掛載事件。
設置爲從屬掛載的命令如下。
mount --make-slave <shared-mount-object>
從從屬掛載克隆的掛載對象也是從屬的掛載，它也從屬於原來的從屬掛載的主掛載對象。
將一個從屬掛載對象設置爲共享/從屬掛載，可以執行如下命令或者將其移動到一個共享掛載對象下。
mount --make-shared <slave-mount-object>
如果你想把修改過的掛載對象重新標記爲私有的，可以執行如下命令。
mount --make-private <mount-object>
通過執行以下命令，可以將掛載對象標記爲不可綁定的。
mount --make-unbindable <mount-object>
這些設置都可以遞歸式地應用到所有子目錄中，如果讀者感興趣可以搜索到相關的命令。
在代碼中實現mount namespace隔離與其他namespace類似，加上CLONE_NEWNS標識位即可。讓我們再次修改代碼，並且另存爲mount.c進行編譯運行。
//[...]
int child_pid = clone(child_main, child_stack+STACK_SIZE,
CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWIPC
| CLONE_NEWUTS | SIGCHLD, NULL);
//[...]
執行的效果就如同PID namespace一節中“掛載proc文件系統”的執行結果，區別就是退出mount namespace以後，root namespace的文件系統不會被破壞，此處就不再演示了。
6. Network namespace
通過上節，我們瞭解了PID namespace，當我們興致勃勃地在新建的namespace中啓動一個“Apache”進程時，卻出現了“80端口已被佔用”的錯誤，原來主機上已經運行了一個“Apache”進程。怎麼辦？這就需要用到network namespace技術進行網絡隔離啦。
Network namespace主要提供了關於網絡資源的隔離，包括網絡設備、IPv4和IPv6協議棧、IP路由表、防火牆、/proc/net目錄、/sys/class/net目錄、端口（socket）等等。一個物理的網絡設備最多存在在一個network namespace中，你可以通過創建veth pair（虛擬網絡設備對：有兩端，類似管道，如果數據從一端傳入另一端也能接收到，反之亦然）在不同的network namespace間創建通道，以此達到通信的目的。
一般情況下，物理網絡設備都分配在最初的root namespace（表示系統默認的namespace，在PID namespace中已經提及）中。但是如果你有多塊物理網卡，也可以把其中一塊或多塊分配給新創建的network namespace。需要注意的是，當新創建的network namespace被釋放時（所有內部的進程都終止並且namespace文件沒有被掛載或打開），在這個namespace中的物理網卡會返回到root namespace而非創建該進程的父進程所在的network namespace。
當我們說到network namespace時，其實我們指的未必是真正的網絡隔離，而是把網絡獨立出來，給外部用戶一種透明的感覺，彷彿跟另外一個網絡實體在進行通信。爲了達到這個目的，容器的經典做法就是創建一個veth pair，一端放置在新的namespace中，通常命名爲eth0，一端放在原先的namespace中連接物理網絡設備，再通過網橋把別的設備連接進來或者進行路由轉發，以此網絡實現通信的目的。
也許有讀者會好奇，在建立起veth pair之前，新舊namespace該如何通信呢？答案是pipe（管道）。我們以Docker Daemon在啓動容器dockerinit的過程爲例。Docker Daemon在宿主機上負責創建這個veth pair，通過netlink調用，把一端綁定到docker0網橋上，一端連進新建的network namespace進程中。建立的過程中，Docker Daemon和dockerinit就通過pipe進行通信，當Docker Daemon完成veth-pair的創建之前，dockerinit在管道的另一端循環等待，直到管道另一端傳來Docker Daemon關於veth設備的信息，並關閉管道。dockerinit才結束等待的過程，並把它的“eth0”啓動起來。整個效果類似下圖所示。
圖2 Docker網絡示意圖
跟其他namespace類似，對network namespace的使用其實就是在創建的時候添加CLONE_NEWNET標識位。也可以通過命令行工具ip創建network namespace。在代碼中建立和測試network namespace較爲複雜，所以下文主要通過ip命令直觀的感受整個network namespace網絡建立和配置的過程。
首先我們可以創建一個命名爲test_ns的network namespace。
# ip netns add test_ns
當ip命令工具創建一個network namespace時，會默認創建一個迴環設備（loopback interface：lo），並在/var/run/netns目錄下綁定一個掛載點，這就保證了就算network namespace中沒有進程在運行也不會被釋放，也給系統管理員對新創建的network namespace進行配置提供了充足的時間。
通過ip netns exec命令可以在新創建的network namespace下運行網絡管理命令。
# ip netns exec test_ns ip link list
3: lo: <LOOPBACK> mtu 16436 qdisc noop state DOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
上面的命令爲我們展示了新建的namespace下可見的網絡鏈接，可以看到狀態是DOWN,需要再通過命令去啓動。可以看到，此時執行ping命令是無效的。
# ip netns exec test_ns ping 127.0.0.1 connect: Network is unreachable
啓動命令如下，可以看到啓動後再測試就可以ping通。
# ip netns exec test_ns ip link set dev lo up # ip netns exec test_ns ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.050 ms ...
這樣只是啓動了本地的迴環，要實現與外部namespace進行通信還需要再建一個網絡設備對，命令如下。
# ip link add veth0 type veth peer name veth1 # ip link set veth1 netns test_ns # ip netns exec test_ns ifconfig veth1 10.1.1.1/24 up # ifconfig veth0 10.1.1.2/24 up
- 第一條命令創建了一個網絡設備對，所有發送到veth0的包veth1也能接收到，反之亦然。
- 第二條命令則是把veth1這一端分配到test_ns這個network namespace。
- 第三、第四條命令分別給test_ns內部和外部的網絡設備配置IP，veth1的IP爲10.1.1.1，veth0的IP爲10.1.1.2。
此時兩邊就可以互相連通了，效果如下。
# ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_req=1 ttl=64 time=0.095 ms ... # ip netns exec test_ns ping 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. 64 bytes from 10.1.1.2: icmp_req=1 ttl=64 time=0.049 ms ...
讀者有興趣可以通過下面的命令查看，新的test_ns有着自己獨立的路由和iptables。
ip netns exec test_ns route ip netns exec test_ns iptables -L
路由表中只有一條通向10.1.1.2的規則，此時如果要連接外網肯定是不可能的，你可以通過建立網橋或者NAT映射來決定這個問題。如果你對此非常感興趣，可以閱讀Docker網絡相關文章進行更深入的講解。
做完這些實驗，你還可以通過下面的命令刪除這個network namespace。
# ip netns delete netns1
這條命令會移除之前的掛載，但是如果namespace本身還有進程運行，namespace還會存在下去，直到進程運行結束。
通過network namespace我們可以瞭解到，實際上內核創建了network namespace以後，真的是得到了一個被隔離的網絡。但是我們實際上需要的不是這種完全的隔離，而是一個對用戶來說透明獨立的網絡實體，我們需要與這個實體通信。所以Docker的網絡在起步階段給人一種非常難用的感覺，因爲一切都要自己去實現、去配置。你需要一個網橋或者NAT連接廣域網，你需要配置路由規則與宿主機中其他容器進行必要的隔離，你甚至還需要配置防火牆以保證安全等等。所幸這一切已經有了較爲成熟的方案，我們會在Docker網絡部分進行詳細的講解。
7. User namespaces
User namespace主要隔離了安全相關的標識符（identifiers）和屬性（attributes），包括用戶ID、用戶組ID、root目錄、key（指密鑰）以及特殊權限。說得通俗一點，一個普通用戶的進程通過clone()創建的新進程在新user namespace中可以擁有不同的用戶和用戶組。這意味着一個進程在容器外屬於一個沒有特權的普通用戶，但是他創建的容器進程卻屬於擁有所有權限的超級用戶，這個技術爲容器提供了極大的自由。
User namespace是目前的六個namespace中最後一個支持的，並且直到Linux內核3.8版本的時候還未完全實現（還有部分文件系統不支持）。因爲user namespace實際上並不算完全成熟，很多發行版擔心安全問題，在編譯內核的時候並未開啓USER_NS。實際上目前Docker也還不支持user namespace，但是預留了相應接口，相信在不久後就會支持這一特性。所以在進行接下來的代碼實驗時，請確保你係統的Linux內核版本高於3.8並且內核編譯時開啓了USER_NS（如果你不會選擇，可以使用Ubuntu14.04）。
Linux中，特權用戶的user ID就是0，演示的最終我們將看到user ID非0的進程啓動user namespace後user ID可以變爲0。使用user namespace的方法跟別的namespace相同，即調用clone()或unshare()時加入CLONE_NEWUSER標識位。老樣子，修改代碼並另存爲userns.c，爲了看到用戶權限(Capabilities)，可能你還需要安裝一下libcap-dev包。
首先包含以下頭文件以調用Capabilities包。
#include <sys/capability.h>
其次在子進程函數中加入geteuid()和getegid()得到namespace內部的user ID，其次通過cap_get_proc()得到當前進程的用戶擁有的權限，並通過cap_to_text（）輸出。
int child_main(void* args) {
printf("在子進程中!\n");
cap_t caps;
printf("eUID = %ld; eGID = %ld; ",
(long) geteuid(), (long) getegid());
caps = cap_get_proc();
printf("capabilities: %s\n", cap_to_text(caps, NULL));
execv(child_args[0], child_args);
return 1;
}
在主函數的clone()調用中加入我們熟悉的標識符。
//[...]
int child_pid = clone(child_main, child_stack+STACK_SIZE,
CLONE_NEWUSER | SIGCHLD, NULL);
//[...]
至此，第一部分的代碼修改就結束了。在編譯之前我們先查看一下當前用戶的uid和guid，請注意此時我們是普通用戶。
$ id -u 1000 $ id -g 1000
然後我們開始編譯運行，並進行新建的user namespace，你會發現shell提示符前的用戶名已經變爲nobody。
sun@ubuntu$ gcc userns.c -Wall -lcap -o userns.o && ./userns.o 程序開始: 在子進程中! eUID = 65534; eGID = 65534; capabilities: = cap_chown,cap_dac_override,[...]37+ep <<--此處省略部分輸出，已擁有全部權限 nobody@ubuntu$
通過驗證我們可以得到以下信息。
- user namespace被創建後，第一個進程被賦予了該namespace中的全部權限，這樣這個init進程就可以完成所有必要的初始化工作，而不會因權限不足而出現錯誤。
- 我們看到namespace內部看到的UID和GID已經與外部不同了，默認顯示爲65534，表示尚未與外部namespace用戶映射。我們需要對user namespace內部的這個初始user和其外部namespace某個用戶建立映射，這樣可以保證當涉及到一些對外部namespace的操作時，系統可以檢驗其權限（比如發送一個信號或操作某個文件）。同樣用戶組也要建立映射。
- 還有一點雖然不能從輸出中看出來，但是值得注意。用戶在新namespace中有全部權限，但是他在創建他的父namespace中不含任何權限。就算調用和創建他的進程有全部權限也是如此。所以哪怕是root用戶調用了clone()在user namespace中創建出的新用戶在外部也沒有任何權限。
- 最後，user namespace的創建其實是一個層層嵌套的樹狀結構。最上層的根節點就是root namespace，新創建的每個user namespace都有一個父節點user namespace以及零個或多個子節點user namespace，這一點與PID namespace非常相似。
接下來我們就要進行用戶綁定操作，通過在/proc/[pid]/uid_map和/proc/[pid]/gid_map兩個文件中寫入對應的綁定信息可以實現這一點，格式如下。
ID-inside-ns ID-outside-ns length
寫這兩個文件需要注意以下幾點。
- 這兩個文件只允許由擁有該user namespace中CAP_SETUID權限的進程寫入一次，不允許修改。
- 寫入的進程必須是該user namespace的父namespace或者子namespace。
- 第一個字段ID-inside-ns表示新建的user namespace中對應的user/group ID，第二個字段ID-outside-ns表示namespace外部映射的user/group ID。最後一個字段表示映射範圍，通常填1，表示只映射一個，如果填大於1的值，則按順序建立一一映射。
明白了上述原理，我們再次修改代碼，添加設置uid和guid的函數。
//[...]
void set_uid_map(pid_t pid, int inside_id, int outside_id, int length) {
char path[256];
sprintf(path, "/proc/%d/uid_map", getpid());
FILE* uid_map = fopen(path, "w");
fprintf(uid_map, "%d %d %d", inside_id, outside_id, length);
fclose(uid_map);
}
void set_gid_map(pid_t pid, int inside_id, int outside_id, int length) {
char path[256];
sprintf(path, "/proc/%d/gid_map", getpid());
FILE* gid_map = fopen(path, "w");
fprintf(gid_map, "%d %d %d", inside_id, outside_id, length);
fclose(gid_map);
}
int child_main(void* args) {
cap_t caps;
printf("在子進程中!\n");
set_uid_map(getpid(), 0, 1000, 1);
set_gid_map(getpid(), 0, 1000, 1);
printf("eUID = %ld; eGID = %ld; ",
(long) geteuid(), (long) getegid());
caps = cap_get_proc();
printf("capabilities: %s\n", cap_to_text(caps, NULL));
execv(child_args[0], child_args);
return 1;
}
//[...]
編譯後即可看到user已經變成了root。
$ gcc userns.c -Wall -lcap -o usernc.o && ./usernc.o 程序開始: 在子進程中! eUID = 0; eGID = 0; capabilities: = [...],37+ep root@ubuntu:~#
至此，你就已經完成了綁定的工作，可以看到演示全程都是在普通用戶下執行的。最終實現了在user namespace中成爲了root而對應到外面的是一個uid爲1000的普通用戶。
如果你要把user namespace與其他namespace混合使用，那麼依舊需要root權限。解決方案可以是先以普通用戶身份創建user namespace，然後在新建的namespace中作爲root再clone()進程加入其他類型的namespace隔離。
講完了user namespace，我們再來談談Docker。雖然Docker目前尚未使用user namespace，但是他用到了我們在user namespace中提及的Capabilities機制。從內核2.2版本開始，Linux把原來和超級用戶相關的高級權限劃分成爲不同的單元，稱爲Capability。這樣管理員就可以獨立對特定的Capability進行使能或禁止。Docker雖然沒有使用user namespace，但是他可以禁用容器中不需要的Capability，一次在一定程度上加強容器安全性。
當然，說到安全，namespace的六項隔離看似全面，實際上依舊沒有完全隔離Linux的資源，比如SELinux、 Cgroups以及/sys、/proc/sys、/dev/sd*等目錄下的資源。關於安全的更多討論和講解，我們會在後文中接着探討。
8. 總結
本文從namespace使用的API開始，結合Docker逐步對六個namespace進行講解。相信把講解過程中所有的代碼整合起來，你也能實現一個屬於自己的“shell”容器了。雖然namespace技術使用起來非常簡單，但是要真正把容器做到安全易用卻並非易事。PID namespace中，我們要實現一個完善的init進程來維護好所有進程；network namespace中，我們還有複雜的路由表和iptables規則沒有配置；user namespace中還有很多權限上的問題需要考慮等等。其中有些方面Docker已經做的很好，有些方面也纔剛剛開始。希望通過本文，能爲大家更好的理解Docker背後運行的原理提供幫助。