Ⅰ Docker镜像
1.像一个文件联合系统UnionFS，是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下，Union 文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。
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 等标准目录和文件
对于一个精简的OS，rootfs可以很小，只需要包括最基本的命令、工具和程序库就可以了，因为底层直接用Host的kernel，自己只需要提供 rootfs 就行了。由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs。
3.镜像分层的好处就是资源共享
列如：有多个镜像都从相同的 base 镜像构建而来，那么宿主机只需在磁盘上保存一份base镜像，
同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。而且镜像的每一层都可以被共享。
4.docker 镜像都是只读的，当容器启动时，一个新的可写层会加载到镜像的顶部，这一层被称为容器层，容器层之下都称为镜像层。
5.镜像的构建可以通过 Dockfile 和docker commit 这两种方式
docker commit 方式是在一个镜像的基础上，重新对该镜像操作后重新生成的一个专属的镜像。
命令格式 docker commit -m "提交的描述信息" -a "作者信息" 容器ID 要创建的目标的镜像名:[标签名]
示例
Ⅱ 本地的镜像文件都存放在哪里
于Docker相关的本地资源存放在/var/lib/docker/目录下，其中container目录存放容器信息，graph目录存放镜像信息，aufs目录下存放具体的镜像底层文件。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。 如果我的回答能够对您有帮助的话，求给大大的赞。
Ⅲ windows7版本下的docker 镜像文件存放位置在本地哪个文件夹
方案1, 使用参数-g 来修改 Docker 的镜像存储文件夹.
修改方法如下:
在 Ubuntu/Debian 系统下:
编辑 /etc/default/docker 文件, 添加-g 参数的设置, 如下:
DOCKER_OPTS="-dns 8.8.8.8 -dns 8.8.4.4 -g /mnt"
在 Fedora/Centos 系统下:
编辑 /etc/sysconfig/docker 文件, 添加-g 参数的设置, 如下:
other_args="-g /mnt"
重启 Docker 服务, 问题就解决了.
方案2 使用链接
1) 停止 Docker: service docker stop.
2) 做个备份 tar -zcC /var/lib/docker > /mnt/var_lib_docker-backup-$(date + %s).tar.gz
3) 迁移/var/lib/docker目录到met 目录下: mv /var/lib/docker /mnt/docker
4) 建个 symlink: ln -s /mnt/docker /var/lib/docker
5) 确认文件夹类型为symlink 类型 ls /var/lib/docker
6) 启动 docker service.
Ⅳ 介绍——修改cache.img（缓存镜像）
缓存镜像用于存储系统或用户应用产生的临时数据，通常的镜像文件名为chche.img。一般ROM并不需要包含缓存镜像，不过在这里还是介绍一下如何制作和刷缓存镜像。
缓存镜像实际上就是一个空的ext4格式的文件系统镜像，可以使用下面的命令生成缓存镜像。
mkdir -p /mnt/rom/cache
make_ext4fs -s -l 256M -a cache cache.img /mnt/rom/cache
可以使用下面的命令刷缓存镜像。
adb reboot bootloader
fastboot flash cache cache.img
fastboot reboot
Ⅳ Docker镜像存储格式分析
新版本的docker镜像存储其实是很绕的，各种ID和目录定义较多，不是很直观，本文较详细的分析一下镜像本地存储和在registry存储的格式。测试用的docker版本是20.10.9，存储引擎overlay2。
为了方便分析镜像层级结构，我们基于ubuntu加两个文件，使用 docker build -t myubuntu . 创建一个新镜像myubuntu。
镜像元数据存储在 /var/lib/docker/image/overlay2 ：
imagedb目录存储的是镜像元数据。
镜像ID是从Image Json文件得到的，即 sha256sum(ImageJson)。
Layer DiffID是没有压缩的对应层的tar文件的sha256sum值。当然，打包和截包文件的适合得保证是可以可重复操作的，不然会导致Layer的DiffID出错(可以使用tar-split保存tar headers)。比如上面例子中ubuntu镜像只有一层，diff_ids列表只有 (history里面的CMD不占磁盘空间） "sha256:"。每一层的tar文件我们可以通过 docker save ubuntu -o ubuntu.tar 得到，解压ubuntu.tar后可以得到对应的层级的打包后的layer.tar文件，如下可以验证DiffID的值计算原理。
ChainID用于标识镜像层级栈，它的值由DiffID计算得来。ChainID对应的layer目录是 /var/lib/docker/image/overlay2/layerdb/sha256 ，这下面的目录就是ChainID，其中内容存储了镜像的层级栈关系。比如这一层的parent是什么，以及对应的镜像数据存储目录的cache_id。本身layerdb只是存储layer的元数据信息，并不存储实际镜像数据。
即最底层的ChainID跟DiffID一样，而其他层的ChainID则是通过计算从最底层到这层的Digest得到。
查看Image Json文件可以看到myubuntu相比ubuntu的diff_ids加了两层，imagedb目录下面也多了两个镜像元数据信息文件，对应新增加的两层镜像。
除了之前的350f...对应ubuntu，其中7c7e是one.txt那层，而a58f则是two.txt那层。
我们可以看下ChainID目录下的内容，可以看到除了ubuntu的基础层，其他层都有一个文件parent，值就是父层的diff_id，diff是diff_id值，cache-id则是镜像实际存储目录，位于 /var/lib/docker/overlay2/{cache-id} ，size是这一层实际增加文件的大小，tar-split.json.gz是打包这层镜像的配置（参考 https://github.com/vbatts/tar-split )。
CacheID是一个uuid值，每次都不一样。它对应的目录 /var/lib/docker/overlay2/${CacheID} ，该目录存储了镜像每层文件和下一层的链接等。验证一下：
其中diff目录下面便是这一层的文件。link是对应的diff目录的短链接，lower则是下一层diff目录的短链接。
在layerdb目录的size文件可以看到每一层的镜像大小，但是加起来跟 docker images 显示的大小会有点差距，比如myubuntu镜像每一层计算加起来是 4 + 65593591 + 4 = 65593599 / 1024 / 1024 = 62.55MiB ，实际显示是 65.6MB，这是因为 docker images 里面计算是按 65593599/1000/1000=65.59 计算的。
另外，因为镜像每层记录的是相对前一层的文件变化，即便删除了文件和软件包，新镜像大小也不会变小。除非使用 docker export 重新导出一个新镜像。
这个目录存储的是layer diffid和digest的关系，其中digest是镜像仓库里面的目录ID。
其中 v2metadata-by-diff存储了layer diffid对应在镜像仓库的信息，包括digest，sourcerepository等。
diffid-by-digest则是反过来的，文件名是仓库里面的layer digest，内容是layer diffid。因为我们新加的镜像myubuntu并没有push到仓库，所以这个目录下面没有信息。
我们创建一个本地的registry，然后对myubuntu另外打个tag， docker tag myubuntu 127.0.0.1:5000/myubuntu ，则respositories.json会多一条新的记录。此时，distribution目录还没有变化。
当我们执行 docker push 127.0.0.1:5000/myubuntu ，则会发现distribution的两个目录分别多了两条记录，对应的是myubuntu的 7c7e... 和 a58f... 两个diffid。此时repository.json里面 127.0.0.1:5000/myubuntu 会多一条带digest的记录，这就是镜像仓库里面对应的digest。其中push时显示的 digest:sha256:bb3c... 对应的是registry的manifest文件的digest，下一节分析。
registry中存储的镜像文件是经过gzip压缩，比如myubuntu本地大小是65.6MB，推到registry压缩后大小约27MB，压缩比还是不错的。registry存储目录如下，主要分为blobs和repositories两个目录。
repositories的一级子目录是镜像名，这里是myubuntu。下面对应三个子目录 _manifests，_layers, _uploads。
blobs存储的内容除了各镜像layer的压缩后的文件，还包括Manifest Json和Image Json文件(未压缩)。
选一个layer的压缩文件data解压看一下内容：
另外需要注意的是， docker pull 时前面显示的值是对应层在registry的压缩文件的digest值，并不是layer diffid，size也是registry存储的压缩文件大小。