Docker 2015年度回顧

Docker從2013年開源，即將經歷三年的不斷完善與優化。2015年是Docker開源項目日新月異的一年，在這一年的時間裏，Docker前後發佈了v1.5, v1.6, v1.7, v1.8, v1.9 等5個大版本以及7個修訂版。

‍

在功能上，不只增長了」只讀容器」、」ulimit支持」、」日誌驅動」、」Volume插件」、」網絡插件」、」IPAM插件」等新特性，並且更增長了適合企業多樣化的應用場景；user namespace的支持也合併進了1.9實驗版，這使得Docker的安全性獲得大大提高。

Docker registry 2（github上的distribution項目）的發佈，讓鏡像更加標準化，鏡像的傳輸更加高效；新增了鏡像簽名驗證機制，保證了鏡像傳輸的安全，在國內希雲cSphere推出了微鏡像。

Docker社區的活躍度也不斷提高，Docker項目的社區代碼貢獻者由年初的900多增長到目前的1200多，活躍的開源社區爲Docker的穩定性和功能改進提供了有力的保障。

在6月份的DockerCon大會上，Docker公司與Linux基金會聯合推出開放容器項目（OCP），微軟、IBM、Google、Intel、Amazon等巨頭的加入，使Docker成爲了容器技術的業界標準。實際上，容器自己的價值很是有限，重要的是容器的生態！

在本文中，咱們將從Docker的功能、穩定性以及代碼質量方面對2015年Docker的進展狀況進行總結。

 

功能進一步完善

只讀容器

```
需求：爲了方便項目遷移、升級和擴容，每每都須要制定一系列的標準和對數據日誌數據的存儲位置進行約束。

問題：開發團隊並非嚴格遵循制定的標準進行，把數據存放到了規定以外的路徑下，致使數據丟失。這種狀況下怎麼辦？
```
Docker引入的只讀容器特性使容器的rootfs以只讀方式掛載，這樣運維人員能夠強制規定日誌或數據的存儲路徑。若是應用程序須要寫數據，必須經過-v參數指定數據目錄，這樣可以很好地起到了強制約束的做用。

另外的一個應用場景是：若是基於Docker作PaaS平臺，只讀容器可能優點更爲明顯。

 

ulimit支持

 

Linux的ulimit提供了一種簡單的配額控制機制。但在Docker 1.6以前，一個Docker daemon管理全部容器的ulimit是共享的，使用起來很不靈活。Docker 1.6提供了基於容器的ulimit參數控制，用戶能夠爲不一樣的容器設置不一樣的ulimit數，這樣使用起來更加靈活。

 

build過程的配置控制

 

```
問題：主機上已經跑了很是多的業務容器，在資源緊缺的狀況下，如何作到既能成功構建任務，又能保證業務平穩運行？
```
鏡像構建每每是一個很是消耗資源的操做，主機上還運行了不少線上業務，那麼在構建鏡像的時候極可能過分消耗系統資源而致使線上服務不穩定。不只要保證構建任務順利執行，並且更要保證線上業務穩定運行。因此Docker 1.6提供了對build過程的CPU、內存等資源進行配額控制的能力。

推薦：企業生產環境中，拿出幾臺機器專門作構建鏡像的工做，高效而且安全！

 

日誌驅動

```
問題：容器中推薦運行1個進程，若是運行了mysql，不安裝syslog服務，收集日誌怎麼辦？
```
你們應該都很熟悉ELK，以前在虛擬機裏安裝syslog這種方法很奏效，但在容器這就行不通了。

因此在v1.6中提供了可擴展的日誌驅動接口，內置json-file和syslog兩種日誌驅動，用戶能夠根據需求把日誌寫入json文件或者發送到syslog（日誌中心），這樣就不須要再爲每一個容器都安裝syslog服務。

基於日誌驅動的go語言接口，在接下來的幾個版中，逐步添加了fluentd, journald, awslog, gelf等日誌驅動模塊，知足用戶各類複雜的日誌記錄與收集需求。

 

容器與鏡像Label

```
問題：若是應用部署在單臺主機上沒有問題，那麼若是想部署到多臺主機上，該如何調度呢？
```
Docker 官方本身作了一個項目叫Swarm，而且如今Swarm已宣佈能夠在生產環境中使用。爲了方便Swarm之類的集羣管理工具對主機進行分組管理，在v1.4中，用戶能夠爲Docker Daemon指定一個或多個Label，知足應用部署調度到相對應的服務器上。

Docker 1.6新增了容器與鏡像Label的支持，方便用戶根據Label來對容器和鏡像進行分組管理與過濾。

 

Volume插件

```
問題：容器刪除後，如何確保容器裏的數據不被刪除？
```
爲了確保刪除容器數據不被刪除，咱們以前的作法就是經過-v把容器的數據目錄和主機的目錄作一個映射，但這樣數據仍是存放在本地磁盤中。在v1.7實驗版引入了Volume插件機制，用戶能夠根據須要開發本身的Volume插件來使用外部存儲服務。

好比：經過AWS EBS Volume插件，能夠在建立容器時，自動建立一塊EBS，把容器的數據保存在EBS上。

若是須要，用戶也能夠本身根據Volume插件的RPC接口規範開發適合本身的Volume插件，經過企業內部的NAS、SAN等存儲服務來保存容器數據。

Volume插件在v1.8進入正式版對外發布，這樣一來Docker存儲問題也就迎刃而解了。

 

Overlay網絡

