[本文由Yaron Parasol编写]
创建Docker容器是为了帮助实现应用程序组件或架构中的分层的快速,可靠的部署,创建一个容器,该容器包含一个可以部署应用程序的部分,以及成功运行它们所需的中间件和应用程序业务逻辑。 例如,Tomcat容器中的Spring应用程序。 按照设计,Docker有意作为应用程序中独立的部分,通常是架构中的一层或甚至一个节点。
然而,一个应用程序通常是在其架构中是多层的,这意味着多层之间有着依赖关系,依赖性的性质可以是从网络连接和远程API调用到应用程序层之间的消息交换。因此,应用程序是一组具有特定配置的不同容器。这就是为什么需要将应用程序组合在一起。
虽然Docker有一个使用Docker桥连接容器的基本解决方案,但是这个解决方案并不总是首选,尤其是在跨不同主机部署容器时,需要配置正确。
Docker与TOSCA + Cloudify如何协调?
那么,协调人扮演什么角色呢?
业务流程有这两个重要步骤:
作为一个方面说明:在Docker中,你需要一个特殊的调整,因为你通常不会触摸容器内的配置文件,所以你可以保持容器的完整性,所以对于这种情况需要解决方法。
一种方法是使用基于YAML的编排计划编排应用程序的部署和部署后的自动化过程,这是Cloudify采用的方法。基于TOSCA(云应用程序的拓扑结构和业务流程标准),这个编排计划描述了组件及其生命周期和组件之间的关系,特别是涉及到复杂的拓扑结构时。这包括什么与什么有关,什么主持什么,以及其它这样的考虑。TOSCA能够描述基础架构,以及中间件层和应用层。Cloudify基本上采用这TOSCA编排计划(在Cloudify中称为蓝图),并使用遍历组件图或这个组件计划并向代理发布命令的工作流实现这些计划。然后创建应用程序组件并将它们粘合在一起。
代理使用称为插件的扩展,它们是Cloudify配置和各种基础架构即服务(IaaS)和自动化工具API之间的适配器。
在我们的例子中,我们创建了一个与Docker API接口的插件。
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应用程序来解释它是如何工作的。它们由两台主机组成,在本例中,Cloudify并没有创建,而是直接插入并安装了代理。一个是MongoD的容器,一个MongoD的进程。另一种是Nodecellar的容器,里面有NodeJS和Nodecellar应用。当应用程序启动时,Nodecellar容器需要连接到MongoD容器来运行应用程序查询。
一个协调器不应仅限于软件部署,Docker背后的全部思想是为了保持灵活性,所以我们也希望在自动扩展和自动修复CD的情况下使用Docker。 在下一篇文章中,我们将说明如何将Cloudify与Docker一起用于后期部署场景。