内容简介:之前我们都说过,容器间是独立存储的,并且容器内部的修改是没有被持久化的。在前一篇中,我们就说过,容器的运行是在image外面套了个容器层,每次修改都是在容器层进行修改,并不修改到内部的image,所以在容器停止的时候,修改也就消失了。那么比如我在一个容器里面运行一个应用,他的数据库也在该容器中的话,如果这个容器被意外的停止了,那么数据消失了,这肯定不是我们想看到的。再比如两三个应用分别跑在各自的容器里面,但是他们的数据是相通的,也就是要求他们使用的是同一个数据库,那这该怎么弄呢?
引入持久化volume
之前我们都说过,容器间是独立存储的,并且容器内部的修改是没有被持久化的。
在前一篇中,我们就说过,容器的运行是在image外面套了个容器层,每次修改都是在容器层进行修改,并不修改到内部的image,所以在容器停止的时候,修改也就消失了。
那么比如我在一个容器里面运行一个应用,他的数据库也在该容器中的话,如果这个容器被意外的停止了,那么数据消失了,这肯定不是我们想看到的。再比如两三个应用分别跑在各自的容器里面,但是他们的数据是相通的,也就是要求他们使用的是同一个数据库,那这该怎么弄呢?
这就要引入今天要讲的持久化volume。
怎么玩volume
我们先以守护进程的方式启动一个进程,然后将里面的某个虚拟地址映射到本机的某个实际地址,具体命令如下。
我们启动完之后,用docker inspect 命令来查看某容器的详细信息。由于信息太多,我只截取了部分,将就着看看。
我们来看一下宿主机的路径和容器内部的路径指的是不是同一内存。
首先,我们先看一下宿主机的路径,并查看他的index.html文件,很明显这是nginx的欢迎页面。
然后我们修改一下这个文件,改为“我是修改的哈”,查看一下,的确是改好啦的。
接着,我们到容器里面看一下index.html,发现他也被修改啦。
那我们换个方向,先在容器里面修改,再到本机实际的地址看一下,发现实际地址也被修改啦。
具体原理
下面来说一下理由是什么?咱来图说的清楚点。
容器中的地址其实并不真实的物理路径,而是虚拟路径。当我们第一次修改实际路径的时候,其实修改了实际路径中的物理地址中的内容,当我们从容器内部去查看这个内容的时候,他其实也就是从实际路径中获取了内容,即实际路径中的物理地址中的内容。反之,也是一样的。所以总的来说,他们指向的是同一片内存。
长按下图二维码,即刻关注【学习 Java 的小姐姐】 领取超多学习资料哦!
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
图解服务器端网络架构
[日] 宫田宽士 / 曾薇薇 / 人民邮电出版社 / 2015-4 / 79.00元
本书以图配文,详细说明了服务器端网络架构的基础技术和设计要点。基础设计是服务器端网络架构最重要的一个阶段。本书就立足于基础设计的设计细分项目,详细介绍各细分项目的相关技术和设计要点。全书共分为5章,分别讲述进行物理设计、逻辑设计、安全设计和负载均衡设计、高可用性设计以及管理设计时所必需的技术和设计要点。一起来看看 《图解服务器端网络架构》 这本书的介绍吧!