docker 镜像不分层 docker底层镜像

文章目录

• 镜像的分层结构
• 为什么镜像是分层的

• base镜像是什么

• 镜像的写时复制特性
• 构建镜像的两种方式

• docker commit 构建新镜像三部曲
• dockerfile方式

• dockerfile常用指令

• 两种构建方式的区别

镜像的分层结构

Docker镜像是由文件系统叠加而成。最底端是一个文件引导系统，即bootfs。Docker用户不会与引导文件系统有直接的交互。

Docker镜像的第二层是root文件系统rootfs，通常是一种或多种操作系统，例如ubuntu等。

在Docker中，文件系统永远都是只读的，在每次修改时，都是进行拷贝叠加从而形成最终的文件系统。Docker称这样的文件为镜像。
一个镜像可以迭代在另一个镜像的顶部。位于下方的镜像称之为父镜像，最底层的镜像称之为基础镜像。
最后，当从一个镜像启动容器时，Docker会在最顶层加载一个读写文件系统作为容器。

可以看到，新镜像是从 base 镜像一层一层叠加生成的。每安装一个软件，就在现有镜像的基础上增加一层。

1.内核空间是 kernel，Linux 刚启动时会加载 bootfs 文件系统，之后 bootfs 会被卸载掉。用户空间的文件系统是 rootfs，包含我们熟悉的 /dev, /proc, /bin 等目录。 
2.对于 base 镜像来说，底层直接用 Host 的 kernel，自己只需要提供 rootfs 就行了。 而对于一个精简的 OS，rootfs 可以很小，只需要包括最基本的命令、工具和程序库就可以了。相比其他 Linux 发行版，CentOS 的 rootfs 已经算臃肿的了，alpine 还不到 10MB。
我们平时安装的 CentOS 除了 rootfs 还会选装很多软件、服务、图形桌面等，需要好几个 GB 就不足为奇了。)
3.base镜像提供的是最小的Linux发行版
4.同一docker主机支持运行多种Linux发行版( bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了。
rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。
5.由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs。比如 Ubuntu 14.04 使用 upstart 管理服务，apt 管理软件包；而 CentOS 7 使用 systemd 和 yum。这些都是用户空间上的区别，Linux kernel 差别不大。所以 Docker 可以同时支持多种 Linux镜像，模拟出多种操作系统环境。)

为什么镜像是分层的

为什么 Docker 镜像要采用这种分层结构呢？
最大的一个好处就是 ——共享资源。

比如：有多个镜像都从相同的 base 镜像构建而来，那么 Docker Host 只需在磁盘上保存一份 base 镜像；同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。而且镜像的每一层都可以被共享，我们将在后面更深入地讨论这个特性。
这时可能就有人会问了：如果多个容器共享一份基础镜像，当某个容器修改了基础镜像的内容，比如 /etc 下的文件，这时其他容器的 /etc 是否也会被修改？答案是不会！
修改会被限制在单个容器内。
这就是我们接下来要说的容器 Copy-on-Write 特性。
新数据会直接存放在最上面的容器层。
修改现有数据会先从镜像层将数据复制到容器层，修改后的数据直接
保存在容器层中，镜像层保持不变。
如果多个层中有命名相同的文件，用户只能看到最上面那层中的文件。

base镜像是什么

base镜像

base 镜像简单来说就是不依赖其他任何镜像，完全从0开始建起，
其他镜像都是建立在他的之上，可以比喻为大楼的地基，docker镜像的鼻祖。

base 镜像有两层含义：
（1）不依赖其他镜像，从 scratch 构建；
（2）其他镜像可以之为基础进行扩展。
所以，能称作 base 镜像的通常都是各种 Linux 发行版的 Docker 镜像，
比如 Ubuntu, Debian, CentOS 等。

镜像的写时复制特性

Docker的这种机制我们称之为写时复制。

镜像是用来创建容器的,是容器的只读模板,默认可以从 docker hub 上下载。

当容器启动时，一个新的可写层被加载到镜像的顶部。这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”
  
  典型的Linux在启动后，首先将 rootfs(root file system根文件系统) 置为 readonly, 进行一系列检查,
  
 然后将其切换为 “readwrite” 供用户使用。在docker中，起初也是将 rootfs
 以readonly方式加载并检查，然而接下来利用 union mount 的将一个 readwrite 文件系统挂载在 readonly
的rootfs之上，并且允许再次将下层的 file system设定为readonly 并且向上叠加,
 这样一组readonly和一个writeable的结构构成一个container的运行目录, 每一个被称作一个Layer
 所有对容器的改动，无论添加、删除、还是修改文件都
 只会发生在容器层中。只有容器层是可写的，容器层下面的所有镜像层都是只读的。

==下面我们深入讨论容器层的细节。==

