英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料

基于TOSCA元模型简化云应用中的DevOps自动化

Johannes Wettinger lowast;, Uwe Breitenbuuml;cher, Oliver Kopp, Frank Leymann

Institute of Architecture of Application Systems (IAAS), University of Stuttgart, Universitauml;tsstr. 38, 70569 Stuttgart, Germany

摘要

DevOps作为一个新兴的典范，其目的是使开发者和运维人员更加紧密地联系到一起。这保证了在一项新的应用在持续交付过程中快速且频繁的迭代更新。如今的互联网用户和手机APP用户对于运行在云端的应用希望得到关于问题和需求的快速回复。因此，能够做到快速地响应和回复用户的需求将是一个非常重要且有竞争力的优势。除此之外，要想应用DevOps必须改变现有的文化和组织结构，并且需要一些工具来实现端对端的部署过程。自动化是实现开发部门和运维部门紧密高效结合的关键。DevOps团体一直在持续发布新的方法、工具和开源的配置文档来实施这种自动化进程。然而，这些专有的、非均匀的自动化方法相互之间存在很大的差异，因此把他们集成在一起去自动化部署云端的应用是很困难的。在这篇文章中我们提出了一个系统的DevOps配置文档的划分方法并且展示了如何将不同的配置文档转化为TOSCA这个新兴的标准。我们提出了一个集成的建模和运行框架来实现不同方法的无缝集成来对软件拓扑结构来建模和部署。这个框架是通过一个开源的，端对端的工具链来实施的。而且，我们通过一个案例研究验证和评估了所提出的方法的可行性，尤其是向TOSCA转换的性能方面。

1 简介

如今，传统企业中开发部门和运维部门的分隔成为了快速且频繁的应用交付的一大障碍。这两大部门有着不同的目标，相互对立的意向和相互矛盾的工作进程^[1]。例如，开发者想要快速交付新特性，然而，运维人员却希望保持产品的稳定性。因此，这两个部门的合作和沟通主要基于缓慢的，手动的和错误驱动的进程。结果就是，需要花费大量的时间来在产品能够运行的环境下做出改变，添加新特性以及修复bug。然而，尤其是互联网用户和手机用户，他们期望能够快速实现他们所要求的改变或者新的需求。因此，能够实现快速且频繁交付的的自动化实施进程变得很有竞争力。而实现这些的唯一手段就是打破开发和运维部门之间的鸿沟。DevOps^[2]是一个新兴的范式来架起这两个部门之间的桥梁，进而实现高效合作。除了组织结果和文化的改变来消除隔离以外，部署进程还需要实现高度自动化来保证 软件的持续交付^[3]。不断发展的DevOps团体通过提供大量独立的途径，例如工具，配置文档等帮助实现整体的自动化部署。可重复利用的DevOps配置文档例如脚本，组件以及模板等都可以在实现自动化部署过程中免费使用。例如^[4,5]Juju charms1和 Chef cookboooks2.除此之外，云计算被用来提供基本资源，例如虚拟服务器，存储服务，网络以及数据库。DevOps工具之后就能配置和管理这些资源了。因此端对端的自动化部署是通过使用DevOps方法和云服务来实现的。

Chef cookbook 就得安装Chef，而要想使用Juju charm 就得运行Juju。这就使得使用不同的配置文档的人在一起合作时变得很困难。尤其是当要部署的系统包含很多种组件时，多种方式必须结合起来使用，因为不同的方法通常针对不同的中间件和应用组件^[6]。因此，有许多不同的解决方案并且要使他们完美地结合起来使用需要集成一些相互依赖的工具，例如 ，写一些工作流或者脚本来处理这些独立组件之间的调用。然而，这是一项困难，费用高且易出现错误的工作，因为没有一项标准方法以及支持的互操作性来实施这种集成。因此我们这项工作的主要目标就是基于新兴的OASIS标准TOSCA（Topology and Orchestration Specification forCloud Applications）^[7]实现不同种类的DevOps配置文档之间的无缝集成。在本篇文章中，我们做出的主要工作有：

1. 我们首次提出了针对DevOps配置文档的分类方法以及指出了他们是如何工作的
2. 我们提出了一套基于TOSCA的集成的复杂的建模和运行时框架，包含了发现、转换、配置文档的API化以及应用拓扑和改进和部署。
3. 我们针对Chef cookboooks 和 Juju charms讨论了具体的配置文档转换.

