CN104335170A - 云应用部署 - Google Patents

Abstract

一种系统（100）包括应用模型（140）以特征化用于云（130）上的部署的给定应用（110）。一种部署管理器（120）基于与给定应用（110）相关联的应用模型（140）和策略（150）分析用于给定应用（110）的应用需求，以实质上匹配云（130）中的基础设施资源（160），从而满足应用需求。

Description

云应用部署

背景技术

云计算指的是可伸缩的和合并的计算、存储以及联网能力作为服务到终端接收者的网络的递送。名称来自云作为网络的复杂基础设施和可在云内操作的关联硬件的抽象的使用。例如，云计算通过网络为用户的数据、软件以及计算提供服务。这样的计算能力依靠资源的共享来通过网络（通常为因特网）实现规模与公用设施（例如电网）类似的相干性和经济。部署在支持云的资源上的应用目前常常不得不被手动地部署并且那消耗相当多的管理时间。部署应用的手动步骤包括基础设施的提供和安装。这需要从应用的安装或映像的部署链接到所部署的基础设施的完备知识。手动部署通常需要由试图部署应用的用户所通常启动的步骤的许多序列。

附图说明

图1图示了提供用于云应用的自动部署的系统的示例。

图2图示了用于将用于云基础设施的资源能力与应用的执行需求相关的部署管理器的示例。

图3图示了用于应用的自动部署和监控的示例系统。

图4图示了利用用于应用的部署和监控的闭环反馈的示例系统。

图5图示了用于应用的自动部署的示例方法的流程图。

图6图示了用于云应用的自动部署的示例部署系统。

具体实施方式

图1图示了促进用于云应用的自动部署的系统100的示例。系统100可以通过利用部署管理器120提供应用110的自动部署，以确定云基础设施130（也被称为云130）的基础设施能力，并且还通过分析应用模型140和策略150来确定应用110的应用需求。在这种确定之后，部署管理器120可以自动地管理云130上的应用110 的生命周期，其中识别匹配（例如，理想或最佳努力）。基于匹配中的接近的测量和/或其它策略需求，选择匹配并且能够供给/实例化所述基础设施。在对应用需求的资源的这样的绝对或最佳努力匹配之后，然后可以在云130上部署应用110的组件。

当已基于所述匹配部署应用时，部署管理器120还可以管理应用的生命周期的其它方面。例如，部署管理器120可以监控反馈，并且基于这种反馈调整基础设施资源。附加地或可替代地，部署管理器120可以基于这种反馈或其它检测的事件动态地调整应用模型和对应的策略。类似地，这还可以包括收回较老版本的应用组件（例如，代码、中间件（MW）、数据库、操作系统（OS）等）并且安装新版本的组件以实现应用在云基础设施130中的连续部署。

云130可以是混合的，使得其可以是以下各项的组合：被制造以像基础设施资源一样运行的传统数据中心、私有云（在内部被开发的云技术）、公共云（由服务提供商供给的）以及管理的云配置（在内部或在公共云/虚拟私有云中被管理）。如在此所使用的，术语应用适用于组件的集合。此外，应用可以由一组工件（artifact）（例如，安装程序、可执行、配置等）以及一组可以被安装并且与彼此交互的组件（例如，代码、中间件（MV）、数据库、操作系统（OS）等）特征化以用于其组件中的每一个。此外，如在此所使用的，术语确定可以包括编译、列举和匹配。

如本文中所使用的那样，术语“实质上”旨在指示虽然正被修改的术语的功能或结果是期望的或计划中的结果但是一些变化能够产生。在这个上下文中，例如，术语“实质上匹配”描述了结果得到的分析和比较被执行以识别相同的资源的情形；然而，在实践中匹配能够对应于充分地类似于使得能实现部署的一组资源。在多于一个这样的一组资源可能对应于匹配时，部署管理器能够选择最佳匹配的一组可用资源。能够利用用于选择这样的匹配的其他方法。

