内容简介：之前我们都说过，容器间是独立存储的，并且容器内部的修改是没有被持久化的。在前一篇中，我们就说过，容器的运行是在image外面套了个容器层，每次修改都是在容器层进行修改，并不修改到内部的image，所以在容器停止的时候，修改也就消失了。那么比如我在一个容器里面运行一个应用，他的数据库也在该容器中的话，如果这个容器被意外的停止了，那么数据消失了，这肯定不是我们想看到的。再比如两三个应用分别跑在各自的容器里面，但是他们的数据是相通的，也就是要求他们使用的是同一个数据库，那这该怎么弄呢？
引入持久化volume
之前我们都说过，容器间是独立存储的，并且容器内部的修改是没有被持久化的。
在前一篇中，我们就说过，容器的运行是在image外面套了个容器层，每次修改都是在容器层进行修改，并不修改到内部的image，所以在容器停止的时候，修改也就消失了。
那么比如我在一个容器里面运行一个应用，他的数据库也在该容器中的话，如果这个容器被意外的停止了，那么数据消失了，这肯定不是我们想看到的。再比如两三个应用分别跑在各自的容器里面，但是他们的数据是相通的，也就是要求他们使用的是同一个数据库，那这该怎么弄呢？
这就要引入今天要讲的持久化volume。
怎么玩volume
我们先以守护进程的方式启动一个进程，然后将里面的某个虚拟地址映射到本机的某个实际地址，具体命令如下。
我们启动完之后，用docker inspect 命令来查看某容器的详细信息。由于信息太多，我只截取了部分，将就着看看。
我们来看一下宿主机的路径和容器内部的路径指的是不是同一内存。
首先，我们先看一下宿主机的路径，并查看他的index.html文件，很明显这是nginx的欢迎页面。
然后我们修改一下这个文件，改为“我是修改的哈”，查看一下，的确是改好啦的。
接着，我们到容器里面看一下index.html，发现他也被修改啦。
那我们换个方向，先在容器里面修改，再到本机实际的地址看一下，发现实际地址也被修改啦。
具体原理
下面来说一下理由是什么？咱来图说的清楚点。
容器中的地址其实并不真实的物理路径，而是虚拟路径。当我们第一次修改实际路径的时候，其实修改了实际路径中的物理地址中的内容，当我们从容器内部去查看这个内容的时候，他其实也就是从实际路径中获取了内容，即实际路径中的物理地址中的内容。反之，也是一样的。所以总的来说，他们指向的是同一片内存。
长按下图二维码，即刻关注【学习 Java 的小姐姐】 领取超多学习资料哦！
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Getting Started with C++ Audio Programming for Game Development
David Gouveia
Written specifically to help C++ developers add audio to their games from scratch, this book gives a clear introduction to the concepts and practical application of audio programming using the FMOD li......一起来看看 《Getting Started with C++ Audio Programming for Game Development》 这本书的介绍吧!
