-
Notes
-
Run Containers
The 'docker run' command has the following syntax:
The command 'docker run' is a convenient method that executes two commands:
first it creates the container (docker create) and then it starts it (docker start) .
Let's run the nginx image:
The option '-d' (--detach) run the container in background and print container ID.
The option '--rm' instructs Docker to automatically remove the container when it exits.
Let's verify that nginx is up and running:
You can notice that the name of the container (vibrant_mose) is a random name generated by Docker.
To give a custom name to the container, you can use the option '--name'.
Note that the container's port (80) is not published to the Docker's host.
To publish an exposed container's port and map it to a host's port, you can use the option '-p HOST_PORT:CONTAINER_PORT'.
You can also use the option '-P' to publish all exposed ports to random ports in the Docker's host.
Let's use the two options ('-p', '--name') and run again the nginx image:
Let's verify that both the specified port (the container port 80 is mapped to the Docker host port 8080) and the name were used:
You can use the option '--no-trunc' of the 'ps' command to print the full container ID and the command used to start the nginx process.
We can also run a container in an interactive mode by using the flag -it:
The flag -i instructs docker to start an interactive session and connect the user's terminal with the container's STDIN/STDOUT stream.
It allows the user to send command to the container.
The flag -t instructs docker to allocate a pseudo terminal (TTY).
It provides the user a terminal interface to execute commands interactively.
Note that the terminal prompt is different when we are running commands inside the container (root@651d1a7e5cd7:/#)
from the prompt when are running commands inside the Docker host ($).
This might look different for you depending on your configuration
but usually the prompt inside the container takes this format CONTAINER_USER@CONTAINER_ID:/#.
We can also run a specific command in the container and exit immediately:
Because we have used the flag --rm, the two Ubuntu containers we created above will be automatically deleted
when we exit the container (first scenario above) or the command exits (second scenario above).
To stop the container we can use the command 'docker stop'.
The command can accept either the container name, short ID or full ID.
It's also possible to use few characters of the container ID as long as it's unique.
Any of the following should work:
Let's verify that the container was stopped:
Notes:
- the status of the stopped container is showing 'Exited (0) 7 seconds ago'.
- we used the option -a to list all the containers. Without this option the docker command docker ps list running containers only.
- When you stop a container, all its temporary data is lost (memory, tmpfs).
If we want to start the container again we can use the start command (no need to create the container).
Let's verify that the container was started:
The stop command sends a Unix signal SIGTERM to the the main process running in the container so it can terminate gracefully.
After waiting 10 seconds, Docker will send the Unix signal SIGKILL to force terminating the container.
It's possible to override this behavior by using the options
--signal (specify the Unix signal to send to the container)
and --timeout (specify the number of seconds to wait before Docker can kill the container).
If we need to remove the container completely, we need to stop it first then remove it using the 'docker rm' command:
Let's verify that the container was removed:
When the container is removed, all its data is lost (port bindings, environment variables, labels, ...).
It's possible to use the option --force with the command docker rm
to force the removal of the container (Docker will send the Unix signal SIGKILL to the container).
The remaining container was started using the option '--rm', meaning if we stop it, Docker will remove it automatically:
Let's verify that the container was removed:
Instead of using the run command we can also use the create and start command to start a container.
Let's first create the container:
Let's verify that the container was created:
Note that the status of the container is showing 'Created'.
To start the container:
Let's verify that the container was started:
It's possible to pause a container (all its activity will be stopped) by using the command 'docker pause':
Let's verify that the container was paused:
Note that the status of the container is showing 'Paused'.
To resume the container we can use the command 'docker unpause':
:
Let's verify that the container is running:
Note that the created and status columns are still showing the same information
because the container state didn't change while it was paused.
Actually if we have waited longer time before resuming the container,
that time would have been reflected in the created and status columns.
We can use the command docker kill to force terminating container:
Let's verify that the container was killed:
It's possible to use the option --signal with the command docker kill to specify the Unix signal to send to the container.
By default, a container is not restarted when it exits.
We can adjust this behavior, by using the option '--restart'.
It accepts four values: no (default), always, unless-stopped, and on-failure[:n].
The first value (no) instructs Docker to not restart the container if it exits.
The second value (always) instructs Docker to always restart the container whenever it exits.
The third value (unless-stopped) instructs Docker to always restart the container whenever it exits, unless it's stopped.
The last value (on-failure[:n]) instructs Docker to always restart the container whenever it exits with a nonzero exit code.
It's possible to use the on-failure with a number to instruct Docker to restart the container the number of times specified
(e.g., on-failure:2 instructs Docker to restart the container 2 times after which the container won't be restarted again).
-
Set Environment Variables
The "docker run" command has two options that allow you to set environment variables for your containers:
Let's try the option "-e" ("--env"):
The two environment variables were set properly.
The applications running inside the container can use them as they would in a regular deployment in a native host.
In some cases, setting environment variables using the option "--env" can be cumbersome especially if we want to set many of them.
Optionally, you can group all the environment variables in a property file and use the option "--env-file" to pass the file to "docker run" command.
Let's create a property file:
Let's use the option "--env-file":
-
Set Labels
The "docker run" command has two options that allow you to set labels for your containers:
Let's try the option "-l" ("--label"):
Let's check the labels:
The two labels were set properly. We can use them to filter containers:
In some cases, setting labels using the option "--label" can be cumbersome especially if we want to set many of them.
Optionally, you can group all the labels in a property file and use the option "--label-file" to pass the file to "docker run" command.
Let's create a property file:
Let's use the option "--env-file":
Let's check the labels:
-
Set the Container's Hostname
When you run a container, it gets automatically the /etc/hostname file initialized with its ID:
To assign a specific host name to the container, we can use the option -h (--hostname) with the command docker run:
-
Mount Local Volumes
The "docker run" command has two options that allow you to mount local files and directories into your containers:
Let's bind mount a directory and a file using the -v (--volume) option:
Note that:
- We are mounting a directory (/usr/local/bin) and a file (./dockerhostfile.txt) from the Docker host into the container.
- The files/directories from the source (docker host) and the target (container) are separated by the colon character (:).
- The ro flag indicates that the source directory is mounted using the read-only mode (otherwise mounted read-write by default: rw).
- The source file (docker host) needs to be created in advance (otherwise it will be mounted as a directory).
- The user that run the container (in this example root) should have write access if needed.
- If the directories don't exist, they will be automatically created if no permission issues.
- The created directories will be owned by the user that run the container.
Let's do the same with the --mount option:
The same notes discussed above apply to the --mount option, with the following exceptions:
- The files/directories from the source (docker host) and the target (container) are separated by the comma character (,).
- To indicate a read only mount, we need to use the flag readonly (otherwise mounted read-write by default).
- The flag source is used for the source file/directory in the Docker host.
- The flag target is used for the target file/directory in the container.
The command "docker run" provides the option --tmpfs to mount a temporary filesystem.
The data of a tmpfs filesystem is stored in RAM and lost when the container is stopped.
Let's check the default "/tmp" folder:
By default the /tmp folder is mounted as the root filesystem.
This can be an issue if the container's root filesystem is mounted read only (option --read-only).
Let's use the the option --tmpfs:
We can use the --mount option to mount a tmpfs filesystem and set it size: