6月16日，Docker 1.7.0 發布，重磅炸彈在Docker圈引起巨大轟動，同時也為6月22日在舊金山舉辦的DockerCon大會獻禮。在本文中，DaoCloud團隊成員孫宏亮帶領您深度解析Docker 1.7.0。
早在Docker 1.6.0之際，Docker官方的工程師即宣稱：1.7.0版本將會帶來很大的變化，包括：Docker的bug修改以及功能添加;并且還體現在Docker的架構上，如網絡模塊等。
話不多說，趕緊讓我們進入Docker 1.7.0的深度解析。從Docker的版本變更日志來看，Docker 1.7.0在四個方面會有或多或少的變動，分別是：Docker運行時(Runtime)，Docker的代碼變化，Docker的builder模塊，以及Docker的bug修復。
本文主要涉及Docker 1.7.0的runtime。
1. 增添了一個仍然處于試驗階段的特性：支持out of process的數據卷插件。
何為試驗性質的特性，換言之Docker的這部分特性還不支持在生產環境中采用，這些特性更多的希望用戶僅僅在測試環境，以及沙箱環境中采用。試驗性特性完全是Docker 1.7.0的一大亮點。
在以上的基礎上理解out-of-process，就容易很多，插件本身與Docker Daemon無耦合，即插即用，在Docker Daemon范疇之外發揮作用。
目前Docker的試驗性特性可以從兩個方面來描述，首先Docker目前已經支持用戶自定義第三方插件的使用;另外在這基礎上，Docker自身支持了容器數據卷volume插件。此外，Docker還定義了一整套與插件相關的API，方便用戶使用。當然，相信后續在該領域，不論是Docker 官方，還是整個社區，都會不斷有新的插件誕生。值得一提的，在數據卷volume插件方面，出現了Flocker的身影，這也意味著容器的數據存儲問題，真正被提上臺面，并由相應合理的解決方案。
2.從docker daemon的角度，添加了userland-proxy的起停開關。
首先介紹userland- proxy一直以來的作用。眾所周知，在Docker的橋接bridge網絡模式下，Docker容器時是通過宿主機上的NAT模式，建立與宿主機之外世界的通信。然而在宿主機上，一般情況下，進程可以通過三種方式訪問容器，分別為：:, :,以及<0.0.0.0>:。實際上，最后一種方式的成功訪問完全得益于userland-proxy，即 Docker Daemon在啟動一個Docker容器時，每為容器在宿主機上映射一個端口，都會啟動一個docker-proxy進程，實現宿主機上0.0.0.0地址上對容器的訪問代理。
當時引入userland-proxy時，也許是因為設計者意識到了0.0.0.0地址對容器訪問上的功能缺陷。然而，在docker- proxy加入Docker之后相當長的一段時間內。Docker愛好者普遍感受到，很多場景下，docker-proxy并非必需，甚至會帶來一些其他的弊端。
影響較大的場景主要有兩種。
第一，單個容器需要和宿主機有多個端口的映射。此場景下，若容器需要映射1000個端口甚至更多，那么宿主機上就會創建1000個甚至更多的 docker-proxy進程。據不完全測試，每一個docker-proxy占用的內存是4-10MB不等。如此一來，直接消耗至少4-10GB內存，以及至少1000個進程，無論是從系統內存，還是從系統CPU資源來分析，這都會是很大的負擔。
第二，眾多容器同時存在于宿主機的情況，單個容器映射端口極少。這種場景下，關于宿主機資源的消耗并沒有如第一種場景下那樣暴力，而且一種較為慢性的方式侵噬資源。
如今，Docker Daemon引入- -userland-proxy這個flag，將以上場景的控制權完全交給了用戶，由用戶決定是否開啟，也為用戶的場景的proxy代理提供了靈活性。
3. docker exec命令增加- -user參數，用戶控制docker exec在容器中執行命令時所處的用戶。
自從docker 1.3.0引入docker exec之后，用戶對容器的操縱能力被大大釋放，容器對用戶而言不再是一個運行的黑盒。然而，docker exec帶來巨大好處的同時，我們也能看到這其中的一些瑕疵，當然Docker社區也在不斷地完善docker exec。
首先，docker exec在容器中運行的進程會以root權限運行，在權限方面缺乏靈活性的同時，容器的安全很有可能失控。參數- -user恰好彌補了這方面的不足。其次，docker exec的存在打破了容器內進程呈現樹狀關系的現狀，而設計初期Docker容器的很多概念均以樹的思想從init process入手，因此目前docker exec的進程并不能和原生態容器進程完全一樣地被Docker Daemon管理。
4. 增強Docker容器網關地址的配置廣度。
Docker 1.7.0發布之前，在bridge橋接模式下，Docker容器的網關地址是默認生成的，一般為Docker環境中的docker0網橋地址。從容器通信的角度而言，默認的方式已經可以滿足需要。但是，我們依然可以發現，這種模式存在一些弊端，比如網絡配置的靈活性以及網絡安全性。
Docker容器的網絡一直廣受關注，缺乏可配置的特性，在如今的軟件發展中，幾乎就意味著封閉。 --default-gateway 以及--default-gateway-v6 這兩個參數，很大程度上提高了用戶自定義容器網絡的靈活性，用戶更多場景的覆蓋，似乎從Docker的發展中若影若現。結合最近幾次新版本，功能的增強與豐富，不難猜測，Docker的企業化以及生產化，已經更上一層樓。
默認網關的設置，為什么說會和容器的網絡安全相關呢?過去很長一段時間內，docker0作為容器的網關地址，這種方式將容器與宿主機的耦合關系體現的很徹底。docker0作為宿主機上的網絡接口，充當容器與宿主機的橋梁。然而，也正是橋梁的存在，使得容器內部進程很容易穿過網關，到達宿主機，此過程并非對用戶透明。
5. 容器CFS quota的支持
完善Docker對內核cgoups的支持，指的是對于一個組內的進程組在一個周期內被內核CFS調度算法調度的時間限額，單位為微秒。該配置項在cgroups中相應的文件為/sys/fs/cgroup/cpu/cpu.cfs_quota_us。
6. 容器磁盤IO限制的支持
眾所周知，容器將會為用戶提供一個隔離的運行環境，容器內部的進程或者進程組使用資源時將受到限制，這樣的資源，包括：內存資源(物理內存以及swap)，CPU資源(CPU時間片以及CPU核等)，磁盤空間資源等，以上這部分內容或多或少，Docker的新版本之前或多或少都可以實現，然而隔離維度依舊不夠完美，這次Docker添加了—blkio-weight參數，實現對容器磁盤 IO限制的支持。隔離更加完備，用戶也不再需要擔心容器間磁盤IO資源的競爭。
7. ZFS支持
Docker 1.7.0 正式宣布支持ZFS文件系統。此舉也意味著Docker容器文件系統的支持從原先的5種增加到6種。此前，Docker支持 aufs，devmapper，btrfs，ovelayfs，vfs(用于支持volume)，如今添加對ZFS的支持。ZFS的支持，不禁讓人聯想到與Docker的數據卷volume插件的Flocker。錯進錯出，似乎關系較為微妙。
值得一提的是，除了支持ZFS之外，筆者發現在負責容器文件系統的graph模塊中，添加了driver_windows.go,雖然內容極其簡易，并非完全實現對windows的全盤支持，但是至少讓大家看到Docker支持windows的步伐在不斷邁進。
8. docker logs的功能擴展
查看容器日志，相信很多Docker愛好者都體驗過，這也是用戶查看容器運行狀態的重要依據。
可以簡單了解Docker容器日志的原理：對于每一個創建的Docker容器，Docker Daemon均會在內部創建一個goroutine來監聽容器內部進程的標準輸出stdout以及標準錯誤stderr，并將內容傳遞至日志文件中。每當用戶發通過Docker Client發起查看容器日志的請求docker logs之后，Docker Daemon會將日志文件的內容傳遞至Docker Client顯示。
docker logs的發展，幾乎可以分為4個階段：Docker誕生初期的原生態日志打印;允許用戶follow容器的日志;開啟容器容器的tail功能，以及容器日志的since功能，打印從某一個時間戳開始之后的容器日志。
雖然容器日志的功能在逐漸增強，但是不可否認的是，容器日志是容器本身與Docker Daemon耦合最大的模塊之一，而這涉及Docker設計之初的計劃，絕非完美，但的確是短時間內最易用的方案。
9. 容器與宿主機共享UTS命名空間的支持
不同的場景下，容器與宿主機可以完全隔離，容器也可能與宿主機存在共享信息的情況，Docker網絡的host模式就是一個很好的例子，該模式下的容器共享宿主機的網絡命名空間。
共享UTS命名空間的支持，意味著容器與宿主機的關系越來越微妙。也許目前很多Docker愛好者已經習慣容器與宿主機完全隔離的運行，當然也會有一些用戶曾經抱怨完全隔離的運行環境并不能平滑的將傳統遺留業務容器化。那么，目前Docker在兼顧兩者的情況下，更多地在滿足后者的需求，不久的將來，Docker容器的運用場景必將更加豐富，這也是Docker走向企業化以及生產化必須要趟的路。
總體而言，Docker 1.7.0給筆者的感受是：功能上逐漸向企業需求靠攏，在production-ready的路上不斷優化，另外在安全方面在不涉及內核基礎上也不斷完善。
京公網安備 11010502049343號