[[128132]]

Docker在2014年迎來了迅猛的發展，不過在年底傳出了圍繞Docker的一些聲音，聲稱容器服務基礎設施已達到了準備用于生產環境的程度。今年，Gartner等調研公司已經列出了Docker部署到企業中分布式應用程序中的安全挑戰，不過都相當支持Docker總體的發展方向。新年伊始，已經出現了好幾個例子，它們證明了使用容器以便持續改進和日常部署在生產環境中的準備就緒狀況。

用戶們的體驗不一而足：有的用戶堅信可以使用Docker大規模部署分布式Web應用程序；有的用戶已把Docker整合到生產環境中；有的用戶決定還沒有這么做，而有的用戶則拒絕Docker，認為它太過復雜或不夠穩定，無法用于實際的使用場合。

下面不妨看一下這四個例子，它們證明了用戶如何考慮Docker用于生產環境：

Battlefy：交付新的功能特性

軟件工程師Jaime Bueza最近撰寫的一篇博文表明了初創公司Battlefy如何使用Docker和Jenkins工具，在其eSports平臺上發布新的功能特性時，迅速構建并發布Docker映像，然后將映像部署到AWS Elastic Beanstalk上，或者修復軟件錯誤。在過去的五個月，Battlefy的訪客數量已從100個猛增到400000個，它所在的行業預計全球收入有望增長24%；國際用戶群數量已經超過了7000萬。

Battlefy從功能特性或軟件錯誤的GitHub合并請求（pull request）入手，連接到JIRA工單，然后利用測試版工具Screener來檢測每個版本的DOM變化，并將差異做入屏幕截圖。結果被發送到團隊的Slack頻道，評審團隊成員給代碼打上兩個大拇指表情符號后，Jenkins就向AWS S3交付新的代碼；Docker容器被用來構建生產前環境。在生產前環境中完成另一輪的Screener前端測試后，Jenkins隨后得以自動將合并請求并入到主生產環境中。

Battlefy生怕遇到生產環境中的任何故障，于是使用AWS Elastic Beanstalk，那樣如果構建、推送和部署的Docker映像有錯誤，Battlefy就能迅速恢復到前一個版本。

Iron.io：在微服務環境中運用Docker

Iron.io是IronMQ消息隊列系統和IronWorker異步任務處理工具的開發商，它自豪地自認為是Docker的早期采用者；對它來說，微服務架構已儼然成為運行時環境的標準化模式。

在近日的一篇博文中，渠道和整合主管Ivan Dwyer解釋，對Iron.io來說，它們之所以能避免生產環境在安全、發現和故障方面的重大挑戰，就是因為它們在容器層面把Docker整合到系統中：

“我們把每一個任務容器視作一種暫時的計算資源。持續性、冗余性和可用性，我們在服務層面擴建產品時非常注重這一切要素，未必適用于單個的任務容器層面。我們在這方面關注的問題實際上局限于確保本該運行時運行，好讓我們確信如今在充分利用Docker。”

IronWorker在塊存儲系統中擁有超過15套的Docker映像，它們為運行中的代碼提供了語言和庫環境。IronWorker的客戶隨后只能利用編寫代碼所需的庫，并上傳到Iron.io的S3文件存儲環境，他們的消息隊列將底層的Docker映像與用戶的代碼程序包在新的容器里面合并起來，運行進程，然后銷毀容器。

Iron.io在微服務環境下工作，許多遺留的企業生產環境無法使用這種環境，因為它們的可組合性根本不如Iron.io支持的環境。但是就較新的應用開發環境而言，Iron.io可以在生產環境中使用Docker，幫助最終用戶管理成本，并且根據需要在編排基礎設施里面擴展進程。

Mikamai：開發公司期望Docker與Opsworks一并部署

來自開發商Mikamai的開發人員Giovanni Intini總結了許多成熟的開發人員在Docker方面的幾個常見問題：乍一看，大家都喜歡這個概念；他們也喜歡其潛力。不過他們也都有過前車之鑒，不敢過于倉促地采用新技術，因為那樣會導致他們在部署到生產環境后不得不通宵達旦地工作或者放棄為期三天的周末。對二十出頭的編程新手來說，這可能很好玩；但是對于三四十歲的人來說，工作不是生活的全部，在生產就緒的環境中采用新技術面臨的風險是更重大的決定性因素。

Intini仍然看好Docker的潛力；由于基于云的開發運維（DevOps）生態系統還沒有足夠成熟起來，他構建了一些新的開源項目，以便使用亞馬遜的Opsworks（目前還無法支持Docker）等既有服務，能夠將Docker化的容器服務部署到生產環境中。

Intini的應用架構需要負載均衡系統、前端Web服務器、避免任何故障時間的haproxy、應用容器、Redis、PostgreSQL、計劃任務（cron）和異步處理。他想把將其應用程序構建成具有可擴展性的docker化的應用程序。問題在于，當他開發的應用程序在亞馬遜網絡服務云上運行時，Docker其實并不是一種選擇。Intini在近日的博文中分享了用來構建擴展其應用程序的生產就緒的環境的代碼和進程，現在他聲稱其應用程序在部署環境中的停運時間為零。

XMLDirector：反對使用Docker

Andreas Jung是XMLDirector的項目負責人，而XMLDirector是一個XML內容管理系統和工作流平臺，旨在支持企業XML環境，其工具可以轉換發布格式以及管理文檔集合。

兩周前，他撰文描述了如何試圖在生產環境中使用Docker，將特定的XML類型數據庫放入到容器中，以便它們可以迅速地安裝和管理；將Plone企業內容管理系統應用程序放入到容器中，以便它可以用于XML Director的演示；以及將眾多XML特有的數據庫放入到容器中，以便它們可用于對照處理其他XML數據庫后端的方法，測試XML Director的后端。

可惜Docker沒有給Jung留下深刻的印象。他發現，通常的構建過程比使用外殼還要慢5倍至10倍；幾個進程需要重啟Docker；由于Docker創建多個映像和容器，測試后刪除系統上的副本需要一番“搗鼓”。

試圖使用Docker無果后，Jung只好回到“老式的部署環境”，盡管他也承認Docker背后的理論和概念確實不錯（不過他表示“Docker的架構和實施一團糟。Docker在生產環境中完全不穩定。它不可靠，無法預測，靠不住。”）

準備好用于生產環境嗎？視情況而定

Docker已得到了巨大的發展，生態系統在不斷擴大，而且容器化系統在金融機構、媒體及其他大規?？鐕髽I領域當中得到了采用。雖然Docker的容器技術迅速被認為是構建投入到生產環境的分布式應用程序的標準，但早期采用者發覺它最適合這種使用場合：企業已經深思熟慮了如何為其應用程序構建微服務架構。

英文原文：Docker in the Production Environment