《三個生產環境中使用Docker的案例》要點：
本文介紹了三個生產環境中使用Docker的案例，希望對您有用。如果有疑問，可以聯系我們。

在2017年1月17日的Helsinki的首屆Docker線下見面會中,Solita、Zalando和Pipedrive公司分別介紹了Docker在生產環境中的實踐,包括案例及相應的輸入輸出.同時,也介紹了Docker在生產環境中的優點、缺點和痛點.

Solita的使用場景

首先,Solita公司的Heikki Simperi介紹了他們公司如何利用Docker來處理多種app和芬蘭國家鐵路管理系統(VR)的關系,以及他們在使用Docker過程中遇到的問題.

Solita在Docker上運行了多種app,包括火車司機導航系統、通知系統和交通控制app.Heikki特別提到在鐵路管理系統中減少系統停機維護時間的重要性.他的原話是：“anything over a 3-5 min downtime causes delays for trains, but nobody dies.”

他們在使用Docker過程中遇到的大部分問題大致包含以下幾個方面：構建鏡像、創建私有倉庫、移除或者啟動容器以及app中存在的bug.總的來說,他們使用Docker過程中一直是穩定的,并且是零停機維護.

他們之前遇到的問題在升級Docker版本之后或減少或解決.他們正期待Docker1.12穩定版本在RedHat官方渠道上的發布.

Zalando的使用場景

隨后,Rami Rantala介紹了Zalando公司的各個團隊和項目中是如何使用Docker用于部署生產系統.

在Zalando Helsinki的辦公地,這里有超過100多名工作人員和多個團隊,他們負責不同的生產系統、相關探索研究、持續交付等工作,采用敏捷開發的方式開發他們的平臺.

每個自主團隊均有獨立的AWS賬號,而且無視了不可以在生產環境運行Docker的建議.據Rami介紹,在Zalando內,任何運行在AWS上的程序都采用了Docker運行,Docker被認為是唯一允許用于部署生產環境的工具.他們同樣有獨立的Docker資源庫(Pierone),他們自主的Docker基礎鏡像和每個實例運行一個全棧容器.

有很多領域還存在改進的空間,包括如下內容：部署太慢,他們丟失了Docker中層通信的優勢,每個實例運行一個容器的代價很高,導致存在數千個實例；另一個問題在于Docker經常拖垮Pierone.

他們目前正調研使用Kubernetes,它看起來可以降低成本,對AWS賬號和基礎設施要求更低,更高效的利用容器間通信和快速簡單的部署.他們在技術周進行了技術演練,并計劃在第二季度用于生產環境灰度發布.

Pipedrive的使用場景

最后,Renno Reiurm討論了Pipedrive公司在使用Docker中的收獲與痛點.這是家致力于幫助小微企業控制復雜銷售流程的公司,成立于2010年,目前擁有30000家付費客戶,并有200多名雇員和Tallinn、Tartu和New York有三處辦公地.

Pipedrive采用Docker并感受到了隨著業務增長,Chef帶來的各種問題.由于很少去編寫配置單,使得容易遺忘Chef的工作原理,而學習一門新的語言和工具又存在一個準入門檻.

他們最初的Docker平臺是在Vagrant虛機環境中,后來他們遷移到定制化docker宿主機,最近遷移到了Docker4Mac.

Docker構建的第一個版本使用的是Codeship Docker CI beta版本,并且首次使用了Tutum(Docker Cloud)作為編排服務.

這次測試使用有很多缺點,包括Codeship的CI處理速度很慢,Docker構建本身就需要15分鐘.此外,Docker Tutum集群的部署需要10分鐘.有時候,他們慢得都不能確認它是否還在工作.他們還遇到了穩定性的問題,包括‘‘數據丟失’’和‘‘服務宕機’’.

由于需要提高CI過程的速度,并且提高Docker基礎設施的可靠性,Docker基礎設施2.0誕生了.

在運行Docker時,管道驅動的缺點包括：構建、測試和部署容器所需的時間；消費者只需要連接到健康服務；日常維護Jenkins工作,以前容器處理10,000個連接和連續的高負載.

使用Docker的好處包括：應用程序的演進–他們變得足夠通用,可以再多個地區和環境中運行；從想法到上線可以從兩周減少到一天；服務器與服務之間的管理是異步的.

Pipedirve容器采用持續增長：從去年10月以來,有70家公司的Docker服務,90個Docker容器鏡像,500個容器運行,3200個容器部署.Pipedrive上每天有30個容器部署,1個新增容器產生.

Renno對Docker化提出的建議包括：小心對待操作系統、閱讀GitHub上的問題、閱讀源碼、保持最新的數據和性能測試.

優點、缺點和痛點

