IBM Installation Manager creates and services the WebSphere Application Server master image

Brief introduction

The procedures described in this article use IBM installation Manager and do not need to be installed on each system. This article describes how to package important installation Manager data with a product image so that the image can be processed after the image is deployed. We will first review some of the basics of installation Manager.

Installation Manager Basics

In a typical installation topology, IBM installation Manager installs once on each computer. Installation Manager is configured to point to one or more product repositories that contain product loads and metadata for creating an installation image. The repository is typically hosted remotely from the computer running the installation (for example, through HTTP or an FTP server). Repositories are loosely coupled, so they can be shared between installation Manager instances (Figure 1).

Figure 1. Install topology

By installing a group mode or user mode Installation Manager, you may have multiple installation Manager on a single computer:

Group mode allows UNIX? The administrative Group shares a installation manager to manage the product installation. You can install multiple Group mode installation Manager on the same system.

User mode supports installing one installation Manager per user.

Sometimes, administrators do not like to install installation Manager on each computer at all. This may be because managing installation Manager at another product installation can become more complex, or it may be related to disk footprint, especially in virtualized environments.

In addition, for large deployments of WebSphere application Server, administrators may prefer to create a master image in the engineering environment that can be cloned to the target system. After you deploy to the target system, the administrator creates the WebSphere application Server configuration file. Later, when maintenance, such as a repair package or IFix, is performed, the administrator must be able to handle the cloned image.

The remainder of this article reviews the basic components of installation Manager and describes the process of deploying a clone image that supports WebSphere application Server that processes these images.

Installation Manager Directory

Before you go into this process, it is important to understand the directories created by Installation Manager to manage the lifecycle of the products that are used for installation. There are two directories:

The Agent data Location, sometimes referred to as appdatalocation, contains metadata, including the history and status of all installations managed by Installation Manager. This directory is important for the normal operation of the installation Manager. After you create the directory, you cannot move and you should not touch the directory. If the agent data Location is corrupted, all product installations tracked by the agent data Location will become unhandled and need to be reinstalled if processing is required.

This directory is created when installation Manager installs automatically. You can override the default location by specifying-datalocation (or-DL) command-line options when you install installation Manager.

For this process, we will not actually install installation Manager, so we'll discuss how to create the directory for use later in this article.

Shared Resources Directory has two functions:

In some cases, shared resource Directory contains resources that can be shared by the installed product at run time. The WebSphere application Server product has no run-time dependencies on the contents of this folder.

Shared resources Directory is also used at installation time to suspend the load before it is installed to its destination folder. During this step, the transmitted data is filesum checked to ensure that the data is intact. By default, after installation, the content is still cached in Shared resources Directory so that it can be used for rollback or update in the future.

The location of Shared resources Directory is set when the first product is installed. Each product repository specifies a default location, so if the location is not overwritten, the first installed product determines that location. To set this location explicitly, use the-sharedresourcesdirectory command-line option when you install the first product.

As with Agent Data Location, Shared resources Directory cannot be changed after the initial setting. Because the product load is cached here, the space requirements can become very large during the use of the product, with the maintenance application. The WebSphere application Server product image is large, so if the content is allowed to accumulate, the directory becomes many gigabytes in the process of fixing the application multiple times. You must not delete the contents of this folder manually.