Chapter 1. Introduction to the Red Hat Quay Operator
Chapter 1. Introduction to the Red Hat Quay Operator Use the content in this chapter to execute the following: Install 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 the Red Hat Quay Operator Upgrade the registry by upgrading the Red Hat Quay Operator 1.1. Red Hat Quay Operator components Red Hat Quay has a significant number of dependencies. These 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: spec: 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 the Red Hat Quay deployment. 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 RHOCS. 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 alerting to notify 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 (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 ( config.yaml ). Then, they must be referenced in your QuayRegistry bundle as a Kubernetes Secret while indicating which components are unmanaged. Note The Red Hat Quay config editor can also be used to create or modify an existing config bundle and simplifies the process of updating the Kubernetes Secret , especially for multiple changes. When Red Hat Quay's configuration is changed by the config editor and sent to the Red Hat Quay Operator, the deployment is updated to reflect the new configuration. 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 . This Secret must contain a config.yaml key/value pair. This 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 Before you begin the deployment of Red Hat Quay Operator on OpenShift Container Platform, you should consider the following. 1.5.1. OpenShift cluster You need a privileged account to an OpenShift Container Platform 4.5 or later cluster on which to deploy the Red Hat Quay Operator. That 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 will be used in this example. 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) MicroShift Azure Blob Storage Google Cloud Storage Ceph Object Gateway (RADOS) OpenStack Swift CloudFront + S3
spec: 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