```
問題：單臺主機容器之間通訊沒有問題，若是跨主機通訊怎麼辦？
```
Docker容器ip不固定，以及跨主機互聯一直是困擾Docker用戶的一個問題，也是阻礙企業落地的一塊絆腳石。

在Docker支持Overlay網絡以前，經常使用的跨主機通訊方案是經過在每臺主機上運行ambassador容器做爲代理。這種方式無疑形成了管理成本的增長，並且也不適合用到生產環境。

Docker 1.9正式支持了基於VXLAN的Overlay網絡，用戶能夠經過Overlay網絡方便的實現容器跨主機通訊，可是僅僅是解決了跨主機通訊，並無實現固定容器的IP功能。

 

 網絡插件

6月份以前，Docker默認提供了bridge(NAT)網絡、Host網絡、容器網絡（與其它容器共享網絡命名空間）以及none（該模式下容器不建立網絡設備，沒法與外界通信）等四種網絡模式。

雖然這幾種網絡模式能知足大多數應用場景的需求，但不夠靈活，用戶沒法直接使用企業內部現有的SDN來爲容器提供網絡服務。

在1.7發佈之際，Docker實驗版引入網絡插件功能。基於網絡插件的RPC協議，用戶能夠開發自定義的網絡插件來爲容器提供網絡服務。

好比：用戶能夠本身開發基於IPVLAN、MACVLAN、VXLAN等技術的網絡插件實現跨主機通訊。第三方提供的網絡插件也如雨後春筍般出現，如：支持多租戶網絡的Contiv 插件（https://github.com/contiv/netplugin），支持跨主機跨雲通訊的Weave網絡插件等。

希雲cSphere平臺支持容器靜態IP、容器重啓後IP保持不變、跨主機通信、內置名字服務，以及服務發現功能的網絡方案，也很大程度上利用了Docker的插件機制，使企業業務在生產環境上更加有保證。

網絡插件在歷經半年之久的打磨後，1.9版本正式對外發布。

 

User Namespace

```
問題：若是容器和宿主機所使用的用戶同樣，那麼容器安全嗎？
```
容器安全問題是每一個使用容器的技術人員都應該考慮的事情，Docker經過對Linux各類命名空間的巧妙運用，實現了軟件運行環境的沙箱，保證同一個主機上不一樣進程之間的相互隔離。

但因爲User Namespace的實現與libnetwork存在衝突，從而致使User Namespace的支持一直被擱置。因此不少使用容器的同窗一直都還在擔憂容器的安全問題。

但毫無疑問，User Namespace能大大提升Docker的安全性。在User Namespace支持以前，全部容器裏的root用戶其實與宿主機上的root用戶是同樣的，一旦容器沙箱被攻破（越獄），惡意用戶就獲取了宿主機的root權限，這樣確實是很不安全。

經過User Namespace，能夠把容器中的root用戶映射到宿主機上的一個普通用戶，這樣即便發生越獄事件，攻擊者獲取的也只是宿主機上的一個普通用戶的權限，大大增長了容器的安全性。如今是否是對容器更加有信心了？

User Namespace在通過7個月的討論以及無數次修改與完善後，終於在1.9版發佈以前，合併進了master（參考：https://github.com/docker/docker/pull/12648）。用戶能夠經過目前最新的實驗版Docker體驗User Namespace的相關功能。

 

 穩定性持續改進

回顧2015，Docker團隊與開源社區在Docker的穩定性提高方面作了大量工做。

最明顯的表現是集成測試的覆蓋面，在v1.4.0, 集成測試用例377個；到v1.9.1, 集成測試數量提高到1138個。

在每一個PR提交之後，會自動經過github hook觸發Jenkins來執行全部測試用例，從而儘量保證總體功能的穩定性，Docker在生產環境中已經很穩定地運行1年多了。

 

代碼結構逐步優化

Docker的一個競爭產品rkt(https://github.com/coreos/rkt)推出時，曾批評Docker的代碼缺少設計，最明顯地表現是過多的嵌套調用（如：Docker 1.7以前的Job接口）,不過目前來看，rkt仍是敗給了docker。

2015年，Docker在代碼結構上的重大調整主要包括：

- Job接口的移除，減小了過多冗餘的嵌套調用
- 網絡相關的功能抽象到libnetwork項目獨立維護
- 容器生命週期的核心庫libcontainer由docker帳號遷移到runc項目
- 支持Registry V2
- 本地鏡像存儲格式支持content addressability，鏡像ID由隨機生成改成按鏡像內容計算（防止串改鏡像內容）
- API與Daemon功能的隔離，以及API路由的從新設計
- 鏡像Builder的重構
- Graph模塊重構
- 移除LXC執行引擎，從而更加專一於native執行引擎的開發與維護

 

 總結

 

在過去的一年裏，Docker逐步從一個實驗品，成長爲一個羽翼豐滿的可在生產環境中使用的容器引擎。

Docker團隊在開源方面的大力投入以及活躍的開源社區，爲Docker的成長提供了有力的保障。

以希雲cSphere、Swarm、Docker Compose、Kubernetes、Mesos爲表明的容器管理與調度平臺也如雨後春筍般出現，爲Docker在企業內部落地提供了有力的支持。

相信在不遠的未來，容器技術將會在企業界獲得普遍的普及。它在運維管理、軟件發行等方面的變革也將對企業IT生產力產生巨大的提高。

如瞭解更多docker相關知識，請觀看培訓視頻：https://csphere.cn/training！

如須要docker相關產品，請訪問希雲官網首頁：https://csphere.cn！

cSphere1.0版本已發佈，正式商用！歡迎諮詢 400-686-1560