Docke--利用 commit 理解构建镜像

时间:2022-12-26 23:43:47

Docker 利用commit理解构建镜像

镜像是容器的基础,每次执行 docker run 的时候都会指定哪个镜像作为容器运行的基础。当我们使用Docker Hub的镜像无法满足我们的需求时,我们就需要自己定制镜像来满足我们的需求。

镜像是多层存储,每一层是在前一层的基础上进行的修改;而容器同样也是多层存储是在以镜像为基础层,在基础层上加一层作为容器运行时的存储层。

示例说明镜像是如何构建的。

[root@server ~]# docker run --name webServer -d -p 80:80 nginx:1.11  #启动一个容器,基于docker hub上面的nginx:1.11镜像

这条命令会用 nginx:1.11 镜像启动一个容器,命名为 webServer,并且映射了80 端口,这样便可以去访问这个 nginx 服务器。然后我们直接访问宿主机的IP可以看到Nginx的欢迎页面Docke--利用 commit 理解构建镜像

现在,假设我们不喜欢这个欢迎页面,我们喜欢改成别的文字,我们可以使用docker exec 命令进入到容器,修改其内容给

root@714830c04e5e:/# echo '<h1>Hello Docker Nginx Server</h1>' >/usr/share/nginx/html/index.html   #修改默认首页的内容
root@714830c04e5e:/# exit
exit

已交互式终端方式进入 webServer 容器,并执行了 bash命令, 也就是获得了一个可操作的shell。然后覆盖了index.html内容,再次刷新浏览器,会发现内容被改变了。

Docke--利用 commit 理解构建镜像

修改了容器的文件,也就是改动了容器的存储器,可以通过 docker diff 命令查看具体的改动

[root@server ~]# docker diff webServer  #查看webServer容器改动的内容
C /var
C /var/cache
C /var/cache/nginx
A /var/cache/nginx/scgi_temp
A /var/cache/nginx/uwsgi_temp
A /var/cache/nginx/client_temp
A /var/cache/nginx/fastcgi_temp
A /var/cache/nginx/proxy_temp
C /root
A /root/.bash_history
C /usr
C /usr/share
C /usr/share/nginx
C /usr/share/nginx/html
C /usr/share/nginx/html/index.html
C /run
A /run/nginx.pid

现在我们定制好了变化,我们希望能将其保存下来形成镜像。要知道,当我们运行一个容器的时候(如果不使用卷的话),我们做的任何文件修改都会被记录于容器存储器里。而Docker提供了一个 docker commit 命令,可以将容器的存储层保存下来称为镜像。也就是说在原有镜像的基础上,再叠加上容器的存储层,并构成新的镜像。以后我们在运行这个新镜像的时候,就会拥有原有容器最后的文件变化。

docker commit 语法格式:

docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]

 示例将上面更改首页的webServer 容器保存为镜像:

[root@server ~]# docker commit \
--author "Bu Ji <381347268@qq.com>" \
--message "修复了默认首页" \
webServer \
nginx:v1

[root@server ~]# docker images nginx   #查看制作完成的nginx镜像
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               v1                  b639fbcc5ec4        2 minutes ago       183MB
nginx               1.11                5766334bdaa0        21 months ago       183MB

 其中 --author 是指定修改的作者,而 --message 则是记录本次修改的内容。这点和 git 版本控制器相似。还可以使用 docker history 具体查看镜像内的历史记录

[root@server ~]# docker history nginx:v1  #查看nginx:v1镜像的历史记录
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
b639fbcc5ec4        5 minutes ago       nginx -g daemon off;                            157B                修复了默认首页
5766334bdaa0        21 months ago       /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon…   0B                  
<missing>           21 months ago       /bin/sh -c #(nop)  EXPOSE 443/tcp 80/tcp        0B                  
<missing>           21 months ago       /bin/sh -c ln -sf /dev/stdout /var/log/nginx…   22B                 
<missing>           21 months ago       /bin/sh -c echo "deb http://nginx.org/packag…   59.1MB              
<missing>           21 months ago       /bin/sh -c set -e;  NGINX_GPGKEY=573BFD6B3D8…   4.9kB               
<missing>           21 months ago       /bin/sh -c #(nop)  ENV NGINX_VERSION=1.11.13…   0B                  
<missing>           21 months ago       /bin/sh -c #(nop)  MAINTAINER NGINX Docker M…   0B                  
<missing>           21 months ago       /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B                  
<missing>           21 months ago       /bin/sh -c #(nop) ADD file:4eedf861fb567fffb…   123MB 

新的镜像定制好后,我们来运行这个镜像

[root@server ~]# docker run --name web1 -d -p 81:80 nginx:v1  #基于上面新建的nginx:v1启动一个名字为web1的容器

 当我们访问宿主机IP:81时候,其内容和之前修改后的 webServer一样

Docke--利用 commit 理解构建镜像

至此,完成了一个定制镜像,使用的是 docker commit 命令,手动给旧的镜像添加了新的一层,形成了新的镜像,对镜像多层存储应该有了很直观的感受。

慎用 docker commit

使用 docker commit 命令虽然可以比较直观的帮助理解镜像分层存储的概念,但是实际环境中很少这样使用。

首先, 从上面的 docker diff webServer 的结果中,可以发现除了真正想要修改的 /usr/share/nginx/html/index.html 文件外,由于命令的执行,还有很多文件被改动或添加了。这还只是最简单的操作,如果安装软件包、编译构建,那么有大量的无关内容被添加进来,如果不小心清理,将会导致镜像为臃肿。

此外,使用docker commit 意味着所有对镜像的操作都是黑箱操作,生成的镜像也被称为黑箱镜像,换句话说,就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像,别人根本无法从知。虽热docker diff 或许可以告诉得到一些线索,但是远远不到可以确保生成一致镜像的地步。这种黑箱镜像的维护工作是非常痛苦的。

而且,除当前层外,之前的每一层都是不会发生改变的,也就是说,任何修改的结果仅仅是在当前层进行标记、添加、修改,而不会改动上一层。如果使用 docker commit 制作镜像,以及后期修改的话,每次一次修改都会让镜像更加臃肿一次,所删除的上一层的东西并不会丢失,会一直如影随形的跟着这个镜像,即使根本无法访问到。这会让镜像更加臃肿。