使用 Docker Swarm 对 Docker 进行规模扩展

jopen 10年前

我们很高兴地宣布第一个Swarm的Beta版已经发布, 它是一个Docker的本地集群工具.

过去的两年里, Docker让数以百万计的开发人员的生活变得简单,通过容器来使构建, 传输和运行应用变得简单. 但是, 当处理在一个分布式环境下超过一个主机的Docker容器时,事情就变得复杂起来. 

这就是Swarm应用的地方. Swarm将几个Docker引擎集合起来作为一个单独的虚拟Docker引擎暴露给外界. 它提供标准的Docker API, 所以任何已经在Docker工作的工具现在都可以透明地扩展到多个主机.

回到十二月份, 为了解决在分布式环境下工作的问题, 我们发布了一个Swarm的技术预览版, 它基于这几个核心原则:

  • 极其容易入门

  • 相同的Docker API

  • “可插拔式的架构” 实现发现和调度

从那时起, 随着社区帮助, 我们努力工作来让Swarm成为现实, 今天我们自豪地放出了这个项目的一个Beta版.

特性

简单设置

因为 Swarm 是一个标准的 Docker image 并且不依赖于外部的架构,启动它是简单的三个步骤:

  1. 运行一个命令去创建一个集群.
    2. 运行另一个命令去启动Swarm.
    3. 在运行有Docker Engine的每个主机上,运行一个命令与上面的集群相连

关于设置的过程请参考 documentation.

Docker API兼容性

大部分 Docker API 端都可以在Swarm上找到,这意味着基于Swarm上构建的工具都是可以使用的这些API,包括Docker CLI.

这就为Docker用户确保了一致性:无论你是在你的笔记本上开发,在准生产环境上测试或者部署在有几百台主机的生产环境,使用感受都是一样的因为你将使用和你已经熟悉的相同的工具。
比如,通过将Docker CLI指向Swarm,运行一个交互式的shell就如下这样简单:

docker run -H swarm_ip:swarm_port -it ubuntu bash

命令行的后面,Swarm将会在其中的一个主机上创建一个container,并且将标准的输入/输出代理会CLI

资源管理

Swarm认为在集群上资源是可用的,并将放置相应的容器。

标准的布局策略(placement strategy)考虑资源容器的需求,并且利用可用的主机资源组成的集群去优化布局,并使用了一个容器包装算法。

举例来说,下面的命令将会调度一个Redis容器在任何有足够资源的机器上操作1G存储。

docker run -d -m 1g redis


约束

为了让每个容器符合这种特殊的需求,他们的布局可以用约束(constraints)来调整。举例来说,Swarm可以被通知在一个主机上用flash存储运行MySQL:

docker run -d -e constraint:storage==ssd mysql

约束操作在Docker守护进程上标注。拿上一个例子来说,Docker必须以这样的选项开始–label storage=ssd

还有更多高级的表达式被支持:

docker run --rm -d -e constraint:node!=fed*  docker run --rm -d -e constraint:node==/ubuntu-[0-9]+/

相关性

在某些情况下,一个容器的放置必须要相对于其他容器. Swarm可以通过affinities让你定义这些关系.

下面的代码将会运行两个Redis服务器, 保证它们不是在同一个机器上被调度: 

docker run -d --name redis_1 -e ‘affinity:container!=redis_*’ redisdocker run -d --name redis_2 -e ‘affinity:container!=redis_*’ redis

当容器之间的关系是隐含的时候Affinities就被自动生成. 使用如 –link, –volumes-from–net=container: 等选项的容器被联合调度在同一个主机上.

TLS

TLS 验证可以确保与Swarm之间的通信的安全性.

未来


容错调度

在某些点, Swarm将可以在主机故障时重调度容器.

看看这个对带有一些限制条件的前端容器的调度: 

docker run -d -e constraint:storage==ssd nginx

如果这个容器的主机发生宕机, Swarm 将可以检测中断和在其他主机重新调度这个容器并遵守这个限制条件storage==ssd

高可用性调度器

现在,Swarm运行在单一主机模式。在未来Swarm将会支持主机选举。这意味着如果一个Swarm主机宕机,另一个主机将会被选举,集群上的容器调度将不会中断。

内置电池但可更换

从这个项目开始那天,可更换就作为默认的内置功能被提供。

调度器

我们兴奋地宣布:调度器驱动API已经被详细说明而且将要实施。这个API将会允许Swarm与其它集群解决方案(例如Mesos和Kubernetes)相集成。

合作伙伴

Swarm可以很好地与第三方容器编配产品和运供应商提供的编配服务整合,我们与Mesosphere合作开发一个用于Mesos和Mesosphere DCOS的调度驱动,它将作为调度驱动API的一个参考实例这个整合方案允许Swarm在成百上千台机器上批量编配和调度容器。这个整合方案同样计划用于Amazon EC2容器服务(ECS), Google Kubernetes, IBM Bluemix容器服务, Joyent智能数据中心和Microsoft Azure。


发现

为了发现主机是一个集群的一部分,Swarm依赖于一项发现服务.

默认情况下,它将会使用Docker Hub来执行发现。因为这是无需依赖外部设备的最简单的方法。

但是,通过Swarm发现API,也可以使用其它服务。目前,支持的其它发现服务包括:Zookeeper,Consul和etcd。

编配

Swarm是Docker编配工具的一部分,与Machine和Compose并列。这三种工具可以单独使用,但同样设计用于协同工作。

想了解使用它们协同工作,可以阅读这篇博文:用Machine,Swarm和Compose编配Docker.

感谢

我们想要感谢所有通过提交贡献来使这个版本发布的社区成员,他们是:

Chanwit Kaewkasi, Jeff Chien, Pierre Wacrenier, Shijiang Wei, Jessica B. Hamrick, Rob Haswell, zhangbaitong, Ankush Agarwal, Derek Schultz, Gp De Ciantis, Keegan Lowenstein, Luke Marsden, Matt Drollette, Matthew Fisher, Nick Schuch, Omer Katz, Radek Simko, Ranjandas, Thimo, Thomas Meson.

了解更多关于Swarm的信息

我们希望得到你关于这第一个Beta版的反馈,所以请测试它:

了解更多关于Docker的信息