Docker已经上市很多年,不是什么新鲜事物了,很多企业或者开发同学以前也不多不少有所接触,但是有实操经验的人不多,本系列教程主要偏重实战,尽量讲干货,会根据本人理解去做阐述,具体官方概念可以查阅官方教程,因为本系列教程对前一章节有一定依赖,建议先学习前面章节内容。
本系列教程导航:
Docker深入浅出系列 | 容器初体验
Docker深入浅出系列 | Image实战演练
Docker深入浅出系列 | 单节点多容器网络通信
Docker深入浅出系列 | 容器数据持久化
Docker深入浅出系列 | 单机Nginx+Springboot实战
Docker深入浅出系列 | Docker Compose多容器实战
教程目的:
1.克隆credit-facility-service
作为后面部署演示使用,使用docker
分支
2.虚拟机、centos和docker环境安装请查看第一章,本章默认已经安装好centos和docker
Docker深入浅出系列 | 容器初体验
简单来说,Docker Swarm就是一个把多个物理主机或者虚拟机组成的集群上的容器群进行管理的容器编排工具,负责编排、调度和集群管理,由集群的活动由集群管理器控制,加入集群的机器称为节点,允许用户管理跨多个主机部署的多个容器。
SwarmKit是可扩展分布式系统的节点发现、基于Raft的共识、任务调度、基于基元的编排工具包,该工具包使用Raft共识算法来协调和决策分布式系统。
以下列出了Docker Swarm的一些关键术语:
节点(Node): 在编排方面,节点是主机。 一个节点可以是单个主机中的多个VM。
管理节点(Manager Node): 此节点负责维护Swarm编排,它管理集群环境。
工作节点(Worker Node): 该节点负责执行管理节点定义的任务。 它将始终将其状态通知给Manager节点并提供分配给它的服务。
任务(Task): 任务包含一个Docker容器和在容器内运行的命令,它是swarm的原子调度单元,如果某一个任务奔溃,那么协调器将创建一个新的副本任务,该任务将生成一个新的容器
Docker Swarm和k8s都是目前的容器编排的主流技术,但是目前市场上大多数企业都是用k8s进行容器集群管理,k8s背靠Google这棵大树,开源社区也非常活跃,随着这些年云厂商的迅速发展,k8s是未来趋势,我个人建议在真实项目还是使用k8s进行容器编排和管理,不过这里是docker专场,我暂不多说,会在后面k8s专题去讲这一块内容。
假如没有Swarm这类多机容器管理技术,我们很难对容器进行管理,并且容器之间难以实现跨机器通信。而Docker swarm可以让用户轻松在多个机器上发布和管理应用,并且我们不需要关注每个容器实例具体落在哪一个节点,swarm把我们的应用以服务的形式暴露出去,并内置服务发现和负载均衡,让运行在多个节点上的容器集群感觉就像只有一个应用在跑一样简单,可以轻松实现扩容和自动容错(一个swarm任务的容器奔溃会自动扩展一个新的容器
)。Swarm集群通常有几个工作程序节点和至少一个管理程序节点,负责高效地处理工作程序节点的资源并确保集群有效地运行,提高了应用可用性。
Overlay - Overlay
网络管理参与集群的Docker守护程序之间的通信。您可以使用与独立容器的用户定义网络相同的方式创建Overlay
网络。您也可以将服务附加到一个或多个现有的Overlay
网络,以启用服务到服务的通信。Overlay
网络是使用Overlay
网络驱动程序的Docker网络。
ingress - ingress
网络是一种特殊的Overlay
网络,可促进服务节点之间的负载均衡。当任何集群节点在已发布的端口上收到请求时,会将请求转交给名为IPVS的模块。 IPVS通过ingress
网络跟踪参与该服务的所有IP地址,选择其中一个并将请求发送给它。
当对节点进行swarm init
或swarm join
操作时,会自动创建ingress
网络。大多数用户不需要自定义其配置,但是Docker 17.05及更高版本允许您自定义。
docker_gwbridge - docker_gwbridge
是一个桥接网络,它将overlay
网络(包括ingress
网络)连接到单个Docker守护程序的物理网络。默认情况下,服务正在运行的每个容器都连接到其本地Docker守护程序主机的docker_gwbridge
网络。
初始化或加入集群时会自动创建docker_gwbridge
网络,大多数用户不需要自定义其配置,但是Docker允许您自定义。
Docker Engine内有一个嵌入式DNS服务器,当Docker不以Swarm模式运行时,容器会使用这个服务器;而当Docker Engine以Swarm模式运行时,该服务器将用于任务(task)。 它为bridge
,Overlay
或MACVLAN
网络中主机上的所有容器提供名称解析。 每个容器将其查询请求转发到Docker引擎,后者依次检查该容器或服务是否与首先发送请求的容器在同一网络上。 如果是,它将在其内部键值存储中搜索与容器、任务或服务的名称匹配的IP(或虚拟IP)地址,并将其返回给发送请求的容器。
如果匹配的资源与生成请求的容器在同一网络内,则Docker引擎只会返回IP地址。 这样做的好处还在于,Docker主机仅存储属于该节点在其中具有容器或任务的网络的DNS条目。 这意味着它们将不会存储实际上与他们无关的信息,或者其他容器不需要知道的信息。
在上图中,有一个名为custom-net
的自定义网络。 网络上运行着两种服务:myservice和myclient。 myservice有两个与之关联的任务,而客户端只有一个。
客户端myclient
执行对myservice的curl请求,其实,它也是在对DNS进行请求。 容器内置的解析器将查询转发到Docker引擎的DNS服务器。 然后,对myservice的请求将解析为10.0.0.2虚拟IP,转发回客户端,客户端就可以通过虚拟ip去访问容器。
创建服务后,Docker将自动启用负载均衡功能。 因此,在创建服务后,它会立即在服务的网络上获得虚拟IP地址。 就像上文在服务发现部分中所说的那样,当请求服务时,所得到的DNS查询将转发到Docker引擎,该引擎进而返回服务的IP,即虚拟IP。 发送到该虚拟IP的流量将负载均衡到网络上该服务的所有正常运行的容器。 所有负载均衡均由Docker完成,因为只有一个入口点被分配给客户端(一个IP)。
默认情况下,Docker不会激活负载均衡,只有当在创建或更新时使用–publish
标志公开服务时,集群中的每个节点才会开始侦听已发布的端口,这意味着每个节点都可以响应对映射到该端口的服务的请求。
当某个节点接收到一个请求,但该节点没有真实运行的容器实例时,会发生什么?
从Docker 1.12(将Swarm模式集成到Docker Engine的同一版本)开始,就有Routing Mesh
的功能,该功能使用IP虚拟服务器(ipvs)和iptables来负载均衡第4层中的请求。基本上,ipvs实现了第4层 Linux内核上的负载均衡功能,该功能允许将对基于TCP / UDP
的服务的请求重定向到实际的后端(在这种情况下为容器)。 在Swarm的特定情况下,每个节点都侦听暴露的端口,然后使用称为ingress
的特殊Overlay
网络将请求转发到暴露的服务的VIP(虚拟IP)。 仅当将外部流量传输到请求的服务时,才使用此Overlay
网络。 在这种情况,docker会使用与上文描述的相同的内部负载均衡策略。
在上图中,在appnet Overlay
网络上创建了具有两个副本的服务。 我们可以看到该服务在三个节点上的8000
端口上公开,此时,发往应用程序的流量可以转发到任何节点。 假设在这种情况下,有一个外部负载均衡器,它恰好将请求转发到唯一没有该服务实例的节点, 该请求由IPVS在第三个节点上处理和转发,该IPVS使用ingress
网络并因此使用上述负载均衡方法将其重定向到该服务的集群上的其中一个真实运行的容器。
上图来自官方,很清晰展示了在swarm模式,manage节点和worker节点是怎么协作的,这里就不做细说了。
credit-facility-net
credit-facility-volume
,用于持久化Mysql容器数据因为我机器资源不够,我这里只是创建了三台虚拟机,manager节点也是可以部署服务的
这里用到Vagrant
来管理虚拟机,如果不知道Vagrant是什么,请回顾第一章内容。
Vagrant指令可以查看Vagrant详细指令文档
1.在我们的主机(你自己的电脑)创建一个文件夹swarm-centos7
,然后在目录下创建一个Vagrantfile
文件
Vagrant
这里指定了三台虚拟机的配置,并且分别分配了一个静态ip 192.168.101.11
、192.168.101.12
和192.168.101.13
,并且循环创建3台虚拟机。这里指定了docker swarm
最低要求配置1个CPU、1G内存。
2.启动三台虚拟机,记得在启动过程选择你可用的网卡
当该命令执行完毕,会有三台虚拟机成功被初始化
因为后面需要用到ssh客户端工具,所以这里要把密码开放
修改 manager 节点访问密码,用于后面上传文件使用,这里的密码是evan123
这里只演示了manager节点,另外两个worker节点也需要做同样的操作
需要在每个节点安装Docker,请使用SSH客户端工具,分别登陆3个虚拟机,先按以下步骤安装docker
1.卸载之前的docker配置,如有
2.安装服务器必要的依赖
3.配置加速器,因为国内下载docker需要越过长城,会比较慢,这里我用到的是我自己的阿里云加速器,如果不知道怎么配置的,请查看第一章
4.设置Docker仓库
5.安装Docker
6.安装完毕后,分别进入manger节点和2个worker节点,启动docker服务
7.验证docker,输入docker info
,验证下docker是否已经安装成功
这里需要先进入manager节点192.168.101.11
进行swarm初始化操作,
这里会生成一串token,随后需要在worker节点使用该命令去加入到swarm集群中
这里我们需要分别进去两个worker节点192.168.101.12
和 192.168.101.13
执行以下操作
这里表示当前节点加入swarm集群
只能在swarm manager节点查看当前所有节点信息
这里可以看到,我们的3个节点都已经成功加入到swarm集群,manager-node是我们的swarm集群 leader
跟前一章一样,在集群三个节点的/usr/local
下,分别建一个credit-facitliy
目录
配置文件我已经在项目里提前修改好了,大家直接用即可
/usr/local/credit-facility
目录下,创建Dockerfile
/usr/local/credit-facility
目录下,执行以下命令创建额度服务镜像,这里只演示manager
节点,其他节点操作一样
创建完查看下每个节点现有的镜像列表:
从上面查询结果可以看到,我们的额度服务镜像已经成功创建
因为我们后面用到Nginx
服务,所以我们需要提前把配置创建后,然后通过--mount
方式把配置文件覆盖Nginx
容器内的默认配置
在/usr/local/credit-facility
文件夹下,创建一个nginx
目录,并在nginx
目录下建一个nginx.conf
配置文件
我这里利用docker swam
内置DNS原理,我这里配置域名是额度服务名称credit-facility-service
,docker swarm
会自动帮我们路由到对应的服务节点上
/usr/local/credit-facility
文件夹下,创建一个docker-stack.yml
用于创建和管理服务(注意,这里只需要manager节点创建即可,manager节点会把docker service
发布到到其他节点)
docker stack
去发布服务,可以将服务发布到集群各个节点上(docker compose
是用于单机部署,多机部署需要用到docker swarm stack
)
从上面结果可以看到,我们发布的各个服务已经成功启动,额度服务的3个实例也成功发布到3个节点中
上面结果可以清晰看到,每一个实例被发布到哪个节点中
跟前面章节一样,因为额度服务对数据库有依赖,所以这里需要初始化额度服务用到的表,使用Mysql客户端,连接到数据库,把项目里resources/db
的表创建语句放入执行,我这里用Navicat去连接,数据库连接是192.168.101.11:3306
到这里,所有的配置已经完成了,我们来一起核对下现有的文件有哪些,看看大家有没有遗漏的配置
在manager节点的credit-facility
文件夹下,应该有以下文件
在2个worker节点的credit-facility
文件夹下,应该有以下文件
worker-01节点
worker-02节点
192.168.101.11http://192.168.101.11/swagger-ui.html
可以访问到我们的额度服务ip+8080
访问我们的服务因为我们额度服务有用到数据库,这里我们实验下调用额度服务的接口,看是否可以成功入库
请求参数如下:
执行额度注册接口
执行结果:
从上面执行结果可以看到,我们的接口已经成功处理我们的请求,并且入库成功,有兴趣的同学可以到数据库去查看相应记录
docker-stack.yml
创建服务
__EOF__
原文:https://www.cnblogs.com/lonelyxmas/p/12514983.html