Installing IBM Process Mining by mirroring Cloud Pak images to a private container registry

If your cluster is not connected to the internet, you can install the IBM Process Mining in your cluster by using connected or disconnected mirroring.

If you have a host that can access both the internet and your mirror registry, but not your cluster nodes, then you can directly mirror the content from that machine. This process is referred as connected mirroring. If you do not have such a host, you must mirror the images to a file system and then bring the host or the removable media into your restricted environment. This process is referred to disconnected mirroring.

Before you begin

You must complete the steps in the following sections before you generate mirror manifests:

Prerequisites
Prepare a host
Set environment variables and download CASE files

If you intent to use a private container registry for installation, then your cluster must support ImageContentSourcePolicy (ICSP).

Prerequisites

Regardless of whether you plan to mirror the images with a bastion host or to the file system, you must satisfy the following prerequisites:

Red Hat® OpenShift® Container Platform requires you to have cluster admin access to run the install-operator command.
An Red Hat® OpenShift® Container Platform cluster must be installed.
IBM images located on Quay and Docker are migrated to anonymous locations on icr.io. Based on the version of the software you are installing, you need to atttain access to the following sites and ports:
- icr.io:443 for IBM Cloud Container Registry, CASE OCI artifact, and IBM Process Mining catalog source
- github.com for CASEs and tools
- redhat.com
  
  Red Hat registries required per Configuring your firewall for Red Hat® OpenShift® Container Platform

From ibm-pak plug-in version 1.2.0, you can eliminate the port for github.com to retrieve CASES and tooling. You can configure the plug-in to download CASEs as OCI artifacts from IBM Cloud Container Registry (ICCR) by using the following script: oc ibm-pak config repo 'IBM Cloud-Pak OCI registry' -r oci:cp.icr.io/cpopen --enable

Preparing a host

If you are in an air-gapped environment, you must be able to connect a host to the internet and mirror registry for connected mirroring or mirror images to file system which can be brought to a restricted environment for disconnected mirroring. For information on the latest supported operating systems, see Installation documentation for ibm-pak plugin.

The following table explains the software requirements for mirroring the IBM Process Mining images:

Table 1. Software requirements and purpose
Software	Purpose
Docker/Podman	Container management
Red Hat OpenShift CLI (oc)	Red Hat OpenShift Container Platform administration

Perform the following steps on your host:

Install Docker or Podman.

Use the following commands to install Docker (for example, on Red Hat® Enterprise Linux®):
```
yum check-update
yum install docker
```
If you are installing as a non-root user, you must use sudo. For more information, refer to the Podman or Docker documentation for installing as a non-root user.

To install Podman, see Podman Installation Instructions.
Install the oc Red Hat® OpenShift® Container Platform CLI tool.
Download and install the most recent version of IBM Catalog Management Plug-in for IBM Cloud Paks from the IBM/ibm-pak.

a. Use the following command to extract the binary file:
```
tar -xf oc-ibm_pak-linux-amd64.tar.gz
```
b. Run the following command to move the file to the /usr/local/bin directory:
```
mv oc-ibm_pak-linux-amd64 /usr/local/bin/oc-ibm_pak
```
If you are installing as a non-root user, you must use sudo. For more information, refer to the Podman or Docker documentation for installing as a non-root user.

c. Download the plug-in based on the host operating system. Use the following command to confirm that oc ibm-pak -h is installed:
```
oc ibm-pak --help
```
The plug-in usage is displayed.

For more information on plug-in commands, see command-help.

The plug-in is also provided in a container image cp.icr.io/cpopen/cpfs/ibm-pak:TAG where TAG should be replaced with the corresponding plug-in version.

The following command creates a container and copies the plug-ins for all the supported platforms in the directory, plugin-dir. You can specify any directory name and it will be created while copying. After copying, it will delete the temporary container. The plugin-dir directory includes all the binaries and other artifacts you find in the GitHub release and repo at IBM/ibm-pak.
```
id=$(docker create cp.icr.io/cpopen/cpfs/ibm-pak:TAG - )
docker cp $id:/ibm-pak plugin-dir
docker rm -v $id
cd plugin-dir
```
Examples:
- If you are using docker with the plug-in version v1.6.0, then you can provide the command as follows:
```
id=$(docker create cp.icr.io/cpopen/cpfs/ibm-pak:v1.6.0 - )
docker cp $id:/ibm-pak-plugin plugin-dir
docker rm -v $id
cd plugin-dir
```
- If you are using podman with the plug-in version v1.6.0, then you can provide the command as follows:
```
id=$(podman create cp.icr.io/cpopen/cpfs/ibm-pak:v1.6.0 - )
podman cp $id:/ibm-pak-plugin plugin-dir
podman rm -v $id
cd plugin-dir
```

