当前位置: 移动技术网 > IT编程>开发语言>Java > Docker镜像细节

Docker镜像细节

2019年01月30日  | 移动技术网IT编程  | 我要评论

前言

只有光头才能变强。

文本已收录至我的github仓库,欢迎star:https://github.com/zhongfucheng3y/3y

docker

回顾前面:

前面两篇已经讲解了为什么需要docker这项技术,以及解释了docker的基本概念/术语,使用docker成功运行tomcat~

在上篇也同样留下一个问题:我们知道tomcat运行起来需要java的支持,那么我们在dockerhub拉取下来的tomcat镜像是不是也有java环境呢?

所以,这篇主要来讲讲docker镜像相关的知识点!

一、简单了解dockerfile

dockerfile是用来构建docker镜像的文件,是由一系列命令和参数构成的脚本

简单来说:dockerfile是镜像的源码

上一篇我们pull了一份tomcat的镜像,我们也可以去看看它的dockerfile长的什么样:

搜索,拉下去就有得看dockerfile了

我们随便点进去一个看一下:

dockerfile

我们在dockerfile的第一行就可以发现from openjdk:8-jre,所以可以确定的是:在dockerhub拉取下来的tomcat镜像一定有java环境

在这里我们先不说如何阅读/编写dockerfile文件,先了解到dockerfile是镜像的源码即可

简单来说:通过dockerfile文件可以知道我们拉取下来的镜像究竟是怎么构建的。

二、解除镜像的疑惑

我们知道docker hub有很多常用的镜像,比如说centos。我们去pull一个下来看看docker中的centos长啥样:

从hub中pull一个centos

我们可以发现的是:tomcatsize竟然比centos还要大!但按我们常规的想法,centos的镜像可能是3或4gb(现在200m),tomcat的镜像可能就200m(现在400m)。这是为什么呢??

如果我们在pull的时候观察得比较仔细的话,可以发现pull会拉下很多镜像:

pull到很多层镜像

完全pull下来的之后,我们如果使用docker images只能查看到最终的镜像:

只能看到最终我们拉下来的镜像

如果我们使用docker images -a命令的话,可以把中间层镜像都查出来:

  • 理想效果:(在镜像列表里边除了tomcat和centos应该还夹杂着名为<none>的镜像)
  • 遗憾的是:博主一直没测出效果来,也就是我的镜像列表里没有<none>的镜像(怀疑是版本的问题,我的版本是docker版本是18.09.1,centos的版本是centos linux release 7.3.1611 。如果知道具体原因的不妨在评论区下告诉我)

理想效果

emmm,我们可以使用history命令来看看,可以发现tomcat包含很多个镜像层

使用history命令可以发现tomcat包含很多个镜像层

还可以发现一点:dockerfile有多少条命令,那就有多少个镜像层(不信你数数)

说了那么多,就想让大家知道:我们拉取下来的镜像实际上是由很多中间层镜像组成的。

再结合我们上一篇docker入门为什么可以这么简单?,在解决tomcat启动时一直卡住问题时,能够发现的是,我们可以使用cd, ls等基础命令,但无法使用vi命令(需要我自己去下载)。

我们可以推断出,pull下来的镜像由很多层镜像组成【这些镜像都是精简过的(甚至连vi命令都不支持)】

  • 因为tomcat镜像要的基础环境比centos镜像要多,所以tomcat镜像的sizecentos要大

三、docker镜像的特点

关于docker镜像,有以下特点:

  • dockerfile生成
  • 呈现层级结构
  • 每层镜像包含:镜像文件以及镜像json元数据信息

docker镜像示意图

图像来源:

3.1镜像呈现层级结构

联合文件系统(unionfs)是实现docker镜像的技术基础。在docker中一般使用是aufs(another union file system或advanced multilayered unification file system)【具体还是得看宿主机用的什么系统】。

在搜索中文资料的时候,常常会发现有类似的解释:

“aufs是一种 union fs, 简单来说就是“支持将不同目录挂载到同一个虚拟文件系统下的文件系统”, aufs支持为每一个成员目录设定只读(rreadonly)、读写(readwrite)和写(whiteout-able)权限。union fs 可以将一个readonly的branch和一个writeable的branch联合在一起挂载在同一个文件系统下”。

看得我一头雾水....后来去官方文档介绍aufs:

aufs is a union filesystem, which means that it layers multiple directories on a single linux host and presents them as a single directory. these directories are called branches in aufs terminology, and layers in docker terminology

说白了,还是可以理解成:docker的镜像的基础是联合文件系统,它支持将文件系统中的修改信息作为一次提交,并层层叠加,外界看到的是最外层的镜像。(比如外界只看到tomcat镜像,而中间叠加了很多层镜像)

(这里只是拿aufs说明,docker实际上支持很多存储驱动,比如还有devicemapper,overlay2(ubuntu的14.04.4或更高版本,16.04或更高版本), overlay,zfs

3.1.1镜像继承(共享)

docker镜像可以通过分层来进行继承

例如,hello-world的dockerfile镜像from scratch镜像,scratch在docker中是一个基础镜像

from scratch
copy hello /
cmd ["/hello"]

centos的dockerfile镜像也是from scratch镜像:

from scratch
add centos-7-docker.tar.xz /

label org.label-schema.schema-version="1.0" \
    org.label-schema.name="centos base image" \
    org.label-schema.vendor="centos" \
    org.label-schema.license="gplv2" \
    org.label-schema.build-date="20181205"

cmd ["/bin/bash"]

那么centos镜像和hello-world共享同一个基础镜像层scratch,提高了存储效率

再说个例子,比如我们有一个centos镜像,这个镜像大小是202m。然后,我们基于centos镜像手动往里边添加一个tomcat(假设这个tomcat的大小是300m),生成一个镜像,总大小就是502m了。

如果仅仅是单纯的累加这两个镜像的大小:202m+502m=704m,但是由于镜像复用的存在,实际占用的磁盘空间大小是:202m+300m=502m

aufs uses the copy-on-write (cow) strategy to maximize storage efficiency and minimize overhead。

如果想要了解cow,不妨阅读我之前写过的文章:

3.2json文件

docker每一层镜像的json文件,都扮演着一个非常重要的角色,其主要的作用如下:

  • 记录 docker 镜像中与容器动态信息相关的内容
  • 记录父子 docker 镜像之间真实的差异关系
  • 弥补 docker 镜像内容的完整性与动态内容的缺失

docker镜像的json文件可以认为是镜像的元数据信息

最后

今天简单地聊了一下docker镜像的一些细节,但没去深入了解,想要继续深入的同学还得通过官方文档等途径去学习哈。

参考资料:

  • allen 谈 docker
  • 官方文档介绍aufs
  • docker核心实现技术(命名空间&控制组&联合文件系统&linux网络虚拟化支持)
  • docker联合文件系统union file system

乐于输出干货的java技术公众号:java3y。公众号内有200多篇原创技术文章、海量视频资源、精美脑图,不妨来关注一下!

帅的人都关注了

觉得我的文章写得不错,不妨点一下

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网