没有合适的资源?快使用搜索试试~ 我知道了~
IBM:registered:WorkloadDeployer是一种云管理设备,它提供了一种基于模式的方法,可在云中部署和管理应用程序环境。从用户的角度来看,部署有意义的应用程序环境意味着能够定制以满足其特定需求。考虑到该需求,IBMWorkloadDeployer提供了一些可满足广泛定制需求的实用工具。本文将重点讨论为用户提供的新虚拟应用程序部署模型的定制功能。减少部署时间,提高一致性以及促进灵活性,这些都是您在为中间件应用程序环境探索基于云的方法时所期望实现的优势。构建这些环境的传统方法通常即耗时又耗资源,常常需要多个人花费数周的时间来完成此项构建工作。此外,由于涉及的步骤较多,复杂性较高,因此很难实现一致的配
资源推荐
资源详情
资源评论
基于模式方法的云计算基于模式方法的云计算
简介:简介: 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) 文件提供支持的流程。作为一般概述,我们将涵盖
以下步骤:
1. 定义和包装插件构件。
2. 定义要出现在 Virtual Application Builder 中的可配置的应用程序模型组件。
3. 定义要将应用的可视化模型转换成物理模型的模板。
4. 定义用于在已部署的虚拟机上安装、配置和启动软件的生命周期脚本。
定义和封装插件构件
我们将讨论可用于快速封装插件构件的选项,但是无论您决定使用哪种封装机制,您都需要指定插件文档里的
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"
} ]
} ]
} ]
}
}
剩余22页未读,继续阅读
资源评论
weixin_38718223
- 粉丝: 11
- 资源: 930
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功