【践行DevOps理念】Swarm初体验

学习本章必备前置知识：linux基本操作 docker网络 docker基本操作

简介

容器编排Swarm介绍

学习容器编排Swarm之前的docker单机架构:

Docker Swarm不是唯一的容器编排工具，它是docker内置的一个编排容器的工具，无需额外安装，和 Docker Compose 一样，都是 Docker 官方容器编排项目，但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。

Docker swarm的底层基础架构

Docker swarm负载均衡调度

实践阶段

测试环境

node1服务器: manager节点 192.168.0.18, 选择此节点作为swarm的manager节点。
node2服务器：worker节点 192.168.0.17
node3服务器：worker节点 192.168.0.16

创建一个三节点的swarm集群

初始化一个manager节点 docker swarm init --advertise-addr=192.168.205.10

复制token到所有worker节点用于连接manager节点

Service的创建维护和水平扩展

swarm中不再用run生成容器，而是用service create生成service
docker service create --name demo busybox sh -c “while true;do sleep 3600;done”

manager节点查看service：docker service ps [name]

服务名和容器名需要区分开,docker ps看到的是容器名，docker service ls看到的是service名。

manager节点中对指定的service进行横向拓展，横向拓展过程中docker schedule会根据负载均衡调度算法将任务分配给不同的节点。

service的容灾能力，某一节点的service服务被删除或被停止或宕机之后自动重启一个新的服务，并调度到某一个节点上。
在node2和node3这两个工作节点中强制停止或删除被分配的服务：


再回到manager节点可以看到哪些服务停止服务，以及重新启动了哪些服务，始终都保持着5个服务的运行状态

删除服务，分布在各个节点上的相关服务也随之删除

在swarm集群里通过serivce部署wordpress

我们要创建一个WordPress的容器和一个mysql的容器，这两个容器极有可能不会出现在同一台机器上，那么我们要怎样让他们互相之间可以通信呢？
我们可以创建一个overlay的网络，然后让两个容器连接到这个网络，这样子，即使两个容器在不同的机器上也是可以通信的。

创建mysql服务：
docker service create --name mysql --env MYSQL_ROOT_PASSWORD=root --env MYSQL_DATABASE=wordpress --network demo --mount type=volume,source=mysql-data,destination=/var/lib/mysql mysql
参数解读：
–name 指定service名称
–env 设置容器中的环境变量
–network 指定网络
–mount type=volume 类似docker的-v
source 指本地数据持久化挂载目录
destination 指容器中的挂载目录

运行在了manager节点上

创建WordPress容器
docker service create --name wordpress -p 80:80 --env WORDPRESS_DB_PASSWORD=root --env WORDPRESS_DB_HOST=mysql --network demo wordpress
参数解读：
WORDPRESS_DB_HOST这个环境变量对应的mysql是服务名,指定要连接的服务的ip
–network 指定网络

可以看到WordPress服务被调度到了名为node2的工作节点上。

同时根据前面在manager节点所执行的命令中的–network参数在此节点上自动创建了名为demo的overlay网络。

访问node2工作节点的WordPress网站成功，可以看的出mysql和wordpress两个service之间是可以相互访问的。

同时发生了一件神奇的事情：“”虽然wordpress容器被分配在名为node2的工作节点上，但是我们访问其它节点ip地址的80端口也可以访问到WordPress“”（这个问题我们在RoutingMesh之Ingress负载均衡小节讲解）

集群服务间通信之RoutingMesh

docker服务之间通过服务名进行通讯的底层原理是通过DNS服务实现的，swarm内置有DNS服务发现的功能，每一个服务都有一个虚拟ip地址，与每一个服务的replicas的真实ip地址形成map映射，当其它服务访问的时候访问的永远是此服务的vip（虚拟ip）

实例：
node1服务器: manager节点 192.168.0.8, 选择此节点作为swarm的manager节点。
node2服务器：worker节点 192.168.0.7
node3服务器：worker节点 192.168.0.6

初始化一个manager节点并将其它节点作为worker节点并创建一个跨机器通信的overlay网络
docker swarm init --advertise-addr=192.168.0.8
docker network create -d overlay chenchong



