What is a container registry?
A container registry is a place to store container images for use in application development—especially cloud native development on microservices and containerized applications.
Container images—standalone packages of software that can be used to quickly build and run containerized applications and their dependencies—form the basis of the cloud native ecosystem. Used with container engines like Docker, container images transform the way that software is developed and delivered. But without a way to organize and share container images, they wouldn’t be nearly so useful.
That’s where container registries come in. Container registries provide repositories for organizations’ container images. You can think of a registry as a digital warehouse—or, if we compare images to recipes, the registry is a bit like a recipe book. It’s a centralized location for all of our container images, making them easy to archive, update, reference, and use.
What is the difference between a container registry and a repository?
When people talk about container registries, they sometimes use the words “registry” and “repository” interchangeably. That can lead to some confusion on the terms, but the difference is really pretty simple.
A repository (or “repo” for short) is a general term for any specific digital location where software packages are stored. Often, the repository is subject to version control and there is metadata associated with it, so users can keep track of the package and any changes that are made to it. When we refer to the places where packages and version control records are stored on GitHub, for example, we call them “GitHub repos.”
A container registry, on the other hand, is a specific location for storing container images. In a sense, you can think of it as a type of repository—but crucially, it may include one or more discrete repositories for those images, in the same way that a library may include multiple separate collections.
What are the benefits of a container registry?
In cloud native application development, container images can act as modular components. If a developer wants to spin up a fresh instance of a Postgres database, she doesn’t have to provision new resources or spend a great deal of time configuring the database—she can simply download a Docker image of the database and its dependencies.
But the container registry provides more than building blocks. It can also…
Provide a place to save images for sharing and collaboration
Act as a single source of truth for an application or component, providing the most recent version ready for replication and use
Define container images approved for use in the organization
These are some of the most common uses of container image registries, but private registries can carry that functionality still further.
Public container registry vs. private container registry
Public registries are freely available online. Anyone can download container images from them, and–after signing up for an account—anyone can save images to them as well. Docker Hub is the most widely used public registry, and it is typically the registry a developer encounters first, since it is the default registry for Docker tools.
A public registry such as Docker Hub can be a good fit for individual developers who are learning the ropes, or for small open source projects. But because anyone can contribute to the Docker Hub registry and other public registries, images may be contaminated: a security firm reported that more than half of all images on Docker Hub included exploitable vulnerabilities.
For enterprises and other organizations running mission critical software, it’s essential to understand exactly what is in their container registries. This is why they use private registries. A private registry is a container registry that limits access to a defined set of users. It may be hosted on-prem or by a service provider, but either way it will typically include some form of role-based access control (RBAC) enabling the organization to specify who can contribute to the registry and how.
What to look for in a container registry
A private registry performs several crucial functions. It empowers an organization to include only approved images in the registry. It helps the organization control access, and may also provide the ability to scan the registry contents for known vulnerabilities. Additionally, enterprises seeking a private container registry should look for the following features:
Binary-level image scanning from a regularly updated vulnerability database. Critical vulnerabilities are often hidden well below the surface in container images—in the binaries and libraries used by dependencies for your core processes, for example. It’s important that your registry enables “deep-tissue” scanning down to the binary level—and that your scan is backed up by regular database updates from an expert team.
Secure software supply chain through tight integration with CI/CD tools and processes. The more closely your registry works with your Continuous Integration and Continuous Delivery solutions, the more you can automate processes like image promotion for simpler, faster, and more secure software lifecycles.
Deployment flexibility. How flexibly can you use your container registry on-prem, on private clouds, on public clouds, or in multi-cloud environments? Will it be able to adapt as your architecture evolves?
Our own Mirantis Secure Registry provides these features with installation to any Kubernetes distribution via Helm, a vulnerability database updated daily, close CI/CD integration, and more. To explore Mirantis Secure Registry with a trial license, click here.
