前端的gitlab的ci初尝试

时间 2019-11-07

标签前端 gitlab 尝试栏目 Git 繁體版

原文原文链接

本文记录一个前端部署Gitlab的CI。不是在本身的服务器上面搭建的Gitlab。使用的是Gitlab.com的Gitlab的CI，在腾讯云撸的羊毛的小水管也搭不起Gitlab，作个CI的服务器仍是能勉勉强强的。php

Gitlab和Github

Github 一个网站，提供给用户空间建立git仓储，保存用户的一些数据文档或者代码等。html

Gitlab 一个基于git实现的在线代码仓库软件，你能够用Gitlab本身搭建一个相似于Github同样的系统，通常用于在企业、学校等内部网络搭建Git私服。前端

什么是持续集成

阮一峰的这个文章写的挺好的持续集成是什么？vue

持续集成指的是，频繁地（一天屡次）将代码集成到主干。node

持续集成的目的，就是让产品能够快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干以前，必须经过自动化测试。只要有一个测试用例失败，就不能集成。linux

Gitlab的CI

从 GitLab 8.0 开始，GitLab CI 就已经集成在 GitLab 中，咱们只要在项目中添加一个 .gitlab-ci.yml 文件，而后添加一个 Runner，便可进行持续集成。并且随着 GitLab 的升级，GitLab CI 变得愈来愈强大。nginx

首先明白Gitlab CI 几个基本的概念git

GitLab-CI

这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。github

GitLab-Runner

这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件以后，根据里面的规则，分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的，有的是部署用的。vue-cli

.gitlab-ci.yml

这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。

简单来讲就是，你利用Git版本管理Push了本地代码到Remote上(这里就是你gitlab.com)，而后Gitlab，就通知你的服务器，也就是Gitlab-runner来运行构建任务。而后跑测试用例，测试用例经过了就生成Build出相应的环境的代码，自动部署上不一样的环境服务器上面去。

安装Gitlab Runner

若是想要使用Docker Runner，则须要安装Docker。（可选）

curl -sSL https://get.docker.com/ | sh
复制代码

安装 GitLab Runner 太简单了，按照着官方文档的教程来就好拉！下面是 Debian/Ubuntu/CentOS 的安装方法，其余系统去参考官方文档：

# For Debian/Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner
# For CentOS
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ci-multi-runner
复制代码

而后注册Gitlab Runner Runner须要注册到Gitlab才能够被项目所使用，一个gitlab-ci-multi-runner服务能够注册多个Runner。

在 GNU/Linux 系统上注册 Runner:

运行下面命令启动注册程序:

sudo gitlab-runner register
复制代码

输入 GitLab 实例 URL:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
复制代码

输入获取到的用于注册 Runner 的 token:

Please enter the gitlab-ci token for this runner
xxx //这个token在你gitlab.com的项目的 setting >> CI/CD >> Runners settings 下
复制代码

输入该 Runner 的描述，稍后也可经过 GitLab's UI 修改:

Please enter the gitlab-ci description for this runner
一个配置很低的服务器
复制代码

给该 Runner 指派 tags, 稍后也能够在 GitLab's UI 修改:

Please enter the gitlab-ci tags for this runner (comma separated):
tengxun // 这个就至关于每个runner的惟一id，记住这个tag。
复制代码

选择 Runner 是否接收未指定 tags 的任务（默认值：false），稍后能够在 GitLab's UI 修改：

Whether to run untagged jobs [true/false]:
[false]: true
复制代码

选择是否为当前项目锁定该 Runner，以后也能够在 GitLab's UI 修改。该功能一般用于被指定为某个项目的 Runner （默认值：true）：

Whether to lock Runner to current project [true/false]:
[true]: true
复制代码

选择 Runner executor:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker  // 我选择的docker，请记住，选择docker的以前要把docker启动，docker的使用就不是本文所讲的了
复制代码

若是你选择 Docker 做为你的 executor，注册程序会让你设置一个默认的镜像，做用于 .gitlab-ci.yml 中未指定镜像的项目：

Please enter the Docker image (eg. ruby:2.1):
alpine:latest
复制代码

而后，你刷新你setting下面的配置

有个绿色的小圆点，这就代表你已经注册Runner成功了。

配置.gitlab-ci.yml

配置好 Runner 以后，咱们要作的事情就是在项目根目录中添加 .gitlab-ci.yml 文件了。当咱们添加了 .gitlab-ci.yml 文件后，每次提交代码或者合并 MR 都会自动运行构建任务了。

在.gitlab-ci.yml有一些须要讲解的概念

Pipeline

一次 Pipeline 其实至关于一次构建任务，里面能够包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。咱们的任何提交或者 Merge Request 的合并均可以触发 Pipeline。以下图：

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+
复制代码

Stages

Stages 表示构建阶段，说白了就是上面提到的流程。咱们能够在一次 Pipeline 中定义多个 Stages，每一个Stage能够完成不一样的任务。 Stages有下面的特色：

全部 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
只有当全部 Stages 完成后，该构建任务 (Pipeline) 才会成功
若是任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

所以，Stages 和 Pipeline 的关系就是：

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+
复制代码

Jobs

Jobs 表示构建工做，表示某个 Stage 里面执行的工做。咱们能够在 Stages 里面定义多个 Jobs，这些 Jobs 会有如下特色：

相同 Stage 中的 Jobs 会并行执行
相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
若是任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

因此，Jobs 和 Stage 的关系图就是：

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+
复制代码

这些是部署脚本里面的一些基本结构，接下来讲一些.gitlab-ci.yml的基本构成

下面是一个最简单的Node项目的部署脚本。

image: node:alpine  // 默认的ci部署的docker镜像

stages:  // 首先按顺序定义有几个步骤。步骤下面的全部job是同步执行的
 - test  
 - build
  
job1:
 stage: test  // 属于test的stage
 script:
 - npm run test // 这个job执行的脚本
 only:
 - master  // 只监听master分支的代码提交
 tags:
 - tengxun  // 要使用哪一个runner

job2:
 stage: build
 script:
 - npm run build
 only:
 - master
 tags:
 - tengxun

复制代码

注意这里的job1，job2名字是随便取的，没有关系，只要不用Gitlab-CI的关键字就能够。

列出一些经常使用的关键字，掌握了这些就能够开发了。

关键字	是否必须	描述
image	否	用于docker镜像，查看docker文档
services	否	用于docker服务，查看docker文档
stages	否	定义构建阶段
types	否	stages 的别名(已废除)
before_script	否	定义在每一个job以前运行的命令
after_script	否	定义在每一个job以后运行的命令
variable	否	定义构建变量
cache	否	定义一组文件列表，可在后续运行中使用

发现这篇文章对每一个关键字对解释的好清楚，算是个抛砖引玉吧。比我写的都还要清楚。

Gitlab CI yaml官方配置文件翻译

配置以前，你还要在你gitlab.com的对应项目里面的setting >> CI/CD >> Secret variables 定义一些构建变量，由于你的Gitlab-CI要去自动的登陆服务器，而后把打包出来的文件自动更新上去。

Runner 登陆你的服务器是不能用传统输入帐号密码的形式，（由于都自动化了，还须要输入密码，那还叫什么自动化）。只能经过走SSH登陆的形式，若是不懂SSH登陆，请自行谷歌。私钥这些东西确定不能写在yml文件里面，由于yml文件是每一个人都能看见的，因此Gitlab-CI就能够在项目里面自定义私有的变量名。至少项目开源出去以后，不是每一个人都能看见部署服务器的私钥的。

这里的$SSH_PRIVATE_KEY 是你开发机（也就是你的的开发电脑）生成的私钥。注意必定要复制

-----BEGIN RSA PRIVATE

-----END RSA PRIVATE KEY-----
复制代码

这些东西。（这里是个坑。。。由于不多会让你复制私钥的）下面配置的${CI_COMMIT_REF_NAME}，是Gitlab CI 的默认关键字。详情见文档

最后贴上我那个腾讯云小水管的配置，亲测有用。

还真是一个很简单的vue项目。就用vue-cli生成，而后发布到服务器上面指定的目录，服务器上面的nginx配置已经配置好了。

stages:
  - test
  - build
  - deploy

cache:
  key: ${CI_COMMIT_REF_NAME}
  paths:
  - node_modules/

test_dev:
  image: node:alpine
  stage: test
  only:
    - dev
  tags:
    - tengxun
  script:
    - npm run test


build:
  image: node:alpine
  stage: build
  only:
    - master
    - dev
  tags:
    - tengxun
  script:
    - npm set registry https://registry.npm.taobao.org # 设置淘宝镜像地址
    - npm install --progress=false
    - npm run build
  artifacts:  
    expire_in: 1 week
    paths:
      - dist

deploy_dev:
  image: alpine
  stage: deploy
  only:
    - dev
  tags:
    - tengxun
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_DEV_PATH"

deploy_master:
  image: alpine
  stage: deploy
  only:
    - master
  tags:
    - tengxun
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_MASTER_PATH"
  when: manual
复制代码

这里用rsync来同步Build出来的代码，其实也很简单的。

rsync 是一个开源工具，能够进行快速的增量的文件传输。相关文章

简单来讲就是让你源计算机和目标计算机进行文件的同步。

附上rsync的翻译的文档点我

在GitLab-CI中, cache与artifacts比较容易混淆.

其中 cache 指的是缓存, 经常使用于依赖安装中, 如几个jobs都须要安装相同的依赖, 可使用依赖, 此时能够加快依赖的安装进度; 对于artifacts则是将某个工件上传到GitLab提供下载或后续操做使用, 因为每一个job启动时, 都会自动删除.gitignore中指定的文件, 所以对于依赖安装目录, 便可以使用cache, 也可使用artifacts.

两个主要有如下几个区别:

虽然定义了cache, 可是若是cache和.gitignore中重复的这部分, 仍然须要从新安装

从新安装时由于使用的是缓存, 因此颇有可能不是最新的

特别是开发环境, 若是每次都但愿使用最新的更新, 应当删除cache, 使用artifacts, 这样能够保证肯定的更新

artifacts中定义的部分, 会自动生成, 并能够传到下面的job中解压使用, 避免了重复依赖安装等工做若是使用Docker运行Gitlab-Runner, cache会生成一些临时容器, 不容易清理

artifacts能够设置自动过时时间, 过时自动删除

artifacts会先传到GitLab服务器, 而后须要时再从新下载, 因此这部分也能够在GitLab下载和浏览

由于咱们这里要重复使用以前job打包出来在dist下面的文件，因此我会使用artifacts。

when: manual

这里master通常是值稳定的代码版本，因此最好手动执行的。when: manual就是须要手动部署，全部job默认都是自动执行的。

鲁迅曾经说过：有国内加速镜像地址的必定要用国内镜像地址

这里的镜像地址配置包括Docker，APK，NPM。必定要设置啊，当时就卡在这里了好久。

而后咱们push代码到master，点击你项目的CI/CD面板。

而后小水管过了2分钟才跑完Build，扎心了。

点击右面的那个播放三角形，就能够部署到个人那个腾讯云服务器上面去了。（固然，dev分支是默认自动部署和的），这就开始构建了。

好啦，一个简单的前端CI尝试就完了。

that's all。

参考资料

gitlab之gitlab-ci自动部署 GitLab 中文文档 Gitlab CI yaml官方配置文件翻译用 GitLab CI 进行持续集成