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.
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 220.127.116.11 Network Deployment virtual image (virtual image pre-installed with WebSphere ND version 18.104.22.168 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
In this case, CLM is running on a WebSphere V22.214.171.124 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 arrow shows that the WebSphere 126.96.36.199 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
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
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.
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
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.
For more on how to perform tasks in the IBM Cloud, visit these resources:
- Up and download files from a Windows instance.
- Install IIS web server on Windows 2008 R2.
- Create an IBM Cloud instance with the Linux command line.
- Create an IBM Cloud instance with the Windows command line.
- Extend your corporate network with the IBM Cloud.
- High availability apps in the IBM Cloud.
- Parameterize cloud images for custom instances on the fly.
- Windows-targeted approaches to IBM Cloud provisioning.
- Deploy products using rapid deployment service.
- Integrate your authentication policy using a proxy.
- Configure the Linux Logical Volume Manager.
- Deploy a complex topology using a deployment utility tool.
- Provision and configure an instance that spans a public and private VLAN.
- Secure IBM Cloud access for Android devices.
- Recover data in IBM SmartCloud Enterprise.
- Secure virtual machine instances in the cloud.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- Find out how to access IBM SmartCloud Enterprise.
Get products and technologies
- See the product images available for IBM SmartCloud Enterprise.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Dig deeper into Cloud computing on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.
Software development in the cloud. Register today to create a project.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.