RVM 生产准备好了吗？答案

【问题标题】：Is RVM production ready?RVM 生产准备好了吗？
【发布时间】：2023-03-10 21:27:01
【问题描述】：

RVM 非常适合在本地计算机上进行开发。但它在生产机器上安全吗？

【问题讨论】：

如果您的开发机器上没有遇到任何错误，我会认为它是安全的。 RVM is used for deployments too.
RVM 非常可靠。一个更好的问题是，它会做你想做的事吗？也许如果您描述您的目标，我们可以提出更有用的建议。因为这有点模糊。
铁皮人的评论最精彩。最初的问题是一般可以回答的。
对于那些阅读回复的人：2012 年年中的 RVM 与 2011 年年中的 RVM 明显不同。我在下面吃我的话，并开始在我们的暂存环境中使用 RVM，以期将其移至我们的生产环境。

标签： ruby rvm

【解决方案1】：

我为生产构建了 RVM，并在稍后添加了开发人员“niceties”。如果您想了解更多信息，请阅读网站上的文档，并在美国东部夏令时间大多数日子的某个时间通过 irc.freenode.net 上的#rvm 与我交谈。

【讨论】：

真的，我是第一个点赞RVM作者这条评论的人？
偏向于......真棒。
我很好奇，当它覆盖了如此多的 shell 内置函数（如 'cd'）时，为什么你会认为它已准备好生产？如果它是为生产而设计的，您不会将 rvm 限制在您自己的包装器或类似 bash 的外壳中，而不是污染每个人/其他一切都依赖的外壳吗？您已经有效地将 ruby、tcl 等添加到其他任何顶部可能有 !#/bin/bash 的内容中。在 RVM 之前，只需要一个功能性的 libc6 安装，就像内核一样。我知道的每一个包政策都明确禁止 RVM 主要以生产的名义做的事情。
我必须同意这里；几年前 virtualenv 解决了这个问题时，rvm 在 shell 中使用了非常丑陋和不必要的钩子。同时，它们每隔几个月就会中断一次，并且难以调试。我建议如果您确实使用 rvm，请不要在未经您同意的情况下使用它尝试添加的任何挂钩。

【解决方案2】：

由于 RVM 只是一种在现有 Ruby 实现之间下载、隔离和切换的奇特方式，我想说它与您当前运行它的任何 ruby 实现一样可用于生产。

基本上，RVM 所做的只是将您的路径指向特定的 Ruby 实现。这正是在您使用 *nix 发行版的 Ruby 实现时发生的。唯一真正的区别是您的路径将被重写，因此当您运行 ruby -v 时，它将从当前用户的 .rvm 目录而不是像 /usr/local/bin 这样的全局系统目录运行 ruby。

我更进一步说，使用 RVM 比使用通常安装在 *nix 发行版中的解决方案更好，因为它可以轻松地对每个用户的特定 ruby 实现进行沙箱处理。 RVM 还可以尝试在您的生产应用程序上切换 rubies（即从 1.8.7 到 1.9.2），同时在某些事情不能正常工作时保持可靠的回滚策略。它还可以更轻松地让旧应用程序在一个 Ruby 版本上运行，同时将新应用程序切换到更新的版本。

【讨论】：

经过深思熟虑的帖子，您准确总结了 RVM 在生产中正确使用时的作用。环境文件是那里保持一致性的关键。
谢谢韦恩，很高兴知道我“明白了”。 RVM 可能是我用过的最有用的开发工具之一。我目前正在构建一个在 JRuby 上运行的应用程序，因此 RVM 可以在开发中轻松地在 MRI 上运行我的应用程序（因为 MRI 运行我的测试要快得多），然后在部署之前切换到 JRuby 进行测试。赞一个！

【解决方案3】：

我不同意，特别是如果您使用任何类型的自动化生产过程（木偶、厨师、雾等）并且您拥有不止一两台机器。

我们遇到了 RVM X 版本与 RVM 版本 Y 的工作方式完全不同的问题（不同的默认 Rubygems 版本、不同的默认 gemset 配置、系统范围安装工作方式的完全更改），破坏了我们的自动配置过程.

如果您正在开发并随时进行调整，这不是问题，如果您有无人值守的脚本/木偶安装，这将是一个杀手。我们通过锁定到特定的 RVM 版本来解决这些问题，但我记得曾与韦恩交谈，他不鼓励这样做。如果我们继续在 prod 中使用 RVM，我们实际上会将它打包成一系列 .debs（一个用于安装，一个用于每个 Ruby）。

