Docker為何未在生產環境中取得廣泛成功？

Docker的發展勢頭一天比一天強勁，它顯然在試圖解決實際的問題。然而，對如今許多的生產環境用戶來說，沒有出現優點壓倒缺點的局面。在開 發、測試和持續性集成等環境下，Docker在讓容器吸引廣大開發人員方面確實有上佳的表現，不過它還沒有顛覆生產環境。按照DockerCon 2015的“生產環境下的Docker”這一主題，我想公開討論Docker想在生產環境使用場合下得到廣泛采用還沒有克服的種種挑戰。這里提到的問題沒 有一個是新問題，它們都以某種形式出現在GitHub上。大多數問題我已經在大會演講中或與Docker團隊交流中討論過。本文倒不是要明確指出什么不再 是問題：比如說，新注冊中心(registry)克服了舊注冊中心的許多不足。本文并沒有提到仍然問題重重的許多方面，不過我認為下面這些問題是近期內需 要解決的最重的問題;只有解決了這些問題，更多的企業組織才能夠邁出一大步，在生產環境中運行容器。我在電子商務公司Shopify運行Docker的經 歷對本文有很大的影響;一年多來，我們一直在容器上大規模運行核心平臺。由于像Docker這樣發展這么迅猛的技術，不可能一切都保持現狀。如果你發現不 正確之處，務必聯系我。

映像構建

為大型應用程序構建容器映像依然是個挑戰。如果我們要依賴容器映像用于測試、持續性集成和緊急部署，就需要在不到1分鐘的時間內將映像準備就緒。 Docker文件(Dockerfile)讓這對大型應用程序來說幾乎不可能。雖然Docker文件易于使用，但是位于過高的抽象層，無法支持復雜的使用 場合：

• 帶外緩存，面向特別錯綜復雜的、針對特定應用程序的依賴項;
• 在構建時訪問密文(密碼、密鑰和相關內容)，又不將它們提交給映像
• 全面控制最終映像中的層
• 并行處理構建層

大多數人并不需要這些功能，但是對大型應用程序而言，其中許多功能是快速構建映像的先決條件。Chef和Puppet等配置管理軟件使用廣泛，但 是讓人覺得用于構建映像過于笨拙。我打賭，在今后十年內，現有形式的這類系統會因容器而逐漸退出歷史舞臺。然而，許多應用程序依賴它們來配置、部署和編 排。Docker文件無法真實地記錄下現在由配置管理系統管理的復雜性，但這種復雜性需要在某個地方加以管理。在Shopify，我們最后使用 docker commit API，從頭開始構建了自己的系統。這個過程很麻煩，我希望這一幕不會出現在任何人身上，我很想擺脫這種局面，但是我們又不得不掃除障礙。很少有人會花這 么大的力氣去管理用于生產環境的容器。

這個領域會出現什么情況不得而知;目前在這個領域，開展的研究工作并不多(一個例子是dockramp，這是另一種打包器)。Docker引擎會 在將來有所改進，將構建基本步驟(添加文件和設置入口點等)與客戶端(Docker文件)分開來。為版本1.8所做的合并工作已經讓這變得更容易，為配置 管理工具廠商、業余愛好者和公司進行試驗嘗試創造了條件。考慮到配置系統的歷史還很短，認為一種標準有望搞定這個問題(就像運行時標準那樣)是不切實際 的。什么時候可以實現可擴展的映像構建，相當不明朗。據我所知，沒人在積極迭代，很遺憾這種現狀已維持一年多了。

垃圾收集

