【devops】gitlab 实现cicd 实践

本站以分享各种运维经验和运维所需要的技能为主

《python零基础入门》：python零基础入门学习

《python运维脚本》： python运维脚本实践

《shell》：shell学习

《terraform》持续更新中：terraform_Aws学习零基础入门到最佳实战

《k8》暂未更新

《docker学习》暂未更新

《ceph学习》ceph日常问题解决分享

《日志收集》ELK+各种中间件

《运维日常》运维日常

《linux》运维面试100问

通过软件开发的持续方法，您可以持续构建、测试和部署迭代代码更改。这个迭代过程有助于减少您基于错误或失败的先前版本开发新代码的机会。使用这种方法，从开发新代码到部署，您努力减少人为干预，甚至完全不干预。

Continuous Integration (CI) 持续集成
Continuous Delivery (CD) 持续交付
Continuous Deployment (CD) 持续部署

GitLab CI/CD 介绍

Continuous Integration 持续集成

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

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

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

Continuous Delivery 持续交付

持续交付是超越持续集成的一步。每次将代码更改推送到代码库时，不仅会构建和测试您的应用程序，而且还会持续部署应用程序。但是，通过持续交付，您可以手动触发部署。

持续交付会自动检查代码，但需要人工干预才能手动和战略性地触发更改的部署

Continuous Deployment 持续部署

持续部署是超越持续集成的又一步，类似于持续交付。不同之处在于，您无需手动部署应用程序，而是将其设置为自动部署。不需要人为干预。

GitLab CI/CD 是如何工作的

为了使用GitLab CI/CD，你需要一个托管在 GitLab 上的应用程序代码库，并且在根目录中的 .gitlab-ci.yml 文件中指定构建、测试和部署的脚本。

在这个文件中，你可以定义要运行的脚本，定义包含的依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在何处部署应用程序，以及指定是否要自动运行脚本或手动触发脚本。

为了可视化处理过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。

一旦你已经添加了.gitlab-ci.yml到仓库中，GitLab 将检测到该文件，并使用名为 GitLab Runner 的工具运行你的脚本。该工具的操作与终端类似。

这些脚本被分组到 jobs，它们共同组成一个 Pipeline。一个最简单的 .gitlab-ci.yml 文件可能是这样的：

复制代码

before_script:   
  - apt-get install rubygems ruby-dev -y   
  
run-test:   
  script:   
    - ruby --version 6

before_script 属性将在运行任何内容之前为你的应用安装依赖，一个名为 run-test 的 job（作业）将打印当前系统的 Ruby 版本。二者共同构成了在每次推送到仓库的任何分支时都会被触发的 Pipeline（管道）。

GitLab CI/CD 不仅可以执行你设置的 job，还可以显示执行期间发生的情况，正如你在终端看到的那样：

为你的应用创建策略，GitLab 会根据你的定义来运行 Pipeline。你的管道状态也会由 GitLab 显示：

最后，如果出现任何问题，可以轻松地回滚所有更改：

基本CI/CD 工作流程

一旦你将提交推送到远程仓库的分支上，那么你为该项目设置的 CI/CD 管道将会被触发。GitLab CI/CD 通过这样做：

运行自动化脚本（串行或并行）代码Review并获得批准构建并测试你的应用就像在你本机中看到的那样，使用 Review Apps 预览每个合并请求的更改代码 Review 并获得批准合并 feature 分支到默认分支，同时自动将此次更改部署到生产环境如果出现问题，可以轻松回滚通过 GitLab UI 所有的步骤都是可视化的。

深入了解CI/CD 的基本工作流程

Verify：

通过持续集成自动构建和测试你的应用程序
使用 GitLab 代码质量（GitLab Code Quality）分析你的源代码质量
通过浏览器性能测试（Browser Performance Testing）确定代码更改对性能的影响
执行一系列测试，比如 Container Scanning，Dependency Scanning，JUnit tests
用 Review Apps 部署更改，以预览每个分支上的应用程序更改

Package：

