gitlab ci/cd从零单排

安装gitlab

添加gitlab镜像

wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-10.0.0-ce.0.el7.x86_64.rpm

复制代码

安装gitlab

rpm -i gitlab-ce-10.0.0-ce.0.el7.x86_64.rpm

复制代码

修改gitlab配置文件指定服务器IP和自定义端口

vim /etc/gitlab/gitlab.rb

复制代码

修改服务器IP

external_url 'http://gitlab.test.domain.com:8888'

复制代码

执行配置

gitlab-ctl reconfigure

复制代码

启动

gitlab-ctl start 

复制代码

安装 gitlab-runner

下载

curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
复制代码

添加权限

chmod +x /usr/local/bin/gitlab-runner
复制代码

新建gitlab-runner用户

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
复制代码

安装时需要指定我们上面新建的用户

gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
复制代码

启动

gitlab-runner start
复制代码

注册

gitlab-runner register
复制代码

启动

gitlab-runner run
复制代码

基本概念

1.1 CI/CD CI，Continuous Integration，为持续集成。即在代码构建过程中持续地进行代码的集成、构建、以及自动化测试等；有了 CI 工具，我们可以在代码提交的过程中通过单元测试等尽早地发现引入的错误； CD，Continuous Deployment，为持续交付。在代码构建完毕后，可以方便地将新版本部署上线，这样有利于快速迭代并交付产品。

1.2 GitLab CI/CD GitLab CI/CD（后简称 GitLab CI）是一套基于 GitLab 的 CI/CD 系统，可以让开发人员通过 .gitlab-ci.yml 在项目中配置 CI/CD 流程，在提交后，系统可以自动/手动地执行任务，完成 CI/CD 操作。而且，它的配置非常简单，CI Runner 由 Go 语言编写，最终打包成单文件，所以只需要一个 Runner 程序、以及一个用于运行 jobs 的执行平台（如裸机+SSH，Docker 或 Kubernetes 等，我推荐用 Docker，因为搭建相当容易）即可运行一套完整的 CI/CD 系统。

下面针对 Gitlab CI 平台的一些基本概念做一个简单介绍：

Job

Job 为任务，是 GitLab CI 系统中可以独立控制并运行的最小单位。 在提交代码后，开发者可以针对特定的 commit
完成一个或多个 job，从而进行 CI/CD 操作。

Stage

一般的流水线通常会分为几段；在 pipeline
中，可以将多个任务划分在多个阶段中，只有当前一阶段的所有任务都执行成功后，下一阶段的任务才可被执行。

Pipeline

Pipeline 即流水线，可以像流水线一样执行多个 Job. 在代码提交或 MR 被合并时，GitLab 可以在最新生成的 commit
上建立一个 pipeline，在同一个 pipeline 上产生的多个任务中，所用到的代码版本是一致的。

CI Pipeline 上图中，整条流水线从左向右依次执行，每一列均为一个阶段，而列中的每个可操控元素均为任务。 左边两个阶段的任务是自动执行的任务，在commit提交后即可自动开始运行，执行成功或失败后，可以点击任务右边的按钮重试；而右边两个是手动触发任务，需要人工点击右边的“播放”按钮来手动运行。

编写.gitlab-ci.yml 文件

.gitlab-ci.yml 文件被用来管理项目的 runner 任务,该文件存放于项目根目录下

stages:
- build
- test
- deploy

build_maven:
  stage: build
  script:
  - echo "build maven....."
  - echo "mvn clean"
  - echo "done"

test_springboot:
  stage: test
  script:
  - echo "run java test....."
  - echo "java -test"
  - echo "done"

deploy_springboot:
  stage: deploy
  script:
  - echo "deploy springboot...."
  - echo "run mvn install"
  - echo "done"

复制代码

stage翻译为阶段的意思，在构建的过程中，必须要有一个先后顺序。最上面的stages配置意思是，先构建阶段为build的job，然后再构建阶段为test的job，下面build_maven、test_springboot、deploy_springboot都是job，如果不配置stages，默认为：

stages: - build - test - deploy

在每个任务中，通常会包含 image, stage,services, script 等字段。 其中，stage 定义了任务所属的阶段；image 字段指定了执行任务时所需要的 docker 镜像；services 指定了执行任务时所需的依赖服务（如数据库、Docker 服务器等）；而 script 直接定义了任务所需执行的命令。

声明job

开始构建之前YAML文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含script部分：

job1:
  script: execute-script-for-job1

job2:
  script: execute-script-for-job2
复制代码

上面这个例子就是一个最简单且带有两个独立任务的CI配置，每个任务分别执行不同的命令，且job必须包含一个script，不然会报错。

script可以直接执行系统命令(例如：./configure && make && make install)或者是直接执行脚本(test.sh)。 任务是由Runners接管并且由服务器中runner执行。更重要的是，每一个任务的执行过程都是独立运行的。 下面列出保留字段，这些保留字段不能被定义为job名称：

关键字	是否必须	描述
image	否	用于docker镜像，查看docker文档
services	否	用于docker服务，查看docker文档
stages	否	定义构建阶段
types	否	stages 的别名(已废除)
before_script	否	定义在每个job之前运行的命令
after_script	否	定义在每个job之后运行的命令
variable	否	定义构建变量
cache	否	定义一组文件列表，可在后续运行中使用

image和services

这两个关键字允许使用一个自定义的Docker镜像和一系列的服务，并且可以用于整个job周期。详细配置文档请查看a separate document。

before_script

before_script用来定义所有job之前运行的命令，包括deploy(部署) jobs，但是在修复artifacts之后。它可以是一个数组或者是多行字符串。

after_script

after_script用来定义所有job之后运行的命令。它必须是一个数组或者是多行字符串

stages

stages用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。

stages中的元素顺序决定了对应job的执行顺序：

1. 相同stage的job可以平行执行。
2. 下一个stage的job会在前一个stage的job成功后开始执行。 接下仔细看看这个例子，它包含了3个stage：

stages:
 - build
 - test
 - deploy
复制代码

1. 首先，所有build的jobs都是并行执行的。
2. 所有build的jobs执行成功后，test的jobs才会开始并行执行。
3. 所有test的jobs执行成功，deploy的jobs才会开始并行执行。
4. 所有的deploy的jobs执行成功，commit才会标记为success
5. 任何一个前置的jobs失败了，commit会标记为failed并且下一个stages的jobs都不会执行。

这有两个特殊的例子值得一提：

1. 如果.gitlab-ci.yml中没有定义stages，那么job’s stages 会默认定义为 build，test 和 deploy。
2. 如果一个job没有指定stage，那么这个任务会分配到test stage。

.pre&post

stage:.pre为管道的第一个阶段去运行，post为最后一个阶段去运行，如果一个管道仅包含.pre和post阶段管道不会创建