Docker 1.11 增強功能：直接在runC和containerd構建引擎
【編者的話】Docker的更新都會伴隨著周圍工具產品的升級，這次也不例外。1.11直接允許使用runC和containerd構建引擎，runC和containerd也跟隨升級，這次還升級了Compose和Swarm，跟小編來看下大致的介紹吧
最近Docker對整個平臺發布了新的版本，Docker引擎升級至 1.11版本 ，Swarm升級至1.2版本，Compose和Machine也分別升級至1.7和0.7版本。這次升級也開始支持Mac和Windows 10 Bete版的操作系統。上述還只是這個升級的“冰山一角”，不過對于用戶來說還算適度更新吧。底層的引擎經過大規模的重構保證了首個兼容（ Open Container Initiative ）OCI的運行時。更具體的說，現在用戶可以直接在 runC 和 containerd 上構建引擎了。
OCI，runC，containerd....這是怎么了？
Open Container Initiative是什么？
OCI在2015年6月宣布成立，旨在圍繞容器格式和運行時制定一個開放的工業化標準。OCI的目標是為了避免容器的生態分裂為“小生態王國”，確保一個引擎上構建的容器可以運行在其他引擎之上。這是實現容器可移植性至關重要的部分。只要Docker是唯一的運行時，它就是事實上的行業標準。但是隨著可用（和采納）和其他引擎，有必要從技術的角度上定義“什么是容器”，以便不同實現上可以達成最終的一致。
什么是runC？
runC是一個輕量級的工具，它是用來運行容器的，只用來做這一件事，并且這一件事要做好。如果你了解過Docker引擎早期的歷史，你應該知道當時啟動和管理一個容器需要使用LXC工具集，然后在使用 libcontainer 。 libcontainer 就是使用類似 cgroup 和 namespace 一樣的Linux內核設備接口編寫的一小段代碼，它是容器的基本構建模塊。為了是過程更加簡單，runC基本上是一個小命令行工具且它可以不用通過Docker引擎，直接就可以使用容器。這是一個獨立的二進制文件，使用OCI容器就可以運行它。更多信息，請閱讀 Solomon Hykes 的 更多博客 。
什么是containerd?
containerd 是一個簡單的守護進程，它可以使用runC管理容器，使用gRPC暴露容器的其他功能。相比較Docker引擎，使用 gRPC ，containerd暴露出針對容器的 增刪改查的接口 ，然而Docker引擎只是使用 full-blown HTTP API接口對Images，Volumes，network，builds等暴露出這些方法。獲得更過的細節解釋，請參考 Michael Crosby 的 博客 。
它們之間的關聯？
正如上面提到的，Docker引擎可以在runC和containerd上構建。1.11之前，引擎只用于Volums,networks,containerd等。
現在它所有的工作分為四個部分：引擎，containerd，runC，containerd-shim，后者位于runC與containerd之間的部分。
Docker引擎仍然管理者images，然后移交給containerd運行，containerd再使用runC運行容器。
containerd只處理containers管理容器的開始，停止，暫停和銷毀。由于容器運行時是孤立的引擎，引擎
最終能夠啟動和升級而無需重新啟動容器。還有一些其他的好處是：
當linux的代碼被刪除和其他容器運行時的這些改變時能夠保持一種統一的Docker UI命令（表面上看一切都是一樣的）
由于現在有四個組件，以前只是一個單獨的“docker”二進制文件，現在查分各自功能為四個文件： docker , docker-containerd ,
docker-containerd-shim ,和 docker-runc 。如果你在主機上，就可以通過 ps as grep docker 獲取正在運行的進程。
下面是docker三周年vote app的例子正在運行中，如果想在此機器上獲取所有運行的docker進程，你能看到前面提到的四個二進制進程。
如果在Mac或者Windows上，你可以運行 docker run -it — pid host -v /:/hostfs — net host alpine chroot /hostfs 和 ps ax | grep docker 獲得容器中正在運行的進程。-pid host 獲取容器用戶的主機PID命名空間，類似的— net host參數獲取主機UTS的命名空間。更多的信息可以參考引 擎使用手冊 。查看 /var/run/docker/libcontainerd ，你能查到所有正在運行的容器和containerd sock 文件。
其他更新
Networking
Networking 在新版本中得到了改善，1.10版本的引擎新增了DNS服務器，通過IP地址允許每一個容器可以定位到容器名字和網絡別名。當眾多容器擁有相同的網絡別名，DNS服務器將會返回一個狀態記錄。在1.11版本的引擎中，DNS服務器按照隨機的順序返回所有的記錄。這允許您使用DNS輪循作為基本的負載平衡和故障轉移機制。如果多次ping網絡別名，你會得到不同的結果。不管是均衡還是不均衡，你都會在一個容器中得到所有的隨機變化結果。請記住:容器名稱的解析只能在Custom networks（使用docker network create創建的networks）上工作。請看下面關于創建network的例子，使用兩個Nginx的容器，運行在同一個別名的網絡上。
此處之外，networks（還有volumes）現在可以有影像似的標簽了。
Compose 1.7
新版本Compose有好幾個改善的地方包括不在通過命令行傳遞參數讀取，而是直接讀取環境變量中的參數。
接下來，秉承 docker-compose up ，在可能和依賴秩序上，compose仍舊受尊敬。
例如，如果你在redis中查看一個Docker compose文件，你可以在database層次或者前端，一旦redis開始啟動，他們就可以同時進行。
另外還有幾處變化，新版本增加了 docker-compose 命令。還有兩個新的命令新增： docker-compose up — build 和 docker-compose exec 。用戶經常運行 docker-compose build 然后運行 docker-compose up ,在編輯Dockerfile時，增加了跟build類似的up參數。另外一個exec命令也有相同的功能。除此之外， docker-compose logs 模仿 docker logs 命令不再列舉整個容器的日志而且流處理日志，而是只會展示日志。你可以使用 docker-compose logs -f 命令像 docker logs 一樣查看流式日志。 docker-compose logs 目前可以檢測到你什么時間添加新的容器到應用程序，而且使用 docker-compose logs -f 自動添加它們的日志到流中。
Swarm 1.2
Swarm1.1新增了容器調度的試驗支持，在1.2中不再是試驗版了。在swarm1.1之前，如果使用swarm啟動10臺服務器，開始100個前端網頁進程，其中一個服務中斷掉，什么也不會發生。現在容器能針對運行失敗的節點自動重啟。這可以通過設置一個環境變量或者標簽容器，這樣容器啟動時就可以被監控到。
`docker run -d -e reschedule:on-node-failure <image>`
`docker run -d -l ‘com.docker.swarm.reschedule-policy=[“on-node-failure”]’ <image>`
Swarm管理員可以設置追蹤到每一個節點，它會持續向每一個節點檢測心跳包，而且檢測到反應遲鈍的請求就會嘗試重啟這個節點。如果這個節點運行容器接收到重新安排的策略，這個容器將會重新安排到其他地方。swarm的狀態可以通過查詢日志文件獲取，可以有很多管理員。
Registry
在以前，如果你在自己的registry刪除鏡像，結果是邏輯刪除這個鏡像。但是這個鏡像的數據文件還在。數據文件失去引用而已。如果考慮到程序，當你刪除一個變量時，并不能立即刪除這個數據。這里有一個內存的管理，我們后續可以手動刪除或者垃圾回收機制自動處理。現在這些全部都有registry做了。
Docker for Mac and Windows
上個月，Docker放出一個測試版本，宣布開始支持Mac和Windows。Mac和Windows上的Docker不用做任何的更改，但是提高了用戶體驗度。它們提供一個在linux上運行原生Docker非常相似的體驗，除非你想運行多個主機環境，這都不需要借助virtualBox。我在Mac上運行了Docker，然后寫了這邊博客， “Say Hello to Docker for Mac”.
自從Docker1.1發布，現在Docker引入很多新的功能。Mac版本的Docker作為Beta9,localhost 用來做端口轉發，而不是使用有本地linux感覺的docker.local。Beta10版本支持令牌驗證通道HTTPS。Beta11版本更新了內核和Compose。通過發布日志可以看到所有的新特性，更新還有一些關于Mac和Windows眾所周知的問題。
來自： http://dockone.io/article/1327