提供本地工具，同时保持最大的可移植性答案

【问题标题】：Vendoring a native tool while retaining maximum portability提供本地工具，同时保持最大的可移植性
【发布时间】：2012-06-04 16:59:42
【问题描述】：

Twelve-Factor App 宣言说它适用于 Web 应用程序，“......与底层操作系统有清晰的合同，在执行环境之间提供最大的可移植性”[强调由我添加]

然后it says:

十二因素应用也不依赖于任何隐含的存在系统工具。示例包括向ImageMagick 或curl 发起攻击。虽然这些工具可能存在于许多甚至大多数系统上，但没有保证它们将存在于应用程序可能运行的所有系统上未来，或者在未来系统上找到的版本是否会是与应用程序兼容。如果应用程序需要向系统提供外壳工具，该工具应该被供应到应用程序中。

他们之前将“供应商”定义为：

作用于包含应用程序的目录（称为“供应商”或 “捆绑”）。

当（至少在 Linux 上）本机 64 位可执行文件不能在 32 位环境中运行时，应该怎么做？更不用说在其他操作系统上运行了？或者有没有更好的方法来处理这个可移植性问题？

【问题讨论】：

另外，他们似乎没有考虑到您可能在 Windows 上进行开发并想要执行“系统工具”的可能性。与许多其他 EULA 一样，Windows EULA 禁止销售！

标签： dependencies native-code 12factor

【解决方案1】：

在我看来，根本不应该这样做。这是因为：

如果本机可执行文件是动态链接的，那么它们可能无法仅在未来的操作系统版本上运行，更不用说未来或过去的处理器架构了。
据我了解，不可能通过静态链接来完全面向未来的本机可执行文件。你仍然可以有问题。 Solaris 甚至不支持系统库的静态链接！
库依赖项并不是本机工具可以拥有的唯一一种依赖项。也可能存在其他问题。
旧的ImageMagicks - 甚至是curls - 可能存在安全漏洞，可能导致您的应用程序受到威胁。（这有点争议——它的有效性取决于你更信任谁来监视/应用安全更新——维护和升级服务器的人，还是开发人员？当然他们可能是同一个人——现在. 但我在这里的工作假设是服务器最终会应用更新，这反过来会保护您的应用免受系统可执行文件中已在更新中修复的安全漏洞。）

我的观点：如果您选择的依赖管理系统直接无法处理本机可执行文件，请在 README 中添加注释并完成它。如果您没有 README，请创建一个。并且（对于内部网络应用程序）将您需要的本机工具添加到您在设置服务器时使用的标准服务器映像或脚本中，并确保您保留额外的说明它们为什么存在.

【讨论】：

【解决方案2】：

这只是意味着您应该在您的供应商资源之间建立一个声明性依赖关系和一个干净的合同。

如果您的应用依赖于特定版本的软件，您必须与它签订一份清晰的合同，以便您可以模拟/存根功能进行开发。此外，即使在 Windows 中，将依赖项管理作为应用程序的一部分也并非不可能（尽管您可能希望它发生在您的安装程序中，而不是应用程序本身）。

如果您的产品严重依赖其他软件，以至于即使在测试环境中也无法在没有它的情况下运行，那么必须将其捆绑在一起，并且您必须制定 EULA，或者，实际上，您没有一个产品。

【讨论】：