我就先來跟你說說這個“邊界”的實現手段。
假如，現在你要寫一個計算加法的小程序，這個程序需要的輸入來自於一個文件，計算完成後的結果則輸出到另一個文件中。
由於計算機只認識 0 和 1，所以無論用哪種語言編寫這段代碼，最後都需要通過某種方式翻譯成二進制文件，才能在計算機操作系統中運行起來。
而爲了能夠讓這些代碼正常運行，我們往往還要給它提供數據，比如我們這個加法程序所需要的輸入文件。
這些數據加上代碼本身的二進制文件，放在磁盤上，就是我們平常所說的一個“程序”，也叫代碼的可執行鏡像（executable image）。
然後，我們就可以在計算機上運行這個“程序”了。首先，操作系統從“程序”中發現輸入數據保存在一個文件中，所以這些數據就會被加載到內存中待命。
同時，操作系統又讀取到了計算加法的指令，這時，它就需要指示 CPU 完成加法操作。而 CPU 與內存協作進行加法計算，又會使用寄存器存放數值、內存堆棧保存執行的命令和變量。
同時，計算機裏還有被打開的文件，以及各種各樣的 I/O 設備在不斷地調用中修改自己的狀態。就這樣，一旦“程序”被執行起來，它就從磁盤上的二進制文件，變成了計算機內存中的數據、寄存器裏的值、堆棧中的指令、被打開的文件，以及各種設備的狀態信息的一個集合。
像這樣一個程序運行起來後的計算機執行環境的總和，就是我們今天的主角：進程。所以，對於進程來說，它的靜態表現就是程序，平常都安安靜靜地待在磁盤上；而一旦運行起來，它就變成了計算機裏的數據和狀態的總和，這就是它的動態表現。
而容器技術的核心功能，就是通過約束和修改進程的動態表現，從而爲其創造出一個“邊界”。對於 Docker 等大多數 Linux 容器來說，Cgroups 技術是用來製造約束的主要手段，而 Namespace 技術則是用來修改進程視圖的主要方法。你可能會覺得 Cgroups 和 Namespace 這兩個概念很抽象，別擔心，接下來我們一起動手實踐一下，你就很容易理解這兩項技術了。
假設你已經有了一個 Linux 操作系統上的 Docker 項目在運行，比如我的環境是 Ubuntu 16.04 和 Docker CE 18.05。
接下來，讓我們首先創建一個容器來試試。
$ docker run -it busybox /bin/sh
/ #
這個命令是 Docker 項目最重要的一個操作，即大名鼎鼎的 docker run。
而 -it 參數告訴了 Docker 項目在啓動容器後，需要給我們分配一個文本輸入 / 輸出環境，也就是 TTY，跟容器的標準輸入相關聯，這樣我們就可以和這個 Docker 容器進行交互了。
而 /bin/sh 就是我們要在 Docker 容器裏運行的程序。
所以，上面這條指令翻譯成人類的語言就是：請幫我啓動一個容器，在容器裏執行 /bin/sh，並且給我分配一個命令行終端跟這個容器交互。
這樣，我的 Ubuntu 16.04 機器就變成了一個宿主機，而一個運行着 /bin/sh 的容器，就跑在了這個宿主機裏面。
上面的例子和原理，如果你已經玩過 Docker，一定不會感到陌生。
此時，如果我們在容器裏執行一下 ps 指令，就會發現一些更有趣的事情：
/ # ps
PID USER TIME COMMAND
1 root 0:00 /bin/sh
10 root 0:00 ps
可以看到，我們在 Docker 裏最開始執行的 /bin/sh，就是這個容器內部的第 1 號進程（PID=1），而這個容器裏一共只有兩個進程在運行。
這就意味着，前面執行的 /bin/sh，以及我們剛剛執行的 ps，已經被 Docker 隔離在了一個跟宿主機完全不同的世界當中。
這究竟是怎麼做到的呢？本來，每當我們在宿主機上運行了一個 /bin/sh 程序，操作系統都會給它分配一個進程編號，比如 PID=100。
這個編號是進程的唯一標識，就像員工的工牌一樣。
所以 PID=100，可以粗略地理解爲這個 /bin/sh 是我們公司裏的第 100 號員工，而第 1 號員工就自然是比爾 · 蓋茨這樣統領全局的人物。
而現在，我們要通過 Docker 把這個 /bin/sh 程序運行在一個容器當中。
這時候，Docker 就會在這個第 100 號員工入職時給他施一個“障眼法”，讓他永遠看不到前面的其他 99 個員工，更看不到比爾 · 蓋茨。
這樣，他就會錯誤地以爲自己就是公司裏的第 1 號員工。這種機制，其實就是對被隔離應用的進程空間做了手腳，使得這些進程只能看到重新計算過的進程編號，比如 PID=1。
可實際上，他們在宿主機的操作系統裏，還是原來的第 100 號進程。這種技術，就是 Linux 裏面的 Namespace 機制。而 Namespace 的使用方式也非常有意思：它其實只是 Linux 創建新進程的一個可選參數。我們知道，在 Linux 系統中創建線程的系統調用是 clone()，比如：
int pid = clone(main_function, stack_size, SIGCHLD, NULL);
這個系統調用就會爲我們創建一個新的進程，並且返回它的進程號 pid。而當我們用 clone() 系統調用創建一個新進程時，就可以在參數中指定 CLONE_NEWPID 參數，比如：
int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);
這時，新創建的這個進程將會“看到”一個全新的進程空間，在這個進程空間裏，它的 PID 是 1。
之所以說“看到”，是因爲這只是一個“障眼法”，在宿主機真實的進程空間裏，這個進程的 PID 還是真實的數值，比如 100。當然，我們還可以多次執行上面的 clone() 調用，這樣就會創建多個 PID Namespace，而每個 Namespace 裏的應用進程，都會認爲自己是當前容器裏的第 1 號進程，它們既看不到宿主機裏真正的進程空間，也看不到其他 PID Namespace 裏的具體情況。
而除了我們剛剛用到的 PID Namespace，Linux 操作系統還提供了 Mount、UTS、IPC、Network 和 User 這些 Namespace，用來對各種不同的進程上下文進行“障眼法”操作。
比如，Mount Namespace，用於讓被隔離進程只看到當前 Namespace 裏的掛載點信息；Network Namespace，用於讓被隔離進程看到當前 Namespace 裏的網絡設備和配置。
這，就是 Linux 容器最基本的實現原理了。所以，Docker 容器這個聽起來玄而又玄的概念，實際上是在創建容器進程時，指定了這個進程所需要啓用的一組 Namespace 參數。這樣，容器就只能“看”到當前 Namespace 所限定的資源、文件、設備、狀態，或者配置。而對於宿主機以及其他不相關的程序，它就完全看不到了。所以說，容器，其實是一種特殊的進程而已。總結談到爲“進程劃分一個獨立空間”的思想，相信你一定會聯想到虛擬機。
而且，你應該還看過一張虛擬機和容器的對比圖。
這幅圖的左邊，畫出了虛擬機的工作原理。其中，名爲 Hypervisor 的軟件是虛擬機最主要的部分。
它通過硬件虛擬化功能，模擬出了運行一個操作系統需要的各種硬件，比如 CPU、內存、I/O 設備等等。
然後，它在這些虛擬的硬件上安裝了一個新的操作系統，即 Guest OS。
這樣，用戶的應用進程就可以運行在這個虛擬的機器中，它能看到的自然也只有 Guest OS 的文件和目錄，以及這個機器裏的虛擬設備。
這就是爲什麼虛擬機也能起到將不同的應用進程相互隔離的作用。而這幅圖的右邊，則用一個名爲 Docker Engine 的軟件替換了 Hypervisor。
這也是爲什麼，很多可是這樣的說法，卻並不嚴謹。
在理解了 Namespace 的工作方式之後，你就會明白，跟真實存在的虛擬機不同，在使用 Docker 的時候，並沒有一個真正的“Docker 容器”運行在宿主機裏面。
Docker 項目幫助用戶啓動的，還是原來的應用進程，只不過在創建這些進程時，Docker 爲它們加上了各種各樣的 Namespace 參數。這時，這些進程就會覺得自己是各自 PID Namespace 裏的第 1 號進程，只能看到各自 Mount Namespace 裏掛載的目錄和文件，只能訪問到各自 Network Namespace 裏的網絡設備，就彷彿運行在一個個“容器”裏面，與世隔絕。不過，相信你此刻已經會心一笑：這些不過都是“障眼法”罷了。
思考題
鑑於我對容器本質的講解，你覺得上面這張容器和虛擬機對比圖右側關於容器的部分，怎麼畫才更精確？
你是否知道最新的 Docker 項目默認會爲容器啓用哪些 Namespace 嗎？
人會把 Docker 項目稱爲“輕量級”虛擬化技術的原因，實際上就是把虛擬機的概念套在了容器上。