应用模型140能够被采用来诸如通过用于应用的各种组件的元数据描述来特征化用于部署在云130上的给定应用110。部署管理器120能够经由可由处理器执行的指令或可由处理器读取的数据来实现以基于与给定应用相关联的应用模型140和策略150（或诸策略）来分析对于给定应用110的应用要求。如将在下面所描述的那样，策略150能够被提供来描述应用110的附加的操作上下文（例如，在午夜之后操作应用、仅使用东海岸服务器、维护服务器之间的负荷均衡、部署在给定网络域内、确保负荷在服务器上的规定限制之间、确保在给定窗口内不存在即将到来的维护等等以及匹配的“测量接近”的技术）。部署管理器120然后能够确定在云130中足以实现如由模型140和策略150所规定的应用110的应用要求的基础设施资源。

云130的基础设施能力能够经由与云相关联的资源供给和元数据160确定。例如，支持云130的多个服务提供商能够提供规定他们让什么类型的资源可用的文件和描述相应资源供给（例如，可用的三个服务器的资源供给，其中元数据规定存储器大小和处理器速度、负荷（如果已经实例化）、位置、租赁条款、服务级别协定（SLA）、调度的维护等等）的感兴趣属性的元数据。

在一个示例中，部署管理器120可以在将应用110的应用需求与由资源供给和元数据160指定的云的能力相匹配之后自动地在云130上部署给定应用110。在此类型的示例中，其通常相当于执行以下所述的其它接下来的示例的指令（可能是通过调用管理基础设施和/或应用的生命周期的外部系统）。如前所述，术语应用110可以包括一组将被安装和执行的组件（例如，除了安装和配置这种组件的代码之外的多个分层逻辑、用户接口（UI）、中间件（MW）、数据库（DB）、操作系统（OS））。因此，应用110指的是这些组的组件和工件，其还可以包括这种组件和工件的存储库。应用还可以由指向所述组件和工件的指针标识，其包括单独指针或指向一组组件的指针。在另一个示例中，部署管理器120可以生成指令以通知系统（或用户）如何在云130上部署给定应用110。在任一示例中，部署管理器120将由模型140和策略150指定的应用110的需求与由资源供给和元数据160指定的云130的能力相关。

相比于传统系统的人工过程，系统100利用策略和模型驱动方法来自动部署。系统100可以基于在基础设施属性方面特征化其需求的模型140和策略150将基础设施资源（以元数据属性为特征）动态地（或静态地）优化并结合到应用110。这可以包括将应用元数据匹配到资源元数据以及考虑到策略和上下文，从而在同样不需要人工布置步骤的情形下，使优化的或优选的/标记的应用部署及其云130上的组件/相关性自动化。在一个示例中，系统100允许实例的跟踪，而同样支持这种实例的自动管理（例如，以下所述的自动监控和反馈）。提供不同的技术以摄取、编辑并且设计同样可以描述基础设施模板、应用模型和策略的元数据。这种实例可以被存储在数据库或存储库（未示出）中，连同应用110、应用模型140和策略150一起。

系统100可以采用闭环反馈（参见图4）以用于监控应用。这种监控应用可以基于策略，诸如像放大或缩小应用执行需求，以及通知适合的接收方，诸如用户或系统应用。在一个示例中，监听器可以被安装在各种组件中以从监控捕获事件。由监听器接收的事件可以触发处理器，其可以生成系统上的生命周期管理操作（例如，放大、缩小、移动、去供给、警告用户或系统、运行另一可执行组件，其可能涉及在此所描述的系统的组成以及其它应用等）。