.rvmrc 默认提示并且只能在 homedir ~/.rvmrc（而不是系统范围的）中覆盖的方式也没有帮助。

实际上，我喜欢 RVM 在开发中改变并以这种方式做事的方式——没有什么比被向后兼容性阻碍更糟糕的了。然而，这种方法在生产/登台/uat/测试中花费了我们一些时间（并且费尽心思）。

【讨论】：

对于那些在 2012 年阅读这篇文章的人来说，情况发生了变化，我现在正在认真考虑 RVM 在生产中的使用。据我所知，releng 已经有了很大的改善。
.. 但是将 .rvmrc 提交到你的仓库仍然是禁止的。

【解决方案4】：

RVM 显然是一个合理的生产工具

你知道，我曾经发表过类似的rvm is a development tool评论，并被告知rvm最初是一个生产工具。

所以，RVM 会使您的生产环境更加复杂，这是不好的，但它会使其更加孤立和划分，人们称之为模块化的语言，这是好的。

最后，只要您测试您的部署，我看不出任何类型的静态配置本身可能是“不安全的”。

【讨论】：

我建议由于包含和规范，它使生产环境更简单 :)
嘿，韦恩是 rvm 作者。我当然可以相信 rvm 简化了需要多个环境的情况。

【解决方案5】：

这完全取决于您如何安装 RVM 、单用户或多用户。在系统范围内安装 RVM 可能会导致在不同的 rubies 之间进行大量的混乱切换。最好选择单用户，减去 RVM 可以很好地完成它的用途。

【讨论】：

【解决方案6】：

我想这个问题有两个部分：

RVM 是否旨在用于生产机器，而不是开发机器？
RVM 软件是否足够可靠，可以在生产机器上使用？

对于 (1)，Wayne E. Seguin 表示它旨在用于生产机器。质疑他的意图是没有意义的。

对于 (2)，我不太确定。在生产机器上使用具有新版本号every couple of days 的软件是否合适？此外，RVM 曾经删除了我的整个 ~/ruby 目录。值得 Wayne 称赞的是，当我告诉他这件事时，他当晚就修好了，但这对我来说并不完全是“生产准备就绪”。

编辑：我刚刚read about bumblebee 删除了 /usr，我只想说 - 情况可能更糟！哈哈。

【讨论】：

那是多久以前的事了？该项目进展迅速，除了安装程序之外，最近情况不再发生太大变化。此外，经常使用新版本号与 anything 有什么关系？大多数情况下，这些都是与已有功能脱节的新功能。
如果在“生产”中正确使用应该没有问题。
从那时起事情已经很长了:)
@Wayne: 去年 12 月还在 1.0 之后。

【解决方案7】：

我已经在生产网络服务器上使用 RVM 一年多了，现在问题为零。我一直保持最新状态，经常运行rvm get head。零问题，永远。 :)

【讨论】：

如果它应该适合生产，你是否应该经常运行rvm get head？
@Wayne：这种幽默本身就不适合制作！（我开玩笑说这是反对使用它的一个理由，即使我每次遇到它都会翻白眼）。
现在这种“头脑风暴”的幽默比过去少了很多。

【解决方案8】：

是的，我在生产机器上使用了 rvm，还设置了 puppet 模块来安装 rvm 作为默认系统 ruby 以及 gemset 等。

如果您在单个服务器上运行多个应用程序，rvm 可以帮助您将所有应用程序 gemset（和 ruby 版本）完全分开。但是，如果您在服务器上只运行一个应用程序，安装 rvm 可能没有那么多好处。

【讨论】：

我不同意第二部分，因为这是我合作过的大多数人的正常用例:)
RVM 为运行单个应用程序的服务器带来的性能不如运行多个应用程序的服务器。但在任何一种情况下，都不能否认它的令人敬畏。 :)
“但是，如果您在服务器上只运行一个应用程序，安装 dvm 可能没有那么多好处。” 我正在做 Ruby 开发和系统经过多年的 LAMP 开发和管理后的管理，并且有一个好处。如果要更新核心 Ruby 或 Ruby GEM，RVM 确实让维护任务变得更轻松。过去我怀疑 RVM 的价值并从源代码或 PPA 安装 Ruby，但现在我完全“了解”了 RVM 的心态和价值。

【解决方案9】：

我几乎在所有运行 Rails 应用程序的生产服务器上都使用了 RVM！。 RVM 没有让我失望。

【讨论】：