Red Hat Quay.io

In terms of a specific example of how I use Red Hat Quay, we have an environment where we are managing Terraform code stored in GitLab. We run a pipeline and create a renovate pipeline which checks the latest version of the Terraform modules and updates accordingly as per the new version available.

The best features Red Hat Quay offers for my work are that it is easily integrated with RHEL. This means we do not require any additional subscription for Red Hat Quay. If our environment is RHEL-based and we have already purchased the subscription for RHEL, it is better to use Red Hat Quay.

Red Hat Quay has positively impacted my organization by improving reliability because it comes with the RHEL subscription, so we do not require any other, and it is easily integrated with all the RHEL-related tools like OpenShift.

I am not facing any kind of issue with Red Hat Quay at this time.

I have been familiar with Red Hat Quay for a while.

If you are considering Red Hat Quay, my advice is that if you have a RHEL environment and you have already purchased the RHEL subscription, then you must use Red Hat Quay because it is easily integrated with all the services that belong to the RHEL family. Red Hat also has good support. I would rate this product an 8 out of 10.

I am an end-user of Red Hat Quay, having just used it for one more year, and I haven't found any issues. I use this to store my images to share with my colleagues, and I store multiple applications in this one.

My usual use cases for Red Hat Quay involve using it for container storage and deploying the application with OpenShift. I develop using the deployment tool and Docker tool, and I'm familiar with Docker. Compared to Docker, Red Hat Quay is superior because we can create an organization for free, and it offers cloud-on-premises solutions. We can also create multiple organizations in the same profile, which means the same account. This is the basic case compared to the others.

The features of Red Hat Quay that I have found most valuable include the ability to switch between the previous version and the newer version; this is an extra feature currently added, and I appreciate this feature.

Red Hat Quay's automated image building has helped my CI/CD pipeline efficiency by allowing me to store my source code from GitHub and GitLab to my images. It's very convenient, and it automatically stores my images to deploy in the OpenShift application, making it easier to deploy and run the application without any troubleshooting.

The positive impacts I have seen from using Red Hat Quay include the ability to change to a newer version and roll back to the older version. This is the only feature I find beneficial, and I can monitor how many people download my images, which I can verify with the analytics provided.

The value of geo-replication in maintaining consistent access to container images is significant since I store data in MongoDB and use the Apache Web Server application running in Quay.io, where I store my images.

I think Red Hat Quay could improve the security, as users can download the images without a login. This is the only problem, so we need to enhance the security.

I have been working with Red Hat Quay since 2024.

Red Hat Quay is stable and reliable; it is used to build for high availability, but there are ways to improve stability and reliability, such as enabling image mirroring and caching. For example, if a cluster scales rapidly and pulls directly from Quay.io, it might hit network or rate limits. We need to find a solution, such as setting up a local mirror registry, which Red Hat provides as a mirror registry tool; Quay can mirror an external repository automatically. Now our cluster pulls from the local mirror, which is faster and more reliable.

I evaluate how scalable Red Hat Quay is by noting that it automates image updates, allowing us to scale continuously. GitOps tools such as Argo CD and Flux can watch Quay.io and redeploy with new tags if we want, triggering our CI/CD pipelines to roll out new replicas, making it easy to manage if one application fails.

I do not often communicate with the technical support and customer service of Red Hat Quay; there have been no issues I found before.

Before using Red Hat Quay, I used Docker.io, and compared to Docker.io, Red Hat Quay is superior.

I have not used the image vulnerability scanning feature of Red Hat Quay yet; I'm going to learn about this.

Regarding geo-replication in maintaining consistent access to container images, I have found no issues. If I store the image, I can easily pull the image without encountering any problems in Quay.io.

I have no experience with how role-based access control has helped manage permissions in my organization.

I usually measure the effectiveness of Red Hat Quay's extensibility with my existing systems, though I have not used that functionality.

Red Hat Quay is not currently deployed on cloud or on-premises in my organization as it is only an institution with no use for cloud on-premises.

I use Red Hat Quay only with the free version.

I have used documentation for Red Hat Quay, as I have created extensive documentation myself because I am the trainer. I prepare many documents for the students on how to use it, how to manage the registry, and how to manage the images stored in Quay.io.

My impression of the documentation that Red Hat provides for Quay is that it is improved; there is no need for further enhancement. The book contents are very structured, and the course name is Specialization in Containers, DO188. It is structured documentation to use the Quay.io account from the beginning to the end of the process.

On a scale of 1-10, I rate Red Hat Quay an 8.

The main use case is to use Red Hat Quay for image management as an enterprise image registry in our organization. All the container images, whether from AKS, GKE, or OpenShift, are stored on Red Hat Quay and are used for application deployments. This is the only major use case we have.

The best features in Red Hat Quay include the user interface and the RBAC facility, which allows us to control image access for specific teams. We have geo-replication in place, where storage can be replicated across regions, providing redundancy to prevent single points of failure. It is configured to ensure constant availability.

Red Hat Quay's automated image building enhances CI/CD pipeline efficiency because all our applications are deployed through CI/CD pipeline, whether Jenkins or Octopus, and can pull images directly through Red Hat Quay using robot accounts and service accounts. This makes it effective from that perspective.

