为持续交付创建大量 Docker 标签有什么问题吗？
Is there any issues with creating lots of Docker tags for Continuous Delivery?
目前，我们配置了 Jenkins 作业来发布我们的服务，并配置了其他作业以将其部署到测试、阶段和生产。作为发布工作的一部分，我们创建了一个包含服务二进制文件（及其所有依赖项）的 Docker 映像，该映像被推送到我们的私有 Docker 存储库（使用新版本创建了一个新标签）。到目前为止，这很好用，因为很容易将这个（或更旧的）版本从 Jenkins 部署到我们的不同环境，或者只是拉取某个版本的服务并 运行 在本地。我的问题是，如果我们转向持续交付，这种方法是否有效？这个想法是，在每次成功构建之后，我们都会创建一个新的 Docker 标签并推送到我们的私人仓库，并将图像部署到测试环境。我担心的是，如果一天执行几次，将会有很多 Docker tags/layers 必须下载。恐怕时间久了，拉取镜像的时间会很长（可能还有其他我没有意识到的问题）？
因此，为了更清楚地重新表述问题：
- 是否可以创建很多 Docker 标签，或者这是什么
应该避免？
- 有一个基本映像（OS 等）会更好吗，然后从源代码控制系统中的标签构建服务二进制文件，然后构建一个映像，然后将其传输到不同的环境在部署？
- 其他建议？
- public 注册表可以很好地处理多个标签。想想定期发布的 1000 多张图片。 docker 客户端和注册表之间不需要标签同步，只要确保您的注册表足够强大即可。我假设作为测试过程的一部分，您拉下了特定图像和标签？
- 基础镜像每次总是优于全新构建。它还会加快您的构建时间。
Docker Registry v1 (python) 在标记上的缩放方面很糟糕。如果您使用分布式文件系统存储后端（如 GCS 或 S3），这将特别困扰您。有关上下文，请参阅 https://github.com/docker/docker-registry/issues/614。
现在，新协议 (v2) 和 (golang) 注册表应该在这方面做得更好。
底线：
- 您描述的方法没有任何问题，除了 v1 protocol/registry 本身...
- 你应该押注 docker 1.6（发布候选版本已出）和 v2 golang 注册表（在此处：https://github.com/docker/distribution）
目前，我们配置了 Jenkins 作业来发布我们的服务，并配置了其他作业以将其部署到测试、阶段和生产。作为发布工作的一部分，我们创建了一个包含服务二进制文件（及其所有依赖项）的 Docker 映像，该映像被推送到我们的私有 Docker 存储库（使用新版本创建了一个新标签）。到目前为止，这很好用，因为很容易将这个（或更旧的）版本从 Jenkins 部署到我们的不同环境，或者只是拉取某个版本的服务并 运行 在本地。我的问题是，如果我们转向持续交付，这种方法是否有效？这个想法是，在每次成功构建之后，我们都会创建一个新的 Docker 标签并推送到我们的私人仓库，并将图像部署到测试环境。我担心的是，如果一天执行几次，将会有很多 Docker tags/layers 必须下载。恐怕时间久了，拉取镜像的时间会很长（可能还有其他我没有意识到的问题）？
因此，为了更清楚地重新表述问题：
- 是否可以创建很多 Docker 标签，或者这是什么 应该避免？
- 有一个基本映像（OS 等）会更好吗，然后从源代码控制系统中的标签构建服务二进制文件，然后构建一个映像，然后将其传输到不同的环境在部署？
- 其他建议？
- public 注册表可以很好地处理多个标签。想想定期发布的 1000 多张图片。 docker 客户端和注册表之间不需要标签同步，只要确保您的注册表足够强大即可。我假设作为测试过程的一部分，您拉下了特定图像和标签？
- 基础镜像每次总是优于全新构建。它还会加快您的构建时间。
Docker Registry v1 (python) 在标记上的缩放方面很糟糕。如果您使用分布式文件系统存储后端（如 GCS 或 S3），这将特别困扰您。有关上下文，请参阅 https://github.com/docker/docker-registry/issues/614。
现在，新协议 (v2) 和 (golang) 注册表应该在这方面做得更好。
底线：
- 您描述的方法没有任何问题，除了 v1 protocol/registry 本身...
- 你应该押注 docker 1.6（发布候选版本已出）和 v2 golang 注册表（在此处：https://github.com/docker/distribution）