每個部署的重大Docker系統到頭來要編寫垃圾收集器，以便清除主機上的舊映像。使用了各種啟發式方法，比如清除超過X天的舊映像，在主機上最 多執行Y個映像。Spotify最近開放了其系統的源代碼。我們還在很久以前就編寫自己的垃圾收集器。我能明白為此設計一種易預測的用戶界面(UI)有多 難，但是這又是核心中絕對需要的。當生產環境的機器嚷著要存儲空間時，大多數人無意中發現要求收集垃圾。最后，你會遇到同一映像，Docker注冊中心因 龐大映像而溢出，不過這個問題已列在了發行版路線圖上(詳見https://github.com/docker/distribution/blob /master/ROADMAP.md#deletes)。

迭代速度和核心狀態

Docker引擎致力于1.x版本的穩定性。在版本1.5之前，降低準入門檻以便在生產環境得到采用方面所做的工作不多。開發容器的公眾心理模式 對Docker的成功而言必不可少，Docker害怕破壞這種模式是有其道理的。如果用戶體驗(UX)方面的每個變化經歷的過程時間過長，迭代速度難免受 到影響。自版本1.7起，Docker開始發布試驗性版本，以網絡和存儲插件帶頭。這些功能特性被明確標為“未準備用于生產環境”，可能會從核心中取出或 者隨時經歷重大變化。對于早已看好Docker的公司來說，下面這個是好消息：它讓核心開發團隊可以更快速地迭代開發新功能，不用擔心本著最佳設計的精神 而破壞次要版本之間的向后兼容性。公司仍然很難改動Docker核心，因為它需要分支――這是導致最終失敗的行為和維護負擔，或者需要得到上流接受;對于 值得關注的補丁來說，這常常很耗費人力。自版本1.7起，宣布插件后，解決這個問題的策略就很明確：讓每一個固執己見的的組件都可以插入，最后顯示了“帶 電池而且可以更換”這種理念的成果，這種理念最早是在2014年的DockerCon歐洲大會上提出來的(不過相當模糊)。在6月份的DockerCon 大會上，很高興聽到這歸入到“管道”(Plumbing)這個大主題來探討，作為核心開發團隊的重中之重。雖然未來終于大有希望，但是這在今天仍然是個痛 點，就跟過去兩年一樣。

日志

日志是表明有望得益于之前變化的一個方面的例子。這并不是引起強烈關注的問題，卻是普遍性的問題。目前沒有理想的、普通的解決方案。日志到處都 是：尾部日志文件、容器里面的日志、通過掛載發送到主機的日志、發送到主機syslog的日志，通過fluentd(開源數據采集器)等工具來暴露日志， 從應用程序直接發送到網絡的日志，或者發送到文件的日志，讓另一個進程將日志發送到Kafka。在版本1.6中，支持日志驅動程序的功能已并入到核心中 (https://blog.docker.com/2015/04/docker-release-1-6/);然而，驅動程序在核心中必須得到接受 (這并非易事)。在版本1.7中，已并入了試驗性支持進程外插件的功能，但是讓我失望的是，它并不隨帶日志驅動程序。我認為，版本1.8會計劃添加這項功 能，但是在官方記錄中找不到這項。到那時，廠商們就能夠編寫自己的日志驅動程序。社區內部的共享將輕而易舉，大型應用程序再也不必求助于設計定制的解決方 案。

密文

遷移到容器的人大多數依賴配置管理，在機器上安全地配置密文;然而，繼續沿著配置管理這種老路子配置容器中的密文很笨拙。另一個辦法就是將密文與 映像一同分發，但是這帶來了安全風險，而且很難在開發、持續性集成和生產環境之間安全地回收映像。最純粹的解決辦法就是通過網絡訪問密文，讓容器的文件系 統保持無狀態。就在不久前，這方面還沒有任何面向容器的機制;不過最近，兩家頗令人關注的密文代理系統 Valut(https://vaultproject.io)和Keywhiz(https://github.com/square /keywhiz)開放了源代碼。在Shopify，我們一年半前開發了ejson(ejson是一種簡單的庫，用嵌入在JSON文件中的公鑰加密該文件 中的所有值，詳見https://www.shopify.com/technology/26892292-secrets-at-shopify- introducing-ejson)，以解決這個問題，從而管理JSON文件中非對稱加密的密文文件;然而，它就所運行的環境有一些假設，因而讓它與密 文代理系統相比，不是很理想的一般性解決方案(如果你很好奇，可以參閱這篇文章https://www.shopify.com/technology /26892292-secrets-at-shopify-introducing-ejson)。