无法将基于熔丝的卷暴露给Docker容器

我正在尝试为我的docker容器提供一个用于内部使用的encryption文件系统。 这个想法是,容器将像往常一样写入卷,但实际上主机将在将数据写入文件系统之前对数据进行encryption。

我正在尝试使用EncFS – 它在主机上运行良好,例如:

encfs / encrypted / visible

我可以写文件到/可见的,那些得到encryption。 但是,当试图运行一个容器与/可见作为卷,例如:

docker run -i -t –privileged -v / visible:/ myvolume imagename bash

我确实在容器中获得一个卷,但它在原始/encryption文件夹中,而不是通过EncFS。 如果我从/可见卸载EncFS,我可以看到容器写入的文件。 不用说/encryption是空的。

有没有办法让docker挂载通过EncFS的卷,而不是直接写入文件夹? 相比之下,当我使用NFS挂载作为卷时,docker工作正常。 它写入到networking设备,而不是写入到我安装设备的本地文件夹。

谢谢

Solutions Collecting From Web of "无法将基于熔丝的卷暴露给Docker容器"

我无法在本地复制您的问题。 如果我尝试将Docker卷公开为一个encfs文件系统,尝试启动容器时出现错误:

FATA[0003] Error response from daemon: Cannot start container <cid>: setup mount namespace stat /visible: permission denied 

所以有可能你有不同的事情发生。 无论如何,这是什么解决了我的问题:

默认情况下,FUSE只允许安装文件系统的用户访问该文件系统。 在运行Docker容器时,该容器最初以root身份运行。

挂载FUSE文件系统时,可以使用allow_rootallow_other挂载选项。 例如:

 $ encfs -o allow_root /encrypted /other 

在这里, allow_root将允许root用户访问挂载点,而allow_other将允许任何人访问挂载点(假设目录上的Unix权限允许他们访问)。

如果我使用allow_root通过encfs filesytem进行allow_root ,则可以将该文件系统作为Docker卷进行公开, 并且该文件系统的内容在容器内部可以正确显示。

这当然是因为你在主机挂载挂载点之前启动了docker守护进程。 在这种情况下,目录名称的inode仍然指向主机本地磁盘:

 ls -i /mounts/ 1048579 s3-data-mnt 

那么如果你使用像s3fs这样的保险丝守护进程进行安装:

 /usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt ls -i 1 s3-data-mnt 

我的猜测是,码头工人将目录名缓存到inode(对此有更多的了解的人比填空)。

您的评论是正确的。 如果您只需在安装完成后重新启动Docker,您的卷将正确地从主机共享到您的容器。 (或者你可以简单地延迟起始码头,直到所有坐骑完成安装之后)

有趣的是(现在对我来说是完整的)是,当退出容器并且将挂载点卸载到主机上时,从容器内到共享卷的所有写入都奇迹般地出现了(它们被存储在主机本地磁盘):

 [root@host s3-data-mnt]# echo foo > bar [root@host s3-data-mnt]# ls /mounts/s3-data-mnt total 6 1 drwxrwxrwx 1 root root 0 Jan 1 1970 . 4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 .. 1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar [root@host s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash root@5592454f9f4d:/mounts/s3-data# ls -als total 8 4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 . 4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 .. root@5592454f9f4d:/s3-data# echo baz > beef root@5592454f9f4d:/s3-data# ls -als total 9 4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 . 4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 .. 1 -rw-r--r-- 1 root root 4 Sep 16 17:11 beef root@5592454f9f4d:/s3-data# exit exit [root@host s3-data-mnt]# ls /mounts/s3-data-mnt total 6 1 drwxrwxrwx 1 root root 0 Jan 1 1970 . 4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 .. 1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar [root@host /]# umount -l s3-data-mnt [root@host /]# ls -als [root@ip-10-0-3-233 /]# ls -als /s3-stn-jira-data-mnt/ total 8 4 drwxr-xr-x 2 root root 4096 Sep 16 17:28 . 4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 .. 1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar 

你可以通过在nsenter包装挂载调用来解决这个问题,把它挂载到nsenter守护进程所在的同一个Linux挂载名称空间中。

 nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ... 

问题是这种方法是否会在守护进程重启之后继续存在。 😉