生產(chǎn)環(huán)境下的Docker:成功、挫敗和教訓

責任編輯:editor005

2015-02-27 14:16:47

摘自:51CTO

Docker在2014年迎來了迅猛的發(fā)展,不過在年底傳出了圍繞Docker的一些聲音,聲稱容器服務基礎設施已達到了準備用于生產(chǎn)環(huán)境的程度。新年伊始,已經(jīng)出現(xiàn)了好幾個例子,它們證明了使用容器以便持續(xù)改進和日常部署在生產(chǎn)環(huán)境中的準備就緒狀況。

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)深思熟慮了如何為其應用程序構建微服務架構。

鏈接已復制,快去分享吧

企業(yè)網(wǎng)版權所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號