GitLab-CI/CD指南

于 2024-08-10 18:54:18 发布
阅读量635 收藏 14
点赞数 22
分类专栏： 杂记 文章标签： gitlab ci/cd
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/puss0/article/details/141094687
版权

由于公司没有运维，写go服务时各个环境编译部署还是略显麻烦，由于代码管理使用的是 gitlab，所以决定使用 gitlab 自带的 CI/CD 来做自动编译和部署，这样每次提交代码以后就可以自动部署到服务器上了。

gitlab 本身只有 CI/CD 的接口，真正执行 CI/CD 任务的是 gilab runner，它负责与 gitlab 通信，接受 CI/CD 任务，并交给 Executor 执行，Executor 有7种类型：

  • Docker
  • Shell
  • Kubernetes
  • SSH
  • VirtualBox
  • Parallels
  • Custom

Executor的类型在注册 Runner 的时候确定，比较常用的是 Docker 和 SSH。GitLab，Runner 和 Executor 之间的关系如下图所示(图片来自GitLab官方文档)。
在这里插入图片描述

安装gitlab-runner

gitlab 的CI/CD 任务是通过 runner 来运行的，runner 也是 go 语言实现的。我们需要单独安装 runner，而且可以在任意位置安装。

runner 有 docker 版和可执行程序版，这里我选择的是可执行程序版，安装方式可以参考官网。

我的服务器是 linux，使用官方提供的脚本安装：

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash

可执行程序名叫 gitlab-runner ，被放在 /usr/bin/ 目录下。

注册runner

runner 需要注册到 gitlab，其实就是把 runner 的信息告诉 gitlab，这样 gitlab 才知道把 CI/CD 任务交给谁运行。

注册 runner 的命令是 gitlab-runner register ，回车后会以交互式的方式注册 runner，其中比较重要的几个参数是：

  • executor：运行流水线的环境，也就是前面说的7种 Executor 类型，我使用本地 shell 运行流水线，所以输入 shell 。

  • url 和 registration-token：runner 和项目是挂钩的，所谓的注册，其实也就是把 runner 和某个项目关联起来。打开项目的 setting→CI/CD，找到 Runners 点击展开，在 Specific runners 栏下面就是我们需要的 url 和 token。如下图所示

    在这里插入图片描述

当然，为每个项目注册一个 runner 也不太合适，我们可以为一个组注册一个 runner，点开某个组，url 和 token 可以在同样的地方找到。这样组内每个项目就都能使用这个 runner 了。此外，也可以给整个 gitlab 注册 runner，但是这需要 root 账号。

另外，同样的 url 和 token 可以注册多个runner，然后通过 tag 来决定项目使用哪个 runner。
注册 runner 和安装 runner 是两个概念，也就是说即便我们只安装了一个 runner，也能注册多个 runner。安装 runner 是下载可执行程序，而注册只是往 gitlab 设置一些配置信息，它和 runner 本身其实没太大关系，注意此时我们的 runner 还没有开始运行。

除了使用交互式注册，还可以使用非交互方式，命令如下：

gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.com/" \
  --registration-token "$PROJECT_REGISTRATION_TOKEN" \
  --executor "shell" \
  --description "share-runner" \
  --maintenance-note "Free-form maintainer notes about this runner" \
  --tag-list "shell,share" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

注意到 --run-untagged 选项，它表示是否运行在没有标签的的分支上运行流水线。如果没有设置这个参数，也可以在 gitlab 页面上设置。就在我们查看 url 和 registration token 的地方，如果 runner 注册成功的话，可以看到下面的信息：

在这里插入图片描述

点击那个铅笔图标，可以设置 runner，在这里我们也可以勾选 run untagged jobs，如下图所示。

在这里插入图片描述

上面我的 runner 前面小圆点是绿色的，那是因为我的 runner 已经运行起来了。

