首页 > 运维 > Gitlab-CICD实战教程
2021
07-14

Gitlab-CICD实战教程

背景

由于目前公司使用的gitlab,大部分项目使用的CICD是gitlab的CICD,少部分用的是jenkins,使用了gitlab-ci一段时间后感觉还不错,因此总结一下

CICD是什么

我们的开发模式经历了如下的转变:瀑布模型->敏捷开发→DevOps(Development、Operations的组合词,是一组过程、方法与系统的统称)

后来随着DevOps的兴起,出现了持续集成(Continuous Integration)、持续交付(Continuous Delivery) 、持续部署(Continuous Deployment) 的新方法,关于持续集成、持续交付、持续部署,总结如下:

    持续集成的重点是将各个开发人员的工作集合到一个代码仓库中。通常,每天都要进行几次,主要目的是尽早发现集成错误,使团队更加紧密结合,更好地协作。

    持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化,以便任何时刻能够安全地完成代码发布(理想情况下)。

    持续部署是一种更高程度的自动化,无论何时对代码进行重大更改,都会自动进行构建/部署。

持续集成的好处是什么?

持续集成可以使问题尽早暴露,从而也降低了解决问题的难度,正如老马所说,持续集成无法消除bug,但却能大大降低修复的难度和时间。

持续交付的好处是什么?

持续交付的好处在于快速获取用户反馈;适应市场变化和商业策略的变化。开发团队保证每次提交的修改都是可上线的修改,那么决定何时上线,上线哪部分功能则完全由产品业务团队决定。

虽然持续交付有显著的优点,但也有不成立的时候,比如对于嵌入式系统的开发,往往需要软硬件的配合。

持续部署的好处是什么?

持续部署的目标是通过减少批量工作的大小,并加快团队工作的节奏,帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态, 让团队更容易去创新、试验,并达到可持续的生产率

市面上的CI有很多,如果在github上搜一下ci工具,也会搜到很多,比如:

  1. Travis CI

  2. Circle CI

  3. Jenkins

  4. AppVeyor

  5. CodeShip

  6. Drone

  7. Semaphore CI

  8. Buildkite

  9. Wercker

  10. TeamCity

这里只介绍Gitlab-CI

pipeline(管道、流水线)

    一次 Pipeline 其实相当于一次构建任务,里面可以包含多个流程(Stage),比如自动构建、自动进行单元测试、自动进行代码检查等流程 ;

    任何提交或者 Merge Request 的合并都可以触发 Pipeline ;

Stage(构建阶段)

    Stage表示构建阶段,就是上面提到的流程 ;

    可以在一次 Pipeline中定义多个 Stage;

    Stage有如下特点 :

        所有 stages 会按照顺序运行,即当一个 stage 完成后,下一个 Stage才会开始

        只有当所有 Stage 成功完成后,该构建任务 Pipeline 才算成功

        如果任何一个 Stage失败,那么后面的 Stage 不会执行,该构建任务 (Pipeline) 失败

阶段是对批量的作业的一个逻辑上的划分,每个 pipeline都必须包含至少一个 Stage。多个 Stage是按照顺序执行的,如果其中任何一个 Stage失败,则后续的 Stage不会被执行,整个 CI 过程被认为失败。

Jobs(任务)

    job表示构建工作,表示某个stage里面执行的工作 ;

    一个stage里面可以定义多个job ;

    jobs有如下特点 :

        相同 stage 中的jobs 会并行执行

        相同 stage 中的 jobs 都执行成功时,该 stage 才会成功

        如果任何一个job 失败,那么该 stage 失败,即该构建任务 (Pipeline) 失败

举一个例子,比如下面这个图:

image.png

这里的四个Statge(阶段): Verify、Build、Dockerpush、Deploy四个,这四个阶段组成一条Pipeline

每个阶段都有一个job,所以总共四个job,也就是unit-testjava-packagedocker-pushservice-1这四个,当然,每个stage可以由多个job组成

Job 的执行过程中往往会产生一些数据,默认情况下 GitLab Runner 会保存 Job 生成的这些数据,然后在下一个 Job 执行之前(甚至不局限于当次 CI/CD)将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上,它也能看到彼此生成的数据。

.gitlab-ci.yml中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

关于.gitlab-ci.yml、before_script、after_script是什么,先别急,在后面有介绍

在了解了 Job 配置的 script、before_script、after_script 和 cache 以后,可以将整个 Job 的执行流程用一张图概括:

image.png


