【发布时间】：2019-02-20 05:25:35
【问题描述】：
我正在 Dockerising 一个旧项目。项目中的一个功能引入了用户指定的 Git 存储库，由于存储库的大小可能导致文件系统不堪重负，我创建了一个固定大小的本地文件系统，然后将其挂载。这是为了防止网络主机的文件系统被填满。
一般的做法是这样的：
IMAGE=filesystem/image.img
MOUNT_POINT=filesystem/mount
SIZE=20
PROJECT_ROOT=`pwd`
# Number of M to set aside for this filing system
dd if=/dev/zero of=$IMAGE bs=1M count=$SIZE &> /dev/null
# Format: the -F permits creation even though it's not a "block special device"
mkfs.ext3 -F -q $IMAGE
# Mount if the filing system is not already mounted
$MOUNTCMD | cut -d ' ' -f 3 | grep -q "^${PROJECT_ROOT}/${MOUNT_POINT}$"
if [ $? -ne 0 ]; then
# -p Create all parent dirs as necessary
mkdir -p $MOUNT_POINT
/bin/mount -t ext3 $IMAGE $MOUNT_POINT
fi
这在 Linux 本地或远程 VM 中运行良好。不过，我想在容器内部运行这个shell代码或类似的东西。我想这样做的部分原因是将所有繁琐的东西包含在一个容器中，以便构建一个新的主机尽可能简单（在我看来，设置自定义挂载和 cron-restart 规则主持人反对）。
因此，此命令在容器内不起作用（“文件系统”是主机上的 Docker 卷）
mount -t ext3 filesystem/image.img filesystem/mount
mount: can't setup loop device: No space left on device
它也不适用于容器文件夹（“filesystem2”是容器目录）：
dd if=/dev/zero of=filesystem2/image.img bs=1M count=20
mount -t ext3 filesystem2/image.img filesystem2/mount
mount: can't setup loop device: No space left on device
我想知道容器是否没有合适的内部机器来进行安装，因此我是否应该改变方向。我不想在这方面花费太多时间（我只是将一个项目移动到一个仅限 Docker 的服务器），这就是为什么我想尽可能让mount 工作。
其他选项
如果这不可行，那么我需要研究一个可与 Docker 和 Swarm 一起使用的大小受限的 Docker 卷。关于这是否真的有效，网络上有相互矛盾的报道 (see this question)。
suggestion here 表示 Flocker 支持此功能。但是，我很犹豫是否要使用它，因为在 be abandoned 看来，可能受到了 ClusterHQ 破产的影响。
This post 表示我可以将--storage-opt size=120G 与docker run 一起使用。但是，docker service create 似乎不支持它（除非该选项已被重命名）。
更新
根据评论会议，我取得了一些进展；我发现将--privileged 添加到docker run 可以启用挂载，但代价是取消了安全隔离。一位乐于助人的评论者说，最好使用--cap-add SYS_ADMIN 的更细粒度的控制，让容器保留一些隔离。
但是，Docker Swarm 还没有实现这些标志，所以我不能使用这个解决方案。 This lengthy feature request 建议我不要着急添加此功能；已经等了两年了。
【问题讨论】：
-
啊，我刚刚用
--privileged在一个Ubuntu容器中挂载了一个文件。现在，我只需要在服务中执行此操作，但这还不允许；解决方法是somewhere in here。 -
您可以在容器中允许
mount使用--cap-add SYS_ADMIN而不是--privileged。 -
谢谢@mviereck。我同意这样会更安全，但看起来（我当前版本的）Swarm (
docker service create) 也不支持。