在这篇文章中提到的主要工作是基于先前被发布在第七届国际应用程序和云计算大会上的Standards-based DevOps Automation and Integration Using TOSCA^[8]这篇文章中的研究。为了使读者能够更好地理解，在本篇文章中开始的部分我们重复了先前的研究来介绍当前的研究现状。剩下的部分主要由以下部分组成：第2部分进行了问题描述并提出了一项驱动方案来作为运行案例。第3部分展示了我们的基础工作，包括对DevOps配置文档的分类以及对Chef cookbooks ，Juju charms 和TOSCA的介绍。在第4部分描述了我们的核心工作，即基于TOSCA的集成建模和运行时框架的搭建。基于驱动方案，在第5部分介绍了针对我们的框架和实施的评估和验证体系。第6和第7部分介绍了相关工作以及对本次研究进行了总结。

2 问题提出以及驱动方案

DevOps团队通过分享开源的配置文档方案，例如脚本，组件，模板等来部署中间件和应用组件。他们的可移植性以及共享性使得他们能作为一个预定义的方法来重复使用进而实现对多种不同的应用的自动化部署，尤其是对网页应用以及手机的后台应用。只要使用一种单一的配置文档，那么与这种配置文档实现互操作和通信的工具就必须被同时使用，例如，要想使用Chef cookbooks 就得使用Chef runtime^[9]。然而，将不同种类的配置文档例如Chef cookbooks 和Juju charms无缝集成起来使用是最主要的挑战。要学习和集成他们所有的特性例如调用机制、模式声明、参数传递等就需要额外的努力。除此之外，不同的配置文档和工具的编排也必须要使用工作流或者脚本在非常低层次的抽象上集成起来。这需要对通信技术有很深的了解以及对整体流程方法有全面把握。通常，这需要大量的胶水代码来粘合，但这样做使得非专业人员很难理解和维护整体流程。接下来我们将会讨论一个驱动方案来作为具体案例以验证集成不同种类的配置文档的必要性。

图1展示了一个网上应用的一部分拓扑结构^[10]。该应用程序本身托管在Apache HTTP服务上，并依赖于PHP模块。应用程序的数据库托管在一个MySQL主/从环境以提高应用程序的可扩展性以及使数据库的高可用性：写到数据库上的数据同时也复制到了从数据库上，所以读取所需求的数据时就能将压力平分到各个从数据库上了。万一主数据库崩溃了，任何一个从数据库都能成为一个主数据库。用户可以按照一定的要求或者偏好来选择低层基础设施和/或平台。例如，Apache和MySQL服务器可以被托管到亚马逊网络服务上3。为了为这个应用程序实施自动化部署，我们的目的是重复使用已存在的DevOps配置文档，尤其是部署中间件的时候。例如，假设Apache HTTP服务器和PHP模块在同一个虚拟机上运行，那么就可以用Chef cookbooks来部署他们。然而，没有Chef cookbook能够部署一个完整的MySQL主从服务器。除此之外，还缺失管理这种环境所必要的组件。因此，使用Juju团队共享的MySQL charm来部署和动态安装这种MySQL能够更好地满足所有的需求。这样做就在自动化部署过程中添加进来了别的配置文档，这就意味着要学习、使用和构建额外的工具来处理和执行相应的配置文档。最后，我们可能还实施了定制的Unix脚本来为我们的网页应用和它的数据库实现特定的部署和操作要求。这些脚本用来部署拓扑结构中具体应用的部分。因此，在自动化部署程序中还需要另外一种配置文档。所以，三种不同的部署技术必须以重用最适用的配置文档的方式结合起来从而以全自动的的方式高效部署应用。这种方式早已经在一个简单的应用拓扑结构上实现了，就像图1所展示的那样。因此，用一次部署多次运行的方式仅使用一个单一的部署方案对于许多方案来说是不合适的。

像TOSCA5这样的云服务标准通过一套元模型来解决无缝集成和不同结构之间的结合问题。OTSCA可以被无缝集成以及使用来创建能够自动化部署的应用组件。TOSCA是一项新兴的标准，它缺乏一个社会生态系统以及可重用的配置文档。然而，基于开源社区的生态系统是实践中建立TOSCA的关键^【11,12】。因为DevOps社区提供这样的生态系统但是他们大多都是独立和专用的，所以我们的目标就是发现并且向TOSCA转化现有的DevOps配置文档来使得他们能够重用和无缝集成。也就是支持用可执行的DevOps配置文档改进以TOSCA为基础的应用拓扑结构来实现维护应用软件时的自动化部署。为了提供帮助理解的背景知识，接下来的第3部分介绍了DevOps配置文档的分类方法，概述了两款具体的DevOps工具即Chef和Juju，以及说明了TOSCA的基本构造。

