GitLab CI 持续集成

原创
2019/04/14 16:51
阅读数 3.9K

简介

从GitLab 8.0开始就把GitLab-Ci集成在GitLab中了,我们只要在项目中添加一个.gitlab-ci.yml文件,然后添加一个Runner就可以进行持续集成了,GitLab-Ci实现自动化部署流程:用户提交代码->检查是否有.gitlab-ci.yml文件->如果无,则结束;如果有,则调用runner执行脚本->获取返回的结果。

概念

  • pipline

一次piplien相当于一次构建任务,里面可以包含多个流程,如编译、测试、部署等。任何提交或者MergeRequest的合并都可以触发Pipline,如图:

  • Stages

Stages表示构建阶段,我们可以在一个Piplien中定义多个Stages,这些Stages会有以下特点:

  1. 所有的Stages会按照顺序运行,即当一个Stages完成后,下一个Stage才开始
  2. 只有当所有Stages完成后,该构建任务(Pipline)才会成功
  3. 如果任何一个Stage失效,那么后面Stages不会执行,该构建任务(Pipline)失效

因此,Stages和Pipline的关系是:

  • Jobs

Jobs表示构建工作,表示某个Stage里面执行工作,我们可以在Stage里面定义多个Jobs,这些Jobs会有以下特点:

  1. 相同Stage中的Jobs会并行执行。
  2. 相同Stage中的Jobs都执行成功时,该Stage才会成功。
  3. 如果任何一个Job失败,即该构建任务(Pipline)失败。

Jobs和Stage的关系图:

  • gitlab runner

执行构建任务的一个服务,把构建任务放到runner里面而不是在CI里面做是不想把”构建”这个重任(通常较大的工程构建都比较小耗资源) 放到gitlab上而影响gitlab性能。通过把gitlab runner安装到不同机器上,让这台单独的机器来执行构建任务,GitLab-Runner可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型):

  1. Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
  2. Specific Runner:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

向GitLab-CI注册一个Runner需要两样东西:GitLab-CI的url和注册token。如果要注册Shared Runner,你需要到管理界面的Runners页面里面去找注册token。如下图所示:

如果要注册Specific Runner,需要到指定的项目中去找对应的token,如图:

实践

  • GitLab-Runner的安装与注册

以centos 7为例, 使用了清华大学的镜像,新建 gitlab-ci-multi-runner.repo

[root@i-vvwtw5ne ~]# touch /etc/yum.repos.d/gitlab-ci-multi-runner.repo

将以下内容写入文件

[gitlab-ci-multi-runner]
name=gitlab-ci-multi-runner
baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packages.gitlab.com/gpg.key

执行

[root@i-vvwtw5ne ~]# yum makecache
[root@i-vvwtw5ne ~]# yum install gitlab-ci-multi-runner

注册一个Rnner

让Runner启动起来

[root@i-vvwtw5ne ~]# gitlab-runner start

登陆到gitlab就可以看到新注册的Runner了,如图:

配置.gitlab-ci.yml文件

在工程目录下增加一个.gitlab-ci.yml文件,内容如下:

# 缓存服务, 如果有文件需要多个stages共用,例如jar/war包
cache:
  paths:
  - target/

# 本次构建的阶段:build package
stages:
- build
- deploy
# 构建 Job
build:
  stage: build
  tags:
  - dev
  only:
   - dev
  script:
  - echo "=============== 开始编译构建和打包任务  ==============="
  - pwd
  - gradle clean build -x test
  # 部署
deploy:
  stage: deploy
  tags:
  - dev
  only:
   - dev
  script:
  - echo "=============== 开始部署任务  ==============="
  # 测试,是否能够通过 ssh 连通远程服务器
  - sshpass -p Falsesoul**** ssh -o StrictHostKeychecking=no root@192.192.18.73
  - echo "=============== 将 jar 包部署到远程服务器上  ==============="
  - sshpass -p Falsesoul**** scp -o StrictHostKeychecking=no /home/gitlab-runner/builds/66b08c53/0/cos/yh-cos/yh-cos-web/build/libs/yh-cos-web-0.0.1.jar  root@192.192.18.73:/opt/war/
  - echo "=============== 开始执行  ==============="
  - sshpass -p Falsesoul**** ssh -o StrictHostKeychecking=no root@192.192.18.73 "sh deploy.sh"

当有提交或Meger request到dev分支的时候,就会自动触发pipline,如图:

 

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部