How do you run a container as a daemon?

Please note that if the intention is to launch a container that stays up, it is not sufficient to specify the -d flag. The container must run a non-daemon, and non-terminating command so that it remains running. If the command goes in the background or it terminates, the container will be stopped.

How do you automatically restart a container if it fails?

The --restart flag restarts the container automatically based on the container’s running process exit code:

Flag

Description

--restart=no

Never restart: default.

--restart=always

Ignore the exit code: always restart.

--restart=unless-stopped

Ignore if it has been stopped before.

--restart=on-failure

Only if non-zero exit code.

--restart=on-failure:3

Same as above but max 3 attempts.

How do you override the image’s startup command?

If the image defines the startup command by using the CMD declaration in the Dockerfile, it is just a matter of specifying the required command as the last argument to docker run.

However, an image may define an automatic command to be executed when a container is run via the ENTRYPOINT declaration. (see Dockerfile Configuration). To override this command, use the --entrypoint="<command>" flag.

How do you define startup arguments?

If you want to execute a command when a container is launched but you want to have flexibility in terms of its arguments, you can use ENTRYPOINT [ "<command>" ] to define the command that should be executed when the container is run, and, optionally, the CMD [ "arg1","arg2",...] declaration to specify the command’s arguments.

For example:

ENTRYPOINT [ "/bin/bash" ]
CMD [ "--norc" ]

In the above case, docker run without a command argument will run /bin/bash --norc but the latter may be optionally overridden:

docker run -ti simple

bash-4.3# exit
exit

docker run -ti simple --version

GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
Check the **Running an Image** section to see how to
override these options when running a container .

The ENTRYPOINT declaration may be overridden using the --entrypoint flag when using the docker run command. In the below example, both the ENTRYPOINT and the CMD declarations are being overridden:

How do you setup a working directory?

Rather than referring all commands using absolute paths, a default working directory may be defined using the WORKDIR declaration.

How do you copy files to the image?

Use the ADD <source> <destination> declaration, which supports various modes:

Copy file: In this case, <source> is a file within the build directory only. For example:

ADD config.xml /var/lib/app/config.xml

Fetch file from URL: In this case is a file that will be retrieved from an URL. For example:

ADD http://intranet/config.xml /var/lib/app/config.xml

Unpack archive file: In this case is an archive file such as .tar, .tar.gz, etc. For example:

ADD images.tar /var/www/images/

Alternatively, the COPY declaration may be used which will avoid any unpacking when dealing with archive files.

How do you add metadata?

Use the LABEL <variable>="<value>" declaration. For example:

LABEL release="1.2"

Multiple label may also appear in the same line. For example:

LABEL release="1.2" author="ernie"

The labels can be extracted using the docker inspect command:

docker docker inspect -f {{.ContainerConfig.Labels}} gato_lindo

map[author:ernie release:1.2]

docker inspect -f {{.ContainerConfig.Labels.author}} gato_lindo

ernie

How do you specify default build arguments?

Defaults for the --build-arg flag passed to the docker build command may be specified using the ARG <value> or ARG <name>=<value> declarations. For example:

ARG betaImage
ARG runAs=webuser

Volumes

What are volumes?

Volumes are Docker’s mechanism to writing and sharing persistent data (that survives stopping a container). All volumes have in common the fact that they appear as mount points inside the container. However, how (and to what object) the mount point is connected to the outside world may vary:

A host’s directory: A regular UNIX path sitting within the host.

A new volume: A new volume is created when the container is launched but it is not deleted when it is stopped unless special directives are provided.

A volume registered by a container: When a new volume is created, in reality it is associated with the container’s name. Therefore, a second container may refer the volume created by a previous one. This way we stop creating brand new volumes every time which is not very useful anyway.

How do you find out a container’s internal IP address?

How do you connect two containers?

Containers that listen on a TCP port are, by default, available on the Docker’s bridge virtual network. For example, let’s suppose that we have a server that listens on port 8000 that is exposed and mapped to port 80 and a client that takes the server’s URL:

As you can see, the exposed port (80) is irrelevant in the case of the client reaching the client via the Docker’s bridge.

However, what if we want the client container to talk to the regular host’s network interface? In this case we have to use the --net="host" flag when we invoke the client and use the mapped port instead. For example: