In the previous chapter, after installing Docker, we pulled an image and created a container from it. Docker's primary objective is running containers. In this chapter, we'll see the different operations we can perform with containers, such as starting, stopping, listing, deleting, and so on. This will help us use Docker for different use cases, such as testing, CI/CD, setting up PaaS, and so on, which we'll cover in later chapters. Before we start, let's verify the Docker installation by running the following command:

    $ docker version  

This will give the Docker client and server version, as well as other details.

We need an image to get the container started. Let's see how images are searched for on the Docker registry. As we have seen in Chapter 1, Introduction and Installation, a registry holds the Docker images, which can be both public and private. By default, the search happens on the default public registry, which is the Docker Hub and is located at https://hub.docker.com/.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client.

The docker search command lets you...

After searching for the image, we can pull it to the system by running the Docker daemon. Let's see how we can do that.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client.

To pull an image from the Docker registry, you can either run the following:

    docker image pull [OPTIONS] NAME[:TAG|@DIGEST]

Or the legacy command:

    docker pull [OPTIONS] NAME[:TAG|@DIGEST]

The following is an example of pulling the ubuntu image:

    $ docker image pull ubuntu

We can list the images that are available on the system by running the Docker daemon. These images might have been pulled from the registry, imported through the docker image pull command, or created through a Dockerfile.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client.

Run either one of the following commands to list the images:

    $ docker image ls
    $ docker images

Once we have the images, we can use them to start containers. In this recipe, we will start a container with the ubuntu:latest image and see what happens behind the scenes.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client.

We can start a container using either of the following syntaxes:

    docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
    docker container run [OPTIONS] IMAGE [COMMAND] [ARG...]

We can list both running and stopped containers.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client. You will also need a few running and/or stopped containers.

To list the containers, either run the following command:

    docker container ls [OPTIONS]

Or run the following legacy command:

    docker ps [OPTIONS]

If the container emits logs or output on STDOUT/STDERR, then we can get them without logging into the container.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client. You will also need a running container, that emits logs/output on STDOUT.

To get logs from the container, run the following command:

    docker container logs [OPTIONS] CONTAINER

Or run the following legacy command:

    docker logs [OPTIONS] CONTAINER

Let's take an example from the earlier section...

We can stop one or more containers at once. In this recipe, we will first start a container and then stop it.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client. You will also need one or more running containers.

To stop a container, run the following command:

    docker container stop [OPTIONS] CONTAINER [CONTAINER...]

Or run the following legacy command:

    docker stop [OPTIONS] CONTAINER [CONTAINER...]

If you already have running containers, then you can go ahead and...

We can remove a container permanently, but before that, we have to stop the container or use the force option. In this recipe, we'll create and remove a container.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client. You will also need some containers in a stopped or running state to delete them.

Use the following command:

    $ docker container rm [OPTIONS] CONTAINER [CONTAINER]

Or run the following legacy command:

    $ docker rm [OPTIONS] CONTAINER [CONTAINER]

Let...

We can remove all stopped containers with a single command. In this recipe, we'll create a bunch of containers in a stopped state, and then delete all of them.

Ensure that Docker daemon 1.13 (and above) are running on the host and can be connected through the Docker client. You will also need some containers in a stopped or running state in order to delete them.

Use the following command:

    $ docker container prune [OPTIONS]

Let's first create a container, and then delete it using the following commands...

Before Docker 1.2, when a container exited for any reason or the Docker host was rebooted, the container had to be manually restarted using the restart command. With the release of Docker 1.2, a policy-based restart capability was added to the Docker engine to automate restarting containers. This feature is activated using the --restart option of the run command and it supports container restart at Docker host boot time, as well as when container failures occur.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client.

Linux divides privileges that are traditionally associated with superusers into distinct units, known as capabilities (run man capabilities on a Linux-based system), which can be independently enabled and disabled. For example, the net_bind_service capability allows nonuser processes to bind the port below 1,024. By default, Docker starts containers with limited capabilities. With privileged access inside the container, we allocate more capabilities to perform operations that are normally done by the root user. In order to have a better understanding of privileged mode, let's first try a simple mount on an unprivileged container and observe the effect:

Ensure...

From Docker 1.2 onwards, we can give access of the host device to a container with the --device option, following the run command. Earlier, you had to bind-mount it with the -v option, and that had to be done with the --privileged option.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client. You will also need a device to pass the container to.

You can give access of a host device to the container using the following syntax:

    docker container run...

While doing development and debugging, we might want to look inside an already running container. There are a few utilities, such as nsenter (https://github.com/jpetazzo/nsenter), which allow us to enter the namespace of the container to inspect its state. With the exec option, which was added in Docker 1.3, we can inject a new process inside a running container.

Make sure that the Docker daemon is running on the host and that you can connect through the Docker client. You might also need a running container to inject a process into.

While doing debugging, automation, and so on, we will need the container's configuration details. Docker provides the container inspect command to get those easily.

Ensure that the Docker daemon is running on the host and can be connected through the Docker client.

To inspect a container, run the following command:

    $ docker container inspect [OPTIONS] CONTAINER [CONTAINER...]

We'll start a container and then inspect it, like so:

    $ ID=$(docker container run -d -i ubuntu /bin/bash)
    $...

With Docker 1.6, a feature has been added so that we can label containers and images through which we can attach arbitrary key-value pairs as metadata. You can think of them as environment variables, that are not available for applications running inside containers, but they are available to Docker clients that manage the images and containers. Labels attached to images also get applied to containers that are started using those images. We can also attach labels to containers while starting them. Having labeled an image or a container, the labels can later be used for filtering or selection purposes.

For this recipe, let's assume that we have an image with the label com.example.image=docker-cookbook. We will see how to assign a label to an image in the next chapter:

As you can see from the preceding screenshot, if we use filters with the...

On Linux (and all Unix-like) operating systems, when a process exits, all the resources associated with that process are released with the exception of its entry in the process table. This entry in the process table is kept until the parent process reads the entry to learn about the exit status of its child. This transient state of a process is called a zombie. As soon as the parent process reads the entry, the zombie process is removed from the process table, and this is called reaping. If the parent process exits before the child process, the init process (PID 1) adopts the child process (PID 1) and it eventually reaps adopted child processes when they exit:

In the preceding screenshot, we snipped the process tree for Ubuntu 14.04 on the left-hand side and Ubuntu 18.04 on the right-hand side. As we can see, both process trees have the init...