gitlab ci/cd 中,需要使用到 docker registry 账号 push 镜像,这个可以设置为机器人,可以避免个人账号泄露
配置Harbor机器人 登录 Harbor 管理界面,进入系统管理→认证页面; 选择机器人 Token页签,点击左上角的新建机器人,创建一个名为gitlab-ci的机器人; 给该机器人一个名称,并给该机器人添加相应的权限; 机器人创建完成以后,点击右侧的查看token来复制该机器人的 token,这个就是以后用 gitlab-ci 配置文件使用的账号密码; 在gitlab 创建 harbor-robot 用户; 为该用户添加项目级别的 开发 权限; 配置gitlab-ci 在项目的设置中添加 docker registry 账号密码,仓库地址是harbor的; 编辑.gitlab-ci.yml文件,把账号密码改为之前复制的 token; 注意点
有些情况下创建的机器人账户会带上$符号,在gitlab中是无法使用的,需要将$改为两个$$来表示$;
结束 这样gitlab-ci 就可以顺利跑测试、构建、推送镜像了;
以上内容,只是简单的配了配 harbor,可以有很多其他方法完成该工作,这里只是简单的记录下而已;
如果需要复杂的设置,欢迎移步harbor 文档,那里有更多的内容可以提供参考。
如果你打算搭建一套发布系统,你可能会考虑jenkins,或者其他。 我要介绍的则是一些现成的,使用更简单的工具。没用特殊环境要求的情况下则完全可以代替jenkins。
GitHub Actions gitlab ci 阿里云流水线 coding持续部署 上面只是列举了四类,实际上你会发现市面上的云服务商和代码仓库都提供了类似的工具,虽然有些是收费的,但是也有不少免费的,对于个人来说其实大多数都是够用了。
tsconfig.json 中 exclude node_modules,但 tsc 还是报错。
node_modules/connect-mongo/src/types.d.ts:113:66 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'. 113 get: (sid: string, callback: (err: any, session: Express.SessionData | null) => void) => void; ~~~~~~~~~~~ node_modules/connect-mongo/src/types.d.ts:114:45 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'. 114 set: (sid: string, session: Express.SessionData, callback?: (err: any) => void) => void; ~~~~~~~~~~~ node_modules/connect-mongo/src/types.d.ts:118:47 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'. 118 touch: (sid: string, session: Express.
去年花了三天时间开发了一个简易版的nodejs发布系统,它是基于pm2自带的deploy机制开发的,主要原理就是在两台装有pm2的机器直接通信,并执行相应的命令。再往简单了说就是在发布机上远程执行命令,而朱雀发布系统提供了一个图形界面而已。
当时把这个系统定位为nodejs专用发布系统,因为它依赖了pm2,而pm2则是nodejs专用的进程管理工具,其他语言用不到。这个系统的上线也算是解决了我司一直以来没有合适的nodejs发布系统的空缺。
经过9个月的使用,也算比较稳定。但是也存在问题,最大的问题是部署应用方面比较繁琐。
基本流程如下:
发布机和应用服务器设置ssh通信配置。 应用服务器安装git(有自带,但是版本太旧)。 配置git用户名,邮箱。 生成ssh公钥。 把应用服务器的公钥配置到git代码服务器上。以便能拉代码。 发布机远程执行git pull来代码操作,各应用服务把代码拉取下来。 执行编译打包操作。 执行重启服务操作。 部署一次系统还是比较麻烦的,如果应用服务器有多台,可能还要重复这样的操作多次,实在比较麻烦。
使用scp同步代码的方式会比较简单一些,但是像nodejs这样的项目,node_module占了很大比重,如果每次都打包的话会拖慢同步速度,而scp又不具备排除文件夹的能力。
最后找到了rsync命令可以满足需求。然后就是基于rsync实现了一版。不用再依赖pm2,应用服务器也不用强制使用git了。
朱雀和Jenkins对比如何? 要说Jenkins那绝对是持续集成领域的老大哥,自然是功能强大。但是每个团队和产品有其特殊性,Jenkins并不完全适用。而朱雀也有其优势。
朱雀本身部署简单,使用go开发,不依赖运行时,无需安装,开箱即用。 目前支持和测试过的数据库有sqlite3(目前用的,不需要繁琐的安装过程)和mysql。 配置简单。 部署发布一键完成,不需要单独的部署过程。 并行发布。 审批,通知,权限。 开源,可定制开发。 项目地址:朱雀发布系统
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发布系统
朱雀发布系统支持scp(rsync)发布