Docker进阶篇教程 docker swarm弹性、动态扩缩容

承接上文： Docker进阶篇教程，docker-compose, docker swarm, 弹性、扩缩容

9. 体会swarm弹性、扩缩容

以后告别docker run , 容器只是玩具，脱离了编排，它就没有任何意义了！

先准备一下，下面集群跑起来，三主一从：

9.1 理解扩缩容

下面演示swarm动态扩缩容：

上面如果新加一个web应用，按照以前的方式，需要我们在nginx里面手动配置，非常痛苦，而我们使用了swarm之后，这就变成了动态扩缩容，扩展10个web应用，对于nginx，它跟访问一个web应用没有什么区别，也就是它屏蔽了底层的差异，如下图：

9.2 docker service命令

9.3 理解灰度发布

灰度发布即是金丝雀发布，我们要升级我们的项目，有两种方式，
一是停止网站，挂一个404，这种方式非常耗费流量
另一种即是滚动发布，升级不影响网站的使用，平滑升级，docker swarm 和k8s均可实现

咦？我们是在docker-1机器上创建的，但1、2、4上都没有这个docker进程，它却跑到了docker-3里面（docker-3也是manager节点）! 可见它是随机分布的！

9.4    replicas 3个副本测试

下面创建3个副本测试：

下面在docker-1机器上查看：

重点来了： 动态更新nginx成3个副本，1上没有，2、3、4都有nginx。但用1的ip访问却也能访问到nginx！！！如下图：

结论：docker-1我们也通过docker ps 查看了，它里面是没有nginx服务的，但是由于它是在集群里面，所以他依然能访问我们部署的服务，只要在集群里面，无论在哪个ip, 都能正常访问的，这就是集群 —> 整体！

集群即是整体，非常大的一个整体，整体里面有很多机器，机器里面有很多容器服务在跑（假设它们都提供同一个服务），但是对于用户而言，用户访问进来就是一个大的整体，整体里面可以随时动态地扩缩容

9.5 replicas 10个副本测试

分别查看四个机器，发现四个节点上分别跑3、3、2、2个nginx容器。

当然，同样的命令也可以再设置成只有1个副本，下图执行完，之前好多的服务就都停了：


以上就是弹性、扩缩容！

我们要百分百利用服务器资源，比如阿里云10000台服务器，平时用的不多，都卖给别人了，通过虚拟化把资源划分给别人，而到了双十一这一天，这个时候阿里那边就可以把这一万台都动用起来，因为它们是在同一个集群里面的，即实现了动态扩缩容！服务的高可用！服务器的高可用！

9.6 scale命令扩缩容

k8s更难，功能更多。swarm相当于简单版的k8s，我们学完swarm，然后再去学k8s，有很多内容都是相通的，比如：副本、服务器、多容器

10. docker swarm概念总结

• Swarm
  集群的管理和编排，docker可以初始化一个swarm集群，其他节点可以加入，加入的时候有两个角色 --> 管理节点、工作节点

• Node
  就是一个docker节点，我们在linux上安装了一个docker,那么这就是一个节点，多个节点就组成了一个网络集群（管理者、工作者），(集群需要一个管理者，就是上面说的swarm）

• Service
  即任务，可以在管理节点或者工作节点来运行，当然也是整个docker集群的核心，用户访问的就是它！我们操作的也是它！
  service的创建（docker service create）跟我们之前docker run 是一样的

• Task
  容器内的命令，细节、小任务
  因为我们在真正创建容器的时候，它是一层一层的，并不是一下子就创建完成的，下图演示一下：

图解：
上图的右边是我们通过docker-compose构建的服务，depoly部署了4个副本，然后图左边即是生成了4个任务，虽然说整个它是一个大的服务，但是它里面有4个副本，每个副本跑在哪个镜像上，跑在哪个服务器上，都不是我们要关心的，因为这是docker-swarm集群节点帮我们随机分配，随机做的，
所以要理解我们部署的每一个副本就是一个个小的task任务而已，想扩展多少个都是随机的

• 工作模式 图解

上图图解：
一个service可以创建多个副本，每一个副本其实就是一个task任务，任务里面跑着咱们最终运行着的容器

• docker swarm集群 内部原理 图解
  
  上图图解：

1. docker收到docker service create命令
2. 这个命令通过API进入scheduler调度，这个调度它自己有内部的算法，它根据咱们的集群节点是否可到达、压力来确定应该分配到哪里，以我们在集群里面跑了10个nginx举例，它并没有把这10个都跑在一个容器里面，而是类似平均分配这样，这就是scheduler调度在起作用
3. 被分配的节点把服务运行起来

大概流程：

docker service命令 --> 管理节点 --> API --> 调度 --> 工作节点（创建task容器,自动创建和维护）

同理，k8s里面逻辑也是如此, 比如:

kubectl get pod
kubectl service api

• 服务副本与全局服务

我们刚才说到所有东西都是随机分配的，而且管理节点和工作节点都可以跑项目， 我们的项目可以分为一个是可以在全局跑的service, 还有一个是只能在副本上跑的项目，比如当我们不想在工作节点跑项目的时候，我们可以只让它以副本的方式启动，全局的服务可以在任何节点上跑，工作节点上的服务只让它在工作节点上面跑，这样该怎么实现呢？实现方式如下：

• docker swarm网络
  docker swarm网络与我们之前学习的网络还是有很大差异的，
  先启动一个服务：
  
  扩展成5份， 然后查看网络：
  
  
• Overlay网络
  集群里面的多个服务，即使是跨机器，我们也可以把它加进来，如下图：
  

无论容器（服务）在哪个机器，我们只需将容器加到这个Overlay网络里面，它会自动在多个电脑上面去找

• Ingress网络
  特殊的Overlay网络，具有负载均衡的功能， IPV5 , VIP

可见, ingress网络绑定了四个ip（同一个网络下的）,如下图：

• 为啥引入Overlay技术？
  
  由于我们搭建将以上四台服务器搭建成了集群，如果上面四个容器还只是单独的服务的话，他们之间的网络是ping不通的，所以引入了Overlay这个技术，新加了一层网络叫Overlay网络，我们把所有节点加入到Overlay网络里面之后， 让他们之间能够互相ping通，集群或者说网络就变成了一个整体了！

11. docker其他命令学习方式

11.1 Docker Stack

11.2 Docker Secret

k8s中也有这个概念，学k8s的时候再说

11.3 Docker Config

12. 拓展到K8S

超过10台用k8s不用swarm