Installing by mirroring images to a private container registry (with ibm-pak plug-in)

Mirroring images to your private container registry

The process of mirroring images takes the image from the internet to your host, then effectively copies that image to your private container registry.

Complete the following steps to mirror your images from your host to your private container registry:

1. Step 1. Generate mirror manifests
2. Step 2. Authenticating the registry
3. Step 3. Mirror images to final location

After you mirror your images, you can configure your cluster and complete the air gap installation by installing WebSphere Automation by way of Red Hat Open Shift Container Platform.

Step 1. Generate mirror manifests

Note: If you want to install subsequent updates to your air-gapped environment, you must run a CASE get command to get the image list when performing those updates. A registry namespace suffix can optionally be specified on the target registry to group-mirrored images.

1. Define the environment variable $TARGET_REGISTRY by running the following command:

   export TARGET_REGISTRY=<target-registry>

   The <target-registry> refers to the registry (hostname and port) where your images will be mirrored to and accessed by the oc cluster. For example, setting TARGET_REGISTRY to example.com:5000/mynamespace creates manifests such that images are mirrored to the top-level namespace that is named mynamespace.

2. Run the following commands to generate mirror manifests to be used when mirroring from a bastion host (connected mirroring):

   oc ibm-pak generate mirror-manifests \
      $CASE_NAME \
      $TARGET_REGISTRY \
      --version $CASE_VERSION

   The ~/.ibm-pak directory structure is built over time as you save CASEs and mirror. The following tree shows an example of the ~/.ibm-pak directory structure for connected mirroring. You might need to install the tree command first.

   tree ~/.ibm-pak
      /root/.ibm-pak
      ├── config
      │   └── config.yaml
      ├── data
      │   ├── cases
      │   │   └── <YOUR-CASE-NAME>
      │   │       └── <YOUR-CASE-VERSION>
      │   │           ├── XXXXX
      │   │           ├── XXXXX
      │   └── mirror
      │       └── <YOUR-CASE-NAME>
      │           └── <YOUR-CASE-VERSION>
      │               ├── catalog-sources.yaml
      │               ├── image-content-source-policy.yaml
      │               └── images-mapping.txt
      └── logs
         └── oc-ibm_pak.log

   Note: A new directory, ~/.ibm-pak/mirror, is created when you issue the oc ibm-pak generate mirror-manifests command. This directory holds the image-content-source-policy.yaml, images-mapping.txt, and catalog-sources.yaml files.
   Tip: If you are using a Red Hat Quay.io registry and need to mirror images to a specific organization in the registry, you can target that organization by specifying:

   export ORGANIZATION=<your-organization>
   oc ibm-pak generate mirror-manifests \
      $CASE_NAME \
      $TARGET_REGISTRY/$ORGANIZATION \
      --version $CASE_VERSION

   You can also generate manifests to mirror images to an intermediate registry server, then mirroring to a final registry server. This is done by passing the final registry server as an argument to --final-registry:

   oc ibm-pak generate mirror-manifests \
      $CASE_NAME \
      $INTERMEDIATE_REGISTRY \
      --version $CASE_VERSION \
      --final-registry $FINAL_REGISTRY

   In this case, in place of a single mapping file (images-mapping.txt), two mapping files are created:

   1. images-mapping-to-registry.txt
   2. images-mapping-from-registry.txt
3. Run the following commands to generate mirror manifests to be used when mirroring from a file system (disconnected mirroring):

   oc ibm-pak generate mirror-manifests \
      $CASE_NAME \
      file://local \
      --final-registry $TARGET_REGISTRY

   The following tree shows an example of the ~/.ibm-pak directory structure for disconnected mirroring:

   tree ~/.ibm-pak
   /root/.ibm-pak
   ├── config
   │   └── config.yaml
   ├── data
   │   ├── cases
   │   │   └── ibm-cp-common-services
   │   │       └── 4.4.0
   │   │           ├── XXXX
   │   │           ├── XXXX
   │   └── mirror
   │       └── ibm-cp-common-services
   │           └── 4.4.0
   │               ├── catalog-sources.yaml
   │               ├── image-content-source-policy.yaml
   │               ├── images-mapping-to-filesystem.txt
   │               └── images-mapping-from-filesystem.txt
   └── logs
      └── oc-ibm_pak.log
   

   Note: A new directory, ~/.ibm-pak/mirror, is created when you issue the oc ibm-pak generate mirror-manifests command. This directory holds the image-content-source-policy.yaml, images-mapping-to-filesystem.txt, images-mapping-from-filesystem.txt, and catalog-sources.yaml files.

