In this article by Scott Gallagher, author of the book Mastering Docker – Second Edition, we will cover the places you store your containers, such as Docker Hub and Docker Hub Enterprises. We will also cover Docker Registry that you can use to run your own local storage for the Docker containers. We will review the differences between them all and when and how to use each of them. It will also cover how to set up automated builds using web hooks as well as the pieces that are all required to set them up. Lastly, we will run through an example of how to set up your own Docker Registry. Let's take a quick look at the topics we will be covering in this article:

• Docker Hub
• Docker Hub Enterprise
• Docker Registry
• Automated builds

(For more resources related to this topic, see here.)

Docker Hub

In this section, we will focus on that Docker Hub, which is a free public option, but also has a private option that you can use to secure your images. We will focus on the web aspect of Docker Hub and the management you can do there.

The login page is like the one shown in the following screenshot:

Dashboard

After logging into the Docker Hub, you will be taken to the following landing page. This page is known as the Dashboard of Docker Hub.



From here, you can get to all the other sub pages of Docker Hub. In the upcoming sections, we will go through everything you see on the dashboard, starting with the dark blue bar you have on the top.

Exploring the repositories page

The following is the screenshot of the Explore link you see next to Dashboard at the top of the screen:



As you can see in the screenshot, this is a link to show you all the official repositories that Docker has to offer. Official repositories are those that come directly from Docker or from the company responsible for the product. They are regularly updated and patched as needed.

Organizations

Organizations are those that you have either created or have been added to. Organizations allow you to layer on control, for say, a project that multiple people are collaborating on.

The organization gets its own setting such as whether to store repositories as public or private by default, changing plans that will allow for different amounts of private repositories, and separate repositories all together from the ones you or others have.



You can also access or switch between accounts or organizations from the Dashboard just below the Docker log, where you will typically see your username when you log in.



This is a drop-down list, where you can switch between all the organizations you belong to.

The Create menu

The Create menu is the new item along the top bar of the Dashboard. From this drop-down menu, you can perform three actions:

• Create repository
• Create automated build
• Create organization

A pictorial representation is shown in the following screenshot:

The Settings Page

Probably, the first section everyone jumps to once they have created an account on the Docker Hub—the Settings page. I know, that's what I did at least.



The Account Settings page can be found under the drop-down menu that is accessed in the upper-right corner of the dashboard on selecting Settings.



The page allows you to set up your public profile; change your password; see what organization you belong to, the subscriptions for e-mail updates you belong to, what specific notifications you would like to receive, what authorized services have access to your information, linked accounts (such as your GitHub or Bitbucket accounts); as well as your enterprise licenses, billing, and global settings. The only global setting as of now is the choice between having your repositories default to public or private upon creation. The default is to create them as public repositories.

The Stars page

Below the dark blue bar at the top of the Dashboard page are two more areas that are yet to be covered. The first, the Stars page, allows you to see what repositories you yourself have starred.



This is very useful if you come across some repositories that you prefer to use and want to access them to see whether they have been updated recently or whether any other changes have occurred on these repositories.

The second is a new setting in the new version of Docker Hub called Contributed. In this section, there will be a list of repositories you have contributed to outside of the ones within your Repositories list.

Docker Hub Enterprise

Docker Hub Enterprise, as it is currently known, will eventually be called Docker Subscription. We will focus on Docker Subscription, as it's the new and shiny piece. We will view the differences between Docker Hub and Docker Subscription (as we will call it moving forward) and view the options to deploy Docker Subscription.

Let's first start off by comparing Docker Hub to Docker Subscription and see why each is unique and what purpose each serves:

Docker Hub

• Shareable image, but it can be private
• No hassle of self-hosting
• Free (except for a certain number of private images)

Docker Subscription

• Integrated into your authentication services (that is, AD/LDAP)
• Deployed on your own infrastructure (or cloud)
• Commercial support

Docker Subscription for server

Docker Subscription for server allows you to deploy both Docker Trusted Registry as well as Docker Engine on the infrastructure that you manage. Docker Trusted Registry is the location where you store the Docker images that you have created.

You can set these up to be internal only or share them out publicly as well. Docker Subscription gives you all the benefits of running your own dedicated Docker hosted registry with the added benefits of getting support in case you need it.

Docker Subscription for cloud

As we saw in the previous section, we can also deploy Docker Subscription to a cloud provider if we wish. This allows us to leverage our existing cloud environments without having to roll our own server infrastructure up to host our Docker images.

The setup is the same as we reviewed in the previous section; but this time, we will be targeting our existing cloud environment instead.

Docker Registry

In this section, we will be looking at Docker Registry. Docker Registry is an open source application that you can run anywhere you please and store your Docker image in. We will look at the comparison between Docker Registry and Docker Hub and how to choose among the two. By the end of the section, you will learn how to run your own Docker Registry and see whether it's a true fit for you.

An overview of Docker Registry

Docker Registry, as stated earlier, is an open source application that you can utilize to store your Docker images on a platform of your choice. This allows you to keep them 100% private if you wish or share them as needed. The registry can be found at https://docs.docker.com/registry/.

This will run you through the setup and the steps to follow while pushing images to Docker Registry compared to Docker Hub. Docker Registry makes a lot of sense if you want to roll your own registry without having to pay for all the private features of Docker Hub. Next, let's take a look at some comparisons between Docker Hub and Docker Registry, so you can make an educated decision as to which platform to choose to store your images.

