Customizing With WebSphere CloudBurst, Part 5: Maintaining Virtualized WebSphere Application Server Environments

Customizing with WebSphere CloudBurst, Part 5:
Maintaining virtualized WebSphere Application

Server environments
Skill Level: Intermediate
Dustin Amrhein
Staff Software Engineer
IBM
Xiao Xing Liang (liangxx@cn.ibm.com)

Software Engineer
IBM
27 Jan 2010
The IBM® WebSphere® CloudBurst™ Appliance provides the capability to create

highly customized IBM WebSphere Application Server environments and then deploy
them into their own cloud. However, the job of the appliance does not end once the
environments have been deployed. WebSphere CloudBurst delivers users function
that helps you update and maintain these environments. This article discusses how
to use WebSphere CloudBurst to apply WebSphere Application Server Hypervisor
Edition iFixes, fixpacks, and your own fixes to both images and actual WebSphere
Application Server virtual system environments.
Introduction
Throughout the course of this series, we have discussed how to use the IBM
WebSphere CloudBurst Appliance to create and deploy highly customized
WebSphere Application Server environments into your very own cloud. Using the
appliance, these customizations can be delivered at each layer of the software
stack, from the operating system all the way up to the middleware and your
applications. The resultant customized environments can be saved on the appliance
in the form of patterns, which provide you with the means to simply, rapidly, and
consistently deploy complete application environments into a cloud.
Maintaining virtualized WebSphere Application Server environments

© Copyright IBM Corporation 2010. All rights reserved. Page 1 of 30
developerWorks® ibm.com/developerWorks
Of course, if the WebSphere CloudBurst Appliance only provided you with the
capability to create and deploy WebSphere Application Server environments into a
cloud, it would be overlooking a significant element in the application environment
lifecycle: maintenance.
Maintaining application environments, whether in a traditional or cloud environment,

can occupy a significant and sometimes overwhelming portion of your time.
Maintenance actions in such environments include delivering fixes and upgrades to
your applications and to the infrastructure on which they depend. Obviously, the
WebSphere CloudBurst Appliance does not eliminate the need for such
maintenance, but it does provide features that make the delivery of maintenance to
your applications and application infrastructure simple, safe, and fast.
Before looking at the appliance’s maintenance capabilities, it’s important to note that
you can leverage the maintenance functionality of WebSphere CloudBurst from both
a tactical and strategic perspective. The difference between these two approaches is
the resources that you interact with to deliver maintenance. From a tactical
standpoint, you will primarily interact with WebSphere CloudBurst virtual systems.
Strategically, you will deal with updating both WebSphere CloudBurst virtual images
and patterns. The sections that follow address both tactical and strategic
approaches for these areas:
• Applying interim fixes to deployed virtual systems.

• Applying fixpacks to deployed virtual systems.
• Applying custom maintenance actions.
• Using the command line to automate maintenance actions.
• Delivering application updates.
• Creating new, updated patterns.
Tactical maintenance: Virtual systems

Maintaining and updating environments dispensed by WebSphere CloudBurst can
be approached both tactically and strategically. When you talk about a tactical
approach, you are talking about the capability to directly maintain and update the
deployed WebSphere CloudBurst virtual systems. These virtual systems represent
WebSphere Application Server cells, and you can use functionality in the appliance
to deliver fixes and updates to that system. Specifically, you can use the appliance
to apply interim fixes (iFixes), apply service (including the ability to move from one
WebSphere Application Server release level to the next), and deliver updates to your
applications that are running in the cell.
Applying interim fixes

Page 2 of 30 © Copyright IBM Corporation 2010. All rights reserved.
ibm.com/developerWorks developerWorks®
When a bug is discovered and subsequently fixed in the WebSphere Application

