Chapter 3. Configuring Red Hat Quay before deployment

1. Log in to the OpenShift Web Console.
2. Click Operators OperatorHub.
3. Type local storage into the search box to find the Local Storage Operator from the list of Operators. Click Local Storage.
4. Click Install.

5. Set the following options on the Install Operator page:

   • For Update channel, select stable.
   • For Installation mode, select A specific namespace on the cluster.
   • For Installed Namespace, select Operator recommended namespace openshift-local-storage.
   • For Update approval, select Automatic.
6. Click Install.

Procedure

1. Log in to the OpenShift Web Console.
2. Click Operators OperatorHub.
3. Type OpenShift Data Foundation in the search box. Click OpenShift Data Foundation.
4. Click Install.

5. Set the following options on the Install Operator page:

   • For Update channel, select the most recent stable version.
   • For Installation mode, select A specific namespace on the cluster.
   • For Installed Namespace, select Operator recommended Namespace: openshift-storage.

   • For Update approval, select Automatic or Manual.

     If you select Automatic updates, then the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without any intervention.

     If you select Manual updates, then the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to update the Operator to a newer version.

   • For Console plugin, select Enable.

6. Click Install.

   After the Operator is installed, a pop-up with a message, Web console update is available appears on the user interface. Click Refresh web console from this pop-up for the console changes to reflect.

7. Continue to the following section, "Creating a standalone Multicloud Object Gateway", to leverage the Multicloud Object Gateway Component for Red Hat Quay.

Procedure

1. In the OpenShift Web Console, click Operators Installed Operators to view all installed Operators.

   Ensure that the namespace is openshift-storage.

2. Click Create StorageSystem.

3. On the Backing storage page, select the following:

   1. Select Multicloud Object Gateway for Deployment type.
   2. Select the Create a new StorageClass using the local storage devices option.

   3. Click Next.

      Note

      You are prompted to install the Local Storage Operator if it is not already installed. Click Install, and follow the procedure as described in "Installing the Local Storage Operator on OpenShift Container Platform".

4. On the Create local volume set page, provide the following information:

   1. Enter a name for the LocalVolumeSet and the StorageClass. By default, the local volume set name appears for the storage class name. You can change the name.

   2. Choose one of the following:

      • Disk on all nodes

        Uses the available disks that match the selected filters on all the nodes.

      • Disk on selected nodes

        Uses the available disks that match the selected filters only on the selected nodes.

   3. From the available list of Disk Type, select SSD/NVMe.

   4. Expand the Advanced section and set the following options:

      Volume Mode	Filesystem is selected by default. Always ensure that Filesystem is selected for Volume Mode.
      Device Type	Select one or more device type from the dropdown list.
      Disk Size	Set a minimum size of 100GB for the device and maximum available size of the device that needs to be included.
      Maximum Disks Limit	This indicates the maximum number of PVs that can be created on a node. If this field is left empty, then PVs are created for all the available disks on the matching nodes.

   5. Click Next

      A pop-up to confirm the creation of LocalVolumeSet is displayed.

   6. Click Yes to continue.

5. In the Capacity and nodes page, configure the following:

   1. Available raw capacity is populated with the capacity value based on all the attached disks associated with the storage class. This takes some time to show up. The Selected nodes list shows the nodes based on the storage class.
   2. Click Next to continue.

6. Optional. Select the Connect to an external key management service checkbox. This is optional for cluster-wide encryption.

   1. From the Key Management Service Provider drop-down list, either select Vault or Thales CipherTrust Manager (using KMIP). If you selected Vault, go to the next step. If you selected Thales CipherTrust Manager (using KMIP), go to step iii.

   2. Select an Authentication Method.

      Using Token Authentication method

      • Enter a unique Connection Name, host Address of the Vault server ('https://<hostname or ip>'), Port number and Token.

      • Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

        • Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Data Foundation.
        • Optional: Enter TLS Server Name and Vault Enterprise Namespace.
        • Upload the respective PEM encoded certificate file to provide the CA Certificate, Client Certificate, and Client Private Key.

        • Click Save and skip to step iv.

          Using Kubernetes authentication method

      • Enter a unique Vault Connection Name, host Address of the Vault server ('https://<hostname or ip>'), Port number and Role name.

      • Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

        • Enter the Key Value secret path in Backend Path that is dedicated and unique to Red Hat OpenShift Data Foundation.
        • Optional: Enter TLS Server Name and Authentication Path if applicable.
        • Upload the respective PEM encoded certificate file to provide the CA Certificate, Client Certificate, and Client Private Key.
        • Click Save and skip to step iv.

   3. To use Thales CipherTrust Manager (using KMIP) as the KMS provider, follow the steps below:

      1. Enter a unique Connection Name for the Key Management service within the project.

      2. In the Address and Port sections, enter the IP of Thales CipherTrust Manager and the port where the KMIP interface is enabled. For example:

         • Address: 123.34.3.2
         • Port: 5696
      3. Upload the Client Certificate, CA certificate, and Client Private Key.
      4. If StorageClass encryption is enabled, enter the Unique Identifier to be used for encryption and decryption generated above.
      5. The TLS Server field is optional and used when there is no DNS entry for the KMIP endpoint. For example,kmip_all_<port>.ciphertrustmanager.local.
   4. Select a Network.
   5. Click Next.
7. In the Review and create page, review the configuration details. To modify any configuration settings, click Back.
8. Click Create StorageSystem.

Procedure

1. On the OpenShift Web Console, and then select Operators OperatorHub.
2. Search for Red Hat OpenShift Data Foundation, and then select Install.
3. Accept all default options, and then select Install.

4. Confirm that the Operator has installed by viewing the Status column, which should be marked as Succeeded.

   Warning

   When the installation of the Red Hat OpenShift Data Foundation Operator is finished, you are prompted to create a storage system. Do not follow this instruction. Instead, create NooBaa object storage as outlined the following steps.

5. On your machine, create a file named noobaa.yaml with the following information:

   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 creates a single instance deployment of the Multi-cloud Object Gateway.

6. Apply the configuration with the following command:

   $ oc create -n openshift-storage -f noobaa.yaml

   Example output

   noobaa.noobaa.io/noobaa created

7. After a few minutes, the Multi-cloud Object Gateway should finish provisioning. You can enter the following command to check its status:

   $ oc get -n openshift-storage noobaas noobaa -w

   Example output

   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

8. Configure a backing store for the gateway by creating the following YAML file, named 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.

9. Enter the following command to apply the configuration:

   $ oc create -f noobaa-pv-backing-store.yaml

   Example output

   backingstore.noobaa.io/noobaa-pv-backing-store created

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

10. Run the following command to make the PersistentVolume backing store the default for all ObjectBucketClaims issued by the Red Hat Quay Operator:

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