Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

Chapter 7. Deploying Applications

JBoss EAP features a range of application deployment and configuration options to cater to both administrators and developers. For administrators, the management console and the management CLI offer ideal graphical and command-line interfaces to manage application deployment in a production environment. For developers, the range of application deployment testing options include a configurable file system deployment scanner, the HTTP API, an IDE such as Red Hat JBoss Developer Studio, and Maven.

When deploying applications, you may want to enable validation for deployment descriptors by setting the org.jboss.metadata.parser.validate system property to true. This can be done one of the following ways:

  • While starting the server.

    $ EAP_HOME/bin/standalone.sh -Dorg.jboss.metadata.parser.validate=true
  • By adding it to the server configuration with the following management CLI command.

    /system-property=org.jboss.metadata.parser.validate:add(value=true)

7.1. Deploying Applications Using the Management CLI

Deploying applications using the management CLI gives you the benefit of single command-line interface with the ability to create and run deployment scripts. You can use this scripting ability to configure specific application deployment and management scenarios. You can manage the deployments for a single server when running as a standalone server, or an entire network of servers when running in a managed domain.

7.1.1. Deploy an Application to a Standalone Server Using the Management CLI

Deploy an Application

From the management CLI, use the deploy command and specify the path to the application deployment.

deploy /path/to/test-application.war

A successful deployment does not produce any output to the management CLI, but the server log displays deployment messages.

WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war")
WFLYUT0021: Registered web context: /test-application
WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")

The application has been successfully deployed.

Undeploy an Application

From the management CLI, use the undeploy command and specify the deployment name.

  • Undeploy the application and delete the deployment content.

    undeploy test-application.war
  • Undeploy the application without removing the deployment content from the repository.

    undeploy test-application.war --keep-content

    This is the same as disabling the deployment from the management console.

A successful undeployment does not produce any output to the management CLI, but the server log displays undeployment messages.

WFLYUT0022: Unregistered web context: /test-application
WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 62ms
WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")

The application has been successfully undeployed.

List Deployments

From the management CLI, use the deployment-info command to list deployment information.

deployment-info

The output will show details about each deployment, such as the runtime name, status, and whether it is enabled.

NAME                 RUNTIME-NAME         PERSISTENT ENABLED STATUS
jboss-helloworld.war jboss-helloworld.war true       true    OK
test-application.war test-application.war true       true    OK

You can also filter the deployments to display by name using the --name argument.

7.1.2. Deploy an Application in a Managed Domain Using the Management CLI

Deploy an Application

From the management CLI, use the deploy command and specify the path to the application deployment. You must also specify the server groups to which the application should be deployed.

  • To deploy the application to all server groups.

    deploy /path/to/test-application.war --all-server-groups
  • To deploy the application to specific server groups.

    deploy /path/to/test-application.war --server-groups=main-server-group,other-server-group

A successful deployment does not produce any output to the management CLI, but the server log displays deployment messages for each affected server.

[Server:server-one] WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war")
[Server:server-one] WFLYUT0021: Registered web context: /test-application
[Server:server-one] WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")

The application has been successfully deployed to the appropriate server groups in your managed domain.

Undeploy an Application

From the management CLI, use the undeploy command and specify the deployment name. You must also specify the server groups from which the application should be undeployed.

  • Undeploy the application from all server groups with that deployment.

    undeploy test-application.war --all-relevant-server-groups
  • Undeploy the application from specific server groups. Note that the --keep-content parameter is required, as the content must remain in the repository for other server groups with that deployment.

    undeploy test-application.war --server-groups=other-server-group --keep-content

    This is the same as disabling the deployment from the management console.

A successful undeployment does not produce any output to the management CLI, but the server log displays undeployment messages for each affected server.

[Server:server-one] WFLYUT0022: Unregistered web context: /test-application
[Server:server-one] WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 74ms
[Server:server-one] WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")

The application has been successfully undeployed.

List Deployments

From the management CLI, use the deployment-info command to list deployment information. You can list deployment information by deployment name or by server group.

To display deployment information by name:

deployment-info --name=jboss-helloworld.war

The output will list the deployment and its state in each server group.

NAME                 RUNTIME-NAME
jboss-helloworld.war jboss-helloworld.war

SERVER-GROUP       STATE
main-server-group  enabled
other-server-group added

