『中级篇』容器编排Docker Swarm介绍(42)

314 阅读3分钟

原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
原文链接地址:『中级篇』容器编排Docker Swarm介绍(42)

到今天这次总结,如果跟着我一起学一起练的老铁,完全入门docker了。在日常的开发和测试,绝对是没有问题的。不管是我们自己和docker公司,他们的初心都是想用在生产环境下,但是生产环境和测试环境完全是两种环境条件。

之前的学习实践环境

在用学习容器编排之前,所有操作本地进行的,docker cli 连接是一台的docker host,不管是docker run 还是docker container 都是在一台机器上,但是实际的生产环境下,一个应用很复杂他部署在一台机器上满足不了我们的需求,都是通过集群的方式来解决问题的。


到处都使用容器带来的困扰
  1. 怎么去管理这么多容器?
  2. 怎么能方便的横向扩展?
  3. 如果容器down了,怎么能自动恢复?
  4. 如何去更新融起而不影响业务?
  5. 怎么去调度容器的创建?
  6. 保护隐私数据?


Swarm的架构
  1. swarm集群的架构
  2. 节点下面有角色:Worker Manager
  3. Manager 是整个warm集群的大脑,为了避免单点的故障,我们的大脑至少有2个,状态的同步通过raft协议进行同步。raft协议可以确保多个Manager之前是同步的。

分布式系统之于单机系统,优势之一就是有更好的容错性

  • 比如,一台机器上的磁盘损坏,数据丢失,可以从另一台机器上的磁盘>恢复(分布式系统会对数据做备份)
  • 比如,集群中某些机器宕机,整个集群还可以对外提供服务
    这是如何做到的?比较容易的一个想法就是备份(backup)。一个系统的工作模是:接受客户端的command,系统进行处理,将处理的结果返回给客户端。由此可见,系统里的数据可能会因为command而变化。
    实现备份的做法之一就是复制状态机(Repilcated State Machine,RSM),它有一个很重要的性质——确定性(deterministic)
  • 如果两个相同的、确定性的状态从同一状态开始,并且以相同的顺序获得相同的输入,那么这两个状态机将会生成相同的输出,并且结束在相同的状态
    也就是说,如果我们能按顺序将command作用于状态机,它就可以产生相同的状态和相同的输出
    那么一个状态机如何实现呢?如下图所示(来自raft协议):
image
image

上图中,每个RSM都有一个replicated log,存储的是来自客户端的commands。每个RSM中replicate log中commads的顺序都是相同的,状态机按顺序处理replicate log中的command,并将处理的结果返回给客户端。由于状态机具有确定性,因此每个状态机的输出和状态都是相同的。
上图中有一个模块——Consensus Module刚刚没有提及。这个模块用于保证每个server上Log的一致性

  • 如果不做任何保障,直接将commad暴力写入,一旦服务器宕机或者出现什么其他故障,就会导致这个Log丢失,并且无法恢复。而出现故障的可能性是很高的,这就导致系统不可用
  • raft就是Consensus Module的一个实现
    因此,raft是一致性协议,是用来保障servers上副本一致性的一种算法。
  1. worker是通过gossip的网络结构进行同步
  2. Service 和Replicas,这里的Service在docker compose中的Service是一样的。



命令合集

个人主页:IT人故事会

PS:之后通过很多很多的实践操作一起来学习Swarm。

image