DevOps之Gitlab-CICD实践篇

Posted by 刘勇 on 2020-02-03

DevOps之Gitlab-CICD实践篇

背景

  • 随着公司项目使用gitlab越来越多,业务发布的次数越来越频繁,对于发布效率提出了更高的要求。从2012开始,Gitlab官方开始集成了Continuous Integration (CI) & Continuous Delivery (CD)功能。本文主要针对该功能的实践做一个分享。

基础介绍

  • GitLab CI/CD可以做很多事情,下图展现了GitLab CI/CD工作流程中整个的服务能力,而无需使用外部工具来交付软件。

    image

  • 在介绍实践方案之前,我们先简单的了解一下和Continuous Integration (CI) & Continuous Delivery (CD)功能有关的相关知识。

术语介绍

术语名 含义
commit 就是一次git的提交,默认提交时会触发pipeline。
Job Runner execute的内容
pipeline 不同stage下的不同job组成的集合,即一次流水线。
Runner 单独执行每个Job的agent或者服务器,一个job最终会分配到某个Runner执行。
Stage 一个阶段stage,里面可能包含很多个job,同一个阶段里面的job会并行执行。

gitlab-pipeline介绍

  • 一次pipeline其实相当于一次任务构建,里面可以包含多个流程,如安装依赖、运行测试、编译代码、部署测试服务器、部署生产服务器等。 任何提交或者Merge Request的合并都可以触发pipeline,触发pipeline创建的方式主要有如下。如需详细了解,请查阅官网

    image

gitlab-stage介绍

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

    • 所有Stage会按照Stages参数里定义的顺序串行执行,即当一个Stage完成后,才会执行下一个Stage
    • 默认情况下只有当所有Stage成功后,最终的pipeline构建任务才会成功。
    • 默认情况下任何一个Stage失败,那么后面的Stage不会执行,该构建任务最终会失败。
  • pipelinestage的关系简单理解为下图。

    image

gitlab-job介绍

  • job表示构建工作,即某个Stage里面执行的工作内容。我们可以在同一个Stage里面定义多个Job,这些Jobs会有以下特点:

    • 相同Stage中的Job会并行执行。
    • 相同Stage中的Job都执行成功时,该Stage才会成功。
  • 如果任何一个Job失败,那么该Stage失败,即该构建任务失败。
  • stagejobs的关系简单理解为下图。

    image

  • 我们以某个pipeline为例解释pipelinestagejob的含义,具体请看下图。

    image

gitlab-ci-yaml介绍

  • pipeline执行的内容使用yaml语言进行描述,默认文件名为.gitlab-ci.yml,该文件默认放在仓库的根目录下即可生效。关于yaml语言的使用可点击这里。下表对gitlab 11.11.4版本中.gitlab-ci.yml文件里常用的关键字参数进行简单说明。如需深入了解可查阅官方文档
关键字 说明
script runner中执行的shell语句内容
image docker镜像,runner执行时会使用该镜像做为基础环境,执行对应job中的内容。
services docker中的服务,runner执行时会关联该服务的镜像做为基础环境,执行对应job中的内容。
before_script 执行job之前执行的一组命令。
after_script 执行job后执行的一组命令。
stages 定义一个pipeline中所有阶段的执行顺序。
stage 定义job归属哪个stage,默认为test。
only 限制何时创建job,即限制触发job创建的条件,可用only:refs、only:kubernetes、only:variables和only:changes进行限制。
except 限制何时不创建job,即限制不会触发job创建的条件。和only关键字的作用相反。 可用except:refs、except:kubernetes、except:variables和except:changes进行限制。
tags 用于选择哪个Runner来执行job的标签列表,这个标签必须和注册runner时定义的tags一致。
allow_failure 允许失败的job可以正常提交状态。有时候一个完整的pipeline会有多个stage,有时候为了不阻塞该stage后面的stage执行,会设置该job允许失败。
when 限制什么时候执行job,注意它不是限制创建job的条件,限制创建job的条件参数是only或者except。 有时候某个job的执行你想手工点击确认才执行,可用该参数。
environment 用于定义作业部署到特定环境,比如部署到production正式环境或者testing测试环境。
cache 后续运行时应缓存的文件列表。主要用于存储project的依赖项,它可以在同个project中的不同pipelines或者jobs中共享使用。比如避免重复下载npm packages, Go vendor packages等,减少pipeline的执行时间。
artifacts 成功附加到job的文件和目录列表,主要用于同个pipeline中不同stages之间进行加速,比如后一个stage需要用到上一个stage中生成的image。它存储的内容不能在不同的pipeline中共享使用。关于cache和artifices的详细区别可参考官网说明
dependencies 一个作业(job)所依赖的其他作业,以便您可以在它们之间传递artifacts。
coverage 对给定作业(job)的代码覆盖率进行设置。
retry 发生故障时可以自动重试jobs的次数。
trigger 定义下游管道触发器,比如在该stage中触发其他项目的pipeline。注意和triggers进行区分。
include 允许此作业(job)包括的外部YAML文件列表,可用include:local、include:file,include:template和include:remote关键字参数。类似nginx配置文件的include设置。
extends 此作业(job)将要继承的配置条目。
pages 上传作业(job)结果以用于GitLab的pages静态页面。
variables 定义作业(job)级别上的全局变量。

