持续集成(Continuous integration,简称CI)指的是,频繁地(一天多次)将代码集成到主干。
它的好处主要有两个。
持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。
(2) 持续交付、持续部署的概念 持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。
持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。
(3) 持续集成系统的组成
(4) 为什么要引入auto devops
(1) Pipeline
(2) stages
(3) jobs
(4) gitlab runner
(1) 从docker hub下载gitlab/gitlab-runner镜像
root# docker pull gitlab/gitlab-runner
(2) 准备一个用来完成stage的镜像
多个步骤使用同一个镜像来创建容器,也可以根据不同stage准备多个特定的镜像。
这里只是介绍一个使用docker来完成多个简单stage的demo,就拿一个最简单的能完成任务的镜像,一个简单的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
解释一下:
root# docker-compose up -d
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:
注册runner
root# docker exec -it gitlab-runner gitlab-runner register
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镜像的拉取策略“来说。
一次Pipeline的体验 提交代码
流水线在执行的时候
流水线运行完毕
流水线总体概况
(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 拉取
作者:Chengzi_comm 来源:CSDN 原文:https://blog.csdn.net/chengzi_comm/article/details/78778284