时下Docker编排工具一瞥
从《Docker orchestration》这篇有趣的文章中，我们要思考为什么需要编排工具？基本的前提是，编排工具扮演了创建基于应用的容器及其层依赖的时间编排的角色，也就是使容器之间能够通信、彼此可以传递运行期的属性。在此我们更深入地探讨这篇文章的观点。
今日，尚无关于容器作为可移植的部署单位的讯息。但是，通常应用由多个容器构建会增加复杂度。而且，由多个Docker镜像组建集群的方式颇为笨重，因为这需要让容器感知其他容器的存在并暴露内部信息给其需要通信的容器。这并非小事一桩，尤其是当容器分布在不同主机上时。例如，构建一个由Docker容器组成的Mongo或者Cassandra集群，需要考虑集群环境内，哪些端口需要暴露、哪些卷（volume）需要挂载（mount）等复杂信息。
这些场景驱动了一些编排工具的发展，正如这篇关于Docker容器和微服务的优秀文章提出并由这篇 InfoQ文章所引述的，列表中的容器编排工具正在快速成长。这里列出其中著名的工具（当然这不是全部）。
- Kubernetes - Google出品的开源Docker容器编排工具，特别为微服务的编排而设计。
- Fleet - CoreOS的Docker编排工具，为在CoreOS上安装容器而设计。
- Docker - Docker最近公布了Docker Swarm和Compose，这是为运行Docker集群而设计的编排服务。
此外，CoreOS最近公布了Rocket，我们将有幸一窥这另一种格式的容器将如何影响编排工具的前景。
纯粹的编排标准的必要性
我们经常使用可搬运的容器（shipping containers）来形容软件容器作为标准打包单位的角色。可搬运的容器是标准化益处的极佳示例。没有标准的容器，搬运货物的场景将与今天完全不同。就可搬运的容器而言，容器的形状、体积和装配的实际标准不会受制于单一的容器厂商，而更趋向于多家厂商共存。CoreOS近期公布的Rocket只是这一趋势的首个象征。
用TOSCA来解决
TOSCA （云应用的拓扑编排标准，Topology Orchestration Specification for Cloud Applications）是由OASIS组织 （XML的制定者）管理的。从TOSCA 编排工具的跟踪记录和发展速度上看，已经发展得相当成熟，许多组织正在投注和促进其成功。 自多年前的第二版以来，TOSCA得到了长足的发展，同时在商业和开源项目中吸引眼球，博得了诸如Juju、Cloudify、IBM Cloud Orchestrator和 OpenStack Heat的芳心。同时也被电信供应商领袖阿尔卡特-朗讯、 华为和思科所采纳。
事实上，TOSCA由标准团体（OASIS）在背后支持，使其成为强大的平台来定义能够可移植于各种云环境和容器提供商的标准容器编排工具的规范。
本文将提供一个示例来展示把当前的Docker API标准映射到可移植的TOSCA标准是多么的简单，因此，我们将使用直观的声明式方式来描述复杂的基于Docker的应用拓扑。
Docker的TOSCA规划
为使初始的映射过程简单，我们使用python客户端docker-py作为如下提案的基础。
接下来是TOSCA规划的代码片段，用来描述基于Docker的MongoDB服务器--更大的应用拓扑的一部分。映射按照最新的TOSCA规范中的YAML格式和Docker容器建议的模型工具来使用TOSCA。
mongod:
type: docker_container
properties:
image: dockerfile/mongodb
command: mongod --rest --httpinterface --smallfiles
exported_ports:
- 27017
- 28017
port_bindings:
- 27017: 27017
- 28017: 28017
volumes:
- ~/my-host-dir, container-dir, rwTOSCA格式非常类似其他类型的依赖注入，主要的不同是基于YAML并且更特定于编排领域。因此，其中包含了生命周期、关系、策略和计划，还描述了应用服务的运作方面的定义。
使用TOSCA运行简单的Docker示例
我将使用Cloudify上的开源编排工具、一个简单的TOSCA命令行分析器让你感受基于TOSCA的编排工具是如何工作的。
我们将使用基于NodeJS的web应用nodecellar示例，后台数据库使用MongoDB。每个服务将运行在独立的Docker容器中，如下图所示。
从DockerHub下载nodecellar TOSCA规划的Docker镜像，该镜像可以重用于后续的安装和卸载。从镜像启动整个应用的镜像启动约10秒左右！
示例逐步指导
示例在12.04作为底层的操作系统的环境中测试过。示例可以有两种规划实现，一种是单一主机部署，另一种是OpenStack上的集群部署。简单起见，本文重点放在单一主机部署的示例上。
通过如下步骤运行示例
| 搭建环境 | |
| 安装Docker | |> curl -sSL https://get.docker.com/ubuntu/ \| sudo sh 使用如下命令检查安装是否正确： > sudo docker ps |
| 安装Cloudify | |> pip install cloudify 使用如下命令检查安装是否正确： > cfy --version 也可以使用vagrant-box获取cloudify的预配置镜像或者其他安装选项如这里所述 |
| 安装TOSCA/Docker示例 | |
| 下载示例 | 从此处下载和解压缩示例 |
| 将当前TOSCA规划指向示例规划文件 | |>cfy local init -p blueprint/docker-singlehost-blueprint.yaml -i blueprint/cfy-local-inputs.json --install-plugins |
| 执行安装流程 | |>sudo cfy local execute -w install 这个命令将在规划上执行上一步设置好的安装流程。 安装/卸载流程是每个规划的隐式工作流程之一。安装流程将遍历TOSCA依赖关系图，并按照指定的关系和依赖定义的顺序，在每个节点上执行生命周期命令。卸载流程是类似的逆操作。 在这份规划中，在第一次运行时将下载Docker镜像（这将耗时几分钟），然后运行两个Docker实例，一个是mongod实例，另一个是nodejs实例，应用和数据库会安装到对应的实例上。 |
| 检查输出 | > cfy local outputs 输出应当打印出nodecellar应用的主机:端口号 |
| 打开应用 | 使用上一步的主机名和端口号在浏览器中打开如下链接： http://输出的主机名:输出的端口号 注意，如果运行在vagrant-box上，应当替换默认的host_ip属性值localhost为vagrant虚拟机主机IP |
写在最后
以当前IT基础设施的演进速度，可以假设我们将继续拥有多家容器供应商和编排引擎。照此观点，定义和管理容器集群的规范将会标准化，并由多家容器或编排工具的供应商支持，否则容器作为可移植的搬运单位将受到质疑。
此外，我们必须假设许多公司将全部应用都运行于容器之内的期待是不切实际的，更可能的情况是运行混合的应用。为每种应用类型设计编排引擎很容易出现运作上的噩梦，这是存在多种既支持不同容器又支持混合环境（包括基于Chef、 Puppet、SaltStack等等的非容器化服务）的独立编排引擎另一个原因。
TOSCA当前编排规范的先进性使其成为容器标准蓝图的定义的理想候选者。
拥有标准的编排格式并非考虑选择TOSCA的唯一因素，不像大多数当下基于容器的编排工具几乎完全处理初试设置和安装阶段的事情，TOSCA覆盖了整个应用的生命周期，包括部署后的事情，如监控、额外的工作流程（持续部署、水平扩展、订正）以及自动触发这些工作流程的策略，从而提供了更全面的编排定义。
这项工作的目的是为了说明使用标准的TOSCA YAML编排Docker的应用是多么简单。我希望这篇文章能为社区的讨论和头脑风暴提供良好的基础。