为了很好的使用存储引擎,必须明白Dcoker是如何创建和存储images的。
然后要明白这些images是如何让containers使用的。最后简短介绍一些images和containers操作。
Images and layers
每个Docker image都会参照只读列表里的layers,这些layers代表不同的文件系统。
layers被堆放在顶端,以形成容器根文件系统的基础。
下图,Ubuntu15.04 image包含了4 个堆image layers.
Docker 存储引擎负责堆放这些layers,然后提供一个统一的展示。
当创建一个新的容器,将底层堆的最上层设置成可写,通常这层叫做“containers layer”
对正在运行的容器做所有的修改,比如创建新文件,修改已存在的文件,删除文件。这些操作都是在可写的容器层。
下图,展示了以Ubuntu15.04为基础的容器。
Containers and layers
容器和镜像主要的不同就是,顶层可写层。所有的修改操作都是存储在这个可写层的。
当容器被删除的时候这个可写层也就被删除了。而底层的image没有改变。
因为每个容器有自己的可写容器层,所有的更改都存储在这容器层中,这意味着多个容器可以同时使用同一个底层image。
下图显示多个容器共用Ubuntu15.04image:
docker存储引擎负责开启和管理 image 层 和可写的container 层。
存储引擎的两个关键技术:堆栈image层和copy-on-write.
Copy-on-write 策略
共享是提升资源利用率的很好途径。
copy-on-write是个很想共享和复制的策略。
- 需要相同数据的系统进程共享该数据的同一实例,而不是拥有自己的副本。
- 如果一个进程需要修改和写数据,操作系统会给这个进程复制需要的数据给它使用。
-
- 只有需要写数据的进程才有权访问复制的数据。
- 其他所有的进程继续使用原共享数据
docker在image和containers中都是用了copy-on-write技术。CoW策略优化了image
磁盘空间使用以及
容器的启动时间性能。
共享减少images空间
所有image和containers 层存在与Dcoker本地的存储空间中,都被存储引擎管理。
一般在/var/lib/docker/. 目录中。
zane@zane-V:~$ docker pull ubuntu:15.04 15.04: Pulling from library/ubuntu 9502adfba7f1: Pull complete 4332ffb06e4b: Pull complete 2f937cc07b5f: Pull complete a3ed95caeb02: Pull complete Digest: sha256:2fb27e433b3ecccea2a14e794875b086711f5d49953ef173d8a03e8707f1510f Status: Downloaded newer image for ubuntu:15.04
从上面的输出来看,实际上pull 了4个image layer.这四个image layers 组成了ubuntu:15.04 这个Dcokerimage。
这4个image layer 分别存在自己目录中,当然这些目录在Dcoker 本地的存储空间中
在docker1.10之前,存储每个layer都是以image layer ID为目录名称存储的。docker1.10之后就不是这样了。
尽管显示的方式不同,但是1.10前后都是可以共享image层的。
做些实验来说明共享image:
1.在空目录中写Dockerfile,以15.04为基础
FROM ubuntu:15.04
2.在image中 /tmp目录增加newfile,内容为"Hello world"
FROM ubuntu:15.04
RUN echo "Hello world" > /tmp/newfile
3.保存并退出文件
4.在Dockerfile文件的目录下启动命令行,并创建新image
zane@zane-V:~/mydockerbuild$ docker build -t changed-ubuntu . Sending build context to Docker daemon 2.048 kB Step 1 : FROM ubuntu:15.04 ---> d1b55fd07600 Step 2 : RUN echo "Hello world" > /tmp/newfile ---> Running in 914cfa4e2724 ---> 3a3a082982a2 Removing intermediate container 914cfa4e2724 Successfully built 3a3a082982a2
上面的输出显示新的image被创建ID:3a3a082982a2
5.运行docker image命令验证新changed-ubuntu image 已经在docker本地存储空间
zane@zane-V:~/mydockerbuild$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE changed-ubuntu latest 3a3a082982a2 3 minutes ago 131.3 MB zane/aiapple 007 d2f5f84bec87 12 days ago 275.1 MB zane/aiapple 009 d2f5f84bec87 12 days ago 275.1 MB ziapple latest d2f5f84bec87 12 days ago 275.1 MB
6.运行docker history 命令来查看创建changed-ubuntu image 时使用了哪些image 层。
zane@zane-V:~/mydockerbuild$ docker history changed-ubuntu IMAGE CREATED CREATED BY SIZE COMMENT 3a3a082982a2 6 minutes ago /bin/sh -c echo "Hello world" > /tmp/newfile 12 B d1b55fd07600 11 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B <missing> 11 months ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$/ 1.879 kB <missing> 11 months ago /bin/sh -c echo '#!/bin/sh' > /usr/sbin/polic 701 B <missing> 11 months ago /bin/sh -c #(nop) ADD file:3f4708cf445dc1b537 131.3 MB
可以看到只有3a3a082982a2 是刚创建的,且执行了我们预期的命令。而其余4个都是ubuntu.15.04 原本就有的。
可以看到他们的创建时间都是很久之前的。
注意:changed-ubuntu image并没有自己独享的每一个image层。从下图中可以看到,新image 与ubuntu15.04是共享底层的4个image的。
图片是官方例子,其实本地的3a3a082982a2,就是官方例子中的94e6b7d2c720.
可以看到docker history 还可以看到每一层的大小,我们刚刚创建的3a3a082982a2 只有12B,也就是说,我们刚刚创建了changed-ubuntu只额外占用了12B 的空间,其余都是共享的。
那么如果再以changed-ubuntu为基础image 再创建新的image呢?
重写Dcokerfile:
zane@zane-V:~/mydockerbuild$ cat Dockerfile FROM changed-ubuntu RUN echo "Based on changed-ubuntu" > /tmp/new.t
创建新的image:
zane@zane-V:~/mydockerbuild$ docker build -t bashed_on_changed-ubuntu . Sending build context to Docker daemon 2.048 kB Step 1 : FROM changed-ubuntu ---> 3a3a082982a2 Step 2 : RUN echo "Based on changed-ubuntu" > /tmp/new.t ---> Running in 0132c351fa33 ---> 93a447865aa6 Removing intermediate container 0132c351fa33 Successfully built 93a447865aa6
查看新image的history
zane@zane-V:~/mydockerbuild$ docker history bashed_on_changed-ubuntu IMAGE CREATED CREATED BY SIZE COMMENT 93a447865aa6 29 seconds ago /bin/sh -c echo "Based on changed-ubuntu" > / 24 B 3a3a082982a2 31 minutes ago /bin/sh -c echo "Hello world" > /tmp/newfile 12 B d1b55fd07600 11 months ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B <missing> 11 months ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$/ 1.879 kB <missing> 11 months ago /bin/sh -c echo '#!/bin/sh' > /usr/sbin/polic 701 B <missing> 11 months ago /bin/sh -c #(nop) ADD file:3f4708cf445dc1b537 131.3 MB
可以看到bashed_on_changed-ubuntu,共享了changed-ubuntu的所有image,在重新创建了93a447865aa6;并且只占用了额外的24B。
复制使容器更效率
只有容器层是可写的,共享image 层都是只读的。这样保证了,多个容器层底层共享image的数据安全。
每个容器有它自己的可写层。
当在容器中修改一个已存在的文件,Dcoker使用存储引擎执行copy-on-write 操作。
操作的细节取决于不同的存储引擎,对于AUFS 和 OverlayFS 存储引擎来说copy-on-write操作非常完美:
- 通过image 层 搜索需要更改的文件。
- 该过程从顶部,最新层开始,并向下工作到基本层一次一层。
- 在找到的文件第一次复制的时候执行copy-up操作。
- copy-up 复制这个文件到容器的自己的可写层。
- 在容器自己的可写成修改刚刚复制过来的文件。
如果以我们刚刚创建的changed-ubuntu 为基础运行了5个容器会发生什么?
1.在命令行运行5次docker run
zane@zane-V:~$ docker run -dit changed-ubuntu bash 9635de83c668a61be7077ad309798a686fbfe29abf5f152dc84d641dd4b84a7b zane@zane-V:~$ docker run -dit changed-ubuntu bash f92f01d11ff0d93f09ca6b94ebda3b699dc959297cf90565acf7f337d1c8af03 zane@zane-V:~$ docker run -dit changed-ubuntu bash a341fec4b3604a21dda733839cfea56005712335daa8344ece0a22c4df53076a zane@zane-V:~$ docker run -dit changed-ubuntu bash 54b836a993084953972507015515ad4a9c8c779508ad1a581a7b50fa0a496f42 zane@zane-V:~$ docker run -dit changed-ubuntu bash 7f3ea62f1430b20ab7948281d88ef96140a688cf7bd08454c40ce1ad3d057620
以changed-ubuntu image为基础启动了5个容器。当每个容器被创建后,Dcoker 会分别增加一个可写层,并分配随机的UUID。
2.运行docker ps 命令验证5个容器正常运行中
zane@zane-V:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7f3ea62f1430 changed-ubuntu "bash" 3 minutes ago Up 3 minutes berserk_borg 54b836a99308 changed-ubuntu "bash" 3 minutes ago Up 3 minutes condescending_mccarthy a341fec4b360 changed-ubuntu "bash" 3 minutes ago Up 3 minutes ecstatic_saha f92f01d11ff0 changed-ubuntu "bash" 3 minutes ago Up 3 minutes hungry_mestorf 9635de83c668 changed-ubuntu "bash" 3 minutes ago Up 3 minutes
上面5个运行的容器,都共享changed-ubuntu镜像。CONTAINER ID 是由 UUID所派生的。
3.列出本地存储的内容
$ sudo ls /var/lib/docker/containers
copy-on-write
- 不仅仅减少了容器使用的空间,
- 而且减少了容器启动需要的时间。
因为在启动的时候,Dcoker仅需要为每个容器创建一个可写层。
数据卷和存储引擎
当删除容器时,任何没有存到数据卷里的容器修改内容,也会被删除。
数据卷是docker 本地主机的文件系统里的一个目录或者文件,这个目录或文件是直接挂载到容器里的。
数据卷是不被docker的存储引擎所控制的。读写数据卷是绕过存储引擎的,并以本机主机速度运行。
可以挂载多个数据卷到容器。多个容器也可以共享一个或者多个数据卷。
数据卷驻留在Docker主机上的本地存储区域之外,进一步增强了它们与存储驱动程序控制的独立性。
当容器被删除时,任何存储到数据卷的数据都会持久化在docker 主机上。
总结
- 新建容器,将底层堆的最上层设置为可写,叫做“containers layer”。对运行容器的修改,都是保存在这一层,而不会对底层image(不可写)做任何改变
- docker存储引擎
- 任务
- 开启和管理image层和container层
- 关键技术
- 堆栈image层
- copy-on-write
- 任务
- copy-on-write
- 共享是提升资源利用率的很好途径
- copy-on-write是很好的共享和复制的策略
- 系统进程共享同一实例,不是拥有自己的副本
- 需要修改时,给这进程复制需要的数据
- 优点
- 优化了image磁盘空间使用
- 因为共享了公用数据
- 容器的启动时间性能
- 启动时,仅需要为每个容器创建一个可写层即可
- 优化了image磁盘空间使用
- 当容器需要修改文件,docker存储引擎执行copy-on-write操作
- 不同存储引擎操作细节不同,AUFS,OverlayFS 执行过程
- 通过image 层 搜索需要更改的文件
- 该过程从顶部,最新层开始,并向下工作到基本层一次一层
- 在找到的文件第一次复制的时候执行copy-up操作
- copy-up 复制这个文件到容器的自己的可写层
- 在容器自己的可写成修改刚刚复制过来的文件
- 通过image 层 搜索需要更改的文件
- 不同存储引擎操作细节不同,AUFS,OverlayFS 执行过程
- 数据卷
- 删除容器时,任何存到数据卷的数据都会持久化到docker主机上
- 数据卷是本地主机的一个目录或文件,可直接挂载到容器里
- 数据卷是不被docker存储引擎控制。
- 读写数据卷是绕过存储引擎的,并以本地主机速度运行
- 容器与数据卷
- 可挂载多个数据卷到一个容器
- 也可多个容器共享一个数据卷