运行一个名为whoami的web服务用于获取当前容器id，并后台运行，可以看到其运行在名为node2的worker节点
docker service create --name whoami -p 8000:8000 --network chenchong -d jwilder/whoami

在worker节点查看容器id

访问这个service的web服务，可以看到已经获取到了worker节点查看到的容器id(注意这里，可以通过任何节点来访问服务)

再创建一个service并连接到上面创建的名为chenchong的overlay网络
docker service create --name client -d --network chenchong busybox sh -c “while true; do sleep 3600; done”
可以看到其运行在了名为node1的manager节点

进入名为client的这个容器ping一下whoami服务可以看到这个服务的vip为10.0.1.2

接下来我们对whoami服务进行横向拓展
docker service scale whoami=2
这个服务分别分配到了node2和node3

进入node2和node3的whoami服务的容器中查看其ip分别是10.0.1.3和10.0.1.8


进入名为client的这个容器ping一下whoami服务可以看到这个服务的vip依然为10.0.1.2，实际上ping的过程中是对service的不同容器进行负载均衡的访问，在这个访问过程中其实已经访问了whoami服务的所有容器地址，因为容器的ip的增多和减少或者从一台机器迁移到另一台机器上都会导致容器ip的变动，但是我们这个服务ip永远不会变，然后我们的服务ip会和其对应的容器ip有一个map关系，我们可以通过服务ip来找到其对应的容器ip的具体地址

实践出真知，我们再次来论证一下访问whoami服务的时候是否对该service的不同容器进行了负载均衡的轮询访问，由以下实验可以得出前面的论述是正确的。

这张图讲的是我们在client访问dns也就是服务名，它会把dns解析到具体的服务ip(虚拟ip)并通过iptables和lvs（Linux虚拟服务器）来做负载均衡（把这个访问负载均衡到不同的节点上）

小节总结：该小节讲的主要是Routing Mesh, 这是我们在docker swarm里的一个技术，Routing Mesh主要有两种体现，该小节主要讲的是Routing Mesh的Internal这个网络，讲的主要是我们同一个连接到overlay网络里面的容器是如何进行通讯的，首先是通过服务名（service name）,这个服务名对应的ip地址并不是容器的具体ip地址，而是vip,一个虚拟的ip，当容器进行了横向拓展，我们通过vip去访问的时候，它会帮我们做容器的负载均衡

RoutingMesh之Ingress负载均衡

实例：
node1服务器: manager节点 192.168.0.6, 选择此节点作为swarm的manager节点。
node2服务器：worker节点 192.168.0.7
node3服务器：worker节点 192.168.0.8
运行两个wordpress服务和一个mysql服务
SwarmSchedule给node1服务器中调度了一个mysql容器
SwarmSchedule给node2服务器中调度了一个wordpress服务器
SwarmSchedule给node3服务器中调度了一个wordpress服务器
我们在node1服务器中访问wordpress服务成功
问：为什么可以在一个没有wordpress容器的节点上通过本地ip访问wordpress？

让我们查看一下iptables中的nat（网络地址转换）表


在nat表中我们发现本机访问80端口会自动转交数据包到172.19.0.2:80这个地址，接下来我们看一下本地网络，发现了docker_gwbridge这个网络命名空间与nat表中的转换地址处于同一网段下

执行docker network insprect docker_gwbridge来查看该命名空间，发现了ingress-sbox（docker网络的netns 网络的命名空间文件在/var/run/docker/netns目录中,这是/var/run/docker/netns目录下的一个网络命名空间名,我们在本地访问80端口所发送的数据包都转给了ingress-sbox）

进入ingress-sbox网络命名空间查看该其真实ip
nsenter --net=/var/run/docker/netns/ingress_sbox

如果执行iptables -nL -t mangle可以看到ingress-sbox通过LVS把通往80端口的数据包做load balancing ,把数据包通过overlay跨机器转到了某一个service容器具体的ip地址

拓展：ipvsadm是一个LVS管理工具，安装ipvsadm并执行ipvsadm -l后可以看到负载均衡的具体地址