Mirroring prerequisites

Complete the following perquisites before you mirror images of IBM Fusion and its services.

Install OC CLI and related mirroring tools

  1. Install Docker or Podman.
  2. Install oc command tool from any of the Red Hat OpenShift Container Platform cluster:
    1. Log in to the system from where you want to run commands.
    2. Log in to OpenShift Container Platform.
    3. Click bell icon and select Command line tools.
    4. Click the appropriate oc download option based on your operating system.

      Alternatively, you can also download the platform based oc client from the following OpenShift Container Platform link: https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.18.x/.

    5. Download and install ibm-pak OC plugin tool. For more information about the procedure, see https://github.com/IBM/ibm-pak.
      Note: IBM Fusion 2.12.x does not support image mirroring with oc‑mirror V2 when used with the ibm‑pak CLI. Newer versions of oc‑mirror use V2 mirroring behavior, which is not yet compatible with the current ibm‑pak CLI mirroring workflow. To successfully complete image mirroring for disconnected or offline installations, use oc‑mirror with V1 mirroring behavior.

Configure common environment variables

Define the following environment variables for your target container registry. Each of the subsequent steps makes use of these values to mirror all the related components.

export LOCAL_ISF_REGISTRY="<Your container registry host>:<port>"
export LOCAL_ISF_REPOSITORY="<Your image path>"
export TARGET_PATH="$LOCAL_ISF_REGISTRY/$LOCAL_ISF_REPOSITORY"

LOCAL_ISF_REGISTRY is your target container registry.

LOCAL_ISF_REGISTRY is the image path in which you want to mirror the images. You can choose your own repository paths. For example, sds-images/isf or sds-images. See the following sample values:

export LOCAL_ISF_REGISTRY="registryhost.com:443"
export LOCAL_ISF_REPOSITORY="mirror-all-fusion-2.12.1"
export TARGET_PATH="$LOCAL_ISF_REGISTRY/$LOCAL_ISF_REPOSITORY"

Considerations

  • Repository and target path must be same for IBM Fusion and IBM Storage Scale.
  • Run all commands as root user.
  • In the commands, replace <your enterprise registry> with your enterprise registry and its corresponding pull-secret.
  • If you use a non-default port (other than 443), then append a colon and port number after your enterprise registry value. For example, <Your enterprise registry>:9443.
  • You must mirror images to a single repository, a single registry, and a single path.
  • Depending on which IBM Fusion services you want to enable you can choose to only mirror images for that service, however you must mirror IBM Fusion images. Review the IBM Fusion and its services support matrix for platform compatibility. For more information, see IBM Fusion services and platform support matrix.
  • The offline mirroring process includes applying ImageDigestMirrorSet or ImageContentSourcePolicy files to your cluster. Any changes to the IDMS or ICSP on clusters triggers a MachineConfigPool rollout, which can cause nodes to reboot. This includes adding, updating, or deleting IDMS or ICSP files.

    There are two options for offline upgrade mirroring:

    Mirroring images to the same location as the previous offline installation
    This gives the IDMS or ICSP files that are identical to your previous installation, and you can choose to not apply the IDMS or ICSP files or oc apply the file and OpenShift® recognizes there is no change in content and exit gracefully.
    Mirror images to a different location as the previous offline installation
    Because the generated IDMS or ICSP is tailored specifically to the target offline registry, mirroring to a new location every time gives a different IDMS or ICSP every time. Applying a new IDMS or ICSP triggers the MCP rollout and contains the potential to reboot nodes, which can be disruptive to the health of the OpenShift cluster.
    Additionally, if you have done multiple offline upgrades using this method, then your cluster likely have multiple ICSP or IDMS files, some of which are old and unused. Again, deleting a IDMS or ICSP can trigger a disruptive MCP rollout. It is recommended to not delete any IDMS or ICSP files from the cluster until you have completed your upgrade to your target version of IBM Fusion HCI.

    However, the ibm-pak plugin generates an IDMS with the same name every time, if you use this method, it is recommended you to edit the generated IDMS and change the metadata.name to unique name to avoid overwriting an existing IDMS on your cluster.