基于模式方法的云计算

分享到

基于模式方法的云计算

作者:Dustin Amrhein，Ted Kirby，Brian Stelzer,发布于2011-12-27

简介： IBM® Workload Deployer 是一种云管理设备，它提供了一种基于模式的方法，可在云中部署和管理应用程序环境。从用户的角度来看，部署有意义的应用程序环境意味着能够定制以满足其特定需求。考虑到该需求，IBM Workload Deployer 提供了一些可满足广泛定制需求的实用工具。本文将重点讨论为用户提供的新虚拟应用程序部署模型的定制功能。

减少部署时间，提高一致性以及促进灵活性，这些都是您在为中间件应用程序环境探索基于云的方法时所期望实现的优势。构建这些环境的传统方法通常即耗时又耗资源，常常需要多个人花费数周的时间来完成此项构建工作。

此外，由于涉及的步骤较多，复杂性较高，因此很难实现一致的配置结果。除了在最近 10 年不断增加 IT 成本，这些挑战使企业无法获得他们在当今瞬息万变的消费市场中所需的灵活性。

走进 IBM? Workload Deployer。该创新的解决方案（基于其前身 WebSphere® CloudBurst Appliance）能够处理这些传统问题，它可以快速、重复、高效地部署云中间件环境。

基于模式的方法是 IBM Workload Deployer 的基础部分和所提供的优势。使用云管理设备，您可以构建和部署模式来表征您配置完整的应用程序环境。这些模式源自虚拟镜像，使您能够将整个（通常是复杂的）环境表征为一个单一的可部署单元。

当您已经准备好使用一个特定的应用程序环境时，您只需选择一个模式并进行部署。IBM Workload Deployer 会自动对环境中的各种虚拟机进行部署、配置和集成，并在数分钟内交付完整的产品。

除了前所未有的速度这一明显优势外，一致的模式还能保证从部署到部署保持一致的结果，使您能够将更多的时间用于您的应用程序，花费更少的时间确认支持环境配置是否正确。

为了促进该技术快速普及，IBM Workload Deployer 还附带一组预构建的虚拟镜像、虚拟系统模式和虚拟应用程序模式。您可以立即实现部署，并且快速、一致地交付通用的中间件应用程序环境也能使您从中获益。

然而，创建您自己的自定义模式将进一步增加您从该方法获得的价值。在这方面，IBM Workload Deployer 针对它支持的两种模式模型提供全面的定制技术。

IBM Workload Deployer 继承了其先身 WebSphere CloudBurst 的虚拟系统模式。尽管产品名称已经更改，但是定制此类模式的基本概念和技术依然保持不变。在本文中我们将不再对这些定制技术进行讨论，但是您可以参考 developerWorks 系列文章使用 WebSphere CloudBurst 实现定制，深入了解此类模式的各种定制方法。

本文的其余部分将重点讨论 IBM Workload Deployer 中的虚拟应用程序模式的定制，并在结尾提供此类定制的示例。

自定义虚拟应用程序模式

虚拟应用程序模式是 IBM Workload Deployer V3 引进的新部署模型。此类模式采取了完全以应用程序为中心的方法构建、部署和管理云中的中间件应用程序环境。

您可以通过提供应用程序并指定该应用程序的功能性和非功能性需求来构建一个虚拟应用程序模式。IBM Workload Deployer 采用您的输入并将其转换成一个安装、配置和集成完善的中间件应用程序环境，如图 1 所示。

图 1. IBM Workload Deployer 中的虚拟应用程序方法

作为虚拟应用程序模式的用户，您无需了解如何安装、配置或集成中间件和应用程序，因为这些模式囊括了这些知识。这些模式是如何做到的呢？这都是通过插件实现的。

虚拟应用程序模式中插件的作用

图 2 所示的针对 Web 应用程序的 IBM Workload Deployer Pattern 示例强调了一个虚拟应用程序模式中的主要组件。

图 2. 虚拟应用程序模式示例

