docker数据卷vs已挂载的主机目录

我们可以在docker中拥有一个数据卷:

$ docker run -v /path/to/data/in/container --name test_container debian
$ docker inspect test_container
...
Mounts": [
    {
        "Name": "fac362...80535",
        "Source": "/var/lib/docker/volumes/fac362...80535/_data",
        "Destination": "/path/to/data/in/container",
        "Driver": "local",
        "Mode": "",
        "RW": true
    }
]
...

但是,如果数据量存在/var/lib/docker/volumes/fac362...80535/_data,是否与使用安装的文件夹中的数据有什么不同-v /path/to/data/in/container:/home/user/a_good_place_to_have_data？

1> E235..：

---

虽然使用它们时感觉相同,但只有目录位置的变化,才有不同之处.

卷与绑定坐骑

使用Bind Mount,主机上的文件或目录将 安装到容器中.文件或目录由其在主机上的完整路径或相对路径引用.

使用Volume,在主机上的Docker存储目录中创建一个新目录,Docker管理该目录的内容.

卷绑定的卷优势:

与绑定装载相比,卷更易于备份或迁移.

您可以使用Docker CLI命令或Docker API管理卷.

卷适用于Linux和Windows容器.

可以在多个容器之间更安全地共享卷.

卷驱动程序允许您在远程主机或云提供程序上存储卷,加密卷的内容或添加其他功能.

新卷的内容可以由容器预先填充.

卷

由Docker创建和管理.您可以使用docker volume create命令显式创建卷,或者Docker可以在容器或服务创建期间创建卷.

创建卷时,它存储在Docker主机上的目录中.将卷装入容器时,此目录是装入容器的目录.这类似于绑定挂载的工作方式,除了卷由Docker管理并与主机的核心功能隔离.

给定的体积可以同时安装到多个容器中.当没有正在运行的容器正在使用卷时,该卷仍可供Docker使用,并且不会自动删除.您可以使用docker volume prune删除未使用的卷.

装入卷时,可能会命名或匿名.匿名卷在首次装入容器时未给出明确的名称,因此Docker为它们提供了一个随机名称,该名称在给定的Docker主机中保证是唯一的.除名称外,命名和匿名卷的行为方式相同.

卷还支持使用卷驱动程序,这些驱动程序允许您将数据存储在远程主机或云提供程序上,以及其他可能性.

绑定坐骑

自Docker早期开始供货.与卷相比,绑定装载具有有限的功能.使用绑定装入时,主机上的文件或目录将装入容器中.文件或目录由主机上的完整路径引用.该文件或目录不需要已存在于Docker主机上.如果它尚不存在,则按需创建.绑定安装非常高效,但它们依赖于具有特定目录结构的主机文件系统.如果您正在开发新的Docker应用程序,请考虑使用命名卷.您无法使用Docker CLI命令直接管理绑定装入.

还有tmpfs mounts.
tmpfs安装

磁盘上没有持久存储tmpfs挂载,无论是在Docker主机上还是在容器中.它可以在容器的生命周期中由容器使用,以存储非持久状态或敏感信息.例如,在内部,swarm服务使用tmpfs挂载将秘密挂载到服务的容器中.

参考:https:
//docs.docker.com/storage/

---

绑定挂载更容易备份。遗憾的是，Docker没有提供任何命令来备份卷。您必须使用带有绑定安装的临时容器来创建备份

2> VonC..：

---

是否与使用-v/path/to/data/in/container:/ home/user/a_good_place_to_have_data挂载的文件夹中的数据有什么不同？

这是因为,如" 将主机目录挂载为数据卷 "中所述

主机目录本质上是依赖于主机的.因此,您无法从Dockerfile安装主机目录,因为构建的映像应该是可移植的.主机目录在所有潜在主机上都不可用.

如果要在容器之间共享某些持久性数据,或者想要从非持久性容器中使用,则最好创建一个命名的数据卷容器,然后从中装入数据.

您可以结合两种方法:

 docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

在这里,我们推出了一个新的容器并从dbdata容器中安装了容量.
然后我们安装了一个本地主机目录/backup.
最后,我们传递了一个命令,用于tar将dbdata卷的内容备份到backup.tar我们/backup目录中的文件.当命令完成并且容器停止时,我们将留下我们dbdata卷的备份.

---

@PermaFrost依赖于主机意味着您不能使用来自主机的卷路径编写Dockerfile,因为该Dockerfile可以在任何主机上构建,每个主机都有自己的特性:在一台主机上有效的路径可能在另一台主机上不可用.这就是为什么安装主机文件夹是*运行时*操作(docker run),而不是编译时间(docker build)

---

@PermaFrost命名卷是独立于主机的,并且是持久的.即使只有一个容器,这意味着我可以在任何主机上导出和恢复命名卷.请参阅https://madcoda.com/2016/03/docker-named-volume-explained/

3> RtmY..：

---

Yes, this is quiet different from a few perspectives. Like you wrote in the question's title, it is all about understanding why we need data volumes vs bind mount to host.

Part 1 - Basic scenarios with examples

Lets take 2 scenarios.

Case 1: Web server.
We want to provide our web server a configuration file that might change frequently.
For example: exposing ports according to the current environment.
We can rebuild the image each time with the relevant setup or create 2 different images for each environment. Both of this solutions aren’t very efficient.

With Bind mounts Docker mounts the given source directory into a location inside the container.
(The original directory / file in the read-only layer inside the union file system will simply be overridden).

For example - binding a dynamic port to nginx:

version: "3.7"
services:
  web:
    image: nginx:alpine
    volumes:
     - type: bind #<-----Notice the type
       source: ./mysite.template
       target: /etc/nginx/conf.d/mysite.template
    ports:
     - "9090:8080"
    environment:
     - PORT=8080
    command: /bin/sh -c "envsubst < /etc/nginx/conf.d/mysite.template > 
        /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"

(*) Notice that this example could also be solved using Volumes.

Case 2 : Databases.
Docker containers do not store persistent data: any data that will be written to the writable layer in container’s union file system will be lost once the container stop running.

But what if we have a database running on a container, and the container stops - that means that all the data will be lost?

Volumes to the rescue.
Those are named file system trees which are managed for us by Docker.

For example - persisting Postgres SQL data:

services:    
  db:
    image: postgres:latest
    volumes:
      - "dbdata:/var/lib/postgresql/data"
    volumes:
     - type: volume #<-----Notice the type
       source: dbdata
       target: /var/lib/postgresql/data
volumes:
  dbdata:

Notice that in this case, for named volumes, the source is the name of the volume (For anonymous volumes, this field is omitted).

Part 2 - Comparison

Differences in management and isolation on the host

Bind mounts exist on the host file system and being managed by the host maintainer.
Applications / processes outside of Docker can also modify it.

Volumes can also be implemented on the host, but Docker will manage them for us and they can not be accessed outside of Docker.

Volumes are a much wider solution

Although both solutions help us to separate the data lifecycle from containers, by using Volumes you gain much more power and flexibility over your system.

With Volumes we can design our data effectively and decouple it from other parts of the system by storing it dedicated remote locations (Cloud for example) and integrate it with external services like backups, monitoring, encryption and hardware management.