Configure a complex cloud app test system

Using IBM Workload Deployer and Collaborative Application Lifecycle Management

Cloud applications continue to grow more complex, making the task of rapidly delivering a cloud solution, whether it is just a production-level application or an intricate virtual application or system pattern, more difficult. To answer this challenge, the author examines the complexity involved in attempting to establish a working, easily repeatable Collaborative Lifecycle Management system (CLM; also referred to as Collaborative Application Lifecycle Management) running on an IBM® WebSphere® Application Server using DB2® as the database.

Bradley C. Herrin (bcherrin@us.ibm.com), Software Engineer, IBM

Herrin began working for IBM as a co-op while completing his Computer Science undergraduate at North Carolina State University. He started his career with the Rational Application Developer (RAD) test team with a focus in JSF and JPA web tools. While working for the RAD team, Herrin had the chance to develop some highly agile install/configuration automation using Rational Build Forge; this opportunity opened the door for a move to the Rational Core Automation Team where his focus today is on leveraging cloud technologies with integrated automation. Herrin has a strong background in product testing, cloud computing, rapid provisioning tools, automation, and Linux. The use of cloud with automation is his true software passion and is a technology that he feels will revolutionize the way we test the products of tomorrow.



22 March 2012

Also available in Chinese Russian Japanese Portuguese

Cloud applications continue to grow more complex, making the task of rapidly delivering a cloud solution — a one-off production-level application, an application within a deployment package along with operating system, or even an intricate virtual application pattern (a cloud component/middleware service and a policy for configuration purposes) or virtual system pattern (one or more virtual images and applications that implements a deployment topology) — more difficult.

To answer this challenge and examine this complexity, this article demonstrates how to establish a working, easily repeatable Collaborative Lifecycle Management system that runs on WebSphere Application Server using DB2 as the database. IBM Workload Deployer and the Rational® Team Concert CLM feature are used. The end result is a topology that testers can reproduce in a daily, on-the-fly build to verify app defects and builds, perform smoke tests, and enable other testing activities.

Let's begin

IBM Workload Deployer (IWD) is a hardware appliance that gives users an environment in which they can deploy repeatable patterns (or repeatable solutions) of middleware onto a private cloud.

The initial problem presented to the team involved how to overcome the challenges of the complexity of establishing a working CLM system running on WebSphere using DB2 as the database vendor in a repeatable time saving manner. The parameters of the problem included:

  • Testers need to be able to reproduce this topology with daily builds on the fly for defect verification, build verification, smoke testing (a non-granular look at whether an entire system functions in a general way), etc.
  • The average tester was spending roughly 3 to 5 working days installing and configuring a test system before testing scenarios could be executed.

To change this culture, IWD and integrated automation functions (such as bash and Python scripts and WSAdmin) were used through the development of IWD script packages to offer a repeatable solution. It took the team 60 minutes using the following steps.


Step 1: Establish the foundation

The solution pattern topology in this article takes an out-of-the-box Red Hat Enterprise Linux® 64-bit WebSphere 8.0.0.1 Network Deployment virtual image (virtual image pre-installed with WebSphere ND version 8.0.0.1 and IBM Installation Manager 1.4.4) and with added script packages, it installs, configures, and deploys CLM onto the virtual image in conjunction with an out-of-the-box RHEL 64-bit DB2 V9.7.4 virtual image. Figure 1 illustrates the CLM topology the IWD VSP maps to, a visual representation of the VSP this article discusses.

Figure 1. The CLM topology the IWD VSP maps to
The CLM topology the IWD VSP maps to

In this case, CLM is running on a WebSphere V8.0.0.1 server with CLM data being housed on a DB2 V9.7.4 server.

One of the great assets of IWD is its ability to establish the relationship between the different virtual images in the pattern. The existing relationship (shown by the arrow between virtual system parts) allows you to openly communicate between the CLM data and the application itself, in turn resulting in a much more developer friendly environment for multi-server designs. Figure 2 illustrates the relationship established by IWD.

Figure 2. The relationship established by IWD
The relationship established by IWD

The arrow shows that the WebSphere 8.0.0.1 server recognizes the DB2 9.7.4 server. Thus communication between the two servers is not a complicated battle the user has to forge out (threading his way among firewalls, proxies, etc.).

Once the foundation for the solution is established, the next steps are to prepare the WebSphere server and the DB2 server for CLM application deployment.


Step 2: Create databases (JTS, CCM, QM, DW)

We developed a script package composed of a Linux bash script to invoke the db2admin (DB2 administration server command) to silently create the databases CLM requires for each of the applications.

The parent bash script:

#!/bin/sh
su - db2inst1 -c "sh /tmp/createDatabases.sh"

The child bash script:

#!/bin/sh
db2 CREATE DATABASE jtsDB AUTOMATIC STORAGE YES ON '/db2fs' DBPATH ON '/db2fs' 
 USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM PAGESIZE 16384

Step 3: Update pre-installed Installation Manager to version 1.5.2

CLM 4.0 has a dependency on Installation Manager; it needs version 1.5.2. We updated the out-of-the-box version using an Installation Manager response file wrapped into an IWD script package.

The sample bash script:

echo "Enter IM Directory"
cd /opt/IBM/InstallationManager/eclipse

echo "Launching IM 1.5.2 Update"
./IBMIM --launcher.ini silent-install.ini -input $IMFilePath/imUpdate152.xml
 -keyring $IMFilePath/im.keyring -accessRights admin -acceptLicense

