DevOps系列文章之 GitLab Runner

003.Gitlab配置runner gitlab runner是用于执行 gitlab cicd任务的工具,最终执行gitlab cicd任务的组件就是runner。gitlab runner可以部署在Windows、Linux、Kubernetes中,可以通过包管理器、二进制、容器等方式进行部署。gitlab runner将监听gitlab服务器上由项目中的 .gitlab-ci.yml 文件定义的作业。当作业被触发时,gitlab runner将下载代码并执行任务。 阅读详情

Runner

Runner就像一个个的工人,而Gitlab-CI就是这些工人的一个管理中心,所有工人都要在Gitlab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,Gitlab-CI就会通知相应的工人执行软件集成脚本。如下图所示:

gitlab里面的runner叫Gitlab-Runner,Gitlab-Runner是配合Gitlab-CI进行使用的。一般地,Gitlab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知Gitlab-CI。这时Gitlab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本(也就是在Job执行流程那个图中所示的第三步:script),所以,Gitlab-Runner就是一个用来执行软件集成脚本script的东西。

Runner类型

Gitlab-Runner可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型)。

  • Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
  • Specific Runner:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

什么情况下需要注册Shared Runner?

  1. 比如,GitLab上面所有的工程都有可能需要在公司的服务器上进行编译、测试、部署等工作,这个时候注册一个Shared Runner供所有工程使用就很合适。

什么情况下需要注册Specific Runner?

  1. 比如,我可能需要在我个人的电脑或者服务器上自动构建我参与的某个工程,这个时候注册一个Specific Runner就很合适。

Runner搭建

1、linux操作系统,安装docker环境。(如果安装了devops,docker环境可以不用安装)

2、安装gitlab-runner

1. Runner 安装

在GitLab Runner 10之前,gitlab-runner的名称叫gitlab-ci-multi-runner,安装命令如下

# For Debian/Ubuntu
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-ci-multi-runner

# For RHEL/CentOS
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
sudo apt-get install gitlab-ci-multi-runner

在GitLab Runner 10及其以上,可执行文件已重命名为gitlab-runner。

linux系统,可以通过以下命令安装

# For Debian/Ubuntu/Mint
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-runner

# For RHEL/CentOS/Fedora
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

如果要安装特定版本的GitLab Runner:

# for DEB based systems
apt-cache madison gitlab-runner
export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E apt-get install gitlab-runner=10.0.0

# for RPM based systems
yum list gitlab-runner --showduplicates | sort -r
export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E yum install gitlab-runner-10.0.0-1

授予其执行权限:

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

创建一个GitLab CI用户:

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

1.解决gitlab-runner执行docker命令提示权限不足的问题
将gitlab-runner用户添加到docker组
sudo usermod -aG docker gitlab-runner
验证是否生效:
sudo -u gitlab-runner -H docker info
2.给gitlab-runner sudo权限
sudo vi /etc/sudoers
在root ALL=(ALL:ALL) ALL下增加gitlab-runner ALL=(ALL) NOPASSWD: ALL

2. 获取Runner注册Token

安装好Runner之后,需要向Gitlab进行注册,注册Runner需要GitLab-CI的url和token。可根据需求注册选择所需类型Runner。这里介绍spercific runners为例

在这里插入图片描述

图中的Url和Token是runner链接到仓库的两个重要参数

3.runner配置

执行注册runner的命令(如果你是安装的gitlab-ci-multi-runner):sudo gitlab-ci-multi-runner register

执行注册runner的命令(如果你是安装的gitlab-runner):sudo gitlab-runner register

接下来会提示你输入一系列配置内容

注意,在要求输入tag时,想好tag的名字,这个就相当于你的runner的id

## 输入url
a、Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
 
## 输入token
b、Please enter the gitlab-ci token for this runner
 
## 写个描述
c、Please enter the gitlab-ci description for this runner
 
## 这个tag很重要,好好想个名字并记住,随后在ci配置中需要对应上。
d、Please enter the gitlab-ci tags for this runner (comma separated)
 
## ci没有配置tags时是否执行这个runner?建议采用默认值。            
e、Whether to run untagged builds [true/false]
 
## 是否只对当前工程有效?理论上讲只有“Shared runners”才有效。选true。            
f、Whether to lock Runner to current project [true/false]
 
## 选择一个执行器。我们接来下的方案是基于shell的,输入shell。    
g、Please enter the executor: virtualbox, docker+machine, kubernetes, parallels, docker-ssh, shell, ssh, docker-ssh+machine, docker:

注册完成后,会出现一个runner,我这里注册了两个,所以会有两个tag

