提示
本文最初發表於華來四公衆號，請掃描以下二維碼關注。給盆盆發微信(微信號：markpah)，即可要求加入Windows Docker微信羣、或者微軟混合雲微信羣。您還可以加入華來四QQ羣(423730487)，以參加在線視頻講座。
衆所周知，Docker能打通開發和運維的任督二脈，所謂DevOps是也。有朋友說，這符合王陽明的"知行合一"之教。
而Windows Server 2016 TP4內置的Windows Docker亦已經出來一段時間，這裏就來和諸公彙報一下測試結果。
Linux和Windows，容器裏各有多少進程？
在安裝配置Container Host的時候，經常報錯Container OS Image下載失敗(沒辦法，牆內的緣故)。
什麼是Container OS？顧名思義，是從容器角度看到的OS。
Container OS實際是應用所依賴的用戶模式(User mode)OS組件，對於Windows容器來說，例如ntdll.dll、kernel32.dll或者coresystem.dll之類的System DLL。主機上的所有容器共享內核模式(Kernel mode)OS組件，對於Windows，就是ntoskrnl.exe，還有驅動等。
例如對於以下命令，意味着Windows系統從docker映像中獲取Windows Server Core的用戶模式OS組件，並啓動cmd獲得Shell。
docker run -it windowsservercore cmd
Linux也是一理，如果運行以下命令，意味着從docker映像中獲取Ubuntu的用戶模式組件，並且啓動Bash Shell。
docker run -it ubuntu /bin/bash
對於以上兩個容器，Linux容器裏的進程比較少，可以參考以下截圖：
而Windows容器，則情況略有不同。
在Windows主機上啓動Process Explorer，可以看到這個Windows容器的進程相對多一些：
這是因爲在Windows系統中，需要給應用提供一些用戶模式的系統服務，例如DNS、DHCP、RPC等服務，這樣從容器的角度來看，容器獲得了自己獨有的服務(一般是在各自的svchost裏運行)，構成了所謂的Container OS。
我們可以用PowerShell命令查看容器內部啓動的Windows服務，大概有27個，參考附圖。
很可惜，這個版本的Windows docker裏，雖然有遠程桌面服務，但是目前還不支持遠程桌面到容器，所以無法使用容器應用的圖形化界面。
容器裏的應用，到底應該啓動多少Windows服務？由於Windows服務的具體作用是非文檔化的，所以不像Linux可以做到最精簡。但是由於這些服務幾乎不佔用什麼額外的資源，對於容器性能沒有影響。
Windows容器的進程間怎麼隔離的？
在最新的測試版本里，容器對象的權限設置有了改變，只有SYSTEM權限才能查看。所以要查看Windows容器的進程隔離，需要用SYSTEM權限啓動Winobj。這可以藉助Psexec來實現：
Psexec -i -d -s winobj.exe
可以看到Windows對象空間裏多了一個Containers的節點，其下有若干個GUID分支，這些GUID代表系統裏的容器。其下每個容器有自己獨立的BaseNamedObjects等命名空間，包括互斥信號量、內存Section、事件等。
可以用PowerShell查看容器的GUID，參考附圖。
每個容器節點下，有自己的Session分支，例如該容器，佔據了Windows系統的Session 2。如附圖所示。
這就是爲什麼，不管用任務管理器，還是PowerShell，抑或是Process Explorer等工具，我們都在Windows主機裏看到容器裏的所有進程都會標記Session爲2。
藉助Process Explorer，我們可以看到容器裏的進程，所打開的Handle，其中就指向先前所看到的Windows容器對象命名空間。
同時還能看到，容器進程所在的WindowStation並不是WinSta0，而是Service-0x0-3e7$，3e7的10進制等於999，等於九五之尊，這是SYSTEM服務所在的窗口站。所以容器進程無法在Windows桌面上擁有圖形化界面。
還可以查看一個有意義的對象，Windows容器所掛載的主機目錄，類似於Linux容器的Volume。
Windows容器的文件系統怎麼隔離的？
和Linux一樣，Windows容器映像採用分層的文件系統，基於映像創建容器後，相當於在只讀的分層文件系統上再覆蓋一層可讀寫的文件系統層。如果要修改的文件在最上層的可讀寫層裏沒有，則沿着分層的Layer找到目標文件後，將其用COW(Copy on write：寫時複製)複製到可讀寫層再修改。
讓我們進入到Windows主機的以下目錄：
C:\ProgramData\Microsoft\Windows\Hyper-V\Containers
該目錄下列出所有通過PowerShell命令創建的容器文件。其下有文件夾和文件，都以容器的GUID來命名。
其中的926A300B-ACB7-4B28-9D86-45BF82C1211C.vhdx就是該容器的最上層的可讀寫層，是一個VHDX文件。
記住該可讀寫層並不是一個完整的文件系統，它需要和Image的現有文件系統組成Union File System。如果嘗試雙擊該VHDX(只能嘗試掛載停止狀態的容器VHDX)，試圖掛載到Windows系統，會彈出以下報錯信息，提示該虛擬硬盤無法掛載。
Image的文件系統位於以下路徑(Windows Server Core的Container OS文件)：
C:\ProgramData\Microsoft\Windows\Images\CN=Microsoft_WindowsServerCore_10.0.10586.0\Files
如果用Process Explorer查看容器進程訪問的Dll，可以看到其訪問的路徑爲Container OS文件。
如果是用docker命令創建的進程，道理類似，但是其可讀寫層文件系統位於以下路徑：
C:\ProgramData\docker\windowsfilter
Windows容器還有註冊表
和Linux不一樣，Windows容器需要考慮註冊表的隔離問題。
下面讓我們進入PowerShell命令創建的Windows容器文件夾內部。
C:\ProgramData\Microsoft\Windows\Hyper-V\Containers\926A300B-ACB7-4B28-9D86-45BF82C1211C\Hives
在這個Hives文件夾下方，有很多命名爲*_Delta的文件，這是容器所訪問的註冊表配置單元文件。
從命名方式中可以看到，容器的註冊表和文件系統一樣，也採用分層架構，最上層的是可讀寫的註冊表命名空間。而Image映像也有隻讀部分的註冊表空間，路徑如下。
C:\ProgramData\Microsoft\Windows\Images\CN=Microsoft_WindowsServerCore_10.0.10586.0\Hives
在Process Explorer裏可以看到可讀寫層、只讀層註冊表合併後所加載的內容。
Docker命令所創建的容器，方法類似，位於類似以下路徑：
Windows容器的資源限制
大家知道，Docker可以調用CGroup技術來限制Linux容器的CPU、內存等資源佔用。而在Windows容器裏，內存資源的限制，則是通過Windows的JO(作業對象)技術來實現。
可以參考以下技術來限定Windows容器的CPU、內存和磁盤IO。例如可以將容器的內存限定爲最大佔用爲5GB。
https://msdn.microsoft.com/en-us/virtualization/windowscontainers/management/manage_resources?f=255&MSPPError=-2147217396
然後用Process Explorer打開任意一個容器進程的屬性對話框，切換到Job標籤頁。
可以看到所有容器進程共享一個作業對象，而且該作業對象的內存限額(Job Memory Limit)爲5GB。
寫到現在，手都酸了，這次就到這裏吧，下次有空再一起討論容器的網絡隔離，和Azure container service整合等高大上的技術吧。