如何用Docker和Kubernetes將MongoDB作為微服務來運行

這期內容當中小編將會給大家帶來有關如何用Docker和Kubernetes將MongoDB作為微服務來運行，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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

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

編排工具是管理多個容器如何被創建、如何升級、如何發揮高可用性的。編排工具也可以控制多個容器之間的連接關系來達到 用多個容器來搭建一個復雜的應用的效果。

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

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

MongoDB注意事項

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

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

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

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

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

• 值得注意的是，編制工具可能監控容器的狀態的同時，也可能監控在容器內運行的應用程序，或者備份他們的數據。這就意味著使用強大的監控功能，備份像MongoDB Cloud Manager解決方法都是不可能的，包括使用Mongo DB Enterprise Advanced也是不可能的。考慮一些創建自己的鏡像，鏡像可以包括自己喜歡包括MongoDB和MongoDB自動化代理的版本。

使用Docker和Kubernetes實現MongoDB副本集合

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

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

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

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

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

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

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

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

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

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

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

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

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

Replication Controller被命名為mongo-rc2

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

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

注意，即使在3個或者更多節點的Kubernetes集群上運行像圖3所示的配置，Kubernetes可能（通常都會）會調度兩個或者更多的MongoDB副本集合構件在同一個主機上。這是因為Kubernetes講這三個節點看成三個獨立的service了。

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

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

多個可用性區域 MongoDB副本集合

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

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

上述就是小編為大家分享的如何用Docker和Kubernetes將MongoDB作為微服務來運行了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。