本文介紹了利用Docker和Kubernetes搭建一套具有冗余備份集合的MongoDB服務(wù)，從容器對CI和CD引發(fā)的改變?nèi)胧?，討論了容器技術(shù)對MongoDB帶來的挑戰(zhàn)和機(jī)會，然后實戰(zhàn)如何部署一套穩(wěn)定的MongoDB服務(wù)，非常的干貨~
介紹
想嘗試在筆記本電腦上運行MongoDB么?希望通過執(zhí)行一個簡單的命令，然后就有一個輕量級、自組織的沙盒么?并可再通過一條命令就可以移除所有的痕跡么?
需要在多個環(huán)境中運行相同的應(yīng)用程序棧?創(chuàng)建自己的容器鏡像，使得開發(fā)、測試、操作和支持團(tuán)隊啟動一份完全相同的環(huán)境。
容器正在改變整個軟件生命周期;它覆蓋了從最初的技術(shù)試驗到通過開發(fā)、測試、部署和支持的概念證明。
閱讀微服務(wù)：容器和編排白皮書(https://www.mongodb.com/collateral/microservices-containers-and-orchestration-explained)。
編排工具管理著多個容器如何創(chuàng)建、升級和高可用。編排同樣管理著容器如何連接，并利用多個微服務(wù)容器創(chuàng)建穩(wěn)定的應(yīng)用服務(wù)。
豐富的功能、簡單的工具、強(qiáng)大的API讓容器和編排得到DevOps團(tuán)隊的青睞。DevOps工程師將它們整合到持續(xù)集成(CI)和持續(xù)交付(CD)工作流中。
本篇文章將探索在嘗試運行和編排MongoDB容器時遇到的問題，并描述如何克服這些問題。
對于MongoDB的思考
采用容器和編排運行MongoDB帶來了一些新的思考：
MongoDB數(shù)據(jù)庫節(jié)點是有狀態(tài)的。若一個容器掛了，并且被重新編排，數(shù)據(jù)丟失是不能接受的(雖然它可以從其他節(jié)點中恢復(fù)數(shù)據(jù)，但是很費時)。為解決這個問題，Kubernetes中的卷抽象(Volume abstraction)特性將用于映射MongoDB數(shù)據(jù)文件夾到一個持久化地址，避免容器的失敗或重編排。
同一組MongoDB數(shù)據(jù)庫備份節(jié)點之間需要通信，即使是在重編排之后。同一冗余備份集合的節(jié)點必須知道全部其他節(jié)點的地址，但是當(dāng)某個容器重編排之后，它的IP地址會變化。例如，所有Kubernetes內(nèi)的容器共享一個IP地址，當(dāng)pod被重編排之后這個地址就會改變。在Kubernetes中，這個問題可以通過聯(lián)系Kubernetes服務(wù)與MongoDB節(jié)點來解決，采用Kubernetes的DNS服務(wù)提供主機(jī)名給重編排之后的服務(wù)。
一旦每個獨立的MongoDB節(jié)點(每個節(jié)點在單獨容器中)啟動起來，備份集合必須初始化，并把每個節(jié)點加入進(jìn)來。這需要編排工具提供額外的邏輯。特別是備份集合中只有一個MongoDB節(jié)點時，必須執(zhí)行rs.initiate和rs.add命令。
如果編排框架提供自動化重編排容器功能(如Kubernetes的特性)，那么這可以提高M(jìn)ongoDB的容災(zāi)性，節(jié)點會在掛掉之后自動重新創(chuàng)建，恢復(fù)到完整冗余水平且不需要人工干預(yù)。
當(dāng)編排框架掌控所有容器的狀態(tài)時，它并不管理容器內(nèi)的應(yīng)用或者備份數(shù)據(jù)。這就意味著采用一個有效的管理和備份方案很重要，如MongoDB Cloud Manager，包括MongoDB Enterprise Advanced和MongoDB Professional兩部分。考慮到需要創(chuàng)建鏡像，可采用你傾向的MongoDB版本和MongoDB Automation Agent。
利用Docker和Kubernetes實現(xiàn)MongoDB冗余備份
如前一節(jié)所述，MongoDB這類分布式數(shù)據(jù)庫在利用編排框架(如Kubernetes)進(jìn)行部署時需要額外考慮。本節(jié)將對這部分細(xì)節(jié)進(jìn)行分析，并介紹如何實現(xiàn)。
首先，我們在一個單獨的Kubernetes集群(同一個數(shù)據(jù)中心內(nèi)，并不存在物理上的冗余備份)中創(chuàng)建整個MongoDB冗余集合。如果跨多個數(shù)據(jù)中心進(jìn)行創(chuàng)建，其步驟也差異不大，后續(xù)將會介紹。
備份中的每個成員都運行在獨自的pod中，只暴露其IP地址和端口。固定的IP地址對于外部應(yīng)用和其他冗余備份節(jié)點非常重要，它決定了哪些pod將被重新部署。
下圖展示了其中一個pod與關(guān)聯(lián)的冗余控制器和服務(wù)的關(guān)系。
深入這些配置中描述的資源，內(nèi)容如下：
啟動核心節(jié)點mongo-node1。該節(jié)點包括了一個叫做的mongo的鏡像，來源于Docker Hub(https://hub.docker.com/_/mongo/)，其暴露27107端口。
Kubernetes的卷特性用于映射/data/db文件夾到持久化目錄mongo-persistent-storage1;該目錄為Google Cloud上創(chuàng)建的目錄映射mongodb-disk1，用于持久化MongoDB的數(shù)據(jù)。
容器由pod進(jìn)行管理，標(biāo)記為mongo-node，同時對rod提供一個隨機(jī)生成的名字。
冗余控制器命名為mongo-rc1，用于確保mongo-node1的實例一直處于運行中。