node.js - NodeJS 生产部署最佳实践

Question

我正在寻找以一致且及时的方式将一些 Web 服务部署到生产中的方法。

我目前正在实现一个部署管道，该管道将以将特定版本的软件手动部署到 Ansible 提供的多个虚拟机结束。这个想法是使用版本 A 配置 x 数量的实例，同时已经有 y 数量的实例运行版本 B。然后镜像并轻弹流量。相同的机制应该允许我使用我已经制作的镜像来扩展一组新的虚拟机。

我已经考虑了以下选项，但想知道是否有我忽略的东西:

1. TGZ

CI 环境将从已通过单元测试和集成测试的项目构建 tarball。可以选择捆绑依赖项(无需在生产计算机上运行 npm install 并依赖于公共(public)或私有(private) npm 存储库的网络连接)。

我的主要问题是，任何依赖于系统库的依赖项都将构建在不同的计算机上(尽管是相同的镜像)。我不喜欢这样。

1. NPM

CI 环境将发布到私有(private) NPM 存储库，Ansible 部署脚本将在配置后检查特定版本。同样，当您想要部署时，这会受到对可用外部服务的依赖的影响。我不喜欢这样。

1. Git

任何系统相关模块都会作为配置的一部分进行全局安装，并且所有其他依赖项都会 checkin 存储库。这使我能够灵活地进行差异部署，从而仅推送增量，并且流程管理器几乎可以立即自动重新启动应用程序守护程序。然后依赖关系就被绝对锁定。

这意味着除非需要扩展，否则无需启动新的虚拟机。部署可以直接推送到所有事件实例。

Answer 1

首先，无论采用哪种部署方法，您都需要确保在部署新代码时不会丢弃请求。一种简单的方法是在切换之前从负载均衡器中删除 Node 。在此之前，您可能还需要尝试评估是否有待处理的请求、打开的连接或因提前终止而产生负面影响的任何其他内容。或者类似 up模块。

大多数人不建议对模块进行源代码控制。似乎带有 node_modules 的 .tgz 已经从 npm install 中填充，同时在 package.json 中利用 bundledDependencies 声明 可能涵盖您所有的担忧。通过这种方法， Node 上的 npm install 将不会再次下载并安装所有内容。不过，它将重建 node-gyp 实现，这可能会解决您的系统库问题。

您还可以使用 git 标签更轻松地跟踪具有特定依赖项和有效负载的版本。手动部署代码可能会变得乏味，您可能需要考虑自动化例程，同时从界面迭代数据库中 x 数量的已知服务器条目。 docker.io可能会感兴趣。