Server product, IBM delivers the fix in a package called an interim fix, or iFix for
short. As a WebSphere Application Server administrator, you can download these
fixes and then use tools like IBM’s Update Installer to apply the fixes to the
necessary WebSphere Application Server components.
For a virtualized WebSphere Application Server cell that has been dispensed by
WebSphere CloudBurst, you could choose to still follow the same process you have
always used to apply iFixes to WebSphere Application Server environments, but the
appliance provides a means to do this in a rapid and failsafe manner.
To apply interim fixes to a running virtual system, you first upload the interim fix into
the WebSphere CloudBurst catalog:
1. From the Catalog drop-down menu, select the Emergency Fixes link.
2. Click the green cross to add a new fix, provide the necessary information
in the panel displays, then click OK (Figure 1).
Figure 1. Emergency fix information panel
3. You can now upload the PAK file for the interim fix using the file upload
dialog in the Emergency fix files section of the panel. The PAK file that
you upload into the WebSphere CloudBurst Appliance is the same file
that you would use in a normal WebSphere Application Server
environment. There is no special packaging of these files for the
appliance.
4. Once you have uploaded the file, you can select a Severity for the fix
(optional), and then select the virtual image versions that the iFix is
Applicable to. In Figure 2, the 7.0.0.7-ws-was-ifpk98482.pak file has
been attached to the emergency fix that was created. In addition, access
was granted to two different users, the severity was set to normal, and the
fix was applied to the WebSphere Application Server 7.0.0.7 virtual

image. Now that the fix has been defined and a PAK file has been
provided, you can use WebSphere CloudBurst to apply the iFix.
Figure 2. Uploading a PAK file
5. Navigate to the Virtual Systems panel and click on any virtual system on
which the fix is applicable.
6. Click the wrench icon in the upper-right corner of the page.
7. On the next panel, select Select service level or fixes (Figure 3).
Figure 3. Applying an interim fix

8. To apply a PAK file that you have uploaded into the WebSphere
CloudBurst catalog as an emergency fix, select Apply emergency fixes,
then select the fix or fixes that you want to apply.
9. The default activity is to click OK and apply the fix right away. However,
you can schedule the application of the fix for a future time by selecting
Schedule service and providing a date and time for the fix to be applied
(Figure 4), then click OK.
Figure 4. Scheduling fix application

At this point, WebSphere CloudBurst drives the fix application process. The
appliance first shuts down each virtual machine in the virtual system. Next, the
appliance takes a snapshot of the entire system, enabling you to rollback to the
previous system state if undesired behavior results after applying the fix. After taking
the snapshot, WebSphere CloudBurst applies the interim fix to the WebSphere
Application Server installations in each of the virtual machines in your virtual system,
then restarts the virtual machines and WebSphere Application Server components
within those machines. The status of the virtual system is updated in the console
(Figure 5).
Figure 5. Maintenance applied to a virtual system

Notice the new Service history section in the virtual system’s detail panel (Figure
6). If you expand this section, you will see a complete history of the service that has
been applied to the virtual system.
Figure 6. Virtual system service history

As mentioned above, WebSphere CloudBurst takes a snapshot of the virtual system

before applying any fix. If you want to rollback to the previous state of the system,
simply click the Restore button, circled in Figure 6.
By coupling a simple click-to-apply method for interim fixes with an automatic

snapshot process, applying these fixes with the appliance is both simple and safe.
Applying fixpacks to virtual systems
You can use features in WebSphere CloudBurst to apply fixpacks to the WebSphere
Application Server components in your deployed virtual systems. The process is
similar to the application of interim fixes, and it provides the same simplicity and
safety as that process.

Applying fixpacks begins by loading a new WebSphere Application Server

Hypervisor Edition virtual image into the WebSphere CloudBurst catalog. This new
virtual image contains all the usual components of the WebSphere Application
Server Hypervisor Edition -- namely the operating system, IBM HTTP Server, and
WebSphere Application Server parts -- but it also contains maintenance that has
been specifically packaged for WebSphere CloudBurst. This maintenance package
includes updates to all of the parts (including the operating system) that make up the
WebSphere Application Server Hypervisor Edition image.
Consider a case in which you have virtual systems based on WebSphere Application
Server V7.0.0.5 and you would like to upgrade those to V7.0.0.7:
1. Upload the new WebSphere Application Server Hypervisor Edition virtual

image that packages release 7.0.0.7. To do this, select the Catalog >
Virtual Images, then click on the green arrow.
2. On next panel, provided an http(s) URL to the OVA file location for the
virtual image (Figure 7) and then click OK. The image download process
will begin.
Figure 7. Adding a new virtual image
3. When the image download is complete, not only do you have a new
virtual image in your catalog that you can use to build patterns, but
because of the special maintenance package described above you also
have the ability to upgrade applicable virtual systems. However, in order
to use the new image to build patterns or apply upgrades, you must first
accept the licenses associated with the image. To do this, click the
Accept link in the License agreement field. Read through any license