To display deployment information by server group:

deployment-info --server-group=other-server-group

The output will list the deployments and their state for the specified server group.

NAME                 RUNTIME-NAME         STATE
jboss-helloworld.war jboss-helloworld.war added
test-application.war test-application.war enabled

You can also list all deployments in the domain using the deploy -l command.

7.2. Deploying Applications Using the Management Console

Deploying applications using the management console gives you the benefit of a graphical interface that is easy to use. You can see at a glance which applications are deployed to your server or server groups, and you can enable, disable or remove applications from the content repository as required.

7.2.1. Deploy an Application to a Standalone Server Using the Management Console

Deployments can be viewed and managed from the Deployments tab of the JBoss EAP management console.

Deploy an Application

Click the Add button and use the New Deployment wizard to deploy an application. You can choose to deploy an application by uploading a deployment or creating an unmanaged deployment. Deployments are enabled by default.

  • Upload a deployment

    Upload an application that will be copied to the server’s content repository and managed by JBoss EAP.

  • Create an unmanaged deployment

    Specify the location of a deployment. This deployment will not be copied to the server’s content repository and will not be managed by JBoss EAP. Note that exploded deployments are only supported as unmanaged.

Undeploy an Application

Select the deployment and choose the Remove option to undeploy the application. This undeploys the deployment and removes it from the content repository.

Disable an Application

Select the deployment and choose the Disable option to disable the application. This undeploys the deployment, but does not remove it from the content repository.

Replace an Application

Select the deployment and choose the Replace option. Select the new version of the deployment, which must have the same name as the original, and click Finish. This undeploys and removes the original version of the deployment, and then deploys the new version.

7.2.2. Deploy an Application in a Managed Domain Using the Management Console

From the Deployments tab of the JBoss EAP management console, deployments can be viewed and managed by:

  • Content Repository

    All managed and unmanaged deployments are listed in the Content Repository section. Deployments can be added and assigned to server groups here.

  • Unassigned Content

    Deployments that have not been assigned to any server groups are listed in the Unassigned Content section. Deployments can be assigned to server groups or removed here.

  • Server Groups

    Deployments that have been assigned to one or more server groups are listed in the Server Groups section. Deployments can be enabled and added directly to a server group here.

Deploy an Application
  1. From Content Repository, click the Add button.
  2. Choose to deploy an application by uploading a deployment or creating an unmanaged deployment.
  3. Follow the prompts to deploy the application.

    Note that a deployment must be assigned to a server group before it can be enabled.

Deployments can also be added, assigned to a server group, and enabled in one step by adding the deployment from Server Groups.

Assign an Application to a Server Group
  1. From Unassigned Content, select a deployment and click the Assign button.
  2. Select one or more server groups to which this deployment should be assigned.
  3. Optionally, select the option to enable the deployment on the selected server groups.
Unassign an Application from a Server Group
  1. From Server Groups, select the appropriate server group.
  2. Select the desired deployment and click the Unassign button.

Deployments can also be unassigned from multiple server groups at once by selecting the Unassign button for the deployment in Content Repository.

Undeploy an Application
  1. If the deployment is still assigned to any server groups, be sure to unassign the deployment.
  2. From Content Repository, select the deployment and click the Remove button.

This undeploys the deployment and removes it from the content repository.

Disable an Application
  1. From Server Groups, select the appropriate server group.
  2. Select the desired deployment and click the Disable button.

This undeploys the deployment, but does not remove it from the content repository.

Replace an Application
  1. From Content Repository, select the deployment and click the Replace button.
  2. Select the new version of the deployment, which must have the same name as the original, and click Finish.

This undeploys and removes the original version of the deployment, and then deploys the new version.

7.3. Deploying Applications Using the Deployment Scanner

The deployment scanner monitors the deployment directory for applications to deploy. By default, the deployment scanner scans the EAP_HOME/standalone/deployments/ directory every five seconds for changes. Marker files are used to indicate the status of a deployment and to trigger actions against deployments, such as undeploying or redeploying.

While it is recommended to use the management console or management CLI for application deployment in a production environment, deploying using the deployment scanner is provided for the convenience of developers. This allows users build and test applications in a manner suited for rapid development cycles. Additionally, the deployment scanner should not be used in conjunction with other deployment methods.

