Container registries are an essential resource for working with containers at scale. By providing a centralized location for storing, distributing, and downloading container images, container registries help developers to publish their applications as containers while also making it easy for users to find those applications.

Keep reading for an explanation of how container registries work, why you should use them, which types of container registry solutions are available, and how to set up your own registry if desired.

What Is a Container Registry?

A container registry is a type of tool that can host and distribute container images.

A container image is a binary file that serves as the blueprint for executing applications as containers. Container images aren’t containers themselves; to create a container, you have to run a container based on a container image. But container images tell your container runtime which processes to execute when it starts a container.

Thus, the role of a container registry is not to run containers, but rather to provide an efficient, centralized solution for storing the data that is necessary for running containers. By allowing teams to host a virtually unlimited number of container images in a single place, container registries make it easy for developers to publish their applications as container images, and for users to access those images.

How Does a Container Registry Work?

Container registries work by allowing software developers to create repositories, which host different types of container images. Typically, a single registry contains multiple repositories; for instance, developers might set up a different repository for each specific application that they want to share through a registry.

Once they’ve set up repositories, developers push container images into them. They can do this using the Docker command line with a command such as:

docker image push someregistry.com:1234/somerepo/some-image:latest

Or, they can use integrations in their CI/CD software to push images into container registries automatically after the images have been built.

After an image is inside a container registry, users can connect to the registry to download and run images within it. For example, to download an image for Alpine Linux and start a container based on it, you could run:

docker run alpine

Some container registries – namely, Docker Hub – are integrated with most Docker and Kubernetes environments by default, which means you can download and run images from them simply by specifying the image name (and the repository path, in some cases). That’s why, in the preceding command, we didn’t have to specify a registry name; we just pointed to “alpine,” which is the name of the Alpine Linux image stored on Docker Hub. However, if you use a registry other than Docker Hub, you typically need to specify a network host name or server address for the registry, along with a port number and the repository path.

Many container registries also provide Web interfaces that developers can use to manage container images and configure access controls for them, and which application consumers can use to search for images. But to run images in production with the help of a registry, you’d rely on command-line tools (or Kubernetes configuration files) to point to the registry and images. The advantage of this approach is that you can download the container images you want and run containers based on them in a single step – without having to download the container images through the Web first and then upload them to your container runtime environment.

Types of Container Registries

Container registries can be broken down into several categories (some of which are overlapping).

Private vs. Public Registries

Some container registries are public, meaning that the images hosted on them are accessible to anyone on the Internet. Public registries are most often used to share applications that developers want to make available to the public at large.

In contrast, private registries, which are accessible only to select users, are useful for sharing applications that should not be public – such as an app that is used only by a business’s employees.

Fully Managed vs. Self-Hosted Registries

Some container registries, like Docker Hub and the registry services offered by major public clouds, are available as fully hosted and managed solutions. Users don’t need to set up any infrastructure or software to use these registries; they just create accounts and start hosting images.

On the other hand, it’s possible to set up a self-hosted registry (which we explain how to do later in this article). A self-hosted registry runs on your own server, giving you more control over how the registry is configured and where the container images are hosted.

Open Source vs. Proprietary Registries

You can find container registries that are fully open source and free of cost (such as Docker Registry, Docker’s official registry tool), as well as proprietary registries. Some of the proprietary registries are free to use, but their source code is not public. Many proprietary registries are available only as managed services, not as standalone registries that you can deploy on your own infrastructure (although there are exceptions, such as JFrog Artifactory, a proprietary registry that can be deployed on private infrastructure).

On the whole, open source registries provide more flexibility and customization options, and they’re free of cost, but they usually require more work to set up and manage compared to proprietary registries.

Container Registries, Compared

There are a variety of specific types of container registries available. Here’s a look at some of the most popular.

Docker Hub

Docker Hub is the official managed container registry service from Docker. It’s also almost certainly the most widely used public registry.

Docker Hub repositories are public by default, but Docker Hub offers a private repository feature that developers can use to restrict who can access their container images. However, Docker Hub is not compatible with local or on-premises deployments, so you have to entrust your images to third-party infrastructure to use Docker Hub.

As a well-known container registry that is integrated with Docker and Kubernetes by default, Docker Hub is a good choice if you want the simplest registry experience and if having fine-grained control over your registry is less important.

Public Cloud Registries

Each of the major public cloud providers offers a managed container registry service:

• Elastic Container Registry (ECR), the container registry on AWS.
• Azure Container Registry (ACR), Azure’s registry solution.
• Container Registry in Google Cloud Platform.

Each of these registries is a fully managed service that integrates well with its respective public cloud platform. That makes these registries a good choice if you already depend extensively on the public cloud that they are a part of. For instance, if you deploy containerized applications using Elastic Kubernetes Service (EKS), the AWS managed Kubernetes service, for example, you might find ECR attractive. To be clear, though, you don’t strictly need to use a public cloud’s container registry to deploy containers on that cloud. You could also use Docker Hub or any private registry.

Open Source and Custom Container Registries

Several open source container registries exist that you can deploy in any location of your choosing: a local laptop or PC that you use for development purposes, your own on-premises server, or a virtual machine running on a public cloud IaaS service like Amazon EC2. Popular examples include Docker Registry, which (again) is Docker’s official open source container registry, and Harbor, another well-supported open source registry.

Although setting up these registries requires more effort than using a fully managed container registry service, the tradeoff is greater control over how the registry and the underlying host machine are configured.

Setting up your own registry is not especially difficult if you are familiar with basic Docker and/or Kubernetes commands. For instance, to deploy Docker Registry locally, use the command:

docker run -d -p 1234:1235 --name registry-server registry:2

This starts Docker Registry as a container based on the official image of Docker Registry from Docker Hub.

Or, if you want to run Docker Registry inside Kubernetes, you could define a Pod and Service like the following:

apiVersion: v1

kind: Pod

metadata:

name: my-docker-registry-pod

labels:

app: registry

spec:

containers:

- name: registry

image: registry:2.8.1Code language: Perl (perl)

apiVersion: v1

kind: Service

metadata:

name: docker-registry

spec:

selector:

app: registry

ports:

- port: 1234

targetPort: 1234Code language: Perl (perl)

Container Registry Security

As with any type of service that makes potentially sensitive information available over the network, container registries present some security challenges. Best practices for securing container registries include:

• Use access controls: Although in many cases images that you upload to a container registry will be publicly accessible by default, most registries also offer access control tools that you can use to restrict who can download images. Take advantage of access controls to protect sensitive applications.
• Use minimalist images: Minimalist images not only save space in your registry. They also reduce the attack surface of your applications by restricting the contents of container images to the minimum necessary to run an application.
• Isolate the registry: Unless you need your registry to be publicly accessible, place it behind a firewall to help prevent malicious users from finding it.
• Sign your images: Most container registries provide features for managing signed container images. Image signing helps to verify the authenticity of images and ensure that images haven’t been tampered with before they run. Wherever possible, take advantage of signed images to protect against malware that could lurk inside container registries.
• Enable image scanning: Some managed registry services provide built-in container image scanners (like Docker Hub Vulnerability Scanning), or you can set up image scanning using standalone tools. Either way, image scanners help to protect registry contents by detecting vulnerabilities inside images.

Practices such as these mitigate the risk that container registries, which should provide an easy means of managing and sharing containerized applications, don’t become a backdoor that attackers can use to tamper with software or push malware to unsuspecting users.