panels that display and click the OK button if you accept.
4. To upgrade existing virtual systems to the version of WebSphere

Application Server packaged in the new image, navigate to Virtual
Systems and select the virtual system you want to upgrade.
5. The details for the virtual system display in the right panel. Click on the
wrench icon and click the Select service level or fixes link in the dialog
(Figure 8).
Figure 8. Applying service to virtual systems
6. To apply the upgrade, select Move to service level and then choose the
desired level. WebSphere CloudBurst will only display appropriate
upgrade levels for a given virtual system. As with the interim fix
application process described earlier, you can optionally schedule the
service level upgrade to be applied at a future time. Once you have
scheduled the upgrade process and selected the level to upgrade to, click
OK to begin the upgrade.

As in the interim fix application process, WebSphere CloudBurst shuts down the
virtual system, takes a snapshot of the entire thing, upgrades the WebSphere
Application Server components in the virtual machines, and then restarts the
system. At the end, you can view the Service history section on the detail page of
the virtual system and see that your upgrade was applied (Figure 9).
Figure 9. Upgrade service history
As was the case after applying interim fixes, if any undesired behavior occurred as
the result of applying the upgrade, you can easily roll back by clicking the Restore
button in the Snapshot section of the virtual system’s detail page.
Using archives for emergency fixes
Earlier, you saw that you can upload PAK files into the WebSphere CloudBurst
catalog and subsequently apply those to a virtual system. In addition to uploading
PAK files into the catalog, you can also upload archive files to be used as an
emergency fix.
The archive file contains XML metadata that tells WebSphere CloudBurst how to
apply your custom fix, and it also packages the artifacts that you need in order to
carry out the fix action. Although intended primarily for maintenance purposes, fix
actions can be anything that you can do in a script or module. The archive is

restricted to 512 megabytes in size and it can only be run once against a given
eligible virtual system.
Why would you choose to package an emergency fix in an archive? There are many
different possibilities; for example, to applying custom fixes to an operating system
(if you are using your own image with Red Hat as the operating system), applying
fixes to custom vendor software that you added into an image during the extend and
capture process, and so on.
Suppose that you have custom anti-virus software installed in one of your virtual
images within the WebSphere CloudBurst catalog. If you have running virtual
systems that are based on this image and the anti-virus software vendor releases
new updates, you probably want to apply those updates to the virtual systems. To do
this, you could create an archive file and upload it as an emergency fix.
The archive file contains three elements:
• service.xml file
• Custom shell script
• Binaries containing the necessary updates (optional).
Only the first two elements are required. You might not need to package the actual
binaries for the software update if, for example, you retrieve those from the vendor
over a network connection during the application of the update. Your service.xml file
to apply this software update has the structure shown in Listing 1.
Listing 1. The service.xml file
<?xml version="1.0" encoding="UTF-8"?>

<rmsd:Service xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:rmsd="http://www.ibm.com/websphere/rainmaker/service/servicedescription"
xsi:schemaLocation="http://www.ibm.com/websphere/rainmaker/service/servicedescription
./Service.xsd">
<rmsd:ImagePrereqs>
<rmsd:prereq name="WAS 7.0.0.7 with anti-virus software" version="7.0.0.7"/>
</rmsd:ImagePrereqs>
<rmsd:Packages>
<rmsd:Package name="Anti-virus update" type="ifix" target="APPLICATION">
<rmsd:Command name="/bin/sh /tmp/avupdate/updateAntiVirusSoftware.sh">
<rmsd:Log>/tmp/avupdate/logs</rmsd:Log>
<rmsd:Location>/tmp/avupdate</rmsd:Location>
<rmsd:Timeout>600000</rmsd:Timeout>
</rmsd:Command>
</rmsd:Package>
</rmsd:Packages>
</rmsd:Service>
In service.xml, the virtual image prerequisites for the maintenance package are
specified in the ImagePrereqs element. Details about how to apply the
maintenance, including the working directory, log file location, timeout, and which

