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

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

下面不妨看一下今年的四個例子，它們證明了用戶如何考慮Docker用于生產(chǎn)環(huán)境：

Battlefy：交付新的功能特性

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

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

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

Iron.io：在微服務環(huán)境中運用Docker

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

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

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

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

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

Mikamai：開發(fā)公司期望Docker與Opsworks一并部署

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

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

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

XMLDirector：反對使用Docker

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

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

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

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

準備好用于生產(chǎn)環(huán)境嗎?視情況而定

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