Creating registry namespaces

Top-level namespaces are the namespaces that appear at the root path of your private registry. For example, if your registry is hosted at myregistry.com:5000, then mynamespace in myregistry.com:5000/mynamespace is defined as a top-level namespace. There can be many top-level namespaces.

When the images are mirrored to your private registry, it is required that the top-level namespace where images are getting mirrored already exists or can be automatically created during the image push. If your registry does not allow automatic creation of top-level namespaces, you must create them manually.

When you generate mirror manifests, you can specify the top-level namespace where you want to mirror the images by setting TARGET_REGISTRY to myregistry.com:5000/mynamespace which has the benefit of needing to create only one namespace mynamespace in your registry if it does not allow automatic creation of namespaces. The top-level namespaces can also be provided in the final registry by using --final-registry.

If you do not specify your own top-level namespace, the mirroring process will use the ones that are specified by the CASEs. For example, it will try to mirror the images at myregistry.com:5000/cp, myregistry.com:5000/cpopen etc.

So if your registry does not allow automatic creation of top-level namespaces and you are not going to use your own during generation of mirror manifests, then you must create the following namespaces at the root of your registry.

cp
cpopen

There can be more top-level namespaces that you might need to create. See section on Generate mirror manifests for information on how to use the oc ibm-pak describe command to list all the top-level namespaces.

Seting environment variables and downloading CASE files

If your host must connect to the internet via a proxy, you must set environment variables on the machine that accesses the internet via the proxy server.

If you are mirroring by using connected mirroring, set the following environment variables on the machine that accesses the internet via the proxy server:

export https_proxy=http://proxy-server-hostname:port
export http_proxy=http://proxy-server-hostname:port

Example

export https_proxy=http://server.proxy.xyz.com:5018
export http_proxy=http://server.proxy.xyz.com:5018

Before mirroring your images, you can set the environment variables on your mirroring device, and connect to the internet so that you can download the corresponding CASE files. To finish preparing your host, complete the following steps:

Save a copy of your environment variable values to a text editor. You can use that file as a reference to cut and paste from when you finish mirroring images to your registry.

Create the following environment variables with the installer image name and the version.
```
export CASE_NAME=ibm-process-mining
export CASE_VERSION=3.0.0
```
For more information on CASE name and version, see IBM: Product CASE to Application Version.
Connect your host to the intranet.
The plug-in can detect the locale of your environment and provide textual helps and messages accordingly. You can optionally set the locale by running the following command:
```
oc ibm-pak config locale -l LOCALE
```
In the command, replace LOCALE with the preferred value - de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_Hans, zh_Hant.
Configure the plug-in to download CASEs as OCI artifacts from IBM Cloud Container Registry (ICCR).
```
oc ibm-pak config repo 'IBM Cloud-Pak OCI registry' -r oci:cp.icr.io/cpopen --enable
```
As an alternative, you can use the following command to refrain from using the GitHub repository:
```
oc ibm-pak config repo "IBM Cloud-Pak OCI registry" --enable
```

After running this command, the default repository is changed to oc ibm-pak config.

Enable color output (optional with v1.4.0 and later)
```
oc ibm-pak config color --enable true
```
Download the image inventory for IBM Process Mining to your host.

If you do not specify the CASE version, it downloads the latest CASE.
```
oc ibm-pak get \
$CASE_NAME \
--version $CASE_VERSION
```

By default, the root directory that is used by plug-in is ~/.ibm-pak. This means that the preceding command downloads the CASE in the directory, ~/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION. You can set the IBMPAK_HOME environment variable to configure this root directory. Assuming IBMPAK_HOME is set, the preceding command downloads the CASE under $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION.

You can locate the log files at $IBMPAK_HOME/.ibm-pak/logs/oc-ibm_pak.log.

Your host is now configured and you can now mirror the images.

