问题描述
正在设置他们的源代码和构建系统，并且在AWS上有两个持久的虚拟机用于托管源代码和Artifactory。他们有一些编译器（几GB大小），希望通过NFS进行访问，他们想知道是否应该将这些编译器托管在Artifactory中。他们在寻找“最佳实践”的答案，但是在这个问题的背后，他们似乎没有找到太多的相关信息。他们希望获得一些关于这个决策背后的思考的链接。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
使用Artifactory的优点
使用Artifactory（或其他二进制库管理工具）相对于传统文件存储（如NFS）有一些主要优点：
1. 管理构建版本：Artifactory可以帮助您管理构建产物的不同版本。
2. 集中访问：您可以通过Artifactory在基础架构中的多个地方访问构建产物（尽管您已经通过NFS实现了这一点）。
3. 下载/还原之前的版本：Artifactory允许您下载或还原以前的构建产物版本，这对用户来说非常有用。
4. 控制访问权限：您可以控制谁/什么有权访问存储的构建产物。
如果您的用例不需要上述任何一项功能，那么我会说Artifactory可能过于复杂，建立和维护它的工作量可能不会超过您从中获得的价值。虽然我过去使用过它，并且它确实是一个非常好的工具，可以完成其旨在实现的目标。
编译器的使用场景
在许多情况下，编译器是按原样使用的，已经由第三方打包好。在更改构建系统的结构时，更换编译器通常意味着切换到不同的版本，但这些版本也已经预先打包好。如果这是您的用例，构建产物存储库提供一个单一的优点：可用性。即使提供者决定（无论出于什么原因）停止该版本，您仍然在存储库中有您的副本。
但是，如果编译器接收任何无需更改版本的更新，或者如果您进行任何形式的定制（即使只是在不更改任何代码的情况下进行构建），您希望将这些特定版本存储在Artifactory中，以便能够随时可靠地获取它们。
性能考虑
需要注意的是，您如何使用编译器可能会影响构建的性能，特别是在构建时间可能长达数小时的非常大型项目中。您需要分析构建的结构和/或使用模式，以确定是否值得追求优化，以及在哪些方向上进行优化。
直接从NFS调用编译器非常方便 – 构建服务器上几乎不需要配置。但大型构建的性能可能对NFS性能非常敏感，无论是NFS服务器本身的性能还是连接其与构建服务器之间的网络性能。一些Artifactory可能直接支持NFS。您需要测量切换到此类服务的影响，在某些情况下，仍然使用专用NFS服务器可能更好。或者，考虑切换到包含本地安装编译器的虚拟机镜像。
请注意，您提到您将使用JFrog，我相信它如果没有记错的话是支持NFS的。
其他解决方案
如果您只是希望能够方便地加载和管理多个版本的编译器，还可以考虑使用环境模块（http://modules.sourceforge.net/）。这个工具可以帮助您在Linux上加载和管理不同的工具链。每个编译器都会有自己的文件夹，按版本进行划分，这使得您可以直接访问所有版本。配置在服务器端使用PATH和其他环境变量定义。在用户端，需要将一个bash脚本安装到用户的.bashrc文件中。
虽然这是一种有趣的方法，但它可能不如Artifactory适用于大型项目或需要更高级别的构建和版本管理的场景。因此，根据您的需求和项目规模，选择合适的解决方案。
总结
在决定是否将编译器放在Artifactory中时，关键是考虑您的项目需求。如果您需要对版本进行管理，需要集中访问，需要可靠地下载以前的版本，并且需要控制访问权限，那么Artifactory可能是一个很好的选择。如果您的需求不包括这些功能，您可以继续使用NFS，但要考虑性能方面的影响，并在必要时考虑其他解决方案。
希望这些信息能帮助您做出明智的决策。如果您需要更多关于Artifactory或其他解决方案的信息，我建议查阅相关文档或向社区寻求帮助。