Professional Documents
Culture Documents
Dustin Amrhein
Staff Software Engineer
IBM
09 Dec 2009
As an IBM® WebSphere® CloudBurst™ user, you create patterns and deploy them
into a private cloud. These patterns are complete representations of IBM WebSphere
Application Server environments and can include many different parts, such as a
deployment manager, custom node, administrative agent, and more. Each of these
parts maps to a unique virtual machine, and that virtual machine is created from a
virtual image. Specifically, the virtual machine is created from an IBM WebSphere
Application Server Hypervisor Edition virtual image, which contains the operating
system, WebSphere Application Server, and IBM HTTP Server, all pre-installed,
pre-configured, and pre-tuned. However, this image does not contain other
customizations or content that might be required for your specific environment. This
article describes how easy it is to customize the WebSphere Application Server
Hypervisor Edition virtual image to meet your application environment’s specific
needs.
Introduction
This series of articles has been discussing customization capabilities of the IBM
WebSphere CloudBurst Appliance. Part 1 provided an overview of the different
customization capabilities of the appliance, and explained when and why you would
employ these capabilities. Part 2 explored the use of editing patterns to create
custom WebSphere environments. Part 3 further explored creating such custom
environments by discussing the role of script packages as a means to save the
configuration of your WebSphere Application Server environment directly into the
pattern.
Parts 2 and 3 focused specifically on techniques that enable you to customize the
topology and configuration of your middleware layer via pattern editing. While those
customizations are important, customization of the operating system layer is also
often required.
When you build a WebSphere CloudBurst pattern, you select a particular version of
WebSphere Application Server Hypervisor Edition on which that pattern will be
based. When the pattern is deployed, each of the parts in the pattern results in the
creation of a virtual machine containing the WebSphere Application Server node
type represented by the part (Figure 2).
Each virtual machine is created from the WebSphere Application Server Hypervisor
Edition virtual image that was selected to be the basis of the pattern. Parts 2 and 3
in this series provided examples of how to influence both the WebSphere Application
Server topology and the configuration of the WebSphere Application Server cell that
is comprised of virtual machines. This article will explain how you can customize the
underlying WebSphere Application Server Hypervisor Edition to deliver
customizations at the operating system level of these virtual machines.
There are many reasons for directly customizing the WebSphere Application Server
Hypervisor Edition (hereafter referred to as Hypervisor Edition) virtual images
shipped with WebSphere CloudBurst. Doing so enables you to introduce custom
operating system configurations. This might mean installing custom software (like
anti-virus programs, JDBC drivers, monitoring agents, and so on), altering operating
system configurations (such as network timeouts), and much more. Customizing
virtual images is a good way to capture the kinds of customizations that are needed
in most, if not all, of your WebSphere Application Server environments. If there is
functionality you want in every deployed virtual machine, directly adding it into the
image is typically the fastest and easiest way to make this happen.
How
First, you select an existing virtual image and extend it. As a result, WebSphere
CloudBurst creates a running virtual machine in the private cloud based off of the
selected image, as shown in Figure 3.
Once the virtual machine is running in the cloud, you can login and install custom
software or otherwise configure the operating system environment. When installing
this new software or modifying the environment in the virtual machine, it is important
that you understand the disk layout of the virtual machine. Hypervisor Edition is
separated into four separate virtual disks, one disk each for the operating system,
WebSphere Application Server binaries, WebSphere Application Server profiles, and
IBM HTTP Server that exist in the image. You can introduce changes into the
operating system, IBM HTTP Server, or WebSphere Application Server virtual disks.
You should not introduce customizations into the WebSphere Application Server
profiles disk space, as they will be discarded during the capture phase of the
extend/capture process. Namely, changes cannot be made anywhere in the
/opt/IBM/WebSphere/Profiles directory, nor in any of its subdirectories. Employ the
use of script packages to deliver customizations that affect the configuration in this
area of the virtual machine. This restriction enables WebSphere CloudBurst to
capture your extended WebSphere Application Server virtual image to support all
the different parts (IHS, Deployment manager, custom node, and so on).
When you have made the desired changes to the virtual machine instance, the
modified environment can be captured and stored as a virtual image in the
WebSphere CloudBurst catalog alongside the other virtual images. When the
appliance has successfully captured the new virtual image, it can be used as the
basis for custom WebSphere CloudBurst patterns. The entire extend/capture
process is depicted in the Figure 3.
The ability to produce customized virtual images and use them in an auditable
manner to construct virtual systems is an important value proposition of the
WebSphere CloudBurst Appliance. Think of the customization as the installation of
additional software and capabilities to create a certified, supported virtual image.
Once this has been performed and tested in accordance with your enterprise’s
standards, the resultant image is captured and locked. You can then construct virtual
systems based on this image, enabling configuration of the new capabilities using
script packages on one or more of the virtual machines, in a repeatable and
auditable way.
The remainder of this article will focus on a particular scenario that involves
extending an image, installing custom software, capturing the resultant image, and
storing it back into the WebSphere CloudBurst catalog. In addition, you will see how
to use this image to build a custom pattern containing a script package that
configures the newly installed software during pattern deployment. Finally, you will
walk through pattern deployment and the resulting virtualized environment.
Extension example
Use cases and the process for image customization, or extension, is probably best
seen through an example. One of the most common examples is the inclusion of a
monitoring agent in each image. The example here will use customization features
of the appliance to produce an application environment that contains virtual
machines with embedded IBM Tivoli® Monitoring Linux OS Agents. (Although this
article explicitly shows the Tivoli Monitoring agent, this process can be followed for
extensions of other agents, or for any other software product in general.)
Additional software, like agents, often needs configuration parameters that are
unique for different deployment environments. For example, monitoring agents
usually require configuration to communicate with a monitoring server. While this
configuration can be hardwired into the embedded software agent, the solution is
more flexible when the agent configuration is parameterized. This example shows
how to combine the WebSphere CloudBurst extend/capture capability with the
scripting and pattern capabilities (described in Parts 2 and 3 of this series) to
configure the agent via script parameters. These agents will be configured here to
communicate with an existing IBM Tivoli Enterprise Monitoring Server specified
during deployment.
If you want to actually extend your image with the Tivoli Monitoring agent, you will
also need to have access to the Tivoli Monitoring agent software, and both a Tivoli
Enterprise Monitoring Server and an IBM Tivoli Enterprise Portal Server installation.
It is also important that the network utilized by the virtual machines created by
WebSphere CloudBurst can communicate with the network hosting the monitoring
server, in this case the Tivoli Enterprise Monitoring Server instance.
2. Enter Name, Description, and Version information about the image you
want to create on the General Information dialog that displays (Figure 5).
Figure 5. Basic information for the new image
4. The last configuration step before the image extension process begins
involves the virtual machine’s hardware configuration. During this step,
you can optionally change the default size of the four different virtual
disks, and change the default number of network interfaces in the virtual
machine, which is 1 (Figure 7). If the software you are adding is sizable,
you will need to increase the target disk size accordingly. Click OK to
begin the process.
Figure 7. Hardware configuring for the extended image
6. The virtual system that was created during the deployment displays
(Figure 9). Expand the Virtual machines section and then collapse the
single virtual machine that appears under this section.
Figure 9. Logging into the virtual machine
7. From here, you can either SSH into the virtual machine directly from the
console using the provided links, or you can use your own SSH client to
login to the host that is shown in the Located at field. In either case, once
you have logged into the virtual machine you can start making any
desired customizations. In this example, you will in fact be installing
additional software into the virtual machine.
8. The additional software you will be installing in this example is the Tivoli
Monitoring agent. To install this software, you first need to get the Linux
9. Once you have the software image, you need to make it available on the
virtual machine that was created as a result of extending the Hypervisor
Edition image above. You have two options for making the software
image available:
• Copy the TAR file to the virtual machine and then untar it.
• Untar the file to a disk that is mountable by the Hypervisor Edition
virtual machine.
For this example, use the second option (although you can use the first
option if it is easier for your own particular use case).
10. After making the software image available, navigate to the directory that
contains the unpacked contents of the original TAR file. Once in the
appropriate directory, you can run the installation from a terminal window
(Figure 10). Simply press Enter to accept the default install location and
Enter again to create the specified install directory.
Figure 10. Installing the Tivoli Monitoring Linux OS Agent
11. Next, you are presented with a list of options for how you want to install
the agent (Figure 11). Choose option 1 to install the products to the local
virtual machine.
Figure 11. Choosing installation mode
12. On the next panel, select option 1 to accept the license agreement for
Tivoli Monitoring Linux OS Agent.
13. On the following three panels, you are prompted to choose an encryption
key, operating system support, and operating system. In each case, press
Enter to accept the default for those properties.
14. Next, you are presented with a list of products that are available for
installation (Figure 12). Select the Monitoring Agent for Linux OS by
entering the number 6 and pressing Enter.
Figure 12. Choosing a product to install
16. When the agent installation and initialization is complete, you are asked if
you want to install additional products (Figure 13). Press Enter to indicate
that you do not wish to install additional products.
Figure 13. Finishing the ITM Linux OS Agent installation
At this point, the Tivoli Monitoring Linux OS Agent has been installed. Although the
message indicates that you can now configure the installed agent, you do not need
to do that at this time. You will include a script package in patterns built from this
image that automates the configuration of the agent each time a virtual machine
containing the agent is created.
17. You can now capture the image to store it in the WebSphere CloudBurst
catalog. To do this, navigate back to the Virtual Images section in the
WebSphere CloudBurst catalog (Figure 14).
18. Select the WAS 7.0.0.3 with ITM Agent virtual image. The image should
still be in Draft state, and you can capture it by clicking the capture icon in
the upper-right hand toolbar.
Figure 14. Capturing the extended image
19. Click OK to confirm the capture request and begin the capture process.
During the capture, the updated virtual machine disks are transferred
back to the appliance. Because these virtual disks are quite sizeable (~20
GB before any customizations), you should have a 1GB connection
between your appliance and the hypervisors in your cloud. When the
capture is complete and stored in the WebSphere CloudBurst catalog, the
status message will be updated (Figure 15).
Figure 15. The captured image
20. At this point, you can optionally make the image read-only by locking it.
You can also assign access to the image as desired.
As a result of extending and capturing the customized virtual image, you have a new
virtual image called WAS 7.0.0.3 with ITM Agent stored in the WebSphere
CloudBurst catalog. You can now use this new image to create custom patterns,
thus ensuring that all the nodes in the WebSphere Application Server cell created by
deploying such a pattern will contain installed Tivoli Monitoring Linux OS Agent
software. However, simply having the agent software installed in the virtual
machines does not give you much unless you correctly configure the agents to
report back to a monitoring server, specifically a Tivoli Enterprise Management
Server instance.
As seen in Figure 16, as the objective of deploying a pattern based on your new
virtual image -- besides having a running WebSphere Application Server
environment -- is to have a Tivoli Monitoring ITM Linux OS Agent up and running in
each machine and to have those agents correctly configured to communicate with
an existing Tivoli Enterprise Management Server instance.
To achieve this objective with a custom pattern, you must create a new script
package that will be part of the pattern. The script package will include a shell script
that will configure the Tivoli Monitoring Linux OS Agent in the virtual machine so that
it reports to the desired Tivoli Enterprise Management Server. The contents of the
script file is shown in Listing 1.
#!/bin/sh
#
# For WebSphere CloudBurst Appliance
# Script to change ITM agent config to point to correct ITM server
#
PROGNAME=`basename $0`
BINDIR=`dirname "$0"`
ITM_DIR=/opt/IBM/ITM
ITM_RSP=$BINDIR/configITMAgent.rsp
echo "----------------------------------------------"
echo " Show environment variables"
echo "----------------------------------------------"
set
echo "----------------------------------------------"
echo " Stop ITM Agent"
echo "----------------------------------------------"
$ITM_DIR/bin/itmcmd agent stop lz
echo "----------------------------------------------"
echo " Build response file for config of ITM Agent "
echo "----------------------------------------------"
# Environment variable ITM_TEMS_HOSTNAME
if [[ "$ITM_TEMS_HOSTNAME" = "" ]]; then
echo "ITM TEMS hostname was not passed in! Default to localhost."
ITM_TEMS_HOSTNAME=localhost
fi
echo "ITM TEMS Hostname is $ITM_TEMS_HOSTNAME"
echo "----------------------------------------------"
echo " Change config for ITM Agent "
echo "----------------------------------------------"
$ITM_DIR/bin/itmcmd config -A -p $ITM_RSP lz
#---------------------------------------------------
# remove response file
rm -f $ITM_RSP
echo "----------------------------------------------"
echo " Start ITM Agent"
echo "----------------------------------------------"
$ITM_DIR/bin/itmcmd agent start lz
echo ""
echo "Done"
Notice that the shell script makes use of a variable called ITM_TEMS_HOSTNAME.
This variable represents the hostname of the existing Tivoli Enterprise Management
Server installation, and will become part of the script package definition in
WebSphere CloudBurst.
21. Compress the shell script inj Listing1 into a file called
itm_agent_config.zip.
24. Define the variable for the Tivoli Enterprise Management Server
hostname, and provide information that tells WebSphere CloudBurst how
to invoke the script within the .zip file. In the script package definition
(Figure 18), you can see the ITM_TEMS_HOSTNAME variable is defined.
You will supply the value for this variable when deploying a pattern that
contains this script package. In addition, a value for the working directory
field is supplied. This directory will be the location to which the script
package .zip file is unzipped. Finally, the command that should be used to
invoke the script package is provided in the Executable field. With this
information specified, you can begin to use this script package to build
custom patterns.
Figure 18. Defining the ITM agent configuration script package
25. You can now create a pattern based on your custom virtual image.
Navigate to the Patterns page and select an existing pattern to clone. For
this example, use the existing WebSphere single server pattern
(although any pattern could be used). To clone the pattern, click the clone
button in the upper right toolbar. A panel will display that asks for
information about the new pattern you are creating (Figure 19).
Figure 19. Creating the custom pattern
In this example, the pattern is named WAS single server - ITM and, most
importantly, the WAS 7.0.0.3 with ITM Agent is selected as the virtual
image on which to base the pattern. This ensures that all virtual machines
created as a result of deploying this pattern will be based on the custom
virtual image you created earlier. In this case, that means all of the virtual
machines will have the Tivoli Monitoring Linux OS Agent installed and
running upon activation.
26. Click on the pencil icon (directly to the left of the clone icon) to display the
Pattern Editor (Figure 14), where you can update your pattern as desired.
In this case, you will be including the Configure ITM Agent script
package that you created earlier.
27. Select Script Packages in the drop-down menu displayed in the left side
of the browser, then drag and drop the Configure ITM Agent script
package onto the Standalone server part within the pattern as seen in
Figure 20.
Figure 20. Updating the custom pattern
Again, although the WebSphere single server pattern was cloned in this
example, any pattern can be cloned and configured with the Tivoli
Monitoring Linux OS Agent. For multi-part patterns (for example, a
WebSphere cluster), simply include the Configure ITM Agent script
package on each part in the pattern. This will ensure that each virtual
machine created during deployment is configured to report back to your
Tivoli Enterprise Management Server instance.
28. Click Done editing to return to the main pattern page. Here, you can
optionally lock the pattern and grant access to the appropriate users and
user groups. The pattern is now ready to be deployed into your private
cloud.
29. From the Patterns page on the WebSphere CloudBurst console, select
the WAS single server - ITM pattern, and click the Deploy button in the
center of the panel.
30. Provide a unique name for the pattern deployment and click on the
Configure virtual parts link (Figure 21).
Figure 21. Pattern deployment panel
31. Configure the standalone server virtual part for deployment. Part of the
configuration information you provide will be the value for the variable that
specifies the hostname for the Tivoli Enterprise Management Server. In
Figure 22, the hostname for the Tivoli Enterprise Management Server is
set to cbvm-110.rtp.raleigh.ibm.com.
Figure 22. Configuring virtual parts
32. When the virtual part has been configured, simply click OK to deploy the
pattern. From this point, WebSphere CloudBurst takes over and decides
where to place the virtual machine in your cloud. The status of your virtual
system in the WebSphere CloudBurst console will be updated once the
WebSphere Application Server cell is up and running. (Figure 23)
Figure 23. Deployed virtual system
At this point, you are ready to confirm the correct configuration of the Tivoli
Monitoring Linux OS Agent in your virtual machine.
33. Check the trace files associated with the configuration script. You can do
this from the Virtual Systems page in WebSphere CloudBurst. Collapse
the Virtual machines section, and then collapse the section for the
specific virtual machine (Figure 24).
Figure 24. Trace logs for the Configure ITM Agent script package
34. In the details for the virtual machine, locate the section labeled Script
Packages and click on the remote_std_out.log for the Configure ITM
Agent script package. This log file should contain the messages present
in the configuration script (Listing 1). Most notably, you should see a
message that specifies the Tivoli Enterprise Management Server
hostname supplied during deployment, and the last message in the log
should indicate that the agent was successfully started.
35. In addition to the script package logs, make note of the hostname in the
Located at field under the General information section above. In this
example, the hostname is cbvm-111.rtp.raleigh.ibm.com. If you have
access to a Tivoli Enterprise Portal Server, a shortened form of this new
hostname should appear in the console in a minute or two. From the
Tivoli Enterprise Portal Server console, you can view a graphical
representation of the data being reported to and collected by the Tivoli
Enterprise Management Server. In addition, sub-entries for each reporting
agent will show Linux operating system statistics. In Figure 25, the disk
usage for the virtual machine (cbvm-111) created as a result of deploying
the custom pattern is displayed in the Tivoli Enterprise Portal Server
console.
Figure 25. Virtual machine in the Tivoli Enterprise Portal Server
Summary
The WebSphere CloudBurst Appliance was designed with the knowledge that
WebSphere Application Server users build application environments that encompass
customizations at multiple layers. One such layer of customization is the operating
system environment. By using the image extension and capture facilities provided by
the appliance, you can very easily extend base virtual images, install customizations,
and capture those customized images. Once in the WebSphere CloudBurst catalog,
these customized images can be used to construct as many different patterns as
needed. These patterns can then be dispensed by appliance users, and each virtual
machine created as a result of deployment will be created from the customized
virtual image. The ability to create, capture, and utilize custom WebSphere
Application Server Hypervisor Edition virtual images in WebSphere CloudBurst can
be leveraged to ensure a consistent, yet customized operating system configuration
for your application environments.
Resources
Learn
• More in this series
• Part 1: Creating highly customized private clouds
• Part 2: Using WebSphere CloudBurst to customize a WebSphere
middleware environment
• Part 3: Using script packages for customizing above and beyond patterns
lead the technical effort in the development of a Java RESTful services framework. In
his current role, Dustin is a technical evangelist for emerging technologies in IBM’s
WebSphere portfolio. His current focus is on WebSphere technologies that deliver
cloud computing capabilities, including the WebSphere CloudBurst Appliance.
Ken Klingensmith
Ken Klingensmith is a Certified IT Specialist and one of the founders of Worldwide
WebSphere, an IBM Software Group team providing technical sales support and
enablement globally since 1998. Ken specializes in the WebSphere Application
Server, WebSphere Virtual Enterprise and WebSphere CloudBurst products,
enabling field technical sales in emerging versions, working with customers, and
helping guide product direction. Before joining IBM, Ken was a Senior Systems
Engineer with Transarc Corporation supporting the Encina Online Transaction
Processing product.
Chris Ahl
Chris Ahl is an Advisory Software Engineer in IBM's Software Group, Tivoli division
and works in the Autonomic Computing and Component Technologies area. During
his 20 years in software development at IBM, he has been involved in many software
projects dealing with network management, systems management, device
management and installation technologies. He received a Bachelor's degree in
Computer Science from RIT (Rochester Institute of Technology).