docker镜像管理分析以及retag的实现

在容器化部署的场景下，镜像管理是一个很重要的部分，毕竟所有的程序都是以镜像的方式来交付和运行的。

一个标准的镜像名称分为三个部分：镜像仓库地址/镜像存储库:镜像版本，比如http://hub.docker.io/library/redis:1.0

镜像仓库地址：镜像仓库服务器的域名，比如docker官方镜像仓库http://hub.docker.io

镜像存储库：镜像的存储名称，官方名称repository，比如library/redis

镜像版本：镜像的版本，官方名称tag，比如1.0

众所周知，docker镜像是以分层来存储镜像的，而这个层是分仓库管理的，比如library/redis下的层和private/redis下的层是分开管理的，通过docker registry的api获取到的library/redis下的层在private/redis下是不存在的。

再介绍一下镜像的pull和push过程：

pull操作：

1. 先拉取清单文件
2. 再拉取镜像层

push操作：

1. 先上传所有层到仓库
2. 最后上传清单文件

镜像retag功能实现的原理就是利用了pull的拉取清单文件和push的上传清单文件

通过上面的分析，在做镜像的retag时，就需要考虑retag后的镜像是否是同一个仓库下的，如果是同一个repository下的retag操作，比如library/redis:1.0，在retag后成library/redis:1.1，那么就表示是在同一个repository下，就不需要使用挂载操作，官方称为Cross Repository Blob Mount（交叉挂载层），如果library/redis:1.0在retag后变为private/redis:1.0，由于不在同一个repository下，因此必须要进行mount操作才行，不然在push清单文件的时候会报错，具体步骤如下：

1. 拉取library/redis:1.0的清单文件，相关的API：

   GET /v2/<name>/manifests/<reference>

2. 检查清单文件中的层，如果retag的目标repository与第一步拉取的清单文件的repository不是同一个，进行mount层操作： 

   POST /v2/<name>/blobs/uploads/?mount=<digest>&from=<repository name>

    

3. 上传清单文件到目标repository中，完成retag

   PUT /v2/<name>/manifests/<reference>

    

整个retag的过程就是这样了。