3. 基本理论

在本章中我们将讨论我们的研究所根据的基础理论。3.1部分提供了对DevOps配置文档的基本分类，分出了他们之间概念上和技术上的不同。在接下来的讨论中我们采用了每种分类中最有代表性的案例。TOSCA中最重要的概念和组件在3.4中进行了介绍，作为第4 部分中研究的核心内容，主要介绍了集成模型以及运行时框架。

3.1 对DevOps配置文档的分类

正如在第2 部分所讨论的那样，DevOps社区共享了大量的不同种类的用于部署中间件和应用组件的工具和配置文档，并且其数量还在不断地增长。因为这些工具和配置文档在设计和使用上互不相同，对于他们的分类有利于他们进行系统性的分门别类，就像在先前的研究中所提到的那样^[13]。图2展示了对于DevOps配置文档更进一步的分类，这种分类方法主要基于两大类。

节点中心配置文档（NCAS）是脚本、虚拟机镜像、组件、声明的配置定义等等。这些是在一个独立的节点上执行的，例如一台物理机、一个虚拟机或者一个容器。例如一个应用组件与另一个节点上的数据库连接起来这样跨节点的联系没有明确地表明和实施。因此，节点中心配置文档不能用于部署完整的应用拓扑结构只能安装和配置单独的节点。

环境中心配置文档（ECAS）是脚本、包、模板等等。他们在一个包含着许多节点的环境中执行。跨节点的联系能够被明确地表示和实施。因此，环境中心配置文档可以被用来部署完整的应用拓扑结构。

Unix脚本、Chef cookbooks、Puppet 组件6、SaltStack组件7、以及Docker镜像8是典型的节点中心配置文档。Juju charms和 bundles、Amazon CloudFormation templates9以及OpenStack Heat templates10是环境中心配置文档的典型代表。然而节点中心配置文档以及环境中心配置文档并不是单独使用的。事实上环境中心配置文档通常要使用节点中心配置文档。例如，Juju charms使用Unix 脚本来安装、配置以及连接VM虚拟机上的应用组件。而且，Amazon CloudFormation templates能够使用Chef cookbooks来实施部署逻辑。除了在环境中心配置文档中利用节点中心配置文档以外，还需要额外的管理工具来对环境中心配置文档上的节点中心配置文档进行管理。例如，Marionette Collective12能够在大型环境中管理Chef cookbooks的分配和执行，给环境中的节点提供持续的的，具体环境中的环境信息。在一个节点环境中以Docker为代表的容器是另一种方法来分布和托管基于Docker镜像^[16]的容器等包括多个VM虚拟机。

本文提出的基于节点中心配置文档和环境中心配置文档是我们的转换方法的基础。当选择和结合不同的配置文档来实施自动化部署时还需要考虑别的方面，包括：

依赖等级：一些配置文档依赖于提供者。例如CloudFormation templates等。这些配置文档必须和提供者一起使用，例如本例中的Amazon。其他配置文档依赖于工具例如Chef cookbooks和Juju charms，这些配置文档可以和不同的提供者结合使用但必须安装特定的工具，例如Chef运行时工具和Juju运行时工具。

虚拟化等级：有些配置文档可能依赖于特定的虚拟化方案，例如基于管理程序的虚拟化（如Amazon机器镜像）或者基于容器的虚拟化（如Docker镜像）^[15]。

尤其是环境中心配置文档能够很容易与基础设施中心以及应用中心配置文档区分出来。基础设施配置文档如CloudFormation templates专注于对VM虚拟机、存储以及网络这些基础设计的配置和管理。Juju bundles更倾向于应用中心配置文档，它专注于配置和管理中间件和应用组件以及透明化管理底层基础设施。

有一些基于定义的配置文档如Chef cookbooks和Puppet 组件，他们定义了对像VM虚拟机或者容器这样的资源的配置方案。另一方面，基于镜像的配置文档如Docker镜像通过储存连续的状态信息利用特定资源的状态去创建新的实例。

基于定义的配置文档可以通过声明式的、驱动式的或者两者相结合的方式来创建。

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[151299]，资料为PDF文档或Word文档，PDF文档可免费转换为Word