Pulling an image and running a container

I am borrowing the following recipe from the next chapter to introduce some concepts. Don't worry if the recipe doesn't explain everything; we'll cover the topics in detail later in this chapter, or in the next few chapters. For now, let's pull an image and run it. We'll also get familiar with Docker architecture and its components in this recipe.

Getting ready

First, gain access to a system that has Docker installed.

How to do it...

To pull an image and run a container, go through the following steps:

1. Pull an image by running the following command:

      $ docker image pull alpine

2. List the existing images by using the following command:

      $ docker image ls

3. Create a container using the pulled image and list the containers as follows:

        $ docker container run -id --name demo alpine ash

How it works...

Docker has client–server architecture. Its binary consists of the Docker client and server daemon, and can reside on the same host. The client can communicate via sockets or a RESTful API to either a local or remote Docker daemon. The Docker daemon builds, runs, and distributes containers. As shown in the following diagram, the Docker client sends the command to the Docker daemon running on the host machine. The Docker daemon also connects to either a public or a local registry to get images requested by the client:

So in our case, the Docker client sends a request to the daemon running on the local system, which then connects to the public Docker registry and downloads the image. Once it is downloaded, we can run it.

There's more...

Let's explore some keywords that we encountered earlier in this recipe:

• Images: Docker images are read-only templates, and they give us containers during runtime. They are based on the idea of a base image and layers resting on top of it. For example, we can have a base image of Alpine or Ubuntu, and then we can install packages or make modifications over the base image to create a new layer. The base image and new layer can be treated as a new image. For example, in the following figure, Debian is the base image and then Emacs and Apache are the two layers added on top of it. They are highly portable and can be shared easily:

Layers are transparently laid on top of the base image to create a single coherent filesystem.

• Registries: A registry holds Docker images. It can be public or private, depending on the location from which you can download or upload images. The public Docker registry is called Docker Hub, which we will cover later.
• Index: An index manages user accounts, permissions, searches, tagging, and all that nice stuff that's in the public web interface of the Docker registry.
• Containers: Containers run images that are created by combining the base image and the layers on top of it. They contain everything that is needed to run an application. As shown in the preceding diagram, a temporary layer is also added while starting the container, and this will be discarded if it is not committed after the container is stopped and deleted. If it is committed, then it would create another layer.
• Repository: Different versions of an image can be managed by multiple tags, which are saved with different GUID. A repository is a collection of images tracked by GUIDs.

See also

For more information, check out the documentation on the Docker website at https://docs.docker.com/engine/docker-overview/.