您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
Docker--image分析
 
313 次浏览     评价:  
 2018-4-13 
 
编辑推荐:
本文来自于csdn,主要为大家讲解了docker image的意义,docker image存储位置以及储存形式。

docker image是什么,存储在什么位置。

本文回答两个问题:

1. docker image是什么。

2. docker image存储在哪里,以什么形式存储。

1. docker image是什么

image 里面是一层层文件系统,叫做 Union FS(联合文件系统)。联合文件系统,可以将几层目录挂载到一起,形成一个虚拟文件系统。虚拟文件系统的目录结构就像普通 linux 的目录结构一样,docker 通过这些文件再加上宿主机的内核提供了一个 linux 的虚拟环境。每一层文件系统我们叫做一层 layer,联合文件系统可以对每一层文件系统设置三种权限,只读(readonly)、读写(readwrite)和写出(whiteout-able),但是 docker 镜像中每一层文件系统都是只读的。

构建镜像的时候,从一个最基本的操作系统开始,每个构建的操作都相当于做一层的修改,增加了一层文件系统。一层层往上叠加,上层的修改会覆盖底层该位置的可见性,这也很容易理解,就像上层把底层遮住了一样。当你使用的时候,你只会看到一个完全的整体,你不知道里面有几层,也不清楚每一层所做的修改是什么。结构类似这样:

从基本的看起,一个典型的 Linux 文件系统由 bootfs 和 rootfs 两部分组成,bootfs(boot file system) 主要包含bootloader 和 kernel,bootloader 主要用于引导加载 kernel,当 kernel 被加载到内存中后 bootfs 会被 umount 掉。rootfs (root file system) 包含的就是典型 Linux 系统中的/dev,/proc,/bin,/etc 等标准目录和文件。下图就是 docker image 中最基础的两层结构,不同的 linux 发行版(如 ubuntu 和 CentOS ) 在 rootfs 这一层会有所区别,体现发行版本的差异性。

传统的 Linux 加载 bootfs 时会先将 rootfs 设为 read-only,然后在系统自检之后将 rootfs 从 read-only 改为 read-write,然后我们就可以在 rootfs 上进行读写操作了。但 Docker 在 bootfs 自检完毕之后并不会把 rootfs 的 read-only 改为 read-write,而是利用 union mount(UnionFS 的一种挂载机制)将 image 中的其他的 layer 加载到之前的 read-only 的 rootfs层之上,每一层 layer 都是 rootfs 的结构,并且是read-only 的。所以,我们是无法修改一个已有镜像里面的 layer 的!只有当我们创建一个容器,也就是将 Docker 镜像进行实例化,系统会分配一层空的 read-write 的 rootfs ,用于保存我们做的修改。一层 layer 所保存的修改是增量式的,就像 git 一样。

综上,image其实就是一个文件系统,它与宿主机的内核一起为程序提供一个虚拟的linux环境。在启动docker container时,依据image,docker会为container构建出一个虚拟的linux环境。

2. docker image存储在哪里,以什么形式存储。

当运行sudo docker pull ubuntu命令,从Docker HUB上下载一个ubuntu image后,这个image存储在宿主机的什么位置,以什么形式存储的呢。下面我们一步步来揭开这个答案。

Docker目前支持五种镜像层次的存储driver:aufs、device mapper、btrfs、vfs、overlay。下面以aufs做介绍,这个也是我们系统上用的。

下载一个ubuntu image,修改tag为xuzw,删除其他所有镜像。

在安装docker时,默认的安装位置是/var/lib/docker。让我们看看这个目录下面都有什么。

repositories-aufs:记录了镜像名称以及对应的Id的json文件,

graph:保存的是下载镜像的元数据,包括json和layersize,其中json文件记录了相应的image id、依赖关系、创建时间和配置信息等。layersize为对应层的大小。进入graph文件会发现下面包含着多个文件夹,其中有一个是以我们下载的镜像命名的文件夹ca4……,进入这个文件夹,可以看到json和layersize文件。

json文件内容部分截图如下,layersize显示为0。怎么会为0呢,不用着急,这一层为0,不表示镜像大小就是0。Graph存储镜像时,是分层存储的,graph目录下多出的文件夹其实都对应一个layer。这些layer都与我们的镜像名命名的layer有关联,关系就记录在json文件中。

从这个json文件中,可以看到起父镜像或者上一层镜像就是a46……,graph目录下也存储着这一层的信息。再往下看,可以看到层次关系是:ca4--> a46--> ea3- -> 233。

在graph这个目录里并没有找到我们想找到的镜像内容存放地。graph目录下只是一些镜像相关的信息数据。由上一节我们已经知道,image应该包含一个类似linux的文件系统才对。

containers:这个下面记录的是容器相关的信息,每运行一个容器,就在这个目录下面生成一个容器Id对应的子目录,如下图。

init:保存的是docker init相关的信息。

tmp:是一个空目录,具体起什么作用还不清楚。

volumes:与docker的数据券相关,在此不进行扩展。

现在就只剩下aufs这个目录没有看了,进入aufs这个目录。

mnt是aufs的挂载目录,diff是实际数据来源,也就是我们image实际存储的地方,包括只读层和可读写层,所有这些层最终都一起挂载到mmt所在的目录。layers下为每层依赖有关的描述文件。

在diff、mnt、layers下面有6个文件或子目录,但是从graph目录下看我们的image应该是4层,为什么会多出来2个呢。仔细观察多出来的来个文件或者子目录,会发现其名称和容器Id一致,且有一个包含init。这是为什么呢?

其实,在容器启动之前,mnt和layers都是空目录,diff下面也只有graph目录下我们看到的镜像层对应的4个目录。

在Docker利用image启动一个容器时,会在aufs下新建容器id对应的文件和子目录,同时在镜像的可读层执行新建一个可读写的layer。至于id-init文件或者子目录记录的都是与容器内环境相关的信息,与镜像无关。

既然我们现在已经知道了镜像实际是存储在diff目录下的,那么我们就看看diff目录下各个子目录中的内容。依照镜像的层次关系ca4--> a46--> ea3- -> 233查看。

最终我们看到linux一样的文件系统。已表示image确实是存储在diff目录下的。综上,docker image最终是存储在在/var/lib/docker/aufs/diff中的,同时在graph中有有关进行的记录。在容器启动时,diff下的可读层image和新增的可读写层“容器Id”都将挂载到mmt目录下以容器id命名的子目录下。

   
314 次浏览  评价: 差  订阅 捐助
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号