1

目前，我们配置了 Jenkins 作业，用于发布我们的服务和其他服务，以将其部署到测试、阶段和生产。作为发布工作的一部分，我们创建一个包含服务二进制文件（及其所有依赖项）的 Docker 镜像，该镜像被推送到我们的私有 Docker 存储库（使用新版本创建一个新标签）。到目前为止，这很有效，因为很容易将这个（或更旧的）版本从 Jenkins 部署到我们不同的环境中，或者只是拉取某个版本的服务并在本地运行它。我的问题是，如果我们转向持续交付，这种方法是否有效？这个想法是，在每次成功构建后，我们都会创建一个新的 Docker 标签并推送到我们的私有仓库，并将映像部署到测试环境。我担心的是，如果每天多次这样做，将会有很多 Docker 标记/层需要下载。恐怕随着时间的推移，提取图像需要很长时间（也许还有其他我不知道的问题）？

因此，为了更清楚地重新表述这个问题：

  1. 创建很多 Docker 标签是否可以，还是应该避免这种情况？
  2. 拥有一个基本映像（操作系统等），然后从源代码控制系统中的标签构建服务二进制文件，然后构建一个映像，然后在部署时将其传输到不同的环境，会更好吗？
  3. 其他建议？
4

2 回答 2

3
  1. 公共注册表可以很好地处理多个标签。想想定期发布的 1000 张图像。docker 客户端和注册表之间不需要标签同步，只需确保您的注册表足够强大以应对。我假设作为您的测试过程的一部分，您会拉下特定的图像和标签？
  2. 基础图像总是最好每次都在一个全新的版本之上。它也会加快你的构建时间。
于 2015-04-04T10:38:53.773 回答
2

Docker Registry v1 (python) 在标签扩展方面很糟糕。如果您使用分布式文件系统存储后端（如 GCS 或 S3），这将特别困扰您。有关上下文，请参阅https://github.com/docker/docker-registry/issues/614。

现在，新协议 (v2) 和 (golang) 注册表应该在这方面做得更好。

底线：

  • 您描述的方法没有任何问题，除了 v1 协议/注册表本身......
  • 你应该押注 docker 1.6（候选发布版本）和 v2 golang 注册表（在这里：https ://github.com/docker/distribution ）
于 2015-04-06T06:27:19.637 回答