什么是Docker的编排？它到底意味着什么？为什么我们需要它？

[本文由Yaron Parasol编写]

什么是Docker容器？ Docker容器是为了帮助开发者们快速，可靠地部署应用程序组件或层而被开发出来的，它是通过创建一个包含可自行部署的应用程序组件，中间件和应用程序的业务逻辑的容器来成功进行运行的。举个例子来说，Tomcat容器中的Spring应用程序就是一个docker容器。按照开发设计的原则，Docker被特意的作为应用程序中独立的部分，一般来说，它通常是层中的一个层，甚至一个节点。

然而，一个应用程序在其架构中通常是多层的，这意味着什么呢？这意味着层与层之间有依赖的关系，而依赖的性质可以发生在任何从网络连接和远程API调用到应用程序层之间信息交换的过程中。因此，应用程序也是一组具有特定配置的不同容器。这也就是为什么您需要一种方法来将您的应用程序整合在一起。

虽然说Docker有一个通过使用Docker桥来连接容器的基本解决方案，但是这个解决方案并不会总是首选，尤其是在跨不同主机部署容器时，因为您需要考虑到真实的网络设置这个问题。

Docker与TOSCA + Cloudify的编排。来让我们一探究竟。 （链接）

那么，编排器扮演着什么角色呢？

编排器将会处理两件事：

1. 容器创建的时机 - 因为容器需要按照依赖性的顺序创建
2. 为了允许容器之间能够相互通信所需要的配置 -正因为这样，编排器需要在容器之间传递各自容器运行时的属性。

一点小小的备注：因为在Docker中您通常不会碰到容器内用来保持容器完整性的配置文件，所以您会需要对应用程序做一些调整。对于这种情况来说，您就需要一个非常有趣的解决方法。

一种方法是Cloudify一直采用的，也就是使用基于YAML的编排计划来编排应用程序的部署和部署后的自动化过程。这个编排计划主要是基于TOSCA（云应用程序的拓扑和编排标准）的，它描述了一般情况下以及涉及到复杂的拓扑时的应用程序组件及其生命周期，以及组件之间的关系。比如，哪些组件与哪些组件有关，什么组件主导着什么组件，以及其他各种各样类似的考虑都包括在内。因为TOSCA这个标准能够准确的描述出云应用程序的基础架构，中间件层以及应用层。所以Cloudify大部分情况下都会采用这个TOSCA编排计划（在Cloudify中称为蓝图），并使用遍历组件图或使用这个组件计划向代理发布命令的工作流。然后Cloudify就会创建应用程序组件并将它们组合在一起。

使用代理被我们称为插件扩展，它们是Cloudify配置各种IaaS和自动化工具的API之间的适配器。

接下来，我们会创建一个与Docker API接口的插件来作为演示示例。

介绍Docker Cloudify插件

Cloudify这个Docker插件 其实是非常简单的，因为它会安装在机器上的Docker API端点或服务器上，然后使用Docker-PY来结合创建，配置和删除容器的功能。以下是TOSCA生命周期事件：

• 创建 - 安装应用程序组件
• 配置 - 组件的配置
• 开始 - 启动/运行组件
• 停止和删除 - 关闭和删除

接下来，我们开始使用create来创建容器。我们并不会在开始时就执行这个配置并运行应用程序。但后来我们意识到，对于具有依赖性的容器，我们需要它的运行属性来进行下一步的操作。我们拿创建容器时采取的对应容器IP导入来作为例子。因为当我们创建一个应用服务器容器时需要数据库容器的端口和IP，所以我们把容器的创建推送到了配置事件上，并且使用了一个TOSCA关系的预配置引导用来在运行时获取相关容器的信息，这样我们就可以解决这个问题了。

将运行时的信息公布到具有依赖关系的容器的方法是将它们设置为环境变量。

查看源代码

如果你想打印这段代码，请点击这里

以下是代码展示：

01. interfaces:
02.       cloudify.interfaces.lifecycle:
03.         configure:
04.           implementation: docker.docker_plugin.tasks.configure
05.           inputs:
06.             container_config:
07.               command: mongod--rest--httpinterface --smallfiles
08.               image: dockerfile/mongodb
09.         start:
10.           implementation: docker.docker_plugin.tasks.run
11.           inputs:
12.             container_start:              
13.               port_bindings:               
14.                 27017: 27017
15.                 28017: 28017

Nodecellar 示例

我想通过使用我们的Nodecellar应用程序作为例子来解释它是怎样工作的。Nodecellar应用程序一般来说由两台主机组成，在这种情况下，Cloudify不会被创建，但是SSH会接入并且安装代理。在其中一台主机上我们安装有MongoD容器和MongoD进程。另一台主机上，我们安装了Nodecellar容器和NodeJS与Nodecellar应用程序。Nodecellar容器需要连接到MongoD容器，以便于在应用程序启动时运行程序的query。

其实，编排器不应该仅仅局限于软件部署，因为Docker背后的理念是为了保持开发的灵活性，所以我们也希望在自动扩展和自动修复的情况下使用Docker。在下一篇推送中，我们将精确地为您展示如何在后期部署的场景中将Cloudify与Docker一起搭配使用。