使用 Docker 和 Kubernetes 將 MongoDB 作為微服務運行
介紹
想在筆記本電腦上嘗試 MongoDB?只需執行一個命令,你就會有一個輕量級的、獨立的沙箱。完成後可以刪除你所做的所有痕迹。
想在多個環境中使用相同的 程序棧 副本?構建你自己的容器鏡像,讓你的開發、測試、運維和支持團隊使用相同的環境克隆。
容器正在徹底改變整個軟體生命周期:從最早的技術性實驗和概念證明,貫穿了開發、測試、部署和支持。
編排工具用來管理如何創建、升級多個容器,並使之高可用。編排還控制容器如何連接,以從多個微服務容器構建複雜的應用程序。
豐富的功能、簡單的工具和強大的 API 使容器和編排功能成為 DevOps 團隊的首選,將其集成到連續集成(CI) 和連續交付 (CD) 的工作流程中。
這篇文章探討了在容器中運行和編排 MongoDB 時遇到的額外挑戰,並說明了如何克服這些挑戰。
MongoDB 的注意事項
使用容器和編排運行 MongoDB 有一些額外的注意事項:
- MongoDB 資料庫節點是有狀態的。如果容器發生故障並被重新編排,數據則會丟失(能夠從副本集的其他節點恢復,但這需要時間),這是不合需要的。為了解決這個問題,可以使用諸如 Kubernetes 中的 數據卷 抽象等功能來將容器中臨時的 MongoDB 數據目錄映射到持久位置,以便數據在容器故障和重新編排過程中存留。
- 一個副本集中的 MongoDB 資料庫節點必須能夠相互通信 - 包括重新編排後。副本集中的所有節點必須知道其所有對等節點的地址,但是當重新編排容器時,可能會使用不同的 IP 地址重新啟動。例如,Kubernetes Pod 中的所有容器共享一個 IP 地址,當重新編排 pod 時,IP 地址會發生變化。使用 Kubernetes,可以通過將 Kubernetes 服務與每個 MongoDB 節點相關聯來處理,該節點使用 Kubernetes DNS 服務提供「主機名」,以保持服務在重新編排中保持不變。
- 一旦每個單獨的 MongoDB 節點運行起來(每個都在自己的容器中),則必須初始化副本集,並添加每個節點到其中。這可能需要在編排工具之外提供一些額外的處理。具體來說,必須使用目標副本集中的一個 MongoDB 節點來執行
rs.initiate
和rs.add
命令。 - 如果編排框架提供了容器的自動化重新編排(如 Kubernetes),那麼這將增加 MongoDB 的彈性,因為這可以自動重新創建失敗的副本集成員,從而在沒有人為干預的情況下恢復完全的冗餘級別。
- 應該注意的是,雖然編排框架可能監控容器的狀態,但是不太可能監視容器內運行的應用程序或備份其數據。這意味著使用 MongoDB Enterprise Advanced 和 MongoDB Professional 中包含的 MongoDB Cloud Manager 等強大的監控和備份解決方案非常重要。可以考慮創建自己的鏡像,其中包含你首選的 MongoDB 版本和 MongoDB Automation Agent。
使用 Docker 和 Kubernetes 實現 MongoDB 副本集
如上節所述,分散式資料庫(如 MongoDB)在使用編排框架(如 Kubernetes)進行部署時,需要稍加註意。本節將介紹詳細介紹如何實現。
我們首先在單個 Kubernetes 集群中創建整個 MongoDB 副本集(通常在一個數據中心內,這顯然不能提供地理冗餘)。實際上,很少有必要改變成跨多個集群運行,這些步驟將在後面描述。
副本集的每個成員將作為自己的 pod 運行,並提供一個公開 IP 地址和埠的服務。這個「固定」的 IP 地址非常重要,因為外部應用程序和其他副本集成員都可以依賴於它在重新編排 pod 的情況下保持不變。
下圖說明了其中一個 pod 以及相關的複製控制器和服務。
圖 1:MongoDB 副本集成員被配置為 Kubernetes Pod 並作為服務公開
逐步介紹該配置中描述的資源:
- 從核心開始,有一個名為
mongo-node1
的容器。mongo-node1
包含一個名為MARKDOWN_HASH1ed75a5d1e2c0bb05f410077765af687MARKDOWNHASH
的鏡像,這是一個在 [Docker Hub](https://hub.docker.com//mongo/) 上託管的一個公開可用的 MongoDB 容器鏡像。容器在集群中暴露埠27107
。 - Kubernetes 的數據卷功能用於將連接器中的
/data/db
目錄映射到名為mongo-persistent-storage1
的永久存儲上,這又被映射到在 Google Cloud 中創建的名為mongodb-disk1
的磁碟中。這是 MongoDB 存儲其數據的地方,這樣它可以在容器重新編排後保留。 - 容器保存在一個 pod 中,該 pod 中有標籤命名為
mongo-node
,並提供一個名為rod
的(任意)示例。 - 配置
mongo-node1
複製控制器以確保mongo-node1
pod 的單個實例始終運行。 - 名為
mongo-svc-a
的負載均衡
服務給外部開放了一個 IP 地址以及27017
埠,它被映射到容器相同的埠號上。該服務使用選擇器來匹配 pod 標籤來確定正確的 pod。外部 IP 地址和埠將用於應用程序以及副本集成員之間的通信。每個容器也有本地 IP 地址,但是當容器移動或重新啟動時,這些 IP 地址會變化,因此不會用於副本集。
下一個圖顯示了副本集的第二個成員的配置。
圖 2:第二個 MongoDB 副本集成員配置為 Kubernetes Pod
90% 的配置是一樣的,只有這些變化:
- 磁碟和卷名必須是唯一的,因此使用的是
mongodb-disk2
和mongo-persistent-storage2
- Pod 被分配了一個
instance: jane
和name: mongo-node2
的標籤,以便新的服務可以使用選擇器與圖 1 所示的rod
Pod 相區分。 - 複製控制器命名為
mongo-rc2
- 該服務名為
mongo-svc-b
,並獲得了一個唯一的外部 IP 地址(在這種情況下,Kubernetes 分配了104.1.4.5
)
第三個副本成員的配置遵循相同的模式,下圖展示了完整的副本集:
圖 3:配置為 Kubernetes 服務的完整副本集成員
請注意,即使在三個或更多節點的 Kubernetes 群集上運行圖 3 所示的配置,Kubernetes 可能(並且經常會)在同一主機上編排兩個或多個 MongoDB 副本集成員。這是因為 Kubernetes 將三個 pod 視為屬於三個獨立的服務。
為了在區域內增加冗餘,可以創建一個附加的 headless 服務。新服務不向外界提供任何功能(甚至不會有 IP 地址),但是它可以讓 Kubernetes 通知三個 MongoDB pod 形成一個服務,所以 Kubernetes 會嘗試在不同的節點上編排它們。
圖 4:避免同一 MongoDB 副本集成員的 Headless 服務
配置和啟動 MongoDB 副本集所需的實際配置文件和命令可以在白皮書《啟用微服務:闡述容器和編排》中找到。特別的是,需要一些本文中描述的特殊步驟來將三個 MongoDB 實例組合成具備功能的、健壯的副本集。
多個可用區 MongoDB 副本集
上面創建的副本集存在風險,因為所有內容都在相同的 GCE 集群中運行,因此都在相同的 可用區 中。如果有一個重大事件使可用區離線,那麼 MongoDB 副本集將不可用。如果需要地理冗餘,則三個 pod 應該在三個不同的可用區或地區中運行。
令人驚奇的是,為了創建在三個區域之間分割的類似的副本集(需要三個集群),幾乎不需要改變。每個集群都需要自己的 Kubernetes YAML 文件,該文件僅為該副本集中的一個成員定義了 pod、複製控制器和服務。那麼為每個區域創建一個集群,永久存儲和 MongoDB 節點是一件很簡單的事情。
圖 5:在多個可用區域上運行的副本集
下一步
要了解有關容器和編排的更多信息 - 所涉及的技術和所提供的業務優勢 - 請閱讀白皮書《啟用微服務:闡述容器和編排》。該文件提供了獲取本文中描述的副本集,並在 Google Container Engine 中的 Docker 和 Kubernetes 上運行的完整的說明。
作者簡介:
Andrew 是 MongoDB 的產品營銷總經理。他在去年夏天離開 Oracle 加入 MongoDB,在 Oracle 他花了 6 年多的時間在產品管理上,專註於高可用性。他可以通過 @andrewmorgan 或者在他的博客(clusterdb.com)評論聯繫他。
via: https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes
作者:Andrew Morgan 譯者:geekpi 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive