跳转至

01-自动化CICD-Gitlab

DevOps（英文Development（开发）和Operations（技术运营）的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作

持续集成概念

持续集成Continuous Integration
持续交付Continuous Delivery
持续部署Continuous Deployment

什么是持续集成

持续集成是指开发者在代码的开发过程中，可以频繁的将代码部署集成到主干，并进程自动化测试

image-20211101094132745

什么是持续交付

持续交付指的是在持续集成的环境基础之上，将代码部署到预生产环境

image-20211101094200432

什么是持续部署

在持续交付的基础上，把部署到生产环境的过程自动化，持续部署和持续交付的区别就是最终部署到生产环境是自动化的。

image-20211101094231742

部署代码上线流程

1.代码获取（直接了拉取）
2.编译      （可选）
3.配置文件放进去
4.打包
5.scp到目标服务器
6.将目标服务器移除集群
7.解压并放置到Webroot
8.Scp 差异文件
9.重启      （可选）
10.测试
11.加入集群

运维必知OWASP

Jenkins上OWASP 插件介绍： 它是开放式Web应用程序安全项目[OWASP,Open Web Application Secunity Project]

它每年会出一个top10的安全漏洞，我们需要知道当前top10的漏洞有哪些

image-20211101094356602

https://www.owasp.org/images/5/57/OWASP_Proactive_Controls_2.pdf

https://www.owasp.org/index.php/Top_10_2013-Top_10

自动化运维之DevOps

DevOps（英文Development（开发）和Operations（技术运营）的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作

简单的来说DevOps是一种文化，是让开发开发、运维、测试能够之间沟通和交流

自动化运维工具：saltstack、jenkins、等。因为他们的目标一样，为了我们的软件、构建、测试、发布更加的敏捷、频繁、可靠

如果运维对git不熟，是无法做自动化部署。因为所有的项目都受制于开发

Gitlab服务部署

GitLab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。

GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。

环境准备

[root@linux-node1 ~]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
[root@linux-node1 ~]# uname -r
3.10.0-514.2.2.el7.x86_64

下载epel源
[root@linux-node1 ~]# wget http://mirrors.aliyun.com/epel/epel-release-latest-7.noarch.rpm 
[root@linux-node1 ~]# wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo 

关闭 NetworkManager 和防火墙 
[root@linux-node1 ~]#systemctl stop firewalld.service
systemctl disable firewalld 
systemctl disable NetworkManager

关闭SELinux并确认处于关闭状态 
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
grep SELINUX=disabled /etc/selinux/config
setenforce 0

更新系统并重启
[root@linux-node1 ~]# yum update -y && reboot

我们一共有2台：192.168.56.11和192.168.56.12我们安装在192.168.56.11上

[root@linux-node1 /]# yum install curl policycoreutils openssh-server openssh-clients postfix -y
[root@linux-node1 /]# systemctl start postfix
[root@linux-node1 /]# curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
[root@linux-node1 /]# yum install -y gitlab-ce

#由于网络问题，国内用户，建议使用清华大学的镜像源进行安装

[root@linux-node1 ~]# cat /etc/yum.repos.d/gitlab-ce.repo
[gitlab-ce]
name=gitlab-ce
baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packages.gitlab.com/gpg.key
[root@linux-node1 ~]# yum makecache

安装部署

安装gitlab

[root@linux-node1 /]#  yum install -y gitlab-ce

在安装一个git客户端

[root@linux-node1 /]#  yum install -y git

配置启动

配置并启动gitlab-ce

[root@linux-node1 ~]# gitlab-ctl reconfigure
#时间可能比较长，耐心你等待即可！----


gitlab常用命令：
关闭gitlab：[root@linux-node2 ~]# gitlab-ctl stop
启动gitlab：[root@linux-node2 ~]# gitlab-ctl start
重启gitlab：[root@linux-node2 ~]# gitlab-ctl restart
重载配置文件: gitlab-ctl reconfigure

可以使用gitlab-ctl管理gitlab，例如查看gitlab状态：

[root@linux-node1 /]#  gitlab-ctl status
run: gitlab-workhorse: (pid 7437) 324s; run: log: (pid 7436) 324s
run: logrotate: (pid 7452) 316s; run: log: (pid 7451) 316s
run: nginx: (pid 8168) 2s; run: log: (pid 7442) 318s
run: postgresql: (pid 7293) 363s; run: log: (pid 7292) 363s
run: redis: (pid 7210) 369s; run: log: (pid 7209) 369s
run: sidekiq: (pid 7479) 265s; run: log: (pid 7426) 326s
run: unicorn: (pid 7396) 327s; run: log: (pid 7395) 327s

提示： 我们要保证80端口不被占用

我们可以查看一下端口

