Chapter 1. Introduction to the Red Hat Quay Operator Use the content in this chapter to execute the following: Install Red Hat Quay on OpenShift Container Platform using the Red Hat Quay Operator Configure managed, or unmanaged, object storage Configure unmanaged components, such as the database, Redis, routes, TLS, and so on Deploy the Red Hat Quay registry on OpenShift Container Platform using the Red Hat Quay Operator Use advanced features supported by Red Hat Quay Upgrade the Red Hat Quay registry by using the Red Hat Quay Operator 1.1. Red Hat Quay Operator components Red Hat Quay has many dependencies. These dependencies include a database, object storage, Redis, and others. The Red Hat Quay Operator manages an opinionated deployment of Red Hat Quay and its dependencies on Kubernetes. These dependencies are treated as components and are configured through the QuayRegistry API. In the QuayRegistry custom resource, the spec.components field configures components. Each component contains two fields: kind (the name of the component), and managed (a boolean that addresses whether the component lifecycle is handled by the Red Hat Quay Operator). By default, all components are managed and auto-filled upon reconciliation for visibility: Example QuayRegistry resource apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: quay managed: true - kind: postgres managed: true - kind: clair managed: true - kind: redis managed: true - kind: horizontalpodautoscaler managed: true - kind: objectstorage managed: true - kind: route managed: true - kind: mirror managed: true - kind: monitoring managed: true - kind: tls managed: true - kind: clairpostgres managed: true 1.2. Using managed components Unless your QuayRegistry custom resource specifies otherwise, the Red Hat Quay Operator uses defaults for the following managed components: quay: Holds overrides for deployment of Red Hat Quay on OpenShift Container Platform, for example, environment variables and number of replicas. This component is new as of Red Hat Quay 3.7 and cannot be set to unmanaged. postgres: For storing the registry metadata, As of Red Hat Quay 3.9, uses a version of PostgreSQL 13 from Software Collections . Note When upgrading from Red Hat Quay 3.8 3.9, the Operator automatically handles upgrading PostgreSQL 10 to PostgreSQL 13. This upgrade is required. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. clair: Provides image vulnerability scanning. redis: Stores live builder logs and the Red Hat Quay tutorial. Also includes the locking mechanism that is required for garbage collection. horizontalpodautoscaler: Adjusts the number of Quay pods depending on memory/cpu consumption. objectstorage: For storing image layer blobs, utilizes the ObjectBucketClaim Kubernetes API which is provided by Noobaa or Red Hat OpenShift Data Foundation. route: Provides an external entrypoint to the Red Hat Quay registry from outside of OpenShift Container Platform. mirror: Configures repository mirror workers to support optional repository mirroring. monitoring: Features include a Grafana dashboard, access to individual metrics, and notifications for frequently restarting Quay pods. tls: Configures whether Red Hat Quay or OpenShift Container Platform handles SSL/TLS. clairpostgres: Configures a managed Clair database. This is a separate database than the PostgreSQL database used to deploy Red Hat Quay. The Red Hat Quay Operator handles any required configuration and installation work needed for Red Hat Quay to use the managed components. If the opinionated deployment performed by the Red Hat Quay Operator is unsuitable for your environment, you can provide the Red Hat Quay Operator with unmanaged resources, or overrides, as described in the following sections. 1.3. Using unmanaged components for dependencies If you have existing components such as PostgreSQL, Redis, or object storage that you want to use with Red Hat Quay, you first configure them within the Red Hat Quay configuration bundle, or the config.yaml file. Then, they must be referenced in your QuayRegistry bundle as a Kubernetes Secret while indicating which components are unmanaged. Note If you are using an unmanaged PostgreSQL database, and the version is PostgreSQL 10, it is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the PostgreSQL Versioning Policy . See the following sections for configuring unmanaged components: Using an existing PostgreSQL database Using unmanaged Horizontal Pod Autoscalers Using unmanaged storage Using an unmanaged NooBaa instance Using an unmanaged Redis database Disabling the route component Disabling the monitoring component Disabling the mirroring component 1.4. Config bundle secret The spec.configBundleSecret field is a reference to the metadata.name of a Secret in the same namespace as the QuayRegistry resource. This Secret must contain a config.yaml key/value pair. The config.yaml file is a Red Hat Quay config.yaml file. This field is optional, and is auto-filled by the Red Hat Quay Operator if not provided. If provided, it serves as the base set of config fields which are later merged with other fields from any managed components to form a final output Secret , which is then mounted into the Red Hat Quay application pods. 1.5. Prerequisites for Red Hat Quay on OpenShift Container Platform Consider the following prerequisites prior to deploying Red Hat Quay on OpenShift Container Platform using the Red Hat Quay Operator. 1.5.1. OpenShift Container Platform cluster To deploy the Red Hat Quay Operator, you must have an OpenShift Container Platform 4.5 or later cluster and access to an administrative account. The administrative account must have the ability to create namespaces at the cluster scope. 1.5.2. Resource Requirements Each Red Hat Quay application pod has the following resource requirements: 8 Gi of memory 2000 millicores of CPU The Red Hat Quay Operator creates at least one application pod per Red Hat Quay deployment it manages. Ensure your OpenShift Container Platform cluster has sufficient compute resources for these requirements. 1.5.3. Object Storage By default, the Red Hat Quay Operator uses the ObjectBucketClaim Kubernetes API to provision object storage. Consuming this API decouples the Red Hat Quay Operator from any vendor-specific implementation. Red Hat OpenShift Data Foundation provides this API through its NooBaa component, which is used as an example throughout this documentation. Red Hat Quay can be manually configured to use any of the following supported cloud storage options: Amazon S3 (see S3 IAM Bucket Policy for details on configuring an S3 bucket policy for Red Hat Quay) Microsoft Azure Blob Storage Google Cloud Storage Ceph Object Gateway (RADOS) OpenStack Swift CloudFront + S3 1.5.4. StorageClass When deploying Quay and Clair PostgreSQL databases using the Red Hat Quay Operator, a default StorageClass is configured in your cluster. The default StorageClass used by the Red Hat Quay Operator provisions the Persistent Volume Claims required by the Quay and Clair databases. These PVCs are used to store data persistently, ensuring that your Red Hat Quay registry and Clair vulnerability scanner remain available and maintain their state across restarts or failures. Before proceeding with the installation, verify that a default StorageClass is configured in your cluster to ensure seamless provisioning of storage for Quay and Clair components.

Commands:
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: quay managed: true - kind: postgres managed: true - kind: clair managed: true - kind: redis managed: true - kind: horizontalpodautoscaler managed: true - kind: objectstorage managed: true - kind: route managed: true - kind: mirror managed: true - kind: monitoring managed: true - kind: tls managed: true - kind: clairpostgres managed: true