The sample IM update response file template:

<?xml version="1.0"?>
<agent-input clean="true" temporary="true">
<server>
<repository location="<IM repository>"/>
</server>
<install>
<offering features="agent_core,agent_jre" id="com.ibm.cic.agent"
 version="<IM BUILD Version>"/>
</install>
<profile id="IBM Installation Manager" installLocation="/opt/IBM/InstallationManager"
 kind="self"><data key="eclipseLocation" value="/opt/IBM/InstallationManager"/>
 </profile>
</agent-input>

Step 4: Install CLM on a WebSphere server

The next step is to get the CLM bits onto the WebSphere Application Server. In this scenario, users need the ability to get specific builds of CLM. Taking this into consideration, the team used Build IDs as a parameter of specification in the script package for installing CLM.

At provisioning time, the user is prompted for the Build ID that is substituted into the Installation Manager generated response files using bash commands.

The invoking bash script:

#!/bin/sh
. /etc/virtualimage.properties

echo "CLM Build to be installed: "$CLM_BUILD_ID

echo "Substitute CLM Build ID"

sed -i s%CLM_BUILD_ID_1%$CLM_BUILD_ID% /tmp/CLM/CLM.xml
sed -i s%CLM_BUILD_ID_2%$CLM_BUILD_ID% /tmp/CLM/CLM.xml

echo "Install CLM 4.x via Installation Manager"

cd /opt/IBM/InstallationManager/eclipse
./IBMIM --launcher.ini silent-install.ini -input /tmp/CLM/CLM.xml
 -keyring /tmp/CLM/im.keyring -acceptLicense -accessRights admin

Exit

Step 5: Configure WebSphere Server/deploy CLM apps

The final step of the pattern solution is to configure WebSphere with the appropriate settings required before CLM WAR files can be deployed onto the server.

To let us configure the WebSphere server for our needs, the team created a Python script that invokes the AdminTask object:

print "-------Set Run as User to Root------"
#Set Run as Root
AdminConfig.modify('(cells/CloudBurstCell_1/nodes/CloudBurstNode_1/servers/
 server1|server.xml#ProcessExecution_1183122130078)', '[[runAsUser "root"]
 [runAsGroup ""] [runInProcessGroup "0"] [processPriority "20"] [umask "022"]]') 

print "-------Save Master Configuration-------"
#Save to Master Config
AdminConfig.save()

After configuring WebSphere, we have to configure the teamserver.properties files, create database tables, and deploy the CLM WAR files onto the server.

The team included the teamserver.properties templates in the configuring script package. The templates are populated with the correct hostnames and database strings using bash string substitutions.

Following the string substitutions, the teamserver.properties files for each application are replaced with the customized template.

From this point it's just a matter of using the tools provided by the CLM install. The CLM install provides a set of repository tools (repotools) that can be used to create the tables in the pre-existing databases, thus removing another step from the user during the Jazz Team Server (JTS) setup wizard.

Repotool example:

echo "------Run Repo Tools for JTS Tables------"
cd /opt/IBM/JazzTeamServer/server
./repotools-jts.sh
 -createTables teamserver.properties=
 "/opt/IBM/JazzTeamServer/server/conf/jts/teamserver.properties"
  logFile=repotools.log

Finally, we deployed the application WAR files onto the WebSphere server using a Python script. The script is passed to the WebSphere Admin program (wsadmin.sh), and from there it is invoked to perform the application deployment.

The sample Python script for application deployment:

def deployJazzApp(app_name):

    print "====== installing " + app_name + " Web Application on WAS ======\n"
    app_war= app_name + '.war'
    installed_appname = app_name + '_war'
    app_ctx = '/' + app_name
    appfile = properties.getProperty("CLM_HOME") + "/server/webapps/" + app_war

installcmd = ""

AdminApp.install(appfile, installcmd)
    AdminConfig.save()
    print "====== application " + app_name + " is installed on WAS =========\n"

print "====== Install completed. Please restart your WAS server.============\n"

After the application is deployed, the WebSphere server is restarted and the users are ready to step through the JTS setup wizard and register any of the CLM applications they want. Figure 3 shows how the pattern looks at the end of the process.

Figure 3. Final pattern view
Final pattern view

In conclusion

The team developed this pattern to provide testers with the ability to deploy a CLM/WebSphere/DB2 topology rapidly at anytime with the additional flexible capability of being able to pick up specific builds. However, the design has proved to be more useful than our original intentions. It is a technology that any Rational software engineer can use and the types of people using it extends beyond system verification testers to include:

  • Functional verification testers who test the latest code check-ins.
  • Build verification testers who verify that daily builds are stable.
  • Developers creating products that test integrations with CLM.

The CLM pattern solution is a small taste of what IWD can provide and is also a display of how the quality of software can be increased from innovation at all levels of the development process. By implementing the solution in Rational, the team managed to deliver to users the ability to reallocate the precious resource of time, the time they spend setting up and configuring CLM; they can spend most of that now developing and testing.

IWD has allowed us to dissolve test system complexity into simplicity.

Resources

Learn

Get products and technologies

Discuss

Comments

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 Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Cloud digest

    Complete cloud software, infrastructure, and platform knowledge.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, Rational, WebSphere, Information Management
ArticleID=806611
ArticleTitle=Configure a complex cloud app test system
publish-date=03222012