node.js - Node.js部署，在使用Jenkins和Chef的企业环境中使用哪种方法？

Question

首先让我解释一下上下文。

上下文

当前，我们正在使用Jenkins服务器，并将Chef Server用于我们的配置管理。我们正在朝着更加连续的部署环境迈进，这就是我一直在努力的工作流程:

代码已在GIT上 checkin

Gitlab触发Jenkins运行新版本

Jenkins输入最新代码并运行npm install

Jenkins使用FPM创建RPM

RPM已上传到RPM存储库

Jenkins将应用程序git存储库中的Chef部署食谱上载到Chef Server。

Jenkins通过运行Chef客户端触发应用程序的新部署。

新的RPM由部署指南安装。

在暂存和生产环境的提升(手动触发)中，我没有可用的Internet连接。 RPM解决了这个问题。这些菜谱是使用Berkshelf开发的。

以这种方式部署的Node.js应用程序有时确实会使用已编译的 native 库(一个项目具有3个以上的依赖项编译 native 代码)。

我对这类部署过程知之甚少，但是我听到的一个缺点是，使用RPM并仅在编译环境(当前为Jenkins本身)具有与部署环境相同的体系结构时才对其进行编译。
使用RPM的好处是，工件在所有环境中都保持完全相同，不需要重新编译，并且不会从任何地方提取数百个依赖项。

尽管如此，工作流程似乎有些复杂，对我而言，必须坚持相同的体系结构并不十分灵活。

对于我们的用例，我们需要以下内容:

在云中快速部署(可能是Amazon)

快速部署在我们自己的基础结构上(当前没有Internet连接，但是如果有充分的理由可能允许一些访问)

应用程序更新虽然很少见，但应该易于部署和自动化。可以连续部署

他们正在使用的软件体系结构是微服务体系结构，我希望将数十个Node.js应用程序部署在各种服务器上(为简单起见，可能在同一服务器上进行多个部署)。

对于我自己的项目，我大部分时间都在使用Heroku，而无需进行任何设置。上面的工作流程需要两个星期才能创建(第一次)。

问题

处理所有这些工作的巨大努力使我对上述一些步骤提出了质疑:

rsyncing和使用npm install听起来是否很糟糕，引入所有这些依赖项并在每个环境上重新编译？这真的像我认为的那样不稳定吗？ (我有Java和PHP的背景，在PHP中从来没有进行过编译，而FTPing在过去是一种规范，而在Java中，所有内容都经过了整齐的打包)。

为什么用RPM代替Tarbal？ (直到一周前，我还从未手动构建过RPM，我对其功能几乎一无所知，在这里不知道该使用什么或不使用什么)。

我一直在研究Chef中所谓的“部署食谱”，它基本上安装了部署目录，monit配置，init脚本和(可选)nginx代理配置。该部署手册的版本与部署本身相同，并在原始git存储库代码中提供。在厨师社区中，我还没有找到任何最佳实践，并且我希望它会非常普遍。这不是走的路，甚至不是反模式吗？

在同一服务器上部署多个微服务(使用不同的端口号)，这真的不好吗？是否有意义？ (我简要介绍了Docker，但认为它引入了太多的复杂性作为逻辑上分离微服务的一种方法，我们仍然在努力设置它)。

您可能能够分享的任何经验将不胜感激!

Answer 1

1)最好将所有依赖项与您的应用程序一起交付，然后npm在目标计算机上重建它们。或者，如果您想进入企业，则可以在构建服务器上重建模块，然后打包到tarball/docker或lxc容器/VM镜像中/命名。没有银弹。我个人更喜欢普通的LXC容器。但一般的行为是:将模块与应用程序 bundle 在一起，并在目标平台上重建二进制模块。

2)对于简单的脚本应用程序，最好使用tarball甚至git clone。不，在这种情况下，您实际上不需要系统软件包管理器的所有强大功能和复杂性。但是，如果您要使用定制的nginx或某种系统范围的库或类似的东西，则最好使用RPM或DEB并为您的定制包设置适当的存储库。

3)我不使用Chef，但是对于任何大型项目，最好将部署脚本分为独立的仓库。我的意思是您的部署代码不是您的应用程序代码。就像在一个仓库中有两个单独的应用程序一样。可能但不是一个好习惯。

4)很好。可以扩展，因为您可以只从一台物理计算机开始，然后随您的成长而增长(但是，这听起来很简单。我花了很多时间使我当前的项目可扩展)。但这对于集成测试总是非常好的。您可以生成整个环境，运行集成测试，获取结果，然后在新的环境中从头开始进行新的测试。