Gitlab CI/CD

前言

纵观人类历史的发展以及三次工业革命,你会发现利用机器来替代部分人力劳动,将重复的工作自动化从而解放生产力都是发展的必然趋势,在软件工程领域也不例外,其中 CI/CD 就是其中一项,那么什么是 CI/CD 呢,网上的解释不要太多,这里我就直接放一幅 Gitlab 官网的工作流程图好了:

准备条件

  1. Gitlab runner
  2. .gitlab-ci.yml

    Gitlab runner

    Gitlab runner 是整个 CI/CD 的执行器,它是执行你写的 .gitlab-ci.yml 文件的虚拟机。
    Gitlab runner 分为两种:

  3. 特定的 runner:只能当前项目使用
  4. 共享的 runner:所有项目都可以使用

找到你的项目在 设置>Runners 里
你可以看到如下界面:


左侧就是特定的 runners 右侧就是共享的 runners,只要确保有其一就行。
关于 runner 的安装我不想过多赘述,官网写的很清楚,只要按照步骤一步一步搭建就好了。

.gitlab-ci.yml

当你有了 runner 就可以开始着手写 .gitlab-ci.yml 文件了,.gitlab-ci.yml 文件是对于整个 CI/CD 流程的描述文件,它告诉 runner 应该怎样执行具体的操作。
在具体介绍配置之前,我想先明确整个 .gitlab-ci.yml 里面的几个重要名词:

  1. job: job 是整个 CI/CD 的核心单元,它定义了在什么条件下应该执行什么任务,每个 job 都是相互隔离的。
  2. script: job 下的属性,用于描述 job 要执行的任务。
  3. stages: 定义 job 的分组,不同 job 可以所属于不同的阶段,一共有三个阶段可供选择:test build deploy,stage 的执行是按顺序的,但是 stage 下面的 job 是并行执行的,只有前一个 stage 执行成功才会执行下一个 stage,一旦上一个 stage 中任何一个 job 执行失败都会导致整个流水线失败。
  4. pipeline: 上面的整个流程就是一个流水线。

下面是我的一个前端项目的 .gitlab-ci.yml 文件,以它来作为示例:

image: node:10.13

stages:
- test
- build
- deploy cache:
paths:
- node_modules/ before_script:
## set proxy
- export http_proxy=http://10.2.3.63:3128/
- export https_proxy=http://10.2.3.63:3128/ test:
stage: test
tags:
- sams
script:
- npm install --no-optional --registry=https://registry.npm.taobao.org
- npm run lint
only:
- master
- dev build:
stage: build
tags:
- sams
script:
- npm run build
artifacts:
paths:
- $SOURCE_DIR
expire_in: 2 mins
only:
- master deploy:
stage: deploy
tags:
- sams
before_script:
## set debian mirros
- echo 'deb http://mirrors.aliyun.com/debian/ stretch main non-free contrib' > /etc/apt/sources.list
- echo 'deb-src http://mirrors.aliyun.com/debian/ stretch main non-free contrib' >> /etc/apt/sources.list
- echo 'deb http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list
- echo 'deb-src http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list
- echo 'deb http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list
- echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list
- echo 'deb http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list
- echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list
## Using SSH keys with GitLab CI/CD
## https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hosts
script:
- scp -r $SOURCE_DIR $DEPLOY_SERVER_USER@$DEPLOY_SERVER_IP:$TARGET_DIR
only:
- master
environment: test

