Comparing Four Hosted Docker Registries

One of the most useful aspects of the Docker workflow for deploying containers is Docker Hub. The ability to launch any of the thousands of publicly available containers on Docker Hub without having to build complex pipelines makes it much easier to manage containers and deployments. While this is great for open source software, for proprietary applications, it definitely makes sense to host your images privately in a production-grade registry.

To host your private images you may use either a hosted registry as a service or run your own registry. A hosted registry can be great if your team doesn’t have enough bandwidth to maintain a registry and keep up with the changing API specification. In this article, I’ll evaluate some of the leading hosted docker registry providers.

Overview

Before we dive into the various offerings, I would like to give a quick overview of the Docker registry nomenclature and show you how to work with private images.

Docker Concepts

Index: An index tracks namespaces and docker repositories. For example, Docker Hub is a centralized index for public repositories.

Registry: A docker registry is responsible for storing images and repository graphs. A registry typically hosts multiple docker repositories.

Repository: A docker repository is a logical collection of tags for an individual docker image, and is quite similar to a git repository. Like the git counterpart, a docker repository is identified by a URI and can either be public or private. The URI looks like:

{registry_address}/{namespace}/{repository_name}:{tag}

For example,

quay.io/techtraits/image_service

There are, however, a couple of exceptions to the above rule. First, the registry address can be omitted for repositories hosted with Docker Hub, e.g., techtraits/image_service. This works because the docker client defaults to Docker Hub if the registry address is not specified. Second, Docker Hub has a concept of official verified repositories and for such repositories, the URI is just the repository name. For example, the URI for the official Ubuntu repository is simply \“ubuntu\“.

Working with docker registries

To use a docker registry with the command line tool, you must first login. Open up a terminal and type:

docker login index.docker.io

Enter your username, password and email address for your Docker Hub account to login. Upon successful login, Docker client will add the credentials to your docker config (~/.dockercfg) and each subsequent request for a private image hosted by that registry will be authenticated using these credentials.

Similar to the command line tool, Rancher provides an easy way to connect with your registries for managing your docker deployments. To use a registry with Rancher, navigate to settings and select registries. Next, put in your registry credentials and click create to add a new registry. You can follow the same process for adding multiple registries.

Once your registry is added, the rest of the flow for launching containers from your private images remains the same and is covered in detail here. For instance, in the example below, I’ve created a new service with a private image hosted in Quay.io:

Hosted docker registries

Now that we have covered the basics of working with docker registries, I’m going to evaluate some of the leading hosted registry-as-a-service providers. For each service, I’ll highlight the key features and summarize my findings. I’ll be using the following criteria to evaluate and compare registries:

1. Workflow (build/deployment, collaboration, ease of use and visibility)
2. Authentication and authorization
3. Availability and performance
4. Pricing

Docker Hub

Docker Hub is an obvious choice for hosted private repositories. To get started with Docker Hub, sign up here and create a new private repository. It is very well-documented and straightforward to work with, and so I’ll skip the details. Every user is entitled to one free private repository and you can select between multiple tiers based on the number of private repositories you need. I really like that the pricing is usage independent, i.e., you are not charged for the network bandwidth used for pulling (and pushing) images.

Collaboration and access control: If you are familiar with Github, you will feel right at home with Docker Hub. The collaboration model adopted by Docker Hub is very similar to Github where individual collaborators can be added for each repository. You can also create organizations in Docker Hub. There is also support for creating groups within organizations; however, there is no way of assigning permissions to groups. What this means is that all users added to an organization share the same level of access to a repository. The coarse-grained access control may be suitable for smaller teams, but not for larger teams looking for finer control for individual repositories. Docker Hub also doesn’t support any of LDAP, Active Directory and SAML, which means that you can’t rely on your organization’s internal user directory and groups for restricting access to your repositories.

Docker Hub and your software delivery pipeline: Docker Hub aims to be more than just a repository for hosting your docker images. It seamlessly integrates with Github and Bitbucket to automatically build new images from Dockerfile. When setting up an automated build, individual git branches and tags can be associated with docker tags, which is quite useful for building multiple versions of a docker image.

For your automated builds in Docker Hub, you can link repositories to create build pipelines where an update to one repository triggers a build for the linked repository. In addition to linked repositories, Docker Hub lets you configure webhooks which are triggered upon successful updates to a repository. For instance, webhooks can be used to build an automated test pipeline for your docker images.

Although useful, automated build support by Docker Hub does have a few rough edges. First, the visibility into your registry is limited; for instance, there are no audit logs. Second, there is no way of converting an image repository into an automated build repository. This somewhat artificial dichotomy between repository types means that built images can’t be pushed to an automated build repository. Another limitation of Docker Hub is that it only supports Github and BitBucket. You are out of luck if your git repositories are hosted elsewhere, e.g., Atlassian’s Stash.

