In this article, i’ll walk through the process of configuring a self-hosted Quay registry inside a private OpenShift cluster. Quay, developed by Red Hat, is a robust and versatile container registry that includes features like built-in image scanning, automated builds, and more.
Why Quay?
Quay provides a more feature-rich and flexible option compared to the integrated Docker registry in OpenShift. With Quay, you can take advantage of robust security features, a user-friendly web interface, and advanced image management capabilities, making it an ideal choice for enterprise-level applications.
Prerequisites
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.
My demo is using crc. Also Note that I won’t cover certificate signing in this demo.
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.
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 article.
Red Hat Quay can be manually configured to use multiple storage cloud providers, including the following:
- 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
Installing the Quay Operator in OpenShift
oc new-project quay-enterpriseLogin to Openshift Console. Navigate to OperatorHub and select your project from the dropdown menu in the top left corner. Then, use the search box to look for Red Hat Quay and click Install.
Deciding Storage Solution
If you want the Operator to manage its own object storage, you will first need to ensure the Red Hat OpenShift Data Foundation Operator (formerly known as OpenShift Container Storage Operator) is available on your OpenShift cluster to provide the ObjectBucketClaim API.
Install Red Hat OpenShift Data Foundation. Navigate to OperatorHub and select your project from the dropdown menu in the top left corner. Then, use the search box to look for Openshift Data Foundation and click Install.
After the Operator is installed, a pop-up with a message, Web console update is available appears on the user interface. You can confirm it is completed when the Status column is marked Succeeded.
Create NooBaa object storage. Save the following YAML to a file called noobaa.yml
apiVersion: noobaa.io/v1alpha1
kind: NooBaa
metadata:
name: noobaa
namespace: openshift-storage
spec:
dbResources:
requests:
cpu: '0.1'
memory: 1Gi
coreResources:
requests:
cpu: '0.1'
memory: 1Gioc create -n openshift-storage -f noobaa.yml
noobaa.noobaa.io/noobaa created
After a minute or so, you should see the object storage ready for use (PHASE column is marked Ready)
oc get -n openshift-storage noobaas noobaa -woc get -n openshift-storage noobaas noobaa
NAME S3-ENDPOINTS STS-ENDPOINTS SYSLOG-ENDPOINTS IMAGE PHASE AGE
noobaa ["https://192.168.126.11:31045"] ["https://192.168.126.11:30673"] registry.redhat.io/odf4/mcg-core-rhel9@sha256:728d12151320b501b63ae8cd60f10430532d3e0d231e2fcf02098c36e7e64249 Ready 71sCreating Quay Registry
The default configuration tells the Operator to manage all of Quay’s dependencies (database, Redis, object storage, etc).
- Select Operators Installed Operators, then select the Quay Operator to navigate to the Operator detail view.
- Click 'Create Instance' on the 'Quay Registry' tile under 'Provided APIs'.
- Optionally change the 'Name' of the
QuayRegistry. This will affect the hostname of the registry. All other fields have been populated with defaults. - Click 'Create' to submit the
QuayRegistryto be deployed by the Quay Operator. - You should be redirected to the
QuayRegistrylist view. Click on theQuayRegistryyou just created to see the detail view. - Once the 'Registry Endpoint' has a value, click it to access your new Quay registry via the UI. You can now select 'Create Account' to create a user and sign in.
If you're looking to customize external access to your registry, you can follow the guide in the link below.
Mirror Images
Create a sample repository on Quay to serve as a reference for testing.
With Quay up and running, you can now mirror images from public registries to your Quay registry. Here’s an example:
skopeo copy --dest-tls-verify=false \
docker://docker.io/library/nginx:alpine \
docker://rj-sample-registry-quay-quay-enterprise.router-default.apps-crc.testing/rjhaikal/nginx:alpine
Key Considerations
Security: Quay includes integrated security features, such as Clair for vulnerability scanning and the option to create robot accounts with restricted and temporary permissions.
Storage: As with any registry, Quay needs a significant amount of storage space. Although it can utilize the cluster’s storage, considering external storage may be beneficial for better scalability and performance.
Backup and Disaster Recovery: Make sure you have strategies in place for backing up and recovering your Quay data to maintain business continuity.
Reference
