什么是devops,基于Gitlab从零开始搭建自己的持续集成流水线(Pipeline)

一、gitlab 实现的 auto devops

1. DevOps中的一些概念与原则

(1) 什么是持续集成

持续集成(Continuous integration,简称CI)指的是,频繁地(一天多次)将代码集成到主干。

它的好处主要有两个。

  • 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  • 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

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

(2) 持续交付、持续部署的概念

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

(3) 持续集成系统的组成

  • 一个自动构建过程,包括自动编译、分发、部署和测试等。
  • 一个代码存储库,即需要版本控制软件来保障代码的可维护性,同时作为构建过程的素材库。
  • 一个持续集成服务器。

(4) 为什么要引入auto devops

  1. 部署的环境问题 ;

  2. Dev, QA, Ops的进度问题 ;

  3. 持续集成的好处 :

    • 编译问题与Bug可以在push或合并之后第一时间发现并解决;

    • Devops使持续交付成为可能,使产品随时可交。过去公司做测试可能需要十几、二十几个组件,集成一次往往要一两个小时,费力费时,而且复杂容易出错,而一旦配置出错的话耗时会更久。因此,一次集成测试一周才会做一次,测出Bug要到下一周才能更新,再做测试,这个周期会非常漫长。而持续集成的意义就在于减少风险,和重复的过程,最终提高工作效率。

  4. 关于devops的其他一些介绍 http://www.gzhphb.com/article/20/201544.html

2. GitLab CI中的一些概念

(1) Pipeline

  • 一次 Pipeline 其实相当于一次构建任务,里面可以包含多个流程,比如自动构建、自动进行单元测试、自动进行代码检查等流程 ;
  • 任何提交或者 Merge Request 的合并都可以触发 Pipeline ;

(2) stages

  • stages 表示构建阶段,就是上面提到的流程 ;
  • 可以在一次 Pipeline 中定义多个 stage ;
  • stages有如下特点 :
    • 所有 stages 会按照顺序运行,即当一个 stage 完成后,下一个 stage 才会开始
    • 只有当所有 stages 成功完成后,该构建任务 (Pipeline) 才算成功
    • 如果任何一个 stage 失败,那么后面的 stages 不会执行,该构建任务 (Pipeline) 失败

(3) jobs

  • job表示构建工作,表示某个stage里面执行的工作 ;
  • 一个stage里面可以定义多个job ;
  • jobs有如下特点 :
    • 相同 stage 中的jobs 会并行执行
    • 相同 stage 中的 jobs 都执行成功时,该 stage 才会成功
    • 如果任何一个job 失败,那么该 stage 失败,即该构建任务 (Pipeline) 失败

(4) gitlab runner

  • 执行构建任务的一个服务 ;
  • 把构建任务放到runner里面而不是在CI里面做是不想把”构建”这个重任(通常较大的工程构建都比较小号资源) 放到gitlab上而影响gitlab性能。通过把gitlab runner安装到不同机器上,让这台单独的机器来执行构建任务
  • 关于 gitlab server 与 gitlab runner 之间的关系以及信息交互可以通过下面这个链接看到 : https://xiaozhuanlan.com/topic/3529176084

二、使用 Gitlab 实现一个简单的流水线 (Pipeline)

1. 准备工作

(1) 从docker hub下载gitlab/gitlab-runner镜像

root# docker pull gitlab/gitlab-runner

这里写图片描述

(2) 准备一个用来完成stage的镜像

多个步骤使用同一个镜像来创建容器,也可以根据不同stage准备多个特定的镜像。

这里只是介绍一个使用docker来完成多个简单stagedemo,就拿一个最简单的能完成任务的镜像,一个简单的Dockerfile如下:

FROM docker.io/ubuntu
MAINTAINER user.name user.email

# install tools
USER root
RUN apt-get update
RUN apt-get install -y git cmake g++ gcovr

ENTERPOINT /bin/bash

这篇文章介绍的流水线有两个步骤,第一个步骤完成构建,第二个步骤完成单元测试以及单元测试覆盖率的计算。其实两个stage完全可以放到一个容器中来进行。
为模拟真实的流水线,每个环节做特定的工作。这里假设两个stage完全不同,需要使用不同的容器来完成。

下面是我们根据需要创建的两个不同镜像 :

具体docker的基本操作请自行Google,也可以参考《每天五分钟玩转Docker容器技术》这本书。

这里写图片描述

(3) 安装docker-compose

root# sudo curl -L https://github.com/docker/compose/releases/download/1.17.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

如果上面的源下不了,使用下面的方式 :

yum install -y epel-release
yum install -y python-pip
pip install --upgrade pip
pip install docker-compose

(4) 编写docker-compose.yml

一个简单的docker-compose.yml文件:

runner: 
  image: gitlab/gitlab-runner
  restart: always
  container_name: gitlab-runner
  volumes: 
    - /var/run/docker.sock:/var/run/docker.sock
    - /srv/gitlab-runner/config:/etc/gitlab-runner

解释一下:

  • /var/run/docker.sock:Docker 守护进程 (Docker daemon) 默认监听的 Unix 域套接字(Unix domain socket),容器中的进程可以通过它与 Docker 守护进程进行通信。
  • /srv/gitlab-runner/config: runner的配置文件,可以通过修改这个目录下的config.toml文件来修改runner配置。host主机中的/srv/gitlab-runner/config/config.toml这个文件被映射到runner中的/etc/gitlab-runner/config.toml文件中,主机上的/srv/gitlab-runner/config/config.toml的修改,会导致runner内部的/etc/gitlab-runner/config.toml做同步修改。
  • 下面通过docker-compose启动的容器就是流水线的runner,流水线在这个runner里面触发并开始执行,之后runner会接着创建另外的docker容器,来完成流水线中的构建和单元测试任务。-v 表示挂载,runner通过与主机通信,看似在runner中创建容器,其实是在host主机中创建的. 这个也比较好验证,因为runner中并没有并没有安装docker,如何启动容器;另外流水线完成后在host主机中通过docker ps -a可以看到中间生成的临时容器。

1. 使用docker-compose启动容器

root# docker-compose up -d

这里写图片描述

2. 上面使用docker-compose的方式启动容器,完全可以换成使用docker run来启动容器

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

(5) 在工程中开启 auto devops 选项

项目设置 –> CI/CD –> General pipelines settings –> Enable Auto DevOps

这里写图片描述

使用一个具体的 runner

如果这个项目打开了shared runner,里面可能有多个 runner,我们不想用别人的 runner,只想用自己刚注册的 runner,可以把 shared runner 选项关闭,或者也可以在.gitlab-ci.yml里面的 stage 里面,使用 tags 关键字指定特定的 runner 。关闭共享 runner 如下图:

这里写图片描述

(6) 编写 .gitlab-ci.yml 文件

.gitlab-ci.yml 这个文件以 yaml 的格式描述了整个流水线有哪些流程,应该做哪些事。具体语法就不说了,可以Google下。编写完成以后,这个文件需要放到仓库的根目录,受Git版本控制。yaml 格式在编写时容易出错,可以在 “Gitlab 侧边栏 CI/CD –> Pipelines”页面,右上角有个 “CI Lint” 按钮,进去后输入编写的 .gitlab-ci.yml 文件内容,点击左下角 “Validate” 按钮。

下面是工程中需要用到的 .gitlab-ci.yml:

这里写图片描述

2. 注册runner

root# docker exec -it gitlab-runner gitlab-runner register

这里写图片描述

3. runner的配置文件

配置文件路径: /srv/gitlab-runner/config/config.toml

concurrent = 1
check_interval = 0

[[runners]]
  name = "docker_runner"
  url = "https://gitlab.com/"
  token = "xxxxxxxxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    pull_policy = "never"
  [runners.cache]
    Insecure = false

正常情况下,注册完毕后是没有 pull_policy = "never" 这一行的,可以先手动加上。这放到下面的”docker镜像的拉取策略“来说。

4. 一次Pipeline的体验

提交代码

这里写图片描述

流水线在执行的时候

这里写图片描述

流水线运行完毕

这里写图片描述

流水线总体概况

这里写图片描述

5. 其他一些需要注意的地方

(1) 如何节省因为特定容器配置的时间

在.gitlab-ci.yml里面,一个stage可能需要一个特定的容器来做任务,这样的话,默认会首先从 docker hub 里面 pull,并且如果使用刚 pull 下来的镜像生成容器,还需要更新源以安装配置所需环境,这时候可以考虑使用Dockerfile来配置特定的镜像来做特定任务,在一个 stage 中使用本地镜像来创建容器(容器可以在秒级启动,这个时间跟整个构建流程来说是可以接受的)。使用本地镜像,需要在 /srv/gitlab-runner/config/config.toml 里面添加pull-policy策略,策略有多个可选,可以设置为优先使用本地镜像,如果本地不存在镜像,再从docker hub里面pull,pull-policy的使用语法是 pull _policy = "if_not_present"if_not_present 这个关键字好像不能用了,可以直接换成 never,不使用远程镜像。

(2) docker 镜像的拉取策略有三种

  • never 任何情况下都不从 docker hub 拉取镜像
  • always 任何情况下都不使用本地镜像
  • if-not-present 优先使用本地镜像,如果本地不存在该镜像,会从 docker hub 拉取

拉取策略可以转到官网文档:https://docs.gitlab.com/runner/executors/docker.html

你可能感兴趣的:(工具,devops,持续集成,流水线,Pipeline)