IBM WebSphere Application Server is a robust, enterprise class application server that provides a core set of components, resources, and services that developers can utilize in their applications. In this blog, I am going to talk about Application Edition Management and Automatic Deployment through scripting.
What is Application Edition Management?
Many business applications require constant availability. The standard for application availability asserts that applications are deployed on application server clusters. The redundancy of a cluster is essential to provide continuous availability. Interruption-free application upgrade refers to the ability to upgrade while maintaining application continuous availability. In other words, users of the application experience no loss of service during the application upgrade.
When you perform a rollout to an edition, you replace an active edition with a new edition. To provide interruption-free application upgrades, performing a rollout to an edition includes the following items:
- Fencing a server from receiving new requests.
- Quiescing requests for the application in a particular server.
- Stopping the currently active edition.
- Starting the new edition.
- Resuming the flow of requests to the edition.
To perform a rollout to a target cluster, you can divide the cluster into groups, and define a group size, which specifies the number of nodes to process at a time. Performing a rollout to a group results in the servers in each group being upgraded to the new edition at the same time. Each server in the group is quiesced, stopped, and reset. A rollout can be performed on only one group at a time in the administrative console. When any member in the new edition becomes available, all requests are routed to the new edition.
As you perform a rollout to the edition, some servers in the cluster move from the previous edition to the new edition, some servers are in the process of making the transition, and other servers have not started the transition. All application requests are sent to any server that has an active, running instance of the latest edition of the requested application. For example, when you perform a rollout from edition 1.0 to 2.0, all application requests are served by edition 2.0 when edition 2.0 becomes available on a server. Any servers that are still running edition 1.0 do not serve requests until this server is updated to edition 2.0.
Performing an atomic rollout to an edition replaces an edition on half of the cluster at a time to serve all user requests with a consistent edition of the application. All user requests are served by either the previous or the new edition; user requests are never served by both editions.
An atomic rollout ensures that all application requests are served by a consistent edition, for example, either edition 1.0 or 2.0, but not by both. The currently available edition is taken offline from half of the servers that comprise the cluster. In those servers, the new edition is activated and started, but those servers are held offline until the next step completes. The next step is to take the currently active edition offline in the remaining servers. At this point, no server has an instance of either edition available to serve application requests. The ODR temporarily queues any request that arrives for this application. After the application is fully offline, the first half of the cluster is brought back online. The second half of the cluster transitions from the previous edition to the next edition and is brought back online.
Automatic Deployment with Ant Script
I am assuming by now that you are comfortable with the edition management concept of WebSphere server. In this section I will try to explain how you can achieve it in your organization once deployment is finished. I am assuming the target deployable artifact (EAR, WAR etc) is already prepared by you. The automated script will perform following task for you:
- Install the deployable artifact on server
- Add the shared library reference to it
- Rollout the current edition
If you don’t have any shared library reference in your application then you can modify the script create your own version. You can use this script in both clustered and non-clustered environment with little modification in code. I will explain both processes here. So let’s get started.
You need to follow below steps in order to make below script to work:
- Download build.xml and save it into some accessible location.
- Update the values in all property tags as per your WebSphere.
- Once values are updated correctly, move this file to the server on some accessible location on which WebSphere Deployment Manager is running.
- The given script contains following targets:
- listApps : This command lists all the applications installed on the server
- installAppOnCluster : This command install and application ear on specified cluster
- installAppOnServer : This command install and application ear on specified server
- addSharedLibrary : This command will add shared library to the installed application
- rolloutApplication : This command rolls out an edition to server or cluster
- startDeploymentOnCluster : This command depends upon installAppOnCluster, addSharedLibrary and rolloutApplication. This is the target you need to run in order to start the deployment process on Cluster.
- startDeploymentOnServer : This command depends upon installAppOnServer, addSharedLibrary and rolloutApplication. This is the target you need to run in order to start the deployment process on Server.
- Update com.ibm.SOAP.requestTimeout = 1500 value in <WAS_HOME>/profiles/<Deployment_Manager_Profile>/properties/soap.client.props. Deployment Manager restart is required after this step.
- You need to download addSharedLibraryScript.py and save it to <WAS_HOME>/bin folder of your WAS installation. You don't need to update anything in this file.
- Once above step is completed, you need to place your deployable artifact at path specified against "server.home.dir" property in build.xml file.
- Once step 5 is completed make sure that deployment manager and the server (at least one server from the cluster if you are deploying app on cluster) on which this artifact needs to be installed is running.
- Depending upon where you want to install the app, run either startDeploymentOnCluster or startDeploymentOnServer target as below:
- Navigate to <WAS_HOME>/bin folder
- For Windows: ws_ant.bat -f <path_to_build.xml_file> "<target_name>" (target name has to be in quotes)
- For Linux: ./ws_ant.sh -f <path_to_build.xml_file> "<target_name>" (target name has to be in quotes)
- That is it, if everything goes well you will be able to install the new version of the application and be able to roll out it.
In addition to providing interruption free delivery of your application to your customer, you can also save the valuable manual deployment time if you use this script.