系统100可以在一个或多个硬件平台上被实现，其中系统中的模块可以在一个平台上或跨多个平台被执行。这种模块可以运行在云技术（各种形式/和混合云）上或被供给为SaaS（作为服务的软件），其可以在云上或脱离云被实现。复杂应用可以自动地部署在需求的基础设施上，同样不需要用户理解如何执行这种操作。策略150提供自动指令以用于操作帮助管理者缓解部署错误的指导方针。元数据还可以通过标识应用的类型（例如，经由UI或API）与应用相关联，然后用户不需要理解应用的特性。这种方法基于其与元数据的关联性而允许“最佳实践”、推荐的或施加的用于应用的部署模型。策略还允许从其它上下文考虑分离所述应用特性（例如，关于用户、关于应用、关于基础设施、关于上下文、关于该特定用户、关于该特定应用等）。这促进跨众多应用的应用模型的再次使用。特殊化还可以经由策略实现。例如，这还是系统如何施加，使得特定组的特性值被固定以用于给定应用或版本。例如，系统可以应用通用应用模型以用于网络应用，在又一情形下，明确指定不同的模型或用于模型的属性的某些值。资源还可以从混合云被提供（例如，一些资源从本地数据库和服务器被提供而一些资源从互联网服务被提供）。

出于简化解释的目的，在图1的示例中，系统100的不同的组件被图示和描述为执行不同的功能。然而，本领的技术人员将理解并且认识到，所述组件的功能可以由不同的组件执行，并且数个组件的功能可以在单个组件上被组合和执行。组件可以被实现为，例如，计算机可执行指令、硬件（专用集成电路或处理单元）或实现为二者的组合。在其它示例中，组件可以分布在跨网络的远程设备之间。在一个示例中，拓扑可以被定义，其中应用模板可以包括应用组件应被部署（例如，什么组件将被部署在云中的哪个位置）以用于给定应用的拓扑模型。作为进一步的示例，部署管理器120可以被提供有用于给定应用的拓扑模型（例如，包括各种基础设施资源），并且然后确定在云中基本上与被实例化以用于给定应用的拓扑模型匹配的基础设施资源。在另一个示例中，在供给资源并且部署应用组件以用于给定应用后，则拓扑实例可以被创建以用于给定应用。拓扑实例可以被存储并且用于随后的管理、监控，如在此所公开的。

图2图示了将用于云230的资源能力220与应用的执行需求240相关的部署管理器210的示例。资源能力220可以包括资源供给250，该资源供给250可以来自资源供给池，其由支持云230的多个资源供应商提供。例如，这种资源供给可以包括一个或多个云服务（例如，经由对应的应用程序接口（API）可访问的）、可以实现激活并供给这种服务的现有系统、或现有外部组成（具有函数调用的参数化的工作流程/组成脚本）。资源供给250可以由资源供应商编译/从其摄取。资源能力220还包括资源元数据260，其关联于特征化感兴趣的资源的属性的每个资源供给。例如，这种元数据260可以指定除了其它规范、能力、SLA、调度维持、工作负载（如果已经部分使用）之外的位置/拓扑（例如，用于复合资源）、硬件、CPU、存储器、所包括或支持的操作系统、其它软件方面和标签。资源元数据260可以关联于任何资源，其被资源设计或摄取过程设计或添加到资源池。描述应用模型和资源供给的元数据可以被经由设计者（例如，工具、入口UI或API）捕获以描述所述元数据。包括配方（recipe）（例如，对应于用于部署和诸如非部署（un-deployment）和监控之类的其它生命周期管理功能的指令）的元数据可以构成资源模板。资源元数据260和由元数据指定的相关联的资源供给250可以被提供为可以被其它应用利用的模板（例如，元数据和供给的数据文件）的一部分。

给定应用的执行需求240可以被经由应用元数据270指定，其可以在应用设计时或之后被定义。这可以包括将被单独部署的组件（例如，多个层中的多个应用）。应用元数据260还可以指定资源上的需求/优选。这可以包括作为工作流程或过程（非同步或同步）的通用部署脚本。部署脚本可以进一步包括以用于每个组件的部署指令（例如，在所分配资源上运行的脚本、服务指令等）。这可以包括相关联的指令以部署代理或准备监控和/或管理。指令可以跨组件被应用。通常，应用元数据270可以表示以上相对于图1描述的应用模型。给定应用模型可以被存储在存储器中并且由多个应用利用来促进其部署。如前所述，应用可以包括多个合作组件和工件（例如，资源或可执行和可安装），其被提供有被部署脚本利用的应用。

