文章目录
- [1、Docker Image（镜像）](#1、Docker Image（镜像）)
- 2、镜像命令详解
-
- [2.1 docker rmi](#2.1 docker rmi)
- [2.2 docker save](#2.2 docker save)
- [2.3 docker load](#2.3 docker load)
- [2.4 docker image inspect](#2.4 docker image inspect)
- [2.5 docker history](#2.5 docker history)
- [2.6 docker image prune](#2.6 docker image prune)
- 3、镜像综合实战
-
- [3.1 离线镜像迁移](#3.1 离线镜像迁移)
- [3.2 镜像存储的压缩与共享](#3.2 镜像存储的压缩与共享)
1、Docker Image（镜像）
Docker 镜像是什么
- Docker image 本质上是一个 read-only 只读文件， 这个文件包含了文件系统、源码、库文件、依赖、工具等一些运行 application 所必须的文件
- 我们可以把 Docker image 理解成一个模板， 可以通过这个模板实例化出来很多容器
- image 里面是一层层文件系统 Union FS。联合文件系统，可以将几层目录挂载到一起，形成一个虚拟文件系统
每一层文件系统我们叫做一层 layer，联合文件系统可以对每一层文件系统设置三种权限，只读（readonly）、读写（readwrite）和写出（whiteout-able），但是 docker 镜像中每一层文件系统都是只读的
构建镜像的时候，从一个最基本的操作系统开始，每个构建的操作都相当于做一层的修改，增加了一层文件系统。一层层往上叠加，上层的修改会覆盖底层该位置的可见性，这也很容易理解，就像上层把底层遮住了一样。当你使用的时候，你只会看到一个完全的整体，你不知道里面有几层，也不清楚每一层所做的修改是什么
镜像生活案例
镜像相当于我们 java 或者 C++中的类，相当于一个模板，可以很方便的构建出来不同的对象
我们以日常的地板为例，开发商的房子提供给用户的时候一般是做好了地暖，而这些地暖其实是一层一层添加的，最底层的钢筋水泥层，然后添加保温层，采暖管，再铺设水泥层，到最后交付的时候家家户户都是水泥面，这一层一般是不可修改的，最上层用户一般会再铺设商木地板或者地板砖每家每户的选择不一样，相当于我们镜像的容器层
为什么需要镜像
在部署应用时，通过手工或写一些脚本的方式进行部署。这样部署面临问题就是云端和本地环境一致问题。用户为每个应用打包过程比较繁琐，需要配置和给中修改等操作，非常费劲
然而，Docker 镜像就是为了解决这个小小的打包功能，突然一夜之间成名。那么，你可能说 Docker 镜像就是个压缩包，是的，你猜对了，它就像一个压缩包文件。它是如何解决 Paas 时代所面临的云端和本地一致性问题？很简单，它是把一个镜像制作成一个完整的操作系统所有文件和对应的目录结构，这样的压缩包是跟你本地和测试环境用的操作系统一摸一样
docker 最大的贡献就是定义了容器镜像的分层的存储格式，docker 镜像技术的基础是联合文件系统(UnionFS)，其文件系统是分层的。这样既可以充分利用共享层，又可以减少存储空间占用
docker 镜像提供了一种打包应用程序和预配置服务器环境的便捷方式，可以很方便的将其用于个人用途或与其他 Docker 用户公开共享
2、镜像命令详解
镜像命令清单
| 命令 | 别名 | 功能 |
|---|---|---|
| docker images | docker image ls/docker image list | 列出本地镜像 |
| docker tag | docker image tag | 给镜像打标签，可用于推送镜像仓库 |
| docker pull | docker image pull | 从镜像仓库拉取镜像 |
| docker push | docker image push | 推送镜像到仓库 |
| docker rmi | docker image rm/ docker image remove | 删除本地镜像 |
| docker build | docker image build | 通过 dockerfile制作镜像 |
| docker save | docker image save | 将指定镜像保存成 tar 归档文件 |
| docker load | docker image load | 导入使用docker save 命令导出的镜像 |
| docker image inspect | 查看镜像详细信息 | |
| docker history | docker image history | 查看镜像历史 |
| docker import | docker image import | 从归档文件docker export中创建镜像 |
| docker image prune | 删除不使用的镜像 |
2.1 docker rmi
docker rmi
删除本地镜像
bash
docker rmi [OPTIONS] IMAGE [IMAGE...]别名
bash
docker image rm, docker image remove关键参数
-f :强制删除
- -no-prune :不移除该镜像的过程镜像，默认移除
通过 repository:rag 删除
也可以通过 image id 删除
如果镜像有对应的容器，此时仅仅使用rmi是无法删除的
因此需要用到 -f 参数
2.2 docker save
docker save
将指定镜像保存成 tar 归档文件
bash
docker save [OPTIONS] IMAGE [IMAGE...]别名
bash
docker image save关键参数
-o :输出到的文件
打包一个镜像到文件
打包多个镜像到文件
2.3 docker load
docker load
导入使用 docker save 命令导出的镜像
bash
docker load [OPTIONS]别名
bash
docker image load关键参数
-
-input , -i : 指定导入的文件，代替 STDIN
-
-quiet , -q : 精简输出信息
测试 -q 参数，精简输出信息
2.4 docker image inspect
docker image inspect
查看镜像详细信息
bash
docker image inspect [OPTIONS] IMAGE [IMAGE...]注意事项：
docker inspect 会自动检查是镜像还是容器然后显示相应信息
2.5 docker history
docker history
显示镜像历史
bash
docker history [OPTIONS] IMAGE别名
bash
docker image history关键参数
-H，- -human :大小和日期采用人容易读的格式展现
- -no-trunc :显示全部信息，不要隔断
-q，--quiet: 只显示镜像 id 信息
参看nginx:1.23.4的历史信息
2.6 docker image prune
docker image prune
删除不使用的镜像
不适用的镜像有两种，只要容器不使用，就认为它是不使用的镜像
第二种叫虚悬镜像或者空悬镜像，它的REPOSITORY和TAG都是null
bash
docker image prune [OPTIONS]关键参数
-a，- -all：删除全部不使用的镜像
- -filter filter：指定过滤条件
-f，- -force：不提示是否删除
docker image prune
docker image prune -a
3、镜像综合实战
3.1 离线镜像迁移
从服务器1上拉去一个镜像，我这里的拉的是自己仓库的镜像，是centos7的镜像
拉取成功后，将这个镜像打包成tar文件
将这个tar文件从服务器1上拷贝到服务器2上，使用scp命令
bash
scp 【本地文件的路径】【对端服务器用户名】@【对端服务器地址】:【对端服务器上存放文件的路径】拷贝成功后，在服务器2上对应的目录下查看是否有对应的tar文件
此时服务器2还需要安装docker(自行安装)，不然就无法使用对应的docker 命令，也就无法加载这个tar文件
使用 load -i 命令进行加载
加载成功，测试一下这个镜像，结果没啥问题
3.2 镜像存储的压缩与共享
镜像存储之压缩
拉取 nginx 镜像，如果本地没有，镜像是从仓库拉取，如果有会提示镜像已经存在，并且是最新的
查看nginx:1.21.4的大小
查看机器的CUP架构，再去docker hub 上找对应CPU架构的nginx:1.21.4的大小
docker hub 仓库里面的nginx镜像为54.08MB，将它拉到自己的服务上，结果成为了141MB，为什么呢？
因为镜像在服务端(docker hub)的时候是经过压缩的，拉到本地时就自动进行了解压
这么做的主要原因是镜像在服务端压缩，存储占用空间少，并且其他人在拉取镜像时，传输的数据包更小，就节省了带宽
将这个nginx镜像打一个标签，再推送到自己的仓库去
推送完成后，再去自己的仓库看一下， 发现镜像又被压缩了
镜像存储之共享
拉取nginx:1.21.3
给nginx:1.21.3多次打标签，再上传到自己的仓库
这里出现了Mount from library/nginx，并没有把本地的镜像推送到仓库，因为发现服务端有，所以直接使用了library/nginx里的
推送第二个
直接就告诉我们对应的层已经存在了
推送第三个，第四个都是如此
因此：添加一个新的镜像到我们的仓库的时候，如果 docker hub 发现已经有了是 mount的，不是从本地推上去的