“真正可复制的版本”到底是什么？

#1 楼

它们到底是什么？

这是reproducible-builds.org的引文：


可再现的内部版本是一组软件开发实践，它们创建了一条可验证的路径。从人类可读的源代码到计算机使用的二进制代码。


为什么它们如此重要？

IMO最简单的解释它们重要性的方法是考虑它们作为备份过程的一种变体。

作为示例：


假设一个业务使用（取决于）某些软件供应商许可的某些软件包。而企业仅获得可执行文件，而没有获得用于创建这些可执行文件的源代码。
一切都很好，但是在某些时候软件供应商出了点问题，例如他们倒闭（例如破产）。
从长远来看，这可能会给企业带来风险。即如果没有适当的程序/协议使企业能够（合法）访问与可执行文件（由过去使用）所使用的软件供应商（过去）中的任何东西相关的所有必需的资源，文档，构建过程等。业务）创建（并交付给业务）。
这就是“软件托管”的抢救：如果有这样的协议，人们会认为通过第三者，仍然有可能企业可以访问“无论使用了什么”来复制可执行文件，因此企业可以从那里继续使用该软件，并在适当的地方自行维护该软件（仅用于运行它们的自己的生意）。
但是，上一个项目符号中的“无论使用什么”都是使这项工作最困难的部分。它要求第三方预先进行适当的验证。相信我，需要一段时间才能重新创建可执行文件，您可以证明该可执行文件除了（例如）链接日期外，还与软件供应商交付给软件代理的内容完全匹配。

为什么创建它们如此困难？

如果上面的示例仍然不够清晰，请想象您是我的软件托管代理，请告诉我您需要什么作为输入来重新创建一个我的客户许可的软件的副本。得到它？您不会忘记检查哪个版本的编译器，也许是我的操作系统，编译/链接选项，可重用组件（包括）的版本，库等？

#2 楼

为了提供尝试创建真正可重复的构建的实际示例，请考虑以下内容-

构建管道以git仓库开始，没有用户可以重写历史记录或删除未合并的分支。 />
签出源代码后的第一步“构建”是旋转一个包含所有构建时间相关性的容器。

运行的构建时间容器的输出是包含已编译二进制文件的容器。

对于构建的可重复性更重要的是，以下标签已添加到最终容器中：


原始存储库中的源代码以及git repo的url和上传到工件存储库中的代码的tar快照。
用于运行构建的构建容器的确切版本。
二进制文件加载到的原始基础映像的精确版本。
所有构建时变量的值用于创建二进制文件。
构建三个容器的docker版本以及构建它们时在其下运行的版本。

通过添加所有这些元数据，我们可以确保在将来的任何时候，我们都可以提取出确切的构建依赖项集（通过构建容器），以一组确切的已知步骤编译二进制文件（包含在构建容器中）并将其打包到另一个已知的库中具有所有运行时依赖项的图像（使用基本image标记），并且都可以基于基于容器上标记的源代码的完全正确版本。

从理论上讲，这应该给我们他能够准确地复制构建版本。

这样做的重要性在于，它使我们能够查看生产中正在运行的内容，并且即使一切都进行了重大改进，也可以返回并取出最初使用的代码，基本映像和构建容器的版本，以便例如，请在对该版本进行完全修复之前，先对该版本应用修补程序，以便我们可以重新部署，因为它与修补程序完全相同，唯一的差异是修补程序。