command to invoke, are specified within the Package element. In this case, the
maintenance is applicable to the WAS 7.0.0.7 with anti-virus software virtual
image, and the updateAntiVirusSoftware.sh script will be invoked to apply the
maintenance.
When you have all the elements needed for the emergency fix, compress them into
an archive, and create a new emergency fix in WebSphere CloudBurst in the same
manner described earlier for PAK files. However, instead of uploading a PAK file for
the emergency fix, upload the new archive.
Figure 10. Creating an emergency fix with an archive
When you upload the archive file, click the refresh icon in the upper-right toolbar
(next to the red "X" in Figure 10) and the Applicable to field is automatically
updated. This is done by inspecting the metadata regarding image prerequisites
within the service.xml file of the archive.
You can now apply the emergency fix in the same manner that described earlier:
Navigate to the Virtual Systems page, select the desired virtual system, and then
click the Apply service wrench icon. When prompted to select the fix to be applied,
select Apply emergency fixes and Anti-virus software fix (Figure 11).
Figure 11. Selecting the archive emergency fix

At this point, simply click OK and WebSphere CloudBurst will apply the fix.
Essentially, WebSphere CloudBurst will unzip your archive to the /tmp/avupdate
directory on the target virtual machine(s) and invoke the
/tmp/avupdate/updateAntiVirusSoftware.sh script.
The use cases for archives as emergency fixes in WebSphere CloudBurst are
endless. Provided you package the archive with a valid service.xml and valid script
or module, you can do just about anything you want.
Command line interface options
In WebSphere CloudBurst 1.1, updates were delivered to the command line

interface that provide capabilities for the creation and application of fixes and
upgrades, as was shown using the Web console above. These new features enable
you to apply a single fix or upgrade, or multiple fixes and upgrades, to a virtual
system in an automated fashion.
To support these new capabilities, a new resource and new resource collection exist
in the command line interface. The new resource is cloudburst.fix, and the
resource collection is cloudburst.fixes. The resource collection is just that, a
collection of cloudburst.fix resources.
The cloudburst.fix resource represents an emergency fix in the WebSphere

CloudBurst catalog. You use this resource to create new emergency fixes to be
stored in the catalog of your WebSphere CloudBurst Appliance.
In Listing 2, the first line shows the creation of a fix. A JSON structure containing the
name of the new fix and location of a PAK file is passed to the create method. The
next two lines retrieve the resource for a virtual image named WebSphere
Application Server 7.0.0.7 and update the fix resource’s prereqs property to denote
that the fix is applicable to that particular virtual image.
Listing 2. Creating a new emergency fix using cloudburst.fix
>> fix = cloudburst.fix.create({“archive”:”/opt/myfixes/

7.0.0.7-ws-was-multios-ifpk97370.pak”, “name”:”PK97370”})
>> targetImage = cloudburst.virtualimages[“WebSphere Application Server 7.0.0.7”][0]
>> fix.prereqs.append(targetImage)
Now that the new fix has been created, you can apply the fix on eligible virtual
systems. The cloudburst.virtualsystem resource contains a new method to apply
fixes to the system. Consider the case that you have a virtual system created from a
pattern that is based off on the WebSphere Application Server 7.0.0.7 virtual image.
The name of the virtual system is Function Testing for Single Server, and you
need to apply the fix created above to this system. Listing 3 shows how you could do
this.
Listing 3. Applying emergency fixes using cloudburst.virtualsystem
>> fix = cloudburst.fixes[‘PK97370’]

>> virtualSystem = cloudburst.virtualsystems[‘Function Testing for Single server’][0]
>> virtualSystem.applyFixes(fix)
You can also apply all fixes that are applicable for a given virtual system. To do this,
you use the new findFixes method along with the applyFixes method seen above.
Listing 4. Using the findFixes method
>> virtualSystem = cloudburst.virtualsystems[‘Function Testing for Single server’][0]

>> fixes = virtualSystem.findFixes()
>> virtualSystem.applyFixes()