全局配置

  • image: 要使用的 docker 镜像它会根据你写的镜像名从 docker hub 上面拉取镜像,因为我们的项目是前端项目,所以这里配置的镜像是 node,最终你的 script 指定的脚本会跑在 node 的 docker 环境下,这样就保证你有了必要的环境依赖(node)
  • stages: 定义整个流水线的各个阶段,这里我三个阶段都定义了,但是你可以根据你自己项目的实际情况定义,定义好后流水线将按照你定义的顺序依次执行。
  • cache: 定义 job 之间要缓存的文件,通常我们都会把项目的安装依赖作为缓存,这样下一个 job 就不用重新安装依赖了
  • before_script: 定义所有 job script 执行前需要执行的脚本,这里我设置了代理。

    job 的配置

  • stage: 定义该 job 所属的 stage
  • tags: 指定该 job 使用的 runner
  • script: 该 job 需要执行的脚本
  • only: 该 job 的约束条件,你可以指定该 job 在哪些情况下会触发,比如只有 master 分支和 develop 分支才会执行 deploy 的 job,与此相对的还有一个 except 属性表示什么条件下不执行该 job
  • artifacts: 用于在不同 stage 之间传递结果,通用的做法是将 build 阶段打包出来的文件定义为 artifacts,这样在 deploy 阶段就可以直接使用了,这里你可能会对 artifacts 和 cache 有些搞不清,这里推荐看官方的说明
  • environment: 用于定义 job 部署的环境,这里需要结合 Gitlab 项目的 UI 界面,比如这里我设置的名称叫 test,每次部署成功之后 test 环境下就会多一个部署条目,你可以重新部署甚至回滚到某个部署,如下图所示:

另外 environment 下还有一个 url 属性可以定义部署到的服务器地址,这样你可以在 UI 界面通过点击按钮直接跳转到项目,如果你的 Gitlab 低于 8.11 那只能通过在 UI 界面(上图)手动配置了。

ssh keys 实现免密登录

一般来讲你部署项目的时候不可避免会用到 ssh 协议,但是 ssh 协议需要你手动输入用户名和密码,这样不就无法实现自动化部署了? 别急,Gitlab 已经帮我们想到了这一点,仔细阅读官网上的 Using SSH keys with GitLab CI/CD 这篇文章你就能找到解决方案,或者参考我的实例代码:

## Using SSH keys with GitLab CI/CD
## https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hosts

这里我还是要简单说一下其实现原理,Gitlab 首先让你生成一对 ssh 的公钥和私钥,在每次执行 CI/CD 时将私钥(此时已添加到环境变量里)通过 ssh-add 添加到 ssh-agent 里面进行管理,并将设置好的 $SSH_KNOWN_HOSTS (里面就包含了你要 shh 的主机) 也添加到 known_hosts 文件中,这样在执行 ssh 命令时远程机器就能识别你的身份从而实现免密登录,本质上和你本地实现免密登录的道理是一样的。

其它

环境变量

类似于编程中的变量,环境变量可以存储一些要要变化的或是比较私密的信息,环境变量配置好后可以通过 $ + 变量名 在 script 里面进行调用

查看流水线状态

在 Gitlab 主页找到流水线页签,打开之后就能看到所有流水线的运行情况

点击进入具体的 stage 你可以看到其执行细节,如果失败也可以重新执行

参考资料

https://docs.gitlab.com/ee/ci/README.html

总结

这次也是我初次尝试使用 Gitlab CI/CD ,每次任务大概执行需要 8 分钟,如果你像之前手动去做这些工作那你每次都至少需要花费 8 分钟时间,不要小瞧这 8 分钟,日积月累也是一笔不小的开支,更重要的是机器很少出错的,但是人的话就没法保证了,而且就像我在开篇所说简单重复性的工作必然会被机器取代,这是不可避免的历史规律,不管你用不用它,技术的潮流都会不断向前推动,所以还不如提前拥抱它。
另外此次只介绍了整个 Gitlab CI/CD 功能的冰山一角,Gitlab 还提供很多优秀的功能,比如在 merge request 的时候进行 CI/CD,所以更多的功能还有待挖掘,如果你感兴趣可以去官方文档上找寻,如果有什么不对的地方还请您指正,最后感谢您的阅读!

