理解Docker镜像分层

原文:理解Docker镜像分层

关于base镜像

base 镜像有两层含义:

  • 不依赖其他镜像,从 scratch 构建。
  • 其他镜像可以之为基础进行扩展。

所以,能称作 base 镜像的通常都是各种 Linux 发行版的 Docker 镜像,比如 Ubuntu, Debian, CentOS 等。

base 镜像提供的是最小安装的 Linux 发行版

我们大部分镜像都将是基于base镜像构建的。所以,通常使用的是官方发布的base镜像。可以在docker hub里找到。比如centos: https://hub.docker.com/_/centos

点击版本可以看到github里的Dockerfile

FROM scratch
ADD centos-7-docker.tar.xz /

LABEL org.label-schema.schema-version="1.0"     org.label-schema.name="CentOS Base Image"     org.label-schema.vendor="CentOS"     org.label-schema.license="GPLv2"     org.label-schema.build-date="20181205"

CMD ["/bin/bash"]

ADD命令将本地的centos7的tar包添加到镜像,并解压到根目录/下。生成/dev,/proc/,/bin等。

我们可以自己构建docker base镜像,也可以直接使用已有的base镜像。比如centos。我们可以直接从docker hub上拉取。

拉取

docker pull centos

查看

# docker images centos
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos              latest              1e1148e4cc2c        2 months ago        202MB

可以看到最新的centos镜像只有200mb,是不是觉得太小了?这是因为docker镜像在运行的时候直接使用docker宿主机器的kernel。

Linux操作系统由内核空间和用户空间组成。

内核空间是kernel,用户空间是rootfs, 不同Linux发行版的区别主要是rootfs.比如 Ubuntu 14.04 使用 upstart 管理服务,apt 管理软件包;而 CentOS 7 使用 systemd 和 yum。这些都是用户空间上的区别,Linux kernel 差别不大。

所以 Docker 可以同时支持多种 Linux 镜像,模拟出多种操作系统环境。

需要注意的是:

  • base镜像只是用户空间和发行版一致。kernel使用的是docker宿主机器的kernel。例如 CentOS 7 使用 3.x.x 的 kernel,如果 Docker Host 是 Ubuntu 16.04(比如我们的实验环境),那么在 CentOS 容器中使用的实际是是 Host 4.x.x 的 kernel。

  • ① Host kernel 为 4.4.0-31
  • ② 启动并进入 CentOS 容器
  • ③ 验证容器是 CentOS 7
  • ④ 容器的 kernel 版本与 Host 一致

关于存储结构(About storage drivers)

上文里展示了如何下载一个base镜像。我们通常是基于这份base镜像来构建我们自己的镜像。比如,在centos里添加一个nginx负载均衡。首先,得需要了解镜像的结构是什么。

官方文档: https://docs.docker.com/storage/storagedriver/

先来创建一个自己的镜像

首先,base镜像是基于docker宿主机器kernel之上的Linux发行版。

现在,我们给这台机器安装一个vim,一个httpd. 基于Dockerfile来创建一个新的镜像。

我们的Dockerfile

FROM centos:7
RUN yum install -y vim
RUN yum install -y httpd
CMD ["/bin/bash"]

含义:

  • 基于centos7的base镜像构建
  • 安装vim
  • 安装httpd
  • 执行bash

在当前目录下新建一个文件Dockerfile, 填充上述内容。然后执行

# docker build -t ryan/httpd:v1.0 .
Sending build context to Docker daemon  6.144kB
Step 1/4 : FROM centos:7
 ---> 1e1148e4cc2c
Step 2/4 : RUN yum install -y vim
 ---> Using cache
 ---> 74bdbea98f73
Step 3/4 : RUN yum install -y httpd
 ---> Using cache
 ---> 17d8c4095dc4
Step 4/4 : CMD /bin/bash
 ---> Using cache
 ---> f2b58b1192de
Successfully built f2b58b1192de
Successfully tagged ryan/httpd:latest
  • -t 指定我们创建的镜像名称,镜像名称可以用组织/id:version的方式标记
  • 最后一个参数是Dockerfile所在的路径., 表示当前目录

然后我们添加一个tag latest

docker tag ryan/httpd:v1.0 ryan/httpd:latest
  • 即给镜像ryan/httpd:v1.0标记为ryan/httpd:latest

构建完成之后,查看

