生產環境執行Docker的9個關鍵決策

本文講的是生產環境執行Docker的9個關鍵決策，【編者的話】生產環境執行Docker並沒有想象的那麼簡單，如何實現穩定安全的部署和擴容? 又有哪些需要考慮的關鍵決策? 本文就此做了一些分析和闡述，趕緊來看看吧！

也許你已經構建好了你的Rails或者基於Rack的Ruby應用。它甚至在你筆記本上的Docker容器裡執行著並且團隊裡的其他開發者也是這樣將它跑起來的。一切看上去棒極了，那麼或許是時候裝載它了。

不過，等一下！別急！將應用切換到生產環境中的Docker執行並沒有聽上去那麼簡單。這裡面要做的可不僅僅只是將你本地構建的容器映象裝載到生產環境而已。

讓我們一起來看看，在你可以安全地將容器化的Rails以及基於Rack的Ruby應用部署到生產環境之前你將可能面臨的9個最主要的關鍵決策。

關鍵決策 #1：映象管理

在開發環境裡為構建映象而設定一個Dockerfile及docker-compose.yml是相當簡單的，因此在生產環境裡你也應當建立一個一致的流程來構建Docker映象檔案。這將可以消除對本地環境的任何顧慮，避免了依賴於開發環境筆記本來作為你構建新映象的唯一手段。它還使得你可以建立一個不用開發團隊手工干涉的從程式碼提交到Docker映象的持續部署管道。

除非你打算將你的Docker映象對外公開，否則的話你可能還需要一個私有的Docker映象倉庫。雖然Docker官方提供了一個私有映象倉庫允許你自己來部署和管理映象，然而，你可能並不願意採用它，畢竟如果它發生故障的話會打斷你的釋出流程。你將需要選擇一款方案來加固私有Docker映象，同時還得保證在構建和部署過程中可以訪問到它們。

關鍵決策 #2：選擇一個雲服務提供商

一旦你已經擁有了一個Docker的映象，你需要做的便是將它部署到一臺Docker宿主機上。許多雲服務提供商如今已經加入了對Docker容器部署的支援。由於這裡面大多數是根據所使用的資源而不是容器例項來收費，怎樣核查定價細節以避免天價賬單就顯得至關重要了。

請注意，如果容器的部署過程橫跨多個雲服務提供商的話，這可能會造成將來變更雲服務提供商變得更加困難。如果你希望使用多個雲服務提供商或者想防止被圈死的話，你將需要做的是建立對多重雲服務提供商的支援（或者找到一個支援這樣做的解決方案）。

關鍵決策 #3：網路訪問和安全補丁

在本地開發環境裡執行的容器不會有嚴重的安全風險。所有程式都執行在單臺主機上，生產伺服器上常見的網路入侵風險以及各式各樣的攻擊載體均被隔離開來。

在開發期間為了便於排障，開發環境的配置一般是相對開放的。而在生產環境裡，網路的配置則需要考慮更多方面。公網流量不應該有訪問某些容器的許可權，而應該只有內網的其他容器才可以訪問它們。通過對網路流量的監控，暴力登陸攻擊，以及其他的攻擊載體必須被識別出來然後妥當地處理掉。

此外，你還得在安全補丁釋出後及時跟進，然後判斷你的宿主機和容器是否依然都是安全地還是需要將補丁打上去。

將你的容器挪到生產環境的話需要考慮網路訪問以及如何保證容器和Docker宿主機能及時地打上安全補丁等問題。對於生產環境而言千萬不要忽視這一關鍵步驟。

關鍵決策 #4：容器和宿主機之間的負載均衡

一旦從單個的容器服務轉到跨越一個或多個宿主機的多個容器，我們便將需要對應的負載均衡器來分發傳入的請求。常見的做法是使用像nginx或HAProxy這樣的工具來實現。難點主要在於需要保證當容器建立或銷燬時它們的配置能夠及時更新，為擴容而新增到生產的新Docker宿主機也是如此。你可以及時通過工具或指令碼來滿足這類需求。

需要注意的是，除非你打算在更新後將現有的部署下線，否則你將不得不支援應用服務同一時間多個版本同時執行的情況。你的負載均衡策略需要將這個計算在內，以防止使用者連線的丟失又或者是將流量路由到錯誤的版本。

想了解更多關於如何選擇負載均衡策略的資訊的話，歡迎閱讀我們在伺服器擴容技術方面的文章。

關鍵決策 #5：部署過程