Role-based access control is a major feature we have been using because we have hundreds of applications deployed in our container platform, owned by various application owners. Role-based access helps us restrict access to unwanted users within the organization. We maintain separate organizations with different types of access for users, including admin access, view access, and read access for every image. The geo-replication happens at the backend, while the front-end RBAC is managed through a single dashboard. The continuous dynamic sync runs in the background, though monitoring capabilities are limited to the storage team's purview.

Red Hat Quay can improve its statistics capabilities. Currently, we don't have means to check the overall utilization, such as the number of repositories, frequency of usage for each repository, and which users are accessing specific repositories. Such statistics could be incorporated into the dashboard. While usage logs exist, they are not particularly helpful. To present utilization data to higher management, we need more meaningful and useful information to gauge Red Hat Quay's utilization and plan capacity needs accordingly.

We are not currently using the vulnerability scanning feature with Red Hat Quay because we have external scanning tools.

I have had experience with this product for three to four years.

The initial setup of Red Hat Quay is straightforward, especially since the design suggestions came from Red Hat. We set it up on top of OpenShift using an operator, which was manageable as long as we properly configured the storage and DVPs.

I would rate Red Hat's support for Red Hat Quay as good, around eight out of ten.

In this organization, they are using the Red Hat Quay image registry. I have implemented and managed the solution in another company as well. Apart from Red Hat Quay, I have experience with the internal image registry available as a native registry solution within OpenShift.

The initial setup of Red Hat Quay is straightforward, especially since the design suggestions came from Red Hat. We set it up on top of OpenShift using an operator, which was manageable as long as we properly configured the storage and DVPs.

I still have experience with Red Hat solutions, specifically with OpenShift and Red Hat Quay. I don't have experience with Red Hat AMQ, Satellite, or API Management, as those are handled by a platform team. My scope is only in the container platform and associated tools. Our experience with Red Hat Quay is measured by repositories rather than users. I don't get involved with licensing for Red Hat Quay as that's handled by a separate accounts team. We have an agreement with Red Hat where we receive everything in a bundle, so individual licensing costs aren't a concern. Based on my experience, I rate Red Hat Quay an 8 out of 10.

We use Red Hat Quay as a single source of truth for all of our container images. We store all the container images that are used in the OpenShift platform.

We have a mechanism to create organizations on the Quay registry where we can segregate repositories based on business needs and verticals. This helps put more controls in place so that not all cloud users have access to all repositories. We can control it better. User management in Quay, when we manage the repositories using organizations, is more efficient.

It's pretty user-friendly. It's operator-based, and there's no complication in setting it up. Things like downloading an image, pulling an image, tagging, and pushing it back to the needed organization are fairly easy compared to doing things through the command-line interface.

Red Hat is constantly improving its product. Every new version rollout comes with updates that enhance performance. One example is that we used to experience issues when clicking on a repository if we had thousands of them in the registry. In the latest versions, those things have been taken care of.

From the AI perspective, it just serves as a container registry at this point.

We are also looking for the possibility to retain a VM image from Quay, which is not possible currently.

So, nothing is happening regarding AI. I don’t see the role of AI currently.

I have been using it for two to three years now.

I have been working with Red Hat products for quite a long time now. Overall, I have been working with their products for more than seven to eight years. So I’m pretty comfortable with their support. They are able to cater to our needs and respond to our product defects. So far, so good.

Support-wise, every product is assigned a dedicated technical account manager. They have been able to take care of our needs from a support perspective.

I’ve used the internally managed registry that comes with OpenShift. The internal registry is specific to the cluster, where outsiders cannot access the registry. Of course, if we take care of the network barriers, they can access it, but there will be some security concerns for outsiders to access the registry when it is internal.

Quay being an external registry, all other platforms, like JKS and GKE, can still use Quay registry to store their images.

We do have JFrog and OpenShift in our environment.

I would rate my experience with the initial setup an eight out of ten, with one being difficult and ten being easy.

It’s just a matter of two to three hours, provided you have your OpenShift platform up and running.

Only one person can handle it as long as the prerequisites are in place. You need to ensure that the storage mount points are set up correctly.

Only one person can handle it as long as the prerequisites are in place. It's all a matter of those prerequisites, so we have the application in place. You need to ensure that the storage mount points are in place and that the application is enabled in the backend by the storage team. We've got PostgreSQL being used as a database. So once we have those prerequisites in place, setting it up is fairly easy, and one person can do the job from the front end.

Maintenance is obviously part of operations support. The entire operations team will be supporting it. We have ten-plus members in the team.

We have data operations, like creating organizations and managing the Red Hat Quay registry. We also download the needed reports and upload the reports to the needed organizations based on business needs.

Additionally, we grant and manage rights for the organizations to allow service accounts to pull the image through the CI/CD pipeline.

It is fairly easy to use. It doesn’t take much time to introduce Quay registry to the business units. Anybody who wants to use it as a primary registry just needs to create the organization and move all the images into the respective organization. So, on that front, it is pretty easy to use and faster to deliver to the clients.

I would definitely recommend it.

Overall, I would rate this product an eight out of ten.