Overall, Docker Hub works well for managing private images and automated image builds; however, on a number of occasions I noticed performance degradation when transferring images. Unfortunately without SLAs, I would be a bit concerned about using Docker Hub as the backbone for large-scale production deployments.

Summary:

Workflow:

+ seamless integration with Github and BitBucket

+ familiar Github-esq collaboration model

+ repository links and webhooks for build automation

+ well-documented and easy to use

– build repositories lack support for custom git repos

– limited insight into registry usage

Authentication and authorization:

+ ability to create organizations

– lacks fine-grained access control

– lacks support for external authentication providers , e.g. LDAP, SAML and OAuth

Availability and performance:

– uneven performance

Pricing:

+ inexpensive and usage-independent pricing

Quay.io

Next, we’ll look at Quay.io by CoreOS. It’s a free service for public repositories and there are multiple pricing tiers to choose from, based on the number of private docker repositories you are looking to host. Like Docker Hub, there is no additional charge for network bandwidth and storage.

Authentication and access control: In Quay we can create organizations and teams where each team can have its own permissions. There are three permission levels to chose from: read (view and pull only), write (view, read and write) and admin. Users added to a team inherit their team’s permissions by default. This allows for more control over access to individual repositories. As for authentication, in addition to email based login, Quay supports OAuth integrations but lacks support for SAML, LDAP and Active directory.

Automated builds done right: Workflow is one area where Quay excels. Not only does it have an intuitive and streamlined interface, it does a number of small things right to seamlessly integrate with your software delivery pipeline. A few highlights:

• Support for custom git repositories for build triggers using public keys
• Regular expression support for mapping branches and docker tags. This is quite useful for integrating with your git workflow (e.g. git flow) to automatically generate new versions of docker images for each new version of your application.
• Robot accounts for build servers
• Rich notification options including email, HipChat and webhooks for repository events

Visualizations and more visualizations: Quay has some great visualizations for your docker images, which effectively capture the evolution of an image. Visualizations don’t end there though, as Quay also offers detailed audit trail, build logs (shown below) and usage visualizations for visibility into all aspects of your docker registry.

While working with Quay, I didn’t notice any performance deteriorations, which is a good sign. But since I haven’t used it for large deployments, I don’t have any further insights into how it would behave under load.

Summary:

Workflow:

+ clean, intuitive and streamlined interface

+ automated builds done right

+ great visibility into your registry usage

+ webhooks and rich event notifications

Authentication and authorization:

+ ability to create organizations and teams

+ fine-grained access control through permissions

– limited OAuth-only authentication support

Pricing:

+ relatively inexpensive with usage-independent pricing

Artifactory

Artifactory is an open source repository manager for binary artifacts. Unlike some of the other registry services in our list, Artifactory focuses on artifact management, high availability and security; for instance, it leaves the builds to your build servers. Similar to Quay and Docker Hub, Artifactory comes in two flavours: an on-premise solution and Artifactory cloud. However, unlike Docker Hub and Quay, Artifactory is relatively expensive if you’re only looking to use it as a docker registry. It starts out at \$98/month for 8GB of storage and 400GB network bandwidth per month with per GB charges for additional usage.

Repository or a registry: For a new user, it can be a bit confusing to get started. First, you’ll notice that a docker registry is just a repository in Artifactory. Then we have to select between a local repository or a remote repository. The distinction between the two is that a local repository is hosted by Artifactory whereas a remote repository is an external repository for which Artifactory acts as a proxy. I think remote repositories can be quite useful for ensuring availability, where Artifactory provides a unified interface to all your artifacts while also acting as a cache layer for remote artifacts.

To create a docker registry, select “repositories” in the Admin view and create a new local repository. Make sure you select docker as the package type for the new repository:

The address for your docker registry will look like:

{account-name}-docker-{repo-name}.artifactoryonline.com

For example, I created a “docker-local” repository in my techtraits account and got the following registry address::

techtraits-docker-docker-local.artifactoryonline.com

Except for an awkwardly long address, your docker commands would work the same with Artifactory because it fully supports the docker registry API. For instance, I used the following commands to login, tag, push and pull images with the docker client:

docker login techtraits-docker-docker-local.artifactoryonline.com
docker tag ubuntu techtraits-docker-docker-local.artifactoryonline.com/ubuntu
docker {push|pull} techtraits-docker-docker-local.artifactoryonline.com/ubuntu

