NodeJS生产部署最佳实践

Question

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

我目前正在实现一个部署管道，该管道将以软件的一个特定版本的手动部署操作结束，该操作将由Ansible提供的许多虚拟机完成。其想法是提供使用版本A的x个实例数，同时已经有y个实例运行B版。同样的机制应该允许我使用我已经制作的图像在一个集合中缩放新的vms。

我考虑了以下几种选择，但不知道是否有什么东西我忽略了：

1. TGZ

CI环境将从一个已经通过单元测试和集成测试的项目构建一个tarball。可以选择地，将减少绑定(消除了在生产机器上运行npm安装和依赖到公共或私有npm存储库的网络连接的需要)。

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

1. NPM

CI环境将发布到私有NPM存储库，Ansible部署脚本将在提供之后签出特定版本。同样，当您想要部署时，这也会受到外部服务的依赖。我不喜欢这个。

1. Git

任何依赖于系统的模块都会作为供应的一部分在全局安装，并且所有其他依赖项都被签入存储库。这使我能够灵活地执行差别化部署，其中只有增量被推送，应用程序守护进程几乎可以立即由流程管理器自动重新启动。然后，完全锁定依赖项。

这意味着，除非进行扩展，否则没有必要编制新的VM。部署可以直接推送到所有活动实例。

Answer 1

首先，无论部署方法如何，都需要确保在部署新代码时不要删除请求。一个简单的方法是在切换之前将节点从负载均衡器中移除。在这样做之前，您还可能希望尝试并评估是否存在挂起的请求、打开的连接或任何其他受到过早终止的负面影响。或者类似于向上模块。

大多数人不会推荐源代码来控制你的模块。似乎在使用.tgz中的bundledDependencies声明时，已经从npm install中填充了带有npm install的bundledDependencies，这可能会解决所有的问题。使用这种方法，节点上的npm install将不会再次下载和安装所有内容。不过，它将重新构建节点-gyp实现，该实现可能涵盖您的系统库问题。

您还可以使用git标记来更容易地跟踪具有特定依赖项和有效负载的版本。手动部署代码可能会变得繁琐，您可能需要考虑在从接口迭代数据库中的x个已知服务器条目时自动化这个例程。docker.io可能是有兴趣的。