【持续集成】GitLab CI + Docker 实现持续集成

GitLab CI + Docker 实现持续集成 一、持续集成(Continuous Integration, CI)的基本概念 概述

在传统软件的开发中,代码的集成工作通常是在所有人都将工作完成后在项目即将结束进行时,而这往往会花费大量的时间和精力。而持续集成是一种将集成阶段放在软件开发阶段的做法,以便更加有规律地构建,测试和集成代码。

“持续集成并不能消除 Bug,而是让它们非常容易发现和改正。”

持续集成可以在开发人员提交了新代码后,立刻进行构建、单元测试。从而我们可以根据测试结果以确定新的代码或者环境配置与原来的以及其他开发人员的代码或者环境配置能否正确地集成在一起。

【持续集成】GitLab CI + Docker 实现持续集成

持续交付 & 持续部署

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

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

【持续集成】GitLab CI + Docker 实现持续集成

二、GitLab 持续集成起步

从 GitLab 8.0 开始,GitLab CI 就已经集成在 GitLab 中,我们只需要在项目中添加一个 .gitlab-ci.yml 文件,然后添加一个 Runner,即可进行持续集成。而且随着 GitLab 的升级,GitLab 也变得越来越强大。

.gitlab-ci.yml

.gtilab-ci.yml 文件存放与项目于仓库的根目录,用以来定义 GitLab CI/CD 中的 Pipeline。其实无非是一个配置文件,理解起来挺简单的,我们主要是需要了解 Pipeline 的概念以及如何配置一个 .gitlab-ci.yml

Pipeline & Stages & Jobs

一个 Pipeline 大概相对于一个构建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程,Git 提交时会触发 Pipeline。而一个 Pipeline 中又可以包含一至多个 Stage,即用来定义安装依赖、运行测试之类的流程的。然后,一个 Stage 中又包含了一至多个 Job,Jobs 表示一个 Stage 中具体的构建工作,即某个 Stage 里面执行的工作。我们可以在 Stages 里面定义这些 Job,它们之间的关系如下图所示:

【持续集成】GitLab CI + Docker 实现持续集成

注意:

Stages 会按 .gitlab-ci.yml 中配置的顺序执行,当前面的 Stage 执行完毕后才会继续执行后面的 Stage,如果一个 Stage 失败,那么后面的 Stage 不会执行,该构建任务失败。

Stage 中的 Jobs 会并行执行,当这个 Stage 中所有的 Job 都执行完毕,该 Stage 才算执行成功。换而言之,只要有一个 Job 执行失败,整个 Pipeline 也就失败了。

stages: - build - test - deploy build: stage: build script: - "execute-script-for-build" - "do something..."" only: - master tags: - ruby - postage test: stage: test script: ......

上面配置将一次 pipeline 分成了三个阶段:build、test、deploy。下面介绍配置文件中的节点:

stages: 定义构建的阶段;

build、test、...:定义 jobs_name,即在 stages 中定义的 stage 阶段,一般在 stage 节点注明所属的 stage;

script:Runner 执行的脚本或命令,该节点是必须的。

其他节点:stage 中还有许多其他节点,例如 only、tags 等,但并不是 required ,其具体作用可在文档中了解。

GitLab Runner

当我们理解完上面的概念后,我们还没了解最重要的东西——上面的任务由谁来构建呢?答案就是 Gitlab-runner 了!

为什么不用 GitLab CI 来运行这些构建任务呢?

一般来说,构建任务任务都会占用很多的系统资源(譬如编译代码),而 GitLab CI 又是 GitLab 的一部分,如果由 GitLab CI 来运行构建任务的话,在执行构建任务的时候, GitLab 的性能会大幅下降。

GitLab CI 最大的作用是管理各个项目的构建状态,因此,运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做啦!

因为 GitLab Runner 可以安装到不同的机器上,所以在构建任务运行期间并不会影响到 GitLab 的性能。

三、持续集成的实现

接下来介绍 GitLab 对 Spring Boot 程序的持续集成,当然 GitLab 不止支持 Java 应用服务,肯定也支持其他编译语言,这里主要只是像演示一下过程,过程基本上是相通的。

搭建 GitLab 服务

这不是本次的重点,所以就简要介绍下咯。
利用 Docker 和 Docker Compose 快速搭建 GitLab 服务,docker-compose.yml 文件如下:

version: '3' services: web: image: 'twang2218/gitlab-ce-zh:10.5' restart: always hostname: '192.168.253.139' environment: TZ: 'Asia/Shanghai' GITLAB_OMNIBUS_CONFIG: | external_url 'http://192.168.253.139:8080' gitlab_rails['gitlab_shell_ssh_port'] = 2222 unicorn['port'] = 8888 nginx['listen_port'] = 8080 ports: - '8080:8080' - '8443:443' - '2222:22' volumes: - /usr/local/docker/gitlab/config:/etc/gitlab - /usr/local/docker/gitlab/data:/var/opt/gitlab - /usr/local/docker/gitlab/logs:/var/log/gitlab

启动完毕后,访问 :8080,初始化安装完成后效果如下:

【持续集成】GitLab CI + Docker 实现持续集成

设置初始化密码后刷新,就可以看见登录界面了,登录!

配置 SSH 免密登录 ssh-keygen -t rsa -P 'youname'

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wsxszw.html