Tip: Some products support the ability to generate mirror manifests only for a subset of images by using the --filter argument and image grouping. The --filter argument provides the ability to customize which images are mirrored during an air gap installation. As an example for this function, ibm-cloud-native-postgresql CASE can be used, which contains groups that allow mirroring-specific variant of ibm-cloud-native-postgresql (Standard or Enterprise). Use the --filter argument to target a variant of ibm-cloud-native-postgresql to mirror rather than the entire library. The filtering can be applied for groups and architectures. Consider the following command:

oc ibm-pak generate mirror-manifests \
   ibm-cloud-native-postgresql \
   file://local \
   --final-registry $TARGET_REGISTRY \
   --filter $GROUPS

The command is updated with a --filter argument. For example, for $GROUPS equal to ibmEdbStandard, the mirror manifests are generated only for the images associated with ibm-cloud-native-postgresql in its Standard variant. The resulting image group consists of images in the ibm-cloud-native-postgresql image group in addition to any images that are not associated with any groups. This allows products to include common images and the ability to reduce the number of images that you need to mirror.

Note: You can use the following command to list all the images that will be mirrored and the publicly accessible registries from where those images will be pulled from:

oc ibm-pak describe $CASE_NAME --version $CASE_VERSION --list-mirror-images

The output of the preceding command has two sections:

1. Mirroring Details from Source to Target Registry
2. Mirroring Details from Target to Final Registry. A connected mirroring path that does not involve an intermediate registry will only have the first section.

Make a note of the Registries found subsections in the preceding command output. You will need to authenticate against those registries so that the images can be pulled and mirrored to your local registry. See the next steps on authentication. The Top level namespaces found section shows the list of namespaces under which the images will be mirrored. Manually create these namespaces in your registry (which appears in the Destination column in the command output) root path if your registry does not allow automatic creation of namespaces.

Step 2. Authenticating the registry

Complete the following steps to authenticate your registries:

1. Store authentication credentials for all source Docker registries.

   Your product might require one or more authenticated registries. The following registries require authentication:

   • cp.icr.io
   • registry.redhat.io
   • registry.access.redhat.com

   You must run the following command to configure credentials for all target registries that require authentication. Run the command separately for each registry:

   Note: The export REGISTRY_AUTH_FILE command only needs to run once.

   export REGISTRY_AUTH_FILE=<path to the file which will store the auth credentials generated on podman login>
   podman login <TARGET_REGISTRY>

   Important: When you log in to cp.icr.io, you must specify the user as cp and the password, which is your Entitlement key from the IBM Cloud Container Registry. For example:

   podman login cp.icr.io
   Username: cp
   Password:
   Login Succeeded!

For example, if you export REGISTRY_AUTH_FILE=~/.ibm-pak/auth.json, then after performing podman login, you can see that the file is populated with registry credentials.

If you use the docker login command, the authentication file is typically located at $HOME/.docker/config.json on Linux or %USERPROFILE%/.docker/config.json on Windows. After the docker login command, export REGISTRY_AUTH_FILE to point to that location. For example, in Linux you can issue the following command:

export REGISTRY_AUTH_FILE=$HOME/.docker/config.json

Table 3. Directory description

Directory	Description
~/.ibm-pak/config	Stores the default configuration of the plug-in and has information about the public GitHub URL from where the CASEs are downloaded.
~/.ibm-pak/data/cases	This directory stores the CASE files when they are downloaded by issuing the oc ibm-pak get command.
~/.ibm-pak/data/mirror	This directory stores the image-mapping files, ImageContentSourcePolicy manifest in the image-content-source-policy.yaml file, and CatalogSource manifest in one or more catalog-sourcesXXX.yaml files. The images-mapping-to-filesystem.txt and images-mapping-from-filesystem.txt files are input to the oc image mirror command, which copies the images to the file system and from the file system to the registry respectively.
~/.ibm-pak/data/logs	This directory contains the oc-ibm_pak.log file, which captures all the logs that are generated by the plug-in.

