IBM SmartCloud Enterprise Management (iii) Cloning and modification of customized assets

This article describes how to clone a Google Chrome image that you captured using ICCT in part 2nd. Learn how to customize the mirrors manually to allow XAMPP to be installed during instance configuration. Then, learn how to expose the parameters using manual Rational Asset Manager customization during configuration. Finally, use ICCT to create a XAMPP package that relies on Google Chrome software packages.

Let's get started.

Background knowledge

To create a mirror, you can capture a mirror from one instance, or clone an existing mirror. Each method has its own advantages and disadvantages. In each case, the ability to use parameters when working with virtual machines and packages is an important feature. Use parameters to prevent specific machine environment settings, such as IP addresses or host names, from being frozen in virtual machine mirroring. That is, you may not want other virtual machines to inherit the virtual machine's IP address or host name. Parameters can also implement the necessary system configuration settings, such as opening a port in a firewall, or exposing the choices that users have in the traditional interactive software installer.

Capturing a mirror

You can use the SmartCloud Portal, the SmartCloud API, or the ICCT to capture a mirror based on a running instance. Capturing a mirror clones the assets in the IBM Rational Asset directory and saves a custom mirror based on your instance. If your application is installed on an instance, before capturing the mirror, you can reconfigure the application based on that mirror during the activation of the new instance, without downloading or installing the application for each instance. If a preinstalled application is difficult to reconfigure, it is helpful to include the application binaries as part of the captured mirror and to write an activation script to install the application during activation. You must pay an additional GHR storage fee for a customized mirror.

Cloning a mirror

Cloning a mirror clones the mirrored assets in the IBM Rational Asset directory; however, the cloned mirror continues to share the mirrored binaries with the cloned underlying mirror. The underlying mirror does not change. These assets are typically much smaller than virtual disk mirrors. A cloned mirror is much faster than a capture mirror. The mechanism for cloning mirrors enables the rapid creation of mirrors, which can be customized directly by updating assets in the IBM Rational Asset Manager Asset directory. You do not need to pay any additional costs for the storage of the underlying mirrors. When you create an instance based on a mirrored image of a clone, the required scripts and installers (specified in scripts.txt) are copied from RAM to the virtual disk during configuration and can be installed during activation. This mechanism can also be slow if you copy a large Setup program from RAM or an external source, or if the installer is running slowly.

Clone mirrors share the same underlying mirrored binaries. Sharing the same underlying mirrored binaries has both advantages and risks. One advantage is that you will automatically inherit the maintenance fixes that the source mirror owner performs in the mirrored binary file. One risk is that incompatible changes to the underlying mirrored binaries can damage your application. The original mirror can only be deleted after all clone mirrors have been deleted.

Package

A package is an asset that contains captured information that is used to install and configure software on one or more virtual mirrors. The IBM image Construction and Composition Tool (ICCT) can help create and use software packages to implement a simple automated image-building process. Creating a package requires expertise in how the software works, usually done by a software expert. Because of this encapsulation, the mirror builder using the package does not need to understand specific information about software installation, activation, and reset. Understanding the operation process and the interaction between the Image construction and composition Tool and the deployment artifacts can be helpful in designing your package.

The package supports performing a set of installation tasks at a time. The Mirror builder initially creates a mirror and performs a set of configuration tasks for each mirrored deployment. In addition to installation tasks, packages should provide different deployment-time configurations for the software. The effective use of configuration parameters at deployment reduces the total number of mirrors required, providing a way to adjust the software for each deployment. The package editor in ICCT contains 7 main sections:

Demand

Contains information about the operating system and software prerequisites for the package. This information is specified in this section if the package applies only to a particular operating system or requires another set of software. Installation defines a task that installs software into a mirror. Once a software installation is performed, the installed software becomes a permanent component of the mirror. We recommend that you define the installation of all the large file contents in the "Installation" section to perform any long-running configuration tasks. Configured to provide deployment-time configuration options and activation scripts for pre-installed packages. The configuration section is important for supporting the use of software in different environments and for different purposes. For example, during the mirroring creation process, the tool installs your package. During the installation process, the virtual machine runs with a specific IP address and host name. At a later time, you can deploy a mirror to create a new virtual machine with a different IP address and host name. If the preconfigured software configuration contains information about an IP address or host name, you must reconfigure the software during deployment. In the Image construction and composition Tool, use the configuration section to define the activation scripts that perform this reconfiguration operation during deployment. In addition, you may want to expose common configuration parameters to the deployer that you mirror. For example, many software components contain configurations that each user needs to customize, such as ports and passwords. You can associate a set of parameters for each activation script that you define in the configuration section. If you specify a parameter as configurable, the mirrored deployer can provide a value for the parameter at deployment time. The activation script has access to the parameters that you specify in the package. The firewall allows the package author to specify that some network ports and/or port ranges should be turned on if the firewall blocks all ports by default. The user can specify a fixed port and port range, or reference a parameterized port range value for the configuration parameter. If you use a parameterized port or port range value, the deployer of a mirror that contains such a package can select the port and port range values to open at deployment time. Resetting provides a mechanism to clear the mirror. The mirroring creation process can cause the installation, configuration, and possible execution of your software. This procedure preserves the log files and other artifacts that are not suitable for use in the final mirror for deployment. The reset script clears the artifacts before they are captured.

Specification for reusable software packages

This specification contains information about the installation software that the tool needs to know, the software prerequisites, the parameters that can be used to customize the software, and the functionality that is provided.

Logical structure. An assembled package captures requirements and functions, installs artifacts such as archives and scripts, and requires calls, such as those used to perform an installer with a response file.

Physical structure. Functionality and requirements are stored in a semantic topology file. The operations and properties of the artifact are stored in the functional topology file. Relationships with other packages and mirrored assets are stored in the asset.

Packaged. The package is based on the OMG reusable Asset specification standard that creates a single archive. Package assets are placed in two special directories: artifacts and models. Other content in the packaged package may contain license agreements, documents, internationalization information, and an icon that identifies the package in the user interface.