最后,Jari Kolehmainen的想法引發了關于Docker的演講：優點、缺點和痛點,這讓人想到了如何在生產環節中使用Docker時避免“缺點和痛點”.其中一種方法是使用Kontena容器和微服務平臺——就像它在任何云上工作一樣,易于設置和使用.

Jari提到,在生產環境中使用Docker的第一步是“像一個過山車,有起有伏”,但它的好處超過了這個,而“最終你將會取得巨大的成功”.

對于那些還沒有在生產環境中運行Docker的人來說,也許您正在測試環境中運行它,那么第一步就是選擇正確的路徑,這對于向生產轉移是至關重要的.通常情況下,這條路是預先確定的,無論是項目限制(你必須使用數據中心或一些云服務等),但如果你可以自由選擇,那么你就有三個主要的選擇：DIY,租一個真正的云服務,或者你可以使用一個預制的平臺,比如Kontena.

在DIY模式中,你有一個引擎,比如Docker引擎,你試著調整并與你的團隊或你自己建立真正的“汽車”.

一般來說,這聽起來像是一件有趣的事情,你可以控制所有的事情,而且它是有效的.花了一些時間在實際的引擎上調優后,然后你就可以把所有的東西都放在生產環境上,有時候你可能會得到一輛有引擎的汽車,有很多管道膠帶、空調控制系統,但是你永遠不知道它什么時候會壞.

Jari的建議是“不要做”.在生產環境中,如果你是運行Docker的新手,DIY選項可能是一個有用的學習工具,但最好不要自己動手,因為你很可能只希望通過DIY過程完成自己的工作.

云租賃服務包括AWS、Azure、Kubernetes等提供商提供的一切服務,所有這些都是不錯的選擇.就像坐出租車一樣,你只需要支付一筆錢,你就可以讓整個系統準備好,而不需要維護任何東西.這可能比其他的方案更適合于個人使用.

但是,如果您的項目需要在一個數據中心或者某個沒有這些選項的地方運行,那么第三個選項很可能是正確的.

推薦的平臺包括：Docker集群(新)、Kubernetes、Kontena和DCOS.當你不想自己動手的時候,所有這些都是不錯的選擇.你可以選擇其中一種或另一種,但不推薦DIY.

像Kontena這樣的平臺,就像“預先準備完畢,做好開車的準備”,這讓你可以把注意力集中在你的應用上,而不是在汽車的外殼上.其中包括你需要完成日常任務的大部分功能以及不同的焦點,比如Kontena專注于易用性和易于維護,其他服務可能會關注可伸縮性.

作為一個DevOps的人,這些特性意味著需要更少的維護.因為平臺上有“所有的電池”和“戰斗測試”,這在生產環境中都很重要.

Docker引擎

即使你使用了之前提到的一個平臺,并且安裝了實際的LINUX發行版,安裝了docker引擎,并在上面安裝了平臺,還是有一些事情需要去考慮.當您第一次重新安裝Docker引擎時,您可以使用Red Hat、Ubuntu或這些發行版中的任何一個.通常來說,引擎的默認設置不適合實際的生產環境使用.您可以從Google上查看解決方案,并調整設置,以便引擎能夠處理您在生產環境中需要的實際負載.Docker引擎只是運行容器,它沒有配備完善,所以您需要配置日志管理、容器管理、卷等相關任務.

如果你不想改變默認的設置,Jari強烈建議你使用一個專為容器做的發行版.一個不錯的選擇是Core OS,它叫做容器Linux；Red Hat有自己的原子發行平臺；SUSE也有自己定制的容器配置.通常,這些類型的發行版會有更好的默認值,這些默認值實際上可能在生產環境中起作用.

您必須檢查的一個關鍵問題是圖形驅動程序,如果您使用的是最近的內核版本,您可以使用Overlay2.這是“今天的熱門話題”,但隨著下一個內核版本的發布,這種情況可能會有所改變.它是最快的選擇,你不應該使用它來解決很多問題,大多數發行版都是Overlay1.

默認的Overlay有一些缺點,但是您仍然可以在生產環境中使用它.如果你使用的是Ubuntu那么你可能會切換到Aufs,當你為核安裝了額外的軟件包后,可以切換到它,它也可以和Overlay2一樣工作.

“最痛點”的部分是設備映射,Jari認為這仍然是來源于Red Hat且通常會引起痛點的地方.如果您知道如何配置設備映射的內部關系,那么可以使用設備映射器.

Docker引擎有一個很酷的功能叫做“插件”.插件可以用來提供Overlay網絡,并為引擎提供容量存儲,但是有一個缺點：你不能在一個容器中運行這些插件,盡管他們說你可以,實際上你不能.所以盡量避免它.