# docker images  | grep -E '(ryan|centos)'
ryan/httpd                                                               latest                     f2b58b1192de        About an hour ago   444MB
ryan/httpd                                                               v1.0                       f2b58b1192de        About an hour ago   444MB
centos                                                                   7                          1e1148e4cc2c        2 months ago        202MB
centos                                                                   latest                     1e1148e4cc2c        2 months ago        202MB

可以运行我们创建的镜像:

# docker run -d  --privileged=true -it ryan/httpd:v1.0 /usr/sbin/init
48a4a128cd7b6924149cd97670919d4e2af6cb96c73c901af60d05fe4478225a
# docker ps | grep ryan
48a4a128cd7b        ryan/httpd:v1.0                                                          "/usr/sbin/init"         8 seconds ago       Up 8 seconds       

现在我们的基于原生base centos7的httpd服务器已经启动了。可以通过docker exec -it zealous_kirch /bin/bash来进入容器内部,查看启动httpd。

docker镜像的分层结构

我们可以查看镜像的历史,用上一步的镜像id f2b58b1192de

# docker history f2b58b1192de
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
f2b58b1192de        About an hour ago   /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
17d8c4095dc4        About an hour ago   /bin/sh -c yum install -y httpd                 110MB
74bdbea98f73        About an hour ago   /bin/sh -c yum install -y vim                   133MB
1e1148e4cc2c        2 months ago        /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
<missing>           2 months ago        /bin/sh -c #(nop)  LABEL org.label-schema....   0B
<missing>           2 months ago        /bin/sh -c #(nop) ADD file:6f877549795f479...   202MB   

启动镜像的时候,一个新的可写层会加载到镜像的顶部。这一层通常称为“容器层”, 之下是“镜像层”。

容器层可以读写,容器所有发生文件变更写都发生在这一层。镜像层read-only,只允许读取。

(上图来自官方文档,和本次实验内容略有不同,但原理一样)

第一列是imageid, 最上面的id就是我们新创建ryan/httpd:latest. 下面几行都是我们dockerfile里定义的步骤堆栈。由此可以看出,每个步骤都将创建一个imgid, 一直追溯到1e1148e4cc2c正好是我们的base镜像的id。关于<missing>的部分,则不在本机上。

最后一列是每一层的大小。最后一层只是启动bash,所以没有文件变更,大小是0. 我们创建的镜像是在base镜像之上的,并不是完全复制一份base,然后修改,而是共享base的内容。这时候,如果我们新建一个新的镜像,同样也是共享base镜像。

那修改了base镜像,会不会导致我们创建的镜像也被修改呢? 不会!因为不允许修改历史镜像,只允许修改容器,而容器只可以在最上面的容器层进行写和变更。

容器的大小

创建镜像的时候,分层可以让docker只保存我们添加和修改的部分内容。其他内容基于base镜像,不需要存储,读取base镜像即可。如此,当我们创建多个镜像的时候,所有的镜像共享base部分。节省了磁盘空间。

对于启动的容器,查看所需要的磁盘空间可以通过docker ps -s

# docker run -d -it centos
4b0df4bc3e705c540144d545441930689124ade087961d01f56c2ac55bfd986d
# docker ps -s | grep -E '(ryan|centos)'
4b0df4bc3e70        centos                                                                   "/bin/bash"              23 seconds ago      Up 23 seconds                           vigorous_elion                                                                                                                           0B (virtual 202MB)
b36421d05005        ryan/httpd:v1.0                                                          "/usr/sbin/init"         32 minutes ago      Up 32 minutes                           gracious_swirles                                                                                                                         61.6kB (virtual 444MB)
  • 首先启动一个base镜像用来对比
  • 可以看到第一行就是base镜像centos,第2列的size是0和202MB, 0表示容器层可写层的大小,virtual则是容器层+镜像层的大小。这里对比可以看到一共202M,正好是最初centos镜像的大小。
  • 第二行是我们自己创建的镜像。virtual达到了444MB。对比前面的history部分,可以发现这个数字是每一层大小之和。同时,由于共享base,其中的202M是和第一行的镜像共享的。

修改时复制策略 copy-on-write (CoW)

docker通过一个叫做copy-on-write (CoW) 的策略来保证base镜像的安全性,以及更高的性能和空间利用率。