所以了解了Pipeline、Stage、Jobs后,还有一个很重要的东西,就是Runner

Runner

Runner就像一个个的工人,而Gitlab-CI就是这些工人的一个管理中心,所有工人都要在Gitlab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,Gitlab-CI就会通知相应的工人执行软件集成脚本。如下图所示:

image.png

gitlab里面的runner叫Gitlab-Runner,Gitlab-Runner是配合Gitlab-CI进行使用的。一般地,Gitlab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知Gitlab-CI。这时Gitlab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本(也就是在Job执行流程那个图中所示的第三步:script),所以,Gitlab-Runner就是一个用来执行软件集成脚本script的东西。

Runner类型

Gitlab-Runner可以分类两种类型:Shared Runner(共享型)Specific Runner(指定型)

    Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。

    Specific Runner:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

关于Gitlab-runner的安装,会以单独一个文章进行介绍,注册runner会对应一个tag,记住这个tag;

gitlab docker runner 安装参考https://docs.gitlab.com/runner/install/docker.html

本文测试用的命令如下:

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

runner安装完成后,还要注册runner,参考:https://docs.gitlab.com/runner/register/index.html#docker

本文测试用的命令如下:

docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
#输入 GitLab instance URL
#输入 token  可以在gitlab => Admin Area => Runners => Register an instance  runner 里面找到
#后面输入项不是很重要,可以参考上面的链接文档填写

.gitlab-ci.yml简介

.gitlab-ci.yml 文件被用来管理项目的 runner 任务,Gitlab CI通过.gitlab-ci.yml文件管理配置job,该文件定义了statge顺序、job应该如何触发和工作、执行什么脚本、如何构建pipeline等流程

该文件存放于仓库的根目录, 默认名为.gitlab-ci.yml

我们先看一个简单的例子:.gitlab-ci.yml

## 定义pipeline流程:verify->build->dockerpush->deploy

stages:
  - verify
  - build
  - dockerpush
  - deploy
  
#单元测试
unit-test:
  stage: verify # 属于哪个流程
  tags:
    - test-cicd # runner的tag名称,在哪个runner上面执行,在注册runner可以自定义
  only:
    - master    #只有master分支提交代码才会执行这个任务
  script:
    - echo unit-test # 执行脚本
  
#java编译
java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build#push镜像docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push

#deploy
service-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy

该配置对应下面的pipeline,test-cicd是一个Specific Runner,执行脚本的类型是shell

image.png

所以,以unit-test这个job为例,点击该任务可以进入到log界面查看整个log执行流程

image.png

image.png

剩下的job的执行日志都大部分如此,就不一一列举了

几个重要的关键字解析

关于gitlab-ci.yml,里面有很多关键字配置,下面我主要列举一些比较常用的关键字

before_script和after_script

随着项目越来越大,Job 越来越多,Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。

before_script 和 script 在一个上下文中是串行执行的,after_script 是独立执行的。所以根据执行器(在runner注册的时候,可以选择执行器,docker,shell 等)的不同,工作树之外的变化可能不可见,例如,在before_script中执行软件的安装。

你可以在任务中定义 before_scriptafter_script,也可以将其定义为顶级元素,定义为顶级元素将为每一个任务都执行相应阶段的脚本或命令。

stages

stages的允许定义多个,灵活的场景阶段的pipline。定义的元素的顺序决定了任务执行的顺序。例如:

## 定义pipeline流程:verify->build->dockerpush->deploystages:
  - verify
  - build
  - dockerpush
  - deploy

    build场景的任务将被并行执行。test、deploy 同理

    build 任务成功后,test 执行。test 成功后,deploy 执行

    所有的都成功了,提交将会标记为成功

    任何一步任务失败了,提交标记为失败并之后的场景,任务都不回执行。

tags

tags可以从允许运行此项目的所有Runners中选择特定的Runners来执行jobs。

在注册Runner的过程中,我们可以设置Runner的标签,tags可通过tags来指定特殊的Runners来运行jobs:

#单元测试unit-test:
  stage: verify # 属于哪个流程
  tags:
    - test-cicd # 在哪个runner上面执行,在注册runner可以自定义
    

有时你创建了一个pipeline但是执行会报错如下

 This job is stuck because the project doesn't have any runners online assigned to it. Go to projec

主要原因是:因为runner有标签,但job没有,只需要设置runner可以运行无标签的job就可以了,管理员进入 Runners,勾选:Run untagged jobs      即可

image.png


