前两篇东西，我们分别介绍了Mesos和Dockers的安装和使用。在《Mesos实战》这篇的结尾，我说过将会介绍如何在Mesos集群之上跑几个任务。这趟就着重说说如何在Mesos中通过Docker跑几个Container。
说到Docker的Container，个人理解其实就是将软件和系统环境一并打包发布的机制，这样做的原因是通过一个统一的封装，加快开发，测试，运维的流程，减少了重复配置环境的过程。如果说对于实验室环境来说，Docker的命令行界面其实已经很方便了，但如果作为生产环境中部署docker来说有几个明显的软肋：
缺乏故障监控，资源调度，故障自动转移的平台。
没有一个相对友好的用户界面和相对完整的API。
网络管理不完善。
而这些缺点就是我们将docker迁入Mesos集群中的原因所在。
安装Mesos
这一部分的内容，包括环境介绍请参见《Mesos实战》，这里不再赘述。
不过要说明一下，之后的zk和marathon的安装从道理上应该是在独立的一套主机上，但我这里考虑到仅仅只是实验环境，而且mesos的master节点非常空闲，于是便把之后的安装集中在了master，下文中除了特指的主机之外，全部在master节点上操作。
安装 Zookeeper
上文中对于Mesos的管理，其实我们并没有用到zoopkeeper，不过这次要补上Zookeeper的安装了。
真心不复杂，属于下载来就能用的那种。唯一的依赖包是JAVA环境，不过如果你的Mesos装好了，自然也有了JAVA环境。
$ tar vzxf zookeeper-xxx.tar.gz$ mv zookeeper-xxx /usr/local/zookeeper$ cd /usr/local/zookeeper$ bin/zkServer.sh
正常情况下应该不会有报错，系统会监听2181端口。
安装 Marathon
Marathon即马拉松，从字面上就看得出，这是一个保持系统长时间运行的服务。安装也不是很复杂。
$ wget http://downloads.mesosphere.com/marathon/v0.10.0/marathon-0.10.0.tgz$ tar vzxf marathon-0.10.0.tgz$ mv marathon-0.10.0 /usr/local/marathon
这里有个地方要修改一下要把两句Memeos的lib位置写到/usr/local/marathon/bin/start 启动脚本的头部（Line2~Line5之间即可）：
export MESOS_NATIVE_JAVA_LIBRARY=/usr/local/mesos/lib/libmesos.soexport MESOS_NATIVE_LIBRARY=/usr/local/mesos/lib/libmesos.so
启动Marathon(10.239.21.100是Mesos-master的IP)
$ cd /usr/local/marathon$ bin/start --master 10.239.21.100:5050 --zk zk://10.239.21.100:2181/marathon
访问一下8080端口，查看Marathon主界面（图片是后抓的，已经有了任务，请无视）
执行Shell脚本
点击首页那个硕大的绿色按钮弹出层中
ID，要求全小写，小写字母开头，允许数字和“-”。好吧，要求不少。
command，写入一段shell命令，要求在所有的slave上都可以执行才可以。
这个时候访问Mesos的的控制台http://10.239.21.100:5050应该可以看到有一个任务出现，说明Marathon已经work。
PS：如果你发现在Mesos的头部出现如下图所示的警示框，说明你的主机不能通过主机名的方式访问Mesos集群中的节点。所以，我的建议是对于Mesos和你的工作机都要在hosts中加入对应的主机。
配置Slave支持Docker
本质上讲，一个task在marathon端被发布出来，扔给Mesos master，master根据自己的调度扔给其中的一个slave去执行。这就是我刚才说的“命令要求所有的Slave都能执行”的原因。所以理所当然的要求所有的slave上都要支持docker。
到每个slave上执行
$ apt-get update$ apt-get install docker.io
还记得我之前在mesos-slave-env.sh配置中的那个伏笔吗？
export MESOS_containerizers=docker,mesos
这个配置决定了Mesos可以直接支持Docker。如果没有启用这个配置的话需要在每个Slave上修改这个配置，并在master上通过两条命令重启。
$ /usr/local/mesos/sbin/mesos-start-cluster.sh$ /usr/local/mesos/sbin/mesos-start-cluster.sh
这里有个题外话就是mesos的一个有意思的特性：如果你有一个环境变量叫做MESOS_cluster的话，在启动服务且不被覆盖的话这个值等价于–cluster的入参。所有的参数都可以通过这种方式输入。修改的mesos-slave-env.sh和mesos-master-env.sh两个文件其实是用来启用环境变量的。
在docker中启用Container
Marathon作为一个还没有到1.0版本的项目来说，启动一个container还是最好用API来实现吧。要把一个Json post到http://10.239.21.100:5050/v2/apps 。我习惯上用Chrome的postman插件实现。
以下是我启动一个nginx的例子：
请注意，这是一个标准的RESTful API，一定要加上”Content-type: application/json”的Http header！
几个重要的filed解释：
id：其实是task name，字母开头，支持字母数字和‘-’。
docke.image：docker的镜像，默认会从dockerhub上去下载。
portMappings：对应的是一个container到主机port的mapping。但和传统的docker -p参数不太一样——只能制定开放哪几个端口的对外访问，但不能指定映射到local的什么端口。不过好在从API文档上来看，这只是现阶段没有完成而已，相信之后会完善的。
回到marathon主界面，如果看到对应的task已经启动，点击task名称，进入task描述。
你会看到下面的那个灰色的 mesos-slaver-01 : 31345，点击它就会看到mapping之后的nginx首页。
Swarm项目是Docker公司发布三剑客中的一员，用来提供容器集群服务，目的是更好的帮助用户管理多个Docker Engine，方便用户使用，像使用Docker Engine一样使用容器集群服务。这次分享内容从Swarm项目现状、Swarm社区现状和Swarm未来的一些规划三方面介绍Swarm，目的是能让大家对Swarm有个完整的认识，并且希望更多的人采用到Swarm项目中来。Swarm背景
现实中我们的应用可能会有很多，应用本身也可能很复杂，单个Docker Engine所能提供的资源未必能够满足要求。而且应用本身也会有可靠性的要求，希望避免单点故障，这样的话势必需要分布在多个Docker Engine。在这样一个大背景下，Docker社区就产生了Swarm项目。Swarm是什么
Swarm这个项目名称特别贴切。在Wiki的解释中，Swarm behavior是指动物的群集行为。比如我们常见的蜂群，鱼群，秋天往南飞的雁群都可以称作Swarm behavior。
Swarm项目正是这样，通过把多个Docker Engine聚集在一起，形成一个大的docker-engine，对外提供容器的集群服务。同时这个集群对外提供Swarm API，用户可以像使用Docker Engine一样使用Docker集群。Swarm 特点
对外以Docker API接口呈现，这样带来的好处是，如果现有系统使用Docker Engine，则可以平滑将Docker Engine切到Swarm上，无需改动现有系统。
Swarm对用户来说，之前使用Docker的经验可以继承过来。非常容易上手，学习成本和二次开发成本都比较低。同时Swarm本身专注于Docker集群管理，非常轻量，占用资源也非常少。 *“Batteries included but swappable”，简单说，就是插件化机制，Swarm中的各个模块都抽象出了API，可以根据自己一些特点进行定制实现。
Swarm自身对Docker命令参数支持的比较完善，Swarm目前与Docker是同步发布的。Docker的新功能，都会第一时间在Swarm中体现。
Swarm对外提供两种API， 一种是Docker API，用于负责容器镜像的生命周期管理， 另外一种是Swarm集群管理CLI，用于集群管理。
Scheduler模块，主要实现调度功能。在通过Swarm创建容器时，会经过Scheduler模块选择出一个最优节点，里面包含了两个子模块，分别是Filter和Strategy， Filter用来过滤节点，找出满足条件的节点（比如资源足够，节点正常等等），Strategy用来在过滤出的节点中根据策略选择一个最优的节点（比如对找出的节点进行对比，找到资源最多的节点等等）, 当然Filter/Strategy用户可以定制。
Swarm对集群进行了抽象，抽象出了Cluster API，Swarm支持两种集群，一种是Swarm自身的集群，另外一种基于Mesos的集群。
LeaderShip模块用于Swarm Manager自身的HA，通过主备方式实现。
Discovery Service 服务发现模块，这个模块主要用来提供节点发现功能。
在每一个节点上，都会有一个Agent，用于连接Discovery Service，上报Docker Daemon的IP端口信息，Swarm Manager会直接从服务发现模块中读取节点信息。
Swarm各个模块介绍
集群管理
Swarm Manager CLI用于集群管理。大家可以看这张图，通过三步就可以将集群创建起来。
Swarm容器集群创建完成后，就可以采用Docker命令，像使用Docker Engine一样使用Swarm集群创建容器了。 服务发现
服务发现，在Swarm中主要用于节点发现，每一个节点上的Agent会将docker-egine的IP端口注册到服务发现系统中。Manager会从服务发现模块中读取节点信息。Swarm中服务发现支持已下3种类型的后端：第一种，是hosted discovery service，是Docker Hub提供的服务发现服务，需要连接外网访问。 第二种，是KV分布式存储系统，现在已支持etcd、ZooKeeper、Consul三种。 第三种，是静态IP。可以使用本地文件或者直接指定节点IP，这种方式不需要启动额外使用其他组件,一般在调试中会使用到。 Scheduler
调度模块主要用户容器创建时，选择一个最优节点。在选择最优节点过程中，分为了两个阶段： 第一个阶段，是过滤。根据条件过滤出符合要求的节点，过滤器有以下5种：Constraints，约束过滤器，可以根据当前操作系统类型、内核版本、存储类型等条件进行过滤，当然也可以自定义约束，在启动Daemon的时候，通过Label来指定当前主机所具有的特点。
Affnity，亲和性过滤器，支持容器亲和性和镜像亲和性，比如一个web应用，我想将DB容器和Web容器放在一起，就可以通过这个过滤器来实现。
Dependency，依赖过滤器。如果在创建容器的时候使用了--volume-from/--link/--net某个容器，则创建的容器会和依赖的容器在同一个节点上。
Health filter，会根据节点状态进行过滤，会去除故障节点。
Ports filter，会根据端口的使用情况过滤。
调度的第二个阶段是根据策略选择一个最优节点。有以下三种策略：Binpack，在同等条件下，选择资源使用最多的节点，通过这一个策略，可以将容器聚集起来。
Spread，在同等条件下，选择资源使用最少的节点，通过这一个策略，可以将容器均匀分布在每一个节点上。
Random，随机选择一个节点。
Leadership
Leadership模块，这个模块主要用来提供Swarm Manager自身的HA。
为了防止Swarm Manager单点故障，引入了HA机制，Swarm Manager自身是无状态的，所以还是很容易实现HA的。 实现过程中采用主备方式，当主节点故障以后，会从新选主提供服务，选主过程中采用分布式锁实现，现在支持etcd、ZooKeeper、Consul三种类型的分布式存储，用来提供分布式锁。 当备节点收到消息后，会将消息转发给主节点。 以上就是框架中各个模块的相关介绍，下来和大家一起再看一下，Swarm与周边项目的集成。首先看一下，与三剑客之间的集成。Swarm与周边项目集成
三剑客是Docker公司去年底发布的三个项目，这三者是可以紧密协作的。可以看一下这张图：
最下面是Machine，通过Machine可以在不同云平台上创建出包含docker-engine的主机。Machine通过driver机制，目前支持多个平台的docker-egine环境的部署，比如亚马逊、OpenStack等。 Docker Engine创建完以后，就该Swarm上场了，Swarm将每一个主机上的docker-egnine管理起来，对外提供容器集群服务。最上面是Compose项目，Compose项目主要用来提供基于容器的应用的编排。用户通过yml文件描述由多个容器组成的应用，然后由Compose解析yml，调用Docker API，在Swarm集群上创建出对应的容器。 我们知道现在围绕Docker已经产生了很大的一个生态圈。 因此Swarm不仅在和自家兄弟集成，也能积极和周边的一些项目集成。比如，Swarm现在已经可以和Mesos进行集成。Swarm与Mesos集成时，也是以Framework方式集成，实现了Framework所需的接口。这个大特性处在experiment阶段。Swarm社区的现状
Swarm项目去年底发布，发展了短短半年时间，已经到了0.4版本，目前还处于正在快速演进阶段。 Swarm发布版本周期目前是跟着Docker一起发布，基本上两个月一个版本，在开发过程中，采用迭代方式开发，基本上每两个星期完成一轮迭代。参与社区的方法基本上和其他社区一致。当遇到问题时，可以在社区创建issue，然后描述问题，最好能上环境信息以及问题重现的步骤，这样有利于问题的定位。当然也可也直接通过IRC或者邮件直接交流。 Swarm社区很欢迎大家的参与，不论是使用中遇到的问题以及Bug，还是Swarm功能上目前无法满足大家的地方。都欢迎大家提出来，一起讨论。如果对代码感兴趣的话，可以参考Docker社区的提交代码流程来提交代码，也非常欢迎大家能够参与到Swarm社区中提交代码。Swarm未来规划
首先是支持所有的Docker API，现在支持率大概在95%，其中一些实现还存在问题，需要改进。
第二块是网络部分，通过Libnetwork项目，实现overlay network。
第三块是Self healing，通过这一个功能可以实现，当一个节点故障以后，会将故障节点上的容器在另外一些节点上创建。
第四块是Global Scheduler。这个特性主要用来将一个容器在每一个节点上进行创建。比如，想将一个log容器在每一个节点创建，用来记录日志，则可以通过这一特性实现。
最后是volume，这一块社区最近在讨论。
