Skip to main content

Pywhio

官方 @ PywhiO. Python大数据, AI技术, 微服务, DRF+REACT前后端分离实践.

2 min read · February 29th 2020 (originally published at pywhio)

如何基于Gitlab对大数据项目持续集成

阅读:-


如何基于Gitlab对大数据项目持续集成

要想构建大数据项目,自动化的项目集成和部署是一个关键,在本文中将详细介绍如何利用组件Gitlab实现智能管理从代码到镜像的集成过程。

1 CI/CD概述

1.1 大数据与CI/CD

​ 传统的软件开发过程中,因为软件的规模比较小,所以并不需要集成的过程常常是依赖人工的半自动化方式,而到了大数据的阶段,一方面软件的规模比较大,需要依赖大量的支持分布式计算的组件,另外一方面软件的更新的需求非常频繁,如果是基于半自动化的方式实现软件集成,项目集成的人工成本将变得无法接受,所以在大数据处理的项目中需要重点解决微服务(micro service),服务调用(call stack),和持续集成(CI/CD).

​ 虽然CI/CD是一个相对比较经典的技术,但是在大数据的应用环境下,是一个至关重要的技术。这样可以保障我们对代码进行快速的迭代处理。

1.2 持续集成(CI)

持续集成用于将开发团队成员中的代码集成到公共仓库中。每当开发者进行类似于代码提交等操作的时候,便会执行安装依赖、编译代码、自动化测试等操作。

1582944329959

一个项目的持续集成工作如果采用纯手工操作通常会比较繁琐且容易出错,因而引入gitlab-ci来进行自动化的持续集成工作,每个开发者完成一部分的功能模块时便将其集成至主干之中,这样做能够更早地发现项目之中存在的一系列问题并加以解决,避免了以往在项目后期合并代码产生大量难以解决问题的情况。

1.3 CI/CD 工具选择

1582944360211

​ 图 1-1 基于GitLab的云计算环境

业界关于CI/CD的工具有很多选择,而在我们的大数据项目中,我们选择GitLab来实现相关的功能。 Gitlab是目前在云化环境中,广泛使用的一种CI/CD 的工具,举个例子来说在AWS上就有不少基于Gitlab构建的FaaS基础云化服务。Gitlab扮演了一个桥梁,实现了从源代码到云化服务的无缝转换。

使用Gitlab可以非常方便的实现代码的转换管理,主要具有以下5点优势。

1582944384292

GitLab为DevOps生命周期的所有阶段提供了完整的解决方案,在DevOps生命周期内,GitLab CI / CD跨越了验证(CI)和发布(CD)阶段。

主要的过程见下图:

1582944431777

持续集成(CI):构建,测试

持续交付部署(CD):发布

1.4 基本功能与组件概述

​ 接下来我们重点了解一下GitLab的基本功能和组件。

1582944450987

​ 图 1-2 GitLab的四大组件

从上图可见,主要有四大组件来实现自动加的CI,CD过程。

其中:

  1. 代码仓库:用于协作代码更新管理的git仓库。

  2. 自动化脚本:代码包中,定义自动化流程的脚本,默认命名为.gitlab-ci.yml。

  3. 自动化流程:.gitlab-ci.yml文件中,定义的要运行的命令。对于基于容器的微服务化的应用而言基本的自动化流程为:镜像构建->镜像上传->服务部署

4、执行环境:用于提供执行自动化脚本的环境,其中不同的Runner定义了不同的执行环境,而这些Runner运行在GitLab Runner服务之上。

在这四大组件中,执行环境是核心,他负责根据自动化脚本设定的运行逻辑,执行自动化流程。自动化流程负责将代码转换为镜像,将镜像上传到镜像仓库,将,将镜像仓库中的镜像部署到容器中。相关的概念见下图:

1582944514652

​ 图 1-3 Gitlab-runner的核心作用

从上图可见,GitLab将作为一个核心桥梁,实现将代码到容器应用的转换处理。由于大数据的组件往往需要部署到多台服务器的多个容器上,这个过程如果没有自动化的工具支撑,相关的工作量将大到难以估计。

1.5 GitLab中的代码对象穿越

代码仓库是Gitlab中的一个重要组件,下面我们来看看其中的流穿越的过程。

每发布一个版本, GitLab都会保存发布时版本信息。每个项目定义的自动化脚本位于当前项目根目录下。GitLab中.gitlab-ci.yml文件存放方式如下图:

1582944530861

​ 图1-3 自动化脚本的位置

​ Gitlab CE代码文件及操作记录全部存放在Gitlab CE安装机器上的文件目录中,如下图代码存放路径:

1582944547932

1582944560509

​ 图1-4 项目代码存放的路径

GitLab Runner的HOME目录中会clone一份项目代码做自动化操作,同样存储于文件目录中。整个流程文件穿越流程如右图所示,文件穿越说明如下:

  1. 本地通过gitpush上传代码到代码仓库。

  2. 代码仓库文件实际存储于GitLabCe所在机器的文件路径下。

  3. 触发CI/CD后GitLabRunner会跟更新代码到自己的文件路径下,根据这些代码文件进行自动化构建。

    1582944591528

​ 图1-5 将代码从GitlabCE 拷贝的Gitlab Runner

以上是相关的源代码的整个穿越过程。

1.6 组件安装

1.6.1 关键组件

1582944679500

​ 图 1-6 核心组件

从上图可见,相关的组件主要有两个:

1.Gitlab CE:代码管理工具;安装在容器中。

2.Gitlab Runner:自动化执行器;直接安装在宿主机中。

以上组件就是主要的组件,详细的部署方案见下图。

1582944728479

1.6.2 Gitlab ce

gitlab首先要确保有一台部署了GitLab且版本在8.0以上的服务器,在hbwy0002中以docker方式部署了gitlab-ce的服务

1582944748231

考虑到部署的方便性,GitLab CE可以考虑部署到容器中,这样管理会比较方便。

1.6.2.1 容器化部署

1582944766138

在相关的容器化部署的方案中核心有两个要点:

1.端口映射: 需要映射三个端口,分别支撑 Gitlab Shell; UI(http);UI(https)

2.关键数据持久化:数据,日志,配置文件,需要进行持久化管理。

1582944812819

1582944874625

1.6.3 Gitlab runner

gitlab-runner 它是一个用来执行集成脚本的执行器。比如说,当有人往仓库里push了代码,gitlab-ci就会找出和这个项目相关联的runner,并通知runner执行定义好的脚本。流程图如下:

1582944893856

​ 图 1-7 CI和runner的联动

这里Gitlab runner 需要直接安装到宿主机中。

1.6.3.1 安装

由于我们需要直接通过宿主机的shell环境进行自动化,所以选择通过rpm安装GitLab Runner,若采用docker的方式则shell环境为docker内的shell环境,无法使用宿主机环境。

  1. rpm -ivh gitlab-runner-11.8.0-1.x86_64

  2. systemctl start gitlab-runner

  3. systemctl enable gitlab-runner

由于Gitlab Runner组件默认运行时是以gitlab-runner用户运行,所以在执行系统docker命令时,会出现permission问题。所以需要通过以下方式赋予gitlab-runner用户docker命令权限:

  1. sudo usermod –aG docker gitlab-runner

相关的配置操作提炼见下图:

1582944909260

1.6.3.2 注册

在成功部署GitLab Runner服务后, 需要为项目注册Runner,首先打开web界面:点击到项目中,点击设置->CI/CD->Runner看到如下界面

1582944951857

在服务器终端执行如下命令进行注册

执行:# gitlab-runner register

  1. Runtime platform arch=amd64 os=linux pid=11722 revision=4745a6f3 version=11.8.0

  2. Running in system-mode.

  3. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

  4. http://10.25.226.2:8888/ # web界面中对应的URL

  5. Please enter the gitlab-ci token for this runner:

  6. uRK3f4DfuiVgcXz1UxoD # web界面中对应的令牌

  7. Please enter the gitlab-ci description for this runner:

  8. [hbwy0001]: hbwy # 给runner起一个名字

  9. Please enter the gitlab-ci tags for this runner (comma separated):

  10. dev # 给runner添加一个标签

  11. Registering runner… succeeded runner=uRK3f4Df

  12. Please enter the executor: kubernetes, docker, parallels, virtualbox, docker+machine, docker-ssh+machine, docker-ssh, shell, ssh:

  13. shell # runner**执行的方式**

  14. Runner registered successfully. Feel free to start it, but if it’s running already the config should be automatically reloaded!

    1582945143805

    至此我们部署了gitlab-ci/cd的所需环境,并为项目添加了runner。接下来,就需要添加自动化流程定义脚本:.gitlab-ci.yml

源代码的注册机制是通过git的方式,git是一个分布式的代码版本控制软件,OG4项目中采用了gitlab作为git代码管理工具的服务器,用户只需通过git命令就可将本地的代码推送到git服务器中。

1.6.3.3 互操作

从上面的配置过程中,我们可以发现gitlab-ce中会通过一个gitlab-ci coordinator URL地址来识别相关的runner。