参考:https://stackoverflow.com/questions/53370840/this-job-is-stuck-because-the-project-doesnt-have-any-runners-online-assigned


script

script是一段由Runner执行的shell脚本,可以执行多个,例如:

job:
    script: mvn clean test

这个参数也可以使用数组包含好几条命令

job:
    script:
        - pwd
        - mvn clean test

only and except

only和except两个参数说明了job什么时候将会被创建:

    only定义了job需要执行的所在分支或者标签

    except定义了job不会执行的所在分支或者标签

以下是这两个参数的几条用法规则:

    only和except如果都存在在一个job声明中,则所需引用将会被only和except所定义的分支过滤.

    only和except允许使用正则

    onlyexcept可同时使用。如果onlyexcept在一个job配置中同时存在,则以only为准,跳过except(从下面示例中得出)。

    onlyexcept允许使用特殊的关键字:branchestagstriggers

    onlyexcept允许使用指定仓库地址但不是forks的仓库(查看示例3)。

例子解析:

1.job将会只在issue-开头的refs下执行,反之则其他所有分支被跳过:

job:
    # use regexp
    only:
        - /^issue-.*$/
    # use special keyword
    except:
        - branches

2.job只会在打了tag的分支,或者被api所触发,或者每日构建任务上运行

job:
    # use special keywords
    only:
        - tags    # tag分支 commit之后触发
        - triggers # API 触发
        - schedules # 每日构建触发

3.job将只有master分支提交代码才会执行这个任务。

job:
    only:
        - master
   
        
job:
    only:
        - branches@gitlab-org/gitlab-ce
    except:
        - master@gitlab-org/gitlab-ce

when

when可以设置以下值:

  1. on_success - 只有前面stages的所有工作成功时才执行。 这是默认值。

  2. on_failure - 当前面stages中任意一个jobs失败后执行。

  3. always - 无论前面stages中jobs状态如何都执行。

  4. manual - 手动执行(GitLab8.10增加)。

stages:- build- cleanup_build- test- deploy- cleanup
 build_job:
  stage: build
  script:
  - make build
 cleanup_build_job:
  stage: cleanup_build
  script:
  - cleanup build when failed
  when: on_failure
 test_job:
  stage: test
  script:
  - make test
 deploy_job:
  stage: deploy
  script:
  - make deploy
  when: manual
 cleanup_job:
  stage: cleanup
  script:
  - cleanup after jobs
  when: always

脚本说明:

    只有当build_job失败的时候才会执行`cleanup_build_job 。

    不管前一个job执行失败还是成功都会执行`cleanup_job 。

    可以从GitLab界面中手动执行deploy_jobs。

manual:

    在GitLab的用户界面中显示该作业的“播放”按钮

    意味着deploy_job仅在单击“播放”按钮时才会触发job。

修改上面那个例子

stages:
  - verify
  - build
  - dockerpush
  - deploy
  - cleanupbefore_script:
  - pwdafter_script:
  - echo after_script#单元测试unit-test:
  stage: verify
  tags:
    - test-cicd
  script:
    - echo unit-test#java编译java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build#push镜像docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push#deployservice-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy
  when: manual # 手动触发job,只有点击按钮才会触发cleanup_job:
  stage: cleanup
  script:
    - echo clean up
  when: always # 前面的job成功与否,都会执行该job

pipeline如下:

image.png

allow_failure

when一起控制job执行与否的配置还有一个就是allow_failure

allow_failure可以用于当你想设置一个job失败的之后并不影响后续的CI组件的时候。失败的jobs不会影响到commit状态。

下面的这个例子中,java-packagejava-package2将会并列进行,如果java-package2失败了,它也不会影响进行中的下一个stage,因为这里有设置了allow_failure: true。

stages:
  - verify
  - build
  - dockerpush
  - deploy
  - cleanupbefore_script:
  - pwdafter_script:
  - echo after_script#单元测试unit-test:
  stage: verify
  tags:
    - test-cicd
  script:
    - echo unit-test#java编译java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build#java编译java-package2:
  stage: build
  tags:
    - test-cicd
  script:
    - execute_script_that_will_fail # 该shell会导致job执行失败
  allow_failure: true # 不影响后面的任务进行#push镜像docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push#deployservice-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy
  when: manualcleanup_job:
  stage: cleanup
  tags:
    - test-cicd
  script:
    - echo clean up
  when: always

java-package2会执行错误


variables

