Innovations within reach: Leveraging the IBM Workload Deployer CLI to automate WebSphere application deployments

Middleware environments are becoming increasingly complex. Developers search for ways to eliminate time spent waiting for others to deploy new application code, administrators cope with the emergence of clouds and ever-faster software release cycles by automating the deployment process, and managers know they can save significantly in time and money by eliminating inefficiencies in the IT workflow. This article describes possible ways to address these needs by integrating IBM® Workload Deployer into an existing automation software lifecycle solution with XebiaLabs' deployment automation product, Deployit . This content is part of the IBM WebSphere Developer Technical Journal.


Vincent Partington (, Chief Technical Officer, XebiaLabs

Vincent Partington is a technology entrepreneur and an Internet industry veteran with over 15 years of experience. Vincent’s passion for technology began while studying computer science at the University of Amsterdam where Vincent was involved heavily in the then budding Internet scene in Amsterdam, working at the first free Internet service (De Digitale Stad) from 1995 onwards. After graduating in 1997, he continued his work in the Internet industry. He quickly stumbled upon what was later to become J2EE and delivered his first Enterprise Java application in 1998.

After working in the Java EE space at different companies, Vincent Partington joined Xebia, in 2003. At Xebia, Vincent performed a whole range of assignments covering the spectrum of the activities of Xebia IT Architects: middleware architecture, automated build and deployment systems, performance tuning, security assessments, SOA architecture and numerous software audits. He has also taught a number of courses on Enterprise Java topics such as security and the Spring framework.

Seeing a need for standard Java EE deployment automation, Vincent Partington founded the startup XebiaLabs in the summer of 2008. After delivering the first version of the product to launching customer KLM, the product, Deployit, was extended to not only support WebSphere Application Server but a host of other middleware platforms including Oracle WebLogic Server, JBoss Application Server and Tomcat. As the Chief Technical Officer of XebiaLabs Vincent is involved in development of the product and research into new features and new directions for the product.

Vincent Partington holds a masters degree in Computer Science from the University of Amsterdam in the Netherlands. You can contact him at or follow him on Twitter at @vpartington.

03 August 2011

Also available in Chinese

Each installment of Innovations within reach features new information and discussions on topics related to emerging technologies, from both developer and practitioner standpoints, plus behind-the-scenes looks at leading edge IBM® WebSphere® products.

Complete, complementary deployments

IBM Workload Deployer V3 and Deployit from XebiaLabs both "deploy" things, but they deploy different things. Deployit deploys application artifacts and resources, such as EAR files and data sources, to middleware systems like IBM WebSphere Application Server (but also HTML to web servers, IBM WebSphere MQ configurations to queue managers, and so on). IBM Workload Deployer, on the other hand, deploys patterns (or topologies) of virtual images to hypervisors -- but not just any kind of virtual images. IBM Workload Deployer is especially geared toward deploying middleware topologies.

IBM Workload Deployer and WebSphere CloudBurst

IBM Workload Deployer V3 is an updated and enhanced version of the WebSphere CloudBurst Appliance, renamed to reflect the expanded scope of workloads it can deploy, which are no longer limited to only WebSphere workloads. The content for this article (including screen captures) was created using a WebSphere CloudBurst Appliance, but everything noted here is equally applicable to IBM Workload Deployer V3. However, for the sake of consistency with the images presented, "WebSphere CloudBurst" is used throughout this article to refer to both products.

In other words, IBM Workload Deployer deploys the middleware systems and Deployit deploys applications to those middleware systems -- complementary functionalities that form a perfect fit.

At XebiaLabs, we have been working on two exciting new integrations for Deployit. We created a Deployit plugin that enables you to deploy EAR files directly to virtual systems created by IBM Workload Deployer V3 or its predecessor, IBM WebSphere CloudBurst Appliance V2. We also created a WebSphere CloudBurst script package to deploy application artifacts and resources on newly created virtual systems.

This article explores two integrations between WebSphere CloudBurst and Deployit as a way of showing how you can leverage the WebSphere CloudBurst command line interface and script packages to integrate cloud deployment with your application deployment automation solution.

The command line interface

The first integration we’ve built is to invoke WebSphere CloudBurst from Deployit. In this scenario, Deployit invokes WebSphere CloudBurst to deploy a pattern and to read the information about the pattern just deployed so that Deployit can deploy the Java™ EE application to it. Deployit uses the WebSphere CloudBurst command line interface (CLI) to do this.

You can download the WebSphere CloudBurst CLI as described in the Information Center. The small 2.2MB package that you get requires a Java virtual machine (JVM) to run and includes a Jython interpreter. It can be run interactively or with a Jython script that needs to be run. The CLI will seem familiar if you’re accustomed to wsadmin.

The API exposed by the WebSphere CloudBurst CLI is pretty straightforward and starts with the cloudburst object. You can get more information about this object and its sub-objects by typing help(cloudburst) on the command line. For this integration, we used the following resource collections:

  • cloudburst.patterns is the list of patterns managed by the WebSphere CloudBurst Appliance.
  • cloudburst.clouds is the list of cloud groups on the WebSphere CloudBurst Appliance.
  • cloudburst.virtualsystems is the list of virtual systems managed by the WebSphere CloudBurst appliance.

Deploying a pattern

To deploy a pattern with the WebSphere CloudBurst CLI, you basically need to select the pattern to deploy from the cloudburst.patterns resource collection, select the cloud groups to deploy to from the cloudburst.clouds resource collection, and then call cloudburst.virtualsystems.create with those objects and the name of the virtual system to create. Actually, you'll also need to pass in the password to be used for the new image and for the WebSphere Application Server installation that will be installed on it.

After calling cloudburst.virtualsystems.create you’ll need to use the waitForcommand to wait until the deployment has finished, and then print the final state of the virtual system so that Deployit can retrieve that from the output.

To do all this, the WebSphere CloudBurst CLI script to create a virtual system ( by deploying a pattern looks like Listing 1.

Listing 1
#!/usr/bin/env cloudburst

from time import sleep
from socket import gethostbyaddr

patternName = sys.argv.pop(0)
cloudName = sys.argv.pop(0)
systemName = sys.argv.pop(0)
systemPassword = sys.argv.pop(0)

print "Deploying pattern", patternName, "to cloud", cloudName, "with name", systemName

myPattern = cloudburst.patterns[patternName][0]
myCloud = cloudburst.clouds[cloudName][0]
mySystem = cloudburst.virtualsystems.create({'name': systemName, 'cloud': myCloud, 
'pattern': myPattern, '*.*.password': systemPassword})

mySystem = cloudburst.virtualsystems[systemName][0]

print "Deployed pattern", patternName, "to cloud", cloudName, "with name", systemName

mySystem = cloudburst.virtualsystems[systemName][0]
print "state:", mySystem.currentstatus_text

You can invoke the script with this command:

$ <path-to-cloudburst-cli>/bin/cloudburst -h <appliance> -u <username> -p <password> -f <patternName> <cloudName> <systemName> <systemPassword>

Reading information about a virtual system

After WebSphere CloudBurst has deployed the pattern, Deployit needs to know the hostname and IP address of the virtual system that was created. The WebSphere CloudBurst CLI script in Listing 2 ( will be run and Deployit will read the IP address and the hostname of the virtual system that was created from the output of this script.

Listing 2
#!/usr/bin/env cloudburst

from time import sleep
from socket import gethostbyaddr

systemName = sys.argv.pop(0)

print "Reading information about virtual system", systemName

mySystem = cloudburst.virtualsystems[systemName][0]
print "state:", mySystem.currentstatus_text
ipaddr = mySystem.virtualmachines[0].ip.ipaddress
print "ipaddr:", ipaddr
hostname = gethostbyaddr(ipaddr)[0]
print "hostname:",hostname

Putting it together: from Deployit to WebSphere CloudBurst

To finish the integration, the two scripts above are bundled in a Depoyit plug-in. (Details about the plug-in are beyond the scope of this article.) To give you an idea of how to use this integration, this is what it looks like when it has been put together in Deployit:

  1. From the Deployit UI (Figure 1), you select the application artifacts and resources you want to deploy. Version 1.0 of the PetClinic-ear application in this case.
  2. Select the WebSphere CloudBurst Appliance to which you want to deploy.
  3. Enter the name of the WebSphere CloudBurst pattern to deploy and the cloud group in which to deploy it.
    Figure 1. Select application artifacts to deploy in Deployit
    Figure 1. Select application artifacts to deploy
  4. Press the Deploy button in Deployit to start the deployment.
  5. Deployit starts the pattern deployment in WebSphere CloudBurst (Figure 2) by invoking the WebSphere CloudBurst CLI script.
    Figure 2. Deploy patterns in WebSphere CloudBurst
    Figure 2. Deploy patterns in WebSphere CloudBurst
  6. When the pattern deployment is finished, Deployit reads the information about the newly created virtual system and the middleware that’s on it. For this, Deployit first invokes the WebSphere CloudBurst CLI script and then starts its standard WebSphere Application Server discovery process to read the topology of the WebSphere Application Server profile that was just created.
  7. Finally, Deployit installs the application on it (Figure 3), using the existing Deployit logic to deploy to WebSphere Application Server environments.
    Figure 3. Install applications with Deployit
    Figure 3. Install applications with Deployit

From development-centric to operations-centric

The integration above is one way to integrate WebSphere CloudBurst into a deployment automation system. You could say that it is the development-centric approach: you have an application to deploy and select an on-demand environment to deploy it to. The application deployment system, Deployit in this case, makes sure that environment is there and then deploys to it.

The alternative could be called the operations-centric approach: a system administrator wants to scale out the infrastructure and needs an application to be installed on that system for it to be fully functional. In this scenario, WebSphere CloudBurst will call out to the deployment automation solution to deploy the application onto a newly created virtual system.

Script packages

While the WebSphere CloudBurst CLI provides a way to call into WebSphere CloudBurst, script packages provide a way to call out from WebSphere CloudBurst to another system. In its simplest form, a script package is just a .zip or tar.gz file that you can add to the WebSphere CloudBurst catalog and associate with a pattern. When that pattern is deployed, the script packages gets copied to the selected hosts in the pattern and the command is specified when the script package that was created gets executed.

However, two things make script packages more powerful. First, you can define variables that a user must enter when deploying a pattern with that script package in it. These values get added to the environment variables that are available by default to the executing command.

Second, you can define the configuration for a script package in the script package itself using a JSON object. This enables the script package developer to pre-define the configuration and alleviates this burden from the WebSphere CloudBurst administrator.

Invoking a deployment automation system with script packages

Because anything can be placed inside a script package, we’ll put the Deployit CLI (a Jython-based CLI similar to wsadmin and the CloudBurst CLI itself) in the script package. When the script package is executed, the Deployit CLI is run to tell the Deployit server (running on a different machine) to discover the newly created virtual system and then deploy the application on that discovered environment.

The most interesting part of this integration is the JSON object. It defines:

  • Where to extract the script package (location).
  • What command to run (command) and, most importantly,
  • The variables (keys) that the user has to enter.

In this case, you want the WebSphere CloudBurst user to tell you the application (APPLICATION) to deploy and the version of that application (VERSION). (Listing 3).

Listing 3
"name": "Invokes Deployit to deploy an application",
"version": "1.0.0",
"description": "This script package invokes Deployit to deploy an application onto 
the pattern",
"command": "/opt/tmp/deployit-scriptpackage/",
"log": "/opt/tmp/deployit-scriptpackage/logs",
"location": "/opt/tmp/deployit-scriptpackage",
"timeout": "0",
"commandargs": "$APPLICATION $VERSION",
"keys": [
"scriptkey": "APPLICATION",
"scriptvalue": "",
"scriptdefaultvalue": ""
"scriptkey": "VERSION",
"scriptvalue": "",
"scriptdefaultvalue": ""

The script (Listing 4) referenced from the script package configuration sets the TARGETHOST environment variables used by the Deployit CLI script to discover the WebSphere Application Server profile, sets the APPLICATION and VERSION environment variables that are used to determine what version of what application to deploy, and then invokes the Deployit CLI to run the script.

Listing 4

export JAVA_HOME=/opt/IBM/HTTPServer/Plugins/java/jre
export VERSION=$2
export TARGETHOST=`hostname`
echo "Deploying version $VERSION of application $APPLICATION to WAS on virtual host 

cd `dirname $0`

chmod +x bin/
bin/ -host deployit -username admin -password admin -f

Putting it together: from WebSphere CloudBurst to Deployit

This is the scenario a system administrator would follow:

  1. Add the script package to the WebSphere CloudBurst Appliance.
    Figure 4. Add script package
    Figure 4. Add script package
  2. Associate the script packages with one or more patterns.
  3. Create a virtual system from one of those patterns. While doing so, enter the name and version of the application to deploy (Figure 5).
    Figure 5. Specify application to deploy
    Figure 5. Specify application to deploy

After the virtual system has been created, the script package is executed. The script package invokes the Deployit CLI to tell the Deployit server to discover the WebSphere Application Server profile on the newly created virtual system. The script package invokes the Deployit CLI to tell the Deployit server to deploy the version 1.0 of the PetClinic-ear application on that new WebSphere Application Server profile (Figure 6).

Figure 6. Deploying the applicationi
Figure 6. Deploying the applicationi


While this article stayed at a high level, two points should resonate from these two integrations:

  • The integration features offered by the WebSphere CloudBurst CLI and the WebSphere CloudBurst Applicance script packages make for a very extensible, powerful platform that can be integrated into a build and deployment automation system quite easily.
  • Whether to trigger WebSphere CloudBurst pattern deployment from application deployment (the first scenario) or trigger application deployment from a WebSphere CloudBurst pattern deployment (the second scenario) is a choice you need to make, depending on which makes more sense with your use cases.

Most importantly, integrations like these show that an application deployment automation system such as Deployit and WebSphere Cloudburst can be seamlessly integrated to give you the ability to deploy your application to cloud environments without needing a lot of knowledge on cloud infrastructure and provisioning systems. This enables developers to set up new development environments from the Deployit self-service UI, it enables testers to set up their own testing environments -- often a bottleneck in enterprise development -- and, finally, it enables application deployers to deploy applications to virtual environments.

In short, all this enables you to go from an on demand infrastructure to on demand applications!



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Cloud computing, Agile transformation
ArticleTitle=Innovations within reach: Leveraging the IBM Workload Deployer CLI to automate WebSphere application deployments