由于不可抗力 /(ㄒoㄒ)/~~国庆学习了 GitLab CI 简单来聊一聊

那一蔚蓝

已于 2022-10-12 22:10:32 修改

阅读量196

点赞数 1

分类专栏： CI 文章标签：云原生 devops

于 2022-10-11 21:15:31 首次发布

本文链接：https://blog.csdn.net/lijieaace/article/details/127268374

版权

CI 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

GitLab CI

一、CI/CD？
二、GitLab CI
总结

一、CI/CD？

CI/CD 是一种通过在应用开发阶段频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，解决了重复迭代一个重要过程。

具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的步骤一般被叫做"pipeline（管道）"，由开发和运维团队相互协同支持，来维护整个应用的周期迭代。现在主要说的是其中的 CI ，也就是其中的持续集成，主要谈一谈GitLab 其中的CI。

二、GitLab CI

1. 相关概念

GitLab CI/CD官网
他是这样介绍的：考虑一个应用程序，它的代码存储在 GitLab 的 Git 存储库中。开发人员每天多次推送代码更改。对于每次推送到存储库，您都可以创建一组脚本来自动构建和测试您的应用程序。这些脚本有助于减少您在应用程序中引入错误的机会。

这种做法被称为持续集成。提交给应用程序的每个更改，甚至是提交给开发分支的更改，都是自动且持续地构建和测试的。这些测试可确保更改通过您为应用程序建立的所有测试、指南和代码合规性标准。

GitLab 本身就是一个使用持续集成作为软件开发方法的项目示例。对于项目的每次推送，都会对代码进行一组检查。

总结其实就是一个在迭代中维护代码流水线上一个重要工具统称的概念

2. 选择，GitLab CI特点

由于大部分公司代码都是在 GitLab 中完成的，因此 CI/CD 解决方案可以非常简单，自己的一套CI会更加适用，与 GitLab CI 的无缝集成
使用简单、快速

流程图有个大概的了解

GitLab CI 流程图
在这里插入图片描述

3.环境以及其他配置

1. gitlab-ci.yml

首先运行一整套流程他肯定有一个规则表，这就是对管道（后面的pipeline）的执行制定了一个规则，在提交代码后会按照这个规则表去执行相应的job，来管理整个CI的工作流程。
官网中的一个 eg：

stages:
  - build
  - test

build-code-job:
  stage: build
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2

解释：在这个例子中，build 阶段的 build-code-job 作业首先运行。它输出作业使用的 Ruby 版本，然后运行 rake 来构建项目文件。如果此作业成功完成，则 test 阶段中的两个 test-code-job 作业将并行启动并对文件运行测试。

示例中的完整流水线由三个作业组成，分为两个阶段，build 和 test。每次将更改推送到项目中的任何分支时，流水线都会运行。

2. pipeline

管道是持续集成、交付和部署的顶级组件。

管道包括：

jobs，它定义了要做什么。例如，编译或测试代码的作业。
stages，定义何时运行作业。例如，在编译代码的阶段之后运行测试的阶段。

作业由runners执行。如果有足够的并发运行者，同一阶段的多个作业将并行执行。

如果一个阶段中的所有作业都成功，则管道将进入下一个阶段。

如果一个阶段中的任何作业失败，则（通常）不会执行下一个阶段，并且管道会提前结束。

一般来说，管道是自动执行的，一旦创建就不需要干预。但是，有时您也可以手动与管道交互。

一个典型的管道可能包含四个阶段，按以下顺序执行：

一个build stage，有一个工作叫做compile.
一个test stage，有两个作业称为test1和test2。
一个staging stage，有一个工作叫做deploy-to-stage.
一个production stage，有一个工作叫做deploy-to-prod.

总结类似pipeline 就是我们运行货物（代码）的一个传送带（管道）。

3. GitLab Runner

首先有了制定的规则以及管道，那肯定必须要有工人去作业与这些管道才能让管道动起来。
GitLab Runner 是一个与 GitLab CI/CD 一起使用以在管道中运行作业的应用程序。

可以选择在拥有或管理的基础设施上安装GitLab Runner 应用程序，就是在自己的服务器上安装 Runner 。如果这样做，出于安全和性能原因，您应该将 GitLab Runner 安装在与托管 GitLab 实例的机器不同的机器上。当您使用不同的机器时，可以在每台机器上拥有不同的操作系统和工具，例如 Kubernetes 或 Docker。

同时运行多个作业。
对多个服务器（甚至每个项目）使用多个令牌。
限制每个令牌的并发作业数。

4.gitlab-ci.yml的一些关键字

关键字	描述
default	工作关键字的自定义默认值。
include	从其他 YAML 文件导入配置
stages	流水线阶段的名称和顺序
variables	为管道中的所有作业定义 CI/CD 变量
workflow	控制运行什么类型的管道