如所示的，附加策略280可以被提供，其被应用于应用/基础设施并且指出用于操作应用的上下文。例如，策略可以指定用于应用的位置（例如，仅在东海岸服务器上进行操作、时间（例如，在午夜之后并且在早晨6：00之前进行操作）、处理需求（例如，所指定的处理速度和存储器需求）、和/或负载平衡需求（例如，没有服务器将以50%以上的负载进行操作）、SLA、可用性需求（例如，在接下来的x天内没有调度维护）、安全（例如，特定的网络域或安全域）。

应用可以由部署管理器210通过检索相关联的元数据270并且基于最佳匹配（例如，如果被策略施加，则可以精确标记）匹配资源池中的可用资源供给250来部署。资源元数据260到应用元数据270的匹配可以根据严格的规范（例如，处理器必须以1GHZ进行操作），或可以被根据阈值规范匹配（例如，在500 MHZ以上操作的处理器是可接受的）。因此，匹配可以是绝对匹配，或可以是实质匹配，其中匹配是最佳适合或接近期望匹配准则。配方可以由部署管理器210处理并且指出用于应用部署的代码/工件。例如，这种配方可以被经由已知的存储库位置得到或经由指针指出所述配方。例如，当类似的应用元数据由另一应用使用时，对应于应用的复合资源的拓扑可以被部署管理器210保存为新的资源类型以便再次使用。例如，相同应用或类似应用的多次发布可以再次使用相同应用的元数据，但采用不同的策略以涉及操作上下文。

图3图示了用于应用的自动部署和监控的示例系统300。系统300包括执行引擎310以用于应用的自动部署。这种引擎还可以包括供给管理器以便与服务供应商建立服务等级协议，并且可以包括以上所述的部署管理器。事件处理器和调度器可以314被利用以便处理应用事件并且调度与应用相关联的任务。如前所述，监听器/处理器可以被定义和安装以用于监控事件。这可以包括调度供给/部署并且跟踪生命周期管理操作（例如，今晚或在接下来的2周部署）。配置监控器320和规则引擎可以被采用以用于配置提供来自应用的反馈的监控器组件324，并且用于应用规则和策略以用于执行所述应用。系统300包括模型数据库330，其例如可以包括应用模型、基础设施模型、和工件指针。实例数据库334可以被采用以存储应用的所实现的目标实例。应用用户接口340可以被采用以设计应用并且配置元数据以用于操作所述应用，然而基础设施用户接口244可以被采用以指定基础设施需求。部署组件350可以包括部署应用编程接口（API）和指令，诸如像可以被经由部署配方来指定。一个或多个调出354可以指定定制的操作指令以用于给定应用。供给组件360可以包括供给API和插件，以用于与各种云基础设施组件交互。

系统300可以被用作设计者工具以构建/部署基础设施和应用模板。其还允许应用开发者、测试者、或其他管理者或设计者来构建应用模型。类似地，他们可以设计策略和规则以用于执行和部署。基础设施和应用数据中的一些或全部可以被摄取到存储库中，其分别被示作数据库330和340。替代地，这种基础设施或应用数据可以被经由API传送。应用工件（代码、可执行、安装包等）还可以被经由数据库或API摄取或指出。例如，API或入口用户接口340和344可以被用于关联或更新要匹配和部署的请求，同时还指示要使用的应用模板和策略。这种API和用户接口可以被实现为先前所述设计者工具的部分，以定义元数据并且关联到基础设施（例如，经由基础设施模板和拓扑）。

可以提供代理和监控工具的准备和设置，使得应用可以发现实例（其已被仪表化并具有代理（如果需要的话））。这可以被经由指令/配方来实现，其被用于在将应用和其相关联的组件结合到基础设施资源之后部署基础设施和应用元件。事件/报告允许闭环反馈，其可以被用于放大/向外缩放（基于策略）或更新上下文/策略以用于未来的变化（如果被策略允许）以及通知适合的当事人或系统（参见图4和以下的描述）。如上所指出的，云和资源池可以是混合实体，其中一些资源被本地服务而一些被远程服务。对于可以支持自动缩放、工作负载管理以及保障/监控事件的处理的云或硬件资源，应用可以被自身管理（例如，利用反馈来确定性能、改变执行需求、并且产生警告（如果必要））。