注册完 runner 会生成配置文件 /etc/gitlab-runner/config.toml ，可以打开查看，我们配置的信息都在里面。

启动runner

在启动 runner 之前，我们可以先创建一个专门的用户来运行 runner，比如：

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

这里我们添加的用户叫 gitlab-runner ，你也可以使用被的用户，甚至 root ，或者为了方便部署，使用部署的用户。
然后安装并启动 gitlab 服务：

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

所谓安装就是设置为系统服务，它会在 /etc/systemd/system/ 目录下生成 gitlab-runner.service 文件。
其他命令：

  • gitlab-runner stop 停止 gitlab-runner 服务。
  • gitlab-runner start 启动 gitlab-runner 服务。
  • gitlab-runner restart 重启 gitlab-runner 服务。
  • gitlab-runner status 查看 gitlab-runner 服务状态。
  • gitlab-runner uninstall 卸载 gitlab-runner 服务。
  • gitlab-runner list 列出所有注册的 runner。

编写流水线

我们通过在项目根目录下创建一个叫 .gitlab-ci.yml 的文件来定义流水线，也就是 CI/CD 如何执行。

流水线分为阶段和作业，阶段通过 stages 关键字定义，阶段是作业的容器，每个阶段内可以定义多个作业。阶段之间是串行执行的，阶段内的多个作业是并行执行的。

关于流水线的编写，可以参看官方文档，或者《GitLab CI/CD 从入门到实战》这本书。当然 gitlab 官方也提供了很多示例，各种语言都有，如果不知到如何开始，可以参考官方示例。

基本结构如下：

stages: # 定义阶段
 - test    # 阶段名
 - build   # 阶段名
 - deploy  # 阶段名
 
 unit_test:    # 作业名
	 stage: test # 作业属于 test 阶段
	 script:     # 作业执行的命令
		 - echo "unit test"
		 
compile:        # 作业名
	stage: build  # 作业属于 build 阶段
	script:       # 作业执行的命令
		- echo "build"
		
deploy_test:     # 作业名
	stage: deploy  # 作业属于 deploy 阶段
	secipt:        # 作业执行的命令
		- echo "deploy test"

我用的是 go 语言，使用 shell 运行和部署，只有测试环境和正式环境。

default:
  interruptible: true # 允许打断流水线

variables:
  GOBIN: "/usr/local/go/bin/go"
  GOINSECURE: git.i****d.com
  GOPRIVATE: git.i****d.com
  GOPROXY: https://goproxy.cn,direct

image: golang:latest

stages:
  - test
  - build
  - deploy

format:
  stage: test
  script:
    - echo "单元测试"
    - pwd
    - echo ~
    - echo $CI_COMMIT_BRANCH
    - echo $CI_DEFAULT_BRANCE
    - export GOINSECURE=$GOINSECURE
    - export GOPRIVATE=$GOPRIVATE
    - export GOPROXY=$GOPROXY
    - $GOBIN version
    - $GOBIN mod tidy
    - $GOBIN test -v 2>&1 | go-junit-report -set-exit-code > report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml

compile:
  stage: build
  script:
    - echo "编译"
    - pwd
    - echo ~
    - export GOINSECURE=$GOINSECURE
    - export GOPRIVATE=$GOPRIVATE
    - export GOPROXY=$GOPROXY
    - $GOBIN version
    - $GOBIN mod tidy
    - mkdir -p _build
    - $GOBIN build -o _build/$CI_PROJECT_NAME main.go
  artifacts:
    expire_in: 1 hour
    paths:
      - _build

