Docker commands

Docker is an open-source software and a standard for vir­tu­al­ising ap­plic­a­tion con­tain­ers. Container vir­tu­al­isa­tion is a further de­vel­op­ment of virtual machines, but there’s one important dif­fer­ence: instead of sim­u­lat­ing a complete operating system, a single ap­plic­a­tion is vir­tu­al­ised in a container.

Docker is con­trolled 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 un­der­stand­ing of what Docker commands are and how they work, let’s look at the structure of Docker. The Docker in­stall­a­tion on a local host contains the Docker Engine as its core. The Docker engine consists of three main com­pon­ents:

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 con­trolled via the API.
3. The command line interface (‘CLI’), which is used as a docker command to com­mu­nic­ate 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 cor­res­pond­ing API calls are generated and submitted to the Docker daemon to execute.

There are two types of Docker commands that have become es­tab­lished.

On the one hand, there are stan­dalone 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 func­tion­al­it­ies were added, it became in­creas­ingly difficult to find suitable verbs.

So-called ‘Docker man­age­ment commands’ were in­tro­duced to group commands and restore order to the diversity of commands. Docker man­age­ment commands are usually nouns. Well-known examples are ‘docker image’ and ‘docker container’. The Docker man­age­ment commands group verbs as sub­com­mands.

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.

Re­gard­less of whether Docker stan­dalone commands or Docker man­age­ment commands are being used, the Docker commands are invoked on the command line. The name of the command is entered followed by optional para­met­ers. 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 in­form­a­tion:

In most cases, we don’t just call the Docker CLI, but pass the name of a specific command. This can be a stan­dalone command or a man­age­ment command followed by a sub­com­mand. Let’s first look at the general pattern of a Docker stan­dalone command. The name ‘docker’ is followed by the name of the command, optional para­met­ers, and the name of a Docker object if ap­plic­able:

Two familiar Docker stan­dalone commands from pro­duc­tion use are used to display status in­form­a­tion:

Next, let’s fa­mil­i­ar­ise ourselves with Docker man­age­ment commands. As mentioned earlier, these are used to bring order to an or­gan­ic­ally in­creas­ing range of commands. For example, there was ori­gin­ally the ‘docker ls’ command for listing con­tain­ers on a host and, ana­log­ously, the ‘docker images’ command for listing images. Not exactly intuitive. Even though both commands can still be used, more con­sist­ent al­tern­at­ives with ‘docker container ls’ and ‘docker image ls’ now exist.

The general scheme for Docker man­age­ment commands is based on the well-known structure of Docker stan­dalone commands. The name ‘docker’ is followed by the name of the man­age­ment command along with its sub­com­mand. We again conclude with optional para­met­ers 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 in­ter­act­ive mode:

Let’s compare the general structure for Docker man­age­ment commands with the in­di­vidu­al com­pon­ents of the previous example:

Like most command line commands, Docker commands are con­trolled by optional para­met­ers 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 mean­ing­ful. 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 un­der­stand, but takes more time to type and takes up more space. The long form is well-suited for creating scripts; the mean­ing­ful option names serve for doc­u­ment­a­tion purposes.

A majority of the existing Docker commands are used to manage Docker con­tain­ers, 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 de­pend­en­cies and con­fig­ur­a­tion 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. Con­tain­ers 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 vir­tu­al­isa­tion, Docker now includes functions that extend far beyond that. For example, Docker-Compose and Docker-Swarm can be used to or­ches­trate container fed­er­a­tions, which was tra­di­tion­ally reserved for Docker al­tern­at­ives. 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 com­pon­ents. Cor­res­pond­ing commands are available for control:

1. Container operating system and union file system
2. Software com­pon­ents and con­fig­ur­a­tion
3. En­vir­on­ment variables and runtime con­fig­ur­a­tion
4. Ports and volumes
5. Processes and logs

Most Docker func­tion­al­it­ies can now be con­trolled using Docker man­age­ment commands these days. Although the original commands still work, there are more ex­press­ive equi­val­ents:

However, there are still a handful of Docker stan­dalone commands. These cannot be replaced with Docker Man­age­ment commands, as they refer to the Docker in­stall­a­tion as a whole:

Unlike vir­tu­al­isa­tion with virtual machines, a Docker container does not contain its own operating system. Instead, all con­tain­ers 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 con­tain­ers at startup:

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

Con­tain­ers can be started, stopped, and removed on a host. Fur­ther­more, the processes running inside a container can be con­trolled. Ac­cord­ingly, 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 com­pon­ents:

• Image layers: contain data added by operation on the file system. Layers are overlaid and reduced to a con­sist­ent 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 iden­ti­fies the image layers it contains.

A Docker image contains read-only layers. Each layer describes suc­cess­ive 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 ap­plic­a­tion. However, in many cases it is useful to share files between the container and the host system. For this purpose, Docker re­cog­nises different types of volumes. The dif­fer­ences between the volumes are subtle; the choice of the ap­pro­pri­ate type depends heavily on the par­tic­u­lar de­ploy­ment scenario:

• Named volumes – re­com­men­ded
• Anonymous volumes – are lost when the container is removed
• Bind Mounts – not re­com­men­ded; per­form­ant
• Tmpfs Mounts — located in main memory; only under Linux

A handful of Docker commands are available for in­ter­act­ing with volumes: