2. Permission denied, please try again
出现这个问题是没有配置「ssh免密登录」,配置操作见@为什么需要免密登录部分
3. rsync: Failed to exec a: No such file or directory
这个问题一般情况下并不会出现,但却是个实实在在的坑。我在deploy的job里面通过rsync将构建生成的dist目录上传至服务器,抛出不存在该目录的错误。我在compile这个job执行后,list下根目录下的文件/夹:
可以看见,实实在在是生成了dist目录,但进入下一个job的时候却提示不存在!问题出在:
dist目录并不是由构建直接生成的文件夹,而是release-[timestamp]目录的软链接(笔者用的是Ubuntu,在webpack配置里面设置了个骚操作:每次构建产出一个release-[timestamp]目录,同时建立一个软链。软链不是一个目录,它的内容就是目标文件夹的地址)。
在我的.gitlab.yml配置里面,artifacts缓存的是dist,没有把实际的文件夹release-[timestamp]缓存,那么进入下一个job的时候,自然就提示不存在该目录了。解决办法是:
前言
本文介绍的内容包含:
阅读本文需要你:
CI/CD科普
1. CI与CD
持续集成(Continuous Integration)指开发人员在特性分支(频繁)提交代码,立即执行构建和单元测试,代码通过测试标准后集成到主干的过程。强调的是分支代码的提交、构建与单元测试,这个过程的产出是单元测试报告。
说明:这里的 test 是指unit test(图片来源见文末参考链接)
持续交互(Continuous Delivery)是在持续集成的基础上,将构建的代码部署到「类生产环境」,完成QA测试之后手动部署到生成环境的过程。强调代码部署,这个过程产出测试报告。
说明:这里的 test 是真的test
持续部署(Continuous Deployment)是持续交互的下一步,强调部署生产环境代码的过程自动化,同时可以处理上线通知等操作。
说明:与持续交互主要就是手动跟自动的区别。
2. CI/CD的必要性
以一言概之的话我想应该是:机械的事情让机器做。一个开发团队,没有CI/CD,我想可能是这样子的:无法管理代码多人多地协作(git repository也是CI的一部分),系列的shell需要人工处理,代码的发布需要登录服务器等等;相反,拥有CI/CD,这些事情都交给机器去完成,腾出的碎片时间去做更有意义的事情(比如摸鱼放松下)。
3. 理想的CI/CD开发流应该是怎样的?
我认为理想的CI/CD开发流应该包含三个阶段:build、deploy和notify build阶段专注做代码构建与单元测试,deploy阶段专注做test/gray/prod环境的代码部署,notify阶段专注做上线通知,如下图;![image](https://user-images.githubusercontent.com/26505680/55954980-bef1a980-5c92-11e9-9dc9-f962703bf09b.png)
以下内容围绕build和deploy两个阶段完成从0到1的部署。笔者的系统环境:Ubuntu 18.04.1 LTS
Gitlab-Runner安装并注册
官网文档 install gitlab-runner
之后是QA式操作,按照提示语输入信息即可,可参考官网操作,需要注意:
注册成功后,我们就能在:Settings >> CI/CD >> Runners下看到我们注册的runner![image](https://user-images.githubusercontent.com/26505680/55956821-7092d980-5c97-11e9-8313-768fb9471449.png)
Gitlab-Runner配置
在项目根目录下新建 .gitlab.yml文件,加入如下内容:
unit_test、compile和deploy_test是自定义的job名字,另外几点配置说明:
tags
(打tag时触发)等(这些条件是或的关系,满足其中一个即触发);on_success
、always
、manual
等;before_script
有很长一段内容,这里的作用是配置ssh免密登录,后面详述。ssh免密登录
为什么需要免密登录?
先在本机(注册runner所在的机器)配一遍免密登录服务器的流程: 1. 生成一对公私钥:使用rsa作为非对称加密方式
说明:一路enter就好了,切记 Enter passphrase 时直接enter,这样就是 no passphrase。如果你非要加个password,对不起,没救了!
2. 定义ssh config内容:在~/.ssh/config文件写入以下内容(文件不存在直接创建)
说明:定义ssh的config文件是为了快捷访问,就像你配置host一样,没有hostname,你只能访问ip。配置后你就可以通过
ssh any_name
登录服务器了。当然,不出意外,会要求你输入服务器的登录密码。3. 免密登录: 免密登录的精髓就是:把本机的公钥存储到目标服务器的authorized_keys文件内(该文件服务器上不存在可以直接创建。)
特别地:如果你的端口不是默认的22端口,则加上端口号
-p PORT
4. 验证登录:
不出意外,你应该可以直接登录服务器了。那么,我们回到gitlab的配置上~
gitlab上定义ssh配置信息
我们进入gitlab页面位置:Settings >> CI/CD >> Environment variables下定义![image](https://user-images.githubusercontent.com/26505680/55960821-1ea28180-5ca0-11e9-8d1f-12f768813af5.png)
.gitlab.yml
上出现的几个变量:使用rsync传输文件
说明:hostname就是你在ssh config定义的
Host
值。rsync操作指南定义environment
设置environment的好处是可以对各发布环境进行管理,特别是线上发布,出现bug可以及时操作回滚。 在gitlab web页面位置:Operations >> environments 可以查看当前项目下的environments,点击其右侧的预览按钮即可查看对应环境的发布效果
点击其中一个environment:test_env,可以查看当前环境下的所以发布记录,右侧的按钮可以执行回滚操作。
![image](https://user-images.githubusercontent.com/26505680/55962177-f9634280-5ca2-11e9-8985-c4b273e99909.png)
踩坑小记
在整个搭建过程,很多都是关于ssh登录服务器的问题,择几个高频出现的问题说明下: 1. Host key verification failed 当我们初次使用ssh登录服务器的时候,ssh会要求验证远程服务器的身份,通过身份验证之后才允许连接。解决该问题有两种方式:
StrictHostKeyChecking no
,如此.gitlab.yml
配置中就可以去掉关于known_hosts
的设置了;将脚本输出的结果保存在
~/.ssh/known_hosts
文件中(@gitlab上定义ssh配置信息部分有提及),这样ssh在登录之前会从该文件中拿到目标服务器的公钥指纹进行身份确认。2. Permission denied, please try again 出现这个问题是没有配置「ssh免密登录」,配置操作见@为什么需要免密登录部分
3. rsync: Failed to exec a: No such file or directory 这个问题一般情况下并不会出现,但却是个实实在在的坑。我在deploy的job里面通过rsync将构建生成的dist目录上传至服务器,抛出不存在该目录的错误。我在compile这个job执行后,list下根目录下的文件/夹:
可以看见,实实在在是生成了dist目录,但进入下一个job的时候却提示不存在!问题出在:
dist目录并不是由构建直接生成的文件夹,而是release-[timestamp]目录的软链接(笔者用的是Ubuntu,在webpack配置里面设置了个骚操作:每次构建产出一个release-[timestamp]目录,同时建立一个软链。软链不是一个目录,它的内容就是目标文件夹的地址)。
在我的
.gitlab.yml
配置里面,artifacts
缓存的是dist
,没有把实际的文件夹release-[timestamp]
缓存,那么进入下一个job的时候,自然就提示不存在该目录了。解决办法是:在compile这个job里面,构建之后复制一份dist目录,再将
public
目录交由artifacts
缓存。参考文章