runner 左边会有一个小绿点,表示该runner是能正常执行的

Gitlab-runner的配置

GitLab-CI会为这个Runner生成一个唯一的token,以后Runner就通过这个token与GitLab-CI进行通信。

那么,问题来了。注册好了的Runner的信息存放在哪儿了呢?

原来,Runner的信息是存放在一个配置文件里面的,配置文件的格式一般是.toml。这个配置文件的存放位置有以下几种情况:

  • 在类Unix操作系统下(0.5.0之后版本)
    • 如果是以root用户身份运行gitlab-runner register,那么配置文件默认是/etc/gitlab-runner/config.toml
    • 如果是以非root用户身份运行gitlab-runner register,那么配置文件默认是~/.gitlab-runner/config.toml
  • 在其他操作系统下以及0.5.0之前版本

配置文件默认在当前工作目录下./config.toml

一般情况下,使用默认的配置文件存放Runner的配置信息就可以了。当然,如果你有更细化的分类需求,你也可以在注册的时候通过-c或--config选项指定配置文件的位置。具体查看register命令的使用方法:gitlab-runner register --help。

问题:如果不运行gitlab-runner register命令,直接在配置文件里面添加Runner的配置信息可以吗?

回答:当然不可以。因为gitlab-ci-runner register的作用除了把Runner的信息保存到配置文件以外,还有一个很重要的作用,那就是向GitLab-CI发出请求,在GitLab-CI中登记这个Runner的信息并且获取后续通信所需要的token。

让注册好的Runner运行起来

Runner注册完成之后还不行,还必须让它运行起来,否则它无法接收到GitLab-CI的通知并且执行软件集成脚本。怎么让Runner运行起来呢?gitlab-runner提供了这样一条命令gitlab-runner run-single

以上的就是在linux机器上直接安装runner的过程,关于gitlab ci怎么使用runner执行我们想要执行的任务,可参考这篇文章:

【云原生】DevOps之使用Gitlab Runner进行CICD 在很久之前的文章中,我们已经搭建过了Jenkins+Docker+Harbor+SpringCloud微服务持续集成自动化部署,今天来介绍Gitlab原生的Gitlab Runner CICD功能。Gitlab实现CICD的方式有很多,比如通过Jenkins,通过Gitlab Runner等,今天主要介绍后者。Gitlab在安装的时候,就默认包含了Gitlab CI的能力,但是该能力只是用于协调作业,并不能真的去执行作业,因此需要搭配Gitlab Runner来作为执行器实现具体的CICD工作。 阅读详情

相关推荐

gitlab-runner使用kubernetes executor

记录一下使用gitlab-runner通过k8s作为executor来进行cicd的一个过程。 包括但不限于: gitlab-runner部署到k8s的deployment.yml,以及一些configmap和serviceaccount gitlab-runner使用的config.toml,定义executor=k8s 项目根目录的.gitlab-ci.yml文件。定义整个cicd的流程。 另外简单提供了一下dind方案,以及业务镜像部署到k8s的方案。

IT老吴的博客 3974

Gitlab-Runner原理与实现

应用场景: 通过技术手段保证gitlab中项目某个版本的可用性,当我想发布新版本时随实可以tag出一个可用的版本。与github配套的是travis,使用非常简单,只需要将github账户与travis绑定就可以选择保护的项目及版本,但是要在gitlab上实现类似的功能就只能靠自己来搭建了,今天就来介绍下gitlab-runner是如何工作的。   Gitlab/GitHub使用规范 示意...

咖啡男孩之SRE之路 2万+

什么是devops,基于Gitlab从零开始搭建自己的持续集成流水线(Pipeline)

持续集成 devops pipeline CI/CD Gitlab 运维

Chengzi_comm的专栏 3万+

GitLab-CI之GitLab Runner

gitlab-ci工作流程图: 调度机制: A:打上tag标签,就会调度到指定节点 B:未打上标签,会有公平调度算法 Executor Docker 将Executor连接到Docker Daemon,并在一个单独容器中跑每一次的构建过程,并使用在.gitlab-ci.yml文件中定义的镜像,Docker Executor具体是通过config.toml文件来配置的。 Kuberentes 让Runner连接到连Kubernetes API Server,为每一个Job动态创建一个Pod来执行GitLab

qq_42997214的博客 1137

使用jenkins和gitlab-runner DevOps CICD - 制作docker镜像并推送到阿里云镜像仓库

