Selecting a container registry for your Docker environment can sometimes feel like choosing what to eat at a Chinese restaurant that features a hundred items on its menu—The number of choices can be overwhelming, and you may not understand exactly what each option entails.
As a result, you end up ordering General Tso’s chicken because it’s the only thing you really recognize. Then you spend the rest of the evening questioning whether you made the right choice and ate an authentic Chinese meal.
If this sounds like the challenge you face when deciding which container registry to use, fret not. Although we can’t tell you what to order the next time you get Chinese—that’s a personal choice—we can explain which factors to consider when you evaluate which container registry or registries to use.
What Is a Container Registry?
Container registries serve a pretty simple and straightforward purpose: They host images for the containers that you create, and/or for containers that other people create and you want to use. They also allow you to upload new versions of your container images and keep track of version histories across multiple iterations.
In this sense, a container registry is similar to a GitHub (or GitLab, or whatever your favorite hosted Git service is called) repository, except that a container registry hosts container images instead of source code.
Indeed, some of the key terminology associated with container registries is also similar to that of Git. For example, the term for downloading a container image from a repository is pull, which is more or less equivalent to the pull command in Git. Likewise, push is the command in both the Docker CLI and Git for uploading container images or source code to a registry or a repository.
We actually think that it would be less confusing if we called container registries container repositories. To a developer or sysadmin, a repository is a more obvious descriptor for what a registry does. We’re unsure why the Docker folks started calling their container image repositories registries in the first place. But that’s what they did, and the usage stuck, so here we are.
(We should note that some container registries let you create so-called repositories within them, so repository is a term that exists in the world of containers, and it does not mean the same thing as registry. We still think this terminology is more confusing than it needs to be.)
Types of Container Registries
There are lots of container registries out there. They can be broken down into several distinct categories:
- Cloud-based registries: Registries that are hosted in the public cloud by a third-party provider, such as Docker Hub.
- On-premises registries: Registries that you can install on your own infrastructure. You can create an on-premises registry manually using Docker, via Docker Registry (which is distinct from Docker Hub) or using a third-party registry like Quay.
- Public registries: Registries that anyone can access. Docker Hub is an example. So is Quay.io, a hosted public registry that is built using Quay. (To be clear, you can install Quay itself on your infrastructure; Quay.io is a hosted implementation of Quay designed for public access.)
- Private registries: Registries that require permissions in order to upload or download container images. You can create private registries using a service like Docker Hub, even though many Docker Hub registries are publicly accessible.
As you can see, there is a lot of overlap between these categories. Some container registries fall into multiple categories.
Questions to Ask When Choosing a Container Registry
How can you decide which registry is right for you? You might start by asking yourself the following questions:
Am I building a containerized app for the public to use? Or is it an internal app that will be used only inside my organization?
In the former case, a hosted public registry will be a better fit. In the latter case, you’ll want a private registry (though that registry could be hosted in the public cloud or on your own infrastructure).
Can I store my images on someone else’s infrastructure?
If compliance or security needs prevent you from hosting images in someone else’s cloud, then you’re going to need an on-premises registry.
How scalable are my container registry needs?
Like most things in the public cloud, hosted registries are easy to scale up because you don’t have to worry about expanding the infrastructure yourself. If you anticipate quickly growing the size of your registry or the number of people using it, a cloud-based registry will help you to scale faster.
If my registry is public, how will people find it? Will I point them to it explicitly or will I expect them to discover it themselves?
Docker Hub is the first place most people go when they’re looking for publicly available container images, so that’s a good place to create a registry if you want people to find your images easily. But if your target users are likelier to find you through a different platform, such as your website, Docker Hub’s popularity with the general public will be less important to you.
How important is open source to me?
Some container registries are open source, like Docker Registry and Portus. Others, like Docker Hub, are not. If you are worried about lock-in, software abandonment and the other fears that can arise from relying on proprietary code, you might prefer an open source container registry.