The deployment scanner is only available when running JBoss EAP as a standalone server.

7.3.1. Deploy an Application to a Standalone Server Using the Deployment Scanner

The deployment scanner can be configured to allow or disallow automatic deployment of XML, zipped, and exploded content. If automatic deployment is disabled, you must manually create marker files to trigger deployment actions. For more information about the available marker file types and their purposes, see the Deployment Scanner Marker Files section.

By default, automatic deployment for XML and zipped content is enabled. For details on configuring automatic deployment for each content type, see Configure the Deployment Scanner.

Warning

Deploying using the deployment scanner is provided for the convenience of developers and is not recommended for use in a production environment. It should also not be used in conjunction with other deployment methods.

Deploy an Application

Copy the content to the deployment folder.

$ cp /path/to/test-application.war EAP_HOME/standalone/deployments/

If auto-deployment is enabled, this file will be picked up automatically, deployed, and a .deployed marker file will be created. If auto-deployment is not enabled, then you will need to manually add a .dodeploy marker file to trigger deployment.

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy
Undeploy an Application

Trigger an undeployment by removing the .deployed marker file.

$ rm EAP_HOME/standalone/deployments/test-application.war.deployed

If auto-deployment is enabled, you can also remove the test-application.war file, which will trigger the undeployment. Note that this does not apply for exploded deployments.

Redeploy an Application

Create a .dodeploy marker file to initiate redeployment.

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy

7.3.2. Configure the Deployment Scanner

The deployment scanner can be configured using the management console or the management CLI. You can configure the deployment scanner’s behavior, such as the scan interval, deployment folder location, and autodeployment of certain application file types. You can also disable the deployment scanner entirely.

For details on all available deployment scanner attributes, see the Deployment Scanner Attributes section.

Use the below management CLI commands to configure the default deployment scanner.

Disable the Deployment Scanner
/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)

This disables the default deployment scanner.

Change the Scan Interval
/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-interval,value=10000)

This updates the scan interval time from 5000 milliseconds (five seconds) to 10000 milliseconds (ten seconds).

Change the Deployment Folder
/subsystem=deployment-scanner/scanner=default:write-attribute(name=path,value=/path/to/deployments)

This changes the location of the deployment folder from the default location of EAP_HOME/standalone/deployments to /path/to/deployments.

The path value will be treated as an absolute path unless the relative-to attribute is specified, in which case it will be relative to that path.

Enable the Automatic Deployment of Exploded Content
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-exploded,value=true)

This enables the automatic deployment of exploded content, which is disabled by default.

Disable the Automatic Deployment of Zipped Content
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-zipped,value=false)

This disables the automatic deployment of zipped content, which is enabled by default.

Disable the Automatic Deployment of XML Content
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-xml,value=false)

This disables the automatic deployment of XML content, which is enabled by default.

7.3.3. Define a Custom Deployment Scanner

A new deployment scanner can be added using the management CLI or by navigating to the Deployment Scanners subsystem from the Configuration tab in the management console. This will define a new directory to scan for deployments. The default deployment scanner monitors EAP_HOME/standalone/deployments. See Configure the Deployment Scanner for details on configuring an existing deployment scanner.

The following management CLI command adds a new deployment scanner that will check EAP_HOME/standalone/new_deployment_dir every five seconds for deployments.

/subsystem=deployment-scanner/scanner=new-scanner:add(path=new_deployment_dir,relative-to=jboss.server.base.dir,scan-interval=5000)
Note

The specified directory must already exist or this command will fail with an error.

A new deployment scanner has been defined and the specified directory will be monitored for deployments.

7.4. Deploying Applications Using Maven

Deploying applications using Apache Maven allows you to easily incorporate deployment to JBoss EAP into your existing development workflow.

You can use Maven to deploy applications to JBoss EAP using the WildFly Maven Plugin, which provides simple operations to deploy and undeploy applications to the application server.

7.4.1. Deploy an Application to a Standalone Server Using Maven

The following instructions show how to deploy and undeploy the JBoss EAP helloworld quickstart to a standalone server using Maven.

See Using the Quickstart Examples in the JBoss EAP Getting Started Guide for more information on the JBoss EAP quickstarts.

Deploy an Application

