docker镜像管理
docker镜像概念
Docker的三大核心概念分别是镜像、容器、仓库。Docker运行容器前需要本地存在对应的镜像,如果本地没有对应的镜像,Docker会尝试从默认的镜像仓库下载。当然用户也可以通过配置,使用自定义的镜像仓库。也就是说,镜像是运行容器的前提,仓库是存放镜像的场所,可见镜像更是Docker的核心。
docker镜像原理
Docker镜像本质就是一个文件,底层依赖于联合文件系统(UnionFS)。
什么是UnionFS?
UnionFS是一种分层、轻量级、高性能的文件系统,支持对文件系统的修改作为一次提交来层层叠加。这很类似于我们生活中的千层饼或鸡蛋,由蛋黄、蛋清、蛋壳一层一层的最终构成了一个鸡蛋。
UnionFS的特性
联合文件系统最大特点就是分层和联合加载。
在加载时可以一次同时加载多层文件系统,通过联合加载把各层文件系统叠加起来,从外部看只能看到一个文件系统,最终的文件系统保护所有底层的文件和目录。
Docker镜像分层结构及加载原理
由于docker镜像底层采用联合文件系统,自然而然docker镜像也是分层的。docker采用的联合文件系统为aufs (advanced multi layered unification filesystem),是一种可堆叠的联合文件系统。
按照docker官网的说法,docker文件系统分为两层:bootfs
和rootfs
。最底层为bootfs,其上为rootfs
- bootfs:用于系统引导的文件系统,包括bootloader和kernel,容器启动完成后会被卸载以节约内存资源
- rootfs:位于bootfs之上,表现为docker容器的根文件系统
- 传统模式中,系统启动之时,内核挂载rootfs会首先将其挂载为“只读”模式,完整性自检完成后将其重新挂载为读写模式
- docker中,rootfs由内核挂载为“只读”模式,而后通过“联合挂载”技术额外挂载一个“可写”层
当删除容器时,这个容器自有的“可写”层会一起被删除
bootfs层:
bootfs包含了bootloader和linux内核,用户是不能对这层作任何修改的,在内核启动之后,bootfs实际上会unmount掉。
rootfs则包含了一般系统上的常见目录结构,类似于/dev, /proc, /bin等等以及一些基本的文件和命令。
rootfs层:
对于linux上不同版本的问题,docker可以同时运行多个rootfs。
Docker的文件系统是分层的,它的rootfs在mount之后会转为只读模式, Docker在它上面添加一个新的文件系统,来达成它的只读。由于共享一个内核,这也是为什么docker比虚拟机消耗资源更少的根本原因。
images层:
从下图中,我们能看到多个只读的文件系统,Docker中把他们称为层。image是只读的,container部分则是可写的。如果用户想要修改底层只读层上的文件,这个文件就会被先拷贝到上层,修改后驻留在上层,并屏蔽原有的下层文件。
container层:
最后一部分是容器(container), 容器是可读写的。
在系统启动时,Docker会首先一层一层的加载image,直到最先面的base image,这些image都是只读的。最后,在最上层添加可读写的一个容器, 这里存放着诸如unique id,网络配置之类的信息。
docker镜像为什么要分层
docker镜像采用基于联合文件系统的分层结构主要是为了共享公用文件,除了节约存储空间,还能实现对文件的高效管理。
镜像可以通过分层来进行继承,基于父镜像可以制作各种具体的应用镜像。如果你有面向对象编程语言的开发经验,这就很好理解,它类似于继承与多态,子类可以继承父类功能并能派上新功能。
关于镜像的分层,在使用后续的docker pull命令时可以很好的进行验证。比如使用docker pull命令下载一个mysql镜像,将会看到是一层一层的下载。另外如果不同镜像包含相同的公用部分(层),假设之前已经下载过包含了公用层的镜像的话,再下载包含公用层的其他镜像,会提示这些公用层已经存在于本地了,这个镜像的下载过程就不在去下载公用层,整个过程就会明显快很多。
docker存储驱动
docker提供了多种存储驱动来实现不同的方式存储镜像,下面是常用的几种存储驱动:
- AUFS
- OverlayFS
- Devicemapper
- Btrfs
- VFS
AUFS
AUFS(AnotherUnionFS)是一种Union FS,是文件级的存储驱动。AUFS是一个能透明覆盖一个或多个现有文件系统的层状文件系统,把多层合并成文件系统的单层表示。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的,只有最上层的文件系统是可写的。当需要修改一个文件时,AUFS创建该文件的一个副本,使用CoW将文件从只读层复制到可写层进行修改,结果也保存在可写层。在Docker中,底下的只读层就是image,可写层就是Container。
AUFS文件系统据说有3W行代码,而ext4文件系统却只有4000-5000行左右代码,这些代码是要被整合进内核的,后来AUFS申请要被合并进内核代码的时候,linuz觉得它这代码太过臃肿,于是拒绝了。因此AUFS这个文件系统一直以来就不是linux内核中自有的文件系统,想用AUFS这个文件系统的话,必须自己向内核打补丁并去编译使用它,但redhat系列的操作系统一向以稳定著称,不会干这种出格的事,所以在redhat系列操作系统中使用AUFS并无可能。而ubuntu上的docker默认使用的就是AUFS。
OverlayFS
Overlay是Linux内核3.18后支持的,也是一种Union FS,和AUFS的多层不同的是Overlay只有两层:一个upper文件系统和一个lower文件系统,分别代表Docker的镜像层和容器层。当需要修改一个文件时,使用CoW将文件从只读的lower复制到可写的upper进行修改,结果也保存在upper层。在Docker中,底下的只读层就是image,可写层就是Container。目前最新的OverlayFS为Overlay2。
AUFS和Overlay都是联合文件系统,但AUFS有多层,而Overlay只有两层,所以在做写时复制操作时,如果文件比较大且存在比较低的层,则AUSF会慢一些。而且Overlay并入了linux kernel mainline,AUFS没有。目前AUFS已基本被淘汰。
DeviceMapper
Device mapper是Linux内核2.6.9后支持的,提供的一种从逻辑设备到物理设备的映射框架机制,在该机制下,用户可以很方便的根据自己的需要制定实现存储资源的管理策略。AUFS和OverlayFS都是文件级存储,而Device mapper是块级存储,所有的操作都是直接对块进行操作,而不是文件。Device mapper驱动会先在块设备上创建一个资源池,然后在资源池上创建一个带有文件系统的基本设备,所有镜像都是这个基本设备的快照,而容器则是镜像的快照。所以在容器里看到文件系统是资源池上基本设备的文件系统的快照,并没有为容器分配空间。当要写入一个新文件时,在容器的镜像内为其分配新的块并写入数据,这个叫用时分配。当要修改已有文件时,再使用CoW为容器快照分配块空间,将要修改的数据复制到在容器快照中新的块里再进行修改。
OverlayFS是文件级存储,Device mapper是块级存储,当文件特别大而修改的内容很小,Overlay不管修改的内容大小都会复制整个文件,对大文件进行修改显然要比小文件要消耗更多的时间,而块级无论是大文件还是小文件都只复制需要修改的块,并不是整个文件,在这种场景下,显然device mapper要快一些。因为块级的是直接访问逻辑盘,适合IO密集的场景。而对于程序内部复杂,大并发但少IO的场景,Overlay的性能相对要强一些。
docker registry
启动容器时,docker daemon会试图从本地获取相关的镜像,本地镜像不存在时,其将从Registry中下载该镜像并保存到本地。
Registry用于保存docker镜像,包括镜像的层次结构和元数据。用户可以自建Registry,亦可使用官方的Docker Hub。
docker registry的分类:
- Sponsor Registry:第三方的Registry,供客户和Docker社区使用
- Mirror Registry:第三方的Registry,只让客户使用
- Vendor Registry:由发布docker镜像的供应商提供的registry
- Private Registry:通过设有防火墙和额外的安全层的私有实体提供的registry
docker registry的组成:
- Repository
- 由某特定的docker镜像的所有迭代版本组成的镜像仓库
- 一个Registry中可以存在多个Repository
- Repository可分为“顶层仓库”和“用户仓库”
- 用户仓库名称格式为“用户名/仓库名”
- 每个仓库可包含多个Tag(标签),每个标签对应一个镜像
- Index
- 维护用户帐户、镜像的检验以及公共命名空间的信息
- 相当于为Registry提供了一个完成用户认证等功能的检索接口
Docker Registry中的镜像通常由开发人员制作,而后推送至“公共”或“私有”Registry上保存,供其他人员使用,例如“部署”到生产环境。
docker镜像的制作
Docker Image 的制作两种方法
方法 1:docker commit #保存 container 的当前状态到 image 后,然后生成对应的 image
方法 2:docker build #使用 Dockerfile 文件自动化制作 image
方法 3:Docker Hub 自动构建
基于容器来制作镜像
docker commit : 从容器创建一个新的镜像。
docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]
OPTIONS 说明:
- -a : 提交的镜像作者;
- -c : 使用 Dockerfile 指令来创建镜像;
- -m : 提交时的说明文字;
- -p : 在 commit 时,将容器暂停。
[root@localhost ~]# docker pull busybox
Using default tag: latest
latest: Pulling from library/busybox
61c5ed1cbdf8: Pull complete
Digest: sha256:4f47c01fa91355af2865ac10fef5bf6ec9c7f42ad2321377c21e844427972977
Status: Downloaded newer image for busybox:latest
docker.io/library/busybox:latest
[root@localhost ~]# docker run --name bi -it busybox
/ # ls
bin dev etc home proc root sys tmp usr var
/ # mkdir data
/ # echo 'busybox test page' > data/index.html
/ # cat data/index.html
busybox test page
在创建镜像时,我们不能关闭容器,必须使其处于运行状态,所以我们必须要另起一个终端,然后执行
[root@localhost ~]# docker commit -p bi
sha256:adb6814ee79ed4bc761601d89b427b0f0762ca7ba4418fb5b180533b7d091929
[root@localhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> adb6814ee79e 3 seconds ago 1.22MB
busybox latest 018c9d7b792b 4 weeks ago 1.22MB
[root@localhost ~]# docker tag adb6814ee79e evereternity/bi:v0.1
[root@localhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
evereternity/bi v0.1 adb6814ee79e 46 seconds ago 1.22MB
busybox latest 018c9d7b792b 4 weeks ago 1.22MB
[root@localhost ~]# docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: evereternity
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
[root@localhost ~]#
[root@localhost ~]# docker push evereternity/bi:v0.1
The push refers to repository [docker.io/evereternity/bi]
d7e08212e4fc: Pushed
514c3a3e64d4: Mounted from library/busybox
v0.1: digest: sha256:7a65f0e0d46fb7b71e0381128355b91f5ef071ac155503f6dc706ead8012d99e size: 734
使用新生成的镜像创建容器
[root@localhost ~]# docker pull evereternity/bi:v0.1
v0.1: Pulling from evereternity/bi
Digest: sha256:7a65f0e0d46fb7b71e0381128355b91f5ef071ac155503f6dc706ead8012d99e
Status: Image is up to date for evereternity/bi:v0.1
docker.io/evereternity/bi:v0.1
[root@localhost ~]# docker run --name t1 -it evereternity/bi:v0.1
/ # ls
bin data dev etc home proc root sys tmp usr var
/ # ls data/
index.html
/ # cat data/index.html
busybox test page
新生成的镜像中是包含了新增的内容的,但容器默认要启动的进程sh进程,但我们是要启动一个http站点,所以我们要在创建镜像时将容器默认启动的进程设为httpd,这样一来我们就可以通过新生成的镜像来快速构建一个简单的http站点了。
使用docker inspect
命令查看b1容器启动的默认进程是什么
[root@localhost ~]# docker inspect t1
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"sh"
],
"Image": "evereternity/bi:v0.1",
重新生成镜像并上传
[root@localhost ~]# docker commit -a 'evereternity' -c 'CMD ["/bin/httpd","-f","-h","/data"]' -p t1 evereternity/bi:v0.2
sha256:3e06e84549155f943da9472741379f39ff8acf716a1c1b306c1e6114e8b2ce27
[root@localhost ~]# docker push evereternity/bi:v0.2
The push refers to repository [docker.io/evereternity/bi]
99025c58a57d: Pushed
d7e08212e4fc: Layer already exists
514c3a3e64d4: Layer already exists
v0.2: digest: sha256:95fc7c9a5b69c7cd282dfd86caaefc6d51138d242a20652ce20d03f63db8f454 size: 941
[root@localhost ~]# docker run --name t2 -d evereternity/bi:v0.2
bef1dce3a48cec71f827f2667501892de05b88576c7efca8c8a0be3f306b0768
[root@localhost ~]# docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bef1dce3a48c evereternity/bi:v0.2 "/bin/httpd -f -h /d…" 13 seconds ago Up 11 seconds t2
f59bd30e08b0 evereternity/bi:v0.1 "sh" 12 minutes ago Up 12 minutes t1
使用docker inspect
命令查看t2容器启动的默认进程是什么,以及其IP地址,然后用curl命令访问该IP,看是否能访问到网页
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"NetworkID": "2aa6262694d84c71a2781260ae81343b188b66a169247fa3e533867048b4f265",
"EndpointID": "0a2232af8b2a20c5e5597d35261c268f289971618a48eed251c6797adc11807b",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.3",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
#访问
[root@localhost ~]# curl 172.17.0.3
busybox test page
镜像的导入和导出
docker中我们使用docker save
进行导出,使用docker load
进行导入。
save 和 export
save 保存的是镜像,export 保存的是容器
load 和 import
load 载入镜像包,import 载入容器包,但两者都会恢复为镜像
load 不能对载入的进行进行命名,import 可以
save
docker save : 将指定镜像保存成 tar 归档文件。
docker save [OPTIONS] IMAGE [IMAGE...]
OPTIONS 说明:
- -o : 输出到的文件。
将镜像 runoob/ubuntu:v3 生成 my_ubuntu_v3.tar 文档
[root@localhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
evereternity/bi v0.2 3e06e8454915 14 minutes ago 1.22MB
evereternity/bi v0.1 adb6814ee79e 33 minutes ago 1.22MB
nginx latest 4bb46517cac3 2 weeks ago 133MB
busybox latest 018c9d7b792b 4 weeks ago 1.22MB
[root@localhost ~]# docker save -o busybox_v0.2.gz evereternity/bi:v0.2
[root@localhost ~]# ls
anaconda-ks.cfg busybox_v0.2.gz
load
docker load : 导入使用 docker save 命令导出的镜像。
docker load [OPTIONS]
OPTIONS 说明:
- --input , -i : 指定导入的文件,代替 STDIN。
- --quiet , -q : 精简输出信息。
[root@localhost ~]# ls
anaconda-ks.cfg busybox_v0.2.gz
#导入镜像
[root@localhost ~]# docker load -i busybox_v0.2.gz
Loaded image: evereternity/bi:v0.2