Kubernetes 上的 GitLab + ArgoCD 实践(二):使用自建 GitLab Runner 完善 CI 流程

文章目录

从共享 Runner 到自建 Runner

在上篇文章Kubernetes 上的 GitLab + ArgoCD 实践(一):实现基础 CI/CD 流程
,我们已经将CI的流程大致走了一遍,不过当时使用的是 GitLab 已有的 Runner(通常是 Shared Runner 或 GitLab 托管 Runner)。这种方式虽然入门简单,但在真实生产环境中,我们往往需要更高的资源掌控权,例如:

  • 构建镜像时能直接访问 Kubernetes 集群内部服务
  • 避免企业内部代码或镜像流量暴露到外网
  • 根据项目规模灵活扩容 Runner 资源
  • 支持 GPU、ARM 等特殊编译环境
  • 可自定义缓存、网络、安全策略

所以,这一篇文章我将在上篇文章的基础上进行微调,所以,这一篇文章我将在上篇文章的基础上进行微调,实现自建 Runner 与 GitLab 项目之间的对接,并再次完成镜像构建与推送的完整 CI 流程,使 CI/CD 流程真正做到在自己掌控的基础设施上稳定运行。

CI流程

上一篇文章中的CI流程:

  • GitLab 执行 CI → 构建镜像 → 更新 gitops repo → ArgoCD 自动同步。
    本篇文章中的CI流程:
  • 自建 GitLab Runner 在本地/K8s 中执行 CI → 构建镜像(使用 Kaniko) → 更新 gitops repo → ArgoCD 自动同步。
bash 复制代码
┌────────────┐      ┌─────────────────────┐      ┌───────────────┐     
│ Developer  │ ---> │ GitLab Server       │ ---> │ GitLab Runner │
│   (push)   │      │ (trigger pipeline)  │      │ (build+update)│
└────────────┘      └─────────────────────┘      └───────────────┘
                                                          │
                                                          ▼
                                                   ┌─────────────┐
                                                   │ ArgoCD      │
                                                   │ syncs to k8s│
                                                   └─────────────┘

GitLab Runner

GitLab Runner 是用于在 GitLab 平台的 CI/CD 流水线中执行作业(job)的组件。

GitLab Runner 充当代理,将 GitLab 项目与能够运行作业的环境连接起来,这些环境可以是物理机器、虚拟机,或者 Docker 容器。

一个简短的例子:

执行job:GitLab Runner 负责执行在 job pipeline 中 定义的任务。这可以包括代码编译、自动化测试、application 交付,或软件开发周期中所需的其他任务。

想了解更详细内容,可以查看 GitLab 官方文档。

Gitlab-runner创建

  1. 进入gitops-repo项目 -> 设置 -> CI/CD -> Runner,点击"新建项目Runner",填写信息(比如标签、描述等)

  2. GitLab 默认只会把 Job 分配给标签匹配的 Runner,这里将runner 标签(Tags)设置为k8s

  3. 然后点击"创建",就会生成一个令牌。这个令牌是专门给这个预先创建的Runner使用的。

    请记下下图中--token部分显示的"glrt-"开头的token,之后在k8s集群设置时要使用

  4. 检视runner

    页面上虽然已经能看到 Runner,但它会显示为灰色,那是因为它还没真正"上线"。换句话说,GitLab 只是记录了 Runner 的配置,还没有收到来自实际执行节点的注册与心跳信号,因此暂时无法投入工作。

Gitlab-runner 设置

gitlab-runner安装有多种方式,但推荐使用用 Helm:

首先添加Helm 仓库,并更新本地 Helm 仓库缓存

增加repo并update

bash 复制代码
helm repo add gitlab https://charts.gitlab.io
helm repo update

安装

  1. 创建namespace
bash 复制代码
kubectl create namespace gitlab-runner
  1. 安装gitlab-runner
  • glrt-xxxxx:换成你在 GitLab project(项目)中新建 Runner 得到的 认证 token
  • runners.executor=kubernetes:关键,告诉 Runner job 要跑在 K8s Pod 中
  • tags: 指定为k8s,与先前在gitlab上建立的runner tags保持一致
bash 复制代码
helm install demo-project-runner gitlab/gitlab-runner \
  --namespace gitlab-runner \
  --create-namespace \
  --set gitlabUrl=https://gitlab.com \
  --set runnerRegistrationToken="glrt-g2_Ae6iUjsZ6yUC763vZ0G86MQpwOjE4cTBlcgp0OjMKdTppN3FuMxg.01.1j08wwxur"  \
  --set runners.executor=kubernetes \
  --set rbac.create=true \
  --set serviceAccount.create=true \
  --set serviceAccount.name=gitlab-runner \
  --set runners.requestConcurrency=4 \
  --set runners.tags="k8s"

验证gitlab-runner安装

使用 Helm 安装完成 GitLab Runner 后,可以通过以下指令查看当前命名空间内的所有资源:

bash 复制代码
 kubectl get all -n gitlab-runner

你会看到 Helm 已经为 Runner 创建好一整套运行所需的组件,其中最核心的是一个 Deployment,以及由它管理的 Runner Pod。

bash 复制代码
NAME                                                    READY   STATUS    RESTAR                                                                                        TS       AGE
pod/demo-project-runner-gitlab-runner-c664b4cc5-zb6lg   1/1     Running   29 (30                                                                                        m ago)   17h

