探究Docker 1.13 存储插件和Propagated Mounts

Docker 1.13最激动人心的特性之一，就是新的插件管理系统。它在1.12尚处于实验阶段，但是现在已经融合成一个完整的功能。本文从插件管理系统出发，深入讨论了容器挂载，追求新技术点的同学不要错过哦！

为什么管理插件非常重要？

最终的目标是快速轻松地利用插件的可扩展性。Docker的任务是让所有插件都像容器一样被管理和运行，把Docker Hub作为集中资源，让插件更可用，从而推动过程标准化。

为了更好地理解这个系统的必要性，让我们倒回到插件管理系统之前，看插件是如何工作的。在主机层面，插件作为单独的服务存在，每一个独立管理。这些插件不需要在一个容器里。无论关于网络还是存储，插件都是由Docker Engine按需激活，使用/var/lib/docker/plugins里的.sock， .spec，或者 .json文件。当需要一个功能时，Docker engine会起对应的插件，而不管它的运行位置。Docker文档因此也被称为实现“Legacy”。

使用一个非常简单的插件API，其弊端是市面上众多插件都采用他们自己的安装选项，从而导致了面板上的不一致和很差的用户体验。大多数插件需要手动移动文件，创建复杂的docker容器，甚至从资源那里建立一个go的package。REX-Ray不断改革创新，维持了一个相对简单的三步过程：

1. curl | sh安装

2. 添加一个配置文章或者环境变量。

3. rexray start来启动服务和sock文件

标准化使整个过程更加简单。它提供了一个警戒线和变量的最小值。我们如何在容器里解决存储的问题？

探究容器挂载

REX-Ray从一个容器的需求出发来挂载volume，并且让这些挂载点对于底层的操作系统（OS）可用。为了让挂载点在容器里对Docker运行的主机可用，利用了Linux的shared捆绑挂载。你可以在复杂的docker run命令里看到：

$ docker run -d -v /run:/run:shared ubuntu

其中的关键是，它只在/run路径是一个共享的挂载时工作。在不同的操作系统上可能会不一致。为了减轻这一点，Docker引入了一个名叫Propagated Mount的功能。文档上这样说：被挂载的路径作为递归共享（rshared），路径下的挂载对于docker可见。一个propagated mount是必要的，让Docker daemon可以在容器里看到挂载。

REX-Ray依托于libStorage package来挂载，挂载的volume在/var/lib/libstorage/volumes/实现。因为REX-Ray是容器化的，挂载在主机层级上的/rootfs/var/lib/libstorage/volumes是可用的。propagated mount确保了这个路径下的挂载volume对于Docker daemon可用。

更多的细节，你可以使用findmnt功能来看在插件初始化findmnt -R -o SOURCE,TARGET,PROPAGATION /前后挂载的传播。如果它工作正常，你可以看到类似/var/lib/docker/plugins//rootfs/var/lib/libstorage/volumes标记为已共享的路径。

 

 

REX-Ray与Docker1.13插件管理系统

我们相信容器化REX-Ray以及把它作为一个插件管理是很棒的选择，由此简化Docker管理的存储可扩展性。工程团队正在努力开发REX-Ray的下一个版本（0.8），包含了对这一新操作模型的相关更新。同时大家会很高兴看到Docker使用REX-Ray作为在文件中创建一个EBS volume插件提供端对端步骤的概念验证。如果你对创建一个自定义插件感兴趣，不妨看一看。

我们从技术角度观察了REX-Ray使用插件管理系统，展示了如何从Docker Hub运行REX-Ray EBS插件。大家可以移步Experimental Docker Managed Plugin at {code} Labs（https://github.com/codedellemc/labs/tree/master/setup-awsec2-docker-plugin）进行尝试。目前尚是实验性功能，还不能用于生产。

原文：探究Docker 1.13 存储插件和Propagated Mounts