1582945225041

注册成功之后这里runner就是与gitlab-ce服务已经建立过连接,为了管理这种连接关系,gitlab-ce会管理如下信息结构:

1.名字: runner的名字。 Hbwy

2.标签:dev

3.内部id:标示runner的id uRK3f4Df

4.执行器:shell

Shell脚本语言的优势在于处理偏操作系统底层的业务,例如:Linux系统内部的很多应用(有的是应用的一部分)都是使用Shell脚本开发的,因为有1000多个Linux系统命令为它做支撑,特别是Linux正则表达式及三剑客grep、sed、awk等命令。

我们在runner注册的时候,就使用的是shell命令:

执行:# gitlab-runner register

1.7 GitLab CI Pipeline相关的配置

  1. 简单介绍一下pipeline、stage、job的概念。

job:最小的任务单元,通常只做一件事情,比如测试、编译。

stage:代表一个阶段,阶段中可以包含多个jobs,一旦有一个job出现错误,那么下一个stage将不再执行,只有全部jobs执行成功才会开始执行下一个stage。

pipeline:翻译过来是管道,你也可以把它当成一整个流水线,里面有多个stage有顺序地排序在一起。

整体结构可以看下图:

1582945372156

图中的便是一个完整的pipeline,其中Update、Test、Build分别代表了三个阶段。每个阶段中都有自己的job,比如Test阶段中就有test-job1和test-job2两个job。

  1. GitLab CI/CD Pipelines定义在YAML文件中,此文件默认命名为.gitlab-ci.yml。.gitlab-ci.yml文件有特定的编写语法,语义,提供了自一些常见标签和环境变量。

  2. 常用标签

标签定义范畴
script需要执行的Shell命令.
before_scriptJob执行之前需要执行的命令
after_scriptJob执行完成之后需要执行的命令
stages定义pipline中的stages
stage指定job所属的stage
only指定job执行的分支
except派出job执行的分支

标签说明:

• before_script/after_script:运行在自动化流程前/后,常用于软件安装/清理 工作。

• stages定义顺序执行的阶段,一个stage可以包含多个job,多个job在一个stage周期内是并行执行的。

• Job中定义子标签script, script定义了多条顺序执行的Sehll命令,能够完全达到手动执行Shell命令的效果。

• Job中定义了子标签only,except用于限定只有特定分支更新才会执行此job。

• when定义了用于在发生故障运行的job,比如只有当前一个阶段的所有工作都成功时才执行当前job: on_success,或者忽略其它job执行情况allow_failure, 还可以指定整个流程的触发条件为manual,这样代码提交或更新不会触发自动化,只有手动通过Web界面点击运行才可以触发流程。

  1. 变量Variables

GitLab Runner提供了环境变量功能,用于增加自动化脚本的动态性。 例如:需要将自动化流程中构建的docker image版本与,代码提交的tag一致。使用$CI_COMMIT_TAG变量,能够标识当前git提交的tag号。

1.7.1 原型实验实例

在这个方案中,我们使用harbor作为容器镜像的仓库

  1. OG4项目的.gitlab-ci.yml如下所示:

    1582945424191

对应stage

a) build:登录registry,根据最新代码进行镜像构建/上传。

b) deploy:stack重新部署。

c) check:检查stack情况,退出登录。

  1. 流程触发

git tag -a ‘v0.3’ -m ‘new release’ 创建备注为新版本、版本为v0.3的标签

git push origin v0.3 提交发送v0.3版本到仓库

  1. 结果查看

通过gitlab-ce的web界面可以看到自动化执行情况,点击每一个stage可以看到terminal执行命令及执行情况

(1) 重构镜像执行情况:

1582945460781

1582945474665

(2)上传镜像:

1582945486874

(3)退出登录:

1582945495676

(4) 通过harbor查看镜像情况

1582945508938

  1. pipeline运行状况

    1582945523150

可以看到,通过GitLab CI/CD能够代替在代码更新后, 手动进行持续集成的流程。

1.7.2 正式部署方案

1582945765406

详细的执行情况见下图:

1582945780216

经过详细运行以后,整个的pipeline说明如下:

1582945801990

1.7.3 CI/CD总结

1582945816601

从上图可见,gitlab-runner负责将代码转换为镜像,这个转换过程是发生在运行runner的host上。 转换成功以后会发送到相关的镜像仓库Docker Registry , 在本方案中是harbor。

1582945841967

分享到微博

Previous

Weibologin模块上线
Starter
MicroServ
Tutorials
Blog