When you first start your containerization journey, it looks something like this:
- Learn Docker and containerization
- Learn how to containerize an application
- Build a container image for the application
The next step is then where do I save the containerized application?
In this blog post, you’ll learn about container registries, the importance of them, and how to get started using them.
When you build a containerized application, you need a place to store it that isn’t your local computer. For example, when you run
docker build from a Dockerfile, that image then gets created and saved on your computer.
After that, there’s a single point of failure - the containerized image is only available to you.
If other engineers need to use it, your teammates, etc., they can’t. Because of that, you need a place to save a container image.
A container registry is that exact place. You can save a container image in a container registry instead of locally, or you can save the container image locally and push it up to a container registry. You can then give other engineers and teammates access to the container registry and to the container image inside of the container registry.
When thinking about the benefits of a container registry, it comes down to a few things:
- Storing images
- Automating the build of containers
- Giving access to the container images
- Scanning images
As discussed in the What Are Container Registries section, storing container images in a centralized location gives you the ability to share the container image with teammates. It also gives you a place to store the container image that isn’t on your local computer. If your local computer were to crash and you didn’t have a backup, the container image would no longer exist. Having that single point of failure isn’t practical for production environments.
The next step after building a container image is deploying the container that’s made up of the container image. In a production environment, you’d want to do that in an automatic and repeatable way. Using something like CICD to build your container image from, say, a Dockerfile makes a lot more sense than doing it manually. Then, you can use that same CICD pipeline to push the container image to a container registry, automating the entire process.
Once a container image exists in a container registry, teammates and other engineers will then need access to it. You can, for example, ensure that teammates have full admin access or read-only access for a specific registry where a container image lives.
An added benefit to some container registries, but not all, are tools like image scanning. You can use container image scanning tools to ensure that the container image is secure and is following best practices.
Below is a list of container registries to consider.
First, there’s Docker Hub. Docker Hub is a go-to for many organizations and engineers because it’s free, SaaS, and easy. However, do keep in mind that recently, Docker Hub set data rate limits for pulling images. You’re only given X amount of container image pulls depending on the type of plan you have. You can learn more about that here.
Next, there’s Artifactory by JFrog. There’s a free version and a paid version of Artifactory depending on what you want to use. Other benefits of Artifactory include XRay, which is a way to secure container images by scanning them using CVSS scoring and the National Vulnerability Database (NVD).
In Azure, AWS, GCP, and other clouds, there are also container registries. If you’re embedded into a specific public cloud, it wouldn’t hurt to use those container registries. Azure has Container Registry, AWS has Elastic Container Registry (ECR), and GCP has Container Registry.