正如您所看到的，虚拟应用程序模式是由组件、链接和策略组成的：

组件：表示给定工作量的功能配置。在针对 Web 应用程序的虚拟应用程序模式中，提供用于企业应用程序（EAR 文件）、Web 应用程序（WAR 文件）、数据库、OSGI 应用程序等的组件。这些组件提供了您要构建和部署的环境的重要组成部分。
链接：表示虚拟应用程序模式中组件之间的集成点。在图 2 所示的模式中，链接指定该企业应用程序依赖于该模式中的数据库组件。
策略：如图 2 所示的 Scaling Policy 允许您为您自己的应用程序环境指定功能性和非功能性需求。策略规定环境的配置和持续管理方面。

当您构建和部署虚拟应用程序模式时，您可以以图 2 所描述的形式与可视化编辑器进行交互。从终端用户的角度来看，这使您能够轻松构建和部署一个配置完善、集成式的动态云计算环境。

需要提供虚拟应用程序模式暗示和封装的功能，这是插件出现的原因。虚拟应用程序模式提供的所有安装、配置、集成和管理功能均来自于插件或插件集。插件定义为虚拟应用程序模式的用户提供组件、链接和策略，并提供必要的功能来支持这些元素。

好消息是，IBM Workload Deployer 拥有一个开放的设计，允许您将自己的插件添加到系统中。为什么这很重要？因为，如果您想要创建自己的虚拟应用程序模式类型以应对定制软件上的定制工作量，或者您想要扩展 IBM Workload Deployer 提供的虚拟应用程序模式之一，那么您就需要开发一个或多个自定义插件。

在本文中，我们将重点讨论创建一个自定义插件的过程，该插件可扩展针对 Web 应用程序的 IBM Workload Deployer Pattern 并提供 WebSphere? Application Server Community Edition 支持。此示例将提供插件的整体架构的背景、IBM 推出的新插件开发工具包 (Plug-in Development Kit) 的用法，以及您可采用的将您的自定义插件添加到 IBM Workload Deployer 的方式。让我们开始吧！

插件的构成

在我们创建自定义插件以便为 WebSphere Application Server Community Edition 提供支持之前，您需要了解插件的构成。一个典型的插件由 6 个配置点构成：

部署之前，在 config.json 文件中定义插件的整体定义。
在部署时，将应用程序模型转化为一个未定义的拓扑。
将未定义的拓扑转化为定义的拓扑。
配置所需的资源，并将定义的拓扑转化为最终拓扑。
实际部署到私有云中。
安装、配置并启动已部署虚拟机上的软件。

预部署

插件的整体定义是由 config.json 配置文件定义。config.json 文件包含以下信息：

要安装的软件包（中间件或其他软件）。
基本硬件要求（例如，32 位与 64 位的虚拟机主机的安装软件包）。
插件名称、版本和关联的模式类型。

Virtual Application Builder 工具用于构建您的虚拟应用程序模式。该模式由组件、链接和策略构成，其中各项均在名为 metadata.json 的插件配置文件中定义。metadata.json 文件为每个组件、链接和策略定义下列各项：

用在 Virtual Application Builder 中图形化表示插件的名称、描述和图标。
稍后在部署虚拟机上配置软件包时使用的可配置属性。

部署

Virtual Application Builder 会接受您使用 metadata.json 定义信息创建的模式，并创建一个应用程序模型；图 2 是图形化一个由组件、链接和策略组成的应用程序模型的示例。然后再逐步阐述该应用程序模型，直到最后部署开始。IBM Workload Deployer 演示了这些步骤的执行过程。

部署流程的第一步是将应用程序模型转换成未定义的拓扑。未定义的拓扑具有通用性，它提供了关于要包括哪些软件包以及内存和磁盘要求等信息。该转换过程会使用您定义的 <template>.vm。

第二步是接受未定义的拓扑，并将其转换成定义的拓扑。config.json 文件包含完成该流程所需的转换数据。该流程的一个重要部分是将应用程序模型的要求（操作系统、架构、磁盘、内存）映射到插件提供的组件。