Aside from the new findFixes and applyFixes method, there are similar findUpgrades
and applyUpgrades methods for virtual system resources. The findUpgrades method
finds any upgrades that apply to a virtual system resource, while the applyUpgrades
method applies the upgrades to a given system. These two methods provide the
ability to apply fixpacks using the command line interface.
The new features delivered to the command line interface in WebSphere CloudBurst
V1.1 enable you to automate the application of fixes, upgrades, and even groups of
fixes to your deployed virtual systems, thus making the task of applying maintenance
a consistent and repeatable process.
Delivering application updates
Applying fixes and upgrades to the WebSphere Application Server components in

your application environment is likely only one piece of your overall maintenance
picture. Another significant maintenance responsibility in these environments is the
delivery of updates to the applications running on WebSphere Application Server. A
new feature in WebSphere CloudBurst V1.1 makes it very simple to deliver
application updates into the environments deployed by the appliance.
In WebSphere CloudBurst V1.0, script packages were automatically invoked near

the end of the pattern deployment process. While this is still the default behavior,
you now have the option of declaring user-initiated script packages. These script
packages are invoked when you initiate them via the WebSphere CloudBurst
console. This enables you to run a script at a time of your choosing, and as many
times as you desire.
Now, consider a case in which you want to create a script package to install an
application, but you also know that you will be updating that application over time.
Even though WebSphere CloudBurst can provision an entire environment, with
applications, in mere minutes, you might prefer on occasion to simply deliver
application updates to an already provisioned environment. This is a perfect use
case for the new user-initiated script package capability:
1. To satisfy this use case, it is best to define two new script packages in
WebSphere CloudBurst. The first script package will be created to
automate the installing of the application during the pattern deployment
process. It will not be user-initiated, but rather it will be automatically
invoked by WebSphere CloudBurst once the necessary WebSphere
Application Server components in the virtual system have been started.
Figure 12 shows the definition of a script package that installs an
application into a WebSphere Application Server environment. The
installApp.jy script within the defaultAppInstall.zip file contains the logic to
install the application. This script retrieves the application from the
location denoted by the APPLICATION_URL variable, with the name

specified by the APPLICATION_NAME variable. When included in a

pattern, this script package will be automatically invoked by WebSphere
CloudBurst near the end of pattern deployment because the Executes
field is set to at virtual system creation.
Figure 12. Default script package
2. With the script package for automating the application installation defined,
another script package that is user initiated can be created. This script
package will use the same .zip file and same script package definition
values as the first, except for the Working directory and Executes field
values. In addition, there is no need to define environment variables for
the user initiated script package. This is because this script package will
only be used in concert with the one defined above. As such, the
APPLICATION_URL and APPLICATION_NAME environment variables
will already be present in the virtual machine.
Figure 13. User initiated script package

It is good practice for all of your script packages to have unique working
directory values, even though it is not necessary in this case because
both script packages are using the same .zip file with the same contents.
The important distinction between these two script packages is the
Executes field value. In this case, the value is set to when you initiate it,
which means that the script package is invoked when you decide, and it
can be invoked as many times as necessary. This is the script package
that will deliver application updates into the WebSphere Application
Server environment.
3. The next step is to create a custom WebSphere CloudBurst pattern and

use the pattern editor to include both of the above script packages. In
Figure 14, a basic single server pattern with these two script packages is
shown.
Figure 14. Pattern with application install and update script
packages

Deploy the pattern by clicking the Deploy button. Values for both the
APPLICATION_URL and APPLICATION_NAME parameters are supplied
as configuration information, as shown in Figure 15.
Figure 15. Deploying the pattern

4. When WebSphere CloudBurst completes the deployment for this single

server pattern and the virtual system is in the started state, the
WebSphere Application Server administration console can be accessed
via the WebSphere link (circled in Figure 16) on the single server’s virtual
machine detail panel.
Figure 16. Accessing the WebSphere Application Server
administration console

5. A look at the WebSphere enterprise applications listing in the WebSphere

Application Server’s administration console should show the
MyApplication_v0001 application listed (Figure 17).
Figure 17. Application listing in the administration console
6. When a new version of the MyApplication application becomes available,

it is delivered into the WebSphere Application Server environment by
running the user initiated script created earlier. To run the user initiated
script, return to the Virtual Systems page for this WebSphere Application
Server cell. Navigate to the single server’s virtual machine details, and
you should see the user initiated script in the Script Packages section
(Figure 18).

