The DTR is a solution that provides a secure location where you can store and manage your Docker images either on premises or in the cloud. It also provides some monitoring to let you get insight into usage so you can tell what kind of load is being passed to it. DTR, unlike Docker Registry, is not free and does come with a pricing model. As we saw earlier with Docker Subscription, the pricing plan for DTR is the same. Don't fret as we will go over Docker Registry in the next section of the book so you can understand it as well and have all the options available to you for image storage.
The reason we separate it out into its own section is that there are a lot of moving pieces involved and it's critical to understand how they all function not only as a whole to the Docker Subscription piece, but as it stands by itself, the DTR piece where all your images are being maintained and stored.
There are two ways you can install DTR, or rather there are two locations where you can install DTR. The first is that you can deploy it in house on a server you manage. The other is deploying it to a cloud provider environment like that of Digital Ocean, Amazon Web Services (AWS), or Microsoft Azure.
The first part you will need is a license for the DTR. Currently, they do offer a trial license that you can use, which I highly recommend you do. This will allow you to evaluate the software on your selected environment without having to fully commit to that environment. If there is something that you find doesn't work in a particular environment or you feel another location may suit you better, you can then switch without having to be tied to a particular location or having to move your existing environment around to a different provider or location. If you do choose to use AWS, they do have a pre-baked Amazon Machine Image (AMI) that you can utilize to get your Trusted Registry set up much quicker. This avoids having to do it all manually by hand.
Before you can install the Trusted Registry, you first need to have Docker Engine installed. If you don't already have it installed, please see the documentation located with the link below for more information on doing so.
https://docs.docker.com/docker-trusted-registry/install/install-csengine/
You will notice there is a difference in installing the normal Docker Engine from the Docker CS Engine. The Docker CS Engine stands for commercially supported Docker Engine. Be sure to check the documentation as the list of recommended or supported Linux versions are shorter than the regular list for Docker Engine.
If you are installing using the AMI, then please follow the instructions here:
https://docs.docker.com/docker-trusted-registry/install/dtr-ami-byol-launch/
If you are installing on Microsoft Azure, then please follow the instructions here:
https://docs.docker.com/docker-trusted-registry/install/dtr-vhd-azure/
Once you do have Docker Engine installed, it's time to install the DTR piece. If you are reading to this point we will be assuming that you aren't installing to AWS or Microsoft Azure. If you are using either of those two methods, please see the links from above. The installation is very straightforward:
$ sudo bash -c '$(sudo docker run docker/trusted-registry install)'
Once this has been run, you can navigate in your browser to the IP address of your Docker host. You will then be setting the domain name for your Trusted Registry as well applying the license. The web portal will guide you through the rest of the setup process.
In accessing the portal you can set up authentication through your existing LDAP or Active Directory environments as well, but this can be done at anytime.
Once that is done, it is time for Securing Docker Trusted Registry, which we will cover in the next section.
Now that we have our Trusted Registry set up, we need to make it secure. Before making it secure you will need to create an administrator account to be able to perform actions. Once you have your Trusted Registry up and running, and are logged into it, you will be able to see six areas under Settings. These are:
- General settings
- Security settings
- Storage settings
- License
- Auth settings
- Updates
The General settings are mainly focused around settings such as HTTP port or HTTPS port, the Domain name to be used for your Trusted Registry, and proxy settings, if applicable.
The next section, Security settings, is probably one of the most important ones. Within this Dashboard pane you are able to utilize your SSL Certificate and SSL Private Key. These are what make the communication between your Docker clients and the Trusted Registry secure. Now, there are a few options for those certificates. You can use the self signed ones that are created when installing the Trusted Registry. You can also do self signed ones of your own, using a command line tool such as OpenSSL. If you are in an enterprise organization, they more than likely have a location where you can request certificates such as the one that can be used with the registry. You will need to make sure that the certificates on your Trusted Registry are the same ones being used on your clients to ensure secure communications when doing docker pull or docker push commands:
The next section deals with image storage settings. Within this Dashboard pane, you can set where your images are stored on the backend storage. Options for this might include an NFS share you are using, local disk storage of the Trusted Registry server, an S3 bucket from AWS, or another cloud storage solution. Once you have selected your Storage Backend option, you can then set the path from within that Storage to store your images:
The License section is very straightforward as this is where you update your license when it's time to renew a new one or when you upgrade a license that might include more options:
Authentication settings allow you to tie the login to the Trusted Registry into your existing authentication environment. Your options here are: None or a Managed option. None is not recommended except for testing purposes. The Managed option is where you would set up usernames and passwords and manage them from there. The other option would be to use an LDAP service, one that you might already be running as well, so that users have the same login credentials for their other work appliances such as email or web logins.
The last section, Updates, deals with how you manage updates for the DTR. These settings would be totally up to you how you handle updates, but be sure if you are doing an automated form of updates that you are also utilizing backups for restoring purposes in the event that something goes wrong during the update process.
Now that we have covered the items that help you secure your Trusted Registry, we might as well take a few minutes to cover the other items that are within the console to help you administer it. Beyond the Settings tab within the registry, there are four other tabs that you can navigate and gather information about your registry. Those are:
- Dashboard
- Repositories
- Organizations
- Logs
The Dashboard is the main landing page you are taken to when you log in via your browser to the console. This will display information about your registry in one central location. The information you will be seeing is more hardware related information about the registry server itself as well as the Docker host that the registry server is running on. The Repositories section will allow you to control which repositories, either Public or Private, your users are able to pull images from. The Organizations section allows you to control access, that is, who on the system can push, pull, or do other Docker related commands against the repositories that you have elected to configure. The last section, the Logs section, will allow you to view logs based upon your containers that are being used from your registry. The logs are rotated every two weeks with a maximum size of 64 mb. You are able to filter through the logs as well based on a container as well as being able to search for a date and/or time.
In this section, let's pull an image, manipulate it, and then place it on our DTR for access by others within our organization.
First, we need to pull an image from the Docker Hub. Now, you could start from scratch with a Dockerfile and then do a Docker build and then push, but let's, for this demonstration, say we have the mysql image and we want to customize it in some way.
$ docker pull mysql Using default tag: latest latest: Pulling from library/mysql 1565e86129b8: Pull complete a604b236bcde: Pull complete 2a1fefc8d587: Pull complete f9519f46a2bf: Pull complete b03fa53728a0: Pull complete ac2f3cdeb1c6: Pull complete b61ef27b0115: Pull complete 9ff29f750be3: Pull complete ece4ebeae179: Pull complete 95255626f143: Pull complete 0c7947afc43f: Pull complete b3a598670425: Pull complete e287fa347325: Pull complete 40f595e5339f: Pull complete 0ab12a4dd3c8: Pull complete 89fa423a616b: Pull complete Digest: sha256:72e383e001789562e943bee14728e3a93f2c3823182d14e3e01b3fd877976265 Status: Downloaded newer image for mysql:latest $ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE mysql latest 89fa423a616b 20 hours ago 359.9 MB
Now, let's assume we made a customization to the image. Let's say that we set up the container to ship its logs off to a log stash server that we are using to collect our logs from all our containers that we are running. We now need to save those changes.
$ docker commit be4ea9a7734e <dns.name>/mysql
When we go to do the commit, we need a few tidbits of information. The first is the container ID, which we can get from running a docker ps command. We also need the DNS name of our registry server that we set up earlier, and lastly a unique image name to give it. In our case, we will keep it as mysql.
We are now ready to push the updated image to our registry server. The only information we need is the image name that we want to push, which will be the <dns.name>/mysql.
$ docker push <dns.name>/mysql
The image is now ready to be used by the other users in our organization. Since the image is in our Trusted Registry, we can control access to that image from our clients. This could mean that our clients would need our certificate and keys to be able to push and pull this image, as well as permissions set up within the organization settings we previously went over in the last section.
$ docker pull <dns.name>/mysql
We can then make run the image, make changes if needed, and push the newly created image back to the Trusted Registry server as necessary.