GitLab CI允许你为.gitlab-ci.yml增加变量,该变量将会被设置入任务环境。通过两种方式可以引用

  • 美元符+大括号引用:${}

  • 美元符:$

示例如下:

variables:
  SOFT_VERSION: '1.0'
  TAG_NAME: 'xxx'#构建镜像docker-build:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - docker build -t $TAG_NAME:${SOFT_VERSION}

如果有些值不想在配置文件中显示,比如密码什么的,可以在代码仓库中setting->CICD->Variables 自定义变量,跟在.gitlab-ci.yml配置变量效果是一样的

image.png

variables的保留字

gitlab-ci有一些预定义变量,这些变量大部分以CI开头

预定义变量:

VariableGitLabRunnerDescription
CIall0.4标识该job是在CI环境中执行
CI_COMMIT_REF_NAME9.0all用于构建项目的分支或tag名称
CI_COMMIT_REF_SLUG9.0all先将$CI_COMMIT_REF_NAME的值转换成小写,最大不能超过63个字节,然后把除了0-9a-z的其他字符转换成-。在URLs和域名名称中使用。
CI_COMMIT_SHA9.0allcommit的版本号
CI_COMMIT_TAG9.00.5commit的tag名称。只有创建了tags才会出现。
CI_DEBUG_TRACE9.01.7debug tracing开启时才生效
CI_ENVIRONMENT_NAME8.15alljob的环境名称
CI_ENVIRONMENT_SLUG8.15all环境名称的简化版本,适用于DNS,URLs,Kubernetes labels等
CI_JOB_ID9.0allGItLab CI内部调用job的一个唯一ID
CI_JOB_MANUAL8.12all表示job启用的标识
CI_JOB_NAME9.00.5.gitlab-ci.yml中定义的job的名称
CI_JOB_STAGE9.00.5.gitlab-ci.yml中定义的stage的名称
CI_JOB_TOKEN9.01.2用于同GitLab容器仓库验证的token
CI_REPOSITORY_URL9.0allgit仓库地址,用于克隆
CI_RUNNER_DESCRIPTION8.100.5GitLab中存储的Runner描述
CI_RUNNER_ID8.100.5Runner所使用的唯一ID
CI_RUNNER_TAGS8.100.5Runner定义的tags
CI_PIPELINE_ID8.100.5GitLab CI 在内部使用的当前pipeline的唯一ID
CI_PIPELINE_TRIGGEREDallall用于指示该job被触发的标识
CI_PROJECT_DIRallall仓库克隆的完整地址和job允许的完整地址
CI_PROJECT_IDallallGitLab CI在内部使用的当前项目的唯一ID
CI_PROJECT_NAME8.100.5当前正在构建的项目名称(事实上是项目文件夹名称)
CI_PROJECT_NAMESPACE8.100.5当前正在构建的项目命名空间(用户名或者是组名称)
CI_PROJECT_PATH8.100.5命名空间加项目名称
CI_PROJECT_PATH_SLUG9.3all$CI_PROJECT_PATH小写字母、除了0-9a-z的其他字母都替换成-。用于地址和域名名称。
CI_PROJECT_URL8.100.5项目的访问地址(http形式)
CI_REGISTRY8.100.5如果启用了Container Registry,则返回GitLab的Container Registry的地址
CI_REGISTRY_IMAGE8.100.5如果为项目启用了Container Registry,它将返回与特定项目相关联的注册表的地址
CI_REGISTRY_PASSWORD9.0all用于push containers到GitLab的Container Registry的密码
CI_REGISTRY_USER9.0all用于push containers到GItLab的Container Registry的用户名
CI_SERVERallall标记该job是在CI环境中执行
CI_SERVER_NAMEallall用于协调job的CI服务器名称
CI_SERVER_REVISIONallall用于调度job的GitLab修订版
CI_SERVER_VERSIONallall用于调度job的GItLab版本
ARTIFACT_DOWNLOAD_ATTEMPTS8.151.9尝试运行下载artifacts的job的次数
GET_SOURCES_ATTEMPTS8.151.9尝试运行获取源的job次数
GITLAB_CIallall用于指示该job是在GItLab CI环境中运行
GITLAB_USER_ID8.12all开启该job的用户ID
GITLAB_USER_EMAIL8.12all开启该job的用户邮箱
RESTORE_CACHE_ATTEMPTS8.151.9尝试运行存储缓存的job的次数

更多配置,可以参考官方参考文档:https://docs.gitlab.com/ee/ci/yaml/


本文》有 0 条评论

留下一个回复