理解镜像，容器，存储引擎

时间：2017-06-09 12:20:30 阅读：315 评论：0 收藏：0 [点我收藏+]

为了很好的使用存储引擎，必须明白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磁盘空间使用
    - 因为共享了公用数据
  - 容器的启动时间性能
    - 启动时，仅需要为每个容器创建一个可写层即可
当容器需要修改文件，docker存储引擎执行copy-on-write操作
- 不同存储引擎操作细节不同，AUFS,OverlayFS 执行过程
  - 通过image 层搜索需要更改的文件
    - 该过程从顶部，最新层开始，并向下工作到基本层一次一层
  - 在找到的文件第一次复制的时候执行copy-up操作
    - copy-up 复制这个文件到容器的自己的可写层
  - 在容器自己的可写成修改刚刚复制过来的文件
数据卷
- 删除容器时，任何存到数据卷的数据都会持久化到docker主机上
- 数据卷是本地主机的一个目录或文件，可直接挂载到容器里
- 数据卷是不被docker存储引擎控制。
  - 读写数据卷是绕过存储引擎的，并以本地主机速度运行
- 容器与数据卷
  - 可挂载多个数据卷到一个容器
  - 也可多个容器共享一个数据卷

理解镜像，容器，存储引擎

原文：http://www.cnblogs.com/Aiapple/p/6971292.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年09月23日 (328)
2021年09月24日 (313)
2021年09月17日 (191)
2021年09月15日 (369)
2021年09月16日 (411)
2021年09月13日 (439)
2021年09月11日 (398)
2021年09月12日 (393)
2021年09月10日 (160)
2021年09月08日 (222)