首先让我解释一下上下文。
上下文
当前,我们正在使用Jenkins服务器,并将Chef Server用于我们的配置管理。我们正在朝着更加连续的部署环境迈进,这就是我一直在努力的工作流程:
在暂存和生产环境的提升(手动触发)中,我没有可用的Internet连接。 RPM解决了这个问题。这些菜谱是使用Berkshelf开发的。
以这种方式部署的Node.js应用程序有时确实会使用已编译的 native 库(一个项目具有3个以上的依赖项编译 native 代码)。
我对这类部署过程知之甚少,但是我听到的一个缺点是,使用RPM并仅在编译环境(当前为Jenkins本身)具有与部署环境相同的体系结构时才对其进行编译。
使用RPM的好处是,工件在所有环境中都保持完全相同,不需要重新编译,并且不会从任何地方提取数百个依赖项。
尽管如此,工作流程似乎有些复杂,对我而言,必须坚持相同的体系结构并不十分灵活。
对于我们的用例,我们需要以下内容:
对于我自己的项目,我大部分时间都在使用Heroku,而无需进行任何设置。上面的工作流程需要两个星期才能创建(第一次)。
问题
处理所有这些工作的巨大努力使我对上述一些步骤提出了质疑:
您可能能够分享的任何经验将不胜感激!
最佳答案
1)最好将所有依赖项与您的应用程序一起交付,然后npm在目标计算机上重建它们。或者,如果您想进入企业,则可以在构建服务器上重建模块,然后打包到tarball/docker或lxc容器/VM镜像中/命名。没有银弹。我个人更喜欢普通的LXC容器。但一般的行为是:将模块与应用程序 bundle 在一起,并在目标平台上重建二进制模块。
2)对于简单的脚本应用程序,最好使用tarball甚至git clone。不,在这种情况下,您实际上不需要系统软件包管理器的所有强大功能和复杂性。但是,如果您要使用定制的nginx或某种系统范围的库或类似的东西,则最好使用RPM或DEB并为您的定制包设置适当的存储库。
3)我不使用Chef,但是对于任何大型项目,最好将部署脚本分为独立的仓库。我的意思是您的部署代码不是您的应用程序代码。就像在一个仓库中有两个单独的应用程序一样。可能但不是一个好习惯。
4)很好。可以扩展,因为您可以只从一台物理计算机开始,然后随您的成长而增长(但是,这听起来很简单。我花了很多时间使我当前的项目可扩展)。但这对于集成测试总是非常好的。您可以生成整个环境,运行集成测试,获取结果,然后在新的环境中从头开始进行新的测试。
关于node.js - Node.js部署,在使用Jenkins和Chef的企业环境中使用哪种方法?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24417233/