# 部署生产环境（仅release分支）
deploy_prod:
  stage: deploy
  variables:
    SERVER_IP: "1**.**.**.*"
  script: 
    - echo "部署生产环境"
    - ssh z**j@$SERVER_IP mkdir -p /data/z**j/$CI_PROJECT_NAME # 创建项目文件夹
    - ssh z**j@$SERVER_IP mkdir -p /data/z**j/$CI_PROJECT_NAME/config # 创建配置文件夹
    - ssh z**j@$SERVER_IP "cd /data/z**j/$CI_PROJECT_NAME/ && [ -f run.sh ] && ./run.sh stop || :" # 停止服务
    - scp _build/$CI_PROJECT_NAME z**j@$SERVER_IP:/data/z**j/$CI_PROJECT_NAME/ # 拷贝可执行文件
    - scp run.sh z**j@$SERVER_IP:/data/z**j/$CI_PROJECT_NAME/ # 拷贝run.sh
    - scp config/application.prod.toml z**j@$SERVER_IP:/data/z**j/$CI_PROJECT_NAME/config/application.toml # 拷贝配置文件
    - ssh z**j@$SERVER_IP "cd /data/z**j/$CI_PROJECT_NAME/ && chmod +x run.sh"
    - ssh z**j@$SERVER_IP "cd /data/z**j/$CI_PROJECT_NAME/ && ./run.sh start" # 重启服务
  only:
    - release # 仅release分支部署到生产环境
  environment: production

# 部署测试环境（非main和release分支）
deplog_test:
  stage: deploy
  variables:
    SERVER_IP: "1**.**.**.*"
  script:
    - echo "部署测试环境"
    - ssh z**j@$SERVER_IP mkdir -p /data/z**j/$CI_PROJECT_NAME # 创建项目文件夹
    - ssh z**j@$SERVER_IP mkdir -p /data/z**j/$CI_PROJECT_NAME/config # 创建配置文件夹
    - ssh z**j@$SERVER_IP "cd /data/z**j/$CI_PROJECT_NAME/ && [ -f run.sh ] && ./run.sh stop || :" # 停止服务
    - scp _build/$CI_PROJECT_NAME z**j@$SERVER_IP:/data/z**j/$CI_PROJECT_NAME/ # 拷贝可执行文件
    - scp run.sh z**j@$SERVER_IP:/data/z**j/$CI_PROJECT_NAME/ # 拷贝run.sh
    - scp config/application.test.toml z**j@$SERVER_IP:/data/z**j/$CI_PROJECT_NAME/config/application.toml # 拷贝配置文件
    - ssh z**j@$SERVER_IP "cd /data/z**j/$CI_PROJECT_NAME/ && chmod +x run.sh"
    - ssh z**j@$SERVER_IP "cd /data/z**j/$CI_PROJECT_NAME/ && ./run.sh start" # 重启服务
  except:
    - $CI_DEFAULT_BRANCH
    - release
  environment: test

多环境部署通过不同的分支来实现， .gitlab-ci.yml 中的 environment 关键字只是对部署任务做一个记录和分类，方便管理和查询部署任务，并无实际区分部署环境的功能。

