‫This section is going to be all about container image registries.
‫There's a lot to go through,
‫so, we're actually going to start with basically saying that you need an image registry in your plan.
‫It's not really an optional part of the container ecosystem. The way that Docker and other tools are
‫designed is that they need a place, off your servers and off of your developer workstations, to actually
‫store your images.
‫Technically, they can be zip files and you can export and import them but that's really an arduous
‫situation.
‫So you really want to plan for a registry, whether it's on the internet or a private one.
‫We're going to actually go through some things and different lectures here where we talk about the
‫details of Docker Hub and some of the auto-build options there.
‫We're going to focus on the Docker Store for a lecture and how that's actually different than Hub.
‫And then the Docker Cloud option, which is actually also different than Hub, but also an add-on to the
‫Docker tool set,
‫and maybe could help you make it easier to deploy servers and your stuff into the cloud.
‫We also have the new Swarms feature now in Docker Cloud that I’ll have a specific lecture on.
‫And then, you're going to learn how to build your own registry and deploy it on either your local machine
‫or on a Docker Swarm to use as a private registry.
‫It's actually open-source. And then we'll mention some of the third-party registry options in case you
‫don't want to use Docker Hub or the open-source Docker registry.
‫In this lecture we're going to cover some of the advanced topics of Docker Hub.
‫Now, it is the most popular image registry in the world for containers, but it's not the only one.
‫Let's just see what it does
‫in addition to what we've already discussed so far. In summary, Hub is a registry, but it also has image building
‫in it.
‫That's not normally a part of,
‫for example, the open-source registry and so it does have a little bit of extra stuff in it that allows
‫you to build images on the fly.
‫We're going to jump into some of those features here.
‫And then, also talk about linking your GitHub and BitBucket accounts to Hub and checking out some of
‫the auto-build features for building your images based on the commits.
‫And then, we're going to show some features around chaining image building together, so that you can make
‫it easier to make sure your images are always up to date.
‫We've already covered a little bit about Docker Hub
‫when we first learned about images earlier in this course. But, I wanted to go through some of the other
‫features that maybe we haven't discussed, and then compare that to the Docker Store, and then talk about
‫what Docker Cloud might do for us before we actually get into other registry options for ourselves.
‫Obviously, Docker Hub is a registry.
‫It's what we've been talking about this whole course.
‫It's how we pull all of our images, and it is the default registry for Docker. But, it's not the only one
‫by far.
‫Let's talk about what it can do besides what we've already done.
‫We can see that I have repositories here, obviously. You can tell that I actually have at least one private
‫one here. The private ones,
‫you get one free, and the rest you have to pay for.
‫You set up a billing account like normal and you pay for that. When you create repositories, and on
‫each one of your images, whether they're public or private, you can choose to give permissions to people.
‫This is what my view would look like for a repository that I own.
‫This happens to be a public one.
‫If I went into Settings, you can see that I can switch back and forth between making it private and
‫public.
‫I can delete it. I can create webhooks, and the webhooks are really handy for when your images are built
‫and pushed into Docker Hub.
‫You can have it send a webhook to some other service, like Jenkins or Codeship, or Travis CI, or something
‫like that, to have automated builds continue down the lines.
‫Those webhooks are there to help you automate the process of getting your code all the way from
‫something like Git or GitHub to Docker and all the way to your servers where you want to run them. The
‫Collaborators is the permissions area where you can set permissions for other people to do things with
‫your image.
‫And then we also have Organizations. So, you have your own permissions for your own repositories and then
‫you can give others permissions to your repositories. But, if you want to create organizations you can
‫do that as well.
‫They're totally free.
‫For example, underneath this organization, I can see all of their repos. And then, because I have the
‫permissions for each one, I can actually go in and change all their settings.
‫You can see that I can control team membership.
‫I can control billing like you would normally do for private images.
‫This is very much like GitHub, if you've used GitHub at all, or if you've ever paid for anything on GitHub.
‫It's very similar where everything that's open-source is free and then anything you want to be private
‫you have to pay for in-group plans. And the Organizations work the same way as GitHub.
‫There's not a whole lot else to it.
‫I just want to show you a few key things that you need to know if you want to start using it.
‫One is, if you're using a GitHub or BitBucket to store your code, don't click this button to create your
‫repository.
‫Also, don't do a Docker push before creating it first, because what you really want to do is go up here
‫to create and create automated build. The automated build allows Docker Hub to create this CI path
‫that will automatically build your image based on code commits.
‫This is like the reverse webhook.
‫The webhooks we just looked at a while ago are for Docker Hub to notify something else that it's finished
‫with an image.
‫But this process allows Docker Hub to be notified when something else happens.
‫I always set it up for auto-building my own repositories.
‫In this case, for instance, I just chose a repository I have access to and GitHub.
‫And then, I give it a short description and it allows me to create a repository.
‫But, in this case, it knows it's coming from GitHub.
‫Anytime there's a commit based on certain requirements, or certain branches, it will actually build
‫my image on the fly.
‫Then I get a nice little e-mail saying it's successful or not.
‫That's why you see on a lot of images that they're automated builds.
‫That's just one indication of quality because it shows that this image is likely always up to date
‫with wherever the source code is. You'll see here, like the Jekyll server that we used previously
‫in this course, that I have some of these automated options here that I didn't have in the previous repository
‫that wasn't set up for automation.
‫So here I have build details, build settings. You can see that each time it's built it's successful
‫in the history. And then, in the build settings, I can choose which branches I want to build. Something
‫I highly recommend is that, down here under repository links,
‫if you are building images on Docker Hub, and you're using a from statement that you're pulling from
‫some other image, then you want to set up repository links here, so that any time that software changes
‫your image gets rebuilt.
‫And that's a big deal because, over time your, image is going to have dependencies on it, and it's going
‫to need to update when those get updated themselves,
‫maybe based on security requirements or new bug fixes. And so, on mine, because it's running Ruby and Jekyll
‫inside my image, and it's from statement in the Docker file is actually the Jekyll,
‫I put those here so that any time those images get rebuilt, mine will then get rebuilt.
‫If you also want to create a build trigger...a build trigger is another inbound way for you to automatically
‫have an image be built, and maybe you have some other software that's not GitHub that you want to kick
‫off builds whenever something happens.
‫So you can create those unique post URLs there.