NAME                                                READY   UP-TO-DATE   AVAILAB                                                                                        LE   AGE
deployment.apps/demo-project-runner-gitlab-runner   1/1     1            1                                                                                                   17h

NAME                                                          DESIRED   CURRENT                                                                                           READY   AGE
replicaset.apps/demo-project-runner-gitlab-runner-c664b4cc5   1         1                                                                                                 1       17h
root@k8sm01:~# kubectl get all -n gitlab-runner
NAME                                                    READY   STATUS    RESTARTS       AGE
pod/demo-project-runner-gitlab-runner-c664b4cc5-zb6lg   1/1     Running   29 (30m ago)   17h

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/demo-project-runner-gitlab-runner   1/1     1            1           17h

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/demo-project-runner-gitlab-runner-c664b4cc5   1         1         1       17h

同时回到gitlab,将会看到gitlab上的runner已经被点亮

CI过程

Clone repo

bash 复制代码
mkdir -p /root/demo-cicd-project/app-repo
cd /root/demo-cicd-project/app-repo
git clone git@gitlab.com:mygroup/app-repo.git

微调CI文件

上一章中使用的 .gitlab-ci.yml 基本可以直接沿用。这里只做少量调整:为相关 Job 增加 tags,使它们能够被我们自建的 Runner 正确接手执行。镜像构建部分依旧沿用 Kaniko 的方式,不需要额外修改。

bash 复制代码
stages:
  - build
  - update-gitops

variables:
  IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
 
build-image:
  stage: build
  tags:
    - k8s
  image: 
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  variables:
    DOCKER_AUTH_CONFIG: "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}"
  script:
    - | 
     /kaniko/executor \
     --dockerfile=Dockerfile  \
     --context=$CI_PROJECT_DIR \
     --destination=${IMAGE} 
  #  because gcr.io/kaniko-project/executor is a light image  without sh shell, so it is changed to "command mode" instead of "script mode"
  #command:
  #  - /kaniko/executor 
  #  - --dockerfile=Dockerfile 
  #  - --context=$CI_PROJECT_DIR 
  #  - --destination=${IMAGE}

update-gitops:
  stage: update-gitops
  tags:
    - k8s
  image: alpine:3.18
  before_script:
    - apk add --no-cache git yq
    - git config --global user.email "ci@mydomain.com"
    - git config --global user.name "gitlab-ci"
  script:
    - git clone https://oauth2:${GITOPS_REPO_TOKEN}@${GITOPS_REPO_URL#https://} gitops
    #- git clone https://$GITOPS_REPO_USER:$GITOPS_REPO_TOKEN@${GITOPS_REPO_URL#https://} gitops
    - cd gitops
    - yq e '.spec.template.spec.containers[0].image = strenv(IMAGE)' -i ./myapp/deployment.yaml
    - git add .
    - git commit -m "Update image to $IMAGE"
    - git push origin HEAD:main
  only:
    - main

push repo

bash 复制代码
git add .
git commit -m "build image by gitlab-runner"
git push origin main

验证

当完成push后,应该会触发CI完成.gitlab-runner.yml文件中定义的build与update-gitops阶段

job状态显示"job succeeded

进入project对应的repo将会看到已经构建好的image

结语:CI 是起点,不是终点

通过本篇的实践,我们已经把 GitLab 自建 Runner 引入到 Kubernetes 中,并成功运行了完整的持续集成流程。现在,每一次代码提交都会触发自动构建、测试和反馈,让质量问题更早暴露,开发协作也不再依赖人工提醒。这种稳定、可重复的 CI 机制,是现代软件交付体系最重要的基石。

当然,CI 只是自动化之旅的一半。构建产物仍需要被可靠地推向各个环境,让应用真正落地到用户侧。也就是说,只有继续推进持续交付(CD),我们才能打通从代码到上线的全链路。下一篇将正式从 CI 扩展到 CD,带你使用 GitLab 与 ArgoCD,将部署能力纳入自动化体系之内,逐步实现 Kubernetes 上的 GitOps 交付流程。

下一篇敬请期待:

《Kubernetes 上的 GitLab + ArgoCD 实践(三):使用 ArgoCD 打通 CD 流程》

让我们继续把自动化的"最后一公里"走到底

相关推荐
engchina4 小时前
WSL Ubuntu で Kubernetes v1.34.2 + Docker 環境を構築する
ubuntu·docker·kubernetes
Gold Steps.8 小时前
OpenEBS — 云原生 CNS 高性能存储
云原生·kubernetes·存储
广州中轴线15 小时前
OpenStack on Kubernetes 生产部署实战(十三)
容器·kubernetes·openstack
切糕师学AI16 小时前
Helm Chart 是什么?
云原生·kubernetes·helm chart
不倒翁玩偶17 小时前
Gitlab拉取代码token换成账号密码登录
gitlab
广州中轴线18 小时前
OpenStack on Kubernetes 生产部署实战(十七)
容器·kubernetes·openstack
xixingzhe218 小时前
ubuntu安装gitlab
linux·ubuntu·gitlab
陈桴浮海1 天前
Kustomize实战:从0到1实现K8s多环境配置管理与资源部署
云原生·容器·kubernetes
张小凡vip1 天前
Kubernetes--k8s中部署redis数据库服务
redis·kubernetes
Hello.Reader1 天前
Flink Kubernetes HA(高可用)实战原理、前置条件、配置项与数据保留机制
贪心算法·flink·kubernetes