三個生產環境中使用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。