Figure 18. User initiated script package execution
Click the Execute now link to invoke the Install custom application –
User Initiated. This will cause the invocation of the installApp.jy script,
which will retrieve the application from the location you noted during
deployment, uninstall the old application, and install the new application
with an updated version number. After the script runs, check the
WebSphere Application Server administration console, and you should
see the new version of the application (Figure 19).
Figure 19. Updated version of MyApplication
You can see the updated MyApplication_v0002 application was successfully

installed into the WebSphere Application Server environment.
Strategic maintenance: Images and patterns

While the tactical approach for updating and maintaining WebSphere CloudBurst
environments applies to running systems, the strategic approach applies to updating
and maintaining images and patterns. You can use functionality provided by the
appliance to create customized images and patterns that contain all of the fixes and
updates necessary for your application environment. In addition, you can ensure that
these updated images and patterns are available to all of the appliances in your
environment.

Extending virtual images with interim fixes and fixpacks
When you receive an interim fix or fixpack from IBM, there are two considerations for
applying the maintenance:
1. You need to apply the maintenance to any running WebSphere

Application Server environments, as discussed above.
2. Just as importantly, you need to ensure that any subsequent deployments

contain the necessary update. In WebSphere CloudBurst this means that
you want to capture that maintenance in a pattern that you can deploy as
many times as necessary.
You can do this by extending a WebSphere Application Server Hypervisor Edition

virtual image, applying the maintenance in the virtual machine created by the
appliance, and then capturing the updated image and storing it in the WebSphere
CloudBurst catalog. Once the image has been stored, you can create new custom
patterns (or clone your existing custom patterns) and select this new image as the
basis for your patterns.
Image extension begins by selecting an image to start with from the WebSphere
CloudBurst catalog. In this case, start by selecting the WebSphere Application
Server Hypervisor Edition 7.0.0.7 image. With the image is selected, click the
Extend button (Figure 20).
Figure 20. Extend WebSphere Application Server 7.0.0.7 virtual image

Because interim fixes nearly always affect only the WebSphere

Application Server binaries, they can be applied during the image
extension process. However, fixes affecting the configuration or
profiles space (/opt/IBM/WebSphere/Profiles) cannot be applied
during image extension because changes to this area of the virtual
image are not preserved during the capture process. More detail is
available in the Information Center.
As part of the image extension process, WebSphere CloudBurst automatically

creates a standalone server pattern based on the selected virtual image. That
pattern is then deployed by WebSphere CloudBurst into the private cloud to create a
running virtual machine that you can customize as necessary. These customizations
can be just about anything you need, but in this case we will focus on installing
interim fixes into the virtual machine instance.
When you initially extend a virtual image, WebSphere CloudBurst prompts you for,
among other things, a name and version for the new image you are creating. Under
the covers, WebSphere CloudBurst creates and deploys a pattern based on the
image, thus resulting in the creation of a virtual system. The virtual system’s name is
a combination of the name you provided for your new virtual image along with the
version you specified. Figure 21 shows a virtual system called WebSphere
Application Server 7.0.0.7 iFix 98482 1.0 that was created as the result of an
image extension request.
Figure 21. Install interim fix by apply service

Because the extension process creates a virtual system, you can use the interim fix
and fixpack techniques described earlier to apply fixes to the virtual system, and
recapture the extended image, including the fixes. Simply click the Apply service
icon, select the fix or upgrade that you want to install, and then let the appliance
apply the maintenance.
When the fix has been applied, the virtual machine state can be captured and stored
in the WebSphere CloudBurst catalog as a new virtual image. To do this, navigate
back to the Virtual Images section in the WebSphere CloudBurst catalog and select
the WebSphere Application Server 7.0.0.7 iFix 98482 virtual image. The image
should still be in Draft state, and you can capture it by clicking the capture icon in the
upper-right toolbar. When the capture is complete and stored in the WebSphere
CloudBurst catalog, the status message will be updated.
Figure 22. The captured virtual image

Updating patterns with the new image
Now that you have captured the new image, you can create a new pattern based on
the new image:
1. Navigate to the Patterns page and select an existing pattern to clone, or

