Container Registries in Docker

A container registry in docker is a single/ only place where we can find docker images, manage docker images, perform vulnerability analysis and decide on the access control. Furthermore, using CI/CD, we can have fully automated Docker pipelines for faster feedback. In this article, we will discuss Container registries in Docker with the following topics:

• Docker image storage and distribution
  • What is a container registry?
  • Why use the container/Docker registry?
  • How to deploy a Docker Registry server?
• Docker Hub container registry
  • Other Public container registries from AWS, Azure, and Google
• Docker Repository vs. Docker Registry
• Public vs. Private container registries

 

 

Docker Image storage and distribution

When using Docker, we create an app or service and then continue to pack it, including all its dependencies and/or configuration, into a container image. Additionally, we can view an image as a static representation of the app/service, configuration, and dependencies. Finally, the image needs to instantiate to create a container that runs on the Docker host to run this app/ service.

There can be numerous images that are not easy to handle, and therefore we should be able to store these images somewhere, preferably in a registry. Moreover, this registry acts as a library of images and is needed when we deploy the images to production. Docker maintains an official library of images via Docker Hub, which is a public registry. Additionally, there can be numerous private registries as well at the organizational level and many different public registries.

The below diagram shows this arrangement:

 

As shown above, the image shows the Docker registry distribution. The docker container, which is a running instance of the image, accesses the image from the registry. This registry can be on-premise (private at the organizational level) or on a public cloud. Putting the Docker images in the registry lets us store static and immutable application versions that will include dependencies and configuration at the framework level. These images are versioned, and one can deploy them in multiple environments as deployment units.

We can view the registry as a bookshelf where the number of images is stored and can be pulled for building containers that can run services, web apps, etc.

Let us now move onto the details of the container registry.

 

 

What is a container registry?

A Docker registry, or a container registry as we know it popularly,  is a system for Docker images. The container registry deals with the storage and distribution of Docker images. For example, each image might have different versions, and each of them gets identified by a tag.

A Docker/container registry can further organize into Docker repositories. A Docker repository holds/ consists of all the versions of a particular image. The Docker registry allows us to pull images as needed and also push new images into it with proper permissions.

As we have seen in our previous tutorials on Docker many times, the Docker Engine, by default, interacts with the DockerHub, which is Docker’s public registry, as already mentioned. We can also run an on-premise Docker registry/distribution, which is open-source and commercially available and is called Docker Trusted Registry.

If we want to pull an image from DockerHub with the name myimage/Hello, we can execute the following command:

It will pull the latest version of the above image locally from DockerHub.

To pull the same image from an on-premise registry, we need to run a command specifying the location of the registry, port, name, and tag of the image, etc., as shown in the following command.

We have specified that we need to pull the image version of myimage/Hello with tag 1.1 from my-docregistry at port 9000.

So now we can see the difference between the way we pull an image from public and private registries.

We recommend using Private registries (on-premise or cloud) when the following cases are true:

1. The Docker image is confidential, and we should not share them publicly.
2. We want minimum network latency between the images and their chosen deployment environment. For example, suppose our production environment for a particular app is on-premise to minimize network latency. In that case, we might opt to have an on-premise Docker Trusted Registry within the same local network as an app.

In the above cases, it is advantageous to go for private Docker registries.

 

 

Why use the Container/Docker registry?

The question now arises: what is the Docker registry’s purpose, or why should we use the Docker registry?

We can justify ourselves with the following points.

• With Docker registries, we can tightly control where we can store our images.
• We fully own our image distribution pipeline with the Docker registry.
• We can integrate image storage and distribution tightly into an in-house development workflow with the aid of container registries.

 

 

How to deploy a Docker Registry server?

A “registry” is an instance of a “registry” image, and it runs inside the Docker. So before we can deploy a registry, we need to have Docker installed on the host. Let us follow the sequence of steps to deploy and configure a registry server.

 

Run a local registry

Using the following command, start the registry container.

The registry container is now ready to use.

 

 

Copy an image from Docker Hub to your registry

Next, we pull the image from Docker Hub. For example, let us pull an image “ubuntu” with version “16.04” from DockerHub using the following command.

Then we re-tag it as “my-ubuntu-image” and then push it to the local registry container. For this, we use the following command.

The following screenshot shows/ displays the execution of the above commands.

 

As the last step, we delete the “ubuntu:16:04” and “my-ubuntu-image” on localhost, and the local registry pulls the “my-ubuntu-image.” The command sequence is as follows:

The below screenshot shows the execution of the above commands.

Stop a local docker registry – docker container stop registry command

We can stop the local registry using the “docker container stop” command as follows:

 

Then remove the container using ‘docker container rm‘:

 

Basic configuration

