利用docker compose模板，我们可以在本地单机docker环境快速地搭建一个apache storm集群，进行应用开发测试。
除此之外，本文还会介绍docker compose开发和云端部署经验，以及容器部署的调度约束。
本文的storm示例部署架构如下：
其中包含如下容器
zookeeper：apache zookeeper三节点部署
nimbus：storm nimbus
ui：storm ui
supervisor：storm supervisor (一个或多个)
如果您希望在直接云端部署验证，可以直接跳过这一节。
在mac/windows上，开发者只需利用docker toolbox就可安装配置本地的docker环境。它已经包括了docker和docker compose等工具可以方便地进行容器镜像和编排模板开发。
首先我们下载代码
在docker compose模板“docker-compose.yml”中，描述了上图所示的storm应用架构。其具体内容如下：
首先我们来构建所需的topology容器镜像，它会利用"../storm-starter"中定义的dockerfile来构建镜像。如果您需要测试自己的应用，只需要更新其中的jar文件即可。
我们可以运行下列命令构建测试镜像：
为了充分利用docker网络的能力，我们需要为 apache storm 应用创建一个自定义的bridge网络
现在我们可以用下面的命令来一键部署storm应用
部署完毕，检查storm应用状态
注意: 如果您本地docker环境配置与本文不一致，相应的docker虚机ip地址可能有所不同。您可以通过<code>docker-machine ip default</code>来获取相应的ip地址，并替换上面url中的"192.168.99.100"
利用如下命令，您可以伸缩supervisor的数量，比如伸缩到3个实例
您也许会发现web界面中并没有运行中的topology。我们不是已经在compose模板中定义“topology”容器依赖于“nimbus”服务容器吗？这个原因是docker compose只能保证容器的启动顺序，但是无法确保所依赖容器中的应用已经完全启动并可以被正常访问了。
所以，这个我们需要运行下面的命令来再次启动“topolgoy”服务应用来提交拓扑
稍后刷新storm ui，我们可以发现storm应用已经部署成功了
在本地docker单机环境只能做些简单的开发测试。而利用阿里云容器服务，我们可以在一组虚拟机部署和运行分布式apache storm。
为了确保应用的可用性，我们需要将zookeeper的三个容器实例部署到不同的ecs虚拟机上。同理，也需要将supervisor的容器实例部署到不同的ecs虚拟机上。
注意：
在这个试验中我们需要创建一个最少包含3个ecs节点的集群。如果集群中的节点数量不足三个，会导致部署失败。
容器服务支持按量付费的ecs实例，可以按小时付费，对20个节点以下集群不收额外的管理费用。测试之后您可以随时释放ecs实例或docker集群。
首先，我们对之前的docker compose模板做一些调整，来适合云端部署。更新版本如下：
这个模板只是针对本地的compose模板做了几个简单的调整和增强。其中变动的部分如下:
对“topology”服务，我们指明了预先构建的docker镜像而非像开发环境中那样动态构建镜像
容器服务缺省为每个集群创建了跨节点的容器网络，无需在compose模板中提供网络描述
除此之外，模板中利用了下列阿里云扩展来简化容器部署
为每个“zookeeper”服务，定义 <code>role: zookeeper</code> 标签，并用环境变量定义部署约束 <code>affinity:role!=zookeeper</code>。这样集群不会把zookeeper容器调度到已经拥有<code>role: zookeeper</code> 标签的节点上
同样，“supervisor”服务容器也利用了反亲和性约束将容器部署到不同节点上。而且"supervisor"服务的<code>aliyun.scale: "3"</code> 指明了容器的伸缩数量，所以系统会自动部署3个supervisor容器到3个不同的ecs节点上。
另外，上节谈到了docker-compose无法解决“topology”和“nimbus”容器之间的依赖次序，而容器服务提供了一个更加优雅的方案来保证容器之间的正确依赖
为"nimbus"容器添加标签<code>aliyun.probe.url: tcp://container:6627</code> 可以通过tcp端口6627的可用性来判断容器的健康状态
为"topology"容器添加标签<code>aliyun.depends: nimbus</code> ，让其等待"nimbus"进入健康状态之后再启动。这就确保了容器应用之间的正确的时序依赖。
我们还利用<code>aliyun.routing.port_8080: storm-ui</code>标签，这样可以为“ui”服务提供虚拟域名“storm-ui”来直接访问storm ui，而无需关系storm ui容器具体部署在集群中的哪一个节点。
通过容器服务控制台，基于以上面的模板之间部署一个容器应用，几分钟以后一个分布式storm应用已经在云端运行起来！我们点击“ui”服务端点，就可以打开storm ui。
检查应用的容器列表，这里我们可以发现不同的zookeeper容器被部署到不同的esc实例上。
topoloy也已经成功提交，这个过程是不是很简单 :-)
上文中，利用简单的调度约束可以让系统在集群中自动挑选合适的节点部署容器。但在真实的场景中，很多用户希望能够把容器部署到指定的一个或多个节点之上。这时应该如何做呢？
当节点加入集群之后，容器服务会为每个节点提供一些预定义的标签。
此外，用户还可以为节点编辑自定义标签。在控制台集群列表页面，选择集群并点击更多操作，我们可以看见如下操作菜单：
点击“用户标签管理”，就可以方便地编辑节点标签
提示： 与docker的社区实现不同，在容器服务中为指定docker节点添加标签，无需编辑配置文件并重启docker engine即可生效。
下面的示例，我们希望把三个zookeeper节点依次部署到第一、第二和第三号节点。另外把“ui”和“nimbus”容器部署到包含“server:manager”标签的节点上。这时候compose模板如下：
我们可以非常方便地利用下面约束来选择包含指定标签的节点
zookeeper1：<code>constraint:aliyun.node_index==1</code> 等等
nimbus，ui：<code>constraint:server==manager</code>
当storm部署成功后，再查看相应的容器部署。它们是不是完全依照您的指令来部署到指定节点上了呢？:-)
针对节点的容器调度约束，不但可以让你更好地对集群内节点进行分类管理，还非常适合使用host网络的应用场景。
利用容器和容器编排技术可以大大简化大数据框架的部署复杂性，提升部署效率。可以让数据工程师轻松在本地和云端搭建自己的计算环境，进行开发、测试和生产部署。