Chapter 1. Introduction to the Red Hat Quay Operator
This document outlines the steps for configuring, deploying, managing and upgrading Red Hat Quay on OpenShift using the Red Hat Quay Operator.
It shows you how to:
- Install the Red Hat Quay Operator
- Configure object storage, either managed or unmanaged
- Configure other unmanaged components, if required, including database, Redis, routes, TLS, etc.
- Deploy the Red Hat Quay registry on OpenShift using the Operator
- Use advanced features supported by the Operator
- Upgrade the registry by upgrading the Operator
1.1. QuayRegistry API
The Quay Operator provides the
QuayRegistry custom resource API to declaratively manage
Quay container registries on the cluster. Use either the OpenShift UI or a command-line tool to interact with this API.
QuayRegistrywill result in the Operator deploying and configuring all necessary resources needed to run Quay on the cluster.
QuayRegistrywill result in the Operator reconciling the changes and creating/updating/deleting objects to match the desired configuration.
QuayRegistrywill result in garbage collection of all previously created resources and the
Quaycontainer registry will no longer be available.
QuayRegistry API is fairly simple, and the fields are outlined in the following sections.
1.2. Quay Operator components
Quay is a powerful container registry platform and as a result, has a significant number of dependencies. These include a database, object storage, Redis, and others. The Quay Operator manages an opinionated deployment of Quay and its dependencies on Kubernetes. These dependencies are treated as components and are configured through the
QuayRegistry custom resource, the
spec.components field configures components. Each component contains two fields:
kind - the name of the component, and
managed - boolean whether the component lifecycle is handled by the Operator. By default (omitting this field), all components are managed and will be autofilled upon reconciliation for visibility:
spec: components: - managed: true kind: clair - managed: true kind: postgres - managed: true kind: objectstorage - managed: true kind: redis - managed: true kind: horizontalpodautoscaler - managed: true kind: route - managed: true kind: mirror - managed: true kind: monitoring - managed: true kind: tls
1.3. Using managed components
QuayRegistry custom resource specifies otherwise, the Operator will use defaults for the following managed components:
- postgres: For storing the registry metadata, uses a version of Postgres 10 from the Software Collections
- redis: Handles Quay builder coordination and some internal logging
objectstorage: For storing image layer blobs, utilizes the
ObjectBucketClaimKubernetes API which is provided by Noobaa/RHOCS
- clair: Provides image vulnerability scanning
- horizontalpodautoscaler: Adjusts the number of Quay pods depending on memory/cpu consumption
- mirror: Configures repository mirror workers (to support optional repository mirroring)
- route: Provides an external entrypoint to the Quay registry from outside OpenShift
- 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 handles TLS
The Operator will handle any required configuration and installation work needed for Red Hat Quay to use the managed components. If the opinionated deployment performed by the Quay Operator is unsuitable for your environment, you can provide the Operator with
unmanaged resources (overrides) as described in the following sections.
1.4. Using unmanaged components for dependencies
If you have existing components such as Postgres, Redis or object storage that you would like to use with Quay, you first configure them within the Quay configuration bundle (
config.yaml) and then reference the bundle in your
QuayRegistry (as a Kubernetes
Secret) while indicating which components are unmanaged.
The 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 Quay’s configuration is changed via the config editor and sent to the Operator, the Quay deployment will be updated to reflect the new configuration.
1.5. Config bundle secret
spec.configBundleSecret field is a reference to the
metadata.name of a
Secret in the same namespace as the
Secret must contain a
config.yaml key/value pair. This
config.yaml file is a Quay config YAML file. This field is optional, and will be auto-filled by the 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 Quay application pods.
1.6. Prerequisites for Red Hat Quay on OpenShift
Before you begin the deployment of Red Hat Quay Operator on OpenShift, you should consider the following.
1.6.1. OpenShift cluster
You need a privileged account to an OpenShift 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.6.2. Resource Requirements
Each Red Hat Quay application pod has the following resource requirements:
- 8Gi of memory
- 2000 millicores of CPU.
The Red Hat Quay Operator will create at least one application pod per Red Hat Quay deployment it manages. Ensure your OpenShift cluster has sufficient compute resources for these requirements.
1.6.3. Object Storage
By default, the Red Hat Quay Operator uses the
ObjectBucketClaim Kubernetes API to provision object storage. Consuming this API decouples the Operator from any vendor-specific implementation. Red Hat OpenShift Data Foundation provides this API via 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)
- Azure Blob Storage
- Google Cloud Storage
- Ceph Object Gateway (RADOS)
- OpenStack Swift
- CloudFront + S3