如何在与当前“`Dockerfile`”匹配的码头映像中运行CI构建，同时了解资源？

Question

如果存储库包含定义CI管道和开发人员(例如可视化代码开发容器)使用的构建环境的C1，则CI管道应满足以下要求：

1. CI管道应在从工作分支中存在的Dockerfile构建的坞映像上下文中构建存储库的内容(或在适用于拉请求上下文的情况下，将其合并到目标分支的结果)。

• 基本原理:构建应该是确定性的，所以旧的存储库版本应该使用原始的坞映像构建，而不是使用最新的版本。
• 基本原理:对Dockerfile的更改应自动考虑，不需要手动用户干预(即本地码头构建，然后手动推送)。

1. 如果适用的Dockerfile已经“烘烤”到这样的映像中，则CI管道应该重用已经构建的码头映像。

• 基本原理:在每次提交时构建一个码头映像是资源消耗(时间、精力)。

我找不到现成的最佳实践来实现这一点(如果有关系的话，我的CI环境是Azure DevOps管道)，所以我附带了以下概念：

• 计算Dockerfile's散列。
• 从码头注册中心加载docker_image_name:$hash。
• 如果加载失败，则从docker_image_name:$hash构建Dockerfile并将其推送到停靠器注册表。
• 使用docker_image_name:$hash (来自注册表/本地缓存)运行CI管道(在我的例子中使用Azure的集装箱作业 )。

问题：

1. 作为我用例的解决方案，这个过程有意义吗？
2. 我无法想象第一个意识到这个用例的人。是否有满足我需要的现有机制(作为码头实用程序的一部分、Azure DevOps管道框架的一部分或完全不同的机制)？

Answer 1

作为我用例的解决方案，这个过程有意义吗？

vscode开发容器是DevOps空间中最伟大的发明之一，我不敢相信更多的人没有谈论它们。我认为让本地开发环境和管道同步是很有意义的。虽然我认为你上面概述的程序可以简化。

我无法想象第一个意识到这个用例的人。是否有满足我需要的现有机制(作为码头实用程序的一部分、Azure DevOps管道框架的一部分或完全不同的机制)？

我目前正在我的附带项目中做这件事。azure也支持它。

Answer 2

Docker具有内置的功能，您可以以多种方式使用它。

一种方法是为每个构建保留一个“缓存”标记。这是好的，如果你的回购通常没有很多并行工作正在进行。

docker pull ${MY_IMAGE}:cache || true
docker build --cache-from ${MY_IMAGE}:cache -t ${MY_IMAGE}:${VERSION} -t ${MY_IMAGE}:cache .
docker push ${MY_IMAGE}:${VERSION}
docker push ${MY_IMAGE}:cache

如果您的回购有许多并行工作正在进行，不要创建缓存标记，而是使用最新版本。

docker pull ${MY_IMAGE}:latest || true
docker build --cache-from ${MY_IMAGE}:latest -t ${MY_IMAGE}:${VERSION} .
docker push ${MY_IMAGE}:${VERSION}

这基本上是你在问题中概述的过程，但我们依靠码头来为我们做工作。第一步是在本地拉下图像层。这比构建新映像更快(通常)，如果您的CI/CD设置正确，那么缓存的使用应该已经存在了。

然后，--cache-from标志告诉Docker使用该图像作为缓存。这将阻止Docker构建没有更改的任何层。