Docker，Volumes与Bind Mounts之间的持久数据，例如DB，elasticsearch？ [英] Docker, Volumes vs Bind Mounts for persistent data such as DB, elasticsearch?
问题描述
说卷比绑定安装
我对此问题有几个疑问。帖子说：
I have a few questions regarding the issue. The post says:
创建卷时，该卷存储在Docker主机上的目录中
与我同在，但是我是Docker的新手，我想知道这里的 docker host 是什么。
Bear with me, but I'm new to docker, and I'm wondering what is docker host here.
是否是我在其中构建映像的机器（可能不是）？
是在其中运行映像的机器吗？如果是这样，如果我在多台计算机上运行映像会发生什么，它将创建两个独立的卷吗？
当我进行开发和生产设置，docker如何为每个环境管理两个单独的卷？
Is it a machine where I build the image (probably not)?
Is it the machine where the image will be run? If it is so, what happens if I run the image on multiple machines, will it create two independent volumes?
When I have developement and production setup, how docker manages two separate volumes for each environment?
此外，通过执行 docker-compose down 当我使用数据量时，这是让我犹豫使用数据量的第一个障碍，是
Besides it seems fairly easy to lose data by doing docker-compose down when I use data volumes, that's the first obstacle that makes me to hesitate to use data volumes, is there an obvious solution to mitigate the issue?
推荐答案
实际上这不是一个原则-不使用绑定安装。是的，默认情况下，一旦您在容器中拥有root特权，它们安装不正确（例如 -v / bin：/ var / log ）会损坏主机的文件系统；它们的便携性也较差，但它们促进了主机和容器之间的文件交换。当您想为服务提供初始配置，或将要编译的源代码放入容器时，我相信您宁愿 bind mount 而不是为 docker volume cp 操作。另外，应尽可能使用：ro 选项（只读），以防止从容器内部修改数据。
That's not a doctrine actually - not using bind mounts. Yes, they can damage your host's file system if mounted inaccurately (like -v /bin:/var/log) as soon as your have root privileges inside container by default; also they are less portable but they facilitate file exchange between host and container. When you want to provide initial configuration for your service, or put source code for compilation into container, I believe you would prefer to bind mount instead of creating and running temporary container for docker volume cp operations. Also, you should always use :ro option when possible (read only) to prevent data modification from inside container.
Docker主机-这是一台运行Docker守护进程的计算机（PC）。
Docker host - it is a machine (PC), where Docker daemon is running.
这是我在其中构建映像的计算机（可能不是）？
Is it a machine where I build the image (probably not)?
不正确。您可以使用 docker CLI 或 docker API 进行远程构建。
Not true. You can build using docker CLI or docker API remotely.
是在其中运行映像的机器吗？
Is it the machine where the image will be run?
是的，映像由docker运行
Yes, images are run by docker daemon and thus it will be the host.
如果是这样，如果我在多台机器上运行映像，会发生什么情况，
它会创建两个独立的卷吗？
If it is so, what happens if I run the image on multiple machines, will it create two independent volumes?
这取决于。可以通过不同的方式来实现在不同计算机上运行映像的方法，这些方法可以与 kubernetes 或 docker swarm 等编排器凝视，并以手动结束在单独的Docker守护程序上启动。使用协调器，可以在不同主机之间共享相同的卷，但是在这种情况下，您不能使用 bind mount ，而使用 volumes 。
It depends. Running images on different machines can be achieved in different ways, staring with orchestrators like kubernetes or docker swarm and ending with manual launch on separate docker daemons. With orchestrators it is possible to have same volume, shared among different hosts, but in this case you can't use bind mounts, you use volumes.
在进行开发和生产设置后，Docker如何为每个环境管理两个
单独的卷？
When I have developement and production setup, how docker manages two separate volumes for each environment?
Docker是由您管理的人。
Docker doesn't it is you who manages.
除了当我使用数据卷时通过docker-compose
看起来很容易丢失数据之外，这是第一个障碍
犹豫不决地使用数据量，是否有明显的解决方案来缓解
的问题？
Besides it seems fairly easy to lose data by doing docker-compose down when I use data volumes, that's the first obstacle that makes me to hesitate to use data volumes, is there an obvious solution to mitigate the issue?
卷可以轻松地在 docker-compose 会话之间持续存在。最明确的实现方法是预先声明音量
Volumes can easily persist between docker-compose sessions. The most explicit way to achieve that is to declare volume in advance with
docker volume create foo
，然后在撰写文件中使用它：
and then use it in your compose files:
version: '3'
services:
abc:
volumes:
foo:/foo
volumes:
foo:
external: true
这篇关于Docker，Volumes与Bind Mounts之间的持久数据，例如DB，elasticsearch？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