Step 3. Mirror images to final location

Complete the steps in this section on your host that is connected to both the local Docker registry and the Red Hat OpenShift Container Platform cluster.

1. Mirror images to the final location.
   • For mirroring from a bastion host (connected mirroring):

     Mirror images to the TARGET_REGISTRY:

     oc image mirror \
       -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping.txt \
       --filter-by-os '.*'  \
       -a $REGISTRY_AUTH_FILE \
       --insecure  \
       --skip-multiple-scopes \
       --max-per-registry=1

     If you generated manifests in the previous steps to mirror images to an intermediate registry server followed by a final registry server, do the following steps.

     First, mirror images to the intermediate registry server:

     oc image mirror \
       -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-to-registry.txt \
       --filter-by-os '.*'  \
       -a $REGISTRY_AUTH_FILE \
       --insecure  \
       --skip-multiple-scopes \
       --max-per-registry=1

     Next, mirror images from the intermediate registry server to the final registry server:

     oc image mirror \
       -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-from-registry.txt \
       --filter-by-os '.*'  \
       -a $REGISTRY_AUTH_FILE \
       --insecure  \
       --skip-multiple-scopes \
       --max-per-registry=1

     The oc image mirror --help command can be run to see all the options available on the mirror command. By using continue-on-error, the command tries to mirror as much as possible and continues on errors.

     oc image mirror --help

     Note: Sometimes based on the number and size of images to be mirrored, the oc image mirror command might take longer. If you are issuing the command on a remote machine, it is recommended that you run the command in the background with a nohup so even if network connection to your remote machine is lost or you close the terminal, the mirroring continues. For example, the following command starts the mirroring process in background and writes the log to my-mirror-progress.txt.

     nohup oc image mirror \
        -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping.txt \
        -a $REGISTRY_AUTH_FILE \
        --filter-by-os '.*' \
        --insecure \
        --skip-multiple-scopes \
        --max-per-registry=1 > my-mirror-progress.txt  2>&1 &

     You can view the progress of the mirror by issuing the following command on the remote machine:

     tail -f my-mirror-progress.txt

   • For mirroring from a file system (disconnected mirroring):

     Mirror images to your file system:

     export IMAGE_PATH=<image-path>
     oc image mirror \
        -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-to-filesystem.txt \
        --filter-by-os '.*'  \
        -a $REGISTRY_AUTH_FILE \
        --insecure  \
        --skip-multiple-scopes \
        --max-per-registry=1
        --dir "$IMAGE_PATH"

     The <image-path> refers to the local path to store the images. For example, in the previous section if provided file://local as input during generate mirror-manifests, then the preceding command will create a v2/local subdirectory inside the <image-path> directory and copy the images under it.

   Note: Sometimes based on the number and size of images to be mirrored, the oc image mirror command might take longer. If you are issuing the command on a remote machine, it is recommended that you run the command in the background with nohup so that even if you lose network connection to your remote machine or you close the terminal, the mirroring continues. For example, the following command starts the mirroring process in the background and writes the log to my-mirror-progress.txt.

   export IMAGE_PATH=<image-path>
   nohup oc image mirror \
      -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-to-filesystem.txt \
      --filter-by-os '.*' \
      -a $REGISTRY_AUTH_FILE \
      --insecure \
      --skip-multiple-scopes \
      --max-per-registry=1 \
      --dir "$IMAGE_PATH" > my-mirror-progress.txt  2>&1 &

   You can view the progress of the mirror by issuing the following command on the remote machine:

   tail -f my-mirror-progress.txt

2. (For disconnected mirroring only) Continue to move the following items to your file system:
   • The <image-path> directory that you specified in the previous step
   • The auth file referred by $REGISTRY_AUTH_FILE
   • ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-from-filesystem.txt
