If you're working on a cloud environment that requires the Continuous Integration (CI) process from CI/CD, you need to consider how to store and manage the built packages. What do I mean by packages? These packages can be archive files like WAR or EAR files for Java, but they can also be containerized images that include the compiled sources combined with a programming run time. They might also be base images like NodeJS, CentOS, RHEL, Windows, Python, etc. If you want to store and manage container images, you need to have a container image registry that is easy to operate yet flexible, powerful, and secure enough to meet the industry standard.
[ You might also enjoy: Essential components of a Linux-based air-gapped network ]
Enter Quay. Quay is a container registry for storing containers, Helm charts, and other container-related content. There are three flavors of Quay:
- Red Hat Quay.io
- Red Hat Quay
- Project Quay
Let's examine these in more detail.
Three flavors of Quay
First is Quay.io, which is supported and managed by Red Hat and offers enterprise-level support. The service has a variety of pricing tiers for private repositories, depending on your organization's needs, and public repositories can be hosted for free. Quay.io also includes additional features for building and scanning images.
The second option is Red Hat Quay, which can be deployed as an on-premises solution or in a private cloud environment. This option is also available through Red Hat OpenShift as a built-in Operator.
Both of these options are built upon the foundation of Project Quay. Project Quay is an open source container image registry maintained by the community and based on the Apache 2.0 License. Although Project Quay is a community-driven open source project, it includes Clair, a leading container vulnerability scanner.
Project Quay is an open source project, which means you can contribute through its GitHub repository.
How do you decide which one to use?
Although there is really no gold answer that works for all scenarios, here is a table that can help you to narrow down your choice.
|Scenario||What you probably need|
|If you are just starting as a hobbyist and wanting something to deploy your container image right away||You probably want Quay.io|
|If you want to explore or contribute to an upstream project, and are not in need of a production-ready enterprise solution||You probably want Project Quay|
|If you want enterprise-level support, do not need on-premise hosting, and want to minimize the learning curve||You probably want Quay.io|
|If you want enterprise-level support and want to deploy in your own cloud environment||You probably want Red Hat Quay|
How to get started?
After you decide which Quay flavor to explore, the best way to get started will vary. The instructions are quite different among the Quay flavors, but here are the links:
If you are using containers or Kubernetes, you might want to explore Quay Operator.
To help you further, I created few tutorial videos to make your Quay journey easier:
- Red Hat Quay: Building a Docker/Container image for Quay in Red Hat OpenShift
- Red Hat Quay: Pushing a Docker/Container image to Quay in Red Hat OpenShift
- Red Hat Quay: Create a Config Map to store TLS certificate in Red Hat OpenShift
- Red Hat Quay: Create an OpenShift secret to store Quay secret
A cloud environment that requires the Continuous Integration (CI) process from CI/CD, might leave you wondering how to store and manage the built packages. Container images can be a challenge to organize but I hope you can see now that Quay provides several functionality levels and options for you and your environment.
[ Get this free ebook: Managing your Kubernetes clusters for dummies. ]