Red Hat SummitRed Hat Blog
Today Red Hat announces Red Hat Quay 3.1.
Red Hat Quay is a distributed, highly available container registry for enterprises. This release builds on the focus to help Quay users store, build and deploy their images in a more secure way across diverse enterprise environments and to leverage several new backend technologies. With the availability of repository mirroring, a new Kubernetes Operator for a more streamlined setup, a new repository mode to support archived or (temporarily) frozen repositories and enhancements for storage and database support, this release hardens the product’s manageability across hybrid environments.
Get started with the release here. Read on for more details on the latest updates.
Content (re)distribution across the globe
The newest Quay feature is repository mirroring, supported in Technology Preview, which complements our existing geographic replication features. Both can be used side by side.
Quay geo-replication is designed for a shared, global registry. It mirrors the entire storage backend data between two or more different storage backends while the database, and therefore the entire Quay configuration and data, is shared. The primary use case for geo-replication is to speed up access to the binary blobs for geographically dispersed setups while content is the same across regions.
Repository mirroring takes this a step further for more diverse use cases. It has been designed for mirroring content between distinct, different registries. It allows a user to synchronize explicitly selected (whitelisted) repositories or a subset of it from any source registry into Quay. Customers can benefit from these features when getting content into and distributing content through Quay. This can provide an additional level of freedom and independence for distributed registries meanwhile helping to ensure that content that is used in more than one registry is mirrored to all other clusters and registries that are supposed to use it.
With repo mirroring in Quay, customers can:
-
continually synchronize repositories from external source registries into Quay (content ingress point)
-
mirror a subset of the entire registry content to distributed deployments
-
set up and apply filters to sync a smaller subset of a repository using tag filters
Mirroring across different regions and data centers helps distributed teams across the globe in cases that have rigorous requirements, such as if a subset can be stored in only one region but not another.
This capability makes use of the container tool Skopeo. Skopeo is a popular member of the OpenShift family, sharing underlying libraries with CRI-O, Podman and Buildah. Since Skopeo communicates directly with registry servers (no daemon required), it’s well suited for replication.
Operators to help deploy and manage the container registry
Operators, which encode the operational knowledge of the lifecycle and management of a Kubernetes-native application, have been on the rise in the Kubernetes ecosystem. Operators play an important role not only for the Kubernetes ecosystem, but also for Red Hat Quay in particular. Three major features of Red Hat Quay 3.1 are based on the Operator technology and other Operators are planned for future versions of Quay.
With this release of Quay, we introduce an Operator for Quay called the Quay Setup Operator that helps to deploy and maintain Quay on Red Hat OpenShift. A full Quay deployment (including a database) can be performed in minutes thanks to automation, which helps to more efficiently configure development and test environments. OpenShift customers can focus on their applications versus having to manage Quay. Initially marked as Developer Preview we plan to capture customer feedback and stabilize it before making it available as Generally Available in future releases of Quay. Customers are welcome to use it, provide feedback or even contribute to the code using the GitHub repository.
Storage backend leveraging NooBaa
Red Hat Quay already supports a variety of storage backends for both on-premise and cloud deployments. With Quay 3.1 we proudly introduce support for NooBaa, leveraging the NooBaa S3 Operator. NooBaa is a flexible, lightweight and scalable S3 API which supports various storage services underneath. NooBaa's Operator plans to be available as the Red Hat Multi-Cloud Object Gateway Operator, as part of Red Hat OpenShift Container Storage 3, with more features planned to be leveraged in future versions of Quay. This helps to set the stage to allow customers to use Red Hat OpenShift Container Storage in current and future versions with Quay.
A new entry in the dropdown menu for storage backends inside the configuration UI has been added for customers to try out in Technology Preview.
Support for partner offering to run PostgreSQL in HA mode on OpenShift using an Operator
While Quay could be deployed in a highly available manner running on OpenShift we recommended to run the database outside of the cluster in previous versions of Red Hat Quay. This is due to a lack of operational capabilities of stateful database applications if they run on Kubernetes. Now with Operator technology, it has helped to solve these types of operational problems. Today, Red Hat’s partner ecosystem offers various database Operators in Operatorhub.io.
Our focus is on the core registry and therefore we can leverage our partner ecosystem for areas of additional expertise. Starting with Red Hat Quay v3.1 customers can use the Crunchy Data PostgreSQL Operator, which has been tested to provision database backends of Quay.
"Crunchy Data greatly values its collaboration with Red Hat, and has been a first mover in contributing to open source technologies like the PostgreSQL Operator, which uses the Operator Framework. Crunchy Data helps the Red Hat Quay container registry to offer a resilient high-availability architecture for the PostgreSQL storage back end. Our mutual customers can scale their Quay environments with the confidence of an infrastructure agnostic, cloud-native database-as-a-service, and the backing of support from our skilled PostgreSQL engineers," said David Bagley, VP of Worldwide Sales, Crunchy Data.
Support for (temporarily) frozen or archived repositories
Certain customers are in the process of defining their operational models and processes for containerized applications. Meanwhile they also need to be aligned to several regulations or internal processes requiring additional governance as part of their application lifecycle management. They may need to keep all versions of their containerized applications that have been used in production for a certain amount, even after they’ve been decommissioned, or they may need to temporarily “freeze” a repository to prevent undesirable content changes.
To help satisfy those customer requirements Quay 3.1 introduces a read-only repository mode, otherwise known as frozen zones. This is designed to give developers more granular control over their environments at critical times, such as freezing certain zones from any changes right before a production release.
What’s ahead for Quay
Red Hat is committed to the continued development of Quay. We have a number of updates planned. In the future, we will continue to focus on a deeper integration into OpenShift as the industry’s most comprehensive enterprise Kubernetes platform using Operator based services, advanced vulnerability scanning and enhanced support for distributed, multi-cloud setups and air-gapped environments. For further information you can watch the most recent roadmap briefing.
Quay 3.1 is now available. Get started with Quay.