click the green cross to create an entirely new pattern. For this example,
select the WebSphere single server pattern, and click the clone button
in the upper-right tool bar.
2. In the next dialog, provide a unique name for your new pattern and, most
importantly, select the WebSphere Application Server 7.0.0.7 iFix
98482 image as the basis for the new pattern.
Figure 23. Create new pattern based on new image

Selecting the patched image as the basis for your new pattern ensures
that all virtual machines created as a result of deploying the pattern will
contain the interim fix installed in the custom image. It is important to note
that you can clone any pattern -- whether it is a pattern that was shipped
on the appliance or one that you built and customized -- and simply select
the new virtual image as the basis for the pattern. You might also want to
use this process to update patterns even if you have not created custom
virtual images. You can clone patterns and change the underlying virtual
image to create a pattern based on a new version of the WebSphere
Application Server, or you can create a new pattern that can be targeted
for a different hypervisor platform. By doing this, you do not lose any of
the customizations that you have built into the pattern, such as custom
topologies, script packages, and advanced options, but you do change
the virtual image from which the virtual machines will be created during
deployment.
3. After creating the pattern, you can verify the interim fix’s presence by
deploying the pattern and checking the resulting environment. From the
Patterns page on the WebSphere CloudBurst console, select your new
pattern and click the Deploy button in the center of the panel to deploy a
virtual system.
4. When deployment is complete, check that the environment contains the

necessary fixes by first logging into the virtual machine using the SSH link
in the WebSphere CloudBurst console, or by using your own SSH client.
Then, you can again use the historyInfo command in the
/opt/IBM/WebSphere/AppServer/bin directory. The
7.0.0.7-ws-was-ifpk98482 fix should be listed in the installed maintenance
packages.

Listing 5. Result of historyInfo command
Installation Event
------------------------------------------------------------------------
Maintenance Package ID 7.0.0.0-WS-WAS-IFPK98482
Action install
Package Filename 7.0.0.0-WS-WAS-IFPK98482.pak
Backup File Name /opt/IBM/WebSphere/AppServer/properties/version/nif/backup
/7.0.0.0-WS-WAS-IFPK98482.pak
Timestamp 2010-12-17 23:33:55-0500
Result success
Component Installation Event
---------------------------------------------------------------------
Component Name prereq.banshee
Action install
Update Action replace
Timestamp 2010-12-17 23:33:55-0500
Result success
Component Installation Event
---------------------------------------------------------------------
Component Name bundle.wsfp.thinclient
Action install
Update Action replace
Timestamp 2010-12-17 23:33:55-0500
Result success
The process of installing interim fixes into custom virtual images during the
WebSphere CloudBurst extend and capture process provides you with the means to
quickly upgrade your WebSphere Application Server environments. You simply
create a custom virtual image containing the necessary fix or fixes, and create new
patterns based on this image. In this way, you can be sure that all of your
WebSphere Application Server environments created by future pattern deployments
contain the necessary fixes.
Summary
The WebSphere CloudBurst Appliance provides capabilities that address each
component of the lifecycle of a WebSphere Application Server application
environment. Namely, this means you can use the appliance to create, deploy, and
maintain your WebSphere Application Server environment running in a cloud. In
particular to the maintenance phase of the lifecycle, you can use the WebSphere
CloudBurst Appliance to apply both fixes and upgrades. In a tactical sense, this
means applying those fixes and upgrades to the WebSphere CloudBurst virtual
systems running in your cloud. From a strategic perspective, this means patching
and updating the images and patterns that form the environments you deploy to your
cloud. In either case, the WebSphere CloudBurst Appliance provides functionality
that makes maintaining your application environments simple, safe, and fast.

Resources
Learn
• More in this series
• Cloud computing for the enterprise (series)
• WebSphere CloudBurst Appliance product information
• Cloud Computing Journal
• Is there value in cloud computing?
• IBM developerWorks WebSphere
Discuss
• Space: WebSphere Cloud Computing for Developers
• Space: Cloud Computing Central
• YouTube: WebSphere CloudBurst Appliance videos
• Forum: WebSphere CloudBurst Appliance Forum
• Blog: A view from the clouds: Cloud computing for the WebSphere developer
• Follow us on Twitter
About the authors

