摘要：注意事項(xiàng)用容器和編排工具運(yùn)行介紹了一些額外注意事項(xiàng)數(shù)據(jù)庫是有狀態(tài)的。尤其，在副本集合中，一個(gè)節(jié)點(diǎn)必須被用來執(zhí)行和命令。名字叫做的被配置用來確保的單個(gè)實(shí)例是一直在運(yùn)行的。

想要在你的手提電腦上嘗試MongoDB嗎？執(zhí)行一個(gè)命令，然后擁有一個(gè)輕量級(jí)，獨(dú)立的沙箱；再執(zhí)行一個(gè)命令，刪除你完成之后所有的痕跡。是不是需要一個(gè)在多個(gè)環(huán)境中都跟你的應(yīng)用程序堆棧一樣的應(yīng)用程序？創(chuàng)建一你自己的容器鏡像，然后讓你的開發(fā)，測(cè)試，操作和支持團(tuán)隊(duì)搭建一個(gè)跟你環(huán)境完全一樣的克隆版本。

容器正在徹底改革整個(gè)軟件生命周期：從最早的技術(shù)實(shí)驗(yàn)到貫穿開發(fā)，測(cè)試，配置到版本支持的概念驗(yàn)證。

編排工具是管理多個(gè)容器如何被創(chuàng)建、如何升級(jí)、如何發(fā)揮高可用性的。編排工具也可以控制多個(gè)容器之間的連接關(guān)系來達(dá)到 用多個(gè)容器來搭建一個(gè)復(fù)雜的應(yīng)用的效果。

齊全的功能，簡(jiǎn)單的工具和強(qiáng)大的API令容器和編排功能成為運(yùn)維團(tuán)隊(duì)的最愛，運(yùn)維團(tuán)隊(duì)將這些功能整合到持續(xù)集成（CI）和持續(xù)交付（CD）工作流程之中。

這篇帖子深入研究了當(dāng)你們嘗試在容器中運(yùn)行和編程MongDB時(shí)所面臨的挑戰(zhàn)，然后闡述了這些挑戰(zhàn)如何克服。

用容器和編排工具運(yùn)行MongoDB介紹了一些額外注意事項(xiàng)：

MongoDB數(shù)據(jù)庫是有狀態(tài)的。在容器運(yùn)行失敗，并且重新調(diào)度之后，數(shù)據(jù)丟失是不合需要的（可以通過從replica set中的其他節(jié)點(diǎn)恢復(fù)數(shù)據(jù)，但是需要耗費(fèi)時(shí)間）。為了解決這個(gè)問題，Kubernetes中的數(shù)據(jù)卷這種抽象功能就可以被用來映射在容器中原本是MongoDB數(shù)據(jù)目錄，變成了一個(gè)持久數(shù)據(jù)目錄位置，在這個(gè)位置，數(shù)據(jù)的存活比容器運(yùn)行失敗、重新調(diào)度要長(zhǎng)。

在副本集合中的MongoDB數(shù)據(jù)庫節(jié)點(diǎn)必須要互相交流——重新調(diào)度之后也要交流。在副本集合之中的所有節(jié)點(diǎn)必須知道他們所有的peers，但是當(dāng)一個(gè)容器重新調(diào)度之后，它很可能會(huì)用不同IP地址重新啟動(dòng)。比如，所有在一個(gè)Kubernentes pod里面的容器共享一個(gè)IP地址，pod一旦重新調(diào)度，這個(gè)IP地址也會(huì)改變。有了Kubernetes，這個(gè)現(xiàn)象就可以通過將每個(gè)MongoDB與Kubernetes Service關(guān)聯(lián)來解決，使用的是Kubernetes DNS Service來為通過重新調(diào)度保持不變的servi ce提供hostname。