Starting with v1.4.0, the plug-in creates a file, component-set-config.yaml, in the directory ~/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION to download the CASEs with oc ibm-pak get. This file captures all the CASEs that were downloaded, pinning down their exact versions during this particular download. You can use this file to download the same CASEs with same versions in another environemnt. You can check this file to your source code repository and re-create the same environment each time you use this to download the CASEs. Run the following command:
```
oc ibm-pak get -c file:///home/user/ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION/component-set-config.yaml
```   Ensure that you provide the absolute path after `file://`. <br>
```

You can also edit this file defining the CASEs with pinned down versions that should include your product. The following are contents of an example file, my-csc.yaml:

name: "example-product"                         # <required> defines the name for the "product"; this is NOT a CASE name, but follows IBM CASE name rules. For more information, see https://ibm.biz/case-yaml
version: "1.0.0"                                # <required> defines a version for the "product"
description: "an example product targeting OCP 4.9" # <optional, but recommended> defines a human readable description for this listing of components
cases:                                          # list of CASEs. First item in the list is assumed to be the "top-level" CASE, and all others are dependencies
- name: ibm-mas
 version: 5.5.2
 launch: true                                  # Exactly one CASE should have this field set to true. The launch scripts of that CASE are used as an entry point while executing 'ibm-pak launch' with a ComponentSetConfig
- name: ibm-cp-common-services
 version: 1.15.2

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. After you mirror your images, you can configure your cluster and complete air-gapped installation.

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

Generating mirror manifests
Authenticating the registry
Mirroring images to the final location
Configuring the cluster
Installing IBM Process Mining in Red Hat OpenShift Container Platform

Generating mirror manifests

If you want to install subsequent updates to your air-gapped environment, you must do a CASE get 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.

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 myregistry.com:5000/mynamespace will create manifests such that images will be mirrored to the top-level namespace mynamespace.
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
```
Example: Using ~/.ibm-pak directory structure for connected mirroring

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:
```
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
```
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.

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 using the following command:
```
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), the following two mapping files are created:
- images-mapping-to-registry.txt
- images-mapping-from-registry.txt
When you install IBM Process Mining in an air-gapped environment on Red Hat® OpenShift® Container Platform, you might get a Catalog source collision error. Example of the Error:
```
Error/warning:
Catalog source collision detected for cloud-native-postgresql-catalog, ibm-db2uoperator-catalog in
/root/.ibm-pak/data/mirror/ibm-process-mining/3.1.0/catalog-sources.yaml.
Please remove incorrect version from that file before applying to the cluster
```

You might also notice that the same CASE with different versions are retrieved. This happens when there are inter-dependencies and two different services specify different versions of another service. To resolve this issue, see the digests included in Installing Operator dependencies and Version dependencies topics to decide which versions to keep.

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

Example: Using ~/.ibm-pak directory structure for disconnected mirroring

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
│   │       └── 1.9.0
│   │           ├── XXXX
│   │           ├── XXXX
│   └── mirror
│       └── ibm-cp-common-services
│           └── 1.9.0
│               ├── catalog-sources.yaml
│               ├── image-content-source-policy.yaml
│               ├── images-mapping-to-filesystem.txt
│               └── images-mapping-from-filesystem.txt
└── logs
   └── oc-ibm_pak.log

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.

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-gapped 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 was updated with a --filter argument. For example, for $GROUPS equal to ibmEdbStandard the mirror manifests will be 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.

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 will have two sections:

Mirroring Details from Source to Target Registry
Mirroring Details from Target to Final Registry.

A connected mirroring path that does not involve an intermediate registry will only have the first section.

Note down the Registries found sub sections 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. These namespaces should be created manually 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.

Authenticating the registry

Complete the following steps to authenticate your registries:

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:

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>
```
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 docker login, the authentication file is typically located at $HOME/.docker/config.json on Linux or %USERPROFILE%/.docker/config.json on Windows. After docker login you should 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 2. Descriptions of directories

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 `image-content-source-policy.yaml` and CatalogSource manifest in one or more `catalog-sourcesXXX.yaml`. The files `images-mapping-to-filesystem.txt` and `images-mapping-from-filesystem.txt` 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.

Mirroring images to the 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.

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 \
  --continue-on-error=true
```
  If you generated manifests in the previous steps to mirror images to an intermediate registry server followed by a final registry server, run the following commands:
  1. 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 \
  --continue-on-error=true
```
  2. 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 \
  --continue-on-error=true
