GitLab-CI之GitLab Runner

本文解析了GitLab CI的工作流程,包括调度机制、Executor的实现方式,以及如何利用Kubernetes动态创建Pod来执行构建任务。介绍了Pod的组成结构及其各容器的作用,最后概述了Job构建过程的四个阶段。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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 CI构建过程。
且此Pod除了包含固有的Infra Container外,还一定会包含Build Container和Help Container,另外,可能包含Service Container。简单而言,Build Container用于执行.gitlab-ci.yml文件中在stage标签中定义的脚本。Help Container则用于辅助Build Container的执行构建工作,具体是负责git和certificate store相关的操作。最后Service Container的用途则对应着.gitlab-ci.yml文件中定义的service标签,即一个辅助容器,为Build Container提供服务,其基本实现原理是Docker Link。
最后,每一个Job都会包含四个阶段(Job构建过程的生命周期):Prepare、Pre-Build、Build和Post-Build。这几个阶段的具体作用,我在这里就不阐述了,比较简单,也可以在源码中找到。

### Helm安装GitLab Runner时的报错问题及重新部署方法 在使用Helm安装GitLab Runner时,如果遇到报错问题,可以按照以下方式排查和重新部署。首先,确保删除之前失败的安装记录,并清理相关资源。然后根据需求重新配置并部署GitLab Runner。 #### 1. 删除失败的安装记录 使用以下命令删除失败的Helm释放(release): ```bash helm uninstall gitlab-runner -n gitlab-runner ``` 此命令会删除与`gitlab-runner`相关的所有Kubernetes资源[^1]。 #### 2. 清理残留资源 有时即使删除了Helm释放,仍然可能有残留的Kubernetes资源存在。可以通过以下命令检查并手动清理: ```bash kubectl get all -n gitlab-runner ``` 如果发现仍有资源存在,可以逐个删除它们: ```bash kubectl delete pod <pod-name> -n gitlab-runner kubectl delete svc <service-name> -n gitlab-runner ``` 此外,还需检查是否有ConfigMap或Secret残留: ```bash kubectl get configmap -n gitlab-runner kubectl get secret -n gitlab-runner ``` 若有残留,同样需要手动删除。 #### 3. 重新部署GitLab Runner 在确保环境清理干净后,可以重新部署GitLab Runner。以下是完整的Helm安装命令示例: ```bash helm install gitlab-runner \ --namespace=gitlab-runner \ --create-namespace \ --set gitlabUrl=https://gitlab.example.com \ --set runnerToken=glrt-p3LfPnBwy6pdVjnj1Mmx \ --set certsSecretName=gitlab-runner-certs \ --set rbac.create=true \ --set rbac.clusterWideAccess=true \ gitlab/gitlab-runner ``` 在此过程中,确保提供的参数(如`gitlabUrl`和`runnerToken`)正确无误。 #### 4. 添加污点容忍配置(可选) 如果需要将GitLab Runner调度到特定节点,可以为节点添加污点,并修改ConfigMap以包含污点容忍配置: ```bash kubectl taint node node1 runner=gitlab-runner-only:NoSchedule ``` 随后编辑ConfigMap文件,添加如下内容: ```toml [runners.kubernetes.node_tolerations] "runner=gitlab-runner-only" = "NoSchedule" ``` 保存后应用更改[^3]。 #### 5. 验证部署 使用以下命令验证GitLab Runner是否成功部署: ```bash kubectl get pods -n gitlab-runner ``` 如果Pod状态为`Running`,说明部署成功[^4]。 #### 6. 调试常见问题 如果再次遇到报错,可以使用以下命令查看详细错误信息: ```bash kubectl describe pod <pod-name> -n gitlab-runner ``` 或者查看Pod日志: ```bash kubectl logs <pod-name> -n gitlab-runner ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值