3億Docker容器部署的挑戰及應對方案

編者按：IronWorker是一個面向開發者的任務隊列服務，開發人員可以在不設置和管理任何基礎設施的基礎上，調度執行大規模的任務。幾個月前，Iron開始試用Docker，如今其內部已經部署了3億多個Docker容器，本文中分享了IronWorker在使用基于Docker的基礎架構時，遇到的挑戰、解決方法，以及其中的收獲。以下為原文：

IronWorker是一個任務隊列服務，他讓開發人員在不用設置和管理任何基礎設施的基礎上，調度執行大規模的任務。我們3年多前推出這項服務時，使用了包含所有的語言和代碼包的LXC容器運行任務。Docker使我們能夠輕松地升級和管理一組容器，為客戶提供更多的語言環境和安裝包。

我們剛開始使用的是v0.7.4版本的Dokcer,使用過程中遇到一些困難（不能正常的關閉是一個大的問題，但是后來已經被解決了），我們已經成功地克服了所有的困難，并且發現Docker不僅僅滿足了我們的需求，更是超出了我們的預期。因此我們在我們的基礎架構中推廣使用Docker。基于我們的經驗來看，這樣做是有意義的。

優勢

下面列出幾點我們意識到的Docker的優勢：

更新維護鏡像非常容易

Doker 使用類似git的非常強大的方法來管理Image，使得它能很方便地管理大量的、不斷變化的環境，他的Image分層系統不僅節省空間而且使我們擁有更細區分度的images。

現在，我們能夠跟上快速更新的語言的節奏，我們能夠提供專門的例如一個新的專門為媒體處理而設計的ffmpeg stack。我們現在有多達15個不同的堆棧并且正在迅速擴大。

資源分配

基于Lxc的容器是操作系統級別的虛擬化方法，所有的容器共享系統內核，但是每個容器可以被約束使用指定的資源，比如CPU,內存和I/O.Docker提供REST API、環境版本控制、獲取/提交鏡像、輕松獲取統計數據等功能。Docker支持使用CoW文件系統來更安全的隔離數據。這意味著，任務中對文件的所有改變都分開存儲，并可以用一個命令清除。 LXC是不能跟蹤這種變化。

Dockerfiles使得集成簡單

我們的團隊遍布世界各地。只要發布一個簡單的Dockerfile就可以下班，當你休息時，可以保證其他工作的人能夠生成和你的一樣的鏡像。克服了不同地方的人有不同的作息時間的困難。干凈的鏡像使得它部署和測試更快。我們的迭代周期更快，團隊里每個人更加開心。

不斷壯大的社區

Docker在非常快得更新，甚至比chrome更快。更重要的是，參與增加新功能和修復bug的社區數量在大量增加。 無論是為為鏡像貢獻還是為Docker做貢獻，甚至是為Docker的周邊工具做貢獻，有一大批聰明的人正在為其努力，因此我們也不能置身事外。我們發現Docker的社區非常活躍有意義，我們很高興能夠成為其中一員。

Docker + CoreOS

我們也處在探索階段，但我們發現Docker和CoreOS的結合對于我們來說似乎是更好地選擇。Docker提供了穩定的鏡像管理和容器。CoreOS提供了一個精簡的云操作系統、機器級別分布式編排和虛擬狀態管理。這個組合關注問題的不同方面，是一個更合理的基礎設施棧。

挑戰

每一個服務器端的技術需要微調和定制，尤其是大規模運行時，，Docker也不例外。（例如，我們跑不到5000萬的任務，一個月50萬小時計算，并且不斷更新我們的鏡像）。下面是我們使用大量Docker容器數時遇到的一些挑戰：

向后兼容性不夠

該領域的快速創新雖然是一個優勢，但是也存在缺點。其中之一是向后兼容性差。在多數情況下，我們遇到的問題主要是是命令行語法、API的改變，從產品角度來說這不是一個嚴重的問題。

但在某些情況下，它影響了操作性能。例如，在任何啟動容器后引發的Docker錯誤，我們要解析STDERR并根據錯誤類型進行響應（例如重試）。非常不幸的是，錯誤的輸出格式隨著版本不同變化，不得不在不斷變化的結果中調試，使我們非常疲憊。

Docker的錯誤率

這個問題相對來說還比較好解決，但是意味著每次的更新要經過多次驗證，并且你需要一直開發直到這個更新的版本被發布到了系統大部分環境中。我們幾個月前使用v0.7.4,現在我們的系統更新到v1.2.0.在這個領域我們已經有了一個很大的進步。