Copy-on-write is a strategy of sharing and copying files for maximum efficiency. If a file or directory exists in a lower layer within the image, and another layer (including the writable layer) needs read access to it, it just uses the existing file. The first time another layer needs to modify the file (when building the image or running the container), the file is copied into that layer and modified. This minimizes I/O and the size of each of the subsequent layers. These advantages are explained in more depth below.

Copying makes containers efficient

When you start a container, a thin writable container layer is added on top of the other layers. Any changes the container makes to the filesystem are stored here. Any files the container does not change do not get copied to this writable layer. This means that the writable layer is as small as possible.

When an existing file in a container is modified, the storage driver performs a copy-on-write operation. The specifics steps involved depend on the specific storage driver. For the aufs, overlay, and overlay2 drivers, the copy-on-write operation follows this rough sequence:

Search through the image layers for the file to update. The process starts at the newest layer and works down to the base layer one layer at a time. When results are found, they are added to a cache to speed future operations.

Perform a copy_up operation on the first copy of the file that is found, to copy the file to the container’s writable layer.

Any modifications are made to this copy of the file, and the container cannot see the read-only copy of the file that exists in the lower layer.

Btrfs, ZFS, and other drivers handle the copy-on-write differently. You can read more about the methods of these drivers later in their detailed descriptions.

Containers that write a lot of data consume more space than containers that do not. This is because most write operations consume new space in the container’s thin writable top layer.

简单的说,启动容器的时候,最上层容器层是可写层,之下的都是镜像层,只读层。

当容器需要读取文件的时候

从最上层镜像开始查找,往下找,找到文件后读取并放入内存,若已经在内存中了,直接使用。(即,同一台机器上运行的docker容器共享运行时相同的文件)。

当容器需要添加文件的时候

直接在最上面的容器层可写层添加文件,不会影响镜像层。

当容器需要修改文件的时候

从上往下层寻找文件,找到后,复制到容器可写层,然后,对容器来说,可以看到的是容器层的这个文件,看不到镜像层里的文件。容器在容器层修改这个文件。

当容器需要删除文件的时候

从上往下层寻找文件,找到后在容器中记录删除。即,并不会真正的删除文件,而是软删除。这将导致镜像体积只会增加,不会减少。

综上,Docker镜像通过分层实现了资源共享,通过copy-on-write实现了文件隔离。

对于文件只增加不减少问题,我们应当在同一层做增删操作,从而减少镜像体积。比如,如下测试。

Dockerfile.A: 分层删除文件

FROM centos:7
RUN yum install -y vim
RUN yum install -y httpd
WORKDIR /home
RUN dd if=/dev/zero of=50M.file bs=1M count=50
#创建大小为50M的测试文件
RUN rm -rf 50M.file
CMD ["/bin/bash"]

构建

docker build -t test:a -f Dockerfile.A .

Dockerfile.B: 同层删除

FROM centos:7
RUN yum install -y vim
RUN yum install -y httpd
WORKDIR /home
RUN dd if=/dev/zero of=50M.file bs=1M count=50 && rm -rf 50M.file

构建

docker build -t test:b -f Dockerfile.B .

比较二者大小


[root@sh-k8s-001 tmp]# docker images | grep test
test                                                                     a                          ae673aa7db48        9 minutes ago       497MB
test                                                                     b                          21b2bc49f0bd        12 minutes ago      444MB

显然,分层删除操作并没有真正删除掉文件。

来源

  • https://www.cnblogs.com/CloudMan6/p/6799197.html
  • https://www.cnblogs.com/CloudMan6/p/6806193.html
  • https://docs.docker.com/storage/storagedriver/

原文地址:https://www.cnblogs.com/lonelyxmas/p/10373090.html

时间: 2024-10-08 02:27:42

理解Docker镜像分层的相关文章

深刻理解Docker镜像大小

都说容器大法好,可是假设没有Docker镜像,Docker该是多无趣啊. 是否还记得第一个接触Docker的时候,你从Docker Hub下拉的那个镜像呢?在那个处女镜像的基础上.你执行了容器生涯的处女容器.镜像的基石作用已经非常明显.在Docker的世界里,能够说是:No Image,No Container. 再进一步思考Docker镜像,大家可能非常快就会联想到下面几类镜像: 1.系统级镜像:如Ubuntu镜像.CentOS镜像以及Debian容器等: 2.工具栈镜像:如Golang镜像.