一旦但個(gè)MongoDB節(jié)點(diǎn)在運(yùn)行（每個(gè)都在自己的容器中），副本集合必須要初始化，而且每個(gè)節(jié)點(diǎn)都要添加。這大概就需要一些額外的邏輯性來提供現(xiàn)成的編制工具。尤其，在intended副本集合中，一個(gè)MongoDB節(jié)點(diǎn)必須被用來執(zhí)行rs.initiate和rs.add命令。

如果編制框架提供自動(dòng)的容器重調(diào)度（如同Kubernetes一樣），那么這就能夠增加MongoDB的彈性，因?yàn)檫\(yùn)行失敗的副本集合構(gòu)建可以自動(dòng)重新創(chuàng)建，因此可以實(shí)現(xiàn)恢復(fù)完整的冗余控制水平無需任何人工干預(yù)。

值得注意的是，編制工具可能監(jiān)控容器的狀態(tài)的同時(shí)，也可能監(jiān)控在容器內(nèi)運(yùn)行的應(yīng)用程序，或者備份他們的數(shù)據(jù)。這就意味著使用強(qiáng)大的監(jiān)控功能，備份像MongoDB Cloud Manager解決方法都是不可能的，包括使用Mongo DB Enterprise Advanced也是不可能的?？紤]一些創(chuàng)建自己的鏡像，鏡像可以包括自己喜歡包括MongoDB和MongoDB自動(dòng)化代理的版本。

在之前的小節(jié)也講過，像MongoDB 這樣的分布式數(shù)據(jù)庫，在使用像Kubernetes這樣的編制框架時(shí)，需要一些額外的警示。這個(gè)小節(jié)會(huì)講到下個(gè)層次的細(xì)節(jié)，展示如何實(shí)施。

我們從在單個(gè)Kubernetes集群中創(chuàng)建整個(gè)MongoDB副本集合開始（這個(gè)正常的話，會(huì)在單個(gè)的數(shù)據(jù)中心——不會(huì)提供地理性備援）事實(shí)上，基本上不會(huì)有被改變到在多個(gè)集群上面運(yùn)行的，這些步驟之后會(huì)講到。

每個(gè)副本集合的構(gòu)件都將作為自己的pod被運(yùn)行，伴隨著暴露外部IP地址和端口的服務(wù)。這個(gè)“固定的”（fixed）IP地址十分重要，因?yàn)橥獠繎?yīng)用程序和其他副本集成構(gòu)件可以在pod重新調(diào)度的時(shí)候保持不變，繼續(xù)依賴它。

下圖闡述了這些pods之中的一個(gè)，以及相關(guān)的Replication Controller和service。

逐步通過描述的資源配置，我們有：

從核心開始，這里有叫做mongo-node1的單個(gè)容器，mongo-node1包含了一個(gè)叫做 mongo的鏡像，它就是在Docker Hub上面集群的公開的MongoD B容器鏡像。容器在集群里面暴露端口27107。

Kubernetes 數(shù)據(jù)卷功能被用來在映射 /data/db目錄，在連接到叫做mongo-persistent-storage1持久性數(shù)據(jù)元素；這些依次都是映射到一個(gè)創(chuàng)建在Google Cloud 的叫做mongodb-disk1的磁盤里的。這就是MongoDB存儲(chǔ)數(shù)據(jù)的地方，這樣，它就會(huì)被保存到容器中重新調(diào)度。

容器被保存在一個(gè)pod中，這個(gè)pod上有個(gè)標(biāo)簽標(biāo)著它自己的名字 mongo-node，而且它還提供名字叫做rod的實(shí)例。

名字叫做mongo-rc1的Replication Controller被配置用來確保mongo-node1pod的單個(gè)實(shí)例是一直在運(yùn)行的。