cheniie
关注
  • 22
    点赞
  • 踩
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
GitLab CI/CD 配置指南 .gitlab-ci.yml文件的配置
知无涯
07-19 8124
GitLab的CI/CD 完全是由.gitlab-ci.yml 文件内容决定的 GitLab的CI/CD的具体内容是由.gitlab-ci.yml文件定义的, 一个在GitLab的项目,项目根目录只有有.gitlab-ci.yml文件,并且配置了Runner,那么每次提交代码 都会触发CI的pipline.gitlab-ci.yml文件是告诉GitLab的runner去做什么在每次触发后,runner默认有三个阶段,build,test,deploy,你不必每次编写都使用三个阶段,如果一个阶段没有..
gitLab安装GitLabCI/CD需要的软件（包含maven+git+gitrunner+jdk）
11-21
GitLab CI/CD是GitLab内置的持续集成和持续部署工具，它允许开发者自动化软件开发流程，包括构建、测试和部署。在这个过程中，GitLab Runner是执行这些任务的关键组件。以下将详细介绍安装GitLab CI/CD所需的软件...
持续集成指南：GitLab 的 CI/CD 工具配置与使用
寒冰屋的专栏
10-11 463
写代码这项工作，本质就是将工作自动化，减少手工操作提供效率，因为人的本质都是懒狗，程序员也不能例外，为了各种意义的效率提升（懒），我们需要持续集成工具，将代码测试、编译、发布这些重复性很高的工作，全部变成自动化，减轻工作量，提高效率，解放生产力，为华夏伟大复兴贡献力量
GitLab Runner作为CI/CD
wangqiaowq的博客
07-30 617
CI（）持续集成，CD（）持续部署（也包含了持续交付的意思）。CD 指的是在我们 CI 流程通过之后，将代码自动发布到服务器的过程，这个过程也是自动化的。在开发人员提交代码之后，会触发 gitlab 的 CI 流水线。也就是上图的 CI PIPELINE，也就是中间的部分。在 CI 流水线中，我们可以配置多个任务。比如上图的 build、unit test、integration tests 等，也就是构建、单元测试、集成测试等。在 CI 流水线都通过之后，会触发 CD 流水线。
gitlab ci cd 不完全指南
rubys007的博客
02-02 2878
CI（）持续集成，CD（）持续部署（也包含了持续交付的意思）。lint检查，检查代码是否符合规范自动运行测试，检查代码是否能通过测试这个过程我们可以称之为 CI，也就是持续集成，这个过程是自动化的，也就是说我们不需要手动去执行这些操作，只需要提交代码，这些操作就会自动执行。CD 指的是在我们 CI 流程通过之后，将代码自动发布到服务器的过程，这个过程也是自动化的。在有了前面 CI 的一些操作之后，说明我们的代码是可以安全发布到服务器的，所以就可以进行发布的操作。
Gitlab CI/CD：入门指南
Mr. David 专栏
01-16 579
可以手动创建.gitlab-ci.yml文件，然后编辑内容，也可以借助gitlab提供的模版文件，使用方式是：New File -> Select a template type选择.gitlab-ci.yml即可。先不管这里面做了什么，当我们配置了上述脚本后，GitLab-CI就自动为我们创建好了管线，但此时管线还是处理pending状态，想要GitLab-CI可以工作起来，我们还需要配置GitLab-Runner。YAML文件有两种后缀.yml和.yaml，都可以被解析。
gitlab CI/CD部署
qq_30198507的博客
06-09 132
gitlab CICD部署过程。
GitLab Runner 安装、CI/CD流水线配置指南
算命de博客
06-14 492
通过以上步骤，我们完成了GitLab Runner的安装与配置，并编写了一个示例的GitLab CI/CD流水线配置文件。这样可以实现代码的自动化测试、编译、打包和发布，提高开发效率。希望本指南对您有所帮助。
如何利用Gitlab-ci持续部署到远程机器-详细教程
lili1158的博客
09-22 1246
gitlab配置CICD实践分享，干货满满
git配置、gitLab-ci自动配置、Charles抓包
dingzhaokun的博客
03-27 1754
git配置、gitLab-ci自动部署配置、cors跨域、登录验证码、Charles抓包
Linux中GitLab的代码仓库与CI/CD管理：深度实践指南
最新发布
08-08
Linux是一种开源的、基于Unix的操作系统内核，由林纳斯·托瓦兹（Linus Torvalds）于1991年首次发布。Linux内核是操作系统的核心部分，负责管理系统资源、调度进程、处理硬件设备请求等。Linux内核以其稳定性、安全...
gitlab-ce_7.10.5~omnibus-1_amd64.rar
08-27
GitLab 是一个开源的版本控制系统，它提供了与GitHub 类似的功能，包括代码托管、问题跟踪、持续集成（CI/CD）以及访问控制等。GitLab CE（Community Edition）是其免费版，适合个人和社区使用。"gitlab-ce_7.10.5~...
gitlab-XshellPortable.rar
09-02
GitLab 是一个开源的版本控制系统，它提供了与GitHub类似的特性，包括代码托管、代码审查、问题跟踪、持续集成（CI/CD）等。本压缩包“gitlab-XshellPortable.rar”包含了与GitLab配置相关的文档示例和工具，旨在...
nodejs-ci-cd
02-10
**Node.js CI/CD 实践指南** 在现代软件开发中，持续集成（Continuous Integration, CI）和持续交付（Continuous Deployment, CD）已经成为不可或缺的实践，它们确保代码质量和快速响应变化。Node.js，作为基于...
(a+c)/(b+d)与a/b和c/d的关系
热门推荐
陈戏猿
12-31 1万+
提问：ab\frac{a}{b}ba​ 和 cd\frac{c}{d}dc​ 与 a+cb+d\frac{a+c}{b+d}b+da+c​ 的大小是什么关系？ 要回答这个问题并不困难，即使直觉上不那么强烈，举几个例子总能得出结果，a+cb+d\frac{a+c}{b+d}b+da+c​ 应该落在 ab\frac{a}{b}ba​ 和 cd\frac{c}{d}dc​ 之间。如果它们的大小关系满足一...
如何快速区别odd和even
陈戏猿
02-05 1万+
odd，3个字母，3→奇数； even，4个字母，4→偶数。
为什么网站用域名可以访问，用IP地址就不行
陈戏猿
12-10 1万+
当我们访问某个网站时，通常是用域名去访问，而不用关心IP地址，域名服务会帮助我们通过域名找到IP。然而有一天突然心血来潮，自己拿到了域名对应的IP地址。然后，把域名换成IP地址再访问时却发现访问不了了。 出现这种情况是因为有代理的存在，比如nginx。其实真正的服务并不是起在80端口，往往是一台机器上有很多服务，起在不同的端口，各自拥有不同的域名，但是这些域名都是解析到同一个IP地址的。当请求到达...
如何理解充分条件和必要条件
陈戏猿
01-07 9168
作为九年义务教育的漏网之鱼，相信你多少被 “充分不必要条件” 和 “必要不充分条件” 折磨过。今天我们从一个非专业的角度带你理解必要和充分。 首先还是看下原本的定义。 假设A是条件，B是结论。 1、由A可以推出B，由B可以推出A，则A是B的充要条件(A=B)； 2、由A可以推出B，由B不可以推出A，则A是B的充分不必要条件(A⊆≠B)； 3、由A不可以推出B，由B可以推出A，则A是B的必要不充分条件(B⊆≠A)； 4、由A不可以推出B，由B不可以推出A，则A是B的既不充分也不必要条件(A⊆≠B且B⊆≠A)。
jenkins+gitlab实现CI/CD
05-19
Jenkins和GitLab都是非常流行的开源工具，Jenkins是一个自动化构建工具，而GitLab是一个代码托管和协作平台。使用Jenkins和GitLab可以实现CI/CD（持续集成/持续交付）。 下面是一些基本的步骤： 1. 在GitLab上创建一个新的项目。 2. 在Jenkins中安装GitLab插件。 3. 在Jenkins中创建一个新的任务，选择GitLab项目作为源代码管理器，并指定GitLab访问令牌。 4. 创建一个Jenkinsfile，它将定义Jenkins任务的构建和部署过程。 5. 在Jenkins任务中添加构建步骤，例如编译代码、运行测试等。 6. 在Jenkins任务中添加部署步骤，例如将构建好的代码部署到测试环境或生产环境。 7. 保存并运行Jenkins任务，它将自动从GitLab拉取代码并执行构建和部署过程。 8. 在GitLab中设置Webhooks，以便在代码提交时自动触发Jenkins任务。 这些步骤只是一个简单的指南，实现CI/CD需要更多的细节和配置。但是，使用Jenkins和GitLab可以大大简化软件开发过程，并确保代码的质量和可靠性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值