websphere配置
本文介绍了从开发到生产的迁移策略以及IBM®WebSphere®DataPower SOA Appliance（DataPower）配置的升级。 本文包括示例配置，迁移方法和自动升级技术。
这个由两部分组成的系列的第1部分描述了DataPower配置管理，并且是IBM Press出版的WebSphere DataPower SOA Appliance Handbook中第15章“构建和部署技术”的附录。 有关DataPower和本文中描述的概念的更多信息，请参见本文底部的参考资料部分 。 同样在本文的底部，您可以下载用于DataPower配置和ANT（另一个Neat Tool）迁移和构建的脚本。
DataPower设备用于实现高级安全性，中介和集成模式。 DataPower功能是广泛的，并通过配置服务和对象（通过设备的管理界面）来实现。 必须以受控方式对这些配置进行更改，以确保生产环境中的服务质量。 这些更改从早期开发到测试，再到最终到生产的迁移被称为软件开发生命周期（SDLC）。
第1部分描述了许多与配置内容管理以及如何避免在特定SDLC环境中关联配置有关的问题。 例如，使用主机别名对象，静态主机DNS条目以及使用XML文档外部化静态XSLT信息作为避免在配置中创建环境亲和力的简单策略，已被提出。 当迁移配置时，这些关联通常会引起问题。 服务可能在开发中的特定TCP端口上公开，但是当对该服务进行单元测试或在生产中安装时，可以使用另一个端口。
通过介绍三种简单的服务，本文介绍了通过SDLC进行的配置迁移以及可以用来调解它们的常见问题和工具。 部署策略（在DataPower固件版本3.6中引入）将在迁移过程中显示为一种强大的配置属性修改方法。 本文还介绍了用于处理密钥和证书以及XML和XSLT文档的策略。 通过使用ANT脚本，本文说明了如何将迁移生命周期集成到自动化过程中。
样本配置
该示例配置包含三个XML防火墙服务对象。 BookServiceRouter接受通过HTTPS进行图书查询和购买的请求，然后根据传入URL的内容将这些请求路由到BookService1或BookService2。 BookService1具有较高的优先级，并且购买请求被路由到该服务器，而优先级较低的请求被路由到BookService2。
图1显示了该体系结构。 在典型的拓扑中，图书服务将位于另一台设备或目标位置，但是在这里，为简单起见，它们也托管在单个设备上：
图1.示例应用程序
路由确定基于一个文档（identityDocument.xml），该文档包含将请求转发到的服务的IP地址和端口。 它包含在样式表（local：///BookServiceRouter.xsl）中，该样式表在BookServiceRouter防火墙策略内的Route动作中标识。 这种简单的技术可以将来自XSLT的静态（可能是特定于环境的信息）外部化。 由于identityDocument.xml可以与XSLT分开维护，因此它允许进行与环境无关的配置。 您可以在第1部分中了解有关此技术的更多信息。
identityDocument.xml文档以及其中的地址和端口对于每个环境都是唯一的。 有一个用于开发的identityDocument.xml使用开发中的XML防火墙服务正在侦听的端口。 测试中有一个identityDocument.xml，用于标识测试环境中使用的地址和端口，依此类推。 此技术提供了一种与环境无关的路由机制。
但是，必须使用特定于每个环境的地址和端口来定义服务本身。 开发中的BookServiceRouter XML防火墙将侦听端口3100上的请求，但是“测试”中的BookServiceRouter防火墙必须使用其他端口。 您会看到如何使用部署策略来管理诸如此类的问题。
此配置托管在名为BookService的DataPower应用程序域中。 第1部分描述了应用程序域如何将其配置存储在设备文件系统中，或者可以定义为从设备外位置（例如，软件配置管理（SCM）系统）中获取其配置。 本文将介绍这两种情况。
应用程序域获取其配置的能力实现了容错设计，其中在受控或不受控制的重启情况下，域将自动刷新其配置。 该技术为最终的生产环境配置提供了基础，并且也用于验收。 修改存储在SCM中的域配置并重新启动域可提供一种升级域配置的方法。
部署政策
部署策略用于控制配置对象在DataPower设备上的接受和拒绝，并有助于在导入期间修改对象参数。 “开发和测试”中XML防火墙上使用的不同端口是这些属性的示例，本文将展示如何操作它们。 部署策略可以与所有主要配置导入过程一起使用，例如远程应用程序域配置定义以及WebGUI，CLI和XML管理接口的导入功能。
部署策略通过定义细粒度的配置匹配语句来定义对象过滤和修改，这些语句可以基于源设备，域，对象类型和名称，甚至每个对象内的属性值。 例如，可以定义策略，以仅允许将名为BookServiceRouter，BookService1或BookService2的XML防火墙配置到配置中，并将每个XML防火墙的端口属性修改为指定的值。 总之，部署策略提供以下功能：
- 限制可以导入的对象（白名单）
- 防止导入组或命名对象（黑名单）
- 修改对象的属性（mod列表）
如样本中所讨论的，XML防火墙在迁移到每个SDLC环境中时需要修改端口。 下一节将描述执行此中介的配置。
样本部署策略
部署策略的GUI屏幕有两个选项卡，可用于构建配置匹配语句：Main和Modified Configuration。 下面的图2是示例策略的Main选项卡的示例。 您可以使用“接受的配置”中定义的语句通过提供白名单功能来限制允许哪些对象进入环境。 过滤后的配置语句可通过提供黑名单功能来限制对象。 在此示例中，“接受”和“过滤”配置保留为空白，从而允许导入已处理配置中的所有对象。
图2.接受和过滤的配置匹配语句
由于声明的目标是修改三个示例服务的端口，因此您需要构造一个“修改配置匹配”，以便为每个防火墙服务分配适当的端口。 这需要三个Configuration Match表达式和替换值的分配。 图3显示了三个必需的Modified Configuration语句，以及分配的替换值：
图3.具有新配置值的配置匹配语句
编辑配置匹配语句之一，如下图4所示，分配配置匹配表达式，修改类型和值。 在此示例中，虽然还允许插入和删除，但正在更改配置值：
图4.带有Build按钮的配置匹配编辑屏幕
图4还显示了为创建配置匹配语句而提供的Build按钮。 生成按钮为匹配语句的构建提供了一种简化的方法。 下面的图5显示了名为BookServiceRouter的XML防火墙服务的匹配（通过PCRE表达式），该服务包含任何值的LocalPort属性。 有关确定属性名称的信息，请参阅本系列的第1部分或WebSphere DataPower SOA Appliance Handbook中的第15章，“构建和部署技术”。
图5.配置匹配表达式
配置部署策略后，下一步是将其应用于导入包。 图6显示了在WebGUI的导入功能期间如何使用部署策略的示例：
图6.将部署策略应用于导入包
导入配置操作的执行将是三个具有修改的端口属性值的防火墙的实例化。 其他配置导入方法也支持部署策略，例如命令行界面（CLI）和XML管理界面Import-Package命令以及Application Domain定义的外部配置的定义。 脚本将显示这两种技术的示例。
总而言之，部署策略为自动修改配置属性提供了可靠的方法。 它们受到各种DataPower配置管理方法的支持，并且它们为SDLC中的配置差异管理提供了系统范围的资源。
软件开发生命周期提升
随着时间的推移，将对DataPower配置进行更改。 新服务将添加到应用程序域，其他服务将得到增强或删除。 有时将修改多个服务（例如样式表策略）使用的对象。 当这些更改可用时，您必须将它们与现有服务合并，然后通过大量测试进行验证。 最终，它们将成为生产环境的一部分。 虽然每个组织都根据其需求定义迁移过程，但本文介绍了一种使用脚本化方法进行应用程序升级的方法。 此方法使用“清单”文档来描述已批准用于迁移的更改的详细信息。 它利用DataPower XML管理界面以自动化和脚本化方式进行迁移。 这样，它就可以对配置内容提供确定的，授权的，有文件证明的控制，并有助于恢复生产环境。
下面的图7显示了此SDLC推广策略。 您可以看到清单文件和部署策略如何在整个环境中用于对象和文件（键）的迁移，以及在导入时修改对象属性。 样本中的部署策略是硬编码的，但是更健壮的解决方案可以使用替代方法，例如将部署策略存储在诸如WebSphere Service Registry and Repository之类的存储库中。 此配置将允许在迁移过程中使用和实例化最新的最大策略。 以下各节描述了如何将批准的对象导出到SCM系统并与现有的配置对象合并。
图7.应用程序生命周期
从发展中迁移
开发人员在开发环境的沙箱中进行更改，您必须确保仅将经过测试和批准的对象导出到SDLC流程中。 因此，从开发中导出单个服务和对象，而不是整个应用程序域。 导出整个域可能导致未关联（孤立）的对象和潜在破坏性对象的迁移。 您可以手动选择要从开发中导出的对象，但是在示例（如下图8所示）中，已创建了批准的服务，对象和文件的清单。 ANT脚本工具和DataPower XML管理界面可利用它来识别已批准的更改并将其导出到SCM。
各种命令将通过XML管理界面执行。 例如，导出配置（Do-Export），导入配置（Do-Import），创建文件（Set-File），保存配置（SaveConfig）和删除配置（del-config）。 您可以在IBM Redpaper：WebSphere DataPower SOA Appliances： XML Management Interface中阅读有关XML Management Interface的更多信息。
图8.开发变更迁移
清单1展示了开发清单文件。 在此示例中，BookService1 XML防火墙对象及其必需的对象和文件（通过ref-objects和ref-files属性指示）被指定用于导出。导出的内容将存储在SCM中名为DevelopmentMigration的文件中。 .b64。 它实际上是一个XML文档，其中包含ZIP格式的base64编码的导出。 密钥材料可以从SCM或密钥库中加载。 本文将在稍后讨论自动部署脚本时描述这些用例。
清单1.开发清单
<?xml version="1.0" encoding="UTF-8"?>
<Manifest>
<!-- -->
<!-- Development Manifest -->
<!-- -->
<!-- This Manifest contains a list of Service Objects and Files -->
<!-- which have been approved for migration. -->
<!-- These Objects and Files will overlay named equivalents -->
<!-- in the Testing Environment -->
<!-- -->
<MigrateServiceObjects all-files="false"
zipFile="https://192.168.1.50:8888/DevelopmentMigration/DevelopmentMigration.zip">
<MigrateServiceObject class="XMLFirewallService"
name="BookService1" ref-objects="true" ref-files="true"/>
</MigrateServiceObjects>
<!-- -->
<!-- These objects will be removed from the configuration -->
<!-- -->
<RemoveServiceObjects>
<RemoveServiceObject class="XMLFirewallService" name="BookServiceDeleteMe"/>
</RemoveServiceObjects>
<!-- -->
<MigrateFileSystemObjects>
<!-- -->
<!-- Note that artifacts in certificate directories -->
<!-- are not available for copy off the device -->
<!-- Any Keys and/or Certs must be positioned in temporary for copy -->
<!-- -->
<MigrateFileSystemObject name="temporary:///BookServiceRouter-privkey.pem"
location="https://
192.168.1.51:8888/DevelopmentMigration/BookServiceRouter-privkey.pem"/>
<MigrateFileSystemObject name="temporary:///BookServiceRouter-sscert.pem"
location="https://
192.168.1.51:8888/DevelopmentMigration/BookServiceRouter-sscert.pem"/>
<!-- -->
</MigrateFileSystemObjects>
<!-- -->
<!-- These files will be removed from the configuration -->
<!-- -->
<RemoveFileSystemObjects>
<RemoveFileSystemObject name="temporary:///DeleteMe.xml"/>
</RemoveFileSystemObjects>
<!-- -->
</Manifest>重建测试环境
现在，已批准的对象已迁移到SCM，它们需要进行严格的测试。 尽管开发人员将完成单元测试，但测试环境必须执行系统范围的验证，以确保新的配置更改不会影响应用程序的其他方面。 此测试要求从SCM系统或密钥库中获取所有服务，对象和其他工件的最新版本。
重建测试环境的第一阶段是重新导入最后批准或“已知良好”的应用程序域导出，可以从在上一轮SDLC测试中放置的SCM中提取该导出。 读取开发清单以确定将要导入或删除的更改。 它们将覆盖以前已知的良好配置中存在的所有喜欢的命名对象，并且还可以添加新对象。 也可以在开发清单中标识包括密钥材料在内的新文件，并将这些文件从SCM或密钥存储区加载到测试环境中。 也可能有一些对象和文件被标识为删除。
图9显示了处理流程，还显示了在配置导入过程中如何使用部署策略来微调对象属性（在我们的示例中为端口）。 测试后，将重构的域移至SCM。
图9.重构测试环境
验收
验收环境是生产之前的最后阶段，它不仅代表进行配置验证的最后最佳机会，而且同样重要的是，证明了生产迁移的机制。 验收和生产环境的构建类似。 从开发中迁移了各个服务，以避免迁移与服务本身不相关的无关（孤立）对象。 验收和生产环境将从SCM整体获取其域配置。 不属于域导出的单个文件和密钥也可以从SCM或密钥存储区上载，并通过开发清单进行标识。
图10显示了接受环境的构建过程。 再次，部署策略用于在导入域配置时修改XML防火墙服务上使用的端口值：
图10.接受环境刷新
生产
既然所有测试都已经完成，现在是将域配置迁移到生产环境的时候了。 与接受情况一样，生产环境使用应用程序域对象的获取域配置，以便当设备重新启动（受控或不受控）时，或者从域重启时，域将从SCM获取（获取）其配置。重新启动。
最初从测试环境安装在SCM中的应用程序域现在移至生产SCM库。 生产和测试SCM库可能是同一物理存储库，具有用于测试和生产的单独域。 使用XML管理界面来确定是否需要将任何文件或密钥上载到生产域（在开发清单中指定），然后重新启动域。 从生产SCM获取新的域配置。
图11显示了生产刷新过程。 与接受情况一样，部署策略用于在导入域配置时修改XML防火墙服务上使用的端口值。
图11.生产环境刷新
在将生产设备发布到生产设备服务器场之前，应将其停产，升级，然后进行单独测试以确保配置刷新过程的可行性。 通常，在设备上创建回显服务以验证接口和后端资源的连通性。 然后可以处理其他设备。 可以使用配置管理工具（例如，用于WebSphere DataPower的IBM Tivoli Composite Application Manager系统版本（ITCAM SE））进一步自动化该过程，该工具可在多个设备之间迁移设备配置。
自动化生命周期提升
既然已经描述了从一种环境迁移到另一种环境的过程，那么该过程如何实现自动化？ 本系列文章描述了多种迁移配置的方法。 虽然WebGUI是常用方法，但它需要手动干预。 大多数软件迁移过程中通常需要的是一个更加自动化，可重复和可管理的过程。 大多数组织已经进行了某种自动化的应用程序升级，通常涉及脚本。 例如，在Java EE环境中，通常通过ANT脚本将应用程序提升为不同的SDLC环境。 如下所述，可下载的示例脚本是使用ANT以及其他开源项目编写的。
设置脚本环境
为了运行可下载的示例脚本，您将需要从Apache.org安装ANT。 将需要其他工具来执行ANT任务中本地不可用的任务。 脚本必须访问以下实用程序，它们才能正常运行：
发送HTTPS请求
部署脚本的主要功能之一是通过HTTPS将SOAP请求发送到DataPower XML管理接口，以导入和导出配置以及将文件复制到设备。 由于ANT没有提供执行此操作的方法，因此您将需要其他实用程序，例如cURL实用程序 。 将curl.exe和支持库复制到ANT脚本可访问的路径。
Base-64编码文件
部署过程的重要部分是将单个文件从SCM或其他服务器复制到DataPower文件系统。 复制文件之前，必须对它们进行base64编码。 可以从ANT脚本安装和调用的一种免费且简单的工具是OpenSSL 。 ANT脚本必须可以访问此工具或类似工具。
与源代码管理管理器（SCM）集成
部署过程将与SCM系统集成，以检入DataPower服务并获得要部署的服务的最新版本。 您可以使用许多不同的SCM存储库来存储配置，每个存储库都需要使用自己的方法来与脚本集成。 尽管许多安装使用诸如IBM Rational ClearCase之类的关键任务SCM，但在我们的ANT脚本中使用了开源项目CVS。 我们的目标是演示技术而非SCM程序。 ANT具有可以挂接到CVS应用程序中的特定任务。 为此，请将cvs.exe文件复制到脚本位置或将其添加到服务器的路径。 我们选择将此可执行文件复制到脚本文件夹本身中。 如果未安装CVS，则需要获取安装才能执行附件的脚本。
资料夹结构
可下载的示例脚本由几个文件夹组成，如下图12所示。 三个文件夹位于顶级文件夹DataPowerDeploy下，还有三个脚本。 这些文件夹是：
- Bin-â??? 包含导出和部署过程的主要脚本以及cvs.exe文件
- XML-？ 包含在导出和部署过程中使用的XML文档，包括清单文档，必须对其进行更改以定义要部署到不同环境的服务和文件。
- XSL-â？ 包含在脚本编写过程中使用的XSLT样式表，用于诸如创建用于导出服务的XML Management SOAP请求文档以及从响应中提取服务导出之类的功能。
图12.部署脚本文件夹结构
DataPower XML管理界面
与DataPower设备的所有交互都是通过将SOAP请求发送到设备的XML管理接口来完成的，该接口允许通过HTTPS上的SOAP请求进行经过身份验证的设备配置和管理。 这包括在迁移过程中导出和导入配置和文件。 您必须在所有环境中的所有DataPower设备上启用此接口，您可以使用WebGUI通过登录默认域并从左侧导航菜单导航至XML管理接口来执行此操作。 必须启用XML管理接口，并检查SOAP配置管理和AMP端点服务，如图13所示：
图13.启用XML管理界面
从开发环境导出服务
该脚本的目的是导出开发清单（dev_manifest.xml）中列出的所有服务（如清单1所示），并将导出的配置存储在SCM系统中。 将这些服务部署到流程中的测试环境后，将在以后的SDLC流程中使用此配置。
执行脚本
在顶层文件夹中，有一个名为exportDevServices.xml的文件，该文件是一个XML文档，用作导出项目开发清单中列出的服务的驱动程序脚本。 此驱动程序ANT脚本的目的是设置特定于环境的变量，然后在bin文件夹中调用主脚本getServices_ANT.xml，该脚本隐藏了底层详细信息，并使为您的环境设置变量更容易以创建和提交。 XML管理请求。 在执行主驱动程序脚本之前，请更新xml文件夹中的开发清单。 除了更新此XML文件之外，您还必须更新驱动程序脚本中列出的参数：
- domain ？？-将要从中导出服务的开发域的名称。 在我们的示例中，域名为BookService。
- xmlmgmt_url-包含开发域的设备上XML管理接口的URL。 必须启用XML管理接口，此过程才能起作用。
- DP_uid-â??? 用来将SOAP请求提交到XML管理界面的用户名。
- DP_pw –与XML管理接口提供的用户ID对应的密码。
- CVS_root-吗？ 将用于访问CVS存储库的CVS根目录。 如果存储库受密码保护（应该如此），则用户ID和密码将包含在此根目录中。
- CVS_package-â???? 将包含DataPower服务和域导出的CVS软件包的名称。
- cURL_exec –-curl.exe的位置。
现在已经设置了所有参数，您可以执行exportDevServices.xml ANT脚本。 在较高级别，此脚本将执行以下功能：
- 使用开发清单作为xsl文件夹中XSLT样式表的输入，构建SOAP请求，该请求将发送到DataPower XML管理接口，以通过Do-Export命令导出所需的服务。 清单2显示了此请求的示例：
清单2. do-export XML管理接口请求
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <dp:request xmlns:dp="http://www.datapower.com/schemas/management" domain="BookService"> <dp:do-export> <dp:object class="XMLFirewallService" name="BookService1" ref-objects="true" ref-files="true" /> <dp:object class="XMLFirewallService" name="BookService2" ref-objects="true" ref-files="true" /> <dp:object class="XMLFirewallService" name="BookServiceRouter" ref-objects="true" ref-files="true" /> </dp:do-export> </dp:request> </soapenv:Body> </soapenv:Envelope> - 将在步骤1中创建的SOAP请求发送到DataPower设备。
- 从SOAP请求的响应中提取base64编码的导出。
- 将提取的导出存储在CVS SCM存储库中，该存储在输入参数指定的包内。
从开发升级到测试
从开发环境中导出所需的服务并将其存储在SCM存储库中之后，就可以将其导入测试环境中。 此过程涉及构建多个XML Management SOAP请求并将其发送到测试DataPower设备以重新创建BookService域。
执行脚本
提供的用于演示此操作的脚本位于名为testingDeploy.xml的文件中。 与开发导出的驱动程序脚本非常相似，此驱动程序脚本用于将参数传递给主脚本，以将服务和文件部署到测试环境。 许多必需的参数与上一个脚本相同，但增加了一个。 名为openSSL_exec的参数提供了openSSL安装的位置，该安装用于对要导入到测试域中的文件进行base64编码。
除了这些参数之外，请确保开发清单（dev_manifest.xml）列出了必须复制到新测试环境中的文件。 这些文件很可能是密钥和证书文件，因为它们不是从开发环境中导出的。 在此示例中，这些文件必须驻留在CVS存储库中，但强烈建议将这些文件存储在脚本可以访问的安全密钥存储区中。 设置完所有参数后，便可以执行此脚本，并将执行以下任务：
- 通过将SOAP请求发送到XML Management接口来删除测试DataPower设备上现有的BookService域，如清单3所示：
清单3. del-config请求
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <dp:request xmlns:dp="http://www.datapower.com/schemas/management" domain="default"> <dp:del-config> <Domain name="BookService"/> </dp:del-config> </dp:request> </soapenv:Body> </soapenv:Envelope> - 通过获取测试环境中域的最新备份并将其在SOAP请求中发送到XML管理接口，从CVS存储库中导入“最后一次良好的配置”配置域导出。 如果这是对测试设备的首次部署，则必须将域导出添加到SCM以“启动泵”。 这可以是空域导出。 从SCM检索到的以base64编码的域导出包含在input-file元素内的请求的SOAP正文中。 清单4中显示了一个示例请求：
清单4.导入域请求
<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <dp:request xmlns:dp="http://www.datapower.com/schemas/management"> <dp:do-import source-type="ZIP"> <dp:input-file>UEsDBAoAAAAAA.....</dp-input-file> </dp:do-import> </dp:request> </env:Body> </env:Envelope> - 通过将SOAP请求发送到XML管理接口（类似于上面的清单2中所示的请求），从默认域中导出测试环境的部署策略。
- 将在上一步中导出的部署策略导入到测试环境BookService域中。 同样，将构建一个SOAP请求并将其发送到XML Management接口以导入部署策略。 该请求类似于上面清单4中所示的请求。
- 将开发清单中列出的所有文件复制到测试BookService域中的本地文件系统中。 此步骤将通过XSLT动态构建ANT脚本，该脚本将对要导入的文件进行base64编码，然后构建SOAP请求以发送到包含base64编码文件的XML Management接口。 清单5中显示了此SOAP请求的示例：
清单5.复制文件的XML管理请求
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <dp:request xmlns:dp="http://www.datapower.com/schemas/management" domain="BookService"> <dp:set-file name="cert:///BookServiceRouter-privkey.pem"> LS0tLS1CR......</dp:set-file> </dp:request> </soapenv:Body> </soapenv:Envelope> - 导入从开发BookService域中导出的服务。 这将是使用第一个讨论的脚本exportDevServices.xml导出服务时存储在CVS中的base64编码文件。 该文件包含在与清单4中所示请求类似的SOAP请求中，并发送到XML管理接口。 但是，在此请求中，它指定了导入域时要应用的部署策略-在步骤3中从默认域复制的部署策略。清单6显示了此请求文档的示例：
清单6.保存域配置的XML管理请求
<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <dp:request domain="BookService xmlns:dp="http://www.datapower.com/schemas/management"> <dp:do-import source-type="ZIP" overwrite-objects="true" deployment-policy="BookService Testing"> <dp:input-file>AS0tPS1CF...... </dp:input-file> </dp:do-import> </dp:request> </env:Body> </env:Envelope> - 通过与上述清单3中所示的请求文档类似的SOAP请求，从测试的BookService域中删除开发清单文档中指定的所有服务。
- 通过将SOAP请求发送到XML管理接口（如下面的清单7所示），保存测试的BookService域配置。 该请求使用do-action操作，并将SaveConfig指定为操作：
清单7.保存域配置的XML管理请求
<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <dp:request domain="BookService" xmlns:dp="http://www.datapower.com/schemas/management"> <dp:do-action> <SaveConfig/> </dp:do-action> </dp:request> </env:Body> </env:Envelope>
完成此脚本后，从开发环境导出的服务现在将驻留在测试环境中。 部署策略将修改XML防火墙端口，标记为此类的任何服务或对象都将被删除。
登录到测试的BookService域，以确认所有预期的服务都存在并且状态为“启动”。
促进验收和生产
将所需的服务部署到测试环境并进行了充分的测试后，现在可以将其迁移到验收环境，然后再迁移到生产中。 与从开发到测试的迁移不同，将服务部署到验收和生产环境是在域级别，以确保域中的所有服务（及其支持对象）在测试时都作为一个整体单元迁移。
迁移到验收和生产环境时，该域不会导入到DataPower设备中。 域配置为从远程位置获取配置，该位置可以是SCM存储库或其他服务器。 每次重新启动域（或设备）时，DataPower设备都会获取此配置。 这意味着脚本必须简单地重新启动域，并且将提取SCM中的新域。 域配置中指定的部署策略再次根据需要修改配置。
执行脚本
接受环境部署的驱动程序脚本是acptDeploy.xml文件。 该文件中必须更新与测试部署驱动程序脚本中相同的参数。 同样，您必须为此部署更新清单文件，但是清单文件特定于接受环境，因为我们不再列出特定的服务，并且在文件列表中包括了identityDocument.xml。 为此，我们在示例中有一个名为acpt_manifest的文件。
将正确的参数提供给清单文档和驱动程序脚本后，即可执行脚本。 该脚本将执行以下任务：
- 通过在发送到XML管理接口（如清单8中所示的文档）的SOAP请求中调用do-backup操作，备份测试域并将base64导出存储在SCM存储库中：
清单8.备份域配置的XML管理请求
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <dp:request xmlns:dp="http://www.datapower.com/schemas/management" domain="default"> <dp:do-backup format="ZIP"> <dp:domain name="Testing"/> </dp:do-backup> </dp:request> </soapenv:Body> </soapenv:Envelope> - 重新启动目标域（接受或生产）。 这将引入在目标设备上现有域内定义的新域配置。 清单9显示了一个示例SOAP请求来完成此任务：
清单9.重新启动域的XML管理请求
<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <dp:request xmlns:dp="http://www.datapower.com/schemas/management"> <dp:do-action> <RestartDomain> <Domain>BookService</Domain> </RestartDomain> </dp:do-action> </dp:request> </env:Body> </env:Envelope> - 通过类似于上述清单5中所示的SOAP请求，将清单文档中列出的文件从SCM存储库复制到目标环境。
你有它！ 通过三个简单的步骤，即可将测试域部署到目标环境，该环境可以是验收环境或您的生产环境。 将会应用相同的三个步骤。
结论
必须以受控方式将更改迁移到DataPower设备配置。 必须在每个级别进行测试，以确保不影响服务质量。 本文档提供了一个自动方法的示例，该方法可用于从开发到生产的整个SDLC中的变更迁移。 各个组织的要求可能与这种方法有所不同； 但是，此框架演示了在SDLC迁移中将证明有价值的技术。
翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/0904_rasmussen/0904_rasmussen.html
websphere配置
254
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
