Docker应用容器引擎——构建镜像的两种方式（Dockerfile、commit）
文章目录
- 一.镜像的分层结构
-
- 1.为什么镜像是分层的
- 2.base镜像是什么
- 3.镜像的写时复制特性
- 二.构建镜像的两种方式
-
- 1.docker commit 构建新镜像三部曲
- 2.编写Dockerfile构建镜像
- dockerfile常用指令
-
- COPY
- ADD
- ENV
- VOLUME
- WORKDIR
- RUN
- CMD+ENTRYPOINT
- 两种构建方式的区别
一.镜像的分层结构
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镜像，模拟出多种操作系统环境。)
不同linux系统的内核一样，但是上边的文件系统不一样
1.为什么镜像是分层的
为什么 Docker 镜像要采用这种分层结构呢？
最大的一个好处就是 ——共享资源。
比如：有多个镜像都从相同的 base 镜像构建而来，那么 Docker Host 只需在磁盘上保存一份 base 镜像；同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。而且镜像的每一层都可以被共享，我们将在后面更深入地讨论这个特性。
这时可能就有人会问了：如果多个容器共享一份基础镜像，当某个容器修改了基础镜像的内容，比如 /etc 下的文件，这时其他容器的 /etc 是否也会被修改？答案是不会！
修改会被限制在单个容器内。
这就是我们接下来要说的容器 Copy-on-Write 特性。新数据会直接存放在最上面的容器层。修改现有数据会先从镜像层将数据复制到容器层，修改后的数据直接保存在容器层中，镜像层保持不变。如果多个层中有命名相同的文件，用户只能看到最上面那层中的文件。
这种分层结构，大大减少了磁盘空间和网络带宽（下载时）
2.base镜像是什么
base 镜像简单来说就是不依赖其他任何镜像，完全从0开始建起，
其他镜像都是建立在他的之上，可以比喻为大楼的地基，docker镜像的鼻祖。
base 镜像有两层含义：
（1）不依赖其他镜像，从 scratch 构建；
（2）其他镜像可以之为基础进行扩展。
所以，能称作 base 镜像的通常都是各种 Linux 发行版的 Docker 镜像，
比如 Ubuntu, Debian, CentOS 等。
3.镜像的写时复制特性
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。可见，
容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。这样就解释了我们前面提出的问题：容器层记录对镜像的修改，所有镜像层都是只读的，不会被容器修改，所以镜像可以被多个容器共享。
二.构建镜像的两种方式
1.docker commit 构建新镜像三部曲
运行容器 # docker run -it --name test busybox
修改容器 （以下命令在容器内运行） # echo helloworld > testfile
将容器保存为新的镜像 # docker commit test test:v1
查看镜像 # docker images test:v1
（1）利用ubuntu镜像建立容器vm1，，对它进行修改
（2）使用commit命令进行封装
可以看到我们无法知道那一步做了什么，就是无法审计
（3）使用新封装的镜像构建容器，保存了之前操作的痕迹
2.编写Dockerfile构建镜像
准备编写DockFile实现安装httpd服务
(1)删除前面构建的镜像和容器
docker rmi ubuntu:v1
(2)拉取rhel7镜像源
（3）编写Dockerfile
FROM rhel7 # 源镜像是rhel7，最好将名为rhel7的镜像放在本地
COPY yum.repo /etc/yum.repos.d #将本地的yum源文件复制到容器中的/etc/yum.repo.d/目录下
RUN rpmdb --rebuilddb && yum install -y ##httpd在容器中安装httpd服务
# 执行命令安装httpd并清除yum缓存
# rpmdb 命令用于初始化和重建rpm数据库
# --rebuilddb：从已安装的包头文件，反向重建RPM数据库
EXPOSE 80 # 定义端口为80
CMD ["/usr/sbin/httpd","-D","FOREGROUND"]
# 打开apach服务
# -D 是全局文件/etc/sysconfig/httpd中的打开参数
（4）封装镜像，并测试能否正常使用
[root@server1 docker]# docker build -t rhel7:v1 . ##注意命令后有一个点，表示当前目录下
##-t表示起了个名字
（5）基于刚才封装的镜像运行一个容器
(6) 书写httpd服务默认发布文件，导入容器内部
访问测试
可以看出刚才构建的镜像是好的,基于镜像运行起来的容器也是好的
（7）构建镜像，并添加数据卷挂载位置（VOLUME [“var/www/html”]）
这里数据卷挂载位置指的是容器内的
Build构建镜像
[root@server1 docker]# docker build -t rhel7:v2 .
Sending build context to Docker daemon 4.096kB
Step 1/6 : FROM rhel7
---> 0a3eb3fde7fd
Step 2/6 : COPY yum.repo /etc/yum.repos.d/
---> Using cache ##使用了缓存
---> db0ce1a7fb77
Step 3/6 : RUN rpmdb --rebuilddb && yum install -y httpd
---> Using cache ##使用了缓存
---> ba007361f210
Step 4/6 : EXPOSE 80
---> Using cache ##使用了缓存
---> 554977c12e37
Step 5/6 : VOLUME ["/var/www/html"]
---> Running in 4fbea9452763
Removing intermediate container 4fbea9452763
---> 7094cf717b4c
Step 6/6 : CMD ["/usr/sbin/httpd","-D","FOREGROUND"]
---> Running in 0efba909bae5
Removing intermediate container 0efba909bae5
---> 6d1e0dbaa3ff
Successfully built 6d1e0dbaa3ff
Successfully tagged rhel7:v2
这就要提到一个重要点：镜像的缓存特性
此时可以看到 rhel7:v2比 rhel7:v1多了一层
生成并运行容器，并测试是否可以正常访问，这里指定了宿主机数据卷的位置为/root/docker/web/
可以看到index.html文件已经挂载到了容器内的数据卷目录中
（8）直接在数据卷中编写发布文件
重新生成容器
查看httpd3的数据卷位置
其中/var/lib/～/_data是宿主机目录的位置，/var/www/html是容器内数据挂载位置。
进入数据卷位置并编写发布文件并测试
测试
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，如果指定了很多，只有最后一个有效。
COPY
ADD
ENV
VOLUME
WORKDIR
RUN
CMD+ENTRYPOINT
参数的引用
11.互相传参
两种构建方式的区别
1.容器镜像的构建者可以任意修改容器的文件系统后进行发布，这种修改对于镜像使用者来说是不透明的，镜像构建者一般也不会将对容器文件系统的每一步修改，记录进文档中，供镜像使用者参考。
2.容器镜像不能（更准确地说是不建议）通过修改，生成新的容器镜像。
从镜像运行容器，实际上是在镜像顶部上加了一层可写层，所有对容器文件系统的修改，都在这一层中进行，不影响已经存在的层。比如在容器中删除一个1G的文件，从用户的角度看，容器中该文件已经没有了，但从文件系统的角度看，文件其实还在，只不过在顶层中标记该文件已被删除，当然这个标记为已删除的文件还会占用镜像空间。从容器构建镜像，实际上是把容器的顶层固化到镜像中。
也就是说， 对容器镜像进行修改后，生成新的容器镜像，会多一层，而且镜像的体积只会增大，不会减小。长此以往，镜像将变得越来越臃肿。Docker提供的 export 和 import 命令可以一定程度上处理该问题，但也并不是没有缺点。
3.容器镜像依赖的父镜像变化时，容器镜像必须进行重新构建。如果没有编写自动化构建脚本，而是手工构建的，那么又要重新修改容器的文件系统，再进行构建，这些重复劳动其实是没有价值的。
4.Dockerfile镜像是完全透明的，所有用于构建镜像的指令都可以通过Dockerfile看到。甚至你还可以递归找到本镜像的任何父镜像的构建指令。也就是说，你可以完全了解一个镜像是如何从零开始，通过一条条指令构建出来的。
5.Dockerfile镜像需要修改时，可以通过修改Dockerfile中的指令，再重新构建生成，没有任何问题
6.Dockerfile可以在GitHub等源码管理网站上进行托管，DockerHub自动关联源码进行构建。当你的Dockerfile变动，或者依赖的父镜像变动，都会触发镜像的自动构建，非常方便。