Erlang/OTP连续部署简介

注意：这是我在类似主题上的一个进化延续

我已经搜索了一段时间有关部署和更新Erlang/OTP版本（一组应用程序）的“最佳实践”，但我找不到任何直接的解决方案描述，只找到一些“相关信息”：

我所说的“直接解决方案”是对以下问题的回答：

给定一个生产Erlang/OTP集群，其Erlang/OTP版本运行在几个Erlang节点上，这些节点充当高可用性（24/7）REST API，如何定期向该生产集群推送新代码？有没有什么最佳实践可以做到像git push heroku master一样简单？如果没有，在生产中持续重新部署和部署Erlang/OTP软件的最简单方法是什么

我已经阅读了《Erlang/OTP实用》一书，了解了如何处理Erlang/OTP应用程序和发行版，在我看来，简单的软件升级并不是那么容易。使用

reltool

时，您必须生成一个归档文件，将该归档文件移动到生产机器（

scp

？），在那里解压缩，运行Erlang shell并将新模块加载到Erlang VM中

此外，“向您学习一些Erlang”一书还包括以下内容：

“…如果您可以避免整个过程（从现在起称为relup），并通过重新启动VM和启动新应用程序来进行简单的滚动升级，我建议您这样做。”

及

“据说爱立信使用relups的部门花在测试relups上的时间和他们自己测试应用程序的时间一样多。”

此外，这里是为了避免在生产中对Erlang版本进行热交换

如果这是真的，那么我看不到“Erlang热代码升级”有任何用处，因为每次升级都必须重新启动VM。这使得我不知道如何在生产环境中定期部署Erlang/OTP新代码的健壮且经过测试的方法

附：关于我的软件需求的一些注释

• 我正在编写一组没有任何会话的API入口点，因此在软件更新期间不需要维护会话
• 无需分发Erlang/OTP版本，我正在使用内部定制产品

---

Erlang热代码升级在两种情况下很有用：

如果只有一个关键节点，则无法停止。当您在交换机或路由器上运行Erlang时，可能就是这种情况，这对您的基础架构或您的应用程序非常重要

当您确实希望保留正在运行的节点的状态（并进行一些更改）时。以这样一种方式设计系统通常比处理复杂的升级更容易，您不需要这样做

最好避免热代码升级，因为这很难，但有时是必要的。在这些时候，您将致力于编写和测试升级。你会很高兴的，这一切都可以实现

在您的情况下，您有一个没有状态的节点集群，所以升级的最简单方法是从集群中删除节点，在服务器上上载新版本，启动节点并将其添加回集群。如果在节点之间进行配置，则使用

scp

编写脚本应该很容易。在升级所有节点之前，最好先在5%的机器上测试新版本的代码，例如在20%以上的机器上测试

在某些情况下，您可以复制beam文件，转到Erlang控制台并键入：

code:purge(my_module), code:load_file(my_module).

---

这不建议用于日常工作，但当您在远程机器上进行开发时，它可能会派上用场。例如，当您查找锁争用时，当您有16个或更多内核时，它们可能会出现。您可以每次创建整个版本并上传，但这会减慢开发周期。热代码升级的使用可能有点不规范，但非常方便。

感谢您解释真正需要热升级的情况！请详细说明“…在服务器上上载新版本，启动节点…”好吗？这个行业是如何做到的？哪些工具用于自动上载和启动新版本？另外，当您提到“节点间的应用程序故障转移”时，您是指任何Erlang功能吗？我在回答中添加了链接，以说明我在撰写应用程序故障转移时所指的功能。为了简化发布，您可以使用rebar、relx或erlang.mk（在内部使用relx）。然后，我们通常使用普通的旧scp将发行版复制到服务器（只使用bash脚本包装它）。有一个非常酷的商业工具叫做Wombat，它主要用于监视，但具有编排功能。您通过web界面上传新版本，它可以将其部署到指定的IP或云提供商（同样：“部署”意味着停止运行节点，上传并解包新版本，重新启动节点），因此，基本上我的问题的答案是“使用rebar生成发布>停止Erlang/OTP节点，它是Erlang群集的一部分>将发布添加到节点>再次启动节点>将其加入群集”