前言 DevOps( Development和Operations的组合词 )的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发,DevOps 使一切成为可能。有了 DevOps,团队可以定期发布代码、自动化部署、并将持续集成( CI ) / 持续交付( CD )作为发布过程的一部分。说到 CICD 比较出名的有 jenkins 和 gitlab-runner 、circle.ci 和travis.ci等等,大家可以自行百度或者找相关文章看看这几个的区别,这里就不详细讲了。 Jenk

weixin_43207262的博客 1335

GitLab 运行GitLab-Runner CI/CD发布

本文主要演示使用A推送项目到 B上,和注册GitLab Runner,添加docker类型的Executor来执行构建,并以此为基础完成一个go源码示例项目从编译构建、镜像打包到应用部署的CICD过程。 A:192.168.10.12 B:192.168.10.19 端口2375 Gitlab ip:192.168.10.9 一、在192.168.10.12上使用docker安装gitlab-runner [root@adscom gitlab]# mkdir -p /config #创建配置目录 [r

clover661的博客 1847

DevOps系列文章之 GitLab Runner续

当Project更新,触发Runner服务器上的Runner Service(某管理队伍),Runner Service根据自己的配置信息,和项目的需求(tag指定某个工人),派遣Runner工人去执行Project给予的任务(Job)。1)好处:对于大多数Runner的配置其实是完全相同的(同样的executor,同样的配置文件和工作路径,同样的依赖环境),如果每个项目都去一个个注册不仅麻烦,而且不方便迁移,这时可以使用shared runner。尤其是使用Docker镜像时,必须加入docker组。

Coder_Boy_的博客 1805

前端devops——利用gitlab实现CI/CD自动化部署

Git是一个用于代码的存储和版本控制开源的分布式版本控制系统。GitLab 则是一个用于仓库管理系统的开源项目。本篇文章将讲解如何用gitlab搭建一个私有化的代码管理平台,并实现CI/CD自动化部署。由于条件限制,本篇的所有操作都在windows下执行,并使用docker进行操作。

小敏哥的专栏 6587

DevOps系列文章之 GitLab CI/CD

gitlab-ci.yml 文件被用来管理项目的 runner 任务,Gitlab CI通过.gitlab-ci.yml文件管理配置job,该文件定义了statge顺序、job应该如何触发和工作、执行什么脚本、如何构建pipeline等流程该文件存放于仓库的根目录, 默认名为我们先看一个简单的例子:.gitlab-ci.yml## 定义pipeline流程:verify->build->dockerpush->deploystages:- verify- build- deploy#单元测试。

Coder_Boy_的博客 1638

Auto DevOps之gitlab CI/CD

文章目录CI/CD介绍CI/CD的工作流程ci整体原理安装gitlab runner编写.gitlab-ci.yml关于更优雅的达成目标 CI/CD介绍 CI(Continuous Integration)跟CD(Continuous Delivery/Continuous Deployment)的出现主要是为了帮助我们在开发时能更早的发现代码中的bug,避免我们在这些bug上进行后续的开发(一错再错-.-),甚至将这些bug合并到qa或者staging环境去(错上加错)。 说人话就是,我们在提交代码到gi

scientificCommunity的博客 1545

GitLab Runner执行流程 runner-execution-flow

详细讲解GitLab,GitLab Runner ,执行器之间的数据流转。

知无涯 1万+

使用 Operator 创建 GitLab Runner

如何使用 Opeartor 创建极狐GitLab Runner?

GitLab 中国发行版 766

gitlab runner 安装、注册、配置、使用(Docker部署)

Gitlab Runner作为一个开源的项目,使用Go语言编写,可运行在不同系统重Gitlab Runner用于运行作业并将结果发给gitlab服务器Gitlab Runner与Gitlab CI结合使用,Gitlab CI是gitlab的开源持续集成服务,用于协调作业Gitlab Runner的版本安装时应注意与Gitlab版本尽量同步以防版本差异导致报错。

感谢阅读 1万+

windows安装gitlab_GitLab Runner安装注册配置管理

本文是《GitLabCI实践》教程部分内容,点击上面图片获取免费公开课报名链接,欢迎报名学习!部分观点仅供参考。GitLab Runner是一个开源项目,用于运行您的作业并将结果发送回GitLab。它与GitLab CI结合使用,GitLab CI是GitLab随附的用于协调作业的开源持续集成服务。安装要求GitLab Runner是用Go编写的,可以作为一个二进制文件运行,不需要特定于...

weixin_39884412的博客 2355

GitLab CI/CD实践之GitLab Runner

