Container Registries — A Battle Royale

One of the main advantages of using containers with Kubernetes is continuous availability. Rather than taking the whole system down for an update or maintenance, each container – containing specific microservices – can be replaced on the fly. The way developers do that is by preparing a new container for the updated microservices, setting up that container for production, and switching the flow of the app in the configuration.

Continuous availability means you have multiple versions of the same container created at different times. In some cases, different versions are archived or kept running for safety reasons. After a while, you may end up with different versions from the development process. To get started, you must first select the best one to use based on your specific requirements.

Repository vs. Registry

Before we go ahead and review the best registries to choose from, it is important to understand the main differences between a container registry and a repository. At their cores, they serve different functions and are set up for different reasons.

A container repository is used to store a collection of related images — container manifests — of the same name, for easy setup and rapid deployment. Typically, you can access images on container repositories via secure HTTPs endpoints. In such a manner, you can pull, push or manage images through any system, hardware, or VM instance.

Container registries, on the other hand, store a collection of repositories as well as indexes, access control rules, and API paths. These are often confused with repositories by many and can be hosted by a third party, either publicly or privately to store.

Understanding the Options

With more developments using containers nowadays, it is not surprising to see more solutions for archiving and storing container images being made available. There are several interesting options to choose from – plus you can go down the self-hosted route if you need the extra flexibility. In this part, we are going to focus more on the top solutions to consider.

Quay

Quay is the container registry from Red Hat. It is designed to offer enterprise-level features, which is why this is the favorite registry for corporate use. Aside from the basic functions of container image management, Quay also offers detailed access control, logging, and additional security features.

Container images can be encrypted from the beginning but doing so would mean missing out on some of the more advanced features. For example, Quay supports automated security scanning of container images to find known vulnerabilities on the fly.

Docker Hub

Docker Hub is a popular option among developers. It's also the de facto option for open source containers. It offers its registry for free and comes built into Docker tools, but you have to pay a premium if you want to use Docker Hub as a repository privately. As part of the premium feature, you also benefit from  to identify any vulnerabilities in your images. Another couple of reasons why Docker Hub is popular among developers is its ease of use and integration options—use it if you want to make your repo open source.

This is the default registry used when you run the docker push   and docker pull   commands on your server. Too bad it has limited features in comparison to the others listed here and doesn’t offer the comprehensive access management features that comes with Quay, which is why enterprise users tend to shy away from using this option.

AWS EC2 Container Registry (ECR)

We really can’t talk about container registries without discussing the offer from Amazon. With more and more containers running in AWS environment, adding EC2 Container Registry to the product lineup was a good move by Amazon. (Though attempting to use ECR outside of AWS is a little awkward.)

Being integrated with the AWS ecosystem means you can pull and push container images from the ECR without worrying about server latency. Security is also easier to manage since you can use the IAM service control panel to govern access to your ECR instance. AWS does also offer the capability to specify policies at the repository level. However, ECR does not yet support vulnerability scanning.

Google Container Registry

Google, the company behind Kubernetes, isn’t going to be left behind in offering a capable registry that can also be used as a repository for your container image. The Google Container Registry, or GCR, is one of the most affordable options on the market; you only pay for the storage and bandwidth you use.

It also comes with all the features you would need to set up a repository for your projects. There is no issue with security, although some will find the controls to be less user-friendly than the other options. I personally like GCR for use with private applications — whether they are in GCP or not.

Azure Container Registry

The Azure Container Registry is the last option on our list. It supports all kinds of containers, including Mesosphere. Azure manages network latency by leveraging its vast cloud computing network and making sure that the closest clusters are used.

If you use Azure Kubernetes Service (AKS), this is definitely the registry to utilize. The interactions between the two Microsoft services are incredibly fluid.

Container registry comparison is a matter of understanding your platform and application requirements and finding the one that meets those needs best. Taking into account the cloud environment you use also makes choosing between them easier.

This post was originally published here.