Installing IBM Cert Manager offline (using ibm-pak plug-in)

If your cluster is not connected to the internet, you can install the IBM Cert Manager in your cluster via connected or disconnected mirroring.

To install IBM Cert Manager offline using the ibm-pak plug-in, complete the following steps to download the CASE bundle, mirror images from your host to your private container registry, and create catalog sources:

Prerequisites

Tip: With ibm-pak plug-in version 1.2.0, you can eliminate the port for github.com to retrieve CASES and tools by configuring 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.

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 the file system, which can be brought to a restricted environment for disconnected mirroring. For information on the latest supported operating systems, see ibm-pak plug-in installation documentation.

The following table explains the software requirements for mirroring the IBM Cloud Pak images:

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

Complete the following steps on your host:

  1. Install Docker or Podman.

    To install Docker (for example, on Red Hat® Enterprise Linux®), run the following commands:

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

    yum check-update
yum install docker

    To install Podman, see Podman Installation Instructions.

  2. Install the oc OpenShift Container Platform CLI tool.

  3. Download and install the most recent version of IBM Catalog Management Plug-in for IBM Cloud Paks from the IBM/ibm-pak. Extract the binary file by entering the following command:

    tar -xf oc-ibm_pak-linux-amd64.tar.gz

    Run the following command to move the file to the /usr/local/bin directory:

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

    mv oc-ibm_pak-linux-amd64 /usr/local/bin/oc-ibm_pak

    Note: Download the plug-in based on the host operating system. You can confirm that oc ibm-pak -h is installed by running the following command:

    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 is replaced with the corresponding plug-in version, for example cp.icr.io/cpopen/cpfs/ibm-pak:v1.2.0 has v1.2.0 of the plug-in.

    The following command creates a container and copies the plug-ins for all the supported platforms in a directory, plugin-dir. You can specify any directory name and it is created while copying. After copying, it will delete the temporary container. The plugin-dir has all the binaries and other artifacts that you find in a 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

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 the images are getting mirrored 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 that 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 uses the ones that are specified by the CASEs. For example, it tries 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 the generation of mirror manifests, then you must create the following namespaces at the root of your registry.

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.

Set the environment and download the CASE file

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 via 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:

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

  1. Create the following environment variables with the installer image name and the version.

    export CASE_NAME=ibm-cert-manager
export CASE_VERSION=4.2.8

    To find the CASE name and version, see IBM: Product CASE to Application Version.

  2. Connect your host to the intranet.

  3. The plug-in can detect the locale of your environment and provide textual help and messages. You can optionally set the locale by running the following command:

    oc ibm-pak config locale -l LOCALE

    Where LOCALE can be one of de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_Hans, zh_Hant.

  4. 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

  5. Enable color output (optional with v1.4.0 and later).

    oc ibm-pak config color --enable true

  6. Download the image inventory for your IBM Cloud Pak to your host.

    Tip: 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 the plug-in is ~/.ibm-pak. This means that the preceding command downloads the CASE under ~/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION. You can configure this root directory by setting the IBMPAK_HOME environment variable. Assuming IBMPAK_HOME is set and the preceding command downloads the CASE under $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION.

If the download fails, you can try to increase the default values of the HTTP timeout and maximum HTTP retry attempts as required in the IBMPAK_HTTP_TIMEOUT and IBMPAK_HTTP_RETRY flags.

The log files are available at $IBMPAK_HOME/.ibm-pak/logs/oc-ibm_pak.log.

Your host is now configured and you are ready to mirror your images.

See the following notes:

Mirroring images to your private container registry

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

Generate mirror manifests

See the following notes:

    root/.ibm-pak
    ├── config
    │   └── config.yaml
    ├── data
    │   ├── cases
    │   │   └── $CASE_NAME
    │   │       └── $CASE_VERSION
    │   │           ├── caseDependencyMapping.csv
    │   │           ├── charts
    │   │           ├── component-set-config.yaml
    │   │           ├── xxx
    │   │           ├── xxx
    │   │           └── resourceIndexes
    │   │               └── ibm-cert-manager-resourcesIndex.yaml
    │   └── mirror
    │       └── $CASE_NAME
    │           └── $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-to-filesystem.txt, images-mapping-from-filesystem.txt, and catalog-sources.yaml files.

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

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

    Note down the Registries found sub sections in the preceding command output. You 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 preceding 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:

  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 docker login, the authentication file is typically 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. 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 image-content-source-policy.yaml and CatalogSource manifest in one or more catalog-sourcesXXX.yaml. 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.