用 Container Registry 存储 Docker 镜像
用 NPM Registry 存储 NPM 包
用 Maven Repository 存储 Maven artifacts
用 Conan Repository 存储 Conan 包

Release：

持续部署，自动将你的应用程序部署到生产环境
持续交付，手动点击以将你的应用程序部署到生产环境
用 GitLab Pages 部署静态网站
仅将功能部署到一个 Pod 上，并让一定比例的用户群通过 Canary Deployments 访问临时部署的功能（PS：即灰度发布）
在 Feature Flags 之后部署功能
用 GitLab Releases 将发布说明添加到任意 Git tag
使用 Deploy Boards 查看在 Kubernetes 上运行的每个 CI 环境的当前运行状况和状态
使用 Auto Deploy 将应用程序部署到 Kubernetes 集群中的生产环境

使用 GitLab CI/CD，还可以：

通过 Auto DevOps 轻松设置应用的整个生命周期
将应用程序部署到不同的环境
安装你自己的 GitLab Runner
Schedule pipelines
使用安全测试报告（Security Test reports）检查应用程序漏洞

GitLab CI/CD 快速开始

.gitlab-ci.yml 文件告诉 GitLab Runner 要做什么。一个简单的管道通常包括三个阶段：build、test、deploy，管道在 CI/CD > Pipelines 页面。

创建一个.gitlab-ci.yml 文件

通过配置 .gitlab-ci.yml 文件来告诉 CI 要对你的项目做什么。它位于仓库的根目录下。

仓库一旦收到任何推送，GitLab 将立即查找 .gitlab-ci.yml 文件，并根据文件的内容在 Runner 上启动作业。

下面是一个 Ruby 项目配置例子：

复制代码

image: "ruby:2.5"  
  
before_script:  
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs  
  - ruby -v  
  - which ruby  
  - gem install bundler --no-document  
  - bundle install --jobs $(nproc)  "${FLAGS[@]}"  
   
rspec:  
  script:  
    - bundle exec rspec  
  
rubocop:  
  script:  
    - bundle exec rubocop

上面的例子中，定义里两个作业，分别是 rspec 和 rubocop，在每个作业开始执行前，要先执行 before_script 下的命令。

推送.gitlab-ci.yml 到GitLab

git add .gitlab-ci.yml

git commit -m "Add .gitlab-ci.yml"
git push origin master

配置一个Runner

在 GitLab 中，Runner 运行你定义在 .gitlab-ci.yml 中的作业（job）。

一个 Runner 可以是一个虚拟机、物理机、Docker 容器，或者一个容器集群。

GitLab 与 Runner 之间通过 API 进行通信，因此只需要 Runner 所在的机器有网络并且可以访问 GitLab 服务器即可。

你可以去 Settings ➔ CI/CD 看是否已经有 Runner 关联到你的项目，设置 Runner 简单又直接。

查看Pipeline和Jobs的状态

在成功配置 Runner 以后，你应该可以看到你最近的提交的状态。

为了查看所有 jobs，你可以去 Pipelines ➔ Jobs 页面。

通过点击作业的状态，你可以看到作业运行的日志。

回顾一下：

首先，定义 .gitlab-ci.yml 文件。在这个文件中就定义了要执行的 job 和命令
接着，将文件推送至远程仓库
最后，配置 Runner，用于运行 job

示例

使用GitLab CI/CD 部署衣蛾Spring Boot 应用

复制代码

image: java:8  
   
stages:  
  - build  
  - deploy  
   
before_script:  
  - chmod +x mvnw  
   
build:  
  stage: build  
  script: ./mvnw package  
  artifacts:  
    paths:  
      - target/demo-0.0.1-SNAPSHOT.jar  
   
production:  
  stage: deploy  
  script:  
  - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx  
  - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io  
  - ./cf push  
  only:  
  - master

管道内部分为2个阶段，可以查看每个阶段有几个作业在运行

构建 -> 部署

并且部署阶段绑定了分支，在构建之前，定义预操作，执行脚本，没有匹配到的分支将不会执行部署阶段。