Now we move on to the basic configuration of the container. For example, if we need the registry to be part of the permanent infrastructure, we could set it to restart automatically when Docker restarts or exits. In the following command, we use the “–restart always” flag for this. The command for this is as below.

 

 

As shown in the above screenshot, we can verify that the registry container has started by checking the status of the container.

 

 

Customize the published port in the Docker registry

We can also customize the port used for publishing. If port 5000 is already in use or if we want to run multiple local registries on different ports, we can customize the published port—for example, the following command.

Here we run the registry named “registry-test” on port 5001. Note the option  “-p,” which specifies the host port, and the second part (after :) is the port within the container. It means within the container, the registry listens on port  5000 by default.

We can also use the environment variable “REGISTRY_HTTP_ADDR” to change the port the registry listens on, as shown below:

 

&  docker  run  -d  -e  REGISTRY_HTTP_ADDR=0.0.0.0 : 5001 -p 5001 : 5001 – -name registry – test registry :

This way, we can deploy the registry container on a Docker host.

 

 

Docker Hub container registry

DockerHub is an official hosted registry solution by Docker Inc. Docker Hub provides public and private repositories and automated builds, integration with source control solutions like GitHub and Bitbucket, and also organization accounts.

Anyone running Docker can access the public repository using Docker API. For example, “docker pull ubuntu” will pull the ‘ubuntu‘ image with the “latest” tag. On the other hand, private repositories restrict access to the repository creator or only to members of the organization. DockerHub also supports official repositories. These include images like “Nginx” verified for security and also use best practices.

We can link the DockerHub repository to the source control repository that contains the build context and perform automated image builds. A commit triggered in the source repository will, in turn, trigger a build in DockerHub.

Another feature of DockerHub is that it automatically scans the images in private repositories for any vulnerabilities and produces a detailed report of them.

 

 

Other Public container registries from AWS, Azure, and Google

Apart from DockerHub, other companies also host online Docker registries for public use. These are usually paid. Cloud providers, including Amazon Web Service (AWS) and Google, also provide container – hosting services:

• Amazon Elastic Container Registry (ECR): ECR supports only private repositories. It does not provide automated image building. ECR integrates with AWS Identity and Access Management (IAM) for authentication purposes.
• Google Container Registry (GCR): The GCR  uses  Google Cloud Storage service permissions for authentication. Like ECR, GCR also supports only private repositories. But in addition, it provides automated image builds via integration with Google Cloud Source Repositories and source controls like GitHub and Bitbucket.
• Azure Container Registry (ACR): This registry from Microsoft supports multi-region registries and authenticates using Active Directory. It does not provide automated image building and only supports private repositories.
• CoreOS Quay: This registry offers free as well paid  (public as well as private) repositories. CoreOs Quay uses LDAP and OAuth authentication.  Additionally, this container registry also provides automatic security scanning automated image builds.
• Private Docker Registry: Private Docker container registry provides public and private repositories (up to 3 free repositories) and supports OAuth, LDAP, and Active Directory authentication. 

 

 

Docker Repository vs. Docker Registry

Following are some of the differences between the two:

Docker Registry	Docker Repository
It is a service that stores different Docker images.	It’s a collection of various Docker images with the same name but different tags.
A third party or any other public or private registry like DockerHub, GCR, etc., can host it.	It is a part of the Docker registry.
Examples of Docker registries are DockerHub, Private Docker registry, GCR, etc.	Examples of a Docker repository are Ubuntu, Nginx, etc., wherein each repository is a collection of various images like different versions of Ubuntu.

 

 

Public vs. Private Container registries

Public Container Registry	Private Container Registry
Its public in nature, and anyone can access it.	Mostly private in nature and requires permissions for access.
The public registry offers services that are basic and simple to use.  It works well for individuals and smaller teams.	A private container registry has scanning capabilities and role-based access control, thus offering more security, governance, and efficient management.
It runs into issues, especially as the teams/ applications scale up.	A private Docker registry gives better/ more efficient performances for big clusters and high-frequency roll-outs, along with additional features like access authentication.
Mostly free to use.	One can host it with paid access usually.
Available for public use, for example, DockerHub.	It is used mainly by the on-premise hosts for specific organizations.

 

 

Key TakeAways

1. Container registries are a collection of Docker images and can be public or private.
2. Additionally, by default, DockerHub is the container registry provided by Docker Inc. that we can access by anyone having a Docker installed on the machine. 
3. Moreover, we can deploy our registry container locally, the steps for which we have already discussed above.
4. In addition to the above, a repository is a collection of images having the same name and different tags. Moreover, one can push a repository onto the registry.

Conclusively, with this article, we have completed our series on Docker. Happy learning!!