该章的笔记只对稍微难一点的知识点做记录,简单的就不会进行赘述了。


目录

  • 悬虚镜像(dangling)
  • 镜像和分层
  • 共享镜像层
  • 镜像散列值
  • 困境(push pull时,镜像压缩到值散列值变化)
  • 解决方案(每个镜像层包含一个分发散列值Distribution Hash,不受镜像压缩影响)


镜像包含:镜像层、元数据信息(entrypoint等信息)

悬虚镜像(dangling)

悬虚镜像:没有标签的镜像
产生原因:构建的新镜像A,镜像A取名字时与一存在的镜像B重名。镜像B此时就是悬虚镜像。

  • 移除全部悬虚镜像命令:docker image prune
  • 移除全部悬虚镜像及没有起容器的镜像:docker image prue -a
  • 显示全部悬虚镜像:docker image ls --filter dangling=true

镜像和分层

docker镜像是由一层层耦合的镜像组成的。整体单个同一对象称为“镜像”。

docker查看镜像拉取地址 docker查看镜像层_docker查看镜像拉取地址

  • 查看docker镜像分层命令:docker image inspect。

如何实现镜像堆栈,以及对镜像层对外保持统一的文件系统?

  • 通过存储引擎系统:新版本采用快照机制。
  • docker存储引擎:AUFS、Overlay2、Device mapper、Btrfs、ZFS。目前我仅仅用过Overlay2。
  • 存储引擎(Snapshotter)具有功能:镜像分层、镜像共享、写时复制(Cow)。

共享镜像层

多个 镜像之间会共享镜像层、用以节省空间。

docker查看镜像拉取地址 docker查看镜像层_存储引擎_02


上图中 Already exists显示共享镜像层一存在该层镜像。

镜像散列值

每个镜像都有个一个唯一ID,称为镜像内容散列值,它是根据镜像内容进行加密得到的加密散列值。任何内容改动都会改变散列值

困境(push pull时,镜像压缩到值散列值变化)

镜像在拉取、推送时会对镜像层进行压缩、用以节省存储空间和网络带宽。但是压缩前后docker hub都会对镜像重新进行散列值计算,导致无法进行校验。*压缩不代表分层镜像包含内容值改变)。

解决方案(每个镜像层包含一个分发散列值Distribution Hash,不受镜像压缩影响)

每个镜像层包含一个分发散列值,在传输过程中没层同时包含一个分发散列值会检验拉取镜像是否被修改过,不受镜像压缩影响。

这种模型提升了镜像的安全性,在拉取和推送后可确认内容一致。