What would Docker be without Docker Hub? If it were not for images, you would never have heard of Docker, and that's because simplifying image distribution is what made Docker exponentially useful. Initially the images on Docker Hub suffice, but at some point, as you begin to build your own images, you'll outgrow storing them on Docker Hub for a variety of reasons. In this course, Implementing a Self-hosted Docker Registry, we will dissect deploying your own registry in the following scenarios. First, you will learn to take total control of a registry, perhaps as a matter of compliance, and learn to distribute sensitive images privately. Next, you will see how to co-locate a registry for performance reasons, to save bandwidth, or to mirror Docker Hub images to a local registry cache. Then, you will explore the internal workings of a registry and gain flexibility in securing your registry. Finally, you will be able to standardize application packaging and distribution within your organization using Docker images, to reap the same benefits that Docker Hub brought to open-source public applications. By the end of this course, you'll be well prepared to deploy your own self-hosted registry.
Wes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies delight customers.
Course Overview Hi, my name is Wes Higbee. Welcome to my course Implementing a Self-hosted Docker Registry. From a high level, containers and images can seem mystical, thus all the components of Docker, for example, a registry, can seem overwhelming to understand. However, I've found that once I get under the hood and take a look at how things work behind the scenes, the complexity melts away. And one of the best ways to look under the hood is to run your own registry. And of course, self hosting affords a lot of benefits in having total control over a registry. We'll see these benefits by first deploying our own private self hosted registry and using it to push and pull images. We'll see up a registry mirror of Docker Hub. We'll look at Webhooks to trigger subsequent activities when new images are pushed to our registry, and then we'll get into some of the nuances of running your own registry. For example, cleaning up images and choosing a storage backend. We'll also talk about securing a self-hosted registry. And finally, we'll look at deploying a registry as a part of a production cluster of applications. Let's get started.
Cleaning up Images and Configuring Storage I'll admit it might be hard to visualize a reason for wanting to clean up images and perhaps even to change the storage of images, given that in all the demos in this course we've just been recreating everything when we need to wipe things out. But the reality is, you can't do that in your real production environments. You might not even be able to do that in some of your testing environments because you probably want to keep your image history. At the same time, you can't just have images building up forever. Otherwise, your disks are going to fill up and you're going to come in in the morning and you're going to find that your server has crashed because there's no disk space left. Yes, I've been in that situation, pulling my hair out, trying to figure out what exactly went wrong because nothing should have gone wrong. And then all the sudden, I realize that the images are a lot bigger than I thought and I've been piling these up from all of my testing, and then, of course, I have to recreate servers if that's easy to do, and in my particular case it was easy to do, but that's not always the case, so we don't want to have to do that. You don't want to have to go in and troubleshoot and manually free up disk space and go into maybe a safe mode to do that. So let's actually talk about how we can make sure that images don't just pile up and fill up our disk.
Securing the Registry At some point after seeing the features of a registry and being convinced that the registry is valuable for a couple of different use cases at a minimum, at some point we have to step back and talk about some of the aspects that we need to consider, for example, to secure our registry. That way, when it's time to put a registry into production, we don't just have awesome features, we can also lock things down and make sure just the right people have access. And what do I mean by this? Well, right now we've got this HTTP API that's provided by the registry that we can use from a web browser here if we make web requests to it, or that the Docker daemon itself can interact with via the Docker CLI. We've got this API opened up and potentially exposed to the entire world because we have not locked anything down yet. Now a couple of times I've talked about how you can isolate that registry so that traffic coming from other computers on your network can't get to it, but at some point you might want to expose your registry to somebody else, besides just your local computer, and then you might want to control what they can do with it. So that's one of the aspects of securing a registry that we can talk about. So why don't we start there. Because right now, as you can see, I can make a request to our registry on port 5000, I can grab the catalog here, and I can see our list of repositories and I've got this busybox repository in here. This is running on my local computer, and if I hop out to my Windows machine, and this is also a separate machine on my network, if I hop out to this computer, I can reach back to my Mac where I'm running the registry at and I can access the exact same API. We even saw how we could use this to pull images to another machine, this is really valuable, but obviously we need to lock this down. So let's first talk about some forms of authentication. And the most basic form of authentication is basic authentication. So let's take a look at that first.
Preparing a Production Cluster Registry Throughout this course we've covered many aspects of running your own registry. We've even considered the perspective of various different clients that might access our registry to pull images. Now I'd like to turn our attention to a particular subset of clients. I'd like us to focus on servers. It's not that their concerns are unique, but I think a common use case for a private registry is to be able to house your own internal images to distribute those in a production environment to run your internal applications. Those tend to be proprietary, so hey, a good use case for standing up a private registry. Of course, we've already covered some of the topics that matter when it comes to standing up a sensitive internal registry, especially one used in a production environment. We've touched on security, for example, we've touched on different storage back ends, we've even talked about notifications that can integrate multiple registries together that are controlled by separate teams. So bring all of that perspective with you to this module, and now let's turn our attention to a few more considerations when it comes to running a registry in your production environment where you probably have quite a few machines that are running probably quite a few containers that need to pull images from your own private registry.