Docker Orchestration... What It Means and Why You Need It (Docker 编配 ...它是什么意思，为什么你会需要它？)
Docker Orchestration… What It Means and Why You Need It
原文作者：Cloudify Community
原文地址：https://dzone.com/articles/docker-orchestration-what-it
译者微博：@从流域到海域
译者博客：blog.csdn.net/solo95
本文同样刊载于腾讯云+：https://cloud.tencent.com/developer/article/1019149
Docker 编配 …它是什么意思，为什么你会需要它
本文由Yaron Parasol编写
Docker容器是为了帮助快速，可靠地部署应用程序组件或层(tier)而被发明的，其实现方法是创建一个容器，该容器包含可自行部署的应用程序部分以及成功运行它们所需要的中间件和应用程序业务逻辑。例如，Tomcat容器中的Spring应用程序。按照设计，Docker被故意设计为应用程序中独立出来的独立的部分，通常是层中的一层或甚至层中的一个节点。
然而，一个应用程序通常是在其体系中是多层架构的，这意味着存在层与层之间的依赖关系，依赖的本质可以是从网络连接和远程API调用到应用程序层之间的消息交换之间的任何东西。因此，应用程序是一组具有特定配置的不同容器。这就是为什么你需要一种方法来把你的应用程序粘贴在一起。
虽然Docker有一个使用Docker bridge的基本解决方案，但是这个解决方案并不总是首选，尤其是在跨不同主机部署容器时，您需要关注真正的网络设置。
如何使用TOSCA + Cloudify编配Docker。让我们来一探究竟。点这里
那么，orchestrator扮演什么角色呢？
(orchestrator，音乐中指乐器的调配者，这个建议不翻译，或者参考番剧《中二病也要谈恋爱》，翻译成圣调理人(๑•̀ㅂ•́)و✧)
orchestrator将会处理两件事：
- 容器创建的时机 - 因为容器需要依赖和顺序创建
- 为了允许容器相互通信而进行的对容器的配置 - 为此，orchestrator需要在容器之间传递运行时的某些属性。
作为一个方面的说明：在Docker中，你需要一个特殊的调整，因为你通常不会碰到容器内的配置文件，为了容器保持完好无损，对于这种情况需要一个有趣的解决方法。
一种方法是使用基于YAML的编配方案(orchestration plan)编排应用程序的部署和部署后的自动化过程，这是Cloudify采用的方法。基于TOSCA（云应用程序的拓扑和编配标准），这个编配方案描述了组件及其生命周期，以及组件之间的关系，特别是涉及到复杂的拓扑时。这包括什么与什么相连接，什么host了什么，以及其他这样的考虑。TOSCA能够描述基础架构，以及中间件层和应用层。Cloudify基本上采用这个TOSCA编配方案（在Cloudify中称为blueprint），并使用遍历组件的图(graph)或这个方案的组件并向代理发布命令这样的工作流来实现这个方案。然后创建应用程序组件并将它们粘合在一起。
代理使用被称为插件的扩展(程序)，它们是Cloudify配置和各种基础架构即服务（IaaS）以及自动化工具的API之间的适配器。
在我们的例子中，我们创建了一个与Docker API接口的插件。
Docker Cloudify插件介绍
该Cloudify-Docker插件简单直接，它在机器上安装Docker API 终端/服务器，然后使用Docker-Py把容器
的创建，配置和删除结合起来。TOSCA生命周期事件是：
- Create(创建) - 安装应用程序组件
- Configure(配置) - 组件的配置
- Start - 启动/运行组件
- 还有stop(停止)和(delete)删除 - 关闭和删除
我们从Create开始使用 - 创建一个容器，我们没有在一开始时就去实现配置，并开始运行应用程序。但后来我们意识到，对于具有依赖性的容器，我们需要有运行时的环境属性，比如为了创建容器，我们需要导入相应容器的IP。当我们创建一个app服务器容器时，我们需要端口和数据库容器的IP。因此我们把容器的创建推到了configure eventceng层面上，并且使用了一个基于TOSCA relationship的预配置钩子来在运行时获取相关容器的信息。
将运行时信息公开到具有依赖关系的容器的方法是将它们设置为环境变量。
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 app作为例子来解释这是如何工作的。Nodecellar app由两台主机组成，在这种情况下，Cloudify不创建，只是SSH进入，然后安装代理。一方面，我们有带MongoD进程的MongoD容器。另一方面，我们有带NodeJS和Nodecellar应用程序的Nodecellar容器。Nodecellar容器需要连接到MongoD容器，以在应用程序启动时运行app queris。
最终，orchestrator不应该仅仅局限于软件部署，Docker背后的全部思想是为了保持灵活性，所以我们也希望在自动扩展、自动修复和CD的情况下使用Docker。在下一篇文章中，我们将精确地展示如何将Cloudify与Docker一起用于后期部署场景。
