【编者的话】本文介绍了利用Docker和Kubernetes搭建一套具有冗余备份集合的MongoDB服务,从容器对CI和CD引发的改变入手,讨论了容器技术对MongoDB带来的挑战和机会,然后实战如何部署一套稳定的MongoDB服务,非常的干货~
想尝试在笔记本电脑上运行MongoDB么?执行一个简单的命令,然后你就有一个轻量级、自组织的沙盒;再通过一条命令就可以移除所有的痕迹。
需要在多个环境中运行相同的应用程序栈?创建你自己的容器镜像,让开发、测试、操作和支持团队启动一份完全相同的环境。
容器正在改变整个软件生命周期;从最初的技术试验到通过开发、测试、部署和支持的概念证明。
编排工具管理者多个容器如何创建、升级和高可用。编排同样管理着容器如何连接,并利用多个微服务容器创建稳定的应用服务。
丰富的功能、简单的工具、强大的API让容器和编排得到DevOps团队的青睐。DevOps工程师将它们整合到持续集成(CI)和持续交付(CD)工作流中。
本篇文章将探索你在尝试运行和编排MongoDB容器时遇到的问题,并描述如何克服这些问题。
采用容器和编排运行MongoDB带来了一些新的思考:
如前一节所述,MongoDB这类分布式数据库在利用编排框架(如Kubernetes)进行部署时需要额外考虑。本节将对这部分细节进行分析,并介绍如何实现。
首先,我们在一个单独的Kubernetes集群(同一个数据中心内,并不存在物理上的冗余备份)中创建整个MongoDB冗余集合。如果跨多个数据中心进行创建,其步骤也差异不大,后续将会介绍。
备份中的每个成员都运行在独自的pod中,只暴露其ip地址和端口。固定的IP地址对于外部应用和其他冗余备份节点非常重要,它决定了哪些pod将被重新部署。
下图展示了其中一个pod与关联的冗余控制器和服务的关系。
深入这些配置中描述的资源,内容如下:
mongo-node1
。该节点包括了一个叫做的mongo的镜像,来源于[Docker Hub],其暴露27107端口。 卷
特性用于映射 /data/db
文件夹到持久化目录mongo-persistent-storage1;该目录为Google Cloud上创建的目录映射mongodb-disk1,用于持久化MongoDB的数据。 下图展示了冗余备份及中的另一个成员信息:
90%的配置是相同的,只有几处不同:
第三个冗余备份成员的配置仿照上述的模式进行,下图展示了完整的冗余配置集合:
注意,即使配置如图3一样,在一个三个或者多个节点的Kubernetes集群上,Kubernetes可能会调度两个或者多个MongoDB冗余备份成员在同一个宿主机上。这是因为Kubernetes将三个pod视为三个独立的服务。
为了增加冗余,一个额外的 headless
服务需要被创建。新的服务不具备提供外部服务的能力,甚至没有外部IP地址,但是它用于通知Kubernetes这三个MongoDB Pod是属于同一个服务,于是Kubernetes会将它们调度在不同的节点上。
具体的配置文件和相关操作命令可以从 启动微服务:容器&调度说明白皮书 中找到。其中包含了三个特殊的步骤确保合并三个MongoDB到一个功能中,即本文中描述的冗余备份。
所有冗余部件均运行在同一个GCE集群上时具有很高的风险,在同一个zone的集群也一样。如果发生一个重大事件导致可用zone离线,那么MongoDB冗余集合也就不可用。如果需要地理上的冗余备份,那么三个pod需要运行在不同的zone内。
只需要很少的改动就可以创建这样一个冗余备份集合。每一个集群需要独自的Kubernetes YAML文件来定义pod、冗余控制器和服务。然后,就可以完成一个zone的集群创建、持久化存储和MongoDB节点。
下图展示了运行在不同zone上的冗余结合:
想学习更多关于容器和编排的内容,请阅读 启动微服务:容器&调度说明白皮书 。它提供了完整的说明,关于如何在Google容器引擎上运行Docker和Kubernetes来创建类似本文介绍的冗余备份集合。
原文链接: Running MongoDB as a Microservice with Docker and Kubernetes (翻译:陈杰)
===================================================
译者介绍
陈杰,BOSS直聘app的数据工程师,工作重心为基于用户行为的数据推荐,平时也乐于去实现一些突发的想法。在疲于配置系统环境时发现了Docker,跟大家一起学习、使用和研究Docker。