0

在我们的开发工作流程中，我们构建镜像，将它们推送到注册表，然后在暂存集群中从它们部署服务。工作流程因大量图像推送而严重陷入困境，因为在不同工作站上由完全相同的代码库构建的层往往最终具有不同的哈希值。我们确实了解 docker 的工作原理（即一点变化，层发生变化；一层发生变化，所有后续层也发生变化），但我们仍然相信有很多层失效正在发生，我们所做的任何事情都无法解释到我们的代码库或依赖项，并且完全是由于在不同机器上执行的构建。原则上，我们的构建并不太依赖于平台（我们不会将任何东西编译成机器代码），而且这些机器无论如何都是 x86_64 linux 机器。

有哪些工具、策略和最佳实践可以帮助我们调试为什么会发生这种情况并可能缓解这种情况？

（重要提示：我们目前绝对负担不起的一个已知最佳实践是将构建过程转移到可能在云中的单个专用机器上。请不要建议此解决方案）。

4

2 回答 2

0

有哪些工具、策略和最佳实践可以帮助我们调试为什么会发生这种情况并可能缓解这种情况？

您已经命名了一些您需要处理的事情，这些事情已经指向这一点：

你想要的是一个可重复的构建。也就是说，相同的 VCS 版本正在创建相同的映像（假设基本映像也相同）。

  • 检查使用中的基础镜像是否稳定（例如，您可以固定它们，并且它们不会在每次构建中更改，只是在打算更改它们时）。
  • 时间戳。检查您放入的文件不仅与 repo 中的二进制文件相同，而且还用于元数据。
  • 时间戳。在码头集装箱内。立即冻结以进行构建。不知道，这在很大程度上取决于构建中所做的事情。

您可以通过比较 tarball 及早验证事情。例如，从 VCS 导出一个 tarball 来构建，稍后从图像中导出它，看看有什么变化。用 tar 比较文件列表很容易，而且您通常会保留工件，因此比较多个运行/修订/构建也很容易。

我不知道 Docker / in Docker 中专门用于可重现构建的任何特定工具，因此我无法在这里提出任何建议。

我猜谷歌的构建工具应该支持可重现的构建，但我不知道是否。我知道他们有一个构建工具（已发布）。

于 2021-07-03T14:47:18.210 回答
-1

您可以使用诸如 Dive ( https://github.com/wagoodman/dive/ ) 之类的工具来检查图层。

除此之外 - 除非我看到 Dockerfile，否则帮不上什么忙。

对我来说很好的做法——在 Docker 中使用 Docker 来构建你的镜像。通常类似的流程就足够了：

  1. 创建一个 docker:dind 容器
  2. 在其中克隆您的存储库
  3. 构建你的项目
  4. 运行 docker build（在我的 Dockerfile 中，我确保只复制运行时需要的文件 - 您也可以查找多级 Dockerfile）

一般的想法是始终从“干净的盘子”开始，一旦完成 - 销毁“盘子”并重复下一个构建。

于 2021-06-11T14:22:07.670 回答