So you\u2019re using Docker now. You even built an image. Now what do you do? Chances are you are going to want to use that image somewhere. So then how do you share that image with a teammate or get that image onto a machine somewhere else where it can actually run? This is where registries come into play.<\/p>\n
A Docker registry is a place to store and distribute Docker images. It serves as a target for your An image is essentially a template for Docker containers. It consists of a manifest and an associated series of layers.<\/p>\n A layer represents a filesystem difference. An image\u2019s layers are combined together into a single image that forms the base for a container\u2019s filesystem.<\/p>\n A registry is a content delivery and storage system for named Docker images. It can be thought of as a collection of repositories keyed by name.<\/p>\n A repository is simply a collection of different versions for a single Docker image. In this way, you can think of it as being similar to a git repository. For example, the official Ubuntu repository<\/a> has a description of what is in the image as well as a list of the available versions<\/a>.<\/p>\n A tag is just a named version of the image. It allows you to identify a specific image later on. You can tag an image (almost) however you want. However, it\u2019s probably best to give it a meaningful, human-readable name that can be easily referenced later.<\/p>\n All right, now that we have that down, let\u2019s get into the more interesting stuff.<\/p>\n Imagine a workflow where you push a commit that triggers a build on your CI provider which in turn pushes a new image into your registry. Your registry can then fire off a webhook and trigger a deployment. All without a human having to step and manually do anything. Registries make a fully automated workflow like this much easier.<\/p>\n As the previous example demonstrates, you will likely want to have a private registry for storing your proprietary images. A public registry such as the one on Docker Hub<\/a> is hugely helpful for publicly available and open-source images. However, for your company\u2019s private images, a private registry is what you need.<\/p>\n The question then is: hosted or self-hosted?<\/p>\n The decision to host your own private registry or to go with a hosted option is much like any other question of building it yourself versus outsourcing to a third party. Price, control, flexibility and maintenance all come into play. Instead of rehashing these arguments though, let\u2019s instead just run through what your options are.<\/p>\n Quay<\/a> is a hosted Docker registry from CoreOS<\/a> that sells itself as having \u201cpowerful build triggers,\u201d \u201cadvanced team permissions,\u201d and \u201csecure storage.\u201d They are probably one of the more enterprise-friendly options out there, offering fine-grained permission controls.<\/p>\n They support any git server and let you build advanced workflows by doing things like mapping git branches to Docker tags so that when you commit code it automatically builds a corresponding image.<\/p>\n Quay offers unlimited free public repositories. Otherwise, you pay by the number of private repositories. There\u2019s no extra charge for storage or bandwidth.<\/p>\n Docker Hub<\/a> is the Docker\u2019s own registry offering. Like Quay, they offer unlimited free public repositories and don\u2019t charge for storage or bandwidth. If you need private repositories, they charge based on the number you need and how many parallel builds you can have.<\/p>\n Docker Hub doesn\u2019t offer the fine-grained permissions that Quay does, which may be an issue for more enterprise-level shops. Docker Hub also has more limited git integration, requiring that your code live on GitHub or Bitbucket if you want to take advantage of the automated builds.<\/p>\n It\u2019s worth noting that Docker Hub is the default registry used when you !New Call-to-action<\/p>\n Amazon\u2019s ECR<\/a> is a relatively new option that makes a lot of sense if you are making heavy use of other AWS offerings such as their Elastic Container Service<\/a>. It can be used like any other Docker registry, but you\u2019ll likely get the most benefit out of it within the AWS ecosystem. As with most other AWS products, ECR offers very fine-grained permissions and access control.<\/p>\n One important thing to note is that ECR\u2019s pricing model is very different from Quay and Docker Hub. Instead of charging based on the number of private repositories, they charge strictly based on storage and bandwidth.<\/p>\n Google\u2019s Container Registry<\/a> is much like Amazon\u2019s ECR in that it can be used as a generic Docker registry. You\u2019ll likely get the most benefit if you are already using Google Cloud Platform.<\/p>\n Pricing is similar to ECR where you only pay for storage and network egress. Ultimately, your images are stored in Google Cloud Storage<\/a>. Security is taken very seriously, but the workflow support is lacking a little bit currently. If you are looking to set up sophisticated, automated workflows with your Docker registry, you may want to look elsewhere.<\/p>\n The hosted options above are an easy way to get started. Docker Hub in particular is great for pulling down prebuilt images without needing to configure anything yourself.<\/p>\n However, if you need more control over how and where your images are stored or more flexibility into how your images are distributed, you might want to look into hosting your own registry. The easiest way to do this is by making use of [Docker Distribution].<\/p>\n Distribution is Docker\u2019s open-source registry implementation. It supports V2 of the Docker Registry HTTP API and supersedes the older Docker Registry<\/a>. Distribution will likely serve as the basis for any custom registry you would want to deploy.<\/p>\n Deploying Distribution is extremely simple. The hardest part tends to be picking a storage backend. By default, the registry data is stored in a Docker volume on the host filesystem, but you will usually want to use a different option for scalability, redundancy, and availability reasons.<\/p>\n Distribution provides storage drivers for S3, Google Cloud Storage, and Azure Blob Storage, among others. There is also a well-documented storage driver API if you would like to implement your own.<\/p>\n Distribution has support for almost everything you\u2019ll want, out of the box. There is native support for TLS and basic authentication as well as robust webhook notifications<\/a>. You can set up endpoints to be notified any time a manifest or layer is pushed or pulled. This is crucial for setting up automated workflows.<\/p>\n We\u2019ve covered where Docker registries fit in the picture and why you you likely need them in your Docker workflow. There are plenty of hosted registry providers out there like Quay and Docker Hub if you prefer to offload the maintenance work to someone else in exchange for a little less flexibility.<\/p>\n On the other hand, if you have requirements that make a registry-as-a-service a less attractive option, Docker Distribution makes rolling your own a much simpler proposition. If you\u2019d like to see a more detailed rundown on actually rolling your own private registry with Docker Distribution, check out Jeff Nickoloff\u2019s<\/a> great post<\/a>.<\/p>\n For an even more through look at rolling your own registry with Distribution, check out the Codeship ebook \u201cRunning a Private Docker Registry on Amazon EC2\u201d<\/a>.<\/p>\ndocker push<\/code> and docker pull<\/code> commands. Before we get any further, let\u2019s cover some of the basic terminology related to Docker registries.<\/p>\nImage<\/h4>\n
Layer<\/h4>\n
Registry<\/h4>\n
Repository<\/h4>\n
Tag<\/h4>\n
Why Do I Need a Docker Registry?<\/h2>\n
Hosted Options<\/h2>\n
Quay.io<\/h4>\n
Docker Hub<\/h4>\n
docker push<\/code> or docker pull<\/code>. Regardless of whether you choose to use Docker Hub for you\u2019re private images, you will almost certainly be interacting with it, as most base images will be stored there.<\/p>\nAWS EC2 Container Registry (ECR)<\/h4>\n
Google Container Registry<\/h4>\n
Self-Hosted Options<\/h2>\n
Where To Go From Here<\/h2>\n