用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。

下一步

为了了解更多关于容器和编制——二者涉及的技术，以及他们交付的业务利益——阅读这篇论文：点我就是跟上文提到的那篇论文，在如何get到副本集合上以及在GCE上运行Docker和Kubernetes上提供指导。
加入咱们的网络研讨会，一块儿讨论如何用Docker，Kubernetes和MongoDB来实施微服务，了解更多关于这个话题的东西。

原文连接