镜像层数量可能会很多，所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件，比如 /a，上层的 /a
    会覆盖下层的 /a，也就是说用户只能访问到上层中的文件 /a。在容器层中，用户看到的是一个叠加之后的文件系统。
    添加文件：在容器中创建文件时，新文件被添加到容器层中。 读取文件：在容器中读取某个文件时，Docker
    会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后打开并读入内存。
    修改文件：在容器中修改已存在的文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后修改之。
    删除文件：在容器中删除文件时，Docker 也是从上往下依次在镜像层中查找此文件。找到后，会在容器层中记录下此删除操作。
    只有当需要修改时才复制一份数据，这种特性被称作
    Copy-on-Write。可见，容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。这样就解释了我们前面提出的问题：容器层记录对镜像的修改，所有镜像层都是只读的，不会被容器修改，所以镜像可以被多个容器共享。

构建镜像的两种方式

docker commit 构建新镜像三部曲

运行容器 # docker run -it --name test busybox
修改容器 （以下命令在容器内运行） # echo helloworld > testfile
将容器保存为新的镜像 # docker commit  test test:v1
查看镜像 # docker images test:v1

1.以下是一些常用命令的演示

2.

3.

4.

5.

6.

commit构建镜像

dockerfile方式

dockerfile常用指令

FROM：指定base镜像，如果本地不存在会从远程仓库下载。	

MAINTAINER：设置镜像的作者，比如用户邮箱等。

COPY：把文件从build context复制到镜像
支持两种形式：COPY src dest 和 COPY ["src", "dest"]
src必须指定build context中的文件或目录

ADD：用法与COPY类似，不同的是src可以是归档压缩文件，文件会被自动解压到dest，也可以自动下载URL并拷贝到镜像：
ADD html.tar /var/www
ADD http://ip/html.tar /var/www

ENV：设置环境变量，变量可以被后续的指令使用：
ENV HOSTNAME sevrer1.example.com

EXPOSE：如果容器中运行应用服务，可以把服务端口暴露出去：
EXPOSE 80

VOLUME：申明数据卷，通常指定的是应用的数据挂在点：
VOLUME ["/var/www/html"]

WORKDIR：为RUN、CMD、ENTRYPOINT、ADD和COPY指令设置镜像中的当前工作目录，如果目录不存在会自动创建。

RUN：在容器中运行命令并创建新的镜像层，常用于安装软件包：
RUN yum install -y vim

CMD 与 ENTRYPOINT
这两个指令都是用于设置容器启动后执行的命令，但CMD会被docker run后面的命令行覆盖，而ENTRYPOINT不会被忽略，一定会被执行。
docker run后面的参数可以传递给ENTRYPOINT指令当作参数。
Dockerfile中只能指定一个ENTRYPOINT，如果指定了很多，只有最后一个有效。

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

参数的引用

2.)

11.互相传参

两种构建方式的区别

1.容器镜像的构建者可以任意修改容器的文件系统后进行发布，这种修改对于镜像使用者来说是不透明的，镜像构建者一般也不会将对容器文件系统的每一步修改，记录进文档中，供镜像使用者参考。
2.容器镜像不能（更准确地说是不建议）通过修改，生成新的容器镜像。
从镜像运行容器，实际上是在镜像顶部上加了一层可写层，所有对容器文件系统的修改，都在这一层中进行，不影响已经存在的层。比如在容器中删除一个1G的文件，从用户的角度看，容器中该文件已经没有了，但从文件系统的角度看，文件其实还在，只不过在顶层中标记该文件已被删除，当然这个标记为已删除的文件还会占用镜像空间。从容器构建镜像，实际上是把容器的顶层固化到镜像中。
也就是说， 对容器镜像进行修改后，生成新的容器镜像，会多一层，而且镜像的体积只会增大，不会减小。长此以往，镜像将变得越来越臃肿。Docker提供的 export 和 import 命令可以一定程度上处理该问题，但也并不是没有缺点。
3.容器镜像依赖的父镜像变化时，容器镜像必须进行重新构建。如果没有编写自动化构建脚本，而是手工构建的，那么又要重新修改容器的文件系统，再进行构建，这些重复劳动其实是没有价值的。
4.Dockerfile镜像是完全透明的，所有用于构建镜像的指令都可以通过Dockerfile看到。甚至你还可以递归找到本镜像的任何父镜像的构建指令。也就是说，你可以完全了解一个镜像是如何从零开始，通过一条条指令构建出来的。
5.Dockerfile镜像需要修改时，可以通过修改Dockerfile中的指令，再重新构建生成，没有任何问题
6.Dockerfile可以在GitHub等源码管理网站上进行托管，DockerHub自动关联源码进行构建。当你的Dockerfile变动，或者依赖的父镜像变动，都会触发镜像的自动构建，非常方便。