3. (For disconnected mirroring only) Mirror images to the target registry from file system.

   Complete the steps in this section on your file system to copy the images from the file system to the $TARGET_REGISTRY. Your file system must be connected to the target docker registry.

   Important: If you used the placeholder value of TARGET_REGISTRY as a parameter to --final-registry at the time of generating mirror manifests, then before running the following command, find and replace the placeholder value of TARGET_REGISTRY in the file, images-mapping-from-filesystem.txt, with the actual registry where you want to mirror the images. For example, if you want to mirror images to example.com/mynamespace then replace TARGET_REGISTRY with example.com/mynamespace.
   1. Run the following command to copy the images (referred in the images-mapping-from-filesystem.txt file) from the directory referred by <image-path> to the final target registry:

      export IMAGE_PATH=<image-path>
      oc image mirror \
         -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-from-filesystem.txt \
         -a $REGISTRY_AUTH_FILE \
         --from-dir "$IMAGE_PATH" \
         --filter-by-os '.*' \
         --insecure \
         --skip-multiple-scopes \
         --max-per-registry=1

   If you are on a slow, unreliable network, where connections drop frequently, you can choose either of the following options:

   • Run oc image mirror command in a while loop. If the mirroring fails due to any reason it will start all over again after pausing for a set amount of time (in the following example, for five seconds).

     while ! oc image mirror <args>; do sleep 5; done;

   • Pass the continue-on-error flag to oc image mirror command, set to true (--continue-on-error=true). This flag indicates that the command will try to mirror as much as possible and continue on errors such as network issues. Usage of this flag might cause misleading errors. For more information, see Communication issue due to too many requests error (HTTP 429) while image mirroring.

Configuring the cluster

1. Update the global image pull secret for your Red Hat OpenShift cluster. Follow the steps in Updating the global cluster pull secret.

   The documented steps in the link enable your cluster to have proper authentication credentials in place to pull images from your TARGET_REGISTRY as specified in the image-content-source-policy.yaml which you apply to your cluster in the next step.

2. Create ImageContentSourcePolicy

   Important:

   • Before you run the command in this step, you must be logged in to your Red Hat OpenShift cluster. Using the oc login command, log in to the Red Hat OpenShift Container Platform cluster where your final location resides. You can identify your specific oc login by clicking the user drop-down menu in the Red Hat OpenShift Container Platform console, then clicking Copy Login Command.
   • If you used the placeholder value of TARGET_REGISTRY as a parameter to --final-registry at the time of generating mirror manifests, then before running the following command, find and replace the placeholder value of the TARGET_REGISTRY parameter in file, ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/image-content-source-policy.yaml with the actual registry where you want to mirror the images. For example, replace TARGET_REGISTRY with example.com/mynamespace.

   Run the following command to create ImageContentSourcePolicy:

   oc apply -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/image-content-source-policy.yaml

3. Verify that the ImageContentSourcePolicy resource is created.

   oc get imageContentSourcePolicy

4. Verify your cluster node status and wait for all the nodes to be restarted before proceeding.

   oc get MachineConfigPool

   $ oc get MachineConfigPool -w
   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-53bda7041038b8007b038c08014626dc   True      False      False      3              3                   3                     0                      10d
   worker   rendered-worker-b54afa4063414a9038958c766e8109f7   True      False      False      3              3            

   After the ImageContentsourcePolicy and global image pull secret are applied, the configuration of your nodes will be updated sequentially. Wait until all MachineConfigPools are in the UPDATED=True status before proceeding.

5. Create a new project for the CASE commands by running the following commands.
   Note: You must be logged in to a cluster before performing the following steps.

   export NAMESPACE=<YOUR_NAMESPACE>

   oc new-project $NAMESPACE

6. If you use an insecure registry, you must add the target registry to the cluster insecureRegistries list.

   oc patch image.config.openshift.io/cluster --type=merge \
   -p '{"spec":{"registrySources":{"insecureRegistries":["'${TARGET_REGISTRY}'"]}}}'

7. Verify your cluster node status and wait for all the nodes to be restarted before proceeding.

   oc get MachineConfigPool -w

   After the ImageContentsourcePolicy and global image pull secret are applied, the configuration of your nodes will be updated sequentially. Wait until all MachineConfigPools are updated.

Installing WebSphere Automation by way of Red Hat OpenShift Container Platform

Now that your images are mirrored to your air gap environment, you can deploy WebSphere Automation to that environment. When you mirrored your environment, you created a parallel offline version of everything that you needed to install an operator into Red Hat OpenShift Container Platform. To install WebSphere Automation, complete the following steps.

