用Docker和Kubernetes將MongoDB作為微服務(wù)來運(yùn)行

Neilyo 發(fā)布于2019-07-01 16:22 / 3432人閱讀

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

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

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

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

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

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

MongoDB注意事項

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

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

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

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

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

值得注意的是，編制工具可能監(jiān)控容器的狀態(tài)的同時，也可能監(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自動化代理的版本。

使用Docker和Kubernetes實現(xiàn)MongoDB副本集合

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

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

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

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

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

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

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

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

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

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

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

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

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

Replication Controller被命名為mongo-rc2

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

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

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

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

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

多個可用性區(qū)域 MongoDB副本集合

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

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

下一步

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

原文鏈接