docker从零开始 存储（三）bind mounts

使用bind mounts

自Docker早期以来bind mounts 一直存在。与volumes相比，绑定挂载具有有限的功能。使用bind mounts时，主机上的文件或目录将装入容器中。文件或目录由其在主机上的完整路径或相对路径引用。相反，当您使用卷时，会在主机上的Docker存储目录中创建一个新目录，Docker会管理该目录的内容。

该文件或目录不需要已存在于Docker主机上。如果它尚不存在，则按需创建。绑定挂载非常高效，但它们依赖于具有特定目录结构的主机文件系统。如果您正在开发新的Docker应用程序，请考虑使用命名卷。您无法使用Docker CLI命令直接管理bind mounts。

选择-v或--mount标志

最初，-v或者--volume标志用于独立容器，--mount标志用于群集服务。但是，从Docker 17.06开始，您还可以使用--mount独立容器。一般来说， --mount更明确和冗长。最大的区别在于-v 语法将所有选项组合在一个字段中，而--mount 语法将它们分开。以下是每个标志的语法比较。

具体的用法 和 差异请参看上一节以介绍。

使用绑定装载启动容器

考虑具有一个source目录的情况，并在构建源代码时将构建的代码保存到另一个目录source/target/中，您希望这个构建代码可用于容器/app/，

并且您希望容器在每次构建源时都能访问新构建在开发主机上。使用以下命令将target/ 目录绑定到容器中/app/。从source目录中运行命令 。

该$(pwd)子命令将扩展到Linux或者MacOS主机的当前工作目录。

[[email protected] ~]# mkdir target
[[email protected] ~]# docker run -tid --name devtest --mount type=bind,source="$(pwd)"/target,target=/app nginx:latest
bc8d4cb8bdc26bc77ddc64aa810f7868a13e1019072767a024d8f14b2e4f0a8a

使用docker inspect devtest验证绑定安装正确创建。寻找Mounts部分：

这表明mount是一个bindmount，它显示了正确的源和目标，它表明mount是读写的，并且传播设置为rprivate。

停止容器删除容器：

$ docker container stop devtest

$ docker container rm devtest

挂载到容器上的非空目录中

如果将bind-mount绑定到容器上的非空目录中，则bind mounts 会隐藏目录的现有内容。这可能是有益的，例如当您想要测试新版本的应用程序而不构建新镜像时。当然，它也可能令人惊讶，并且此行为与docker  volume行为不同。

此示例设计极端，但将容器/usr/目录的内容替换为主机上的目录/tmp/。在大多数情况下，这会导致容器无法运行。

这些--mount和-v示例具有相同的最终结果。

[[email protected] ~]# docker run -dit --name broken-container --mount type=bind,source=/tmp,target=/usr nginx:latest
afe70a7698112b93f0d5f200611b80dfe6c4f9e05ad1e8134183975d14428866
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"nginx\": executable file not found in $PATH": unknown.

容器已创建但无法启动。去掉它：

$ docker container rm broken-container

使用只读bind mounts

对于某些开发应用程序，容器需要写入绑定装入，因此更改会传播回Docker主机。在其他时候，容器只需要读访问权限。

此示例修改上面的示例，但ro通过在容器中的挂载点之后添加（默认情况下为空）选项列表，将目录挂载为只读绑定挂载。如果存在多个选项，请用逗号分隔。

[[email protected] ~]# docker run  -dit --name devtest --mount type=bind,source="$(pwd)"/target,target=/app,readonly nginx:latest
c77da99626fd7c8389cc09aee405951f3bd0837a7a78de9d1eb667da2a24cf5f

使用docker inspect devtest验证绑定安装正确创建。寻找Mounts部分：

配置绑定传播

绑定传播默认rprivate为bind  mounts和volume。这里只配置 mount binds，并且仅适用于Linux主机。绑定传播是一个高级主题，许多用户永远不需要配置它。

