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 镜像简单来说就是不依赖其他任何镜像,完全从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所有对容器的改动,无论添加、删除、还是修改文件都只会发生在容器层中。只有容器层是可写的
,容器层下面的所有镜像层都是只读
的。
下面我们深入讨论容器层的细节
容器层保存的是镜像变化的部分,不会对镜像本身进行任何修改
。这样就解释了我们前面提出的问题:容器层记录对镜像的修改,所有镜像层都是只读的,不会被容器修改,所以镜像可以被多个容器共享。运行容器 # docker run -it --name test busybox
修改容器 (以下命令在容器内运行) # echo helloworld > testfile
将容器保存为新的镜像 # docker commit test test:v1
查看镜像 # docker images test:v1
(1)利用ubuntu镜像建立容器vm1,,对它进行修改
(2)使用commit命令进行封装
准备编写DockFile实现安装httpd服务
(1)删除前面构建的镜像和容器
docker rmi ubuntu:v1
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”])
[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
是容器内数据挂载位置。
进入数据卷位置并编写发布文件并测试
测试
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.容器镜像不能(更准确地说是不建议)通过修改,生成新的容器镜像。
从镜像运行容器,实际上是在镜像顶部上加了一层可写层,所有对容器文件系统的修改,都在这一层中进行,不影响已经存在的层。比如在容器中删除一个1G的文件,从用户的角度看,容器中该文件已经没有了,但从文件系统的角度看,文件其实还在,只不过在顶层中标记该文件已被删除,当然这个标记为已删除的文件还会占用镜像空间。从容器构建镜像,实际上是把容器的顶层固化到镜像中。
也就是说, 对容器镜像进行修改后,生成新的容器镜像,会多一层,而且镜像的体积只会增大,不会减小。长此以往,镜像将变得越来越臃肿。Docker提供的 export 和 import 命令可以一定程度上处理该问题,但也并不是没有缺点。
3.容器镜像依赖的父镜像变化时,容器镜像必须进行重新构建。如果没有编写自动化构建脚本,而是手工构建的,那么又要重新修改容器的文件系统,再进行构建,这些重复劳动其实是没有价值的。
4.Dockerfile镜像是完全透明的,所有用于构建镜像的指令都可以通过Dockerfile看到。甚至你还可以递归找到本镜像的任何父镜像的构建指令。也就是说,你可以完全了解一个镜像是如何从零开始,通过一条条指令构建出来的。
5.Dockerfile镜像需要修改时,可以通过修改Dockerfile中的指令,再重新构建生成,没有任何问题
6.Dockerfile可以在GitHub等源码管理网站上进行托管,DockerHub自动关联源码进行构建。当你的Dockerfile变动,或者依赖的父镜像变动,都会触发镜像的自动构建,非常方便。