7.6. 自定义部署行为
7.6.1. 为部署内容定义自定义目录
您可以为 JBoss EAP 定义自定义位置来存储部署的内容。
为单机服务器定义自定义目录
默认情况下,单机服务器部署的内容存储在 EAP_HOME/standalone/data/content
目录中。可以在启动服务器时传递 -Djboss.server.deploy.dir
参数来更改此位置。
$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content
在 JBoss EAP 实例中,所选位置应是唯一的。
jboss.server.deploy.dir
属性指定用于存储使用管理控制台或管理 CLI 部署的内容的目录。要定义由部署扫描程序监控的自定义部署目录,请参阅配置 部署扫描器。
为受管域定义自定义目录
默认情况下,受管域的部署内容存储在 EAP_HOME/domain/data/content
目录中。可以在启动域时传递 -Djboss.domain.deployment.dir
参数来更改此位置。
$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content
在 JBoss EAP 实例中,所选位置应是唯一的。
7.6.2. 控制部署的顺序
JBoss EAP 提供对服务器启动时部署顺序的精细控制。可以指定多个 EAR 文件中存在的应用程序的严格顺序,以及重启后顺序的持久性。
您可以使用 jboss-all.xml
部署描述符声明顶层部署之间的依赖项。
例如,如果您有一个 app.ear
,它依赖于首先部署的 framework.ear
,您可以创建 app.ear/META-INF/jboss-all.xml
文件,如下所示。
<jboss umlns="urn:jboss:1.0"> <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> <dependency name="framework.ear" /> </jboss-deployment-dependencies> </jboss>
您可以使用部署的运行时名称作为 jboss-all.xml
文件中的依赖项名称。
这样可确保在 app.ear
之前部署 framework.ear
。
虽然 jboss-all.xml
文件和其他部署描述符允许您声明服务器没有其他检测的依赖项,但它不是严格的排序功能。JBoss EAP 假设部署描述符中指定的所有依赖项都已部署或可用。如果缺少依赖项,JBoss EAP 不会自动部署它们,部署会失败。
7.6.3. 覆盖部署内容
部署覆盖 可用于将内容覆盖到现有的部署中,而无需物理修改部署存档的内容。它允许您在运行时覆盖部署描述符、JAR 文件、类、JSP 页面和其他文件,而无需重新构建存档。
如果您需要针对需要不同配置或设置的不同环境调整部署,这非常有用。例如,当通过应用程序生命周期将部署从开发、测试到阶段,最后进入生产环境时,您可能需要交换部署描述符,修改静态 Web 资源以更改应用程序的品牌,甚至将 JAR 库替换为不同的版本,具体取决于目标环境。对于需要更改配置但由于策略或安全限制而无法修改或破解存档的安装,它也非常有用。
在定义部署覆盖时,您可以在要替换部署存档中的 文件的文件系统中指定该文件。您还必须指定哪些部署应受到部署覆盖的影响。必须重新部署所有受影响的部署,才能使更改生效。
使用 deployment-overlay add
management CLI 命令添加部署覆盖。
deployment-overlay add --name=new-deployment-overlay --content=WEB-INF/web.xml=/path/to/other/web.xml --deployments=test-application.war --redeploy-affected
在受管域中,使用 --server-groups
指定适用的服务器组,或使用 --all-server-groups
指定所有服务器组。
创建后,您可以将内容添加到现有的 overlay 中,将覆盖链接到部署或移除覆盖。如需完整的使用详情,请执行 deployment-overlay --help
。
参数
name
- 部署覆盖的名称。
content
-
将文件系统上的文件映射到要替换的存档中的文件的逗号分隔列表。每个条目的格式是
ARCHIVE_PATH=FILESYSTEM_PATH
。 部署
- 此覆盖将链接到的以逗号分隔的部署列表。
redeploy-affected
- 重新部署所有受影响的部署。
7.6.4. 使用 Rollout 计划
关于 Rollout 计划
在受管域中,针对域或主机级别资源的操作可能会影响多个服务器。此类操作可以包括一个汇总计划,详细说明操作要应用到服务器的顺序,以及用于详细说明在某些服务器上成功执行该操作时是否可以恢复操作的策略。如果没有指定 rollout 计划,则使用默认的 rollout 计划。
以下是涉及五个服务器组的 rollout 计划示例。操作可以按顺序应用到服务器组(以类
为 )或并发(并发组
)。语法在 Rollout Plan Syntax 中详细介绍。
{"my-rollout-plan" => {"rollout-plan" => { "in-series" => [ {"concurrent-groups" => { "group-A" => { "max-failure-percentage" => "20", "rolling-to-servers" => "true" }, "group-B" => undefined }}, {"server-group" => {"group-C" => { "rolling-to-servers" => "false", "max-failed-servers" => "1" }}}, {"concurrent-groups" => { "group-D" => { "max-failure-percentage" => "20", "rolling-to-servers" => "true" }, "group-E" => undefined }} ], "rollback-across-groups" => "true" }}}
查看上例,将操作应用到域中的服务器在三个阶段完成。如果任何服务器组的策略触发跨服务器组回滚操作,则所有其他服务器组也会回滚。
- 服务器组 group-A 和 group-B 将同时应用操作。该操作将应用于 group-A 系列中的服务器,而 group-B 中的所有服务器将同时处理该操作。如果 group-A 中超过 20% 的服务器无法应用该操作,它将在该组之间回滚。如果 group-B 中的任何服务器都无法应用操作,它将在该组中回滚。
- 在 group-A 和 group-B 中的所有服务器完成后,操作将应用到 group-C 中的服务器。这些服务器将同时处理操作。如果 group-C 中的多个服务器无法应用操作,它将在该组中回滚。
- 在 group-C 中的所有服务器完成后,服务器组 group-D 和 group-E 将同时应用操作。该操作将应用于 group-D 中的服务器,而 group-E 中的所有服务器将同时处理该操作。如果 group-D 中超过 20% 的服务器无法应用该操作,它将在该组之间回滚。如果 group-E 中的任何服务器都无法应用操作,它将在该组中回滚。
rollout Plan Syntax
您可以通过以下任一方式指定推出部署计划。
-
通过在
deploy
命令操作标头中定义 rollout 计划。详情请参阅使用 Rollout 计划 进行部署。 -
通过使用
rollout-plan
命令存储推出部署计划,然后在deploy
命令操作标头中引用计划名称。详情请参阅 使用 Stored Rollout 计划 进行部署。
虽然每种方法都有不同的初始命令,但这两种方法都使用 rollout
操作标头来定义 rollout 计划。这使用以下语法:
rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]
-
PLAN_NAME
是使用rollout-plan
命令存储的 rollout 计划的名称。 SERVER_GROUP_LIST
是服务器组的列表。使用逗号(、
)分隔多个服务器组,以指示应按顺序在每个服务器组上执行操作。使用 caret (^
)分隔符表示应同时在每个服务器组上执行操作。对于每个服务器组,在括号中设置以下任何策略:以逗号分隔的多个策略。
-
rolling-to-servers
:布尔值如果设为true
,则操作将应用于系列的组中的每个服务器。如果值为false
或未指定,则操作将同时应用到组中的服务器。 -
max-failed-servers
: 一个整数,它取组中的最大服务器数,在应恢复组的所有服务器上前无法应用该操作。如果没有指定默认值,则默认值为0,
这意味着任何服务器上的失败都会在组间触发回滚。 max-failure-percentage
:0
到100
之间的整数,代表组中服务器总数的最大百分比,在应该在组的所有服务器上恢复它前无法应用该操作。如果没有指定默认值,则默认值为0,
这意味着任何服务器上的失败都会在组间触发回滚。注意如果
max-failed-servers
和max-failure-percentage
都被设置为非零值,则max-failure-percentage
将具有优先权。
-
-
跨组回滚
:一个布尔值,指示是否需要在一个服务器组中的所有服务器上回滚操作会在所有服务器组中触发回滚。默认值为false
。
使用 Rollout 计划进行部署
您可以通过将 rollout 设置传递给 headers
参数,将 rollout
计划直接提供给 deploy
命令。有关格式的更多信息,请参阅 Rollout Plan Syntax。
以下管理 CLI 命令利用部署计划将应用程序部署到 main-server-group
服务器组,该计划为串行部署指定 rolling-to-servers=true
。
deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}
使用存储的 Rollout 计划进行部署
由于推出部署计划可能比较复杂,您可以选择存储推出部署计划的详细信息。这可让您在使用 rollout 计划名称时引用 rollout 计划名称,而不必每次都需要 rollout 计划的完整详情。
使用
rollout-plan
管理 CLI 命令存储推出部署计划。有关格式的更多信息,请参阅 Rollout Plan Syntax。rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}
这会创建以下部署计划。
"rollout-plan" => { "in-series" => [ {"server-group" => {"main-server-group" => { "rolling-to-servers" => false, "max-failed-servers" => 1 }}}, {"server-group" => {"other-server-group" => { "rolling-to-servers" => true, "max-failure-percentage" => 20 }}} ], "rollback-across-groups" => true }
在部署应用程序时指定存储的 rollout 计划名称。
以下管理 CLI 命令使用
my-rollout-plan
存储的 rollout 计划将应用程序部署到所有服务器组。deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
删除 Stored Rollout 计划
您可以通过指定要删除的 rollout 计划的名称,使用 rollout-plan
管理 CLI 命令删除存储的 rollout 计划。
rollout-plan remove --name=my-rollout-plan
默认 Rollout 计划
所有影响多个服务器的操作都将通过推出部署计划来执行。如果在操作请求中没有指定 rollout 计划,则会生成默认的 rollout 计划。计划具有以下特征:
- 将只有一个高级别阶段。受操作影响的所有服务器组都将同时应用操作。
- 在每个服务器组中,操作将同时应用到所有服务器。
- 在服务器组中的任何服务器上失败将导致跨组进行回滚。
- 任何服务器组失败将导致回滚所有其他服务器组。