Gitlab CI/CD， 钩子

Part One: GitLab CI/CD

CI:持续集成，对每次提交，合并代码时触发流水线，进行一次验证，及时发现问题（如检查代码是否包含错误，项目是否编译通过）。
CD：持续部署/持续交付，方便及时测试。
持续交付指的是在持续集成的环境基础之上，将代码部署到预生产环境。
持续交付：代码开发--》单元测试--》合并代码--》测试人员功能/黑盒测试--》运维人员手动点击部署按钮--》部署到生产

GitLab CI/CD优势：
开源：CI/CD是开源GitLab社区版和专有GitLab企业版的一部分。
多平台：Unix, Windows, macOS和其他任何支持Go的平台上执行构建。
稳定构建：构建与GitLab不同的机器上运行。

GitLab Runner:
是一个处理构建的应用程序。
可以单独部署，并通过API与GitLab CI/CD一起使用。

.gitlab-ci.yml:
pipeline脚本文件，根据文件定义的内容去运行的。

GitLab CI/CD原理：
1、将代码托管到GitLab存储库；
2、在项目根目录创建CI文件 .gitlab-ci.yml（每个分支可定制），在文件中指定运行步骤(称为Jobs)--构建(build)，测试(test)和部署(depoly)脚本；
3、GitLab将检测到它并使用GitLab Runner工具运行脚本；
当提交代码时，GitLab会去检测分支有没有这个文件，这个文件有没有定义使用某个runner, 如果有就按照文件中的步骤运行runner。
4、脚本被分组为作业，它们共同组成了一个管道（pipeline）。

Part TWO: GitLab CI与 jenkins CI对比

1、GitLab8.0以下无CI，传统方式通过GitLab + python脚本 + Jenkins实现CI/CD，GitLab8以后可通过.gitlab-ci.yml取代脚本，GitLab Runner（Go语言写的）取代Jenkins（Java写的）。
2、定时构建：例如，常规的夜间定时构建与发布。
Jenkins 2可以立即使用，以cron式语法定义。GitLab CI没有此功能，但是可通过一种变通办法来实现：通过WebAPI使用同一台或另一台服务器上的cronjob触发作业和管道。
3、权限管理：GitLab可与版本管理一起管理，Jenkins很难管理。
4、插件管理：扩展Jenkins插件的维护、保护和升级成本很高。GitLab是开放式的，任何人都可以贡献。
5、GitLab CI有助于DevOps人员，例如敏捷开发中，开发与运维是同一个人，最便捷的开发方式。Jenkins CI适合在多角色团队中，职责分明，配置与代码分离，插件丰富。
6、复杂度：Jenkins CI比GitLab CI复杂很多。

Part THREE: 安装GitLab

安装GitLab三种方式：下载安装 / Docker安装 / K8S安装，不必纠结哪种方式，用起来都是一样的。

Part FOUR：GitLab Runner

GitLab Runner简介：
1、GitLab Runner是一个开源项目，用于运行作业并将结果发送回GitLab；
2、与GitLab CI结合使用，GitLab CI是GitLab随附的用于协调作业的开源持续集成服务；
3、GitLab Runner版本应与GitLab版本同步；
4、可以根据需要配置任意数量的Runner。

基本特点：
同时执行多个作业；
支持Bash，Windows Batch和Windows PowerShell；
自动重新加载配置，无需重启。

GitLab Runner类型与状态：
类型：
shared 共享类型，运行整个平台项目的作业（gitlab)
group 项目组类型，运行特定group下的所有项目的作业（group）
specific 项目类型，运行指定的项目作业（project）
状态：
locked: 锁定状态，无法运行项目作业
paused: 暂停状态，暂时不会接受新的作业

安装GitLab Runner: Linux安装(在清华源下载runner rpm包）或配置yum源安装/ Docker安装

GitLab Runner注册：获取runner token --> 进行注册
三种类型Runner获取token的方式：
shared类型（需要管理员权限）: Overview --> Runners --> Set up a shared Runner manually --> 复制已有token / 重新生成token
group类型 : Settings --> CI/CD --> Runners --> Expand --> Group Runners --> 复制已有token / 重新生成token
specific类型（项目级，需要项目管理权限）: Settings --> CI/CD --> Runners --> Expand --> Specific Runners --> 复制已有token / 重新生成token

进行注册：
运行命令gitlab-runner register, 输入获取token时的URL 和 token, 选择执行器(Shell,Docker,K8S,SSH等)，注册完成。

Part FOUR: 运行流水线任务

项目根目录添加 .gitlab-ci.yml，实现一个流水线(Pipeline)，Pipeline由运行步骤（Jobs）组成。

stages:
  - buildci // 声明运行步骤(Jobs)，按声明顺序执行流水线
  - depolyci // 声明运行步骤(Jobs)
 
build:
  stage: buildci // 定义运行步骤(Job)
  tags: 
    - build // 指定用build Runner去执行
  only: 
    - master
  script:
    - curl http://serverIp:8080/downGitlabCiShApi > gitlab-ci.sh
    - chmod 751 ./gitlab-ci.sh
    - ./gitlab-ci.sh
deploy:
  stage: deployci  // 定义运行步骤(Job) 
  tags: 
    - deploy // 指定用deploy Runner去执行
  only: 
    - master
  script:
    - echo "hello deploy"

每一次Pipeline执行结果都可以在CI/CD --> pipelines查看，可以查看pipeline每个阶段Job的执行结果。

Part FIVE: Pipeline参数有哪些

[script] 运行的Shell命令或脚本。✅
[image] 使用docker映像.
[services] 使用docker服务映像.
[before_script] 在作业运行前运行脚本。 ✅
[after_script] 在作业运行后运行脚本。✅
[stages] 定义管道中的阶段，运行顺序。 ✅
[stage] 为工作定义一个阶段，可选，未指定默认为test阶段。 ✅
[only] 限制创建作业的时间. ✅
......

GITLAB 钩子
目标：gitlab配置webhook钩子，push代码时触发webhook，向node服务器发送任务，node服务器down代码，执行打包和检测，结束后触发gitlab发邮件。

步骤：
1.进入gitlab，找到自己的项目，查看是否有权限设置，然后设置：
(Settings -> Integrations)

URL：http://nodeServerIp:8080/webhook
 Secret Token:  ABCDEFG // 触发请求的认证码，避免DOS攻击
Trigger: 
勾选Push events选项
 勾选Merge request events选项
 
点击“Add web hook”

2.Setting --> General --> Visibility, project features, permissions --> 点击Expand --> 打开Pipelines（Build, test, and deploy your changes）--> Save Changes

3.Settings -> CI /CD --> Pipeline triggers --> Expand
在展开的输入框中输入“ci ”,点击“Add trigger”, 然后将生成的Token字段复制出来。

4.在项目根目录添加.gitlab-ci.yml文件，文件内容如下：

stages:
  - ci

# 定义 job
build:
  stage: ci
  script:
 - curl http://nodeServerIp:8080/downGitlabCiShApi > gitlab-ci.sh
    - chmod 751 ./gitlab-ci.sh
- ./gitlab-ci.sh