图4图示了将闭环反馈用于应用的部署和监控的示例系统400。系统400包括处理单元410（或处理器），其执行来自存储器414的指令，所述存储器414包括固件或其它存储介质以用于存储与计算机相关联的计算机可执行指令。处理单元410和存储器414可以被提供为部署工具420的一部分，所述部署工具420经由部署管理器450在云基础设施440上部署应用430。如所示的，反馈460被从部署的应用430接收，并且由监控器组件470处理。这种反馈460可以是来自所部署应用430的指示应用如何执行的状态或事件。在一个示例中，反馈460可以被采用以调整所部署的应用430的操作参数，其已被根据之前所确定的执行需求来设置。例如，前台任务可以被调整，使得任务在与当前正执行的相比不同数目的毫秒上进行操作。这可以包括放大或缩小部署的应用430的操作需求。在另一个示例中，反馈460可以被采用以调整云基础设施440的操作基础设施。例如，服务水平协议可以被与云基础设施服务供应商自动再次协商来增加或减少可用资源，以恰当地满足所部署应用430的操作需求。

计算机480可以操作一个或多个接口484以对应用模型490进行编程并且被存储在数据库494中。计算机还可以与部署工具420交互以改变部署并且促进应用的生命周期管理。接口484还可以配置基础设施模板，改变操作需求，配置监控器组件470，并且与系统400内生成的事件和警报进行交互。如前所述，连同在云上被执行的，所部署的应用430可以跨不相关的云延伸，或被提供为混合引用的一部分。例如，所部署的应用430可以在云基础设施440上部分地被执行，并且在作为与云不同的实体（例如，本地服务器数据库对网络数据库）的数据库494上部分地被执行。

鉴于以上所述的之前结构和功能特征，示例方法将被参考图5更好地认识到。尽管出于解释简单的目的，图5的示例方法被示出和描述为串行执行，但将被理解和认识的是，本示例不被图示的顺序限制，如在其它示例中的一些动作可以以不同的顺序发生和/或与在此所示和描述同时地发生。此外，不必所有描述的动作都被执行以实现方法。图5的示例方法可以被实现为机器可读指令，其可以被存储在非临时性计算机可读介质中，诸如，可以是计算机程序产品或其它形式的存储装置。对应于图5的方法的计算机可读指令还可以被从存储器访问并且由处理器执行（例如，图4的处理单元410）。

图5图示了用于应用的自动部署的示例方法500。在510，方法500包括处理应用元数据，其对给定应用进行建模（例如，经由图1的部署管理器120）。方法500包括处理资源元数据，其描述用于云的网络资源以执行给定应用（在520）。在530，方法500包括将应用元数据与资源元数据匹配以确定用于所述云上的给定应用的拓扑。在540，方法500包括基于所确定的用于云的部署状况来部署给定应用。尽管未示出，但所述方法还可以包括监控来自给定应用的反馈（例如，用于放大或缩小用于所述应用的资源、启动/停止应用、移动应用、启动补救或支持流程以修复所检测的问题的反馈）。

方法500可以作为诸如图4中所描述的示例的系统的一部分而被自动执行。系统可以包括用于存储与计算机相关联的计算机可执行指令的存储器以及用于访问存储器、执行计算机可执行指令并且从而执行所述方法500的处理单元。计算机可执行指令可以包括存储在存储器中的应用模型，以特征化用于在云基础设施上部署的给定应用，其中所述应用模型可以被应用元数据描述。在存储器中存储的部署管理器可以分析用于给定应用的应用元数据和与给定应用相关联的策略，从而确定云基础设施中的基础设施资源。基础设施资源可以被指定为资源元数据，其中所述部署管理器将应用元数据与资源元数据自动相关从而满足执行需求。监控器组件可以被采用部署管理器实现，以读取来自给定应用的反馈，并且使得部署管理器能够调整给定应用或基础设施资源。

