Introduction to Docker CLI

We will start with some common commands. Then, we'll take a peek at commands that are used for Docker images. We will then take a dive into commands that are used for containers.

The first command we will look at is one of the most useful commands in Docker and in any command-line utility you may use. This is the help command. This is run simply by executing the command, as follows:

$ docker --help

The preceding command will give you a full list of all the Docker commands at your disposal and a brief description of what each command does. For further help with a particular command, you can run the following command:

$ docker <command> --help

You will then receive additional information about using the command, such as options, arguments, and descriptions for the arguments. You can also use the Docker version command to gather information about what version of Docker you are running:

$ docker version

Client:
 Version:      17.03.0-ce
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   3a232c8
 Built:        Tue Feb 28 08:10:07 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.0-ce
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   3a232c8
 Built:        Tue Feb 28 08:10:07 2017
 OS/Arch:      linux/amd64
 Experimental: false

Docker images management

Let's learn how to view which images you currently have that you can run, and let's also search for images on the Docker Hub. Let's first take a look at the docker images command:

$ docker images

REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
centos                                  7                   49f7960eb7e4        6 weeks ago         200 MB
mariadb                                 10.1                e98a88b23fa0        7 weeks ago         400 MB

There are a few important pieces to understand from the output that you see. Let's go over the columns and what is contained in each of them. The first column that you see is the repository column. This column contains the name of the repository, as it exists on the Docker Hub. If you were to have a repository that was from some other user's account. The tag column will show you what tag the image has. Image ID is based off a unique 64 hexadecimal digit string of characters. The last two columns are pretty straightforward, the first being the creation date for the image, followed by the virtual size of the image. The size is very important because you want to keep or use images that are very small in size if you plan to move them around a lot.

So let's take a look at how we can search for images that are on the Docker Hub using the Docker commands. The command that we will be looking at is docker search. With the docker search command, you can search based on the different criteria that you are looking for. For example, we can search for all images with the term, mariadb, in their name and see what is available.

The command would go something like the following:

$ docker search mariadb

NAME                                                      DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
mariadb                                                   MariaDB is a community-developed fork of M...   2075      [OK]       

If we find an image that we want to use, we can simply pull it using its repository name with the docker pull command, as follows:

$ docker pull <image>

The image will be downloaded and show up in our list when we now run the docker images command that we ran earlier.

With the docker rmi command, you can remove unwanted images from your machine:

$ docker rmi <image>

If you use the -f flag and specify the image’s short or long ID, then this command untags and removes all images that match the specified ID.

Starting containers

Let's first go over the basics of the docker run command and how to run containers. The most basic way to run a container is as follows:

$ docker run -i -t <image>:<tag> /bin/bash

For example, we want run the mariadb image:

$ docker run -i -t mariadb:10.1 /bin/bash

The first -i option, gives us an interactive shell into the running container. The second -t option will allocate a pseudo tty, which when using interactive processes, must be used together with the -I switch.
Once you are comfortable with your container, you can test how it operates in daemon mode:

$ docker run -d <image>:<tag>

If the container is set up correctly and has an entry point setup, you should be able to see the running container by issuing the docker ps command, seeing something similar to the following:

$ docker ps

You can also expose ports on your containers using the -p switch, just like this:

$ docker run -d -p <host_port>:<container_port> <image>:<tag>

Now, there will come a time when containers don't want to behave, and for this, you can see what issues you have using the docker logs command. This command is very straightforward. You specify the container for which you want to see the logs, which is just a redirect from stdout. For this command, you use the container ID or the name of the container from the docker ps output:

$ docker logs <id>

Stopping containers

There are a few commands that we can use to do this. They are docker kill and docker stop. Let's cover them briefly as they are fairly straightforward, but let's look at the difference between docker kill and docker stop. The docker kill command will kill the container immediately.

$ docker kill <container>

For a graceful shutdown of the container, you use the docker stop command.

$ docker stop <container>

When you are testing, you will usually use docker kill, and when you are in your production environments, you will want to use docker stop to ensure that you don't corrupt any data.
With the docker rename command, we can change the name that has been randomly generated for the container. When we used the docker run command, a random name was assigned to our container.

$ docker rename <current_container_name> <new_container_name>

The docker stats command displays a live stream of container(s) resource usage statistics

$ docker stats

CONTAINER           CPU %               MEM USAGE / LIMIT       MEM %               NET I/O             BLOCK I/O           PIDS
30feb5ef3800        0.04%               628.2 MiB / 31.26 GiB   1.96%               9.41 MB / 31 MB     164 MB / 73.7 kB    0
2fb1bdd70ec2        0.04%               384.8 MiB / 31.26 GiB   1.20%               75.3 MB / 45.3 MB   38.5 MB / 783 MB    0

The docker top command gives us a list of all running processes inside the container.

$ docker top <container>

Lastly, let's cover how we can remove containers. In the same way that we looked at removing images earlier with the docker rmi command, we can use the docker rm command to remove unwanted containers. This is useful if you want to reuse a name you assigned to a container:

$ docker rm <container>

Overview of docker architecture

At the very start of the IT revolution, most applications were deployed directly on physical hardware, over the host OS. Because of that single user space, runtime was shared between applications. The deployment was stable, hardware-centric, and had a long maintenance cycle. It was mostly managed by an IT department and gave a lot less flexibility to developers. In such cases, hardware resources were regularly underutilized.

The following diagram shows a Traditional application deployment:

The introduction of the virtual machines (VMs) we emulated the hardware for virtual machines (VMs) and deployed a guest OS on each virtual machine. With virtualization, applications are isolated at VM level and defined by the life cycle of VMs. This gives better return on investment and higher flexibility at the cost of increased complexity and redundancy.

The following diagram shows an application deployment with VMs:

After virtualization, we are now moving towards more application-centric IT. We have removed the hypervisor layer to reduce hardware emulation and complexity. The applications are packaged with their runtime environment and are deployed using containers. Containers are also considered less secure than VMs, because with containers, everything runs on the host OS. If a container gets compromised, then it might be possible to get full access to the host OS. It can be a bit too complex to set up, manage, and automate. These are a few reasons why we have not seen the mass adoption of containers in the last few years, even though we had the technology.

With Docker, containers suddenly became first-class citizens. All big corporations such as Google, Microsoft, Red Hat, IBM, and others are now working to make containers mainstream. Docker was started as an internal project by Solomon Hykes, who is the current CTO of Docker, Inc., at dotCloud. It was released as open source in March 2013 under the Apache 2.0 license. With dotCloud's platform as a service experience, the founders and engineers of Docker were aware of the challenges of running containers. So with Docker, they developed a standard way to manage containers.