Initialize the WildFly Maven Plugin in your Maven pom.xml file. This should already be configured in the JBoss EAP quickstart pom.xml files.

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>${version.wildfly.maven.plugin}</version>
</plugin>

From the helloworld quickstart directory, execute the following Maven command.

$ mvn clean install wildfly:deploy

After issuing the Maven command to deploy, the terminal window shows the following output indicating a successful deployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.981 s
[INFO] Finished at: 2015-12-23T15:06:13-05:00
[INFO] Final Memory: 21M/231M
[INFO] ------------------------------------------------------------------------

The deployment can also be confirmed by viewing the server log of the active server instance.

WFLYSRV0027: Starting deployment of "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
WFLYUT0021: Registered web context: /jboss-helloworld
WFLYSRV0010: Deployed "jboss-helloworld.war" (runtime-name : "jboss-helloworld.war")
Undeploy an Application

From the helloworld quickstart directory, execute the following Maven command.

$ mvn wildfly:undeploy

After issuing the Maven command to undeploy, the terminal window shows the following output indicating a successful undeployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.237 s
[INFO] Finished at: 2015-12-23T15:09:10-05:00
[INFO] Final Memory: 10M/183M
[INFO] ------------------------------------------------------------------------

The undeployment can also be confirmed by viewing the server log of the active server instance.

WFLYUT0022: Unregistered web context: /jboss-helloworld
WFLYSRV0028: Stopped deployment jboss-helloworld.war (runtime-name: jboss-helloworld.war) in 27ms
WFLYSRV0009: Undeployed "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")

7.4.2. Deploy an Application in a Managed Domain Using Maven

The following instructions show how to deploy and undeploy the JBoss EAP helloworld quickstart in a managed domain using Maven.

See Using the Quickstart Examples in the JBoss EAP Getting Started Guide for more information on the JBoss EAP quickstarts.

Deploy an Application

When deploying an application in a managed domain, you must specify the server groups to which the application should be deployed. This is configured in the Maven pom.xml file.

The following configuration in the pom.xml initializes the WildFly Maven Plugin and specifies main-server-group as the server group to which the application should be deployed.

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>${version.wildfly.maven.plugin}</version>
  <configuration>
    <domain>
      <server-groups>
        <server-group>main-server-group</server-group>
      </server-groups>
    </domain>
  </configuration>
</plugin>

From the helloworld quickstart directory, execute the following Maven command.

$ mvn clean install wildfly:deploy

After issuing the Maven command to deploy, the terminal window shows the following output indicating a successful deployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.005 s
[INFO] Finished at: 2016-09-02T14:36:17-04:00
[INFO] Final Memory: 21M/226M
[INFO] ------------------------------------------------------------------------

The deployment can also be confirmed by viewing the server log of the active server instance.

WFLYSRV0027: Starting deployment of "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
WFLYUT0021: Registered web context: /jboss-helloworld
WFLYSRV0010: Deployed "jboss-helloworld.war" (runtime-name : "jboss-helloworld.war")
Undeploy an Application

From the helloworld quickstart directory, execute the following Maven command.

$ mvn wildfly:undeploy

After issuing the Maven command to undeploy, the terminal window shows the following output indicating a successful undeployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.750 s
[INFO] Finished at: 2016-09-02T14:45:10-04:00
[INFO] Final Memory: 10M/184M
[INFO] ------------------------------------------------------------------------

The undeployment can also be confirmed by viewing the server log of the active server instance.

WFLYUT0022: Unregistered web context: /jboss-helloworld
WFLYSRV0028: Stopped deployment jboss-helloworld.war (runtime-name: jboss-helloworld.war) in 106ms
WFLYSRV0009: Undeployed "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")

7.5. Deploying Applications Using the HTTP API

Applications can be deployed to JBoss EAP using the HTTP API with the curl command. For more information on using the HTTP API, see the HTTP API section.

7.5.1. Deploy an Application to a Standalone Server Using the HTTP API

By default, the HTTP API is accessible at http://HOST:PORT/management, for example, http://localhost:9990/management.

