Chapter 9. Using Operator Lifecycle Manager on restricted networks

Procedure

1. Disable the default OperatorSources.

   Add disableAllDefaultSources: true to the spec:

   $ oc patch OperatorHub cluster --type json \
       -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

   This disables the default OperatorSources that are configured by default during an OpenShift Container Platform installation.

2. Retrieve package lists.

   To get the list of packages that are available for the default OperatorSources, run the following curl commands from your workstation without network restrictions:

   $ curl https://quay.io/cnr/api/v1/packages?namespace=redhat-operators > packages.txt
   $ curl https://quay.io/cnr/api/v1/packages?namespace=community-operators >> packages.txt
   $ curl https://quay.io/cnr/api/v1/packages?namespace=certified-operators >> packages.txt

   Each package in the new packages.txt is an Operator that you could add to your restricted network catalog. From this list, you could either pull every Operator or a subset that you would like to expose to users.

3. Pull Operator content.

   For a given Operator in the package list, you must pull the latest released content:

   $ curl https://quay.io/cnr/api/v1/packages/<namespace>/<operator_name>/<release>

   This example uses the etcd Operator:

   1. Retrieve the digest:

      $ curl https://quay.io/cnr/api/v1/packages/community-operators/etcd/0.0.12

   2. From that JSON, take the digest and use it to pull the gzipped archive:

      $ curl -XGET https://quay.io/cnr/api/v1/packages/community-operators/etcd/blobs/sha256/8108475ee5e83a0187d6d0a729451ef1ce6d34c44a868a200151c36f3232822b \
          -o etcd.tar.gz

   3. To pull the information out, you must untar the archive into a manifests/<operator_name>/ directory with all the other Operators that you want. For example, to untar to an existing directory called manifests/etcd/:

      $ mkdir -p manifests/etcd/ 1
      $ tar -xf etcd.tar.gz -C manifests/etcd/

      1

      Create different subdirectories for each extracted archive so that files are not overwritten by subsequent extractions for other Operators.

4. Break apart bundle.yaml content, if necessary.

   In your new manifests/<operator_name> directory, the goal is to get your bundle in the following directory structure:

   manifests/
   └── etcd
       ├── 0.0.12
       │   ├── clusterserviceversion.yaml
       │   └── customresourcedefinition.yaml
       └── package.yaml

   If you see files already in this structure, you can skip this step. However, if you instead see only a single file called bundle.yaml, you must first break this file up to conform to the required structure.

   You must separate the CSV content under data.clusterServiceVersion (each file in the list), the CRD content under data.customResourceDefinition (each file in the list), and the package content under data.Package into their own files.

   1. For the CSV file creation, find the following lines in the bundle.yaml file:

      data:
        clusterServiceVersions: |

      Omit those lines, but save a new file consisting of the full CSV resource content beginning with the following lines, removing the prepended - character:

      Example clusterserviceversion.yaml file snippet

      apiVersion: operators.coreos.com/v1alpha1
      kind: ClusterServiceVersion
      [...]

   2. For the CRD file creation, find the following line in the bundle.yaml file:

        customResourceDefinitions: |

      Omit this line, but save new files consisting of each, full CRD resource content beginning with the following lines, removing the prepended - character:

      Example customresourcedefinition.yaml file snippet

      apiVersion: apiextensions.k8s.io/v1beta1
      kind: CustomResourceDefinition
      [...]

   3. For the package file creation, find the following line in the bundle.yaml file:

        packages: |

      Omit this line, but save a new file consisting of the package content beginning with the following lines, removing the prepended - character, and ending with a packageName entry:

      Example package.yaml file

      channels:
      - currentCSV: etcdoperator.v0.9.4
        name: singlenamespace-alpha
      - currentCSV: etcdoperator.v0.9.4-clusterwide
        name: clusterwide-alpha
      defaultChannel: singlenamespace-alpha
      packageName: etcd

