三個生産環境中使用Docker的案例

本文講的是<b>三個生産環境中使用Docker的案例</b>【編者的話】本文為2017年初Docker線下見面會的記錄，Solita、Zalando和Pipedrive公司做了Docker化經驗分享，并對生産環境中使用Docker的細節進行讨論。本文還推薦了一些Docker生産環境中常使用的優秀工具。

<a href="http://dockone.io/article/2376">【3 天燒腦式 Docker 訓練營 | 上海站】随着Docker技術被越來越多的人所認可，其應用的範圍也越來越廣泛。本次教育訓練我們理論結合實踐，從Docker應該場景、持續部署與傳遞、如何提升測試效率、存儲、網絡、監控、安全等角度進行。</a>

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

首先，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官方管道上的釋出。

随後，Rami Rantala介紹了Zalando公司的各個團隊和項目中是如何使用Docker用于部署生産系統。

在Zalando Helsinki的辦公地，這裡有超過100多名從業人員和多個團隊，他們負責不同的生産系統、相關探索研究、持續傳遞等工作，采用靈活開發的方式開發他們的平台。

每個自主團隊均有獨立的AWS賬号，而且無視了不可以在生産環境運作Docker的建議。據Rami介紹，在Zalando内，任何運作在AWS上的程式都采用了Docker運作，Docker被認為是唯一允許用于部署生産環境的工具。他們同樣有獨立的Docker資源庫（Pierone），他們自主的Docker基礎鏡像和每個執行個體運作一個全棧容器。

有很多領域還存在改進的空間，包括如下内容：部署太慢，他們丢失了Docker中層通信的優勢，每個執行個體運作一個容器的代價很高，導緻存在數千個執行個體；另一個問題在于Docker經常拖垮Pierone。

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

最後，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的人，這些特性意味着需要更少的維護。因為平台上有“所有的電池”和“戰鬥測試”，這在生産環境中都很重要。

即使你使用了之前提到的一個平台，并且安裝了實際的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系統來建構、測試并最終将它們部署到正确的環境中。

一些有用的建議：您應該将建構到測試，再到部署的所有内容（這不是容器特定的）放入腳本中。此外，擁有的配置和腳本都應該由版本控制管理。如果您沒有這樣做，那麼在生産環境中運作時，就會遇到麻煩。最後，不要将關鍵資訊放入配置檔案中;這不是個好實踐。

您可以使用一個支援存儲關鍵資訊的平台，因為它提供了在不同的環境和不同的部署之間處理它們的方法。

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。

===================================================

譯者介紹

陳傑，阿裡巴巴資料庫算法專家，工作重心為資料庫環境下的時序資料序列預測與異常檢測，平時也樂于去實作一些突發的想法。在疲于配置系統環境時發現了Docker，跟大家一起學習、使用和研究Docker。

<b>原文釋出時間為：</b>2017-06-09

<b>本文作者：</b>陳傑

<b>本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。</b>

<b>原文标題：</b><b>三個生産環境中使用Docker的案例</b>