本文介绍了使用Docker和Kubernetes搭建一套具有冗余备份集的MongoDB服务。从容器对CI和CD带来的改变入手，探讨容器技术对MongoDB的影响。挑战与机遇并存，然后如何在实战中部署一套稳定的MongoDB服务，很干货~简介你想试试在笔记本上运行MongoDB吗？我希望通过执行一个简单的命令，就会有一个轻量级的、自组织的Sandbox吗？并用一个命令删除所有痕迹？需要在多个环境中运行相同的应用程序堆栈？创建您自己的容器镜像，使开发、测试、运营和支持团队能够启动一个完全相同的环境。容器正在改变整个软件生命周期；它涵盖了从最初的技术实验到通过开发、测试、部署和支持的概念验证。阅读微服务：容器和编排白皮书(https://www.mongodb.com/collat??eral/microservices-containers-and-orchestration-explained)。编排工具管理多个容器的创建、升级和高可用性。编排还管理容器的连接方式，并利用多个微服务容器来创建稳定的应用程序服务。丰富的功能、简单的工具和强大的API使容器和编排在DevOps团队中很受欢迎。DevOps工程师将它们整合到持续集成(CI)和持续交付(CD)工作流程中。这篇文章将探讨在尝试运行和编排MongoDB容器时遇到的问题，并描述如何克服这些问题。思考MongoDB使用容器和编排来运行MongoDB带来了一些新的思考：MongoDB数据库节点是有状态的。如果一个容器宕机并重新排列，数据丢失是不可接受的（虽然可以从其他节点恢复数据，但很耗时）。为了解决这个问题，Kubernetes中的Volume抽象特性将用于将MongoDB数据文件夹映射到一个持久地址，以避免容器故障或重组。同一组MongoDB数据库备份节点之间需要通信，即使重组后也是如此。同一冗余备份集中的节点必须知道所有其他节点的地址，但是当容器重新排列时，其IP地址会发生变化。例如，Kubernetes中的所有容器共享一个IP地址，该地址会在pod重新排序时发生变化。在Kubernetes中，这个问题可以通过联系Kubernetes服务和MongoDB节点，并使用KubernetesDNS服务为重新排列的服务提供主机名来解决。一旦启动了每个单独的MongoDB节点（每个节点都在一个单独的容器中），就必须初始化备份集并将其添加到每个节点。这需要编排工具提供额外的逻辑。特别是当备份集中只有一个MongoDB节点时，必须执行rs.initiate和rs.add命令。如果编排框架提供自动重排容器的功能（比如Kubernetes的特性），那么这可以提高MongoDB的容灾能力。节点挂掉后会自动重新创建，无需人工干预，恢复到全冗余级别。虽然编排框架持有所有容器的状态，但它不管理容器内的应用程序或备份数据。这意味着采用有效的管理和备份解决方案非常重要，例如MongoDBCloudManager，包括MongoDBEnterpriseAdvanced和MongoDBProfessional。考虑到需要创建镜像，您可以使用您喜欢的MongoDB版本和MongoDBAutomationAgent。使用Docker和Kubernetes实现MongoDB的冗余备份上一节提到，MongoDB等分布式数据库在使用编排框架（如Kubernetes）部署时需要额外考虑。本节将分析这部分的细节，并介绍如何实现。首先，我们在单独的Kubernetes集群中创建整个MongoDB冗余集合（在同一个数据中心，没有物理冗余备份）。如果跨多个数据中心创建，步骤差别不大，后面会介绍。备份中的每个成员都在自己的pod中运行，只公开其IP地址和端口。固定IP地址对于外部应用程序和其他冗余备份节点很重要，它们决定了将重新部署哪些pod。下图显示了其中一个pod与关联的冗余控制器和服务的关系。深入研究这些配置中描述的资源，如下所示：启动核心节点mongo-node1。该节点包含来自DockerHub(https://hub.docker.com/_/mongo/)的名为mongo的图像，它公开了端口27107。利用Kubernetes的volume特性将/data/db文件夹映射到持久化目录mongo-persistent-storage1；此目录是在GoogleCloud上为持久性MongoDB数据创建的目录映射mongodb-disk1。容器由pod管理，标记为mongo-node，并提供一个随机生成的名称给rod。名为mongo-rc1的冗余控制器用于确保mongo-node1实例始终运行。负载均衡服务名为mongo-svc-a并公开了端口27017。服务通过pod的标签将正确的服务匹配到对应的pod，暴露出来的ip和端口供应用程序使用，用于冗余备份集中节点间的通信。虽然每个容器都有一个内部ip，但是当容器重启或移动时它们会改变，所以不能用于冗余备份集之间的通信。下图是冗余备份和另外一个成员信息：90%的配置是一样的，只有一点点不同：硬盘和卷的名字必须是唯一的，所以mongodb-disk2和mongo-persisitent-storage2Pod是分配给jane实例，节点命名为mongo-node2，用于区分新服务和图1中的Pod冗余控制，服务命名为mongo-rc2，服务命名为mongo-svc-b,并获得不同的外部IP地址。（本例中Kubernets分配为104.1.4.5）第三个冗余备份成员的配置遵循上述模式。在具有一个或多个节点的Kubernetes集群上，Kubernetes可能会在同一主机上调度两个或多个MongoDB冗余备份成员。这是因为Kubernetes将三个pod视为三个独立的服务。为了增加冗余，需要创建额外的无头服务。这个服务不具备对外提供服务的能力，甚至没有对外的IP地址，但是用来通知Kubernetes这三个MongoDBPod属于同一个服务，所以Kubernetes会把它们调度到不同的节点上。具体的配置文件和相关操作命令可以在《启动微服务：容器&调度说明白皮书》中找到。确保将三个MongoDB合并为一个功能涉及三个具体步骤，即本文所述的冗余备份。多个可用区MongoDB冗余集运行在同一个GCE集群上的所有冗余组件都有很高的风险，同一个可用区的集群也是如此。如果发生重大事件使可用区下线，那么MongoDB冗余收集也不可用。如果需要地理冗余备份，那么三个pod需要在不同的可用区运行。这样的冗余备份集只需很少的修改即可创建。每个集群都需要自己的KubernetesYAML文件来定义pod、冗余控制器和服务。然后，您可以完成区域集群创建、持久存储和MongoDB节点。下图显示了在不同区域运行的冗余组合：