绑定传播是指在给定的bind mounts或命名volume中创建的挂载是否可以传播到该装载的副本。考虑一个挂载点/mnt，挂载在/tmp。

传播设置控制是否/tmp/a也可以使用挂载/mnt/a。每个传播设置都有一个递归对位。在递归的情况下，请考虑将/tmp/a被/foo挂载。传播设置控制/mnt/a和/或/tmp/a是否将存在。

传播设置 描述
shared 原始挂载的子挂载将暴露给副本挂载，副挂载的副挂载也会传播到原始挂载。
slave 类似于共享挂载，但只在一个方向上。如果原始挂载程序公开子挂载，则副本挂载程序可以看到它。但是，如果副本挂载公开子挂载，则原始挂载无法看到它。
private 挂载是私人的。其中的子挂载不会暴露给副本挂载，而子挂载中的副本挂载不会暴露给原始挂载。
rshared 与共享相同，但传播也扩展到嵌套在任何原始挂载点或副本中的挂载点。
rslave 与从属相同，但传播也延伸到嵌套在任何原始挂载点或副本挂载点。
rprivate 默认值。与private相同，意味着原始或副本挂载点中任何位置的挂载点都不会沿任一方向传播。

在你挂载点设置绑定传播之前，主机文件系统需要已经支持绑定传播。

有关绑定传播的更多信息，请参阅共享子树的 Linux内核文档。

以下示例将target/目录挂载到容器两次，第二个挂载同时设置ro选项和rslave绑定传播选项。

这些--mount和-v示例具有相同的结果。

[[email protected] ~]# docker run -dit --name devtest --mount type=bind,source="$(pwd)"/target,target=/app --mount type=bind,source="$(pwd)"/target,target=/app2,readonly,bind-propagation=rslave nginx:latest

现在，如果你创建/app/foo/，/app2/foo/也存在

[[email protected] ~]# mkdir target/foo
[[email protected] ~]# docker exec devtest ls /app2/
foo
[[email protected] ~]# docker exec devtest ls /app/
foo

果使用selinux，可以添加z或Z选项以修改要装入容器的主机文件或目录的selinux标签。这会影响主机本身上的文件或目录，并且可能会产生Docker范围之外的后果。

  • 该z选项表示绑定装载内容在多个容器之间共享。
  • 该Z选项表示绑定装载内容是私有且非共享的。

使用极端谨慎使用这些选项。绑定安装系统目录（例如/home或/usr使用该Z选项）会导致主机无法运行，您可能需要手动重新标记主机文件。

重要提示：将bind mounts与服务一起使用时，selinux标签（:Z和:z）以及将:ro被忽略。

此示例设置z选项以指定多个容器可以共享绑定装载的内容：

无法使用--mount标志修改selinux标签。

[[email protected] ~]# docker run -itd --name devtest -v "$(pwd)"/target:/app:z nginx:latest
ecb63dfecfdb2602ee32c6e6a34930f86501a052a58fe0da8aacad1f31ecfdeb
[[email protected] ~]# docker run -itd --name devtest2 -v "$(pwd)"/target:/app:z nginx:latest
3427fa5a5ff671454a64186d2cb8fda0553e6c7e912559d43265dd8724cbc2db
[[email protected] ~]# docker run -itd --name devtest3 -v "$(pwd)"/target:/app:z nginx:latest
78abe5d52173bc7cc327983cbb9dac5bdc9bc3cb164fa4fb6940215299191be5

原文地址：https://www.cnblogs.com/benjamin77/p/9513324.html

时间： 2024-11-04 14:17:00

docker从零开始 存储（三）bind mounts的相关文章

docker从零开始 存储（一）存储概述

