Docker Machine Detailed

The author briefly introduces Docker machine and its basic usage in the article "Introduction to Docker Machine", but the details are too much to ignore. Like the difference between Docker and Docker machine? And what are the important things that Docker machine does when we execute the docker-machine create command so that we can remotely manipulate Docker daemon? Is this remote operation secure? This article will attempt to interpret these questions. Note: The demo environment for this article is Ubuntu16.04.

the difference between Docker and Docker machine

Docker is an application of the Client-server architecture, and there are Boshi: Docker Engine. Docker is just a nickname for Docker Engine, and of course Docker has other meanings, such as the name of a company. For simplicity, Docker in this article is equivalent to Docker Engine.

Referring to Docker we have to know that it contains three parts:

1. Docker Daemon
2. A set of REST APIs that interact with Docker daemon
3. A command-line client

The relationship between them is clearly demonstrated:

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

Docker Daemon Socket

Now that Docker clients are communicating with Docker daemon through the REST API, let's look at the ways they can be used:

1. Unix sockets
2. SYSTEMD Socket activation
3. Tcp

We can simply understand 1 and 2 as one way, that is, interprocess communication on the same host. As for 3, it is well understood that communication across networks is done through the TCP protocol.

Since 1 and 2 are used for interprocess communication on the same machine, we can guess that the Docker client and Docker daemon installed on the same host are communicating this way. It is also true that we can view the Docker daemon boot configuration that was 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 for Docker Daemon listening, and the type specified here is System socket activation. Using types 1 and 2 for communication requires the process to have root privileges. This is also the main reason why a user and user group with root privileges will be created automatically during Docker installation. The newly created user and user group name is Docker, and it is recommended that you add users who need to work with Docker to this group, or you will encounter the problem that appears 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 to TCP port 2376, you can use the following command-line arguments:

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

Run the above command, and then view the port that the native listens on:

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

docker_host Environment Variables

The default configuration of the Docker client is to access the native Docker daemon, and when you specify the Docker_host variable, the Docker client accesses the Docker daemon specified in the variable. Let's review the Docker-machine env command:

Originally we executed the $ eval $ (docker-machine env krdevdb) command in the previous article is set docker_host environment variable.

Addressing security issues

Our Docker daemon listened to the TCP port, and unfortunately we didn't do anything to protect it at this point. So any Docker client can interact with our Docker daemon over the TCP port, which is obviously unacceptable. The solution is to enable the TLS certificate authentication mechanism for both Docker daemon and Docker clients. This allows the communication between the Docker daemon and the Docker client to be encrypted, and only clients with a specific certificate installed can interact with the corresponding Docker daemon.

This is the end of the foreshadowing section of this article, and then we will discuss the contents of Docker machine.

Docker Machine Create command

Depending on the Docker machine driver, the Create command does not do the same thing, but there are two things we are concerned about here:

Docker-machine will perform the following actions on the host you specify:

1. Install Docker and configure it.
2. Generate a certificate to protect the security of the Docker service.

Configuring Docker Daemon

There is no secret to the Docker installation process, which is not mentioned here. We focus on the configuration of the Docker daemon. Looking closely we will find that Docker installed in the/etc/systemd/system directory docker-machine a docker-related directory: DOCKER.SERVICE.D. There is only one file in this directory 10-machine.conf:

Well, it didn't surprise us that H-tcp://0.0.0.0:2376 appeared here. After we've done a lot of paving, you should think it's a matter of course. Several of the parameters at the beginning of--tls are primarily related to certificates, and we will describe them in detail in the security settings that follow. It is the/usr/bin/docker that makes people somewhat puzzled. Currently the latest version of Docker machine is also using the old way to set up Docker daemon, and hopefully it will be updated in the next release.

This configuration file is critical because it overwrites the configuration file at the time of the Docker default installation, which launches the Docker daemon in the manner specified by Docker machine. At this point 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,--tlsverify 、--tlscacert 、--Tlscert and –tlskey. The--tlsverify tells Docker that Daemon needs to authenticate the remote client via TLS. The other three parameters specify the path to a PEM format file, which is checked according to the file path they specify:

Comparing the manually installed Docker, you will find that the/etc/docker directory does not have these three files. There is no doubt that they are generated by Docker machine, primarily to enable the TLS authentication feature of Docker daemon. About TLS, the author in the "LAN deployment Docker Registry" in the article slightly involved, was a manual configuration of the certificate, interested friends can refer to.

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

Look at the/home/nick/.docker/machines/krdevdb directory, found some files with the same name (Ca.pem, Server-key.pem, and Server.pem), and compare the files on the host Drdevdb, Find them to be the same!

Let's take a look at this picture:

In addition to the docker_host we have focused on, there are three additional environment variables. The docker_tls_verify tells the DOCKER client that it needs to enable TLS authentication. DOCKER_CERT_PATH Specifies the directory where TLS validates the dependent files, which is the/HOME/NICK/.DOCKER/MACHINES/KRDEVDB directory that we looked at earlier.

At this point, the security issues that beset us are finally explained: Docker machine generates a series of key and digital certificate (*.PEM) files that guarantee security during the execution of the create command. These files are stored on both local and remote Docker hosts, local for configuring Docker clients, and for configuring Docker daemon on the remote host, allowing both sides to set up a token for TLS authentication, which enables secure communication.

Summary

As you can see from the previous section of this article, Docker actually provides all that is provided, but it is more cumbersome to configure! But for users, the need is always simpler and easier to configure. So from a user's point of view, Docker machine is really cool, and a command goes on not only to install VMS and Docker, but also to do a lot of manually intimidating configurations. Then bring a few clear, simple commands. Then, the students can have fun and happy to play!

Docker Machine Detailed