Deploy an Application
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}]},{"operation" : "deploy", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'
Undeploy an Application
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "test-application.war"}},{"operation" : "remove", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'

See this Red Hat Knowledgebase article to learn more about programmatically generating the JSON requests.

7.5.2. Deploy an Application in a Managed Domain Using the HTTP API

By default, the HTTP API is accessible at http://HOST:PORT/management, for example, http://localhost:9990/management.

Deploy an Application
  1. Add the deployment to the content repository.

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}],"json.pretty":1}'
  2. Add the deployment to the desired server group.

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "add", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
  3. Deploy the application to the server group.

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "deploy", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
Undeploy an Application
  1. Remove the deployment from all server groups to which it is assigned.

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "remove", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
  2. Remove the deployment from the content repository.

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "remove", "address" : {"deployment" : "test-application.war"}, "json.pretty":1}'

7.6. Customizing Deployment Behavior

7.6.1. Define a Custom Directory for Deployment Content

You can define a custom location for JBoss EAP to store deployed content.

Define a Custom Directory for a Standalone Server

By default, deployed content for a standalone server is stored in the EAP_HOME/standalone/data/content directory. This location can be changed by passing in the -Djboss.server.deploy.dir argument when starting the server.

$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content

The chosen location should be unique among JBoss EAP instances.

Note

The jboss.server.deploy.dir property specifies the directory to be used for storing content that has been deployed using the management console or management CLI. To define a custom deployment directory to be monitored by the deployment scanner, see Configure the Deployment Scanner.

Define a Custom Directory for a Managed Domain

By default, deployed content for a managed domain is stored in the EAP_HOME/domain/data/content directory. This location can be changed by passing in the -Djboss.domain.deployment.dir argument when starting the domain.

$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content

The chosen location should be unique among JBoss EAP instances.

7.6.2. Control the Order of Deployments

JBoss EAP offers fine-grained control over the order of deployments when the server is started. Strict order of the deployment of applications present in multiple EAR files can be specified along with persistence of the order after a restart.

You can use the jboss-all.xml deployment descriptor to declare dependencies between top-level deployments.

For example, if you have an app.ear that depends on framework.ear being deployed first, then you can create an app.ear/META-INF/jboss-all.xml file as shown below.

<jboss umlns="urn:jboss:1.0">
  <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
    <dependency name="framework.ear" />
  </jboss-deployment-dependencies>
</jboss>
Note

You can use the deployment’s runtime name as the dependency name in the jboss-all.xml file.

This ensures that framework.ear is deployed before app.ear.

Important

Although the jboss-all.xml file and other deployment descriptors allow you to declare dependencies that the server does not otherwise detect, it is not a strict ordering feature. JBoss EAP assumes that all dependencies specified in the deployment descriptor have already been deployed or are available. If there are missing dependencies, JBoss EAP does not automatically deploy them, and the deployment fails.

7.6.3. Override Deployment Content

A deployment overlay can be used to overlay content into an existing deployment without physically modifying the contents of the deployment archive. It allows you to override deployment descriptors, JAR files, classes, JSP pages, and other files at runtime without rebuilding the archive.

This can be useful if you need to adapt a deployment for different environments that need different configurations or settings. For example, when moving a deployment through the application lifecycle from development, to testing, to stage, and finally into production, you might want to swap deployment descriptors, modify static web resources to change the branding of the application, or even replace JAR libraries with different versions depending on the target environment. It is also a useful feature for installations that need to change a configuration but can not modify or crack an archive due to policy or security restrictions.

When defining a deployment overlay, you specify the file on a file system that will replace the file in the deployment archive. You must also specify which deployments should be affected by the deployment overlay. Any affected deployments must be redeployed in order for the changes to take effect.

Use the deployment-overlay add management CLI command to add a deployment overlay.

deployment-overlay add --name=new-deployment-overlay --content=WEB-INF/web.xml=/path/to/other/web.xml --deployments=test-application.war --redeploy-affected
Note

In a managed domain, specify the applicable server groups by using --server-groups or specify all server groups with --all-server-groups.

Once created, you can add content to an existing overlay, link the overlay to a deployment, or remove the overlay. For full usage details, execute deployment-overlay --help.

Parameters

name
The name of the deployment overlay.
content
Comma-separated list that maps the file on the file system to the file in the archive that it will replace. The format for each entry is ARCHIVE_PATH=FILESYSTEM_PATH.
deployments
Comma-separated list of deployments to which this overlay will be linked.
redeploy-affected
Redeploys all affected deployments.

