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 以及把它作为一个插件管理是很棒的选择,由此简化 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 ) 进行尝试。目前尚是实验性功能,还不能用于生产。
作者: Kendrick Coleman 来源: https://blog.codedellemc.com/2017/02/02/deep-dive-docker-1-13-storage-plugins-propagated-mounts/