Gitlab CI/CD的更多相关文章

  1. [转]GitLab Continuous Integration (GitLab CI/CD)

    本文转自:https://docs.gitlab.com/ee/ci/README.html GitLab Continuous Integration (GitLab CI/CD) The bene ...

  2. 使用 Gitlab CI/CD 实现自动化发布站点到 IIS

    说明 这里先介绍下两个东西 CI/CD.GitLab Runner,当然在此之前你需要对 git 有所了解,关于 git 这里不做说明,可以自行百度. 首先介绍 CI/CD :随着我们开发方式的转变, ...

  3. 前端初探 Gitlab CI/CD

    前言 纵观人类历史的发展以及三次工业革命,你会发现利用机器来替代部分人力劳动,将重复的工作自动化从而解放生产力都是发展的必然趋势,在软件工程领域也不例外,其中 CI/CD 就是其中一项,那么什么是 C ...

  4. .Net Core自动化部署系列(三):使用GitLab CI/CD 自动部署Api到Docker

    之前写过使用Jenkins实现自动化部署,最近正好没事研究了下GitLab的自动化部署,顺便记录一下. 使用GitLab部署我们需要准备两件事,第一个起码你得有个GitLab,自己搭建或者使用官方的都 ...

  5. GitLab CI/CD持续集成设置

    GitLab CI/CD持续设置 官方文档地址(https://docs.gitlab.com/ee/ci/README.html) GitLab CI.CD功能非常完善,只需要简单几步,就可以完成项 ...

  6. GitLab CI/CD的官译【原】

    CI / CD方法简介 软件开发的持续集成基于自动执行脚本,以最大限度地减少在开发应用程序时引入错误的可能性.从新代码的开发到部署,它们需要较少的人为干预甚至根本不需要干预. 它涉及在每次小迭代中不断 ...

  7. .NetCore 配合 Gitlab CI&CD 实践 - 开篇

    引言 这是一个系列的文章,讲述的是一个中小型开发团队如何从零开始使用搭建基建 GitLab 代码托管平台,以及使用 GitLab Runner 实现 CI/CD 的故事.本系列通过部署一个完整的 .n ...

  8. .NetCore 配合 Gitlab CI&CD 实践 - 单体项目

    前言 上一篇博文 .NetCore 配合 Gitlab CI&CD 实践 - 开篇,主要简单的介绍了一下 GitLab CI 的持续集成以及持续部署,这篇将通过 GitLab CI 发布一个 ...

  9. GitLab CI/CD 配置

    GitLab CI/CD 配置 概念 持续集成的相关概念,可以看这篇文章 持续集成是什么? - 阮一峰的网络日志 操作示例 创建测试项目 sample-web,然后打开项目的 Runners 配置 找 ...

随机推荐

  1. .net core 3.0中动态卸载程序集

    动态加载程序集在一些插件式的应用中非常常见,.net core 2.0中可以通过AssemblyLoadContext中提供程序集的动态加载功能,但取不支持卸载.现在,在.net core 3.0中提 ...

  2. [笔记] C# 如何获取文件的 MIME Type

    MIME Type 为何物: MIME 参考手册 svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types 常规方式 对于有文件后 ...

  3. Python - 模块 - 第十六天

    Python 模块 在前面的几个章节中我们脚本上是用 python 解释器来编程,如果你从 Python 解释器退出再进入,那么你定义的所有的方法和变量就都消失了. 为此 Python 提供了一个办法 ...

  4. CSS 基础面试题

    1 介绍一下标准的CSS的盒子模型?与低版本IE的盒子模型有什么不同的? 标准盒子模型:宽度=内容的宽度(content)+ border + padding + margin 低版本IE盒子模型:宽 ...

  5. web前端-js

    1. js基础语法 声明变量 var a = 10; 查看变量类型 typeof a; 打印,测试语句 alert(a); #使用弹出框显示 console.log(a);    #使用console ...

  6. Git上传到码云及其常见问题详解

    1.git init 初始化 2.git  remote origin add https://gitee.com/su_yong_qing/SyqSystem.git 这里注意把链接替换为自己的仓库 ...

  7. FCC-学习笔记 Sorted Union

    FCC-学习笔记  Sorted Union 1>最近在学习和练习FCC的题目.这个真的比较的好,推荐给大家. 2>中文版的地址:https://www.freecodecamp.cn/; ...

  8. Docker 安装mysql以及外部访问

    (1)因为我们的镜像是linux环境下的,我所在的系统是windows系统.首先通过docker客户端切换到linux环境下. (2)使用docker pull mysql/mysql-server ...

  9. 智能社javascript

    http://www.chuanke.com/?mod=student&act=study&courseid=91706

  10. 二、HDFS(架构、读写、NN)

    一.HDFS定义 HDFS (Hadooop Distributed File System),它是一个文件系统,用于存储文件,通过目录树来定位文件:其次,它是分布式的,由很多服务器联合走来实现其功能 ...