Gitlab CI实现自动化部署

创建时间: May 21, 2024 11:08 AM
完结: No
更新时间: May 22, 2024 4:46 PM
科目: CI/CD

前言

背景: 我正在开发一个SpringBoot程序，服务器上准备了一个自定义脚本可以进行重启，但我每次更新时，需要基于新内容打包jar， 并上传到服务器部署目录，然后再执行这个重启脚本。总的手动流程就是：本地打包jar， 登录服务器、上传jar、执行重启脚本。这些步骤既定、明确、乏味且重复。Gitlab CI让这个步骤自动化。

正如github上的actions一样，gitlab也提供了一套CI/CD实现。我们可以通过gitlab项目设置中配置好Runner，然后在项目源码的根目录放上一个编辑好的.gitlab-ci.yml文件，就能实现代码提交后，自动触发流程，而流程中可以包括(且不限于)打包编译、部署等。如此，只管提交代码，打包、编译和部署的流程就可以不用费心了。

原理

通过项目根目录的.gitlab-ci.yml gitlab可以构造流水线(pipeline)，以及执行其中的每个job 。那问题是Gitlab是在哪里执行job任务的呢？这个就是Runner , 它可以理解为Gitlab安装在某个服务器上的一个插件，通过这个插件可以调用此服务器的环境和资源从而执行job，而这个服务器可以是自己拥有的任一服务器(只要跟gitlab在网络上是通的即可)。但是这个插件往往需要自己去安装。

步骤

安装Runner

打开gitlab setting中CI/CD 设置：

在服务器上执行好安装和注册命令后，一切正常的话，刷新此页面，可以看到【分配的项目runner】处已经有刚安装好的runner了。、

PS: 关于runner的安装指南，更详细的内容可以参考官网。

配置.gitlab-ci.yml

在项目根目录提供一个.gitlab-ci.yml 文件。例如下面是我的文件:

【说明】 这个配置实现了：在master分支产生提交时，触发此pipeline。此pipeline包含两个job(stages指定的)——build和deploy。build会在runner中执行mvn打包命令生成jar包，deploy会将build产生的jar包通过scp命令拷贝到部署的服务器指定目录上，然后通过ssh执行服务器上指定的shell脚本(shell脚本实现了对此项目的重新部署)。
**【补充】**为了实现scp和ssh远程访问服务器，利用了ssh-agent功能实现免密访问，在before_script部分做了ssh-agent的一些配置。

stages:
  - build
  - deploy

# 使用 workflow 和 rules 来限制整个 pipeline 仅在 master 分支上运行
workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

variables:
  SSH_PRIVATE_KEY: "$SSH_PRIVATE_KEY"  # 从环境变量中获取私钥。在项目设置>CI/CD>变量 里去配置。
  GIT_FETCH_INCLUDE_TAGS: "0"  # GIT操作中禁用浅层克隆

before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client git -y )'
  - eval $(ssh-agent -s) # 执行 ssh-agent -s 命令获取环境变量，并通过 eval 命令将其应用到当前 shell 环境中，从而启动 SSH agent 并设置相应的环境变量，使得后续的 SSH 相关操作能够与 SSH agent 进行通信
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -  # 将私钥添加到 SSH agent
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  - ssh-keyscan 192.168.101.11 >> ~/.ssh/known_hosts
  - chmod 644 ~/.ssh/known_hosts

build:
  stage: build
  script:
    - mvn clean package  # 使用 Maven 进行构建，并生成 Jar 包
  artifacts:
    paths:
      - target/*.jar  # 将构建的 Jar 包作为 artifacts 以便后续任务使用

deploy:
  stage: deploy
  script:
    - scp -r target/*.jar root@192.168.101.11:/usr/local/message-deploy/jar  # 使用 scp 命令将 Jar 包推送到服务器
    - ssh root@192.168.101.11 'cd /usr/local/message-deploy/ && bash rebuildAndReRun.sh'  # 在服务器上执行指定的脚本

PS:

1. 关于.gitlab-ci.yml的配置项说明可以参考官网。
2. 关于.gitlab-ci.yml 语法验证，可以在你项目里的CI/CD里有一个编辑器，可以做语法验证。
3. 上面job中执行的步骤涉及mvn，因此runner所在服务器需要安装并配置好maven，此外git也是必须的(runner需要将代码拉下来)。

提交代码验证

结语

在上面的例子中，创建runner时，终端会有一些交互式选项以供选择。例如runner的执行模式：

• Shell Executor:
• Docker Executor
• Docker Machine Executor
• Kubernetes Executor
• Custom Executor

区别和特点如下：

一般小项目直接用Shell Executor, 上了docker的小项目可以使用Docker Executor，上了Docker的较大规模可以上k8s Executor（不过需要搭建了k8s）。