Mirroring images to final location

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

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

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

      Note: 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 continues. For example, the following command starts the mirroring process in the 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:

      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 creates a subdirectory v2/local inside the 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

      Note: 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 continues. For example, the following command starts 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

  2. For disconnected mirrorings 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 mirrorings 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 images-mapping-from-filesystem.txt file 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

Preparing for unreliable network

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

  1. 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 while(5 seconds in the following example).

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

  2. You can passcontinue-on-error flag to oc image mirror command, set to true (--continue-on-error=true). This flag indicates that the command tries to mirror as much as possible and continue on errors like network issues. The 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 Container Platform 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 that is applied 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 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 ~/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/image-content-source-policy.yaml file 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.

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

  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=ibm-cert-manager

    oc new-project $NAMESPACE

  6. 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}'"]}}}'

  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 IBM Cert Manager with Red Hat OpenShift Container Platform

To install your IBM Cert Manager, complete the following steps:

Creating the catalog source and installing the IBM Cert Manager

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

  1. 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

  2. Verify that the CatalogSource for your IBM Cert Manager operator is created.

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

Installing the operator

You can use of the following methods to install the operator:

Installing the operator from OperatorHub with OpenShift Container Platform console

  1. Login to the OpenShift Container Platform console with the username and password.

  2. In the All Items field, enter IBM Cert Manager. The IBM Cert Manager operator is displayed.

  3. Click the IBM Cert Manager tile. The IBM Cert Manager window is displayed.

  4. Click Install. You see the Install Operator page.

  5. Set the Update Channel to the v4.2 version. If the Channel v4.2 version is not available, click other IBM Cert Manager tile from OperatorHub to install the correct version.

  6. Set Installation Mode to All namespaces on the cluster (default).

  7. Set Installed Namespace to ibm-cert-manager(Operator recommended)

  8. Set Update approval to Automatic.

  9. Click Install.

Installing the operator with CLI

  1. Create a YAML file named, def-certmanager.yaml, with the resources definitions that you need.

  2. Apply this YAML file:

    oc apply -f def-certmanager.yaml

    apiVersion: v1
kind: Namespace
metadata:
  name: ibm-cert-manager
---
apiVersion: operators.coreos.com/v1alpha2
kind: OperatorGroup
metadata:
  name: operatorgroup
  namespace: ibm-cert-manager
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ibm-cert-manager-operator
  namespace: ibm-cert-manager
spec:
  channel: v4.2
  installPlanApproval: Automatic
  name: ibm-cert-manager-operator
  source: ibm-cert-manager-catalog
  sourceNamespace: openshift-marketplace

Installing the operator with script

  1. Log in to the cluster as an administrator with the oc login command.

  2. Go to the ${installer-scripts}/cp3pt0-deployment directory in the downloaded CASE bundle. To download the scripts, see Downloading scripts for additional configuration from specific version CASE bundle.

    cd ${installer-scripts}/cp3pt0-deployment

  3. Run the following command to read the setup_singleton.sh script usage instructions:

    ./setup_singleton.sh -h

    The following output is displayed:

    Usage: setup_singleton.sh --license-accept [OPTIONS]...

Install Cloud Pak 3 pre-reqs if they do not already exist: ibm-cert-manager-operator and optionally ibm-licensing-operator
The ibm-cert-manager-operator will be installed in namespace ibm-cert-manager
The ibm-licensing-operator will be installed in namespace ibm-licensing
The --license-accept must be provided.

