内容简介:这次一起了解下docker Swarm,什么是dockerSwarm。下面这个图,就可以看到docker swarm管理docker的一个架构图。以前使用docker命令行是针对docker主机的,然后到这台机器上单独的控制这台机器上的主机,有了swarm之后,客户端命令是针对docker集群的。它的命令几乎等同于docker的原生命令,它把命令发送给swarm,swarm选择发送一个节点去真正的执行,swarm是通过docker自带的远程的API,来实现对docker的控制。
这次一起了解下docker Swarm,什么是dockerSwarm。
什么是docker Swarm
- 产品背景
使用 docker 的流程,ssh到一台服务器,运行docker命令来运行本机的docker服务,随着docker发展,越来越多的服务想要运行在docker容器中,如果在这样挨个的登录在每个ssh主机上管理容器,就非常的吃力了,而且我们的应用也需要高可用,也需要避免单点的故障,docker现有的能力已经很难满足这样的需求了,在这样的背景下,docker社区就产生类的dockerSwarm项目。
- 概念
什么是swarm,swarm这个名词比较贴切,swarm这个单词的意思就是动物的集群行为,比如我们常见的蜂群,鱼群,大雁南飞都可以成为swarm,swarm项目就是把多个docker 实例聚集在一起形成一个大的docker实例,对外提供集群服务,同时这个集群提供所有的api,用户可以相使用docker实例一样使用docker的集群。
-
昨日今日
>docker swarm在1.12之前是一个独立的项目,需要单独下载,在1.12之后该项目就合并到了docker中,成为docker的子项目,目前docker唯一的一个原生支持docker集群的管理工具。
docker swarm的架构图
下面这个图,就可以看到docker swarm管理docker的一个架构图。以前使用docker命令行是针对docker主机的,然后到这台机器上单独的控制这台机器上的主机,有了swarm之后,客户端命令是针对docker集群的。它的命令几乎等同于docker的原生命令,它把命令发送给swarm,swarm选择发送一个节点去真正的执行,swarm是通过docker自带的远程的API,来实现对docker的控制。
下面这个图,这张图跟上面一张图描述的是一个事情,只不过它暴露了更多的的细节,上面的大框和下面的小框都代表了一台服务器,物理机或者虚拟机,我们从上面说,上面是swarm的一个manager节点,管理这个worker节点,可以看到管理了多少个cpu,多少个内存,每个上面运行的服务,每个服务的状况,比如他们的标签,他们的健康状态,Manager管理者每个节点的生命周期,比如加入一个节点,下线一个节点,manager还管理者每个服务的生命周期,服务的部署,更新,停止,删除,Node节点比较单纯他就运行了docker daemon,因为在1.12之后swarm已经融入了docker本身,开发一个远程的api给manager节点调度,运行具体的服务和容器,下面咱们一起看看服务的部署流程是怎样的,在这样的架构上是如何体现的。
环境的搭建
想想之前学习的mesos,需要先安装docker,Marathon,zookeeper,加入我们现在有5台liunx服务器,每个上面都装有docker,选择一台作为manager,上面执行下图的第一条命令, 执行完之后会打印出来一个token作为dockerSwarm的凭证,然后在每个worker节点下执行第二条命令,表示要加入集群,只需要token和对应manager节点的ip和端口号,集群环境就搭建完毕了
如何部署
客户端的发起docker命令,两种方式
- 直接ssh到manager节点,执行docker命令。
- 通过远程访问的方式,通过Remote API调用manager上的docker命令,我们这张图画的就是第二种方式。
docker Client 在manager节点的外边,假如执行了docker service create,先会经过docker Deamon接受这条命令,传给Scheduler模块,Scheduler模块主要实现调度的功能,负责选择出来最优的节点,里面包含了2个子模块,Fiter 和Strategy,Fiter很明显是过滤节点,用来找出满足条件的节点(资源足够多,节点正常的),Strategy是过滤出来后选择出最优的节点(对比选择资源剩余最多的节点,或者找到资源剩余最少的节点),当然Fiter 和Strategy都是用户可以单独定制的,中间的Cluster是抽象的worker节点集群,包含了Swarm节点里面每个节点的信息,右边的Discovery是信息维护的模块,比如Label Health。Cluster最终调用容器的api,完成容器启动的刘而成。
调度模块
用户在创建服务的时候,选择最优的节点,选择最优节点的管理分为2个阶段。
过滤和策略
filter
- Constraints
约束过滤器,根据当前的操作系统的类型,内核版本,存储的类型进行指标上的约束,也可以自定义约束。当前系统启动的时候可以通过label指定当前机器所具有的特性然后通过Constraints把他们过滤出来。
- Affinity
亲和性过滤器,支持容器的亲和性和镜像的亲和性,比如一个应用,DB容器和web容器放在一起,就可以通过这个来实现,
- Dependency
依赖过滤器,link等等吧Dependency会将这些容器放在同一个节点上,有依赖管理的会将创建的容器和依赖的容器放在同一个节点上。
- Health filter
健康过滤器,根据节点的健康状态进行过滤,把有问题的节点去掉。
- Ports filter
端口过滤器,根据端口的使用情况进行过滤,比如一个8080端口在某个主机上被占用,某些主机未被占用,会选用未被占用的那些主机。
Strategy
- Binpack
在同等情况下,会使用资源最多的节点,通过这个策略可以让容器聚集起来。
- Spread
在同等情况下,会使用资源最少的节点,通过这个策略可以让容器均匀的分布在每个节点上。
- Random
随机选择一个节点。
服务发现
稍微有点复杂,根据场景来说吧
-
Ingress
>基于物理网络之上的虚拟网络,Swarm的上层应用不在依赖于物理网络,并且能够让下面的物理网络保持不变,老铁就理解到这里就可以了,网络本身涉及到的东西太多了,应该也听过网络工程师,既然有这个职位肯定这个不是那么容易学的,在这里就不会深入的进行详解了。
PS:假定运行了一个nginx服务2个实例,nginx1 和nginx2,容器内的端口是80,主机内的端口是8080, 这2个容器分别运行在node2和node3上,看到了吧node1虽然没有运行实例但是依然有8080端口在监听,一个集群在所有的worker节点上都是可以访问到的,随便选一个节点输入它的ip和8080端口就可以访问到,或者搭建一个负载均衡External LB,负责轮询的方式访问每个上边的8080端口,为什么在每个节点上都可以访问我们的服务呢?每个服务启动后所有的节点都会更新自己的VIP LB,把新的服务端口号和服务的信息建立一个关系,VIP LB是基于虚拟IP的负载均衡,VIP LB可以通过虚拟IP解析到真实IP,然后访问到服务。
-
Ingress+ link
>就类型docker-compose,可以通过docker-compose.yml文件创建出来一组容器,他们之前通过link的方式进行访问,其实这种就类型docker-compose的link网络。
PS:也就是在Ingress之上多了一个link的场景,可以通过link的方式访问,也不需要主机的网络,link怎么实现的呢,如果让一个容器link到另一个容器很容易毕竟他们在一台主机上,一个服务link到另一个服务其实没有那么简单了,可能包含一个容器,也可能包含很多个容器,可能运行在一台机器上,也可能分布在多台机器上,我们如何实现可以通过名字来访问彼此呢,这用到了容器的dns,这里的nginx服务依赖于tomcat服务,nginx有2个实例,tomcat有一个实例,所有的nginx的容器都会对tomcat的解析,把它解析到tomcat的VIP,VIP负责做负载均衡,原理就是这样的原理,link的方式外部是访问不到的。link只适合swarm集群内部的场景。
-
自定义网络
>使用自定义的网络,首先要创建网络,所有的网络都可以通过名字来连接彼此,而不需要link操作了。只要连接这个网络的彼此,都可以通过名字。底层来说它和link是类型的。通过dns来解析应用的名字。然后通过VIP LB的形式来进行负载均衡。
#创建自定义网络 docker network create --driver=overlay --attachable mynet
#创建服务 docker service create -p 80:80 --network=mynet --name nginx nginx
Ingress 支持外部访问,Ingress+ link和自定义网络只能容器间进行访问。
服务编排
- 服务部署&服务发现(上边说到了)
- 服务更新 — docker service update
- 服务扩缩容 — docker service scale
Swarm
- 对外以Docker API 接口呈现
好处直接可以平滑的切换到docker swarm上。基本不需要改变现有的系统
- 容易上手,学习成本低
之前docker的经验可以完成继承过来。
- 轻量级,节省资源
专注docker集群的管理。插件的机制swarm的模块都抽象出来对应的API,可以根据自己的特点进行定制实现。
- 对docker命令参数支持完善
跟docker同步发布,docker的新的特性在dockerSwarm上都可以得到体现。
PS:docker Swarm基本都了解的差不多了。下次开始docker swarm的环境搭建。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:已是最新文章
以上所述就是小编给大家介绍的《『高级篇』docker之DockerSwarm的了解(27)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 你了解HTTPS,但你可能不了解X.509
- 你真的了解Mybatis的${}和#{}吗?是否了解应用场景?
- 你所了解的 array_diff_uassoc 真的是你了解的那样吗?
- 图文了解 Kubernetes
- 深入了解 JSONP
- 一文了解 Kubernetes
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
JavaScript设计模式与开发实践
曾探 / 人民邮电出版社 / 2015-5 / 59.00元
本书在尊重《设计模式》原意的同时,针对JavaScript语言特性全面介绍了更适合JavaScript程序员的了16个常用的设计模式,讲解了JavaScript面向对象和函数式编程方面的基础知识,介绍了面向对象的设计原则及其在设计模式中的体现,还分享了面向对象编程技巧和日常开发中的代码重构。本书将教会你如何把经典的设计模式应用到JavaScript语言中,编写出优美高效、结构化和可维护的代码。一起来看看 《JavaScript设计模式与开发实践》 这本书的介绍吧!