The course is part of these learning pathsSee 1 more
This lecture, we will cover what happens when you run a container.
First, you will run a command similar to hello-world to start running a different container than the one previously created.
You will use the command sudo docker run -it ubuntu /bin/bash to instruct Docker to run a container based on the official Ubuntu image.
We will cover where the names for the containers come from and what they really mean. You will review the locations of the images, which lend their names to the containers.
Next, you will get a brief overview of Docker Hub and Docker Store, which are important for downloading images. From here, you will learn how to search in the registries for the images you want.
We will discuss how to pull the images from the registries while specifying a precise tag, paying particular attention to the version.
After we have pulled the image, we will explain where it lives and what to do with it. Then we will check out some of the behind-the-scenes processes
Finally, we will review what has been learned in this lecture, and what to expect in the coming ones.
Welcome back. While we did run the hello-world container in the previous lesson, in this lesson, I'm going to actually explain what's happening. I want to start by running another container. The command will be similar to the hello-world example, though it's not exactly the same thing.
I'm going to run this command, and then we'll break it down so that you can see how it all works in a moment. The command is sudo docker run -it ubuntu /bin/bash and this is going to take a moment to complete. While this is running, I want to describe what's happening at a high level. The command that I just ran instructs Docker to run a container based on the official Ubuntu image.
I want you to focus on the Ubuntu part of the command for now. If you recall, the VM that we're running on here is CentOS. So this is often the point where students ask where is Ubuntu coming from? We've run two containers now, we ran hello-world and Ubuntu, and from an outsider's perspective, it's not really clear where those names come from and what they actually mean.
When we reviewed the Docker architecture I very casually mentioned that Docker downloads images from a registry. Now that registry's where hello-world and Ubuntu come from. They're official images stored on either Docker Hub or the newer Docker Store. Both the Docker Hub and Docker Store serve as centralized locations for Docker images to be downloaded.
Here's a look at the store. Notice the landing page has a search box, at the top and then there's this explore link. While this UI is likely to change over time, as of now, the explore page offers a faceted search. And if you notice here, you can select the registry of either Store or Docker Hub. And there are some additional filters on the side here, and I recommend that you check them out for yourself to see what kind of images already exist.
For now, let's just search for Ubuntu and see what we get. Okay, so we get a few options. Clicking on the one named Ubuntu brings us to a landing page for this particular image. On the right-hand side you can see that there's a command provided that we can use to download this image from the registry. Running this command as it is will download the latest version of Ubuntu.
The ability to pull the latest version is really useful, especially when developing. However, in production you'll need to be precise about which versions to use. And that's where the ability to specify a tag will allow you to download the exact version. That's something we'll cover later in the course.
However, I mention it here because depending on when you watch this, the version for latest, may not be the same for you as it is for me. So, let's go back to the terminal and look at the output. So, notice here at the top, it says unable to find image Ubuntu:latest locally. Docker looks locally on this VM, it can't find the image, so was it does it goes and downloads it from the Docker Hub.
When it downloads the image, it stores it in a subdirectory that lives inside of the /var/lib/docker directory. The next time it runs, it's going to see if an image has changed since it was last downloaded. If it hasn't, then it's just going to use that local version because it already exists locally.
So, the image is now downloaded locally, and if you notice the prompt has changed. Look up here and notice it says vagrant@localhost. That's the bash prompt for our CentOS and down here it says root@ followed by the first several characters of the container ID. This is the bash terminal inside of our Ubuntu container.
Let's look back at the command and see how we got here. Behind the scenes this ran docker pull to pull down the image because it didn't exist locally. Then the Docker run command allows you to execute a command from inside of the container. The command that we're running is the bash binary. The way we are able to get an interactive shell is that we're using the I and T flags.
The I flag makes it interactive by redirecting standard IO. The T flag implements a pseudo TTY, which basically makes the terminal behave like a standard terminal. Because we told Docker to run a bash shell as the container process, if we exit out of this, then the container is going to stop. Okay, let's wrap up here and let's summarize what we've covered.
First, both the Docker Hub and the new Store serve as a registry of existing images that you can use as is, or to form the base for your own images. Second, when using the Docker run command, behind the scenes it's going to download the image if it doesn't exist locally. Then it will run whatever command that you specify.
Using the lowercase I and lowercase T flags will provide an interactive terminal session on the container. And finally, generally speaking, when the process that you run exits the container will too. Alright, in the next lesson we'll dig into the difference between an image and a container. So if you're ready to keep learning, then let's get started in the next lesson.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.