4.1.3. 新組件
Docker Engine也有了一些新的變化，而部分功能實際上早在Docker 0.9就開始提供了。如果你還在運行Docker 0.8及其以前的版本的話，那么還是及早升級的比較好。
libswarm
libswarm是一個"toolkit for composing network services”。它定義了標準接口用于管理和編配一個分布式系統，并提供了一致的API。libswarm打算支持各種編配系統，雖然它看上去更像個高層接口封裝的API而已。
libcaontainer
libcontainer是一個容器的參考實現，它通過Go語言實現來使用Linux的命名空間等技術，而不需要額外的外部依賴。
實際上在Docker 0.9的時候這個模塊就已經分離出來了，到了1.0的時候，此模塊成為了獨立項目并且可以單獨使用。并且從0.9版本的時候開始Docker就已經開始就采用libcontainer來代替LXC作為默認的容器實現方式了，LXC變成了可選項之一。
libchan
libchan現在是Docker的標準通信層，被稱為網絡上的go channel，普通的Go channel只能運行在單機上，而libchan可以跨Unix socket或純TCP/TLS/HTTP2/SPDY/Websocket等運行。使用libchan，可以非常方便的進行任意結構的消息傳遞、實時雙工異步通信、并發編程及同步等。
最后我們再從下面的這張圖，更形象的認識一下這三個工具的作用及關系。
4.2. 大公司的熱情
如果看一下演講嘉賓列表注 13，你一定會感嘆這陣容太豪華了。不錯，很多演講嘉賓都來自大型互聯網公司，比如Facebook、Twitter、Google、Heroku、Yelp以及Group等，很多還都是VP、CTO等高級別的管理人員，可見這次大會規格之高，分量之重。并且他們中的很多人還都進入到了Docker治理委員會。
注 13 http://www.dockercon.com/speakers.html
4.2.1. Google
前面我們已經介紹了Google公司內部的服務都是跑在容器之中的，Google對Docker也表現出了相當濃厚的興趣。除了他們負責基礎設施的VP Eric Brewer進行了主題為《Robust Containers》的演講之外，他們還介紹了自己開源容器管理軟件Kubernetes和對容器資源進行監控的cAdvisor。
4.2.2. Red Hat
Red Hat Enterprise Linux 7版將內置Docker，雖然版本還是0.11，不過很快就會升級的。另外Atomic項目也是Red Hat主導開發的。
4.3. 其它感受
其他一些筆者認為比較有意思的就是使用基于Mesos工具群來對容器進行集群管理了。比如Twitter和Groupon都做了使用Mesos + Aurora/Marathon + ZooKeeper在數據中心進行資源分配和管理的分享；甚至在Twitter看來，數據中心也可以看做是一臺計算機，Mesos就是這臺計算機的OS。
另外就像我們前面在Docker使用場景中介紹過的那樣，很多公司都在使用Docker進行持續集成。
5. Docker現狀及展望
在本節我們將會站在一個開放的角度和更高的層次來審視一下Docker的現狀，包括其問題點，以及對Docker將來的可能性做一些膚淺的推測。
5.1. 生態系統
Docker的發展離不開其生態系統注 14，我們學習Docker也同樣需對其生態系統有所了解。我們可以從下面三點來審視一下Docker當前的發展狀況。
注 14 關于Docker的生態環境，大家也可以參考網上有人制作的一份思維導圖。http://www.mindmeister.com/389671722/docker-ecosystem
5.1.1. 廠商支持
前面我們已經說過了，包括RedHat等在內的Linux發行商以及Google、AWS、Rackspace等云服務提供商都表示對Docker非常濃厚的興趣，甚至已經進行了非常深入的實踐。從這一點上來說，Docker有非常好的政治背景。
5.1.2. 開源項目
圍繞Docker的開源項目就更多了，主要有以下幾類，我們將挑選出一些比較有意思且開發較活躍的項目進行簡單介紹。
PaaS平臺
PaaS平臺大多基于容器技術，Docker天生就適合做PaaS。
- Flynn
Flynn是一個高度模塊化的下一代開源PaaS實現。Flynn分為兩層，Layer 0是底層，也叫資源層，基于Google的Omega論文注 15開發，這一層也包括服務發現。Layer 1則用來進行部署、管理應用程序。Flynn目前開發比較活躍，是一個值得關注的開源項目，而且今年夏天很可能就會發布1.0的版本了。
注 15 http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf
- Deis
Deis是一個支持共有和私有PaaS的開源實現。它支持運行使用Ruby, Python, Node.js, Java, PHP和Go等語言進行應用開發，并能部署到AWS, Rackspace和DigitalOcean等云上。
CI/CD（持續集成/持續部署）
由于Docker的沙箱性、創建速度快等特性，它與生俱來也適合進行CI/CD。很多基于Docker的CI/CD開源方案和服務如雨后春筍般的涌現出來。
- Drone
開源的支持各種語言的CI工具，并且提供了CI/CD服務Drone.io
- Strider CD
開源的CI/CD方案，集成GitHub。
私有倉庫托管（Registry）/容器托管
這類服務主要進行私有倉庫的托管，根據用戶的托管倉庫數量收費。Doccker Hub也提供私有倉庫的收費套餐。
- Quay
Quay除了能托管私有鏡像之外，還能和GitHub集成，使用Dockerfile進行鏡像構建。
- Shippable
Shippable支持Github和Bitbucket，并且提供100%免費的服務，包括私有倉庫。
- Orchard
Orchard也是一個和StackDock類似的Docker托管服務，它提供了便捷的命令行工具來運行各種Docker命令。同時它也提供免費的私有Registry服務，前面介紹的Fig工具就是此公司開發的。
筆者認為傳統的云計算服務提供商除了在云主機上提供對容器的支持之外，說不定將來還會提供專門托管容器的服務。
開發管理工具
軟件工程師天生就是閑不住和想盡一切辦法要提高自己效率的一群人。這里我們簡單介紹兩個方便進行Docker開發的工具。
- Shipyard
Shipyard是一個Docker鏡像和容器管理工具，除了基本的鏡像構建，容器啟動等功能之外，它還具有在瀏覽器中attach到容器的功能，并通過hipache16來進行容器之間的連接。同時它也支持跨節點的Docker管理和容器Metrics采集。
注 16 Hipache: a distributed HTTP and websocket proxy https://github.com/dotcloud/hipache
https://github.com/shipyard/shipyard
- Fig
Fig是一個為了提高基于Docker開發的效率而創建的工具，它通過一個配置文件來管理多個Docker容器，非常適合組合使用多個容器進行開發的場景。
http://orchardup.github.io/fig/index.html
5.1.3. 社區
Docker開發社區非常活躍，除了35名全職員工（外加一只烏龜）之外，還有450名左右的外部代碼貢獻者。到目前Docker Hub已經擁有超過16000多個應用，在GitHub上也有超過7000個Docker相關的項目，其中不乏很多受關注度非常高的項目。
在Twitter上，科技媒體上以及個人Blog上，每天都能看到很多關于Docker的內容。
線下社區活動也在蓬勃展開中。在世界范圍內除了南極洲，Docker Meetup已經遍布35個國家100多個城市，北京在今年3月8日舉行了國內第一次的Docker Meetup，當時有超過40人報名參加。而且第二次北京Docker Meetup將在七月中舉行，目前正在緊鑼密鼓的籌備之中。
5.2. 運用中的問題點
雖然Docker很火，有時候我們也需要反過來看看它還有哪些不令我們滿意的地方，或者說在使用上還存有疑慮。當然這里的問題都是筆者個人主觀看法，只是非常片面的一部分，各位讀者一定要帶著批判性的思維去理解它。
5.2.1. Debug、調優
查看日志可能是最簡單直接的方式了。當然也有很多人都會在Docker容器中運行一個SSHD服務，然后通過SSH登錄到容器中去，不過不建議使用這種方法。
官方推薦使用nsenter注 17工具來完成類似的工作，通過它可以進入到指定的namespace中并控制一個容器。
注 17 https://github.com/jpetazzo/nsenter
5.2.2. 數據管理
這里所說的數據包括數據庫文件，Log，用戶上傳的文件等。
在容器中要想處理數據文件，可能最簡單的方式就是通過共享卷標來實現，即docker run -v。但是隨之帶來的問題是既然是文件，都存在備份問題，如何備份？用ftp或者在容器和宿主機之間共享文件夾的方式？而且隨著容器數量的增多，對共享卷標的管理也勢必會更復雜。
筆者認為理想的解決方法就是使用云服務，比如數據庫使用RDS，文件使用S3。如果不想使用云服務，則可以考慮自己通過FastDFS等實現自己的“云存儲”。Log則通過fluentd/logstash進行集計再用Graphite/Kibana等進行可視化。
5.2.3. 如何和配置管理工具配合使用
到底在容器時代，還需不需要傳統的Puppet或Chef這樣的配置管理工具？當然，從配置管理工具的角度來說，他們都不會放棄對Docker的支持，比如Puppet就已經增加了對Docker（安裝、管理鏡像和容器）的支持。
但隨著不可變基礎設施的普及注 18，冪等性將不再重要，因為我們的容器只需要配置一次。要對容器做出修改，可能只需要修改Dockerfile/manifest/recipe文件重新Provisioning即可。而且也不需要在容器內部安裝任何agent，這樣的話類似Ansible這樣純SSH的配置管理工具比較適合對Docker進行配置。甚至還可能出現專門為Docker的更簡單的配置管理工具。
5.2.4. 安全性
是軟件就會存在bug，包括安全漏洞，Docker也不例外。就
