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

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. This content is part of the IBM WebSphere Developer Technical Journal.

Dustin Amrhein, Staff Software Engineer, IBM

Author photoDustin Amrhein joined IBM as a member of the development team for the WebSphere Application Server. While in that position, Dustin worked primarily on web services infrastructure and web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role Dustin is a WebSphere Client Technical Professional.


developerWorks Professional author
        level

Xiao Xing Liang, Software Engineer, IBM

Xiao Xing Liang photoXiao 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.



27 January 2010

Also available in Chinese Russian Japanese

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.

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

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
    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
    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
    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
    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
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
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
    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
    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
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
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
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
    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
    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
    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
    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
    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
    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
    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
    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
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
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
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
    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
---------------------------------------------------------------------
Maintenance Package ID   7.0.0.0-WS-WAS-IFPK98482
Component Name           prereq.banshee
Action                   install
Update Action            replace
Timestamp                2010-12-17 23:33:55-0500
Result                   success

Component Installation Event
---------------------------------------------------------------------
Maintenance Package ID   7.0.0.0-WS-WAS-IFPK98482
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

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Web development
ArticleID=464260
ArticleTitle=Customizing with WebSphere CloudBurst, Part 5: Maintaining virtualized WebSphere Application Server environments
publish-date=01272010