許多開發者認為那些他們在開發環境裡用到的工具也將在生產環境裡工作。不是這樣的。Docker Compose的配置從開發到生產將會有很大的不同。從卷的設定到埠的繫結以及網路的配置，佈設容器的方式會發生變化。由於挪到了多宿主機的環境複雜度也會相應提高。你可能還需要一些在開發環境不常見的額外容器，例如日誌聚合器，外部資料庫，以及高可用的訊息代理（僅僅列舉幾個）。

協調不同環境配置之間的差異也需要相當大的指令碼化的努力。這可不會像它在開發環境裡docker-compose up那麼簡單。你需要留出足夠的時間來解決這些細節問題，因為你已然從一個簡單的，單個容器應用轉變為一組複雜的容器映象，每個對應多個例項，並且它們需要被佈設到負載均衡器後面以分發處理工作負載。隨著你的應用不斷地更迭以及流量的提升，還將採用滾動升級(rolling upgrades)或者藍-綠部署(blue-green deployment)等策略以防止站點故障。

不太瞭解有哪些有效的部署策略？可以檢視雲原生應用的釋出策略這篇文章來了解更多。

關鍵決策 #6：服務發現

隨著容器數量的不斷增長，也就自然帶來了額外地管理他們的註冊以供應用消費的開銷。業界有多種工具可以用來管理這個流程，大多數需要整合和配置到你的Docker生產環境裡。與此不同的是，Cloud 66找到了一個更為簡單的管理服務註冊中心的方式，那便是利用內部的DNS伺服器來實現。

無論你選擇的是哪款方案，都得確保你的服務註冊和你的容器例項同步，並且在容器擴充套件到多臺Docker宿主機的時候在負載均衡策略方面有所響應。這樣做將可以保證你的應用可以編碼成一個通用的服務名稱（例如myservice.mycluster.local），它可以用來將請求路由到特定的容器例項服務。

關鍵決策 #7：日誌管理

在開發環境裡使用Docker Compose的話可以看到詳細的日誌輸出並且可以快速的排障。而切換到跨越任意數量的宿主機的多個容器例項的場景時，這便會變得更難去排查當機問題。

分散式日誌策略使得伺服器可以從一個或多個的日誌伺服器上採集和聚合日誌記錄。生產環境的基礎設施也將需要支援跨越容器的日誌聚合。你還得考慮該如何規劃查詢和搜尋這些日誌來配合排障等因素。

關鍵決策 #8：監控容器

在生產環境裡對容器的監控是必不可少的。從Docker宿主機到容器，你需要知道每個服務及整體系統的健康性。選擇正確的工具和監控策略可以確保你儘可能地減少中斷的影響並且最大限度地提高主機資源利用率，從而改善使用者的體驗。

不知道你需要什麼樣的監控策略？我們有一份監控策略指南也許可以幫到你。

關鍵決策 #9：資料庫管理

在開發環境，資料庫可以託管在容器裡而無需擔心I/O效能方面的問題。生產環境則無法容忍糟糕的效能，尤其是當我們想交付的是絕佳的使用者體驗的時候。根據需求擴充套件資料庫以處理日益增長的I/O，配套高可用和可靠的備份/還原策略是成功執行一個現代Web應用或者移動端API的關鍵所在。生產環境所選擇的策略將會對你的使用者產生積極或消極的影響。

你可以閱讀我們關於擴充套件生產環境資料庫的文章來了解更多內容。

我真的需要馬上做出這些決策嗎？

是的，很有可能。除非你正要部署的是一個只有小流量訪問的簡單應用或者API，否則的話這裡面的每個決策都將會是影響產品成功的關鍵。看上去有一點擔子，不是嗎？

開發人員需要記住的是Docker是一款工具，而不是一個全面的雲原生應用架構的解決方案。它提供了一些精彩的功能特性，並且我很高興能夠將Docker作為我的基礎架構的一部分。但是，它同其他基於雲的解決方案一樣需要付出同等的努力（甚至大概還會多一些）來維護一個生產環境的Docker部署。

使用Cloud66在生產環境裡管理容器的話則無需再有這些方方面面的無窮顧慮。通過自定義一些配置檔案，我可以將我的環境從開發遷移到生產並且獲得他們平臺提供的所有好處：內建的日誌，安全的網路訪問管理，監控，持續交付，補丁管理，以及他們按需提供的資料庫即服務（Database-as-a-Service）。

親自去嘗試一下吧，看看部署及管理自己的Docker生產環境究竟能變得多簡單輕鬆！

原文連結：9-crtitical-decisions-needed-to-run-docker-in-production （翻譯：吳佳興)

原文釋出時間為：2016-05-12

本文作者：colstuwjx

本文來自雲棲社群合作伙伴DockerOne，瞭解相關資訊可以關注DockerOne。

原文標題：生產環境執行Docker的9個關鍵決策