從Docker版本1.13開始,插件架構 v0.2 被引入進來,它應該可以解決大部分的問題.

一個好的生產規則是保持所有的東西都是最新的.這包括Docker引擎,以及內核；這不僅是針對bug,還包括安全性.

CI/CD 管道

當你在生產環境中運行容器或微服務時,通常會有一大堆你想要處理的服務,如果沒有一個很好的管道,“你會發瘋的”.將這些容器從不同的階段轉移到生產時,必須考慮許多步驟和許多事情,如果不將該流程自動化,那么將會非常困難.基本上有三個階段：構建階段、測試階段和部署階段.

在構建階段,您不應該在自己的機器上構建或運行這些映像.相反,應該有一個CI系統來構建、測試并最終將它們部署到正確的環境中.

一些有用的建議：您應該將構建到測試,再到部署的所有內容(這不是容器特定的)放入腳本中.此外,擁有的配置和腳本都應該由版本控制管理.如果您沒有這樣做,那么在生產環境中運行時,就會遇到麻煩.最后,不要將關鍵信息放入配置文件中;這不是個好實踐.

您可以使用一個支持存儲關鍵信息的平臺,因為它提供了在不同的環境和不同的部署之間處理它們的方法.

一些優秀的管道工具

Jari的個人隱私工具：drone——它很好用,因為它迫使你認為一切都是一個容器.Drone內部的整個管道都是以容器形態運行的.如果你使用了像Travis這樣的工具,它是非常相似的,但是你可以在自己的數據中心里運行它.Jenkins是另一個眾所周知的選擇,但它更復雜一些,不是為容器設計的,但可以使用它.最后一個選擇是Gitlab CI–盡管Jari沒有使用這個工具的個人經驗,但他已經聽到了很多關于它的成功案例.

在這個管道示例中,我們構建自己的云服務時,senor開發人員正在嘗試以類似于Kontena的方式使用管道.

開發人員正在打包下一件重要的事情,當他將變更推送到GitHub時,drone就會集成在那里,獲取we hook,觸發構建,在容器內的管道內運行測試.如果一切正常,它將把實際的Docker鏡像推送到內部注冊中心.最后,它將觸發對Kontena的部署,取決于它是否是一個發布版本等等.通常情況下,它可能只需要幾分鐘的時間,就可以從Git-push部署到生產環境中.Kontena平臺在此過程中充當中介,它將負責所有的滾動部署,并處理負載均衡器的配置.因此,您不需要手動地將每個部件組裝起來.

安全

在生產中使用容器的前幾次,您可能會很高興有一些在生產中運行的東西,您可能不會真正考慮安全性以及應該如何處理它.但是,應該從測試和預發環境中考慮這一點.

審計跟蹤

(如在Kontena中發現的)允許您跟蹤系統的變更以及它們是由誰創建的.

安全補丁

值得推薦作為容器本地操作系統使用,例如,CoreOS將自動更新主機,并在更新完成時重新啟動.您還可以使用配置管理工具,如Chef、Ansible或Puppet來處理安全補丁.您應該為鏡像掃描服務投入一些時間,幫助識別您的Docker映像中的安全問題.例如,Docker Hub和CoreOS的Quay.io 均提供了這種功能.

一些平臺提供網絡安全功能(如Kontena做的).它們可能會加密主機之間或數據中心之間的所有通信.一些平臺包括的額外安全措施包括:創建網絡段、定義策略,以及作為最后的手段：配置防火墻.

為混亂做準備

混亂是生活的一個真實寫照,包括宿主機故障,引擎故障,容器失敗,應用程序崩潰.為“混亂可控”做好準備,意味著當事情發生的時候,這將不是什么大不了的事情.

在計劃生產環境時,強烈建議您這樣做,這樣您就可以在任何時候“殺死”任何主機、任何節點,這樣至少一個主機就可以被完全的暴力所強制,而其他服務一切都還正常.另一個建議是,如果您使用前面提到的任何一個平臺,請信任調度程序,使用集群數據庫,并盡可能將狀態開放,以盡可能流暢的運行Docker.

你可以從Jari的演講中看到幻燈片,地址：http://dwz.cn/66bOeJ.

關于 Kontena

Kontena公司是Kontena的創始人,它是一個開源的、開發人員友好的容器和微服務平臺.Kontena 通過簡化在任何基礎設施上的Docker化應用程序,包括在私有云、公有云或混合云,以達到最大化開發人員幸福的目的.它為任何規模的公司提供了完整的解決方案.Kontena于2015年3月成立,被認為是今年第8屆年度“黑天鵝”最佳新開源項目之一.更多信息,請訪問：www.kontena.io.

文章來自微信公眾號：Docker

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2727.html