有限的工具和庫

雖然Docker 有一個四個月前發布的穩定版本，圍繞它的一些工具仍然不穩定。采用Docker生態圈中的大部分工具意味著需要投入更多的精力。為了使用最新的功能、修復 bug，你團隊中需要有人熬夜加班對這些功能，頻繁的進行一些修改.也就是說，我們很高興有一些Docker 周邊的工具在開發，而且很期待能夠有一個工具在其中脫穎而出。我們對etcd,fleet, kubernetes比較看好。

戰勝困難

接下來根據我們的經驗，更深入的講我們講我們遇到的問題和我們的解決方法。問題列表主要來自我們Ironworker的首席開發兼工程運營總監Roman Kononov和一直在調試和規范化我們Docker操作的Sam Ward。

Debug時的一個異常

說明一下，當我們遇到和Docker相關或者其它系統相關的問題，我們可以自動的重新執行任務，對用戶沒有任何影響（重試是平臺的內置功能）。

刪除操作時間長

起初刪除容器時間長，需要太多的磁盤I/O操作。這導致我們的系統速度明顯變慢，形成了瓶頸。我們不得不增加可用的內核數目，而這個數量遠遠超出我們所需的。

快速刪除Docker容器的解決方案

通過研究使用devicemapper（一個Docker的文件系統驅動），我們發現設置一個選項有作用`--storage-opt dm.blkdiscard=false`，這個選項告訴Docker 刪除容器時跳過花費時間長的磁盤操作,大大加速了容器的關閉過程。當修改好刪除腳本后，這個問題就沒了。

卷無法卸載

由于Docker沒有可靠地卸載卷，容器不能正確地停止。這導致容器永遠在運行，即使已經完成了任務。解決辦法就是顯示地調用用戶自己寫得一些列腳本來卸載卷，刪除文件夾。幸運的時，這個問題是之前我們使用Docker v0.7.6版本時遇到的，當Docker v0.9.0解決這個問題后我們就刪除了那些冗長的腳本。

內存限制開關

Docker 其中的一個發布的版本中突然新增了內存限制選項，刪除了LXC中的選項。其結果是一些工作進程到達內存界限，然后了整體不響應。這弄得我們措手不及，因為 即使使用了它不支持的設置，Docker也沒有出錯。解決方法很簡單，即在Docker內部設置內存限制，但是這種變化讓我們措手不及

未來計劃

正如你所看到的，我們對Docker投入非常的多，我們在接下得每天會繼續投入。除了用它來隔離用戶在IronWorker中運行的代碼，我們也準備在其他的一些領域使用它。 

這些領域包括：

IronWorker 后臺

除 了使用Docker作為任務的容器，我們也在使用它來管理每個服務器上運行的用來管理和啟動任務的進稱。每一進程著的主要任務是從隊列中拿一個任務，把它 放到合適的Docker容器中，運行，監測，運行完后刪除環境。有趣的是同一臺機器上我們有容器化的代碼來管理其它容器。把我們所有的基礎設施環境放到 Docker的容器中讓我們在CoreOS上的運行相當容易。

IronWorker, IronMQ,以及 IronCache APIs

我 們和其他的ops團隊一樣，沒有人喜歡部署。能夠把我們的所有的服務打包Docker容器中，然后簡單、確定地部署，我們非常地激動。不用再配置服務器。 我們需要的就只是能夠運行Dokcer容器的服務器。我們正在替換我們的服務器搭建，使用Docker容器在服務器上為我們發布的產品搭建環境。變得的靈 活、簡單，有更可靠的協議棧。

生成和加載程序

我們也在用Docker容器在IronWorker中生成和加載程序。一個顯著的進步是為用戶改進了，大規模、特定任務負載和工作流的創建、上傳、運行任務的過程。還有一個好處是用戶可以在本地測試程序，而測試環境和我們的生產服務一致。

企業內部部署版

使 用Docker作為主要分發方法，IronMQ企業內部部署版簡化了我們的分發工作，并且提供了一個簡單通用的在幾乎任何云環境中都能部署的方法。就像我 們在共有云上運行的服務，客戶需要的就是可以運行Docker容器的服務器，同時他們可以相對容易的獲得在測試或生產環境中運行的多臺服務器的云服務。

原文鏈接：Docker in Production — What We’ve Learned Launching Over 300 Million Containers（編譯/王曉冉 審校/周小璐）
來自：http://www.csdn.net/article/2014-11-03/2822455