Docker Machine in-depth explanation

Differences between Docker and Docker Machine

Docker is a Client-Server architecture application, and it has an official name: Docker Engine. Docker is just a nickname for Docker Engine. Of course, Docker also has other meanings, such as the name of a company. For simplicity, Docker in this article is equivalent to Docker Engine.

When we talk about Docker, we must know that it consists of three parts:

1. Docker daemon
2. A REST API for interacting with the Docker daemon
3. A command line client

The following figure clearly shows the relationship between them:

Docker Machine is a tool for installing and managing Docker. It has its own command line tool: docker-machine.

Docker daemon socket

Since the Docker client communicates with the Docker daemon through the REST API, let's look at the methods they can use:

1. Unix socket
2. Systemd socket activation
3. TCP

We can simply understand 1 and 2 as a way of communication between processes on the same host. As for 3, it is easy to understand: cross-network communication through the TCP protocol.

Since 1 and 2 are used for inter-process communication on the same machine, we can guess that the Docker client and Docker daemon installed on the same host communicate in this way. This is indeed the case. We can view the Docker daemon startup configuration added by default when installing Docker and open the file /etc/systemd/system/multi-user.target.wants/docker.service:

The -H in the figure is used to specify the socket that the Docker Daemon listens on. The type specified here is system socket activation. Communication using types 1 and 2 requires the process to have root privileges. This is also the main reason why a user and user group with root permissions are automatically created during the Docker installation process. The newly created user and user group are named docker. It is recommended that you add all users who need to operate Docker to this group. Otherwise, you will encounter the following problem when you execute the command:

We can also specify multiple -H parameters at the same time to let Docker daemon listen to different socket types at the same time. For example, to add a listener for TCP port 2376, you can use the following command line parameters:

$ sudo dockerd -H fd:// -H tcp://0.0.0.0:2376

Run the above command and check the port that the machine is listening on:

At this point we can access port 2376 of this host from the Docker client on the remote host.

DOCKER_HOST environment variable

The default configuration of the Docker client is to access the local Docker daemon. When you specify the DOCKER_HOST variable, the Docker client will access the Docker daemon specified in this variable. Let's review the docker-machine env command:

The executed $ eval $(docker-machine env krdevdb) command sets the DOCKER_HOST environment variable.

Addressing security issues

Our Docker daemon listens on the TCP port, but unfortunately we haven't taken any protective measures at this time. Therefore, any Docker client can interact with our Docker daemon through the tcp port, which is obviously unacceptable. The solution is to enable TLS certificate authentication for both the Docker daemon and the Docker client. In this way, the communication between the Docker daemon and the Docker client will be encrypted, and only the client with a specific certificate installed can interact with the corresponding Docker daemon.

This concludes the preparation for this article. Next, we will discuss Docker Machine.

Docker Machine create command

The create command performs different operations depending on the Docker Machine driver, but there are two steps that we are more concerned about here:

docker-machine will perform the following operations on the host you specify:

1. Install Docker and configure it.
2. Generate certificates to secure your Docker service.

Configure Docker daemon

There is nothing secret about the Docker installation process, so I will not go into details here. We focus on the configuration of the Docker daemon. If we observe carefully, we will find that the Docker installed by docker-machine has an additional Docker-related directory under the /etc/systemd/system directory: docker.service.d. There is only one file in this directory, 10-machine.conf:

Well, the presence of -H tcp://0.0.0.0:2376 here doesn’t really surprise us. After all the preparation we've done, you should think this is a given. The parameters starting with --tls are mainly related to certificates. We will introduce them in detail in the security settings later. What is somewhat confusing is /usr/bin/docker in the above picture. The latest version of Docker Machine still uses the old way to set up the Docker daemon. Hopefully this will be updated in the next version.

This configuration file is crucial because it overrides the default configuration file for Docker installation, thereby starting the Docker daemon in the way specified by Docker Machine. Now we have a Docker daemon that can be accessed remotely.

Generate Certificate

We see four parameters starting with --tls in the Docker daemon configuration file, namely --tlsverify, --tlscacert, --tlscert, and –tlskey. The --tlsverify option tells the Docker daemon to verify the remote client via TLS. The other three parameters specify the path of a pem format file respectively. Check the file paths they specify:

Comparing with the manually installed Docker, you will find that these three files do not exist in the /etc/docker directory. They are no doubt generated by Docker Machine, mainly to enable TLS verification feature of Docker daemon.

Now let's go back to the host where Docker Machine is installed.

Checking the /home/nick/.docker/machines/krdevdb directory, I found some files with the same name (ca.pem, server-key.pem, and server.pem). I compared them with the files on the host drdevdb and found that they are the same!

Let's look at this picture again:

In addition to the DOCKER_HOST we have been concerned about, there are three other environment variables. DOCKER_TLS_VERIFY tells the Docker client to enable TLS verification. DOCKER_CERT_PATH specifies the directory of the files that TLS verification depends on, which is the /home/nick/.docker/machines/krdevdb directory we viewed earlier.

At this point, the security issue that has been bothering us has finally been explained: When Docker Machine executes the create command, it generates a series of secret keys and digital certificate (*.pem) files to ensure security. These files are stored locally and on the remote Docker host. The local one is used to configure the Docker client, and the one on the remote host is used to configure the Docker daemon, so that both sides set the TLS verification mark to achieve secure communication.

Summarize

As you can see from the previous part of this article, Docker actually provides everything that should be provided, but it is more troublesome to configure! But for users, what is needed is always simpler and easier configuration. Therefore, from the user's perspective, Docker Machine is really cool. With one command, you can not only install the virtual machine and Docker, but also complete a lot of configurations that are daunting to do manually. Then come a few clear, simple commands. Then, the students can have fun!

This is the end of this in-depth article about Docker Machine. For more information about Docker Machine, please search 123WORDPRESS.COM’s previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!