核心: (1)GitLab Runner是CI/CD执行器,执行.gitlab-ci.yml脚本; (2)GitLab Runner有多种执行引擎,如Shell、Docker等; (3)一个Gitlab仓库可以有多个GitLab Runner,在.gitlab-ci.yml中通过tags指定Runner; (4)向GitLab注册GitLab Runner,需要指定标签,并且可以自定义文件挂载。

天然玩家的博客 1427

VECTOR硬件VN1600系列对比:VN1610、VN1611、VN1630A、VN1640A、VN1630log、VN1670

VN16系列说不清道不明的区别和关系

AmorRun的博客 2万+

DevOps系列GitLab-CICD(二)之安装git-runner-rpm安装方式

目录背景介绍安装系统`下载`gitlab-runner rpm包`安装`gitlab-runner`启动`gitlab-runner`注册`gitlab简单使用模拟测试真实案例 背景 本节是继DevOps实例演示的第三篇文章, 在上一篇文章中, 我们已经成功安装部署了GitLab可以方便的对我们的Git仓库进行管理了,但是要实现我们的需求,仅仅安装GitLab还不行, 还需要安装一个插件Git......

GQ_YIN日常记录 1741

【可信数据空间-连接器技术架构设计方案】

一句话概括连接器是可信数据空间的“数据保镖”和“外交官”。连接器就是一个部署在你本地的软件代理,它代表你安全地对外提供数据服务,确保在共享数据价值的同时,牢牢守住数据的所有权和控制权。它是实现“数据可用不可见”这一理想的关键技术部件。一个生动的比喻:银行的金库和接待员想象一下,你的数据就是藏在银行金库里的黄金和钞票。金库(你的内部数据库): 绝对安全,外人绝对不能进。接待员(连接器): 坐在银行大厅里,负责与客户打交道。客户向接待员提出请求:“我想取1000元。

u014716614的博客 2267

DevOps系列GitLab-CICD(三)之安装git-runner-docker安装方式

目录背景介绍/区别安装系统安装DockerDocker版本启动gitlab-runner注册(配置和参考上一篇)查看是否已经注册完成 背景 本节是继DevOps实例演示的第四篇文章, 在上一篇文章中, 我们已经成功安装部署了GitLab 并且安装了GitLab-Runner,初步完成了我们的DevOps的第一步需求, 本篇文章目的在于再向大家介绍一种git-runner的安装, 在阅读本篇前,...

GQ_YIN日常记录 983

InVEST模型 | HAbitat quality模块计算生境质量

 本文详细介绍使用InVEST模型中HAbitat quality模块计算生境质量,包含各个参数的含义、所需数据、数据处理以及需要各个参数注意的地方等过程。

地理空间科学的博客 1万+

把 SAP Query 用到极致:ABAP Query 的核心概念、配置流程、权限与运输治理全解析

摘要:SAP Query 是一款面向业务用户的自助报表工具,可解决标准报表无法满足业务需求的问题。其核心由四大组件构成:Queries(报表定义)、InfoSets(数据视图)、User Groups(权限分组)和Translation(多语言支持)。通过SQ03、SQ02、SQ01事务码分步创建用户组、数据视图和查询,业务用户无需ABAP知识即可生成Basic List(明细)、Statistics(统计)和Ranked List(排名)三种报表形式。典型案例展示了如何为采购部门设计包含明细追溯和Top1

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 179

DevOps系列文章 之 SpringBoot整合GitLab-CI实现持续集成

CI/CD属于DevOps,代表持续集成、持续交付/部署。CI/CD 自动化了传统上将新代码从提交到生产(例如构建、测试和部署)以及基础设施配置所需的大部分或全部手动人工干预。借助 CI/CD ,开发人员可以对代码进行更改,然后自动测试并推出以进行交付和部署。以实现停机时间最小化,代码发布速度更快。

Coder_Boy_的博客 1798

一句话看懂 vibing-steampunk

摘要: vibing-steampunk(vsp)是一个连接SAP ABAP开发工具(ADT)与AI编码代理(如Claude、GitHub Copilot)的桥梁,通过MCP协议实现自动化代码读写、调试和部署。它利用ADT API直接访问SAP系统,绕过传统GUI操作,支持ECC和S/4HANA等环境。工具提供包分析、依赖检查、LUW行为识别等功能,显著提升ABAP项目维护效率。其创新Hyperfocused模式和方法级编辑大幅降低token消耗,而上下文压缩技术则优化了AI对ABAP代码的理解能力,特别适

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 114
上一篇: DevOps系列文章之 GitLab CI/CD
下一篇: DevOps系列文章之 GitLab Runner续
Coder_Boy_
博客等级 码龄10年 2804粉丝 819原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Coder_Boy_

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值