制作 Erlang 版本的最佳实践是什么?

发布于 2024-10-27 02:02:18 字数 209 浏览 6 评论 0 原文

我一直在查看 Faxien+Sinan 和 Rebar,Erlang OTP 的基本理念似乎是在单个 Erlang 映像实例上安装应用程序和发布。保持版本独立的最佳实践是什么?有没有一种方法可以打包版本,这样您就不必修改要部署到的计算机的站点?将所有依赖项收集到代码库中进行管理怎么样?

也许我违背了常规……我有 Java 背景,“除了 JVM 之外没有预装任何东西”的理念似乎非常不同。

I've been checking out Faxien+Sinan and Rebar, and the basic philosophy of Erlang OTP seems to be, install applications and releases on a single Erlang image instance. What are the best practices for keeping releases self contained? Is there a way to package releases such that you don't have to modify the site for machines that you're deploying to? How about gathering all dependencies into the codebase for management?

Perhaps I'm going against the grain... I come from a Java background and the philosophy of "nothing pre-installed but the JVM" seems very different.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

挥剑断情 2024-11-03 02:02:18

恕我直言,这不是几句话就能回答的。您应该阅读所包含文档的某些部分,尤其是“Erlang/OTP系统文档”(otp-system-documentation-XYZpdf,XYZ是版本号),或者看看书“Erlang 和 OTP 的实际应用”,因为在本书中,有“一个”“服务”示例,其中包含与第一步不同的“部分”,使用 Erlang/OTP 概念,最后构建一个“发布”。

恕我直言,这是目前最好的书,因为它不仅介绍了 Erlang,还展示了 OTP 是什么以及如何在项目中使用 OTP。它不仅仅是松散样本的集合,而且一切都是围绕单个项目构建的。

IMHO this can't be answered in a few sentences. You should have to read some parts of the included documentation, especially "Erlang/OTP System Documentation" (otp-system-documentation-X.Y.Z.pdf, with X.Y.Z being the version number), or have a look at the book "Erlang and OTP in Action" because throughout this book there is "one" example of a "service" with different "parts" from the first steps, using Erlang/OTP concepts and finally building a "release".

IMHO this is currently the best book around, because it not only introduces Erlang, but also shows what OTP is and how OTP is used for a project. And it is not just a collection of loose samples, but everything is build around a single project.

昨迟人 2024-11-03 02:02:18

我将描述目前适用于我对 EC2 上少量实例进行定期(通常是每天)发布的方法:

  1. 我使用 rebar 设置了我的项目并将其签入 github。
  2. 我的所有依赖项都列在我的 rebar.config 文件中(它们也在 github 上)。
  3. 我的 Makefile 看起来与我在此处描述的类似。
  4. 我的 EC2 映像仅包含常规版本的 erlang,默认情况下没有安装其他库。
  5. 为了创建一个新节点,我启动一个实例,克隆我的 git 存储库,然后运行 ​​make。这将获取我的依赖项并构建所有内容。
  6. 为了更新我的代码,我执行了 git pullrebar update-deps。根据更改的内容,我可能会重新启动节点,或者通常我会附加到正在运行的节点并重新加载更新的模块。将启动和附加脚本作为项目的一部分会有所帮助。

了解像 webmachine 这样的项目是如何打包的可能会有所帮助。

我对标准 OTP 发布管理系统了解不多,只是看起来工作量很大。因为这似乎与快速部署背道而驰,所以我从未认真尝试过 - 尽管我确信这对于其他项目来说是有意义的。

I'll describe the approach that currently works for me for regular (often daily) releases to a small number of instances on EC2:

  1. I set up my project with rebar and check it into github.
  2. All of my dependencies are listed in my rebar.config file (they too are on github).
  3. My Makefile looks similar to what I described here.
  4. My EC2 image only has a regular build of erlang and no other libs installed by default.
  5. To create a new node, I spin up an instance, clone my git repository, and run make. This will fetch my dependencies and build everything.
  6. To update my code I do a git pull and a rebar update-deps. Depending on what changed I may restart the node or, quite often, I'll attach to the running node and reload the updated modules. It helps to have start and attach scripts as part of your project.

It may be helpful to look at how a project like webmachine is packaged.

I don't know much about the standard OTP release management system, other than it looks like a lot of work. Because this seems counter to rapid deployment, I never gave it a serious try - though I'm certain it makes sense for other projects.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文