Valid since:
XL Deploy 5.0.1

This scenario shows how you can use the sequential-by-loadbalancer-group orchestrator to deploy to web servers and application servers.

Assume that you have a web site that consists of two groups of physical servers. Each group represents one side of the infrastructure in the load balancer: side A and side B.

To simplify this scenario, assume that each side consists of one physical machine on which you have installed one Apache web server and one WebLogic application server. In reality, each side might consist of more than one machine with more than one web server and there can be a cluster of application servers.

The goal is to deploy a new version of an application to the web site. The application consists of web content (static HTML, pictures, and so on) and an EAR file. Web content is deployed to the Apache web server and the EAR file is deployed to the WebLogic application server.

To deploy a new version of the application, you must:

  • For side A:
    • Disable access to Side A in the load balancer
    • Upgrade the application
    • Enable access to Side A
  • For side B:
    • Disable access to Side B in the load balancer
    • Upgrade the application
    • Enable access to Side B

The end-user experience depends on the static web content and enterprise application being deployed in sync. This means that you cannot deploy only static web content and enable access to it before the enterprise application is fully deployed on the same side of the web site. You want to avoid having static content that points to an application that has not been deployed yet. Therefore, you want to execute the deployment in parallel as much as possible.

Step 1 Define application and infrastructure building blocks

This is the application that will be deployed:

  1. Application that has some static web content: web-content
  2. Application that consists of an EAR file: PetClinic-ear
  3. Composite application that consists of static web content and an EAR file: LB-Application

And this is the infrastructure where it will be deployed:

  1. Define Apache web server sideA-apache
  2. Define Apache web server sideB-apache
  3. Define WebLogic server sideA-wls
  4. Define WebLogic server sideB-wls

This is how it looks in the Repository:

Basic infrastructure

To define the load balancer, create a F5 BIG-IP load balancer and add sideA-apache, sideB-apache, sideA-wls, and sideB-wls as load balancer members.

Load balancer members

Step 2 Create the default deployment plan

If you create a deployment without any customization:

Basic deployment

The resulting deployment plan will be:

Basic deployment plan

Step 3 Divide the deployment into groups

To divide the deployment into two groups, edit the servers in the Repository:

  1. Associate servers sideA-apache and sideA-wls to group 1
  2. Associate servers sideB-apache and sideB-wls to group 2

This is the configuration for the server sideA-apache:

Associate sideA-apache to deployment group 1

Step 4 Add the sequential-by-deployment-group orchestrator

Now you can use the Deployment Properties to add the sequential-by-deployment-group orchestrator:

Enable sequential-by-deployment-group orchestrator

Note: Plan optimization has been disabled to help you track orchestrations.

XL Deploy generates the deployment plan:

Deployment plan with sequential-by-deployment-group orchestrator

Step 5 Parallelize deployment to the servers in each group

Now you can parallelize deployment to the servers in each group by defining additional sub-groups. Put the Apache servers into sub-group 1 and wls servers into sub-group 2.

This is the configuration for the sideA-wls server:

Associate sideA-wls to deployment sub-group 2

Step 6 Add the parallel-by-deployment-sub-group orchestrator

Use the Deployment Properties to add the parallel-by-deployment-sub-group orchestrator.

Enable parallel-by-deplyoment-sub-group orchestrator

XL Deploy generates the deployment plan:

Deployment plan with parallel-by-deployment-sub-group orchestrator

However, this plan does not exactly meet the goal. With this plan, XL Deploy would do the following in parallel:

  1. Deploy to Apache web server
    1. Disable access to Apache web server in load balancer
    2. Deploy to Apache web server
    3. Enable access to Apache web server in load balancer
  2. Deploy to WebLogic application server
    1. Disable access to WebLogic application server in load balancer
    2. Deploy to WebLogic application server
    3. Enable access to Apache web server in load balancer

This means that access to the web site would be allowed, even if it is not fully deployed. Typically, deployment of web content will be faster than deployment of enterprise applications, and users will probably be able to access static web content while the back-end applications are still being deployed.

Step 7 Add the sequential-by-loadbalancer-group orchestrator

To meet the goal, XL Deploy should do the following, sequentially:

  1. Disable access to Apache web server and WebLogic application server
    1. Disable access to Apache web server in load balancer
    2. Disable access to WebLogic application server in load balancer
  2. In parallel:
    1. Deploy to Apache web server
    2. Deploy to WebLogic application server
  3. Enable access to the Apache web server and WebLogic application server
    1. Enable access to WebLogic application server in load balancer
    2. Enable access to Apache web server in load balancer

To achieve this, use the Deployment Properties to add the sequential-by-loadbalancer-group orchestrator.

Enable sequential-by-loadbalancer-group orchestrator

XL Deploy generates the deployment plan:

Deployment plan with sequential-by-loadbalancer-group orchestrator

The sequential-by-loadbalancer-group orchestrator transforms the sub-plans into a new sequential plan that:

  1. Disables access to all containers in original sub-plan
  2. Deploys as with original sub-plan
  3. Enables access to all containers in original sub-plan

Unfortunately, the sequential-by-loadbalancer-group orchestrator is applied too late and access to the web site might be enabled too soon. To fix this, move the orchestrator up one level:

Move up sequential-by-loadbalancer-group orchestrator

The deployment plan now looks like:

Deployment plan with sequential-by-loadbalancer-group orchestrator in right place

Step 8 Optimize the deployment plan

Finally, enable deployment plan optimization:

Enable Optimize Plan

XL Deploy generates the deployment plan:

Optimized deployment plan

Which satisfies the goal.