gitlab-runner介绍

  • .gitlab-ci.yml文件里的内容由谁来执行呢,答案就是gitlab-runnter,一般gitlab-runner会和gitlab所在服务器进行隔离,因为一个任务的构建,往往会执行编译、测试、发布的过程,这个过程会大量消耗系统资源。gitlab-runner几乎可以安装在任何机器上。下面介绍gitlab-runner的官方仓库源安装方式。关于gitlab-runner的其他安装方式请查阅官方文档

  • 添加仓库源

1
2
3
4
5
# For Debian/Ubuntu/Mint
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# For RHEL/CentOS/Fedora
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
  • 安装指定的gitlab-runner版本,比如这里安装11.11.4版本。
1
2
3
4
5
# for DEB based systems
sudo apt-get install gitlab-runner=11.11.4

# for RPM based systems
sudo yum install gitlab-runner-11.11.4
  • 点击左侧栏Settings->CI/CD->Runners->Collapse获取runner的token,如下图。

    image

  • 注册gitlab-runner到gitlab实例。

    image

实践方案

  • 该实践方案主要介绍微服务项目使用gitlab自带的GitLab Continuous Integration (CI) & Continuous Delivery (CD)功能,在gitlab提供的runner里面进行打包、测试、发布。

持续集成CI

  • 持续集成主要是代码编译和打包的过程,一般最终会集成一个适合业务场景的系统层docker镜像。

容器镜像集成

  • 下面为集成系统层docker镜像Dockerfile的主要内容:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
FROM debian:stretch

# 准备软件包文件
ADD soft/ /data/soft/

# 安装基本软件
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -y vim htop wget dnsutils dmidecode ipmitool pciutils perl \
rsync screen less sysstat at stress tcpdump lsof curl telnet ntp rsyslog sudo locales logrotate cron supervisor \
numactl openssh-server-x509 openssh-client iptables gawk filebeat mongodb3.4.16 graphviz \
&& apt-get clean

# 安装开发环境
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& apt-get install -y python python-pip gcc g++ build-essential python-dev python-setuptools python-smbus \
build-essential libncursesw5-dev libgdbm-dev libc6-dev zlib1g-dev libsqlite3-dev tk-dev libssl-dev openssl \
libffi-dev cmake automake python-setuptools libtcmalloc-minimal4 sockstat strace gdb graphviz \
&& apt-get clean

# 安装python3.7
RUN cd /data/soft/ && tar xf /data/soft/Python-3.7.0.tgz && cd Python-3.7.0 && ./configure --enable-optimizations --with-ssl-default-suites=openssl --enable-shared \
&& make && make install && cp libpython3.7m.so.1.0 /lib64/ && ldconfig && rm -rf /data/soft

# 业务启动脚本
COPY entrypoint.sh /sbin/entrypoint.sh
ENTRYPOINT ["/bin/bash", "-x", "/sbin/entrypoint.sh"]
  • 那么怎么把docker镜像推送到docker仓库呢?可在.gitlab-ci.yml文件中进行描述,把build好的镜像推送到gitlab内置的registry中。关于gitlab内置的registry部署可参考官网说明。下面为打包并上传容器镜像stage的主要内容。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
build_push:
only:
refs:
- tags
variables:
- $CI_COMMIT_REF_NAME =~ /^rel_[0-9].*$/ # 规定必须通过打tag且名字为rel_xxx的格式才触发pipeline。
tags:
- docker
stage: ex_build
script:
# build docker image
- docker login $DOCKER_REGISTRY
- echo "$ docker pull $BUILD_IMAGE"
- docker pull $BUILD_IMAGE # 防止$BUILD_IMAGE更新后,runner会缓存,故在build之前先pull一次。
- echo "$ docker build -t $image"
- docker build --no-cache -t $image .
- echo "$ docker tag $image $latest"
- docker tag $image $latest

# push docker image
- echo "$ docker push $image"
- docker push $image
- echo "$ docker push $latest"
- docker push $latest
- docker logout $DOCKER_REGISTRY
when: manual # 手工确认
allow_failure: false
environment:
name: build
  • gitlab-runner中对应job的部分日志截图如下:

    image

持续交付CD

  • 持续交付或者持续发布的方式其实有很多种,理论上只要服务方提供了发布接口,你就可以封装在.gitlab-ci.yml文件里使用gitlab-runner调用api进行自动发布。下面主要介绍容器的发布方式。

发布容器

  • 发布容器时主要调用自建容器服务的发布接口,其中主要的stage内容如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
deployment_production:
only:
refs:
- tags
variables:
- $CI_COMMIT_REF_NAME =~ /^exrel_[0-9].*$/
tags:
- docker
stage: ex_deployment_production
script:
# 更新当前环境下指定渠道
- deploy_service ${CI_ENVIRONMENT_NAME} "$image" #image为持续集成build后push到registry的docker镜像。deploy_service是封装容器发布过程的函数。该函数主要是根据传入的image,请求k8s的kube接口进行微服务发布。
when: manual
environment:
name: production
  • gitlab-runner中发布game微服务的job日志截图如下。

    image

发布流程

  • 微服务的发布流程主要分2种类型:常规发布和热更发布。常规发布需要重建容器,热更发布无需重建容器。

常规发布

  • 下面为常规发布场景下整体的发布流程。

    image

热更发布

  • 核心思路是把需要热更的内容put到etcd集群,服务端集群自动获取内容进行热更,下面为热更发布场景下整体的发布流程。

image

效果展示

常规发布下的pipeline

image

热更发布下的pipeline

image

资料参考



支付宝打赏 微信打赏

赞赏一下