```
  The oc image mirror --help command can be run to see all the options available on the mirror command. Note that we use continue-on-error to indicate that the command should try to mirror as much as possible and continue on errors.
```
oc image mirror --help
```
  Sometimes based on the number and size of images to be mirrored, the oc image mirror 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 will continue. For example, the below command will start the mirroring process in background and write 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 \
--continue-on-error=true > my-mirror-progress.txt  2>&1 &
```      You can view the progress of the mirror by issuing the following command on the remote machine:
``` {: codeblock}
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 \
  --continue-on-error=true \
  --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 subdirectory v2/local inside directory that is referred by <image-path> and copy the images under it.
The following command can be used to see all the options available on the mirror command. Note that continue-on-error is used to indicate that the command should try to mirror as much as possible and continue on errors.
```
oc image mirror --help
```
Sometimes based on the number and size of images to be mirrored, the oc image mirror 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 will continue. For example, the following command will start the mirroring process in the background and write 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 \
   --continue-on-error=true \
   --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
```
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
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.

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 myregistry.com/mynamespace then replace TARGET_REGISTRY with myregistry.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 \
  --continue-on-error=true
```

Configuring the cluster

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 will apply to your cluster in the next step.
Create ImageContentSourcePolicy

Before you run the command in this step, you must be logged in to your 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 TARGET_REGISTRY 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 myregistry.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
```
If you are using Red Hat OpenShift Container Platform version 4.7 or earlier, this step might cause your cluster nodes to drain and restart sequentially to apply the configuration changes.
Verify that the ImageContentSourcePolicy resource is created.
```
oc get imageContentSourcePolicy
```

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                   3                     0                      10d

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.

Create a new project for the CASE commands by running the following commands:

You must be logged in to a cluster before performing the following steps.
```
export NAMESPACE=<YOUR_NAMESPACE>
```
```
oc new-project $NAMESPACE
```

Optional: 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}'"]}}}'

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 IBM Process Mining in Red Hat OpenShift Container Platform

You can now deploy your IBM Process Mining to the air-gapped environment 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 your IBM Process Mining, complete the steps in the following sections:

Creating the catalog source and installing the IBM Process Mining
Accessing the console
Retrieving your console username and password

Creating the catalog source and installing IBM Process Mining

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 drop-down menu in the Red Hat OpenShift Container Platform console, then clicking Copy Login Command.

Set the namespace to install the IBM Process Mining catalog:
```
export NAMESPACE=<YOUR_NAMESPACE>
```

Set the environment variable of the --inventory parameter:

export CASE_INVENTORY_SETUP=<YOUR_CASE_INVENTORY_SETUP>

Create and configure a catalog source.

The recommended way to install the catalog is to run the following command:

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

The following command can also be used to install the catalog:

oc ibm-pak launch \
$CASE_NAME \
  --version $CASE_VERSION \
  --action install-catalog \
  --inventory $CASE_INVENTORY_SETUP \
  --namespace $NAMESPACE \
  --args "--registry $TARGET_REGISTRY --recursive \
  --inputDir ~/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION"

In foundational services version 3.13 and previous versions, the install-catalog command will deploy catalogsource with the latest tag. Starting from foundational services version 3.14, install-catalog deploys the catalog source,opencloud-operators, with catalogsource image digest.

Verify that the CatalogSource for your IBM Process Mining operator is created.

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

Install your IBM Process Mining operators.

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 $NAMESPACE
```
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.
Verify that your IBM Process Mining operator is installed:
```
oc get pod -n $NAMESPACE
```
It might take up to 15 minutes for all the pods to show the Running status.

Accessing the console

Use the following command to get the URL to access the console:

oc get route -n $NAMESPACE cp-console -o jsonpath=‘{.spec.host}’

The preceding command returns the following output:

cp-console.apps.mycluster.mydomain.com

Based on the example output, your console URL would be https://cp-console.apps.mycluster.mydomain.com.

Retrieving console username and password

The default username to access the console is admin.

You can get the password for the admin username by running the following command:

oc -n $NAMESPACE get secret platform-auth-idp-credentials -o jsonpath='{.data.admin_password}' | base64 -d

The following password is an example of the output of the preceding command:

EwK9dj9fwPZHyHTyu9TyIgh9klZSzVsA

Based on the example output, you would then use EwK9dj9fwPZHyHTyu9TyIgh9klZSzVsA as the password.

You have now successfully created and deployed your IBM Process Mining environment by using a private container registry.

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 the IBM Process Mining 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.

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
```

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

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

If you are using a {{site.data.keyword.quay_tm}} 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` to the `oc image mirror` command:
``` {: codeblock}
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 \
  --continue-on-error=true

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 again in other environments. You do not have to worry about updated versions of dependencies being brought into the saved cache.

After setting the mirrored images in the LOCAL Registry, you can proceed to install the Process Mining Operator, its dependencies, and the Process Mining Operand. For more infomation, see Installing IBM Process Mining operator.