转载

探究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不断改革创新，维持了一个相对简单的三步过程：

curl | sh 安装
添加一个配置文章或者环境变量。
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/<name> 实现。因为REX-Ray是容器化的，挂载在主机层级上的 <containerpath>/rootfs/var/lib/libstorage/volumes 是可用的。propagated mount确保了这个路径下的挂载volume对于Docker daemon可用。

更多的细节，你可以使用 findmnt 功能来看在插件初始化 findmnt -R -o SOURCE,TARGET,PROPAGATION / 前后挂载的传播。如果它工作正常，你可以看到类似 /var/lib/docker/plugins/<containerId>/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 ... lugin ）进行尝试。目前尚是实验性功能，还不能用于生产。

作者：Kendrick Coleman

来源： https://blog.codedellemc.com/2 ... unts/

原文 http://dockone.io/article/2079

正文到此结束