第三步是创建最终拓扑。IBM Workload Deployer 将接受已定义拓扑文件，提供任何所需的资源，并编写最终拓扑文件。

第四步是实际部署到私有云。该部署流程和各个步骤所需的相应配置文件如图 3 所示。

图 3. 从创建插件到将插件部署到私有云

第五步（也是最后一步）是安装、配置并启动已部署虚拟机上的软件。通过为要安装的每个软件组件定义一系列的生命周期脚本来完成此步骤，这些脚本包括：install.py、configure.py 和 start.py。

part和nodepart

在深入了解本文的自定义插件创建部分之前，需要讨论一下 part 和 nodepart，因为这两者在以后的章节中非常重要。

插件中的软件包可以包括 part 和 nodepart。每个 part 和 nodepart 对应一个特定的构件（如软件产品）。从技术角度来看，part 和 nodepart 实际上是同一事物，因为它们都是用来安装、配置和启动软件的。

从逻辑的角度来看，nodepart 通常用于安装、配置和启动系统级软件，如防火墙。而 Part 则是用于安装、配置和启动中间件类软件，如 WebSphere Application Server Community Edition。

创建自定义插件

在本文的其余部分，我们将详细讨论创建自定义插件以便为在 WebSphere Application Server Community Edition (WAS CE) 上运行的企业应用程序 (EAR) 和 Web 应用程序 (WAR) 文件提供支持的流程。作为一般概述，我们将涵盖以下步骤：

定义和包装插件构件。
定义要出现在 Virtual Application Builder 中的可配置的应用程序模型组件。
定义要将应用的可视化模型转换成物理模型的模板。
定义用于在已部署的虚拟机上安装、配置和启动软件的生命周期脚本。

定义和封装插件构件

我们将讨论可用于快速封装插件构件的选项，但是无论您决定使用哪种封装机制，您都需要指定插件文档里的 config.json 文件中的构件信息。清单 1 显示了我们的 WASCE 插件的 config.json 文件。

清单 1. 我们的 config.json 定义文件