7.6.4. Using Rollout Plans

About Rollout Plans

In a managed domain, operations targeted at domain or host level resources can potentially impact multiple servers. Such operations can include a roll out plan detailing the sequence in which the operation would be applied to the servers, as well as the policies for detailing whether the operation could be reverted if it fails to execute successfully on some servers. If no rollout plan is specified, the default rollout plan is used.

Below is an example rollout plan involving five server groups. Operations can be applied to server groups serially (in-series) or concurrently (concurrent-groups). The syntax is described in more detail in 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"
}}}

Looking at the example above, applying the operation to the servers in the domain is done in three phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well.

  1. Server groups group-A and group-B will have the operation applied concurrently. The operation will be applied to the servers in group-A in series, while all servers in group-B will handle the operation concurrently. If more than 20% of the servers in group-A fail to apply the operation, it will be rolled back across that group. If any servers in group-B fail to apply the operation it will be rolled back across that group.
  2. Once all servers in group-A and group-B are complete, the operation will be applied to the servers in group-C. Those servers will handle the operation concurrently. If more than one server in group-C fails to apply the operation it will be rolled back across that group.
  3. Once all servers in group-C are complete, server groups group-D and group-E will have the operation applied concurrently. The operation will be applied to the servers in group-D in series, while all servers in group-E will handle the operation concurrently. If more than 20% of the servers in group-D fail to apply the operation, it will be rolled back across that group. If any servers in group-E fail to apply the operation it will be rolled back across that group.
Rollout Plan Syntax

You can specify a rollout plan in either of the following ways.

Although each method has a different initial command, both methods use the rollout operation header to define the rollout plan. This uses the following syntax.

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]
  • PLAN_NAME is the name for the rollout plan that was stored using the rollout-plan command.
  • SERVER_GROUP_LIST is the list of server groups. Use a comma (,) to separate multiple server groups to indicate that that operations should be performed on each server group sequentially. Use a caret (^) separator to indicate that operations should be performed on each server group concurrently.

    • For each server group, set any of the following policies in parentheses. Comma separate multiple policies.

      • rolling-to-servers: A boolean which if set to true, the operation will be applied to each server in the group in series. If the value is false or not specified, the operation will be applied to the servers in the group concurrently.
      • max-failed-servers: An integer which takes the maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is 0, meaning that a failure on any server will trigger rollback across the group.
      • max-failure-percentage: An integer between 0 and 100 that represents the maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is 0, meaning that a failure on any server will trigger rollback across the group.

        Note

        If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.

  • rollback-across-groups: A boolean that indicates whether the need to rollback the operation on all the servers in one server group triggers a rollback across all the server groups. This defaults to false.
Deploy Using a Rollout Plan

You can provide the full details of a rollout plan directly to the deploy command by passing the rollout settings into the headers argument. See the Rollout Plan Syntax for more information on the format.

The following management CLI command deploys an application to the main-server-group server group using a deployment plan that specifies rolling-to-servers=true for serial deployment.

deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}
Deploy Using a Stored Rollout Plan

Since rollout plans can be complex, you have the option to store the details of a rollout plan. This allows you to reference the rollout plan name when you want to use it instead of requiring the full details of the rollout plan each time.

  1. Use the rollout-plan management CLI command to store a rollout plan. See the Rollout Plan Syntax for more information on the format.

    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}

    This creates the following deployment plan.

    "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
    }
  2. Specify the stored rollout plan name when deploying the application.

    The following management CLI command deploys an application to all server groups using the my-rollout-plan stored rollout plan.

    deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
Remove a Stored Rollout Plan

You can remove a stored rollout plan using the rollout-plan management CLI command by specifying the name of the rollout plan to remove.

rollout-plan remove --name=my-rollout-plan
Default Rollout Plan

All operations that impact multiple servers will be executed with a rollout plan. If no rollout plan is specified in the operation request, a default rollout plan will be generated. The plan will have the following characteristics.

  • There will only be a single high-level phase. All server groups affected by the operation will have the operation applied concurrently.
  • Within each server group, the operation will be applied to all servers concurrently.
  • Failure on any server in a server group will cause rollback across the group.
  • Failure of any server group will result in rollback of all other server groups.