The invention of OS-level virtualization to deliver software in packages called containers was one of the first steps toward modernizing the development process of cloud-based applications.
In the pre-container world, Developers had to configure applications specific to physical or virtual machines, creating install packages in unique versions for the operating system and machine variants, often with co-dependencies and interactions with other software installed in the machines. The downside of this approach was that it could be time-consuming for the developers to analyze and patch running systems one at a time when a problem arose.
Containers changed this by enabling developers to create compact, portable units (container images) packaged with all necessary dependencies, operate anywhere, and be deployed using automation.
Here is where the registry comes into play: during the entire development process, the registry remains a source of truth for the images you want to run. The primary purpose of registries is to store and distribute container images. Devs/Ops users push container images into these registries and pull them when they need to spin containers from these stored images. Each of these images can have multiple versions identified by their tags.
Public registry services such as Docker Hub are basic and simple and can work well for individuals and smaller teams which is why they are so popular among developers. The free public repositories come with their own limitations; once teams begin to scale up, they run into numerous issues. In such cases, private registries are a better option.
In environments where privacy is a significant concern, private registries are a better fit, as anyone can push and pull images in public registries. Several open-source and commercial private container image registries are available for our consideration, with various features catered to enterprise environments. Cloud providers such as AWS, MSAzure, and Google Cloud provide their private registries as paid services.
How Do I Choose the Right Container Registry?
Using a private, internal registry affords the most significant potential for security and configuration. Still, it requires careful managing and ensuring the registry’s infrastructure and access controls stay within your organization.
The market is full of options when choosing a container registry. But, before you set out to pick one, the core questions you need to consider beforehand are:
- Do I want to host additional artifacts in addition to container images? Some container registries support other types of files, such as Java, Node.js, or even Python packages. On the other hand, some only support container images.
- Do I need extra security? A feature that only a few container registries offer is a vulnerability scan whenever you push an image to the registry.
- Do I need Role-based access control management(RBAC) for local images?
- Should I go with an on-prem or hosted container registry?
- Do I need the ability to record use in auditable logs so that activity can be traced to a single user?
If you decide to migrate from one container to another, the task is relatively easy in case you change your mind.
Comparison between Top Container Registries Available
| Amazon ECR | Azure CR | Docker Hub | Google AR | |
|---|---|---|---|---|
| Pricing | Storage: free (for 1 year with AWS Free Usage Tier) until 0.5GB/mo for private and 50GB/mo for the public, then $0.10 per GB/mo for data stored in both private or public repositories. more |
Storage: $0.167 per day for 10GB under the Basic tier, $0.667 per day for 100GB under the Standard tier, $1.667 per day for 500GB under Premium tier. more |
Their pricing isn’t based on storage. Free, unlimited public repositories. Pro $5/mo unlimited private repositories. more |
Storage: free until 0.5GB, then $0.10 per GB/mo Data Transfer ingress: potentially free; see network egress pricing info. more |
| Support language packages (npm, Maven, yum, etc.) | ❌ (AWS CodeArtifact will help with that) | ❌ (But support OCI artifacts) | ❌ | ✅ |
| Authentication | AWS IAM | Azure RBAC | Password or Access Token | GCP IAM |
| Cross-region replication | ✅ | ✅ (Only available with Premium tier) | ❌ | ✅ |
| MFA for Image Push/Pull | ✅ | ❌ | ✅ (Beta) | ❌ |
| SLA Availability | 99.9% | 99.9% | NA | 99.9% |
| Garbage collection | ✅ | ✅ | ❌ | ❌ |
| Image Scanning | ✅ (Integrated with Amazon Inspector to provide automated, continuous scanning of repositories.) more |
✅ (Microsoft Defender for container registries includes a vulnerability scanner to scan the images in Azure Resource Manager-based Azure Container Registry registries and provide deeper visibility into images vulnerabilities) more |
✅ (After enabling vulnerability scanning, Docker Hub automatically scans the image to identify vulnerabilities in your container images.) more |
✅ (Container Analysis scanning API provides vulnerability information for the container images in Container Registry and Artifact Registry.) more |
| Rate Limits – Pull – Push |
– 120000/min – 120000/min more |
– up to 10000/min depending on the tier used. – up to 2000/min depending on the tier used. more |
– Users with a paid Docker subscription get up to 5000 pulls per day – Unknown more |
– 60000/min 18000/min more |
Understanding your platform and application needs can help you to compare available container registries and choose the one that best suits them. It is also simpler to choose amongst them if you consider your cloud environment.
What’s next?
That’s it for the first part of this blog post series. I hope you understand Container Registry well, and it will help you choose the right one. Follow up on the topics I covered in there in this blogs post:
Use Private Registry for Containerize a CAP Application – Part 2 (Amazon ECR)
Keep your anticipation high for the upcoming episode, which you will see in great detail.
Stay curious!
References
How to choose a Container Registry
Amazon Elastic Container Registry
Azure Container Registry
Google Artifact Registry