图6图示了用于云应用的自动部署的示例部署系统600。系统600包括应用模型610以特征化用于在云基础设施上部署的给定应用620，诸如以上相对于图1所示出的。部署管理器630基于与给定应用相关联的应用模型610和策略640分析用于给定应用620的执行需求，从而确定云基础设施中的基础设施资源以满足执行需求。

已经在上面描述的是示例。当然，不可能描述组件或方法的每个可想到的组合，但本领的技术人员将认识到许多进一步的组合和变更也是可能的。相应地，本发明旨在包含所有这种落入到包括所附权利要求的本申请的范围内的改变、修改和变化。此外，在本公开或权利要求叙述“一”、“一个”、“第一”或“另一”元件或其等价物的情形下，应认为包括一个或多于一个的这种元件，既不需要也不排除两个或更多的这种元件。如在此所使用的，术语“包括”意味着包括但不限于，以及术语“包含”意味着包含但不限于。术语“基于”意味着至少部分地基于。

Claims (15)

1.一种系统，包括：

应用模型，被存储在存储器中，用于特征化用于云上的部署的给定应用；以及

部署管理器，对应于可由处理器执行的指令，用于基于与给定应用相关联的应用模型和策略分析用于给定应用的应用需求，以实质上匹配云中的基础设施资源，从而满足应用需求。

2.如权利要求1所述的系统，其中部署管理器用于在云上自动部署给定应用。

3.如权利要求1所述的系统，其中部署管理器用于生成指令以通知另一系统或用户如何在云上部署给定应用。

4.如权利要求1所述的系统，进一步包括设计者工具以定义用于基础设施资源和应用需求的元数据。

5.如权利要求4所述的系统，其中设计者工具经由应用元数据定义应用模型，其包括要被单独部署的组件的描述、用于资源的需求或优选、或部署脚本中的至少一个。

6.如权利要求5所述的系统，其中部署脚本包括以下中的至少一个：用于组件的部署指令、用于准备部署代理的指令、用于监控的指令、用于管理的指令、或跨组件应用的指令。

7.如权利要求6所述的系统，其中基础设施资源被经由资源元数据指定，其指定哪些资源供给是可用的或能够供给给定服务的现有系统。

8.如权利要求7所述的系统，其中资源元数据进一步指定以下中的至少一个：位置、拓扑、硬件资源、维持能力、操作系统需求或标签。

9.如权利要求1所述的系统，进一步包括监控器组件以读取来自给定应用的反馈，并且将所述反馈供应到所述部署管理器。

10.如权利要求9所述的系统，其中部署管理器执行基础设施模板和应用模型的动态结合，以将云中的资源实质上匹配到给定应用。

11.如权利要求9所述的系统，其中部署管理器利用反馈来执行相关动作或将该相关动作委托到另一模块。

12.一种方法，包括：

由计算机处理应用元数据以对给定应用进行建模；

由计算机处理资源元数据以描述用于云的基础设施资源从而执行给定应用；

由计算机将应用元数据与资源元数据匹配，以确定用于在云上部署给定应用的拓扑；以及

由计算机基于所确定的拓扑在云中部署给定应用。

13.如权利要求12所述的方法，进一步包括监控来自给定应用的反馈以改变给定应用在云中的部署。

14.一种系统，包括：

存储器，用于存储与计算机相关联的计算机可执行指令；以及

处理器单元，用于访问存储器并执行计算机可执行指令，所述计算机可执行指令包括：

应用模型，被存储在存储器中，用于特征化用于云基础设施上的部署的给定应用，其中所述应用模型由应用元数据描述；以及

部署管理器，被存储在存储器中，用于分析用于给定应用的应用元数据和与所述给定应用相关联的策略，从而确定云基础设施中的基础设施资源，其中所述基础设施资源被指定为资源元数据，并且所述部署管理器将应用元数据与资源元数据自动地实质上匹配，以满足由应用元数据和与给定应用相关联的策略指定的应用需求。

15.如权利要求14所述的系统，进一步包括监控器组件，用于读取来自给定应用的反馈，并且使部署管理器能够调整给定应用或基础设施资源。