1. Create the catalog source.
   Important: Before you run any of the oc ibm-pak launch \ command, you must be logged in to your cluster. Using the oc login command, log in to the Red Hat OpenShift Container Platform cluster where your final location resides. You can identify your specific oc login by clicking the user menu in the Red Hat OpenShift Container Platform console, then clicking Copy Login Command.
   1. Set the WSA_OPERATOR_NAMESPACE and WSA_INSTANCE_NAMESPACE shell variables.

      For the AllNamespaces installation mode, set WSA_OPERATOR_NAMESPACE to openshift-operators. Set WSA_INSTANCE_NAMESPACE to the instance namespace, for example, websphere-automation. For SingleNamespace, use different namespace values. For OwnNamespace mode, set WSA_OPERATOR_NAMESPACE to the same value as WSA_INSTANCE_NAMESPACE.

      WSA_OPERATOR_NAMESPACE=openshift-operators
      WSA_INSTANCE_NAMESPACE=websphere-automation

   2. Create the namespaces, if needed.

      For catalog namespace, openshift-marketplace exists. For AllNamespaces installation mode, the openshift-operators namespace exists.

      oc create namespace $WSA_OPERATOR_NAMESPACE
      oc create namespace $WSA_INSTANCE_NAMESPACE

   3. Set the environment variable of the --inventory parameter:

      export CASE_INVENTORY_SETUP=<YOUR_CASE_INVENTORY_SETUP>

      To find the value for <YOUR_CASE_INVENTORY_SETUP>, see IBM: Product CASE to Application Version . For WebSphere Automation, the value is automationOperatorSetup.

   4. If updating to WebSphere Automation 1.8.1 or 1.8.2, edit zen operator catalog source:

      export CASE_NAME=ibm-websphere-automation
      export CASE_VERSION=<YOUR_VERSION>

      Open the catalog-sources.yaml file for editing.

      vi ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/catalog-sources.yaml

      Search for the word zen to find the section similar to the following example code block.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: ibm-zen-operator-catalog
        namespace: openshift-marketplace
      spec:
        displayName: ibm-zen-6.1.1+20250218.180746.89
        publisher: IBM
        image: airgap.example.com:5001/cpopen/ibm-zen-operator-catalog@sha256:a484bcb5478a54965ac3b0ea8acfe61026f46a2cb01587143e22e01797f5d63f
        sourceType: grpc
        updateStrategy:
          registryPoll:
            interval: 30m0s

      Copy the value of the spec.displayName parameter from your catalog-sources.yaml file and use it to replace the value of the metadata.name parameter. In the pasted value, replace the + character with a - character; the + is not permitted in the metadata.name field.

   5. If updating to WebSphere Automation 1.8.2, edit postgresql operator catalog source:

      Edit the ibm-cloud-native-postgresql operator catalog sources.

      Open the catalog-sources.yaml file for editing.

      vi ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/catalog-sources.yaml

      Search for the word postgresql to find the section similar to the following example code block.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: cloud-native-postgresql-catalog
        namespace: openshift-marketplace
      spec:
        displayName: ibm-cloud-native-postgresql-4.30.0+20241023.165233.2074
        publisher: IBM
        image: api.jagocpxairgap415.cp.fyre.ibm.com:5001/cpopen/ibm-cpd-cloud-native-postgresql-operator-catalog@sha256:3b867e7e0879ec24b5058e5db01c0a9be8d9d8d5ef2b7bb1bb7e247babb8b96d
        sourceType: grpc
        updateStrategy:
          registryPoll:
            interval: 30m0s
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: cloud-native-postgresql-catalog
        namespace: openshift-marketplace
      spec:
        displayName: ibm-cloud-native-postgresql-5.15.0+20250416.103820.2490
        publisher: IBM
        image: api.jagocpxairgap415.cp.fyre.ibm.com:5001/cpopen/ibm-cpd-cloud-native-postgresql-operator-catalog@sha256:7dbff355db7739152961cb6a97887d2e43bc960ac58837c126e03ed1a4480a3a
        sourceType: grpc
        updateStrategy:
          registryPoll:
            interval: 30m0s

      Copy the value of the spec.displayName parameter from your catalog-sources.yaml file and use it to replace the value of the metadata.name parameter. In the pasted value, replace the + character with a - character; the + is not permitted in the metadata.name field.

   6. Create and configure a catalog source.

      To install the catalog, run the following command:

      oc apply -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/catalog-sources.yaml

      Note: In IBM Cloud Pak foundational services version 3.13 and previous versions, the install-catalog command will deploy catalogsource with the latest tag. Starting from IBM Cloud Pak foundational services version 3.14, install-catalog deploys the catalog source, opencloud-operators, with catalogsource image digest.
   7. Verify that the CatalogSource for the WebSphere Automation operator is created.

      oc get pods -n openshift-marketplace
      oc get catalogsource -n openshift-marketplace

