docker image 的sha256 digest摘要
背景：
sha256 digest摘要信息到底是用来干啥的？
harbor从2.0.0版本开始，docker pull命令复制下来的镜像名长这样：
docker pull harbor.avlyun.org/c-web/[email protected]:38f3f34301cec3cabd9de3f65f2b313ed7e44d6b211254e7156d12229c5b459f
ps:@后面的那串东西，其实就是镜像本身的sha256的指纹信息，当然你还是可用通过"镜像地址/镜像名：版本号"来拉取镜像。
探究：
官网说明文档
以下是粗略的翻译：
默认情况下，用户可以通过docker push命令，多次推送镜像名（imagename:tagname）完全相同的镜像到darbor私有化仓库中，就会导致后一次的推送会把前一次的镜像覆盖掉，导致相同的image tag实际上指向的不同的镜像（镜像内容不同，只是镜像名和tag名相同，在自动化构建过程中，若你一直使用相同的镜像名和latest），同时旧镜像的tag会被改为none；
导致这个情况出现的原因是，docker的实现上，并没有强制给与image tag和image digest的映射关系。这样在一些场景下，镜像版本就混乱了，image tag不能真实的反应新旧镜像的image version。但是sha256摘要仍然是可靠的，并且总是指向每一次相同的构建，唯一的缺点是sha256的摘要信息不是以人类可读的格式呈现的。
下面这个截图是harbor镜像仓库，特定项目下的一个镜像的历史版本列表，注意红框部分：
如何查看某个镜像的摘要信息？
docker images --digest
可以查看sha256的值：
harbor上的镜像摘要信息和你docker image生成时，自带的那个摘要信息是一致的；
换句话说，摘要信息是在image生成阶段就确定了，不会变更了。可以作为镜像的唯一标志。你如果把镜像当成一个文件，那么sha256的摘要信息就是文件的指纹。
下面额外分享一个给镜像打版本号的规范，
参考某位大佬的jenkins构建流程的日志发现的：
上图是jenkins构建流程的一个截图，重点是红框部分，给镜像的tag定义为"分支名_commitid"
可以借鉴一下，相当于从镜像的tag上，就知道了这次镜像的来源分支是啥，当前分支的最新commitid是多少，便于排查当前镜像所含代码的版本！！！
harbor上面也可以配置镜像的推送规则，例如：不允许同一个镜像（镜像名+tag相同），不能连续推送两次。