Dustin Amrhein
Dustin Amrhein joined IBM as a member of the development team for WebSphere
Application Server. While in that position, Dustin worked on the development of Web
services infrastructure and Web services programming models. In addition, Dustin
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.
Xiao Xing Liang

Xiao Xing Liang is a software engineer working at the SOA Design Center in the
China Development Lab. He is an IBM Certified WebSphere Enterprise Developer
and an IBM Certified SOA Solution Designer. His current focus is on SOA

governance and related topics including WebSphere Service Registry and

Repository, Rational Asset Manager, Tivoli Application Dependency Discovery
Manager, and Tivoli Change and Configuration Management Database.


Customizing With WebSphere CloudBurst, Part 5: Maintaining Virtualized WebSphere Application Server Environments

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Customizing With WebSphere CloudBurst, Part 5: Maintaining Virtualized WebSphere Application Server Environments

Hochgeladen von

Copyright:

Verfügbare Formate

Customizing with WebSphere CloudBurst, Part 5:

Maintaining virtualized WebSphere Application

Xiao Xing Liang (liangxx@cn.ibm.com)

The IBM® WebSphere® CloudBurst™ Appliance provides the capability to create

Maintaining virtualized WebSphere Application Server environments

Maintaining application environments, whether in a traditional or cloud environment,

• Applying interim fixes to deployed virtual systems.

Tactical maintenance: Virtual systems

Applying interim fixes

Maintaining virtualized WebSphere Application Server environments

When a bug is discovered and subsequently fixed in the WebSphere Application

Maintaining virtualized WebSphere Application Server environments

6. Click the wrench icon in the upper-right corner of the page.

Maintaining virtualized WebSphere Application Server environments

Maintaining virtualized WebSphere Application Server environments

Figure 5. Maintenance applied to a virtual system

Maintaining virtualized WebSphere Application Server environments

Figure 6. Virtual system service history

Maintaining virtualized WebSphere Application Server environments

As mentioned above, WebSphere CloudBurst takes a snapshot of the virtual system

By coupling a simple click-to-apply method for interim fixes with an automatic

Applying fixpacks to virtual systems

Maintaining virtualized WebSphere Application Server environments

Applying fixpacks begins by loading a new WebSphere Application Server

1. Upload the new WebSphere Application Server Hypervisor Edition virtual

Maintaining virtualized WebSphere Application Server environments

panels that display and click the OK button if you accept.

4. To upgrade existing virtual systems to the version of WebSphere

Maintaining virtualized WebSphere Application Server environments

Figure 9. Upgrade service history

Using archives for emergency fixes

Maintaining virtualized WebSphere Application Server environments

The archive file contains three elements:

Listing 1. The service.xml file

<?xml version="1.0" encoding="UTF-8"?>

Maintaining virtualized WebSphere Application Server environments

Figure 10. Creating an emergency fix with an archive

Figure 11. Selecting the archive emergency fix

Maintaining virtualized WebSphere Application Server environments

Command line interface options

In WebSphere CloudBurst 1.1, updates were delivered to the command line

Maintaining virtualized WebSphere Application Server environments

The cloudburst.fix resource represents an emergency fix in the WebSphere

Listing 2. Creating a new emergency fix using cloudburst.fix

>> fix = cloudburst.fix.create({“archive”:”/opt/myfixes/

Listing 3. Applying emergency fixes using cloudburst.virtualsystem

>> fix = cloudburst.fixes[‘PK97370’]

Listing 4. Using the findFixes method

>> virtualSystem = cloudburst.virtualsystems[‘Function Testing for Single server’][0]

Maintaining virtualized WebSphere Application Server environments

Delivering application updates

Applying fixes and upgrades to the WebSphere Application Server components in

In WebSphere CloudBurst V1.0, script packages were automatically invoked near

Maintaining virtualized WebSphere Application Server environments

specified by the APPLICATION_NAME variable. When included in a

Figure 12. Default script package

Maintaining virtualized WebSphere Application Server environments

3. The next step is to create a custom WebSphere CloudBurst pattern and

Maintaining virtualized WebSphere Application Server environments

Figure 15. Deploying the pattern

Maintaining virtualized WebSphere Application Server environments

4. When WebSphere CloudBurst completes the deployment for this single

Maintaining virtualized WebSphere Application Server environments