What to look for when choosing a container registry

Public or private, you should ensure it complies with OSI standards

The last several years have seen container use rise markedly, with 68 per cent of enterprises increasing their use of Kubernetes - the leading container orchestration platform - in the year up to March 2021. With companies increasingly betting their applications and software deployment pipelines on containers, the infrastructure that underlies these containers has become an important part of the enterprise stack.

One element of this infrastructure is the container registry. This acts as a place to store container images and share them out across a system with an automated pipeline. Given the primacy of the container registry in providing a single source of truth and so ensuring that a container deployment runs smoothly, it's no surprise that container registries are now an area of rising importance for DevOps teams.

Historically the choice of container registries was rather limited, but today the range of registries available can often feel overwhelming.

When choosing your container registry, there are two major things to consider: is it a public or a private registry, and does it provide an exit strategy?

Public vs private

One of the most important distinctions made between container registries is whether they're public or private. All container registries serve to provide a repository of container images and artefacts that are used in the development process, but public and private registries differ in their scope.

Public container registries provide basic capabilities in the form of APIs and simple functionalities. This straightforward approach is extremely useful in some contexts, since public registries allow for quick access to the images in the repositories. This simplicity and agility means public registries are ideal for teams that want to provide quick and easy access to developers who are working on newer projects.

However, once teams start scaling and moving into a production environment, private registries can start to make more sense. Alongside the APIs and basic functionality of public registries, private registries also include the ability to support different systems in different geographic locations, and offer improved security through role-based access control. Private container registries also include vulnerability scanning capabilities for images, alongside the means to verify themselves.

Setting up and configuring private registries is more complex and time-consuming, including linking them to authentication systems. However, through allowing teams to better control access to workflows and by providing more granularity over who can do what, private registries bring greater security and resilience against accidents, misconfigurations and malware.

Securing an exit strategy

It's important to ensure that teams have an exit strategy for their container registries, given that their needs may change in the future. Fortunately, it's easy for teams to migrate from one container registry to another - so long as both registries follow the same standards for storing and handling container images.

Thankfully, the Open Container Initiative (OCI) provides standards for container runtimes, image formats, security, governance and policy agents.

OCI standards play a very important role in providing a common language to both commercial and open source container registries, creating a shared foundation for users and vendors alike. So long as you're currently using an OCI-compliant container registry, you should have a viable migration route available. Compliance with other container infrastructure standards like those available from the Cloud Native Computing Foundation (CNCF) also can help in facilitating easy swapping-out of infrastructure.

In conclusion, when you start working with containers at scale, you'll likely find that a private registry is best to ensure your production environment is secure and resilient. And to ensure you retain flexibility in your choice infrastructure stack and to allow for trouble-free migration, it's worth checking your registry follows OCI standards. From there, it's solely about choosing the registry that meets your current needs - confident in the knowledge that you should be able to change registries easily when required.

Erica Langhi is senior solution architect EMEA at Red Hat