《在Docker和Kubernetes上運行MongoDB微服務》要點：
本文介紹了在Docker和Kubernetes上運行MongoDB微服務，希望對您有用。如果有疑問，可以聯系我們。

相關主題：非關系型數據庫

本文介紹了利用Docker和Kubernetes搭建一套具有冗余備份集合的MongoDB服務,從容器對CI和CD引發的改變入手,討論了容器技術對MongoDB帶來的挑戰和機會,然后實戰如何部署一套穩定的MongoDB服務,非常的干貨~

介紹

想嘗試在筆記本電腦上運行MongoDB么?希望通過執行一個簡單的命令,然后就有一個輕量級、自組織的沙盒么?并可再通過一條命令就可以移除所有的痕跡么?

需要在多個環境中運行相同的應用程序棧?創建自己的容器鏡像,使得開發、測試、操作和支持團隊啟動一份完全相同的環境.

容器正在改變整個軟件生命周期；它覆蓋了從最初的技術試驗到通過開發、測試、部署和支持的概念證明.

閱讀微服務：容器和編排白皮書(https://www.mongodb.com/collateral/microservices-containers-and-orchestration-explained).

編排工具管理著多個容器如何創建、升級和高可用.編排同樣管理著容器如何連接,并利用多個微服務容器創建穩定的應用服務.

豐富的功能、簡單的工具、強大的API讓容器和編排得到DevOps團隊的青睞.DevOps工程師將它們整合到持續集成(CI)和持續交付(CD)工作流中.

本篇文章將探索在嘗試運行和編排MongoDB容器時遇到的問題,并描述如何克服這些問題.

對于MongoDB的思考

采用容器和編排運行MongoDB帶來了一些新的思考：

• MongoDB數據庫節點是有狀態的.若一個容器掛了,并且被重新編排,數據丟失是不能接受的(雖然它可以從其他節點中恢復數據,但是很費時).為解決這個問題,Kubernetes中的卷抽象(Volume abstraction)特性將用于映射MongoDB數據文件夾到一個持久化地址,避免容器的失敗或重編排.

 

• 同一組MongoDB數據庫備份節點之間需要通信,即使是在重編排之后.同一冗余備份集合的節點必須知道全部其他節點的地址,但是當某個容器重編排之后,它的IP地址會變化.例如,所有Kubernetes內的容器共享一個IP地址,當pod被重編排之后這個地址就會改變.在Kubernetes中,這個問題可以通過聯系Kubernetes服務與MongoDB節點來解決,采用Kubernetes的DNS服務提供主機名給重編排之后的服務.

 

• 一旦每個獨立的MongoDB節點(每個節點在單獨容器中)啟動起來,備份集合必須初始化,并把每個節點加入進來.這需要編排工具提供額外的邏輯.特別是備份集合中只有一個MongoDB節點時,必須執行rs.initiate和rs.add命令.

 

• 如果編排框架提供自動化重編排容器功能(如Kubernetes的特性),那么這可以提高MongoDB的容災性,節點會在掛掉之后自動重新創建,恢復到完整冗余水平且不需要人工干預.

 

• 當編排框架掌控所有容器的狀態時,它并不管理容器內的應用或者備份數據.這就意味著采用一個有效的管理和備份方案很重要,如MongoDB Cloud Manager,包括MongoDB Enterprise Advanced和MongoDB Professional兩部分.考慮到需要創建鏡像,可采用你傾向的MongoDB版本和MongoDB Automation Agent.

利用Docker和Kubernetes實現MongoDB冗余備份

如前一節所述,MongoDB這類分布式數據庫在利用編排框架(如Kubernetes)進行部署時需要額外考慮.本節將對這部分細節進行分析,并介紹如何實現.

首先,我們在一個單獨的Kubernetes集群(同一個數據中心內,并不存在物理上的冗余備份)中創建整個MongoDB冗余集合.如果跨多個數據中心進行創建,其步驟也差異不大,后續將會介紹.

備份中的每個成員都運行在獨自的pod中,只暴露其IP地址和端口.固定的IP地址對于外部應用和其他冗余備份節點非常重要,它決定了哪些pod將被重新部署.

下圖展示了其中一個pod與關聯的冗余控制器和服務的關系.

深入這些配置中描述的資源,內容如下：

• 啟動核心節點mongo-node1.該節點包括了一個叫做的mongo的鏡像,來源于Docker Hub(https://hub.docker.com/_/mongo/),其暴露27107端口.

 

• Kubernetes的卷特性用于映射/data/db文件夾到持久化目錄mongo-persistent-storage1；該目錄為Google Cloud上創建的目錄映射mongodb-disk1,用于持久化MongoDB的數據.

 

• 容器由pod進行管理,標記為mongo-node,同時對rod提供一個隨機生成的名字.

 

• 冗余控制器命名為mongo-rc1,用于確保mongo-node1的實例一直處于運行中.

 

• 負載均衡服務命名為mongo-svc-a用27017暴露端口.該服務通過pod的標簽匹配正確的服務到對應的pod上,對外暴露的ip和端口給應用程序使用,同時用于冗余備份集合中各節點的通信.雖然每個容器擁有內部ip,但是當容器被重啟或者移動之后它們會變更,因此不能用于冗余備份集合之間的通信.

下圖展示了冗余備份及中的另一個成員信息：

?

90%的配置是相同的,只有幾處不同：

• 硬盤和卷的名字必須是唯一的,于是采用mongodb-disk2和mongo-persisitent-storage2

 

• Pod分配到jane實例,同時節點命名為mongo-node2,用于區分新服務與圖1中的Pod

 

• 冗余控制命名為mongo-rc2

 

• 服務命名為mongo-svc-b,并獲取一個不同的外部IP地址(本例子中,Kubernets分配為104.1.4.5)

第三個冗余備份成員的配置仿照上述的模式進行,下圖展示了完整的冗余配置集合：

?

注意,即使配置如圖3一樣,在一個三個或者多個節點的Kubernetes集群上,Kubernetes可能會調度兩個或者多個MongoDB冗余備份成員在同一個宿主機上.這是因為Kubernetes將三個pod視為三個獨立的服務.

為了增加冗余,需要創建一個額外的headless服務.該服務不具備提供外部服務的能力,甚至沒有外部IP地址,但是它用于通知Kubernetes這三個MongoDB Pod是屬于同一個服務,于是Kubernetes會將它們調度在不同的節點上.

具體的配置文件和相關操作命令可以從《啟動微服務：容器&調度說明白皮書》中找到.其中包含了三個特殊的步驟確保合并三個MongoDB到一個功能中,即本文中描述的冗余備份.

多個可用區域MongoDB冗余集合

所有冗余部件均運行在同一個GCE集群上時具有很高的風險,在同一個zone的集群也一樣.如果發生一個重大事件導致可用zone離線,那么MongoDB冗余集合也就不可用.如果需要地理上的冗余備份,那么三個pod需要運行在不同的zone內.

只需要很少的改動就可以創建這樣一個冗余備份集合.每一個集群需要獨自的Kubernetes YAML文件來定義pod、冗余控制器和服務.然后,就可以完成一個zone的集群創建、持久化存儲和MongoDB節點.

下圖展示了運行在不同zone上的冗余結合：

文：陳杰

文章出處：Docker

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