为持续交付创建大量Docker标记是否存在任何问题？
问题描述：
目前我们有Jenkins作业配置为释放我们的服务，其他人将其部署到测试，舞台和产品。作为发布工作的一部分，我们创建了一个包含服务二进制文件（及其所有依赖项）的Docker镜像，该镜像被推送到我们的专用Docker存储库（使用新版本创建一个新标签）。到目前为止，这很好用，因为可以很容易地将Jenkins的这个（或更早版本）版本部署到我们不同的环境中，或者只需要拉取特定版本的服务并在本地运行。我的问题是，如果我们转向持续交付，这种方法是否行得通？我们的想法是，在每次成功构建之后，我们创建一个新的Docker标记并推送到我们的私人回购站，并将图像部署到测试环境。我担心的是，如果每天都要做好几次，那么会有很多Docker标签/图层需要下载。恐怕随着时间的推移，需要很长时间才能拉出图像（也许还有其他我不知道的问题）？为持续交付创建大量Docker标记是否存在任何问题？
所以要改写这个问题更清楚：
- 它是罚款创造了很多泊坞标签或者是这个东西， 应避免？
- 最好是有一个基础镜像（操作系统等），然后从源代码管理系统中的标签构建服务二进制文件，然后构建一个映像，然后在部署时将其传输到不同的环境中？
- 其他建议？
答
- 公共注册表可以很好地处理多个标记。想想定期发布的1000张图像。 Docker客户端和注册表之间不需要标记同步，只需确保您的注册表足够强大即可应对。作为测试过程的一部分，我假设你拉下特定的图像和标签？
- 基本图像总是优于每次新建的版本。它也会加快你的构建时间。
答
Docker Registry v1（python）在缩放标签上很糟糕。如果您使用的是分布式文件系统存储后端（如GCS或S3），则会特意咬你。关于上下文，请参阅https://github.com/docker/docker-registry/issues/614。
现在，新协议（v2）和（golang）注册表应该会更好。
底线：
- 没有什么错你的描述，除了v1协议/注册表本身的办法...
- 你应该泊坞窗1.6打赌（候选发布版都出来了），和v2 golang注册表（这里是：https://github.com/docker/distribution）