徐雷 frank 2019-03-16 22:05:05 浏览 52 评论 0
分布式
docker
MongoDB
数据库
配置
镜像
集群
微服务
容器
Image
编排
- kubernetes
- microservice
摘要: MongoDB 是 NoSQL 排名第一的数据库, Docker 是最流行的容器引擎, Kubernetes 是谷歌开源的容器编排工具! Kubernetes 和 Docker 使 MongoDB 的开发运维部署变得更加简单和强大.
作者: Andrew Morgan
译者: 徐雷
MongoDB 是 NoSQL 排名第一的数据库, Docker 是最流行的容器引擎, Kubernetes 是谷歌开源的容器编排工具! Kubernetes 和 Docker 使 MongoDB 的开发运维部署变得更加简单和强大.
1,Docker 背景介绍
想快速安装 MongoDB 吗? 现在只需要执行一个 Docker 命令, 就能快速启动一个轻量级, 独立的沙盒;
在多个不同的服务器环境中搭建集群, 快速部署相同的应用? 使用 Docker 容器会非常的简单, 构建自己的 Docker 容器映像, 让开发, 测试, 运营和支持团队启动相同的环境克隆.
Docker 容器正在彻底改变整个软件生命周期: 从最早的技术实验和概念证明到开发, 测试, 部署和支持.
Kubernetes 工具可以管理多个 Docker 容器的创建, 升级和高可用性. K8s 业务流程还控制容器如何连接以从多个微服务容器构建复杂的应用程序. Docker 容器和 K8s 编排已经成为 DevOps 团队的最爱, 现在广泛融入到持续集成 (CI) 和持续交付 (CD) 工作流程中.
本文深入探讨了在 Docker 容器中运行和编排 MongoDB 所面临的额外挑战, 并介绍这些挑战的解决办法.
** 如果要 Linux 实战 Docker 安装 MongoDB 可以参考我写的文章.《Linux 实战 Docker 容器安装 MongoDB, 阿里 Docker 镜像仓库加速》https://yq.aliyun.com/articles/691383.
2,MongoDB 容器的注意事项
使用 Docker 容器和 K8S 运行 MongoDB 额外注意事项:
MongoDB 数据库节点有状态信息. 如果 Docker 容器发生故障并重新编排可能导致数据丢失, 我们并不希望丢失数据(可以从副本集中的其他节点恢复, 但需要时间). 为了解决可能的数据丢失问题, 可以使用诸如 Kubernetes 中的 Volume 卷抽象之类的功能来将容器中临时性 MongoDB 数据目录映射到持久性位置, 这样就可以容忍容器故障和重新编排, 而不会丢失数据.
集群中的 MongoDB 数据库节点必须相互通信. 副本集中的所有节点都必须知道所有节点的地址, 但是当 Kubernetes 重新编排容器时, 可能会使用不同的 IP 地址重新启动. 例如, Kubernetes Pod 中的所有容器共享一个 IP 地址, 该地址在重新编排 pod 时会发生变化. 使用 Kubernetes, 可以通过将 Kubernetes 服务与每个 MongoDB 节点相关联来处理, 该节点使用 Kubernetes DNS 服务为通过重新安排保持不变的服务提供主机名.
每个 MongoDB 节点运行后(每个节点都在自己的容器中), 必须初始化副本集并添加每个节点. 这可能需要编排工具之外的代码. 具体而言, 必须使用目标副本集群中的主 MongoDB 节点执行 rs.initiate 和 rs.add 命令.
如果 K8s 编排框架提供容器的自动重新调度(如 Kubernetes 那样), 那么这可以提高 MongoDB 的弹性, 因为可以自动重新创建失败的副本集成员, 从而在没有人为干预的情况下恢复正常状态.
应该注意的是, 虽然 K8S 可能会监视容器的状态, 但它不太可能监视容器内运行的应用程序或备份数据. 这意味着我们需要再使用强大的监控和备份解决方案非常重要, 例如 MongoDB 企业高级版和 MongoDB 专业版附带的 MongoDB Cloud Manager. 考虑创建自己的镜像, 其中包含首选的 MongoDB 版本和 MongoDB 自动化代理.
3, 使用 Docker 和 Kubernetes 实现 MongoDB Replica Set 副本集群
如上所述, 当使用诸如 Kubernetes 之类的编排工具部署时, MongoDB 等分布式数据库需要特别小心. 本节将进一步详细介绍这一点.
我们首先在单个 Kubernetes 集群中创建整个 MongoDB 副本集群(通常位于单个数据中心内 -- 显然不提供地理冗余). 实际上, 很少需要更改配置来支持跨多个中心的集群架构, 这些步骤将在后面介绍.
Replica Set 副本集群的每个成员将作为单独的 pod 运行, 其中一个服务公开外部 IP 地址和端口. 这个 "固定" 的 IP 地址很重要, 因为外部应用程序和其他副本集成员可以依赖它, 在重新编排 pod 时保持地址不变.
下图说明了其中一个 pod 以及关联的 Replication Controller 和服务.
图 1: MongoDB Replica Set 副本集群成员配置为 Kubernetes Pod 并作为服务公开
配置 Kubernetes Pod 步骤如下:
开始创建名为 mongo-node1 的容器. mongo-node1 包含一个名为 mongo 的镜像, 这是一个托管在 Docker Hub 上的公开可用的 MongoDB 容器镜像. 容器公开集群中的端口 27107.
Kubernetes volumes 卷用于将 / data/db 目录映射到名为 mongo-persistent-storage1 的持久存储元素; 然后映射到在 Google Cloud 中创建的名为 MongoDB-disk1 的磁盘. 这是 MongoDB 存储数据的位置, 以便在容器重新调度时保持不变.
pod 内的容器实例, 标签 mongo-node, 实例名称 rod.
名为 mongo-rc1 的复制控制器, 目的是确保 mongo-node1 pod 的单个实例始终在运行.
名为 mongo-svc-a 的 LoadBalancer 服务向外界公开 IP 地址以及 27017 的端口, 该端口映射到容器中的相同端口号. 该服务使用与 pod 标签匹配的选择器来识别正确的 pod. 该外部 IP 地址和端口将由应用程序和副本集成员之间的通信使用. 每个容器也有本地 IP 地址, 但这些容器在移动或重新启动容器时会发生更改, 因此不会用于 Replica Set 副本集群.
下图显示了 Replica Set 副本集群的第二个成员的配置.
图 2: 第二个 MongoDB 副本集群成员配置为 Kubernetes Pod
只有这些配置不一样, 其他 90%的配置是相同的:
磁盘和卷名称必须唯一, 因此使用名称: MongoDB-disk2 和 mongo-persistent-storage2
来源: https://yq.aliyun.com/articles/693940