管理Docker中的数据 默认情况下,在容器内创建的所有文件都存储在可写容器层中.这意味着: 当该容器不再运行时,数据不会持久存在,如果另一个进程需要,则可能很难从容器中获取数据. 容器的可写层紧密耦合到运行容器的主机.您无法轻松地将数据移动到其他位置. 写入容器的可写层需要 存储驱动程序来管理文件系统.存储驱动程序使用Linux内核提供联合文件系统.与使用直接写入主机文件系统的数据卷相比,这种额外的抽象降低了性能 . Docker有两个容器选项可以在主机中存储文件,因此即使在容器停止之后文件仍

Docker的数据管理(volume/bind mount/tmpfs)

Docker提供了三种不同的方式用于将宿主的数据挂载到容器中:volumes,bind mounts,tmpfs volumes.当你不知道该选择哪种方式时,记住,volumes总是正确的选择. volumes是Docker数据持久化机制.bind mounts依赖主机目录结构,volumes完全由Docker管理.Volumes有以下优点: Volumes更容易备份和移植. 可以通过Docker CLI或API进行管理 Volumes可以无区别的工作中Windows和Linux下. 多个容器共

docker 应用数据的管理之bind mounts

创建容器使用bind mounts 挂载文件系统.宿主机文件系统会覆盖掉容器里初始数据 [root@localhost ~]# mkdir /www/htpm -pv mkdir: 已创建目录 "/www" mkdir: 已创建目录 "/www/htpm" [root@localhost ~]# docker run -d --name web-7 -p 82:80 --mount type=bind,src=/www/htpm,dst=/usr/share/ngi

Docker学习第三天(Docker数据卷管理)

1.Docker数据卷管理 在Docker中,要想实现数据的持久化(所谓Docker的数据持久化即数据不随着Container的结束而结束),需要将数据从宿主机挂载到容器中.目前Docker提供了三种不同的方式将数据从宿主机挂载到容器中: 1.volumes:Docker管理宿主机文件系统的一部分(默认文件位置:/var/lib/docker/volumes) 常用 由上图可知我们到了 /var/lib/docker/volumes 目录下有的文件名很长这时匿名 二有的则是我们创建时制定的 2.

四个修改Docker默认存储位置的方法

方法一.软链接 默认情况下Docker的存放位置为:/var/lib/docker 可以通过下面命令查看具体位置: sudo docker info | grep "Docker Root Dir" 解决这个问题,最直接的方法当然是挂载分区到这个目录,但是我的数据盘还有其他东西,这肯定不好管理,所以采用修改镜像和容器的存放路径的方式达到目的. 这个方法里将通过软连接来实现. 首先停掉Docker服务: systemctl restart docker或者service docker s

Android学习笔记?从零开始?第三天?Activity

Android学习笔记?从零开始?第三天?Activity 转载请注明出处:CLeopard http://blog.csdn.net/cleopard 今天主要是对Activity的学习. –>点击进入Android学习笔记导图 http://blog.csdn.net/cleopard/article/details/44037813 –>19本Android经典教程+104个Github上火爆项目开源源码 http://download.csdn.net/album/detail/151

Bind Mounts and File System Mount Order

     When you use the bind option of the mount command, you must be sure that the file systems are mounted in the correct order. In the following example, the /var/log directory must be mounted before executing the bind mount on the /tmp directory: #

Docker底层存储结构

Docker底层存储结构 由于aufs并未并入内核,故而目前只有Ubuntu系统上能够使用aufs作为docker的存储引擎,而其他系统上使用lvm thin provisioning(overlayfs是一个和aufs类似的union filesystem,未来有可能进入内核,但目前还没有:Lvm snapshot are useful for doing e.g. backup of a snapshot, but regress badly in performance when you

Docker默认存储路径修改

Docker默认存储路径: # docker info...... Data loop file: /var/lib/docker/devicemapper/devicemapper/data......Docker Root Dir: /var/lib/dockerDebug Mode (client): falseDebug Mode (server): falseRegistry: https://index.docker.io/v1/Insecure Registries: 127.0.