Docker Machine深入详解
Docker与DockerMachine的区别
Docker是一个Client-Server架构的应用，人家是有官称的：DockerEngine。Docker只是大家对DockerEngine的昵称，当然Docker还有其他的意思，比如一家公司的名称。简单起见，本文中的Docker等同于DockerEngine。
提到Docker我们必须要知道它包含了三部分内容：
- Dockerdaemon
- 一套与Dockerdaemon交互的RESTAPI
- 一个命令行客户端
下图很清晰的展示了它们之间的关系：
DockerMachine则是一个安装和管理Docker的工具。它有自己的命令行工具：docker-machine。
Dockerdaemonsocket
既然Docker客户端要和Dockerdaemon通过RESTAPI通信，那就让我们看看它们可以采用的方法有哪些：
- Unixsocket
- Systemdsocketactivation
- Tcp
我们可以简单的把1和2理解成一种方式，就是同一台主机上的进程间通信。至于3则很好理解：通过tcp协议进行跨网络的通信。
既然1和2用于同一台机器上的进程间通信，那么我们可以猜想：安装在同一主机上的Docker客户端和Dockerdaemon就是通过这种方式来通信的。事实也正是如此，我们可以查看安装Docker时默认添加的Dockerdaemon启动配置，打开文件/etc/systemd/system/multi-user.target.wants/docker.service：
图中的-H用来指定DockerDaemon监听的socket，此处指定的类型为systemsocketactivation。使用类型1和2进行通信需要进程具有root权限。这也是Docker安装过程中会自动创建一个具有root权限的用户和用户组的主要原因。新创建的用户和用户组名称为docker，建议大家把需要操作Docker的用户都加入到这个组中，否则当你执行命令时就会碰到下图显示的问题：
我们还可以同时指定多个-H参数让Dockerdaemon同时监听不同的socket类型。比如要添加对TCP端口2376的监听就可以使用下面的命令行参数：
$sudodockerd-Hfd://-Htcp://0.0.0.0:2376
运行上面的命令，然后查看本机监听的端口：
此时我们就可以从远程主机上的Docker客户端访问这部主机的2376端口了。
DOCKER_HOST环境变量
Docker客户端默认的配置是访问本机的Dockerdaemon，当你指定了DOCKER_HOST变量后，Docker客户端会访问这个变量中指定的Dockerdaemon。让我们回顾一下docker-machineenv命令：
执行的$eval$(docker-machineenvkrdevdb)命令就是在设置DOCKER_HOST环境变量。
解决安全问题
我们的Dockerdaemon监听了tcp端口，糟糕的是此时我们没有做任何的保护措施。因此任何Docker客户端都可以通过tcp端口与我们的Dockerdaemon交互，这显然是无法接受的。解决方案是同时启用Dockerdaemon和Docker客户端的TLS证书认证机制。这样Dockerdaemon和Docker客户端之间的通信会被加密，并且只有安装了特定证书的客户端才能够与对应的Dockerdaemon交互。
至此本文的铺垫部分终于结束了，接下来我们将讨论DockerMachine相关的内容。
DockerMachinecreate命令
根据DockerMachine驱动的不同，create命令执行的操作也不太一样，但其中有两步是我们在这里比较关心的：
docker-machine会在您指定的主机上执行下面的操作：
- 安装Docker，并进行配置。
- 生成证书保护Docker服务的安全。
配置Dockerdaemon
Docker的安装过程并没有什么秘密，这里不再赘述。我们重点关注Dockerdaemon的配置。仔细观察我们会发现，通过docker-machine安装的Docker在/etc/systemd/system目录下多出了一个Docker相关的目录：docker.service.d。这个目录中只有一个文件10-machine.conf：
好吧，-Htcp://0.0.0.0:2376出现在这里并没有让我们太吃惊。在我们做了巨多的铺垫之后，你应该觉得这是理所当然才是。--tls开头的几个参数主要和证书相关，我们会在后面的安全设置中详细的介绍它们。让人多少有些疑惑的地方是上图中的/usr/bin/docker。当前最新版本的DockerMachine还在使用旧的方式设置Dockerdaemon，希望在接下来的版本中会有所更新。
这个配置文件至关重要，因为它会覆盖Docker默认安装时的配置文件，从而以DockerMachine指定的方式启动Dockerdaemon。至此我们有了一个可以被远程访问的Dockerdaemon。
生成证书
我们在Dockerdaemon的配置文件中看到四个以--tls开头的参数，分别是--tlsverify、--tlscacert、--tlscert和–tlskey。其中的--tlsverify告诉Dockerdaemon需要通过TLS来验证远程客户端。其它三个参数分别指定了一个pem格式文件的路径，按照它们指定的文件路径去查看一下：
对比一下手动安装的Docker，会发现/etc/docker目录下并没有这三个文件。毫无疑问它们是DockerMachine生成的，主要是为了启用Dockerdaemon的TLS验证功能。
现在让我们回到安装了DockerMachine的主机上。
查看/home/nick/.docker/machines/krdevdb目录，发现了一些同名的文件(ca.pem、server-key.pem和server.pem)，和主机drdevdb上的文件对比一下，发现它们是一样的！
让我们再来观察一下这幅图：
除了我们关注过的DOCKER_HOST，还有另外三个环境变量。其中的DOCKER_TLS_VERIFY告诉Docker客户端需要启用TLS验证。DOCKER_CERT_PATH则指定了TLS验证所依赖文件的目录，这个目录正是我们前面查看的/home/nick/.docker/machines/krdevdb目录。
行文至此，困扰我们的安全问题终于得到了解释：DockerMachine在执行create命令的过程中，生成了一系列保证安全性的秘钥和数字证书(*.pem)文件。这些文件在本地和远程Docker主机上各存一份，本地的用于配置Docker客户端，远程主机上的用于配置Dockerdaemon，让两边都设置TLS验证的标记，依此实现安全的通信。
总结
从本文的前一部分可以看到，Docker其实把该提供的都提供了，只是配置起来比较麻烦！但是对用户来说，需要的总是更简单，更容易的配置。因此从使用者的角度来看，DockerMachine确实很酷，一个命令下去不仅能够安装虚机和Docker，还完成了很多手动搞起来令人生畏的配置。然后带来几个清晰、简单的命令。再然后，同学们就可以开心愉快的玩耍了！
到此这篇关于DockerMachine深入详解的文章就介绍到这了,更多相关DockerMachine内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。