5. Identify images required by the Operators you want to use.

   Inspect the CSV files of each Operator for image: fields to identify the pull specs for any images required by the Operator, and note them for use in a later step.

   For example, in the following deployments spec of an etcd Operator CSV:

     spec:
      serviceAccountName: etcd-operator
      containers:
      - name: etcd-operator
        command:
        - etcd-operator
        - --create-crd=false
        image: quay.io/coreos/etcd-operator@sha256:bd944a211eaf8f31da5e6d69e8541e7cada8f16a9f7a5a570b22478997819943 1
        env:
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name

   1

   Image required by Operator.

6. Create an Operator catalog image.

   1. Save the following to a Dockerfile, for example named custom-registry.Dockerfile:

      FROM registry.redhat.io/openshift4/ose-operator-registry:v4.2.24 AS builder
      
      COPY manifests manifests
      
      RUN /bin/initializer -o ./bundles.db
      
      FROM registry.access.redhat.com/ubi7/ubi
      
      COPY --from=builder /registry/bundles.db /bundles.db
      COPY --from=builder /usr/bin/registry-server /registry-server
      COPY --from=builder /bin/grpc_health_probe /bin/grpc_health_probe
      
      EXPOSE 50051
      
      ENTRYPOINT ["/registry-server"]
      
      CMD ["--database", "bundles.db"]

   2. Use the podman command to create and tag the container image from the Dockerfile:

      $ podman build -f custom-registry.Dockerfile \
          -t <local_registry_host_name>:<local_registry_host_port>/<namespace>/custom-registry 1

      1

      Tag the image for the internal registry of the restricted network OpenShift Container Platform cluster and any namespace.

7. Push the Operator catalog image to a registry.

   Your new Operator catalog image must be pushed to a registry that the restricted network OpenShift Container Platform cluster can access. This can be the internal registry of the cluster itself or another registry that the cluster has network access to, such as an on-premise Quay Enterprise registry.

   For this example, login and push the image to the internal registry OpenShift Container Platform cluster:

   $ podman push <local_registry_host_name>:<local_registry_host_port>/<namespace>/custom-registry

8. Create a CatalogSource pointing to the new Operator catalog image.

   1. Save the following to a file, for example my-operator-catalog.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        displayName: My Operator Catalog
        sourceType: grpc
        image: <local_registry_host_name>:<local_registry_host_port>/<namespace>/custom-registry:latest

   2. Create the CatalogSource resource:

      $ oc create -f my-operator-catalog.yaml

   3. Verify the CatalogSource and package manifest are created successfully:

      # oc get pods -n openshift-marketplace
      NAME READY STATUS RESTARTS AGE
      my-operator-catalog-6njx6 1/1 Running 0 28s
      marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
      
      # oc get catalogsource -n openshift-marketplace
      NAME DISPLAY TYPE PUBLISHER AGE
      my-operator-catalog My Operator Catalog grpc 5s
      
      # oc get packagemanifest -n openshift-marketplace
      NAME CATALOG AGE
      etcd My Operator Catalog 34s

      You should also be able to view them from the OperatorHub page in the web console.

9. Mirror the images required by the Operators you want to use.

   1. Determine the images defined by the Operator(s) that you are expecting. This example uses the etcd Operator, requiring the quay.io/coreos/etcd-operator image.

      Important

      This procedure only shows mirroring Operator images themselves and not Operand images, which are the components that an Operator manages. Operand images must be mirrored as well; see each Operator’s documentation to identify the required Operand images.

   2. To use mirrored images, you must first create an ImageContentSourcePolicy for each image to change the source location of the Operator catalog image. For example:

      apiVersion: operator.openshift.io/v1alpha1
      kind: ImageContentSourcePolicy
      metadata:
        name: etcd-operator
      spec:
        repositoryDigestMirrors:
        - mirrors:
          - <local_registry_host_name>:<local_registry_host_port>/coreos/etcd-operator
          source: quay.io/coreos/etcd-operator

   3. Use the oc image mirror command from your workstation without network restrictions to pull the image from the source registry and push to the internal registry without being stored locally:

      $ oc image mirror quay.io/coreos/etcd-operator \
          <local_registry_host_name>:<local_registry_host_port>/coreos/etcd-operator