Docker 集群环境实现的新方式

近几年来,Docker 作为一个开源的应用容器引擎,深受广大开发者的欢迎。随着 Docker 生态圈的不断建设,应用领域越来越广。云计算,大数据,移动技术的快速发展,加之企业业务需求的不断变化,紧随技术更新的步伐,导致企业架构要随时更改以适合业务需求。当前,越来越多的公司都已将以 Docker 为代表的容器技术用于企业级业务平台,比如:腾讯,京东,美团,新浪,阿里巴巴等互联网公司。数据的安全、Docker 容器的稳定运行是众多用户关注的,这就要求我们提供一套行之有效的管理大型容器集群的整体解决方案。为努力实现提供完整的容器技术服务栈及 Docker 化应用开发运维平台给用户的目标。在本文样例中,笔者使用 Docker 公司发布的 Docker Swarm 集群管理工具以及相关的第三方工具作为整个应用开发运维的基础架构。

引言

本文中介绍的架构,是为了实现多个 CentOS 7 主机上 Docker 集群的部署。该架构使用三个工具,分别是 Docker Swarm, consul 和 pipework。

采用 Docker Swarm,主要因为这是 Docker 公司发布的集群管理工具,兼容性和稳定性相比其他公司的 Docker 集群管理工具更出色一些。

实现集群内各节点之间服务发现的方式有多种,包括 etcd,consul 和 zookeeper 等。本文的架构采用的是 consul 方式。相比其他工具,consul 提供 web 管理端且其采用的算法更能保证服务的高可用性。

Docker 容器的 IP 是由 Docker 自带的默认路由通过 DHCP 自动分配,在实现 Docker 容器固定 IP 配置的第三方工具中,开源工具 pipework 简单易用,稳定性优于 weave,更适合当前的网络环境。

接下来,我们分别介绍这三种工具,首先介绍 Docker Swarm 的概念和工作机制。

Docker Swarm 的基本概念和原理 Docker Swarm 简介

Swarm 是 Docker 公司在 2014 年 12 月初发布的一套用来管理 Docker 集群的工具,将多个 Docker 宿主机变成一个单一的虚拟的主机。Swarm 使用标准的 Docker API 接口作为其前端访问入口,与 Docker Client 直接通信。

Docker Swarm 工作原理

Docker 客户端通过 Docker API 向 Swarm 管理端发送请求,Swarm Manager 通过守护进程调用集群中的某个节点来执行任务。因为容器都是运行在节点上,Swarm 作为一个独立的集群管理工具,故并不会因某些原因导致不能正常工作而影响集群内所有节点的正常运行。当服务恢复正常后,Swarm 会读取日志来执行集群的恢复动作。架构图如图 1:

图 1.Docker Swarm 架构图

Docker 集群环境实现的新方式

 

架构说明:

Docker Client 是用户端

Swarm Manager 作为管理程序运行在一台 CentOS 7 管理节点上,这个节点在 Swarm 集群中承担 leader 角色。

Swarm Node 01,02,N 是 Swarm 集群的其他成员,和 Swarm Manager 管理节点一起组成完整的 Swarm 集群,每一个节点都会运行 Swarm 容器。

Docker Daemon 是运行于每一个成员内的守护进程,承担着调度器和路由器的功能。

Discovery service 提供服务发现功能。

通过本章大家了解了什么是 Docker Swarm 及其工作原理,下一章将简要介绍用于提供服务发现功能的工具 consul。

服务发现工具 Consul

Consul 是一个分布式,高可用,支持多数据中心的服务发现和配置共享的服务管理软件,能够与 Docker 容器无缝配合。

Consul 工具的优势

1.一致性协议采用 Raft 算法,用来保证服务的高可用。

2.支持 Health Checking 和 http 和 dns 协议接口。健康检查是 Consul 提供的一项主要功能,根据配置定时调用外部程序执行有效性检查,返回状态有三种:正常,告警和失败。Consul 提供两种发现服务的方式,一种是通过 HTTP API 查看存在哪些服务,另外一种是通过 consul agent 内置的 DNS 服务来完成。两者的差别在于后者可以根据服务检查的实时状态动态调整可用的服务节点列表。

3.支持 Multi DataCenter,每一个数据中心(集群)是由 3-5 个 server 节点和若干 client 节点组成,集群内 Client 和 Server 节点之间是通过 LAN gossip(下一节会有介绍)通信,整个集群内部通信端口必须全部相同,默认是 7000。数据中心(集群)彼此间的通信则是通过 WAN gossip,使用的通信端口和集群内的通信端口不要一致,从而实现了内外网的服务采用不同的端口进行监听,进而可以避免单数据中心的单点故障。

4.提供 web 管理界面,更加直观。

Consul 的架构

笔者根据项目实际需求重新绘制了架构图,如图 2:

图 2.Consul 架构

Docker 集群环境实现的新方式

 

本架构采用单数据中心集群方式,由三个 Server 节点组成。

说明:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/5e3727edbe004874fe303b77ba46c81f.html