Chapter 2. Installing the Quay Operator

2.1. Differences from Earlier Versions

As of Red Hat Quay 3.4.0, the Operator has been completely re-written to provide an improved out of the box experience as well as support for more Day 2 operations. As a result the new Operator is simpler to use and is more opinionated. The key differences from earlier versions of the Operator are:

  • The QuayEcosystem custom resource has been replaced with the QuayRegistry custom resource
  • The default installation options produces a fully supported Quay environment with all managed dependencies (database, caches, object storage, etc) supported for production use (some components may not be highly available)
  • A new robust validation library for Quay’s configuration which is shared by the Quay application and config tool for consistency
  • Object storage can now be managed by the Operator using the ObjectBucketClaim Kubernetes API (Red Hat OpenShift Data Foundations can be used to provide a supported implementation of this API on OpenShift)
  • Customization of the container images used by deployed pods for testing and development scenarios

2.2. Before Installing the Quay Operator

2.2.1. Deciding On a Storage Solution

If you want the Operator to manage object storage for Quay, your cluster needs to be capable of providing object storage via the ObjectBucketClaim API. Using the Red Hat OpenShift Data Foundations (ODF) Operator, there are two supported options available:

  • A standalone instance of the Multi-Cloud Object Gateway backed by a local Kubernetes PersistentVolume storage

    • Not highly available
    • Included in the Quay subscription
    • Does not require a separate subscription for ODF
  • A production deployment of ODF with scale-out Object Service and Ceph

    • Highly available
    • Requires a separate subscription for ODF

To use the standalone instance option, continue reading below. For production deployment of ODF, please refer to the official documentation.

If you already have object storage available via the ObjectBucketClaim API or using an external S3-compatible object storage service (e.g. from a cloud provider), skip to Installing the Operator.

2.2.2. About The Standalone Object Gateway

As part of a Red Hat Quay subscription, users are entitled to use the Multi-Cloud Object Gateway (MCG) component of the Red Hat OpenShift Data Foundations Operator (formerly known as OpenShift Container Storage Operator). This gateway component allows you to provide an S3-compatible object storage interface to Quay backed by Kubernetes PersistentVolume-based block storage. The usage is limited to a Quay deployment managed by the Operator and to the exact specifications of the MCG instance as documented below.

Since Red Hat Quay does not support local filesystem storage, users can leverage the gateway in combination with Kubernetes PersistentVolume storage instead, to provide a supported deployment. A PersistentVolume is directly mounted on the gateway instance as a backing store for object storage and any block-based StorageClass is supported.

By the nature of PersistentVolume, this is not a scale-out, highly available solution and does not replace a scale-out storage system like Red Hat OpenShift Data Foundations (ODF). Only a single instance of the gateway is running. If the the pod running the gateway becomes unavailable due to rescheduling, updates or unplanned downtime, this will cause temporary degradation of the connected Quay instances.

2.2.3. Create A Standalone Object Gateway

To install the ODF (formerly known as OpenShift Container Storage) Operator and configure a single instance Multi-Cloud Gateway service, follow these steps:

  1. Open the OpenShift console and select Operators → OperatorHub, then select the OpenShift Container Storage Operator.
  2. Select Install. Accept all default options and select Install again.
  3. Within a minute, the Operator will install and create a namespace openshift-storage. You can confirm it has completed when the Status column is marked Succeeded.
  4. Create NooBaa object storage. Save the following YAML to a file called noobaa.yaml.

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: '0.1'
         memory: 1Gi
     dbType: postgres
     coreResources:
       requests:
         cpu: '0.1'
         memory: 1Gi

    This will create a single instance deployment of the Multi-cloud Object Gateway.

  5. Apply the configuration with the following command:

    $ oc create -n openshift-storage -f noobaa.yaml
    noobaa.noobaa.io/noobaa created
  6. After a couple of minutes, you should see that the MCG instance has finished provisioning (PHASE column will be set to Ready):

    $ oc get -n openshift-storage noobaas noobaa -w
    NAME     MGMT-ENDPOINTS              S3-ENDPOINTS                IMAGE                                                                                                            PHASE   AGE
    noobaa   [https://10.0.32.3:30318]   [https://10.0.32.3:31958]   registry.redhat.io/ocs4/mcg-core-rhel8@sha256:56624aa7dd4ca178c1887343c7445a9425a841600b1309f6deace37ce6b8678d   Ready   3d18h
  7. Next, configure a backing store for the gateway. Save the following YAML to a file called noobaa-pv-backing-store.yaml.

    noobaa-pv-backing-store.yaml

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: noobaa-pv-backing-store
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 1
        resources:
          requests:
            storage: 50Gi 1
        storageClass: STORAGE-CLASS-NAME 2
      type: pv-pool

    1
    The overall capacity of the object storage service, adjust as needed
    2
    The StorageClass to use for the PersistentVolumes requested, delete this property to use the cluster default
  8. Apply the configuration with the following command:

    $ oc create -f noobaa-pv-backing-store.yaml
    backingstore.noobaa.io/noobaa-pv-backing-store created

    This creates the backing store configuration for the gateway. All images in Quay will be stored as objects through the gateway in a PersistentVolume created by the above configuration.

  9. Finally, run the following command to make the PersistentVolume backing store the default for all ObjectBucketClaims issued by the Operator.

    $ oc patch bucketclass noobaa-default-bucket-class --patch '{"spec":{"placementPolicy":{"tiers":[{"backingStores":["noobaa-pv-backing-store"]}]}}}' --type merge -n openshift-storage

This concludes the setup of the Multi-Cloud Object Gateway instance for Red Hat Quay. Note that this configuration cannot be run in parallel on a cluster with Red Hat OpenShift Data Foundations installed.

2.3. Installing the Operator from OperatorHub

  1. Using the OpenShift console, Select Operators → OperatorHub, then select the Quay Operator. If there is more than one, be sure to use the Red Hat certified Operator and not the community version.
  2. Select Install. The Operator Subscription page appears.
  3. Choose the following then select Subscribe:

    • Installation Mode: Choose either 'All namespaces' or 'A specific namespace' depending on whether you want the Operator to be available cluster-wide or only within a single namespace (all-namespaces recommended)

      If you choose to install in a single namespace, you must set the monitoring component to false:

      spec:
        components:
          - kind: monitoring
            managed: false
    • Update Channel: Choose the update channel (only one may be available)
    • Approval Strategy: Choose to approve automatic or manual updates
  4. Select Install.
  5. After a minute you will see the Operator installed successfully in the Installed Operators page.