Docker Registry will allow you to do the following:

1. Host and manage your own registry from which you can serve all the repositories as private, public, or a mix between the two
2. Scale the registry as needed based on how many images you host or how many pull requests you are serving out
3. All are command-line-based for those that live on the command line Docker Hub will allow you to:
   • Get a GUI-based interface that you can use to manage your images
   • A location already set up on the cloud that is ready to handle public and/or private images
   • Peace of mind of not having to manage a server that is hosting all your images

Automated builds

In this section, we will look at automated builds. Automated builds are those that you can link to your GitHub or Bitbucket account(s) and, as you update the code in your code repository, you can have the image automatically built on Docker Hub. We will look at all the pieces required to do so and, by the end, you'll be automating all your builds.

Setting up your code

The first step to create automated builds is to set up your GitHub or Bitbucket code. These are the two options you have while selecting where to store your code. For our example, I will be using GitHub; but the setup will be the same for GitHub and Bitbucket.



First, we set up our GitHub code that contains just a simple README file that we will edit for our purpose. This file could be anything as far as a script or even multiple files that you want to manipulate for your automated builds. One key thing is that we can't just leave the README file alone. One key piece is that a Dockerfile is required to do the builds when you want it to for them to be automated. Next, we need to set up the link between our code and Docker Hub.

Setting up Docker Hub

On Docker Hub, we are going to use the Create drop-down menu and select Create Automated Build. After selecting it, we will be taken to a screen that will show you the accounts you have linked to either GitHub or Bitbucket. You then need to search and select the repository from either of the locations you want to create the automated build from. This will essentially create a web hook that when a commit is done on a selected code repository, then a new build will be created on Docker Hub.



After you select the repository you would like to use, you will be taken to a screen similar to the following one:



For the most part, the defaults will be used by most. You can select a different branch if you want to use one, say a testing branch if you use one before the code may go to the master branch. The one thing that will not be filled out, but is required, is the description field. You must enter something here or you will not be able to continue past this page.

Upon clicking Create, you will be taken to a screen similar to the next screenshot:



On this screen, you can see a lot of information on the automated build you have set up. Information such as tags, the Dockerfile in the code repository, build details, build settings, collaborators on the code, web hooks, and settings that include making the repository public or private and deleting the automated build repository as well.

Putting all the pieces together

So, let's take a run at doing a Docker automated build and see what happens when we have all the pieces in place and exactly what we have to do to kick off this automated build and be able to create our own magic:

1. Update the code or any file inside your GitHub or Bitbucket repository.
2. Upon committing the update, the automated build will be kicked off and logged in Docker Hub for that automated repository.

Creating your own registry

To create a registry of your own, use the following command:

$ docker-machine create --driver vmwarefusion registry
Creating SSH key...
Creating VM...
Starting registry...
Waiting for VM to come online...

To see how to connect Docker to this machine, run the following command:

$ docker-machine env registry export DOCKER_TLS_VERIFY="1" export
DOCKER_HOST="tcp://172.16.9.142:2376" export
DOCKER_CERT_PATH="/Users/scottpgallagher/.docker/machine/machines/
registry" export DOCKER_MACHINE_NAME="registry"
# Run this command to configure your shell:
# eval "$(docker-machine env registry)" $ eval "$(docker-machine env
registry)"
$ docker pull registry
$ docker run -p 5000:5000 -v <HOST_DIR>:/tmp/registry-dev registry:2

This will specify to use version 2 of the registry.

For AWS (as shown in example from https://hub.docker.com/_/registry/):

$ docker run 
-e SETTINGS_FLAVOR=s3 
-e AWS_BUCKET=acme-docker 
-e STORAGE_PATH=/registry 
-e AWS_KEY=AKIAHSHB43HS3J92MXZ 
-e AWS_SECRET=xdDowwlK7TJajV1Y7EoOZrmuPEJlHYcNP2k4j49T 
-e SEARCH_BACKEND=sqlalchemy  -p 5000:5000  registry:2

Again, this will use version 2 of the self-hosted registry.

Then, you need to modify your Docker startups to point to the newly set up registry. Add the following line to the Docker startup in the /etc/init.d/docker file:

-H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock --insecureregistry
<REGISTRY_HOSTNAME>:5000

Most of these settings might already be there and you might only need to add --insecure-registry <REGISTRY_HOSTNAME>:5000:

To access this file, you will need to use docker-machine:

$ docker-machine ssh <docker-host_name>

Now, you can pull a registry from the public Docker Hub as follows:

$ docker pull debian

Tag it, so when we do a push, it will go to the registry we set up:

$ docker tag debian <REGISTRY_URL>:5000/debian

Then, we can push it to our registry:

$ docker push <REGISTRY_URL>:5000/debian

We can also pull it for any future clients (or after any updates we have pushed for it):

$ docker pull <REGISTRY_URL>:5000/debian

Summary

In this article, we dove deep into Docker Hub and also reviewed the new shiny Docker Subscription as well as the self-hosted Docker Registry. We have gone through the extensive review of each of them. You learned of the differences between them all and how to utilize each one. In this article, we also looked deep into setting up automated builds. We took a look at how to set up your own Docker Hub Registry. We have encompassed a lot in this chapter and I hope you have learned a lot and will like to put it all into good use.

Resources for Article:

• Docker in Production [article]
• Docker Hosts [article]
• Hands On with Docker Swarm [article]