一、前言
本文介绍的内容包含:
- 理解CI/CD及其必要性
- gitlab-runner安装与注册
- gitlab-ci配置说明
- ssh免密登录
- rsync部署文件
- 多环境发布与回滚
- 高频出现的问题并解决
阅读本文需要你:
- 有一定的ssh知识基础,一份SSH操作指南
- gitlab ci/cd概念基础
- 花10min左右的时间
二、CI/CD科普
2.1 CI与CD
<font color="#ff502c">持续集成(Continuous Integration)</font>指开发人员在特性分支(频繁)提交代码,立即执行构建和单元测试,代码通过测试标准后集成到主干的过程。强调的是分支代码的提交、构建与单元测试,这个过程的产出是单元测试报告。
说明:这里的 test 是指unit test(图片来源见文末参考链接)
<font color="#ff502c">持续交互(Continuous Delivery)</font>是在持续集成的基础上,将构建的代码部署到「类生产环境」,完成QA测试之后手动部署到生成环境的过程。强调代码部署,这个过程产出测试报告。
说明:这里的 test 是真的test
<font color="#ff502c">持续部署(Continuous Deployment)</font>是持续交互的下一步,强调部署生产环境代码的过程自动化,同时可以处理上线通知等操作。
说明:与持续交互主要就是手动跟自动的区别。
2.2 CI/CD的必要性
以一言概之的话我想应该是:机械的事情让机器做。一个开发团队,没有CI/CD,我想可能是这样子的:无法管理代码多人多地协作(git repository也是CI的一部分),系列的shell需要人工处理,代码的发布需要登录服务器等等;相反,拥有CI/CD,这些事情都交给机器去完成,腾出的碎片时间去做更有意义的事情(比如摸鱼放松下)。
2.3 理想的CI/CD开发流应该是怎样的?
我认为理想的CI/CD开发流应该包含三个阶段:build
、deploy
和notify
。build阶段专注做代码构建与单元测试,deploy阶段专注做test/gray/prod环境的代码部署,notify阶段专注做上线通知,如下图;
以下内容围绕build和deploy两个阶段完成从<font color="red">0到1的部署</font>。笔者的系统环境:<font color="red">Ubuntu 18.04.1 LTS</font>
三、Gitlab-Runner安装并注册
3.1 安装runner
sudo apt-get install gitlab-runner
3.2 注册runner
sudo gitlab-runner register
之后是QA式操作,按照提示语输入信息即可,可参考官网操作,需要注意:
①. gitlab host和token在你的gitlab项目上找,页面路径是:Settings >> CI/CD >> Runners
②. runner执行器选择 docker,image(镜像)输入 node:8.11.2-stretch
注册成功后,我们就能在:Settings >> CI/CD >> Runners下看到我们注册的runner
四、Gitlab-Runner配置
在项目根目录下新建 .gitlab.yml
文件,加入如下内容:
unit_test
、compile
和deploy_test
是自定义的job名字,另外几点配置说明:
-
cache
:
cache设置缓存文件,这里缓存node_module依赖包,提高job构建效率,定义在全局,对所有的job生效; -
stage
:
设置build和deploy两个阶段 -
artifacts
:
下载文件。定义compile产出的dist文件夹缓存到gitlab服务器,提供下载(gitlab web页面下载)或者在同一个stage的各job之间共享; -
only
:
定义job的触发条件,可以指定分支名、tags
(打tag时触发)等(这些条件是或的关系,满足其中一个即触发); -
when
:
定义job的触发时机,值可以为:on_success
、always
、manual
等; -
dependencies
:
定义当前job所要依赖的job; -
environment
:
定义当前job所属的环境,对<font color="red">回滚操作非常有用</font>,后面详述; - deploy_test这个job的
before_script
有很长一段内容,这里的作用是配置ssh免密登录,后面详述。
五、ssh免密登录
5.1 为什么需要免密登录?
- 构建产出的dist文件要传输到目标服务器(测试机/生成机),要么基于http网络协议、要么基于ssh协议(或其他文件传输协议?)
- 基于http需要写文件接收接口,这里直接使用基于ssh传输文件的rsync,简单、安全!
- runner内定义的一系列script是在一个docker容器内执行的,无法人工干预,那么登录服务器就要做成免密。
先在本机(注册runner所在的机器)配一遍免密登录服务器的流程:
5.2. 生成一对公私钥
使用rsa作为非对称加密方式:
ssh-keygen -t rsa -C "$(whoami)@$(hostname)-$(date -I)"
说明:一路enter就好了,切记 Enter passphrase 时直接enter,这样就是 no passphrase。如果你非要加个password,对不起,没救了!
5.3. 定义ssh config内容
在~/.ssh/config文件写入以下内容(文件不存在直接创建):
Host any_name
Port your_port
HostName server_ip
User user
IdentityFile ~/.ssh/id_rsa
说明:定义ssh的config文件是为了快捷访问,就像你配置host一样,没有hostname,你只能访问ip。配置后你就可以通过 ssh any_name
登录服务器了。当然,不出意外,会要求你输入服务器的登录密码。
5.4. 免密登录
免密登录的精髓就是:<font color="red">把本机的公钥存储到目标服务器的authorized_keys文件内</font>(该文件服务器上不存在可以直接创建。)
ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip
特别地:如果你的端口不是默认的22端口,则加上端口号 -p PORT
5.5. 验证登录
ssh any_name
不出意外,你应该可以直接登录服务器了。那么,我们回到gitlab的配置上~
六、gitlab上定义ssh配置信息
我们进入gitlab页面位置:Settings >> CI/CD >> Environment variables下定义 .gitlab.yml
上出现的几个变量:
-
SSH_PRIVATE_KEY
:把本机(runner所在机器)的私钥复制过来:~/.ssh/id_rsa -
TEST_CONFIG
:把刚才ssh config定义的信息复制过来:~/.ssh/config -
TEST_KNOWN_HOST
:定义这个变量是为了让ssh对服务器进行身份确认(不然会被ssh认为是一个不被信任的环境),变量值使用以下命令生成:
ssh-keyscan -p PORT IP
七、使用rsync传输文件
rsync -rve ssh dist/ user@hostname:project_path/dist
说明:hostname
就是你在ssh config
定义的Host
值。rsync操作指南
八、定义environment
设置environment的好处是可以对各发布环境进行管理,特别是线上发布,出现bug可以及时操作回滚。
在gitlab web页面位置:Operations >> environments 可以查看当前项目下的environments,点击其右侧的预览按钮即可<font color="red">查看</font>对应环境的<font color="red">发布</font>效果
点击其中一个
environment:test_env
,可以查看当前环境下的所以发布记录,右侧的按钮可以执行<font color="red">回滚操作</font>。九、踩坑小记
在整个搭建过程,很多都是关于ssh登录服务器的问题,择几个高频出现的问题说明下:
9.1. Host key verification failed
当我们初次使用ssh登录服务器的时候,ssh会要求验证远程服务器的身份,通过身份验证之后才允许连接。解决该问题有两种方式:
-
设置免身份认证:
在ssh config配置中加一段StrictHostKeyChecking no
,如此.gitlab.yml
配置中就可以去掉关于known_hosts
的设置了; - 通过远程服务器的公钥指纹进行身份认证:
ssh-keyscan -p PORT IP
将脚本输出的结果保存在~/.ssh/known_hosts
文件中(<font color="#ff502c">@gitlab上定义ssh配置信息</font>部分有提及),这样ssh在登录之前会从该文件中拿到目标服务器的公钥指纹进行身份确认。
9.2. Permission denied, please try again
出现这个问题是没有配置「ssh免密登录」,配置操作见<font color="#ff502c">@免密登录</font>部分
9.3. rsync: Failed to exec a: No such file or directory
这个问题一般情况下并不会出现,但却是个实实在在的坑。我在deploy的job里面通过rsync将构建生成的dist目录上传至服务器,抛出不存在该目录的错误。
我在compile这个job执行后,list出根目录下的文件/夹(gitlab-runner的输出):
在本机查看根目录下的文件/夹:
可以看见,gitlab-runner执行构建后实实在在是生成了dist目录,但进入下一个job的时候却提示不存在!问题出在:
dist目录并不是由构建直接生成的文件夹,而是
release-[timestamp]
目录的<font color="red">软链接</font>(笔者用的是Ubuntu,在webpack配置里面设置了个骚操作:每次构建产出一个release-[timestamp]
目录,同时建立一个软链。软链不是一个目录,它的内容就是目标文件夹的地址)。在我的
.gitlab.yml
配置里面,artifacts
缓存的是dist
,没有把实际的文件夹release-[timestamp]
缓存,那么进入下一个job的时候,自然就提示不存在该目录了。解决办法是:
cp dist public
在compile
这个job里面,构建之后复制一份dist目录,再将public
目录交由artifacts
缓存。