docker的镜像原理
一、镜像是什么
镜像是一种轻量级、可执行的独立软件包,用来打包软件运行环境和基于运行环境开发的软件,它包含运行某个软件所需要的所有内容,包括代码、运行时、库、环境变量和配置文件。
所有的应用,直接打包docker镜像,就可以直接跑起来!
如何得到镜像:
- 从远程仓库下载
- 拷贝
- 自己制作镜像(dockerfile)
二、docker镜像加载原理
1、UnionFS(联合文件系统)
下载镜像时,看到的一层一层的就是这个!!
UnionFS(联合文件系统):Union文件系统(UnionFS)是一种分层、轻量级并且高性能的文件系统,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)。Union文件系统是docker镜像的基础,镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
特性:一次同时加载多个文件系统,但从外面看起来,只能看到一个文件系统,联合加载会把各层文件系统叠加起来,这样最终的文件系统会包含所有底层的文件和目录。
2、docker镜像加载原理
docker的镜像实际上时由一层一层的文件系统组成的,这种层级的文件系统UnionFS
bootfs(boot file system)(即系统启动需要的引导加载)
主要包含bootloader和kernel, bootloader主要是引导加载kernel, Linux刚启动时会加载bootfs文件系统,在Docker镜像的最底层是bootfs。这一层与我们典型的Linux/Unix系统是一样的,包含boot加载器和内核。当boot加载完成之后整个内核就都在内存中了,此时内存的使用权已由bootfs转交给内核,此时系统也会卸载bootfs。
rootfs (root file system),在bootfs之上。包含的就是典型Linux系统中的/dev, /proc, /bin,/etc等标准目录和文件。rootfs就是各种不同的操作系统发行版,比如Ubuntu ,Centos等等。
平时我们安装进虚拟机的centos都是好几个G,为什么docker里才200多M?
对于一个精简的OS , rootfs 可以很小,只需要包含最基本的命令,工具和程序库就可以了,因为底层直接用Host的kernel,自己只需要提供rootfs就可以了。由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别,因此不同的发行版可以公用bootfs.
这里也就可以理解虚拟机的启动时分钟级别,而docker的启动是分钟级的!
三、分层理解
1、分层的镜像
我们可以去下载一个镜像,注意观察下载的日志输出,乐意看到一层一层的在下载!
[root@localhost ~] # docker pull 192.168.28.10:5000/nginx
Using default tag: latest
latest: Pulling from nginx
a076a628af6f: Already exists
0732ab25fa22: Pull complete
d7f36f6fe38f: Pull complete
f72584a26f32: Pull complete
7125e4df9063: Pull complete
Digest: sha256:0b159cd1ee1203dad901967ac55eee18c24da84ba3be384690304be93538bea8
Status: Downloaded newer image for 192.168.28.10:5000/nginx:latest
192.168.28.10:5000/nginx:latest
为什么docker镜像要采用这种分层的结构呢?
最大的好处,莫过于是资源共享了!比如有多个镜像都从相同的Base镜像构建而来,那么宿主机只需在磁盘上保留一份base镜像,同时内存中也只需要加载一份base镜像,这样就可以为所有的容器服务了,而且镜像的每一层都可以被共享。
查看镜像分层的方式可以通过docker image inspect命令!
[root@localhost /mxx] # docker image inspect redis:latest
[
{
"Id": "sha256:621ceef7494adfcbe0e523593639f6625795cc0dc91a750629367a8c7b3ccebb",
"RepoTags": [
"redis:latest"
],
"RepoDigests": [
"redis@sha256:0f97c1c9daf5b69b93390ccbe8d3e2971617ec4801fd0882c72bf7cad3a13494"
],
"Parent": "",
"Comment": "",
"Created": "2021-01-13T09:45:41.527587343Z",
"Container": "16535cfaf84a4049b6c02840219e8473787d5610e29409049df3a41bbf77a333",
"ContainerConfig": {
"Hostname": "16535cfaf84a",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"6379/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.12",
"REDIS_VERSION=6.0.10",
"REDIS_DOWNLOAD_URL=http://download.redis.io/releases/redis-6.0.10.tar.gz",
"REDIS_DOWNLOAD_SHA=79bbb894f9dceb33ca699ee3ca4a4e1228be7fb5547aeb2f99d921e86c1285bd"
],
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ",
"CMD [\"redis-server\"]"
],
"Image": "sha256:222c0cecc006d8c73a04a58b5fa15ebae171a6e82a8ee8650ae616f6f1798ef4",
"Volumes": {
"/data": {}
},
"WorkingDir": "/data",
"Entrypoint": [
"docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": {}
},
"DockerVersion": "19.03.12",
"Author": "",
"Config": {
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"6379/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.12",
"REDIS_VERSION=6.0.10",
"REDIS_DOWNLOAD_URL=http://download.redis.io/releases/redis-6.0.10.tar.gz",
"REDIS_DOWNLOAD_SHA=79bbb894f9dceb33ca699ee3ca4a4e1228be7fb5547aeb2f99d921e86c1285bd"
],
"Cmd": [
"redis-server"
],
"Image": "sha256:222c0cecc006d8c73a04a58b5fa15ebae171a6e82a8ee8650ae616f6f1798ef4",
"Volumes": {
"/data": {}
},
"WorkingDir": "/data",
"Entrypoint": [
"docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": null
},
"Architecture": "amd64",
"Os": "linux",
"Size": 104285909,
"VirtualSize": 104285909,
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/610cf5511965d30850be9a0ffdd5c105883cc8671fa596401c1457c772d21fb8/diff:/var/lib/docker/overlay2/9f52d9834c58bcd12e66c358aad9872585bf6bce3488f611328c1ec11288daad/diff:/var/lib/docker/overlay2/79b8d8526445cde7f649ae9619c4fef681953599a7e00454d2171fb7fc8a8691/diff:/var/lib/docker/overlay2/5ee51473aef28cbe8e314313043dcf1442d3b27f00bbaf4909495422630ad9ae/diff:/var/lib/docker/overlay2/7cd24d87c994b78e2c6403cd4566daae04604befb0dade1536e3e5e42e4b33af/diff",
"MergedDir": "/var/lib/docker/overlay2/0b9a766a7c0335e91c797d0e387366ddcb0efc411ee2ce6e1b0a00044dddc374/merged",
"UpperDir": "/var/lib/docker/overlay2/0b9a766a7c0335e91c797d0e387366ddcb0efc411ee2ce6e1b0a00044dddc374/diff",
"WorkDir": "/var/lib/docker/overlay2/0b9a766a7c0335e91c797d0e387366ddcb0efc411ee2ce6e1b0a00044dddc374/work"
},
"Name": "overlay2"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:cb42413394c4059335228c137fe884ff3ab8946a014014309676c25e3ac86864",
"sha256:8e14cb7841faede6e42ab797f915c329c22f3b39026f8338c4c75de26e5d4e82",
"sha256:1450b8f0019c829e638ab5c1f3c2674d117517669e41dd2d0409a668e0807e96",
"sha256:f927192cc30cb53065dc266f78ff12dc06651d6eb84088e82be2d98ac47d42a0",
"sha256:a24a292d018421783c491bc72f6601908cb844b17427bac92f0a22f5fd809665",
"sha256:3480f9cdd491225670e9899786128ffe47054b0a5d54c48f6b10623d2f340632"
]
},
"Metadata": {
"LastTagTime": "0001-01-01T00:00:00Z"
}
}
]
理解∶
所有的Docker镜像都起始于一个基础镜像层,当进行修改或增加新的内容时,就会在当前镜像层之上,创建新的镜像层。
举一个简单的例子,假如基于Ubuntu Linux 16.04创建一个新的镜像,这就是新镜像的第一层;如果在该镜像中添加Python包,就会在基础镜像层之上创建第二个镜像层;如果继续添加一个安全补丁,就会创建第三个镜像层。
该镜像当前已经包含3个镜像层,如下图所示(这只是一个用于演示的很简单的例子)。
在添加额外的镜像层的同时,镜像始终保持是当前所有镜像的组合,理解这一点非常重要。下图中举了一个简单的例子,每个镜像层包含3个文件,而镜像包含了来自两个镜像层的6个文件。
上图中的镜像层跟之前图中的略有区别,主要目的是便于展示文件。
下图中展示了一个稍微复杂的三层镜像,在外部看来整个镜像只有6个文件,这是因为最上层中的文件7是文件5的一个更新版本。
这种情况下,上层镜像层中的文件覆盖了底层镜像层中的文件。这样就使得文件的更新版本作为一个新镜像层添加到镜像当中。Docker通过存储引擎(新版本采用快照机制)的方式来实现镜像层堆栈,并保证多镜像层对外展示为统一的文件系统。
Linux上可用的存储引擎有AUFS、Overlay2、Device Mapper、Btrfs以及ZFS。顾名思义,每种存储引擎都基于Linux中对应的文件系统或者块设备技术,并且每种存储引擎都有其独有的性能特点。
Docker在Windows上仅支持windowsfilter一种存储引擎,该引擎基于NTFS文件系统之上实现了分层和CoW[1]。
下图展示了与系统显示相同的三层镜像。所有镜像层堆叠并合并,对外提供统一的视图。
特点:
Docker镜像都是只读的,当容器启动时,一个新的可写层被加载到镜像的顶部!这一层就是我们通常说的容器层,容器之下的都叫镜像层!
Windows上仅支持windowsfilter一种存储引擎,该引擎基于NTFS文件系统之上实现了分层和CoW[1]。
下图展示了与系统显示相同的三层镜像。所有镜像层堆叠并合并,对外提供统一的视图。
[外链图片转存中…(img-unvv70en-1616491617955)]
特点:
Docker镜像都是只读的,当容器启动时,一个新的可写层被加载到镜像的顶部!这一层就是我们通常说的容器层,容器之下的都叫镜像层!
四、commit镜像(分层原理的例子)
docker commit 提交容器成为一个新的副本
docker commit -m="提交的描述信息" -a="作者" 容器id 目标镜像名:[tag]
实战练习:
1、启动一个tomcat
docker run -it -p 3345:8080 tomcat
在外网浏览器登录查看是否安装成功,发现并不是tomcat安装成功界面!
2、发现tomcat的镜像的webapps内没有内容,镜像的原因,官方的镜像默认webapps是没有文件的!
root@345b5b40cba8:/usr/local/tomcat# ls
BUILDING.txt LICENSE README.md RUNNING.txt conf logs temp webapps.dist
CONTRIBUTING.md NOTICE RELEASE-NOTES bin lib native-jni-lib webapps work
root@345b5b40cba8:/usr/local/tomcat# cd webapps
root@345b5b40cba8:/usr/local/tomcat/webapps# ls
root@345b5b40cba8:/usr/local/tomcat/webapps#
3、把webapps.dist内的内容-r复制到webapps中
cp -r /usr/local/tomcat/webapps.dist/* /usr/local/tomcat/webapps
root@345b5b40cba8:/usr/local/tomcat/webapps.dist# cp -r /usr/local/tomcat/webapps.dist/* /usr/local/tomcat/webapps
root@345b5b40cba8:/usr/local/tomcat# cd webapps
root@345b5b40cba8:/usr/local/tomcat/webapps# ls
ROOT docs examples host-manager manager
4、把自己操作过的容器通过commit提交为一个镜像!以后就可以使用我们制作的镜像了!
docker commit -m="add webapps" -a="mxx" 629ad3f37e55 tomcat01:1.0
sha256:3716bce90595bc7c6209301b01e38f8db9130fc1a9db174dc2e519dcef9447fa
5、查看我们制作的镜像
docker images
[root@localhost ~] # docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat01 1.0 3716bce90595 2 minutes ago 654MB
mysql latest c8562eaf9d81 2 months ago 546MB
redis latest 621ceef7494a 2 months ago 104MB
tomcat latest 040bdb29ab37 2 months ago 649MB