[root@linux-node1 /]# gitlab-ctl restart
ok: run: gitlab-workhorse: (pid 8353) 0s
ok: run: logrotate: (pid 8360) 1s
ok: run: nginx: (pid 8367) 0s
timeout: down: postgresql: 0s, normally up, want up
ok: run: redis: (pid 8437) 0s
ok: run: sidekiq: (pid 8445) 0s
ok: run: unicorn: (pid 8450) 0s

[root@linux-node1 /]# lsof -i:80
COMMAND  PID       USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   8367       root    7u  IPv4  54972      0t0  TCP *:http (LISTEN)
nginx   8368 gitlab-www    7u  IPv4  54972      0t0  TCP *:http (LISTEN)

界面配置

**Web：**访问：192.168.56.11

image-20211101094552276

**提示：**启动gitlab需要时间！

Web页面提示我们需要设置一个账号密码（我们要设置最少8位数的一个账号密码）我们设置密码为：12345678

我们在后面的页面设置用户名

image-20211101094608325

我们现在是以管理员的身份登陆

image-20211101094625281

关闭注册

我们点击右上角管理区域

**第一步：**我们关闭自动注册，因为我们内部使用不需要用户自己注册，由运维分配用户即可

image-20211101094644980

提示：Save在页面最下放！！！！！！ 记得点保存！！！！！！！！！！！！

image-20211101094659456

现在在查看首页就没有注册页面了

创建用户组（项目）

**第二步：**我们创建一个用户，在创建一个项目

先创建一个组

image-20211101094721159

**提示：**gitlab上面有一个项目跟组的概念，我们要创建一个组，才可以在创建一个项目。因为gitlab的路径上首先是ip地址，其次是组

image-20211101094738838

点击下方Create group

image-20211101094751610

创建仓库

然后我们在组里面创建项目

image-20211101094809402

下一步：

image-20211101094822041

image-20211101094830096

创建完成之后它提示我们可以创建一个key对它进行管理

我们点击上面的README然后我们随便在里面写点东西

image-20211101094845726

image-20211101094856665

填写完成我们点击前面进行查看

我们要做免密验证，现在去192.168.56.11复制下面的.ssh/id_rsa.pub

[www@linux-node1 ~]$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8wfTSQcSyhlsGYDSUtuxZNb1Gl3VU56nAPuxAEF2wP2ZWZ2yva354ZdKOOb6rZx2yZxqy5XIj7opBJPbhraXap+NtCH5qWyktR7dH19RBmCS7vUGgvk/5RQC0mVFrC8cztBp0M/5HxMuhVir6mD1rhbDvvaLL6S5y4gljzC1Gr2VRHIb4Et9go/38c2tqMjYCike7WWbFRyL9wTal6/146+9uREZ/r69TBTKrGuRqF44fROQP8/ly02XFjlXyl6J5NnGTk6AU855pwasX0W9aNPce3Ynrpe1TBTubmfQhrH1BwteEmg+ZXNRupxjumA+tPWfBUX+u51r/w7W/d4PD www@linux-node1

#提示：需要提前做秘钥认证

image-20211101095132101

设置Keys

image-20211101095150312

image-20211101095158555

添加完之后我们就可以使用www用户，就可以拉了

image-20211101095212520

拉取代码

点击Projects 选择SSH，我们要将代码拉去下来

[www@linux-node1 ~]$ cd /deploy/code/
[www@linux-node1 code]$ ls
web-demo
[www@linux-node1 code]$ rm -rf web-demo/
[www@linux-node1 ~]$ git clone  git@linux-node1:web/web-demo.git
Cloning into 'web-demo'...
The authenticity of host 'linux-node1 (192.168.56.11)' can't be established.
ECDSA key fingerprint is b5:74:8f:f1:03:2d:cb:7d:01:28:30:12:34:9c:35:8c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'linux-node1' (ECDSA) to the list of known hosts.
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
[www@linux-node1 ~]$ ls web-demo/
README.md

#git clone是克隆的意思

提交代码

我们来模拟开发继续写代码提交

[www@linux-node1 ~]$ mkdir -p /web-demo
[www@linux-node1 ~]$ vim web-demo/index.html
[www@linux-node1 ~]$ cd web-demo/
[www@linux-node1 web-demo]$
[www@linux-node1 web-demo]$ ls
index.html  README.md
[www@linux-node1 web-demo]$ git add *
[www@linux-node1 web-demo]$ git commit -m "add index.html"

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for ) not allowed

需要身份验证：

[www@linux-node1 web-demo]$ git config --global user.email "you@example.com"
[www@linux-node1 web-demo]$   git config --global user.name "Your Name"
[www@linux-node1 web-demo]$ git commit -m "add index.html"
[master be8a547] add index.html
 1 file changed, 169 insertions(+)
 create mode 100644 index.html

