探究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标记为已共享的路径。

 

20170213192603

 

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)进行尝试。目前尚是实验性功能,还不能用于生产。

作者:Kendrick Coleman
来源:https://blog.codedellemc.com/2017/02/02/deep-dive-docker-1-13-storage-plugins-propagated-mounts/

分享到:更多 ()