2. Install the WebSphere Automation operator prerequisites.
3. Install the WebSphere Automation operator.
   1. Install the WebSphere Automation operator.
      Note: You must have cluster admin access to run the install-operator command. However, you do not need cluster admin access for mirroring.

      oc ibm-pak launch \
         $CASE_NAME \
         --version $CASE_VERSION \
         --inventory $CASE_INVENTORY_SETUP \
         --action install-operator \
         --namespace $WSA_OPERATOR_NAMESPACE

   2. Using the oc login command, log in to the Red Hat OpenShift Container Platform cluster where your final location resides. You can identify your specific oc login by clicking the user drop-down menu in the Red Hat OpenShift Container Platform console, then clicking Copy Login Command.
   3. Verify that the WebSphere Automation operator is installed:

      oc get pod -n $WSA_OPERATOR_NAMESPACE

      It might take up to 15 minutes for all the pods to show the Running status.

4. Deploy the following configuration to create an instance of WebSphere Automation in an air gap environment.

   cat <<EOF | oc apply -f -
   apiVersion: automation.websphere.ibm.com/v1
   kind: WebSphereSecure
   metadata:
     name: wsa-secure
     namespace: $WSA_INSTANCE_NAMESPACE
   spec:
     license:
       accept: false
     cveMonitor:
       suspend: true
   ---
   apiVersion: automation.websphere.ibm.com/v1
   kind: WebSphereHealth
   metadata:
     name: wsa-health
     namespace: $WSA_INSTANCE_NAMESPACE
   spec:
     license:
       accept: false
   EOF

   If your cluster has internet access through a proxy server, then you can configure the WebSphereSecure custom resource with the proxy server configuration. For more information, see Configuring to use a proxy server. In the cveMonitor specification, ensure that the .spec.cveMonitor.suspend property is set with a value of false.

   Set the .spec.license.accept property to true from its default value of false if you accept the agreement to the license terms. For more information, see Licensing for WebSphere Automation.

5. Validate the installation.
6. Access the WebSphere Automation UI.

Setting up a repeatable mirroring process

Once you complete a CASE save, you can mirror the CASE as many times as you want to. This approach allows you to mirror a specific version of WebSphere Automation into development, test, and production stages by using a private container registry.

Follow the steps in this section if you want to save the CASE to multiple registries (per environment) once and be able to run the CASE in the future without repeating the CASE save process.

1. Run the following command to save the CASE to ~/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION which can be used as an input during the mirror manifest generation:

   oc ibm-pak get \
      $CASE_NAME \
      --version $CASE_VERSION
   

2. Run the oc ibm-pak generate mirror-manifests command to generate the image-mapping.txt file:

   oc ibm-pak generate mirror-manifests \
      $CASE_NAME \
      $TARGET_REGISTRY \
      --version $CASE_VERSION

   Note: If you are using a Red Hat Quay.io registry registry and need to mirror images to a specific organization in the registry, you can target that organization by specifying:

   export ORGANIZATION=<your-organization>
   oc ibm-pak generate mirror-manifests \
      $CASE_NAME \
      $TARGET_REGISTRY/$ORGANIZATION \
      --version $CASE_VERSION

   Then, add the image-mapping.txt file to the oc image mirror command:

   oc image mirror \
      -f ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping.txt \
      --filter-by-os '.*'  \
      -a $REGISTRY_AUTH_FILE \
      --insecure  \
      --skip-multiple-scopes \
      --max-per-registry=1

If you want to make this repeatable across environments, you can reuse the same saved CASE cache (~/.ibm-pak/$CASE_NAME/$CASE_VERSION) instead of executing a CASE save command again in other environments. You do not have to worry about updated versions of dependencies being brought into the saved cache.