git push命令用于将本地分支的更新，推送到远程主机。它的格式与git pull命令相仿。

[www@linux-node1 web-demo]$ git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default simple

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 7.66 KiB | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@linux-node1:web/web-demo.git
   0c1d357..be8a547  master -> master

我们的gitlab安装在opt/gitlab

gitlab配置文件存放在etc/gitlab/gitlab.rb

image-20211101095434253

#现在git 需要加上主机名，我们可以修改配置文件，让它使用IP进行访问

编辑配置文件

[root@linux-node1 ~]# vim /etc/gitlab/gitlab.rb
external_url 'http://192.168.56.11'


[root@linux-node1 ~]# gitlab-ctl reconfigure
#提示：修改完需要使用reconfigure重载配置才会生效

我们从新登陆进行查看

image-20211101095456814

​ 咦！ 为啥还没改呢！ 我们从新创建一个项目在试一下

image-20211101095512253

友情提示：

关于Git可以查看徐布斯博客 or 廖雪峰Git

Gitlab备份、迁移、恢复和升级

自建的Gitlab服务器常常会因为使用时间的增长，其空间容量等硬件需求都需要升级，或者迁移至更高配置的服务器上。备份、迁移、恢复、升级过程如下

gitlab备份

备份前gitlab的项目如图所示

image-20211101154628984

备份时需要保持gitlab处于正常运行状态，直接执行gitlab-rake gitlab:backup:create进行备份

使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1530156812_2018_06_28_10.8.4_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1530156812_2018_06_28_10.8.4是备份创建的日期

​ image-20211101154646819

/etc/gitlab/gitlab.rb 配置文件须备份

/var/opt/gitlab/nginx/conf nginx配置文件

/etc/postfix/main.cfpostfix 邮件配置备份

1.1 修改备份文件目录

可以通过/etc/gitlab/gitlab.rb配置文件来修改默认存放备份文件的目录
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
修改完成之后使用gitlab-ctl reconfigure命令重载配置文件即可

1.2 设置备份过期时间

