Generating custom images

After you customize the base image successfully, generate custom om-base, om-agent and om-app images.

1. Navigate to /opt/ssfs/runtime/container-scripts/imagebuild folder to generate custom om-base, om-agent and om-app images.

   ./generateImages.sh --OM_TAG=<tagname> --EXPORT=false

   The following docker images are generated in your local registry. Also, an optional tar.gz file copy of the image in the parent directory of your runtime, unless overridden, is present under /opt/ssfs folder.

   om-base:10.0

   This is a base runtime image of the Sterling™ Order Management System Software runtime with all the required components for Sterling Order Management System Software development and testing. When generating the base image, the following error may occur, if the packages are outdated and are not compatible for installation. To download the updated packages for installation, set the REFRESH_RPM_CACHE to true, when running the generateImages.sh script.

   Error: 
    Problem 1: conflicting requests
     - nothing provides ...
    Problem 2: conflicting requestss
     - nothing provides ....

   The om-base image is not a deployable container and is available to create customizations for your applications and agent features that are outside of the deployment cluster.

   om-agent:10.0

   This is a light-weight runtime image of the Sterling Order Management System Software runtime with only those components that are required for running the agents or integration servers, and installing the database components, including running the CDT.

   om-app:10.0

   This is essentially a WebSphere Liberty application server image with the Sterling Order Management System Software EAR added. Starting this image automatically deploys and starts all the installed Sterling Order Management System Software suite of applications.

   The om-app image is not generated, when duplicate WAR files are used to generate images. For more information, see Points to remember when duplicate WAR files are used to generate images.

   The command in step 1 generates om-app image with smcfs, sbc, sma, isccs, and wsc. For IBM® Sterling Store Engagement (Next-generation), pass an additional argument --WAR_FILES with isf and other WAR names as required. For more information about WAR_FILES, see Generate deployment patterns.

   Note: For deploying by using the Operator, only om-agent and om-app images are required to push to the registry.

   Remember:

   • For the images with tag 10.0.2306.0-amd64 and later, the application servers use Liberty profile by default in the directory structure. As a result, all the backend JAR files that were previously located in the /config/dropins/smcfs.ear directory are located in the /config/dropins/smcfs.ear/lib directory. Ensure to update the configuration and references to reflect in the new directory structure, if needed. The Liberty profile can be turned off by setting the --LIBERTY-PROFILE=false when you run the ./generateImages.sh script.
2. To learn about the available parameters, run the following command:

   ./generateImages.sh --help

3. To copy the generated image from the container that is present under /opt/ssfs folder to your local machine, use the docker cp command.

   docker cp container_id:/opt/ssfs/<image_file>

4. To push the tar file to your cluster, complete the following steps:
   1. To make the *.tar available outside the container, copy the generated *.tar image files from /opt/ssfs to /opt/ssfs/shared folder.
   2. Move the om-app and om-agent image tar files to the master node where OpenShift® Container Platform is installed.

   • To push your images directly from customization runtime, see Loading the custom images to the platform.
   • For more information about the deployment patterns, generating differential images, advanced image build options, and combining the image build modes, see Advanced image build options.
5. If generateImages.sh script fails with errors, which relates to image pull connectivity issues,
   Hardcode DNS server in docker daemon.json in RHEL server, by completing following steps.

   1. Edit /etc/docker/daemon.json

      { "dns": ["10.1.2.3", "8.8.8.8"] }

   2. Restart the docker daemon for those changes to take effect.

      sudo systemctl restart docker

      When the container is run or started, the docker populates /etc/resolv.conf with the values from daemon.json.