‫Requirements for this lecture are that you understand what an image is and that you've done a little
‫bit of work with containers.
‫In this lecture, we're going to take a quick tour around Docker Hub and get to know a few of its basic
‫features. Then we'll kind of discuss the difference between an official image and maybe other just
‫as good images, and how to tell the difference between a good image and a bad image.
‫Then I'll show a little bit around downloading images and how you can see the different tags that
‫they'll use and the difference between an Alpine image and other image options.
‫...
‫You should have signed into hub.docker.com. When you sign in your default home page is your
‫dashboard, which will show you all of your repositories, public and private.
‫You're not going to have any yet, but you can see I have some here.
‫They're all public.
‫I have one private. For now let's go to the top and search nginx. What we'll get back is the
‫search results of Docker Hub and you'll see that there's a lot. I could scroll for pages and pages.
‫One of the challenges is there's 15,000 images of Nginx.
‫That's a lot.
‫So I pretty much just use one or two.
‫The official one right here,
‫you'll see at the top, has 10 million-plus pulls.
‫There's several characteristics to figuring out what's the right image.
‫Like me, you're going to start using the images for your workflow that are related to what you do
‫and you're going to get used to specific ones. You're going to like specific ones.
‫Typically, we always start with the official.
‫The official is going to be the only one with the word 'official' actually below it.
‫It will also be the only one where its name doesn't have a forward slash in it.
‫When you and I create images on Docker Hub, we have to create them with our account name in front
‫of them.
‫So when you look at all these other ones, these are account names slash image repository names.
‫It might be actually an organization slash nginx or something like that.
‫But the only ones that get to have just the name of the repo are considered official. Official images
‫are ones that Docker, Inc. actually has a team of people that help take care of them, ensure that they
‫have quality documentation, that they're well tested and that they're put together properly with Dockerfiles
‫that are obeying best practice rules. They usually work with the official team of that software who
‫actually makes it to ensure that it's doing all the things that it should be doing.
‫So I'm going to click on this one.
‫Let's look at a couple of things about Official Repositories.
‫Like I said before, you're often going to be using officials to start with and then eventually you may
‫find that you want to change it slightly or add a few things to it and you'll make your own images.
‫Official images are a great way to start.
‫One of the best things about official images is their documentation.
‫They're always really great at documenting how to make them work,
‫what options there might be, what environment variables, what's the default port and so on.
‫So back up at the top, you'll notice these versions. Versions are a common feature of official repositories.
‫You don't have to have versions in every image but official ones do.
‫Because most open-source software there's always at least a few official versions out in the wild that
‫are officially maintained and supported.
‫That's what we have here. We have the mainline 1.11 for Nginx and then
‫we have what's considered the stable branch of Nginx, which is 1.10. We can see the little name
‫here says stable jessie Dockerfile.
‫All right.
‫So let's break this down.
‫1.11.9, mainline, 1, 1.11 and latest.
‫Those are all tags.
‫When we start talking about images, images aren't necessarily named. Images are tagged. A version
‫of an image can actually have more than one tag.
‫We're going to dive into this a little bit later when we start making our own images and we can
‫play around with tagging.
‫But for now, if I wanted to actually download that specific image, and you remember earlier that we actually
‫already downloaded it,
‫so if I do a docker image ls, you'll see the three images that we've worked with so far on my machine.
‫You see the tag that says latest. Now latest is a special tag.
‫It doesn't necessarily guarantee it's always the latest commit in the repository.
‫What it usually means is you're getting the latest version of this product. In the official
‫repositories,
‫it's very well-defined and consistent so that if you didn't really care right now exactly what version
‫you wanted, you just wanted the most current, then you could just say docker pull nginx. It would
‫download the latest. You'll notice that it already knew I had it, it checked the SHA to make sure it
‫matched the one from Docker Hub and said "Hey I've already got this image,
‫it's up to date." What if I wanted to download docker image version 1.11.9?
‫It's going to go check and see what it needs to do to download that image
‫and it turns out it doesn't need to do anything because it's the exact same version.
‫That's what this line means up here.
‫I can refer to this 'main, latest' version right here by any of these tags.
‫The reason is if I just wanted to stay on the latest version of 1.0, whatever that might be for
‫Nginx, I could just specify a 1. If I wanted to be more specific when I downloaded images and I wanted
‫the most latest version of 1.11, then I could just type 1.11 like this and just
‫leave out the .9 and it would download that one.
‫But in my case, I actually specified the most specific of all the 1.11.9 which shows
‫the point release and that was just to ensure that I got the exact version I wanted.
‫So in your software, a best practice is when you're going to production and you're actually testing software
‫that you're going to be using for others,
‫you always want to specify the exact version.
‫It's rare that you really want your software to update automatically.
‫You usually want to control that process with some other DevOps tool.
‫But when you're developing or just testing something locally, it's super easy with official images to
‫just type in the name and just assume you're going to get the latest.
‫So you'll notice here there's other ones.
‫There's 1.11.9-alpine and these all have very similar names to the first one
‫but they all have the word alpine in them.
‫We're going to get into base images and distributions later, but just for now, Alpine is actually
‫a distribution of Linux that's very very small.
‫It's actually less than 5MB in size I believe. This version will actually mean that it comes from
‫a base image of Alpine, keeping it very small and light, whereas the default one or the latest image actually
‫comes from jessie, which is a Debian distribution. It's a little larger in size probably a little
‫bit over 100MB.
‫In fact, we can actually go over here and we can look.
‫So nginx 182MB right here.
‫If I want to download that exact version of the Alpine, I can say 1.11.9-apline
‫and then do docker image ls and you'll see that the alpine version is actually only 54MB
‫and the latest version is 182MB.
‫You'll also notice that the three versions that I've downloaded all have the same image ID because
‫the image ID is based upon the cryptographic SHA of each image in Docker Hub.
‫So this isn't actually three different copies of 128MB images.
‫It's actually a little deceiving.
‫It's really just three tags of the exact same image ID and it's only total ticking up 182MB
‫and these are just two other lines showing the same image ID with different tags associated to it.
‫But enough about tags and versions for now.
‫Let's check a few more things out
‫in Docker Hub. If I go back up to nginx in the search bar and search for nginx again, you'll see
‫again that there's a lot of other options and these can be made by anyone.
‫You can create your own custom Nginx version and because it's open source software and free to
‫distribute, you can put it back up here and offer it up to the public.
‫This is very similar to the model of GitHub where they allow you to store open source software and
‫you can fork other people's software and also offer it up.
‫The same thing goes here.
‫You can use other people's images and download them, make them your own, re-upload them.
‫So if I ever want to consider not using an official repository, what I usually look for is a number
‫of stars and a number of polls because a popular repository, to me, tends to establish trust.
‫I always recommend you download and inspect the software before you use it. Look in their Dockerfile
‫and hopefully they'll have an open source repository that you can go look at exactly how they
‫made that image.
‫A good indication is when you see things that have five million pulls on them and 945 stars; clearly
‫there's something interesting about this package and why so many people are choosing it rather than
‫using the official image.
‫You can come in here and look at their repository.
‫You can actually see over on the right that he is linked to his GitHub repository where the actual
‫open source software is that builds this image so that you can go and inspect it; and, possibly download
‫the actual source code outside of an image.
‫But, he clearly has done something with this Nginx image that makes it better than the official
‫default.
‫A couple more things. On the top bar, you'll see Explore. Explore
‫just gives you a summary of all the official images and you can peruse through them and, trust
‫me, there's a lot. In fact, in the resources for this section,
‫you'll find a link to the actual list of official images and under 'library,'
‫this is where all the official images and their Dockerfiles live.
‫You can see there's a lot. As a quick recap, in this lecture we talked about Docker Hub and how it's
‫similar to being the apt package manager for Containers,
‫Then how to recognize official images and how to use them.
‫Then I helped you figure out how to determine a good public image from maybe a not-so-good one.
‫Then a few tips about base images and how Alpine ones are typically smaller than their Debian counterparts.
‫So we're going to use these skills in the rest of this section.