The procedure described in this article uses IBM Installation Manager, without the need to install it on every system. It shows how to package up critical Installation Manager data with the product image, so that the image can be serviced after it is deployed. We will begin by reviewing some Installation Manager basics.
Installation Manager fundamentals
In a typical installation topology, IBM Installation Manager is installed once on every machine. Installation Manager is configured to point to one or more product repositories that contain the product payload and metadata used to create an install image. Repositories are often hosted remotely (for example, via HTTP or FTP server) from the machine on which the installation is running. Repositories are loosely coupled and can be shared amongst Installation Manager instances (Figure 1).
Figure 1. Installation topology
It is possible to have multiple Installation Managers on a single machine by installing a group mode or user mode Installation Manager:
- Group mode enables a UNIX® administrative group to share a single Installation Manager to manage product installations. You can have multiple group mode Installation Managers installed on the same system.
- User mode supports one Installation Manager per user.
See the Installation Manager Information Center for more information on administrative modes.
Sometimes administrators prefer not to have Installation Manager installed on every machine at all. This can be due to business policies that complicate managing Installation Manager as another product install, or it might be related to disk footprint, especially in a virtualized environment. :
Furthermore, for large deployments of WebSphere Application Server, administrators might prefer to create a master image in an engineering environment, which can be cloned to target systems. Once deployed to the target systems, administrators create WebSphere Application Server profiles. Later, when it is time to apply maintenance, such as fix packs or ifixes, administrators must be able to service the cloned images.
The remainder of this article will review the basic Installation Manager components and describe a procedure for deploying cloned images of WebSphere Application Server that supports the servicing of those images.
Installation Manager directories
Before diving into the procedure, it is important to understand the directories that Installation Manager creates in order to govern the lifecycle of the products that it is used to install. There are two directories:
- The Agent Data Location, sometimes referred to as the appDataLocation, contains metadata that includes the history and state of all installs being managed by Installation Manager. This directory is critical to the healthy functioning of Installation Manager. Once the directory is created, it cannot be moved and should not be touched. If the Agent Data Location becomes corrupt, then all product installations that are tracked by that Agent Data Location will become unserviceable and will need to be reinstalled if service is needed.
This directory is created when Installation Manager is itself installed. You can override the default location by specifying the
–dL) command line option when installing Installation Manager.
For this procedure we will not actually be installing Installation Manager, so we will discuss how this directory is created for our scenario later in this article.
- The Shared Resources Directory is used for two purposes:
- In some cases, it contains resources that can be shared by installed products at run time. WebSphere Application Server products do not have run time dependencies on the contents of this folder.
- It is also used at install time to stage the payload before it is installed into its target folder. During this step, filesum checks are performed on the transferred data to ensure that it is intact. By default, this content remains cached in the Shared Resources Directory after installation so that it can be used for rollback or update in the future.
The location of the Shared Resources Directory is set when the first product is installed. Each product repository specifies a default location, so if this location is not overridden, then the first installed product determines the location. To explicitly set this location, use the
-sharedResourcesDirectorycommand line option when the first product is installed.
Like the Agent Data Location, the Shared Resources Directory cannot be changed after it is initially set. Because product payloads are cached here, space requirements can grow very large over the lifetime of the product, as maintenance is applied. The WebSphere Application Server product image is large, so if this content is permitted to accumulate, then this directory will grow to be many gigabytes in size over the course of multiple fix pack applications. You should never manually delete the content in this folder.
Fortunately, there is a preference that you can use to prevent the caching of this data. During any installation or maintenance operation, you can use this preference:
With this preference set to false, all data that is no longer needed will be removed after the operation completes. You still need to ensure you have enough space to stage the payload during the installation and maintenance operations, but data will not accumulate over time. If you have previously not used this preference, all old payloads will be removed the first time you use it. The only way to remove the data without performing an install or maintenance operation is with the Installation Manager GUI, using the Delete Saved Files button in the Preferences panel (Figure 2). You can also set the preference in this panel.
Figure 2. Delete Saved Files option in Preferences
Be aware that if you use this preference, then you will always need to connect to a product repository in order to perform rollback or update operations. You will not be able to rely on cached payloads. Most administrators find this an acceptable trade off.
Using the installer
Now that we have reviewed the two directories that Installation Manager creates and uses to govern product installs, let us look at how you can use Installation Manager without actually installing it. In the Installation Manager Information Center documentation, this is referred to as using the installer or install kit.
The installer should not be used on a system where you already have Installation Manager installed. If you attempt this, some operations will detect the installed Installation Manager and block it.
To begin, you must download the Installation Manager installer. You can download the platform-specific installer that matches the platform on which you will be installing:
Extract the files to a directory. The command line invocation
be found in the tools subdirectory of the installer. Use this command to
drive install operations or to invoke a response file that contains your
install instructions. (Be aware that the installer cannot be used to record a
response file.) Sample response files are available for WebSphere
Application Server V8 and WebSphere
Application Server V8.5.
Know that response files and command line arguments provide equivalent capability and the choice to use one versus the other is personal preference. For brevity, examples in this article are shown using command line arguments.
Creating a master image
Now that you have the installer downloaded and extracted, you can install your WebSphere Application Server master image. You must have a WebSphere Application Server product repository for the service level you need to install. Examples in this article will use the IBM-hosted web repository, but you can also set up a locally hosted enterprise repository for your business. For more information on creating an enterprise repository, see these resources:
- Using IBM Installation Manager for Enterprise Deployment
- Create custom installation repositories for WebSphere Application Server with the IBM Packaging Utility
- Managing packages with Packaging Utility
Consider the command shown in Listing 1.
imcl com.ibm.websphere.ND.v85 -repositories https://www.ibm.com/software/repositorymanager/com.ibm.websphere.ND.v85 -installationDirectory <install_home>/AppServer -dataLocation <install_home>/iim_appData -sharedResourcesDirectory <install_home>iim_shared -preferences com.ibm.cic.common.core.preferences.preserveDownloadedArtifacts=false -acceptLicense -showProgress
Arguments and options:
This instructs Installation Manager to install the WebSphere Application Server Network Deployment V85. The fix pack level installed will be the latest found in the specified repositories. All applicable ifixes will also be installed.
You must provide a comma-delimited list of repositories that contain the product payload and metadata for the products you need to install. This repository is the IBM-hosted web repository for WebSphere Application Server Network Deployment V85.
This argument specifies where to install the product.
As discussed earlier, -dataLocation specifies the Agent Data Location which Installation Manager uses to track the state and history of this product installation. When servicing products in this install location you must always specify the same -dataLocation argument.
This argument specifies the location of the Shared Resources Directory. You should always specify the same Shared Resources Directory and Agent Data Location pair.
This preference cleans up the Shared Resources Directory cache after install and update operations. This is discussed in detail above in the Shared Resources Directory section. (There will still be a few files in this folder.)
Review the product license, and then specify this argument.
Gives visual feedback as the install progresses.
After the install operation completes, you will have a directory structure of the form:
As you can see, this creates the Agent Data Location and Shared Resources Directory as peer folders of the product installation. Keeping these folders co-located with the product installation will enable you to apply maintenance to this install image in the future. You can now package up all directories in this master image and copy it to your production systems. The operating system and architecture, and directory structures in your production systems must exactly match those in the environment used to create the master image.
Applying maintenance to your install image
At some time in the future, you might need to apply a fix pack or ifix directly to your deployed product image. To do this, you simply need to use an Installation Manager installer and specify the same –dataLocation and –sharedResourcesDirectory that is associated with your product installation. The installer must always be at the same or higher level than was previously used. If you performed the initial install with Installation Manager 1.5.3 and then did an update with 1.6.0, you can never go back to an installer older than 1.6.0. Doing so can result in corruption of the Installation Manager metadata. One way to guard against this is to package up the installer with the product image, like this:
Suppose that you have WebSphere Application Server Network Deployment installed at fix pack level 184.108.40.206 and you want to apply Fix Pack 220.127.116.11. On the production machine, you would run the same original command, from the /iim_installer_160 folder. This would have the effect of updating your image to the current Fix Pack level that is published to the IBM hosted web repository (currently 18.104.22.168). You could also explicitly specify the fix pack level, by qualifying the package name: com.ibm.websphere.ND.v85_22.214.171.12421017_1724.
Fix packs and iFixes can be applied using the same method.
This article described a process for installing a master image of WebSphere Application Server that can be deployed and serviced. This process involves two key points:
- Use the Installation Manager installer to install the master image and apply maintenance to the image in production.
- Co-locate Installation Manager key directories with the master image and package these up with the image so that maintenance can be applied after it is deployed.
By following these guidelines, you can create serviceable master images of WebSphere Application Server.
Information Center articles:
- Sample response files for WebSphere Application Server V8.5
- WebSphere Application Server Version 8.5 product offerings for supported operating systems
- Create custom installation repositories for WebSphere Application Server with the IBM Packaging Utility
- Sample response files for WebSphere Application Server V8
- WebSphere Application Server Version 8 product offerings for supported operating systems
- IBM developerWorks WebSphere