这篇文章主要讲讲 docker 中镜像有关的知识,将涉及到下面几个方面:
docker images 命令的使用
docker 和 registry 交互的过程,pull 命令到底做了什么
docker storage driver
aufs 的格式和实际的组织结构
Dockerfile 原语和 docker 镜像之间的关系
作者:cizixs 时间:2016-04-06 原文链接: https://cizixs.com/2016/04/06/docker-images/
简介
docker 镜像代表了容器的文件系统里的内容,是容器的基础,镜像一般是通过 Dockerfile 生成的
docker 的镜像是分层的,所有的镜像(除了基础镜像)都是在之前镜像的基础上加上自己这层的内容生成的
每一层镜像的元数据都是存在 json 文件中的,除了静态的文件系统之外,还会包含动态的数据
使用镜像:docker image 命令
docker client 提供了各种命令和 daemon 交互,来完成各种任务,其中和镜像有关的命令有:
docker images
:列出 docker host 机器上的镜像,可以使用-f
进行过滤docker build
:从 Dockerfile 中构建出一个镜像docker history
:列出某个镜像的历史dockerimport
:从 tarball 中创建一个新的文件系统镜像docker pull
:从 docker registry 拉去镜像docker push
:把本地镜像推送到 registrydocker rmi
:删除镜像docker save
:把镜像保存为 tar 文件docker search
:在 docker hub 上搜索镜像docker tag
:为镜像打上 tag 标记
从上面这么多命令中,我们就可以看出来,docker 镜像在整个体系中的重要性。
下载镜像:pull 和 push 镜像到底在做什么?
如果了解 docker 结构的话,你会知道 docker 是典型的 C/S 架构。平时经常使用的 docker pull
, docker run
都是客户端的命令,最终这些命令会发送到 server 端(docker daemon 启动的时候会启动docker server)进行处理。下载镜像还会和 Registry 打交道,下面我们就说说使用 docker pull
的时候,docker 到底在做些什么!
docker client 组织配置和参数,把 pull 指令发送给 docker server,server 端接收到指令之后会交给对应的 handler。handler 会新开一个 CmdPull job 运行,这个 job 在 docker daemon 启动的时候被注册进来,所以控制权就到了 docker daemon 这边。docker daemon 是怎么根据传过来的 registry 地址、repo 名、image 名和tag 找到要下载的镜像呢?具体流程如下:
获取 repo 下面所有的镜像 id:
GET/repositories/{repo}/images
获取 repo 下面所有 tag 的信息:
GET/repositories/{repo}/tags
根据 tag 找到对应的镜像 uuid,并下载该镜像
获取该镜像的 history 信息,并依次下载这些镜像层:
GET/images/{image_id}/ancestry
如果这些镜像层已经存在,就 skip,不存在的话就继续
获取镜像层的 json 信息:
GET/images/{image_id}/json
下载镜像内容:
GET/images/{image_id}/layer
下载完成后,把下载的内容存放到本地的 UnionFS 系统
在 TagStore 添加刚下载的镜像信息
存储镜像:docker storage 介绍
在上一个章节提到下载的镜像会保存起来,这一节就讲讲到底是怎么存的。
UnionFS 和 aufs
如果对 docker 有所了解的话,会听说过 UnionFS 的概念,这是 docker 实现层级镜像的基础。在 wikipedia 是这么解释的:
Unionfs is a filesystem service for Linux, FreeBSD and NetBSD which implements a union mount for other file systems. It allows files and directories of separate file systems, known as branches, to be transparently overlaid, forming a single coherent file system. Contents of directories which have the same path within the merged branches will be seen together in a single merged directory, within the new, virtual filesystem.
简单来说,就是用多个文件夹和文件(这些是系统文件系统的概念)存放内容,对上(应用层)提供虚拟的文件访问。比如 docker 中有镜像的概念,应用层看来只是一个文件,可以读取、删除,在底层却是通过 UnionFS 系统管理各个镜像层的内容和关系。
docker 负责镜像的模块是 Graph
,对上提供一致和方便的接口,在底层通过调用不同的 driver 来实现。常用的 driver 包括 aufs、devicemapper,这样的好处是:用户可以选择甚至实现自己的 driver。
aufs 镜像在机器上的存储结构
NOTE:
只下载了 ubuntu:14.04 镜像
docker version:1.6.3
image driver:aufs
使用 docker history 查看镜像历史:
可以看到,ubuntu:14.04 一共有五层镜像。aufs 数据存放在 /var/lib/docker/aufs 目录下:
root@cizixs-ThinkPad-T450:/var/lib/docker/aufs# tree -L 1
.
├── diff
├── layers
└── mnt
一共有三个文件夹,每个文件夹下面都是以镜像 id 命令的文件夹,保存了每个镜像的信息。先来介绍一下这三个文件夹
layers:显示了每个镜像有哪些层构成
diff:每个镜像的和之前镜像的区别,就是这一层的内容
mnt:UnionFS 对外提供的 mount point,因为 UnionFS 底层是多个文件夹和文件,对上层要提供统一的文件服务,是通过 mount 的形式实现的。每个运行的容器都会在这个目录下有一个文件夹
比如 diff 文件夹是这样的:
root@cizixs-ThinkPad-T450:/var/lib/docker/aufs# ls diff/2d24f826cb16146e2016ff349a8a33ed5830f3b938d45c0f82943f4ab8c097e7/
root@cizixs-ThinkPad-T450:/var/lib/docker/aufs# ls diff/117ee323aaa9d1b136ea55e4421f4ce413dfc6c0cc6b2186dea6c88d93e1ad7c/
etc
root@cizixs-ThinkPad-T450:/var/lib/docker/aufs# ls diff/1c8294cc516082dfbb731f062806b76b82679ce38864dd87635f08869c993e45/
etc sbin usr var
root@cizixs-ThinkPad-T450:/var/lib/docker/aufs# ls diff/fa4fd76b09ce9b87bfdc96515f9a5dd5121c01cc996cf5379050d8e13d4a864b/
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root@cizixs-ThinkPad-T450:/var/lib/docker/aufs# ls diff/511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/
除了这些实际的数据之外,docker 还为每个镜像层保存了 json 格式的元数据,存储在 /var/lib/docker/graph//json
,比如:
root@cizixs-ThinkPad-T450:/var/lib/docker# cat graph/2d24f826cb16146e2016ff349a8a33ed5830f3b938d45c0f82943f4ab8c097e7/json | jq '.'
{
"id": "2d24f826cb16146e2016ff349a8a33ed5830f3b938d45c0f82943f4ab8c097e7",
"parent": "117ee323aaa9d1b136ea55e4421f4ce413dfc6c0cc6b2186dea6c88d93e1ad7c",
"created": "2015-02-21T02:11:06.735146646Z",
"container": "c9a3eda5951d28aa8dbe5933be94c523790721e4f80886d0a8e7a710132a38ec",
"container_config": {
"Hostname": "43bd710ec89a",
"Domainname": "",
"User": "",
"Memory": 0,
"MemorySwap": 0,
"CpuShares": 0,
"Cpuset": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"PortSpecs": null,
"ExposedPorts": null,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh",
"-c",
"#(nop) CMD [/bin/bash]"
],
"Image": "117ee323aaa9d1b136ea55e4421f4ce413dfc6c0cc6b2186dea6c88d93e1ad7c",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": [],
"Labels": null
},
"docker_version": "1.4.1",
"config": {
"Hostname": "43bd710ec89a",
"Domainname": "",
"User": "",
"Memory": 0,
"MemorySwap": 0,
"CpuShares": 0,
"Cpuset": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"PortSpecs": null,
"ExposedPorts": null,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/bash"
],
"Image": "117ee323aaa9d1b136ea55e4421f4ce413dfc6c0cc6b2186dea6c88d93e1ad7c",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false,
"MacAddress": "",
"OnBuild": [],
"Labels": null
},
"architecture": "amd64",
"os": "linux",
"Size": 0
}
除了 json 之外,还有一个文件 /var/lib/docker/graph//layersize
保存了镜像层的大小。
创建镜像:镜像的 cache 机制
在使用 docker build
创建新的镜像的时候,docker 会使用到 cache 机制,来提高执行的效率。为了理解这个问题,我们先看一下 build 命令都做了哪些东西吧。
我们来看一个简单的 Dockerfile:
FROM ubuntu:14.04
RUN apt-get update
ADD run.sh /
VOLUME /data
CMD ["./run.sh"]
这个文件虽然简单,却包含了很多命令:RUN、ADD、VOLUME、CMD 涉及到很多概念。
一般情况下,对于每条命令,docker 都会生成一层镜像。 cache 的作用也很容易猜测,如果在构建某个镜像层的时候,发现这个镜像层已经存在了,就直接使用,而不是重新构建。这里最重要的问题在于:怎么知道要构建的镜像层已经存在了? 下面就重点解释这个问题。
docker daemon 读到 FROM
命令的时候,会在本地查找对应的镜像,如果没有找到,会从 registry 去取,当然也会取到包含 metadata 的 json 文件。然后到了 RUN
命令,如果没有 cache 的话,这个命令会做什么呢?
我们已经知道,每层镜像都是由文件系统内容和 metadata 构成的。
文件系统的内容,就是执行 apt-getupdate
命令导致的文件变动,会保存到 /var/lib/docker/aufs/diff//
,比如这里的命令主要会修改 /var/lib 和 /var/cache 下面和 apt 有关的内容:
root@cizixs-ThinkPad-T450:/var/lib/docker# tree -L 2 aufs/diff/e7ae26691ff649c55296adf7c0e51b746e22abefa6b30310b94bbb9cfa6fce63/
aufs/diff/e7ae26691ff649c55296adf7c0e51b746e22abefa6b30310b94bbb9cfa6fce63/
├── tmp
└── var
├── cache
└── lib
我们来看一下 json 文件的内容,最重要的改变就是 container_config.Cmd 变成了:
"Cmd": [
"/bin/sh",
"-c",
"apt-get update"
],
也就是说,如果下次再构建镜像的时候,我们发现新的镜像层 parent 还是 ubuntu:14.04,并且 json 文件中 cmd 要更改的内容也一致,那么就认为这两层镜像是相同的,不需要重新构建。好了,那么构建的时候,daemon 一定会遍历本地所有镜像,如果发现镜像一致就使用已经构建好的镜像。
ADD 和 COPY 文件
如果 Dockerfile 中有 ADD 或者 COPY 命令,那么怎么判断镜像是否相同呢?第一个想法肯定是文件名,但即使文件名不变,那么文件也是可以变的;那就再加上文件大小,不过两个同名并且大小相同的文件也不一定内容完全一样啊!最保险的办法就是用 hash 了,嗯!docker 就是这个干的,我们来看一下 ADD 这层镜像的 json 文件变化:
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ADD file:9fb96e5dd9ce3e03665523c164bbe775d64cc5d8cc8623fbcf5a01a63e9223ab in /"
],
看到没,ADD 的时候只有一串 hash 字符串,hash 算法的实现,如果感兴趣可以自己研究一下。
喂!这样真的就万无一失了吗?
看完上面的内容,大多数同学会觉得 cache 机制真好, 很节省时间,也能节省空间。但是这里还有一个问题,有些命令是依赖外部的,比如 apt-getupdate
或者 curl http://some.url.com/
,如果外部内容发生了改变,docker 就没有办法侦测到,去做相应的处理了。所以它提供了 --no-cache
参数来强制不要使用 cache 机制,所以说这部分内容是要用户自己维护的。
除此之外,还需要在编写 Dockerfile 的时候考虑到 cache,这一点在官方提供的 dockerfile best practice 也有提及。
运行镜像:docker 镜像和 docker 容器
我们都知道 docker 容器就是运行态的docker 镜像,但是有一个问题:docker 镜像里面保存的都是静态的东西,而容器里面的东西是动态的,那么这些动态的东西是如何管理的呢?比如说:
docker 容器里该运行哪些进程?
怎么把 docker 镜像转换成docker 容器?
docker 容器里面 ip、hostname 这些东西是如何动态生成的?
这就是上面提到的 json 文件的功能,哪些信息会存放在 json 文件呢?答案就是:除了文件系统的内容外,其他都是,比如:
ENV FOO=BAR: 环境变量,
VOLUME /some/path:容器使用的 volume,乍看上去这是文件系统的一部分,其实这部分内容不是确定的,在构建镜像的时候数据卷可以是不存在的,会在容器运行的时候动态地添加。所以这部分内容不能放到镜像层文件中
EXPOSE 80:expose 命令记录了容器运行的时候要暴露给外部的端口,这也是运行时状态,不是文件系统的一部分
CMD [“./myscript.sh”]:CMD 命令记录了 docker 容器的执行入口,这不是文件系统的一部分
好了,既然我们已经知道这些东西是怎么存储的,那么实际运行容器的时候这些内容是怎么被加载到容器里的呢?答案就是 docker daemon,这个实际管理容器实现的家伙。
我们知道,在容器实际运行过程中,每个容器就是 docker daemon 的子进程:
root 3249 0.1 6.6 985212 33288 ? Ssl 04:53 0:19 /usr/bin/docker daemon --insecure-registry 172.16.1.41:5000 --exec-opt native.cgroupdriver=cgroupfs --bip=10.12.240.1/20 --mtu=1500 --ip-masq=false
root 3597 0.0 0.1 3816 632 ? Ssl 04:55 0:00 \_ /pause
root 3633 0.0 0.1 3816 504 ? Ssl 04:55 0:00 \_ /pause
root 3695 0.0 0.1 3816 516 ? Ssl 04:55 0:00 \_ /pause
root 3710 0.0 0.1 3816 528 ? Ssl 04:55 0:00 \_ /pause
root 3745 0.0 0.1 3816 504 ? Ssl 04:55 0:00 \_ /pause
polkitd 3793 0.0 0.2 36524 1280 ? Ssl 04:55 0:07 \_ redis-server *:6379
root 3847 0.0 0.0 4184 184 ? Ss 04:55 0:00 \_ /bin/sh -c /run.sh
root 3872 0.0 0.0 17668 360 ? S 04:55 0:00 | \_ /bin/bash /run.sh
root 3873 0.0 0.3 42824 1752 ? Sl 04:55 0:01 | \_ redis-server *:6379
root 3865 0.0 1.5 166256 8024 ? Ss 04:55 0:00 \_ apache2 -DFOREGROUND
33 3881 0.0 1.0 166280 5140 ? S 04:55 0:00 | \_ apache2 -DFOREGROUND
33 3882 0.0 1.0 166280 5140 ? S 04:55 0:00 | \_ apache2 -DFOREGROUND
33 3883 0.0 1.0 166280 5140 ? S 04:55 0:00 | \_ apache2 -DFOREGROUND
33 3884 0.0 1.0 166280 5140 ? S 04:55 0:00 | \_ apache2 -DFOREGROUND
33 3885 0.0 1.0 166280 5140 ? S 04:55 0:00 | \_ apache2 -DFOREGROUND
root 3939 0.0 0.7 90264 4016 ? Ss 04:55 0:00 \_ nginx: master process nginx
33 3947 0.0 0.3 90632 1660 ? S 04:55 0:00 \_ nginx: worker process
33 3948 0.0 0.3 90632 1660 ? S 04:55 0:00 \_ nginx: worker process
33 3949 0.0 0.3 90632 1660 ? S 04:55 0:00 \_ nginx: worker process
33 3950 0.0 0.3 90632 1660 ? S 04:55 0:00 \_ nginx: worker process
也是说,docker daemon 会读取镜像的信息,作为容器的 rootfs,然后读取 json 文件中的动态信息作为运行时状态。
删除镜像:清理镜像之道
镜像是按照 UnionFS 的格式存放在本地的,删除也很容易理解,就是把对应镜像层的本地文件(夹)删除。docker 也提供了 docker rmi
这个命令来处理。
不过需要注意一点:镜像也是有“引用”这个概念的,只有当该镜像层没有被引用的时候,才能删除。“引用”就是被打上 tag,同一个 uuid 的镜像是可以被打上不同的 tag 的。我们来看一个官方提供的例子:
删除有 tag 的镜像时,会先有 untag 的操作。如果删除的镜像还有其他 tag,必须先把所有的 tag 删除后才能继续,当然你也可以使用 -f
参数来强制删除。
另外一个要注意的是:如果一个镜像有很多层,并且中间层没有被引用,那么在删除这个镜像的时候,所有没有被引用的镜像都会被删除。