Docker(一):理解Docker镜像与容器

一.镜像的概念 1.广泛镜像概念: 镜像是一种文件存储形式,是冗余的一种类型,一个磁盘上的数据在另一个磁盘上存在完全相同的副本即为镜像. 2.Docker镜像概念: 在Docker中镜像同样是一种完全相同的副本,以广泛的镜像来理解就很简单了,Docker虽然在Linux系统中,但是内部又完全和Linux系统隔开.所以我们可用Docker来将自己的项目构建成镜像.相当于把自己的项目代码复制一份到Docker系统里. 二.如何解决项目运行时所需的生产环境 问题很快产生,在Linux中已经安装好的运行

06: docker镜像分层

docker分层 docker镜像的分层(使用的是kvm 链接克隆,写时复制的特性) 1:分层的好处:重复利用,节约资源 2:镜像越大,迁移时间越长:并且你如果使用docker做集群,那么如果镜像太大, 有变化,每个更新的话,都需要很长时间.所以最好是镜像分2-3层(基础系统-应用服务-代码),集群采预与下载. 查看分层镜像信息:(请注意missing - ) [[email protected] ~]# docker history centos_ssh:v1.2 (--no-trunc) I

Docker镜像分层结构剖析

总结: 共享资源 对容器的任何改动都是发生容器层 容器层是可写可读,而镜像层只读 原文地址:https://www.cnblogs.com/weisunblog/p/12235578.html

docker的架构,镜像分层特性,dockerfile缓存特性

Docker网站:https://hub.docker.com/?Docker镜像分层的概念:Docker的最小镜像下载镜像(dockerfile的组成)docker pull hello-world Dockerfile的组成1.>FROM:scratch 抓,挠(从零开始构建)2>COPY: hello /3>CMD: ["/hello"] Base镜像(基础镜像) > ***个人理解: > 用户空间:rootfs > 内核空间 :bootfs

理解Docker(2):Docker 镜像

对于每个软件,除了它自身的代码以外,它的运行还需要有一个运行环境和依赖.不管这个软件是象往常一样运行在物理机或者虚机之中,还是运行在现在的容器之中,这些都是不变的.在传统环境中,软件在运行之前也需要经过 代码开发->运行环境准备 -> 安装软件 -> 运行软件 等环节,在容器环境中,中间的两个环节被镜像制作过程替代了.也就是说,镜像的制作也包括运行环境准备和安装软件等两个主要环节,以及一些其他环节.因此,Docker 容器镜像其实并没有什么新的理论,只是这过程有了新的方式而已. 镜像(i

Docker 镜像之存储管理

笔者在<Docker 镜像之进阶篇>中介绍了镜像分层.写时复制以及内容寻址存储(content-addressable storage)等技术特性,为了支持这些特性,docker 设计了一套镜像元数据管理机制来管理镜像元数据.另外,为了能够让 docker 容器适应不同平台不同应用场景对存储的要求,docker 提供了各种基于不同文件系统实现的存储驱动来管理实际镜像文件. 本文我们就来介绍 docker 如何管理镜像元数据,以及如何通过存储驱动来管理实际的容器镜像文件. Docker 镜像元数

Docker源码分析(九):Docker镜像

1.前言 回首过去的2014年,大家可以看到Docker在全球刮起了一阵又一阵的“容器风”,工业界对Docker的探索与实践更是一波高过一波.在如今的2015年以及未来,Docker似乎并不会像其他昙花一现的技术一样,在历史的舞台上热潮褪去,反而在工业界实践与评估之后,显现了前所未有的发展潜力. 究其本质,“Docker提供容器服务”这句话,相信很少有人会有异议.那么,既然Docker提供的服务属于“容器”技术,那么反观“容器”技术的本质与历史,我们又可以发现什么呢?正如前文所提到的,Docke

10张图带你深入理解Docker容器和镜像

图解Docker容器和镜像 这篇文章希望能够帮助读者深入理解Docker的命令,还有容器(container)和镜像(image)之间的区别,并深入探讨容器和运行中的容器之间的区别. 当我对Docker技术还是一知半解的时候,我发现理解Docker的命令非常困难.于是,我花了几周的时间来学习Docker的工作原理,更确切地说,是关于Docker统一文件系统(the union file system)的知识,然后回过头来再看Docker的命令,一切变得顺理成章,简单极了. 题外话:就我个人而言,