Options:
  --oc string                                    File path to oc CLI. Default uses oc in your PATH
  --operator-namespace string                    Namespace to migrate Cloud Pak 2 Foundational services
  --enable-licensing                             Set this flag to install ibm-licensing-operator
  --enable-private-catalog                       Set this flag to use namespace scoped CatalogSource. Default is in openshift-marketplace namespace
  --cert-manager-source string                   CatalogSource name of ibm-cert-manager-operator. This assumes your CatalogSource is already created. Default is ibm-cert-manager-catalog
  --licensing-source string                      CatalogSource name of ibm-licensing. This assumes your CatalogSource is already created. Default is ibm-licensing-catalog
  -cmNs, --cert-manager-namespace string         Set custom namespace for ibm-cert-manager-operator. Default is ibm-cert-manager
  -licensingNs, --licensing-namespace string     Set custom namespace for ibm-licensing-operator. Default is ibm-licensing
  --license-accept                               Set this flag to accept the license agreement.
  -c, --channel string                           Channel for Subscription(s). Default is v4.2
  -i, --install-mode string                      InstallPlan Approval Mode. Default is Automatic. Set to Manual for manual approval mode
  -h, --help                                     Print usage information

  4. If you need to migrate IBM Cert Manager v3.x.x from the existing IBM Cloud Pak, run the following command:

    ./setup_singleton.sh --license-accept --operator-namespace <Cloud Pak 2 Foundational Service Namespace>

    See the following notes:

    • You can skip this step if you download the script from CASE bundle v4.1.x or later in Step 2. The script determines the migration path automatically based on the version of the IBM Cert Manager installed in the cluster in the next step.
    • Ensure that the catalog source of the IBM Cert Manager exists in the openshift-marketplace namespace.

    • To determine <Cloud Pak 2 Foundational Service Namespace>, run the following command:

      $ oc get csv -A | grep ibm-cert-manager-operator.v3 | awk '{print $1}'
ibm-common-services

  5. If you need to install new IBM Cert Manager, run the following command:

    ./setup_singleton.sh --license-accept

  6. Verify that the following components are installed in the cluster.

    • Make sure that the IBM Cert-Manager Operator is installed in the ibm-cert-manager namespace.

      $ oc get subscription -n ibm-cert-manager
$ oc get csv -n ibm-cert-manager

      The following output is displayed:

      NAME                        PACKAGE                     SOURCE                CHANNEL
ibm-cert-manager-operator   ibm-cert-manager-operator   opencloud-operators   v4.2

NAME                               DISPLAY            VERSION   REPLACES   PHASE
ibm-cert-manager-operator.v4.2.8   IBM Cert Manager   4.2.8                Succeeded

    • Make sure that the IBM Cert-Manager-Config Operand is created.

      $ oc get certmanagerconfig -A

      The following output is displayed:

      NAME      AGE
default   75m

    • Make sure that the IBM Cert-Manager Pods are running in ibm-cert-manager namespace.

      $ oc get pods -n ibm-cert-manager

      The following output is displayed:

      NAME                                         READY   STATUS    RESTARTS   AGE
cert-manager-cainjector-7cfcd9948-lwh2n      1/1     Running   0          76m
cert-manager-controller-7759f789f5-2jldr     1/1     Running   0          76m
cert-manager-webhook-86b9b4b757-dvxg6        1/1     Running   0          76m
ibm-cert-manager-operator-747fdbf467-cc4ss   1/1     Running   0          77m

Setting the hardware profile and accepting the license

See the following notes:

  1. Edit the cert-manager-config resource:

    oc -n ibm-cert-manager edit CertManagerConfig default

  2. Update the cpu and memory of the requests and limits parameters to set the hardware profile. If you need to accept the license, add the spec.license.accept: true parameter.

    apiVersion: operator.ibm.com/v1
kind: CertManagerConfig
metadata:
  labels:
    app.kubernetes.io/instance: ibm-cert-manager-operator
    app.kubernetes.io/managed-by: ibm-cert-manager-operator
    app.kubernetes.io/name: cert-manager
  name: default
spec:
  license:
    accept: true
  certManagerController:
    resources:
      limits:
        cpu: 80m
        memory: 530Mi
      requests:
        cpu: 20m
        memory: 230Mi
  certManagerWebhook:
    resources:
      limits:
        cpu: 60m
        memory: 100Mi
      requests:
        cpu: 30m
        memory: 40Mi
  certManagerCAInjector:
    resources:
      limits:
        cpu: 100m
        memory: 520Mi
      requests:
        cpu: 20m
        memory: 410Mi
  enableCertRefresh: true
  enableWebhook: true
  version: 4.2.8
  imageRegistry: icr.io/cpopen/cpfs
  disableHostNetwork: true

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 Cloud Pak 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:

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

    Note: 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

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