名字叫mongo-svc-a的 LoadBalancerservice暴露了一個(gè)IP地址到外界，還暴露了27017 借口，這個(gè)接口可以在容器中被mapped到同一個(gè)容器的接口數(shù)字。Service使用選擇器來識(shí)別正確pod匹配pod的標(biāo)簽。外部IP地址和接口會(huì)被用于應(yīng)用程序，以及用于副本集成之間的交流。每個(gè)容器都有本地IP地址，但是這些IP地址會(huì)在容器被移動(dòng)或者重新啟動(dòng)的時(shí)候改變，而使用副本集合就不會(huì)。
下一張圖展示了副本集合的第二個(gè)構(gòu)件。

90%的配置都是一樣的，只有這些改變了：

磁盤和數(shù)據(jù)卷名字必須是唯一的，這樣mongodb-disk2和mongo-persistent-storage2會(huì)被使用。

pod被用來設(shè)置instance: jane和 name:mongo-node2的標(biāo)簽，這樣新的service就可以從圖1中的rodPod區(qū)別它（通過選擇器）。

Replication Controller被命名為mongo-rc2

Service被命名為mongo-svc-b ，并且有一個(gè)唯一的，外部IP地址（在這個(gè)實(shí)例中，Kubernetes被賦值104.1.4.5）。

第三個(gè)副本集合構(gòu)件也是相同的模式，下圖就展示了完整的副本集合：

注意，即使在3個(gè)或者更多節(jié)點(diǎn)的Kubernetes集群上運(yùn)行像圖3所示的配置，Kubernetes可能（通常都會(huì)）會(huì)調(diào)度兩個(gè)或者更多的MongoDB副本集合構(gòu)件在同一個(gè)主機(jī)上。這是因?yàn)镵ubernetes講這三個(gè)節(jié)點(diǎn)看成三個(gè)獨(dú)立的service了。

為了增加冗余（在zone里面），一個(gè)額外的headless service被創(chuàng)建。新的service沒有提供新的性能來通知Kubernetes說，那三個(gè)MongoDB pods來自同一個(gè)service，所以KUbernetes嘗試在不同的節(jié)點(diǎn)上調(diào)度他們。

真實(shí)的需要編制和開啟MongoDB的副本集合的配置文件和命令行可以點(diǎn)擊這里查看：點(diǎn)我。特別是，有些特殊的步驟要求將三個(gè)Mongo DB實(shí)例組合到一個(gè)運(yùn)行的，強(qiáng)健的副本集合，這個(gè)的話，已經(jīng)在論文中講了。

所有東西都在同一個(gè)GCE集群里面運(yùn)行，所以副本集合創(chuàng)建的上述東西也還是伴隨著風(fēng)險(xiǎn)的，在同一個(gè)可用區(qū)域也是一樣的道理。假設(shè)有一個(gè)重大事故發(fā)生，可用區(qū)域離線了，那么MongoDB副本集合就不可用了。如果需要地理性備援，那么那三個(gè)pods就應(yīng)該在三個(gè)不同的可用性地帶或者區(qū)域運(yùn)行。

令人吃驚的是，為了分別在三個(gè)區(qū)域內(nèi)創(chuàng)建相似的副本集合，幾乎不需要改變什么——這就要求三個(gè)集群。每個(gè)集群都需要各自的KubernetesYAML文件，這個(gè)文件只定義了pod，Replication Controller和service作為副本集合的一個(gè)構(gòu)件。然后為每個(gè)區(qū)域都創(chuàng)建一個(gè)集群，持久性數(shù)據(jù)和MongoDB。

為了了解更多關(guān)于容器和編制——兩者涉及的技術(shù)，以及他們交付的業(yè)務(wù)利益——閱讀這篇論文：點(diǎn)我就是跟上文提到的那篇論文，在如何get到副本集合上以及在GCE上運(yùn)行Docker和Kubernetes上提供指導(dǎo)。
加入我們的網(wǎng)絡(luò)研討會(huì)，一起討論如何用Docker，Kubernetes和MongoDB來實(shí)施微服務(wù)，了解更多關(guān)于這個(gè)話題的東西。

原文鏈接