{

"name" : "wasce",

"version" : "1.0.0.1",

"patterntypes": {

"primary" : { "webapp":"1.0" }

"packages" : {

"WASCE" : [ {

"requires" : {

"arch" : "x86_64",

"memory" : 512,

"disk" : 300

"parts":[ {

"part" : "parts/wasce.tgz",

"parms" : {

"installDir" : "/opt/wasce"

}

} ],

"WASCE_SCRIPTS":[ {

"parts":[ {

"part":"parts/wasce.scripts.tgz"

} ]

}

config.json 文件是插件中所需的惟一的文件。name、version 和 patterntypes 元素都是必需的：

name 元素指定插件名称。
version 元素定义插件的版本号。
patterntypes 元素指定与插件相关的模式类型。

我们的 WASCE 插件通过将 webapp 指定为 patterntypes 值来扩展 IBM Workload Deployer for Web Applications 模式。这意味着我们在通过与 IBM Workload Deployer 一起提供的 Web 应用程序模式创建模式时，可使用我们定义的这些组件。

requires 元素为您提供了一种方法指定插件所部署的虚拟机所需的操作系统和位架构配置。对于我们的插件，我们指定 64 位 x86 架构的虚拟机。

memory 和 disk 元素指定您的插件所定义的每个软件包的磁盘和内存的最低要求。在配置过程中，IBM Workload Deployer 将追加每个软件包的最小值，并配置满足指定要求的虚拟机。

packages 元素与 part 和 nodepart 元素一起定义文件包。我们的插件提供了两个软件包：WASCE 和 WASCE_SCRIPTS。WASCE 软件包包含了 parts/wasce.tgz part 文件。该文件包含了安装 WebSphere Application Server Community Edition 所需的二进制文件，我们将其直接封装在插件中。

有其他选项可用于指定所需的二进制文件。您可以定义一个文件属性，并让管理员在加载了 IBM Workload Deployer 中的插件后上传所需的二进制文件。您还可以链接到存储了所需构件的远程服务器。WASCE_SCRIPTS 软件包提供将 WASCE 镜像安装到所需位置，安装 EAR 或 WAR 文件并启动服务器所需的生命周期脚本。

定义可配置应用程序模型组件

忽略图标图形的创建，这一步骤非常简单。Web 和企业应用程序是我们想在 Virtual Application Builder 中展示给用户的组件。因此，我们在位于插件文档的 plugin/appmodel 目录中的 metadata.json 文件中指定这两个组件。清单 2 展示了定义 Web 文档组件的 JSON。

清单 2. 指定 Web 文档组件

[

"id" : "WARCE",

"label" : "Web Application (WebSphere Application Server

Community Edition)",

"description" : "A web application cloud component represents an execution

service for Java EE Web applications (WAR files).",

"type" : "component",

"thumbnail" : "appmodel/images/WASCE.png",

"image" : "appmodel/images/WASCE.png",

"category" : "application",

"attributes" : [

{

"id" : "archive",

"label" : "WAR File",

"description" : "Specifies the web application (*.war) to

be uploaded.",

"type" : "file",

"required" : true,

"extensions" : [ "war" ]

}

]

企业文件组件也有类似的一节用在其可下载文件。清单的第一个 type 字段非常重要。该字段的值选项包括 component、link 或 policy，这定义了应用程序模型的类型。我们组件的 id 是 WARCE。只要保证惟一性，它可以是任何值。category 表示一个选项卡，该组件在 Virtual Application Builder 中的调色板上的该选项卡下显示。attributes 阵列定义您定义的组件的属性。当用户在 Virtual Application Builder 中使用该组件时，将看到并能够为这些属性指定值。属性 type 包括 file、string（如此处所示）、number、Boolean、array 和 range。

定义将可视化模型转换为物理模型的模板

插件必须定义如何实施或实现定义组件的部署。在我们的示例中，我们需要说明部署企业或 Web 应用程序组件的意义。

为此，我们提供单一的转换，将用户在 Virtual Application Builder 中构建而衍生的应用程序模型转换成具体的拓扑。清单 3 显示了用于转换的 JSON 文件的一个片段。每个组件和链接都必须进行转换。在我们的插件里，我们的 WARCE 和 EARCE 组件共享同一个转换模板。

清单 3. 转换模板

{

"vm-templates":[

{

"name" : "${prefix}-wasce",

"packages" : [ "WASCE", "WASCE_SCRIPTS" ],

"roles" : [

{

"plugin" : "$provider.PluginScope",

"name" : "WASCE",

"type" : "WASCE",

"quorum" : 1,

"external-uri" : [{"ENDPOINT":"http://{SERVER}:8080"}],

"parms":{

"ARCHIVE" : "$provider.generateArtifactPath( $applicationUrl,

${attributes.archive} )"

"requires" : { "memory":512, "disk":300 }

}

"scaling" : { "min":1, "max":1 }

}

]

}

拓扑片段是一个 JSON 对象，包含 vm-templates 元素，该元素是一个 vm 模板阵列。vm 模板是虚拟机模板；它定义要部署的虚拟机的 parts、nodeparts 和 attributes。对于该示例，我们只需要一个包含四个重要元素的 vm 模板：

name：已部署虚拟机的惟一名称。
packages：这指定安装在每个已部署虚拟机上的 parts 和 nodeparts。WASCE 条目表示使用我们的 WASCE 虚拟镜像，WASCE_SCRIPTS 条目指定 WASCE 生命周期脚本（我们下一步将对其展开讨论）。
roles：插件中的 parts 为 roles 调用生命周期脚本。在您的插件中可以有一个或多个 roles，但是在我们的实例中，我们只有一个 WASCE 角色。当一个节点上的所有 roles 都进入 RUNNING 状态，节点本身则进入绿色 RUNNING 状态。

定义安装、配置和启动软件的生命周期脚本

现在，我们已经准备好为我们的插件定义生命周期脚本。总体而言，我们将编写用于安装、配置和启动我们的插件组件的脚本。您可以在可下载文档中查看完整的脚本，但是我们在这里将强调某些关键构件。

wasce install.py

install.py 脚本将我们的 WASCE 镜像从下载位置复制到要求的 installDir。它还在环境中为后续脚本设置 installDir 值。

IBM Workload Deployer 代理安装的所有 parts 和 nodeparts 都将以 root 用户的身份来运行。chown -R virtuser:virtuser 命令将已安装内容的文件所有权更改为要求的用户和组。

最后，install.py 脚本在 WebSphere Application Server Community Edition 的 bin 目录可执行文件中制作脚本。清单 4 显示了 install.py 脚本的内容。

清单 4. WASCE install.py 脚本

installDir = maestro.parms['installDir']

maestro.trace_call(logger, ['mkdir', installDir])

if not 'WASCE' in maestro.node['parts']:

maestro.node['parts']['WASCE'] = {}

maestro.node['parts']['WASCE']['installDir'] = installDir

# copy files to installDir to install WASCE

this_file = inspect.currentframe().f_code.co_filename

this_dir = os.path.dirname(this_file)

rc = maestro.trace_call(logger, 'cp -r %s/files/* %s' % (this_dir, installDir),

shell=True)

maestro.check_status(rc, 'wasce cp install error')

rc = maestro.trace_call(logger, ['chown', '-R', 'virtuser:virtuser', installDir])

maestro.check_status(rc, 'wasce chown install error')

# make shell scripts executable

rc = maestro.trace_call(logger, 'chmod +x %s/bin/*.sh' % installDir, shell=True)

maestro.check_status(rc, 'wasce chmod install error')

清单 4 显示了脚本如何使用插件框架内提供的 maestro 模块。该模块提供了一些辅助方法，可在安装和其他方面提供帮助。

Wasce.scripts install.py

wasce.scripts 部件还包含一段 install.py 脚本。该脚本安装我们的 WebSphere Application Server Community Edition 生命周期脚本。

清单 5. wasce.scripts install.py 脚本

# Prepare (chmod +x, dos2unix) and copy scripts to the agent scriptdir

maestro.install_scripts('scripts')

wasce.scripts configure.py

wasce.scripts 部件中的 configure.py 脚本将用户提供的应用程序安装到 WebSphere Application Server Community Edition。该脚本利用 WebSphere Application Server Community Edition 的 hot deploy 功能，并简单地将应用二进制文件复制到被监控目录。清单 6 显示了 configure.py 脚本的内容。

清单 6. configure.py 脚本

installDir = maestro.node['parts']['WASCE']['installDir']

ARCHIVE = maestro.parms['ARCHIVE']

archiveBaseName = ARCHIVE.rsplit('/')[-1]

# Use hot deploy

deployDir = os.path.join(installDir, 'deploy')

if os.path.exists(deployDir) == False:

# Make directories

os.makedirs(deployDir)

deployFile = os.path.join(deployDir, archiveBaseName)

# Download WASCE archive file

maestro.download(ARCHIVE, deployFile)

wasce.scripts start.py

wasce.scripts 部件中的 start.py 脚本负责启动 WebSphere Application Server Community Edition 流程。在启动了该流程后，这段脚本将角色的状态更新到 RUNNING。一旦部署进入了 RUNNING 状态，您便可以访问已部署的应用程序环境。清单 7 显示了使用 geronimo.sh start 命令启动 WebSphere Application Server Community Edition，以及使用 gsh.sh 命令等待启动。

清单 7. start.py 脚本

wait_file = os.path.join(maestro.node['scriptdir'], 'WASCE', 'wait-for-server.txt')

installDir = maestro.node['parts']['WASCE']['installDir']

rc = maestro.trace_call(logger, ['su', '-l', 'virtuser', installDir +

'/bin/geronimo.sh', 'start'])

maestro.check_status(rc, 'WASCE start error')

logger.info('wait for WASCE server to start')

rc = maestro.trace_call(logger, ['su', '-l', 'virtuser', installDir + '/bin/gsh.sh',

'source', wait_file])

maestro.check_status(rc, 'wait for WASCE server to start error')

maestro.role_status = 'RUNNING'

logger.info('set WASCE role status to RUNNING')

logger.debug('Setup and start iptables')

maestro.firewall.open_tcpin(dport=1099)

maestro.firewall.open_tcpin(dport=8080)

maestro.firewall.open_tcpin(dport=8443)

构成插件的还有其他脚本和构件，但是这些是其中最重要的。您可以通过在本文的底部下载插件浏览插件的完整内容。

Eclipse 插件汇总

图 4 显示了我们的 wasce 插件的所有组成部分，如在 Eclipse 中的 Package Explorer 视图所见。

图 4. wasce 插件的所有组成部分

安装和使用插件

构建 WebSphere Application Server Community Edition 插件，将其内容封装在 .tgz 文件中。完成封装后，您便可以将新插件加载到 IBM Workload Deployer 信息库中。加载完成后，您可以使用新插件中的组件来创建和部署虚拟应用程序模式。（参见参考资料一节中的 IWD Plug-in Development Kit，了解如何获得和使用免费的 PDK 来执行该步骤的指南。）

加载插件

要加载插件：

打开 IBM Workload Deployer 用户界面。
从页面顶部的各个菜单中选择 Cloud 菜单并单击 System Plug-ins 链接。
单击绿色的 + 图标，上传 .tgz 文件。在加载完该文件后，您可以查看如图 5 所示的插件属性。

图 5. 导入的插件定义

如图 5 所示，wasce 插件显示了您定义的 Enterprise Application 和 Web Application 组件。

使用新插件

既然已经完成了加载新插件，现在您可以使用其组件来创建新的虚拟应用程序模式。要实现这一点，请使用 IBM Workload Deployer 中的 Virtual Application Builder。

单击顶部工具栏上的 Patterns 菜单，然后点击 Virtual Applications 链接。
单击绿色的 + 图标，创建一个新模式。如图 6 所示，确保模式类型为 Web Application，并选择空白模板。

图 6. 创建新的虚拟应用程序模式

单击 Start Building 按钮，进入 Virtual Application Builder。
进入 builder 后，扩展 Application Components 部分。基于 WebSphere Application Server Community Edition 服务器，您应该看到 Enterprise Application 和 Web Application 组件。您可以将这些组件拖放到 canvas，将其添加到您的模式。图 7 显示了新的 Web Application 组件的用法。

图 7. 使用新组件

根据插件中组件的定义，有 Name 和 WAR File 两个属性。这两个属性都是必需的，WAR File 属性包含文件上传对话框。在完成了新模式的创建后，单击 Virtual Application Builder 顶部的 Save 或 Save As 按钮进行保存。此时，您便可以部署新模式。（如需了解更多信息，请参见参考资料一节中的 wasce 示例安装包下载。）

部署自定义虚拟应用程序模式

选择 Patterns 菜单并点击 Virtual Applications 链接，返回虚拟应用程序模式页面。
从屏幕左侧的列表选择您的新虚拟应用程序模式。
单击 Deploy to Cloud 图标，选择合适的云组，然后单击确定。

IBM Workload Deployer 将开始部署环境，它将自动调用您在插件中提供的生命周期脚本，来安装、配置和启动环境。

查看已部署的应用程序

要监控部署流程，选择 Instances 菜单，然后单击 Virtual Applications 链接。部署中的每个虚拟机都将有一个关联的状态。对于 Web Application 或 Enterprise Application 虚拟机，每当部署状态达到 RUNNING 状态时都应出现 Endpoint 链接，如图 8 所示。

图 8. 监控部署流程