Rancher doesn’t have out of the box support for Artifactory but it can be added using the “custom” registry option. Just set your email address, credentials and the repository address and you are all done. You should now be able to use Rancher to run containers from your private images hosted in an Artifactory registry.

Advanced security: Artifactory supports a suite of authentication options including LDAP, SAML and Atlassian’s Crowd. For fine-grained access control, there is support for user and group level permissions. You can also specify which group(s) a new user is added to by default. The permissions can further be controlled on a per-repository level for granular access control. For instance, in the screenshot below I have three groups, each with different access to my private repository:

Summary:

Workflow:

+ all-in-one artifact management model

– learning curve for new users

– limited insight into registry usage

Authentication and authorization:

+ comprehensive authentication capabilities

+ fine-grained access control

Availability and performance:

+ remote repositories for high availability

Pricing:

– steep pricing

####

Google Container Registry

Google is one of the key innovators in the containerization space and so, not surprisingly, it also offers a hosted registry service. If you’re not already using Google cloud services, you can get started by creating a new Google API project (with billing enabled) in Google’s developer console.

Unlike some of the other services, there are some caveats when working with the registry service. Therefore, I’m going to trace the steps for working with it.

First, you’d need to install Google cloud client SDK. Make sure you are able to run docker without sudo if you are installing gcloud as a non-root user. Next, we need to authenticate with Google using the client sdk:

gcloud auth login

To push and pull images, we can invoke the docker command through gcloud:

gcloud preview docker push|pull gcr.io/<PROJECT_ID>/ubuntu

Note that your registry address is fixed for each project and looks like:

gcr.io/<PROJECT_ID>

Google command line tool will add multiple entries for various regions in your docker config when gcloud’s docker commands are invoked for the first time. A config entry looks like:

"https://gcr.io": {
    "email": "not@val.id",
    "auth": "<AUTH-TOKEN>"
}

Note that Google doesn’t store a valid email address in the config because it relies on temporary tokens for authorization. This approach enhances security; however, it does so at the expense of compatibility with the docker client and registry APIs. As it turns out, this additional dependency on Google client SDK and incompatibility with docker is one of the main reasons why Rancher doesn’t support it.

Behind the scenes, your images are simply stored in a Google Cloud Storage (GCS) bucket and you are only charged for GCS storage and network egress. This makes Google registry a relatively inexpensive service. High availability and fast access are other out-of-the-box benefits that you get from a GCS-based image store.

Workflow: While I like the idea of using GCS for storing images, the overall support for a docker based workflow is quite minimal. For instance, the registry service doesn’t support webhooks or notifications for when repositories get updated. It also doesn’t provide any insight into your registry usage. This is one area where I think Google’s docker registry service needs quite a bit of work.

Security and access control: Google takes a number of steps to ensure secure access to your docker images. First, it uses short-lived tokens when talking to the registry service. Second, all images are encrypted before they are written to GCS. Third, access to individual images and repositories can be restricted through GCS support for object and bucket level ACLs. Lastly, you can sync up your organization’s user directories with the Google project using Google Apps Directory Service.

Summary:

Workflow:

– incompatibility with docker client

– minimal support for integration with build and deployment pipelines

– limited visibility into registry usage

Authentication and authorization:

+ fine-grained access control with GCS ACLs

+ enhanced security through short-lived temporary auth tokens

+ support for LDAP sync

Performance and availability:

+ uses the highly available Google cloud storage layer

Pricing:

+ low cost

####

Conclusion:

In this article I compared a few hosted docker registry options. There are obviously pros and cons to all of these tools, and they are changing at a very fast pace right now. I think Quay is currently an excellent option for many organizations. It is inexpensive, offers unparalleled insight into docker registry usage, and can seamlessly integrate with your build and deployment pipelines.

Both Google Container Registry and Artifactory are targeted towards large enterprises with focus on high availability. They also integrate with LDAP to sync with organization’s user directory and groups. I think Google container registry can be a viable option if you are already invested in their cloud platform. In a similar vein to Google, Artifactory can be a great option for teams already using it for centralized artifact management. However, it can get expensive if you only plan to use it as a hosted docker registry.

Enterprise DockerHub is already a very good platform, and should be getting better with the recent announcement of a new version, which should be coming out any day now. Once that is available, I’ll dig in and look at it further.

To learn more about running any of these with Rancher, please join our betaor schedule a demo with one of our services.

Bilal Sheikh is a server and platform engineer with experience in building cloud-based distributed services and data platforms. You can find him on twitter @mbsheikh, or read about his work at techtraits.com

You might also be interested in:

• Container registries you may have missed Some more registry options, beyond the usual suspects