[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
gitlab_rails['backup_keep_time'] = 604800        #以秒为单位

1.3 gitlab自动备份

[root@gitlab ~]# crontab -e
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create

gitlab迁移

迁移的整体思路是：

1、在新服务器上安装相同版本的gitlab

2、将备份生成的备份文件发送到新服务器的相同目录下

这里在10.0.0.6的机器上安装了相同版本的gitlab并能正常运行使用

image-20211101154759900

在老服务器上将备份文件发送至新服务器的相应目录下

[root@gitlab ~]# scp /var/opt/gitlab/backups/1530156812_2018_06_28_10.8.4_gitlab_backup.tar root@10.0.0.6:/var/opt/gitlab/backups/

gitlab恢复

[root@gitlab ~]# gitlab-ctl stop unicorn        #停止相关数据连接服务

[root@gitlab ~]# gitlab-ctl stop sidekiq

[root@gitlab-new ~]# chmod 777 /var/opt/gitlab/backups/1530156812_2018_06_28_10.8.4_gitlab_backup.tar

#修改权限，如果是从本服务器恢复可以不修改

[root@gitlab ~]# gitlab-rake gitlab:backup:restore BACKUP=1530156812_2018_06_28_10.8.4    

#从1530156812_2018_06_28_10.8.4编号备份中恢复

按照提示输入两次yes并回车

image-20211101154843220

[root@gitlab ~]# gitlab-ctl start        #启动gitlab

浏览器访问新服务器的地址进行查看，迁移成功

在实际情况中访问gitlab可能是用域名访问，我们可以修改gitlab配置文件中的url再进行备份，这样就不会影响迁移过程，恢复完成后需要进行的只是修改域名对应的dns解析ip地址

gitlab升级

[root@gitlab ~]# gitlab-ctl stop        #关闭gitlab服务

[root@gitlab ~]# gitlab-rake gitlab:backup:create        #备份

下载新版gitlab的rpm包安装，安装时选择升级

安装的过程中可能会出现报错

Error executing action `run` on resource 'ruby_block[directory resource: /var/opt/gitlab/git-data/repositories]'

解决方法为

[root@gitlab ~]# chmod 2770 /var/opt/gitlab/git-data/repositories

安装成功后重新加载配置并启动

[root@gitlab ~]# gitlab-ctl reconfigure

[root@gitlab ~]# gitlab-ctl restart

gitlab更改默认的nginx

[root@gitlab ~]# vim /etc/gitlab/gitlab.rb

nginx['enable'] = false        #不启用nginx

检查默认nginx配置文件，并迁移至新Nginx服务

/var/opt/gitlab/nginx/conf/nginx.conf #nginx配置文件,包含gitlab-http.conf文件

/var/opt/gitlab/nginx/conf/gitlab-http.conf #gitlab核心nginx配置文件

重启 nginx、gitlab服务

[root@gitlab ~]# gitlab-ctl restart

[root@gitlab ~]# systemctl restart nginx.service

访问可能出现报502。原因是nginx用户无法访问gitlab用户的socket文件。 重启gitlab需要重新授权

[root@gitlab ~]# chmod -R o+x /var/opt/gitlab/gitlab-rails

Gitlab CICD

GitLab CI/CD 介绍

软件开发的持续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。

它涉及到在每次小的迭代中就不断地构建、测试和部署代码更改，从而减少了基于已经存在bug或失败的先前版本开发新代码的机会。

Continuous Integration（持续集成）

假设一个应用程序，其代码存储在GitLab的Git仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送，你都可以创建一组脚本来自动构建和测试你的应用程序，从而减少了向应用程序引入错误的机会。这种做法称为持续集成，对于提交给应用程序（甚至是开发分支）的每项更改，它都会自动连续进行构建和测试，以确保所引入的更改通过你为应用程序建立的所有测试，准则和代码合规性标准。

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，还可以显示执行期间发生的情况，正如你在终端看到的那样：

image-20211101114918511

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

image-20211101114930274

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

image-20211101114940797

基本 CI/CD 工作流程

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

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

通过GitLab UI所有的步骤都是可视化的

image-20211101115020748

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

如果我们深入研究基本工作流程，则可以在DevOps生命周期的每个阶段看到GitLab中可用的功能，如下图所示：

874963-20200203191024392-1340530589

\1. Verify

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

\2. Package

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

\3. 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-runner

# Linux x86-64
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Linux x86
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

# Linux arm
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm

**备注：**使用 sudo uname --m 命令可以查看 Linux 系统的位数。

给予相应权限

sudo chmod +x /usr/local/bin/gitlab-runner

新建一个用户

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

一般来说，我们已经有一些用户了，这一步是可以选择 跳过 的。

但是要注意的是这个用户必须得拥有各命令执行的权限。不然执行过程中会因为一些权限问题导致失败。

安装并运行

sudo gitlab-runner install --user=afei --working-directory=/home/afei/gitlab-runner
sudo gitlab-runner start

注意：

--user 指定为自己的用户，用户在 /home 目录下，既可以选择一个已有用户，也可以选择使用上一步新建的用户

--working-directory 执行工作目录，注意应该选择一个该用户有相关权限的目录

安装后想修改怎么办

修改这个文件即可：/etc/systemd/system/gitlab-runner.service

注册 Runner 步骤

官方介绍链接：https://docs.gitlab.com/runner/register/index.html

示例图片

image-20211101115546702

开始注册

sudo gitlab-runner register

输入你的 GitLab 的 url

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
http://gitlab.sz.sensetime.com/ # 参考上图图解

输入 Token

Please enter the gitlab-ci token for this runner
XbWcqKzG8wMmy4H2PLcX # 参考上图图解

输入这个 Runner 的描述

Please enter the gitlab-ci description for this runner
[hostame] my-runner

输入这个 Runner 的 Tabs，每个 tab 使用英文逗号隔开

Please enter the gitlab-ci tags for this runner (comma separated):
my-tag,another-tag

选择执行方式

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
shell

这里根据自己的实际需要选择把，我选的是 shell。

编写和运行 CI

这里举个简单的例子，帮助大家熟悉一下 CI 的配置和运作。

CI 的语法为 yaml，这里不做解释，仅作为扩展介绍流程。

新建 .gitlab-ci.yml 文件

image-20211101115727011

输入执行脚本

点击上面那个 "Set up CI" 就行。例如输入：

build:
  stage: build
  script:
    - ./build_mtee_ca.sh
  tags:
    - ca,faceunlock,ta,tee

然后就是下图所示这样了

image-20211101115753372

开始执行

如果已经存在 ".gitlab-ci.yml" 文件后，当你 push 代码时，CI 就已经会自动执行了，执行的结果在

image-20211101115815919

你还可以通过点击 failed 弹到下面这个页面，查看具体失败原因

image-20211101115829067

这个错误原因就只是 Runner 指定的用户没有操作指定工作区间文件的相应权限，所以在注册 Runner 的时候一定要注意用户和权限的问题。

指定执行任务

我们也可以指定在一些固定时间自动执行 CI，例如 4:00am，或者每个月的第一天。如下：

image-20211101115856865

点击 New schedule 后有如此页面：

image-20211101115911125

选择你需要的配置即可。

如何设置仅master更新才出发CI

stages:
  - push-yum

push-yum:
  stage: push-yum
  script:
  - echo "Running tests"
  - pwd
  - hostname
  - whoami
  only:
  - master
  tags:
  - os-deploy