Swarm是Docker公司在2014年12月初发布的一套较为简单的工具，用来管理Docker集群，它将一群Docker宿主机变成一个单一的，虚拟的主机。Swarm使用标准的Docker API接口作为其前端访问入口，换言之，各种形式的Docker Client(docker client in Go, docker_py, docker等)均可以直接与Swarm通信。Swarm几乎全部用Go语言来完成开发，上周五，4月17号，Swarm0.2发布，相比0.1版本，0.2版本增加了一个新的策略来调度集群中的容器，使得在可用的节点上它们，以及支持更多的Docker命令以及集群驱动。
Swarm deamon只是一个调度器（Scheduler）加由器(router)，Swarm自己不运行容器，它只是接受docker客户端发送过来的请求，调度适合的节点来运行容器，这意味着，即使Swarm由于某些原因挂掉了，集群中的节点也会照常运行，当Swarm重新恢复运行之后，它会收集重建集群信息。下面是Swarm的结构图：
在任何一个节点执行swarm create命令来创建一个集群标志。这条命令执行完毕之后，swarm会前往Docker Hub上内建的发现服务中获取一个全球唯一的token，用以唯一的标识swarm管理的Docker集群。
因为我们要让sclu083充当Swarm管理节点，所以我们要在这台机器执行swarm manage命令
重点内容需要注意的是：在这条命令中，第一：要以daemon的形式运行swarm；第二：端口映射：2376可以更换成任何一个本机没有占用的端口，一定不能是2375，否则就会出问题。
之后可以在任何一台安装了docker的机器通过命令(命令中要指明swarm maneger 机器的IP地址和端口)在这个集群运行Dcoker容器操作。
现在在10.13.181.85这台机器查看集群的节点的信息。info命令可以换成任何一个Swarm支持的docker命令，这些命令可以查看文档
由上图的结果，我们可以发现一个问题：明明这个小集群中是有3个节点的，但是info命令只显示了2个节点。还缺少节点10.32.105.124。为什么会出现这个情况呢？
在使用Docker Hub内置的发现服务时，会出现一个问题，就是使用swarm create时会出现
注意：这里一定要使用-v命令，因为cluster文件是在本机，启动的容器默认是访问不到的，所以要通过-v命令共享。还有，file:///千万不能忘记了。
(在使用文件作为服务发现的时候，貌似manage list命令只能在swarm manage节点上使用，在其他节点上好像是用不了)
好了，现在集群也已经运行起来了，可以跟第一种方法一样在其他机器上使用集群了。同样在sclu085 机器上做测试:
可以看到，成功访问并且节点信息是正确的。接下来可以把的info命令替换成其他docker可执行命令来使用这个晓得Docker集群了。
Swarm在schedule节点运行容器的时候，会根据指定的策略来计算最适合运行容器的节点，目前支持的策略有：spread, binpack, random.
Random顾名思义，就是随机选择一个Node来运行容器，一般用作调试用，spread和binpack策略会根据各个节点的可用的CPU, RAM以及正在运行的容器的数量来计算应该运行容器的节点。
使用Spread策略会使得容器会均衡的分布在集群中的各个节点上运行，一旦一个节点挂掉了只会损失少部分的容器。
Binpack策略最大化的避免容器碎片化，就是说binpack策略尽可能的把还未使用的节点留给需要更大空间的容器运行，尽可能的把容器运行在一个节点。
下面这条命令达到的效果是：在有redis镜像的节点启动一个名字叫做redis的容器，如果每个节点都没有redis容器，就按照默认的策略启动redis容器。
本站（LinuxIDC）所刊载文章不代表同意其说法或描述，仅为提供更多信息，也不构成任何。
推荐：
网友评论 ()条 查看