nodejs专用发布系统
Nodejs项目部署到服务器以后接下来做的最多的操作就是上线发布了。因为nodejs的语言特性决定了其开发效率高,发布自然就频繁,每个公司或个人都有自己的发布方式。
有的公司会有严格的流程,必须通过CI/CD工具进行发布,有可能使用现成的工具,如:jenkins。有可能是自研发布系统。
有的公司会通过FTP上传代码到服务器发布。
有的公司使用更原始的发布方式,直接登录服务拉代码发布。
不论哪种发布方式都有其优缺点,越高级的工具会有诸多限制,比如有权限控制,有严格的审批流程,自然就不能随时发布,也就越僵化。越原始的方式越简单越灵活,自然风险也越高。
至于采用哪种发布方式,依据需要选择即可。
而关于nodejs的发布方式,本人也是也是多种方式都有使用,公司项目也经历过多次变迁。公司最开始是直接登录服务器拉代码发布,后来有了运维团队,领导说开发自己发布不安全,于是就由运维搭建了Jenkins环境来发布,但是每次发布都需要走流程,后来因为发布太频繁,每1-2天要发布一次,又要灰度发布,运维也会觉得烦。于是开发就搭建了某个发布系统自己来发布,不过这个发布系统有个缺点,就是发布集群的时候是串行的,每次发布要十几分钟。
另外说明一下Jenkins。它应该是使用最多的发布系统了,Jenkins基于Java开发,它已经是成熟的系统了,成熟同时也代表着复杂,复杂代表修改困难,我想大家也不太会基于Jenkins定制开发。 然后是部署困难,相比较nodejs三条命令搞定linux安装nodejs——快捷版,go直接放二进制文件部署,Jenkins部署可能就略显复杂了。
于是下定决心自己开发一个发布系统,朱雀发布系统因此诞生。
基于以往的发布系统使用经历,我想要的是一款使用够灵活,部署够简单的发布系统。市面上现有的系统为了满足各种语言的发布,做的大而全。我自然是不想重蹈覆辙再做一个大而全的系统,我要的是小而美。正好之前了解过PM2本身集成了远程发布功能,可以在此基础上开发。PM2本身的发布过程其实已经很简单了,而且足够灵活,能够满足我的部分要求,但是公司的环境是不能在本地直接连接应用服务器的,所以需要一个中间层代理一下,放一张简单的架构图:
和其他工具架构逻辑一样,都是通过ssh来通信,不同的是朱雀没有直接使用ssh,而是利用了pm2,由pm2来实现通信,它已经为了做了一部分工作,比如拉代码,回滚,执行远程脚本。 由于nodejs的项目特性,它依赖了node_modules包,如果按照打包的方式发布会又大又费时,所以还是选择拉git代码的方式发布比较合适。 所以我只需要给它做一个图形界面,并有一定的管理和审批流程(可根据环境跳过)。 放一张图来看一下:
项目地址:nodejs发布系统