Docker commands

Docker is an open-source software and a standard for virtualizing application containers. Container virtualization is a further development of virtual machines, but there’s one important difference: instead of simulating a complete operating system, a single application is virtualized in a container.

Docker is controlled on a local system via a command line interface. The commands used are essential for working with Docker. We explain how Docker commands work and show you the most important ones.

To gain a better understanding of what Docker commands are and how they work, let’s look at the structure of Docker. The Docker installation on a local host contains the Docker Engine as its core. The Docker engine consists of three main components:

1. The Docker daemon, which runs as dockerd on the host.
2. The Docker API, provided by the Docker daemon. The Docker daemon is accessed and controlled via the API.
3. The command line interface (“CLI”), which is used as a docker command to communicate with the Docker API.

To control Docker, a user enters Docker commands via the command line. The commands are received and processed by the Docker CLI and corresponding API calls are generated and submitted to the Docker daemon to execute.

There are two types of Docker commands that have become established.

On the one hand, there are standalone commands. Usually, these take the form of verbs that perform a specific action. Well-known examples are “docker pull” and “docker build”. As the platform expanded and new functionalities were added, it became increasingly difficult to find suitable verbs.

So-called “Docker management commands” were introduced to group commands and restore order to the diversity of commands. Docker management commands are usually nouns. Well-known examples are “docker image” and “docker container”. The Docker management commands group verbs as subcommands.

In this way, the same verbs can be used in different contexts. For example, the command “docker image rm” is used to remove an image while “docker container rm” is used to remove a container.

Regardless of whether Docker standalone commands or Docker management commands are being used, the Docker commands are invoked on the command line. The name of the command is entered followed by optional parameters. If necessary, this is followed by the name of one or more objects. This can be a container, an image, a volume, or similar.

Let’s look at the general structure of a Docker command on the command line. In the simplest case, only the Docker CLI is called with an option appended:

Well-known examples are the output of the Docker version or the Docker help information:

In most cases, we don’t just call the Docker CLI, but pass the name of a specific command. This can be a standalone command or a management command followed by a subcommand. Let’s first look at the general pattern of a Docker standalone command. The name “docker” is followed by the name of the command, optional parameters, and the name of a Docker object if applicable:

Two familiar Docker standalone commands from production use are used to display status information:

Next, let’s familiarize ourselves with Docker management commands. As mentioned earlier, these are used to bring order to an organically increasing range of commands. For example, there was originally the “docker ls” command for listing containers on a host and, analogously, the “docker images” command for listing images. Not exactly intuitive. Even though both commands can still be used, more consistent alternatives with “docker container ls” and “docker image ls” now exist.

The general scheme for Docker management commands is based on the well-known structure of Docker standalone commands. The name “docker” is followed by the name of the management command along with its subcommand. We again conclude with optional parameters and the name of a Docker object if necessary:

Let’s examine the pattern by looking at a more concrete example. Here is the Docker command to launch a new container from the “httpd” image in interactive mode:

Let’s compare the general structure for Docker management commands with the individual components of the previous example:

Like most command line commands, Docker commands are controlled by optional parameters called “options” when invoked. The options follow the name of the command. They are case-sensitive. Usually there are two notations for most options:

1. Short form: -, e.g. “docker -v”

The short form is not very meaningful. Instead, several options can be combined into one, e.g. “docker run -it” instead of “docker -i -t”. The order is arbitrary, so you could also write “docker run -ti”. The short form is well suited for speedy working with known commands on the command line.

2. Long-form: --<options name>, e.g. “docker –version”

The long form is easy to understand, but takes more time to type and takes up more space. The long form is well-suited for creating scripts; the meaningful option names serve for documentation purposes.

A majority of the existing Docker commands are used to manage Docker containers, Docker images, and Docker volumes. Before going into detail about the specific Docker commands, we provide a brief overview of how the important Docker concepts of container and image are related.

A Docker container is created from an immutable template called an image. A Docker image contains the dependencies and configuration settings needed to create a container. Not only can we create a container from an image, but we can also save an existing container to a new image. Containers and images are related in much the same way as the chicken and the egg are related to each other:

Docker has rapidly developed over the past ten years. In addition to the original container virtualization, Docker now includes functions that extend far beyond that. For example, Docker-Compose and Docker-Swarm can be used to orchestrate container federations, which was traditionally reserved for Docker alternatives. We cover a subset of the original commands below. A full listing is beyond the scope of this article.

A Docker container includes the following components. Corresponding commands are available for control:

1. Container operating system and union file system
2. Software components and configuration
3. Environment variables and runtime configuration
4. Ports and volumes
5. Processes and logs

Most Docker functionalities can now be controlled using Docker management commands these days. Although the original commands still work, there are more expressive equivalents:

However, there are still a handful of Docker standalone commands. These cannot be replaced with Docker Management commands, as they refer to the Docker installation as a whole:

Unlike virtualization with virtual machines, a Docker container does not contain its own operating system. Instead, all containers running on a Docker host access the same operating system kernel. Each container is allocated a certain amount of system resources by command when running. These include memory, CPU cores, mass storage, and (virtual) network devices. Here are two examples:

Assign a CPU core and 10 megabytes of memory to Docker containers at startup:

Map TCP port 80 of the Docker host to port 80 of the Docker container:

Containers can be started, stopped, and removed on a host. Furthermore, the processes running inside a container can be controlled. Accordingly, many of the Docker container commands deal with these tasks:

Unlike virtual machine images, a Docker image is not a single file in its normal state. Instead, it is a composite of multiple components:

• Image layers: contain data added by operation on the file system. Layers are overlaid and reduced to a consistent level by a union file system.
• Parent image: provides basic functions of the image and anchors the image in the Docker ecosystem root tree.
• Image manifest: describes the composite and identifies the image layers it contains.

A Docker image contains read-only layers. Each layer describes successive changes to the image’s file system. For each operation resulting in a change to the image’s file system, a new layer is created. The following commands are used to interact with images on the host:

A Docker container contains an isolated application. However, in many cases it is useful to share files between the container and the host system. For this purpose, Docker recognizes different types of volumes. The differences between the volumes are subtle; the choice of the appropriate type depends heavily on the particular deployment scenario:

• Named volumes – recommended
• Anonymous volumes – are lost when the container is removed
• Bind Mounts – not recommended; performant
• Tmpfs Mounts — located in main memory; only under Linux

A handful of Docker commands are available for interacting with volumes: