GitLab Runner部署(kubernetes环境)

简介: 记录K8S环境部署GitLab Runner的详细步骤

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos
内容:所有原创文章分类汇总及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;

关于GitLab CI

如下图所示,开发者将代码提交到GitLab后,可以触发CI脚本在GitLab Runner上执行,通过编写CI脚本我们可以完成很多使用的功能:编译、构建、生成docker镜像、推送到私有仓库等:
在这里插入图片描述

本次实战内容

今天咱们会一起完成以下操作:

  1. 部署minio,pipeline脚本中的cache功能由minio来实现;
  2. 配置和部署GitLab Runner;
  3. 编写和运行pipeline脚本;

    环境和版本信息

    本次实战涉及到多个服务,下面给出它们的版本信息供您参考:
  4. GitLab:Community Edition 13.0.6
  5. GilLab Runner:13.1.0
  6. kubernetes:1.15.3
  7. Harbor:1.1.3
  8. Minio:2020-06-18T02:23:35Z
  9. Helm:2.16.1

    需要提前准备好的服务

    以下服务需要您在实战前提前准备好:
  10. 部署好GitLab,参考《群晖DS218+部署GitLab》
  11. 部署好Harbor,参考《群晖DS218+部署Harbor(1.10.3)》
  12. 部署好Helm,参考《部署和体验Helm(2.16.1版本)》

准备完毕后开始实战;

部署minio

minio作为一个独立的服务部署,我将用docker部署在服务器:192.168.50.43

  1. 在宿主机准备两个目录,分别存储minio的配置和文件,执行以下命令:

    mkdir -p /var/services/homes/zq2599/minio/gitlab_runner \
    && chmod -R 777 /var/services/homes/zq2599/minio/gitlab_runner \
    && mkdir -p /var/services/homes/zq2599/minio/config \
    && chmod -R 777 /var/services/homes/zq2599/minio/config
    
  2. 执行docker命令创建minio服务,指定服务端口是9000,并且指定了access key(最短三位)和secret key(最短八位):

    sudo docker run -p 9000:9000 --name minio \
    -d --restart=always \
    -e "MINIO_ACCESS_KEY=access" \
    -e "MINIO_SECRET_KEY=secret123456" \
    -v /var/services/homes/zq2599/minio/gitlab_runner:/gitlab_runner \
    -v /var/services/homes/zq2599/minio/config:/root/.minio \
    minio/minio server /gitlab_runner
    
  3. 浏览器访问,输入access key和secret key后登录成功:
    在这里插入图片描述

  4. 如下图,点击红框中的图标,创建一个bucket,名为runner
    在这里插入图片描述
  5. 至此,minio已备好,接下来在kubernetes环境部署GitLab Runner;

    GitLab Runner的类型

    从使用者的维度来看,GitLab Runner的类型分为sharedspecific两种:
  6. 如果您想创建的GitLab Runner给所有GitLab仓库使用,就要创建shared类型;
  7. 如果您的GitLab Runner只用于给某个固定的Gitlab仓库,就要创建specific类型;

今天的实战,我们创建的是specific类型,即先有GitLab代码仓库,然后创建该仓库专用的runner,所以请您提前准备好GitLab仓库;

准备GitLab配置信息(specific)

在部署GitLab Runner之前,要准备两个关键的配置信息,以便GitLab Runner启动后可以顺利连接上GitLab:

  1. 浏览器访问GitLab,打开用来做CI的代码仓库,点击Settings -> CI/CD -> Runners -> Expand:
    在这里插入图片描述
  2. 如下图,红框1中是gitlab url,红框2中是registration token,记好这两个参数,稍后会用到:
    在这里插入图片描述

    准备GitLab配置信息(shared)

    本次实战不会创建shared类型的runner,如果您要创建该类型runner,只需按照以下方法准备信息即可,创建出来的runner就是所有仓库都能使用的了:
  3. 以管理员身份登录GitLab;
  4. 按照下图红框的顺序取得gitlab urlregistration token
    在这里插入图片描述

    部署RitLab Runner

  5. 请确保当前可以通过kubectl命令在kubernetes进行常规操作;
  6. 创建名为gitlab-runner的namespace:

    kubectl create namespace gitlab-runner
    
  7. 创建一个secret,把minio的access key和secret key存进去,在后面配置cache的时候会用到:

    kubectl create secret generic s3access \
    --from-literal=accesskey="access" \
    --from-literal=secretkey="secret123456" -n gitlab-runner
    
  8. 用helm部署GitLab Runner之前,先把chart的仓库添加到helm的仓库列表中:

    helm repo add gitlab https://charts.gitlab.io
    
  9. 下载GitLab Runner的chart:

    helm fetch gitlab/gitlab-runner
    
  10. 当前目录会多出一个文件gitlab-runner-0.18.0.tgz,解压:

    tar -zxvf gitlab-runner-0.18.0.tgz
    
  11. 解压后是名为gitlab-runner的文件夹,内容如下图所示,接下来要修改里面的三个文件:
    在这里插入图片描述

  12. 打开values.yaml,里面有四处需要修改:
  13. 第一处,找到已被注释掉的gitlabUrl参数位置,添加gitlabUrl的配置,其值就是前面在GitLab网页取得的gitlab url参数,如下图红框:
    在这里插入图片描述
  14. 第二处,找到已被注释掉的runnerRegistrationToken参数位置,添加runnerRegistrationToken的配置,其值就是前面在GitLab网页取得的registration token参数,如下图红框:
    在这里插入图片描述
  15. 找到rbac的配置,将createclusterWideAccess的值都改成true(创建RBAC、创建容器gitlab-bastion用于管理job的容器):
    在这里插入图片描述
  16. 设置此GitLab Runner的tagk8s,在pipeline脚本中可以通过指定tag为k8s,这样pipeline就会在这个Gitlab Runner上允许:
    在这里插入图片描述
  17. 找到cache的配置,在修改之前,cache的配置如下图,可见值为空内容的大括号,其余信息全部被注释了:
    在这里插入图片描述
  18. 修改后的cache配置如下图,红框1中原先的大括号已去掉,红框2中的是去掉了注释符号,内容不变,红框3中填写的是minio的访问地址,红框4中的是去掉了注释符号,内容不变:
    在这里插入图片描述
  19. 上图红框4中的s3CacheInsecure参数等于false表示对minio的请求为http(如果是true就是https),但实际证明,当前版本的chart中该配置是无效的,等到运行时还是会以https协议访问,解决此问题的方法是修改templates目录下的_cache.tpl文件,打开此文件,找到下图红框中的内容:
    在这里插入图片描述
  20. 将上图红框中的内容替换成下面红框中的样子,即删除原先的if判断和对应的end这两行,直接给CACHE_S3_INSECURE赋值:
    在这里插入图片描述
  21. 接下来要修改的是templates/configmap.yaml文件,在这里面将宿主机的docker的sock映射给runner executor,这样job中的docker命令就会发到宿主机的docker daemon上,由宿主机来执行,打开templates/configmap.yaml,找到下图位置,我们要在红框1和红框2之间添加一段内容:
    在这里插入图片描述
  22. 要在上图红框1和红框2之间添加的内容如下:

    cat >>/home/gitlab-runner/.gitlab-runner/config.toml <<EOF
            [[runners.kubernetes.volumes.host_path]]
              name = "docker"
              mount_path = "/var/run/docker.sock"
              read_only = true
              host_path = "/var/run/docker.sock"
    EOF
    
  23. 添加上述内容后,整体效果如下,红框中就是新增内容:
    在这里插入图片描述

  24. 修改完毕,回到values.yam所在目录,执行以下命令即可创建GitLab Runner:

    helm install \
    --name-template gitlab-runner \
    -f values.yaml . \
    --namespace gitlab-runner
    
  25. 检查pod是否正常:
    在这里插入图片描述

  26. 看pod日志也并未发现异常:
    在这里插入图片描述
  27. 回到GitLab的runner页面,可见新增一个runner:
    在这里插入图片描述
    至此,整个GitLab CI环境已部署完毕,接下来简单的验证环境是否OK;

验证

  1. 在GitLab仓库中,增加名为.gitlab-ci.yml的文件,内容如下:
    ```yaml

    设置执行镜像

    image: busybox:latest

整个pipeline有两个stage

stages:

  • build
  • test

定义全局缓存,缓存的key来自分支信息,缓存位置是vendor文件夹

cache:
key: ${CI_COMMIT_REF_SLUG}
paths:

  • vendor/

before_script:

  • echo "Before script section"

after_script:

  • echo "After script section"

build1:
stage: build
tags:

  • k8s
    script:
    • echo "将内容写入缓存"
    • echo "build" > vendor/hello.txt

test1:
stage: test
script:

- echo "从缓存读取内容"
- cat vendor/hello.txt

```

  1. 提交上述脚本到GitLab,如下图,可见pipeline会被触发,状态为pending是因为正在等待runner创建executor pod:
    在这里插入图片描述
  2. 稍后就会执行成功,点开看结果:
    在这里插入图片描述
  3. 点开build1的图标,可见此job的输出信息:
    在这里插入图片描述
  4. 点开test1的图标,可见对应的控制台输出,上一个job写入的数据被成功读取:
    在这里插入图片描述
    至此,GitLab Runner已经成功在kubernetes环境部署和运行,接下来的文章,我们会一起实战将SpringBoot应用构建成docker镜像并推送到Harbor;

欢迎关注阿里云开发者社区:程序员欣宸

学习路上,你不孤单,欣宸原创一路相伴...

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
6月前
|
存储 Kubernetes 开发工具
使用ArgoCD管理Kubernetes部署指南
ArgoCD 是一款基于 Kubernetes 的声明式 GitOps 持续交付工具,通过自动同步 Git 存储库中的配置与 Kubernetes 集群状态,确保一致性与可靠性。它支持实时同步、声明式设置、自动修复和丰富的用户界面,极大简化了复杂应用的部署管理。结合 Helm Charts,ArgoCD 提供模块化、可重用的部署流程,显著减少人工开销和配置错误。对于云原生企业,ArgoCD 能优化部署策略,提升效率与安全性,是实现自动化与一致性的理想选择。
321 0
|
3月前
|
Ubuntu 安全 数据安全/隐私保护
在Docker容器中部署GitLab服务器的步骤(面向Ubuntu 16.04)
现在,你已经成功地在Docker上部署了GitLab。这就是我们在星际中的壮举,轻松如同土豆一样简单!星际旅行结束,靠岸,打开舱门,迎接全新的代码时代。Prepare to code, astronaut!
361 12
|
5月前
|
存储 Kubernetes 异构计算
Qwen3 大模型在阿里云容器服务上的极简部署教程
通义千问 Qwen3 是 Qwen 系列最新推出的首个混合推理模型,其在代码、数学、通用能力等基准测试中,与 DeepSeek-R1、o1、o3-mini、Grok-3 和 Gemini-2.5-Pro 等顶级模型相比,表现出极具竞争力的结果。
|
6月前
|
存储 Kubernetes 监控
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
625 33
|
6月前
|
Kubernetes 开发者 Docker
集群部署:使用Rancher部署Kubernetes集群。
以上就是使用 Rancher 部署 Kubernetes 集群的流程。使用 Rancher 和 Kubernetes,开发者可以受益于灵活性和可扩展性,允许他们在多种环境中运行多种应用,同时利用自动化工具使工作负载更加高效。
364 19
|
6月前
|
存储 测试技术 对象存储
使用容器服务ACK快速部署QwQ-32B模型并实现推理智能路由
阿里云最新发布的QwQ-32B模型,通过强化学习大幅度提升了模型推理能力。QwQ-32B模型拥有320亿参数,其性能可以与DeepSeek-R1 671B媲美。
|
7月前
|
存储 Kubernetes 测试技术
企业级LLM推理部署新范式:基于ACK的DeepSeek蒸馏模型生产环境落地指南
企业级LLM推理部署新范式:基于ACK的DeepSeek蒸馏模型生产环境落地指南
310 12
|
7月前
|
人工智能 Kubernetes 异构计算
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
395 5
|
2月前
|
存储 安全 Linux
Linux服务器上安装配置GitLab的步骤。
按照以上步骤,一个基础的GitLab服务应该运行并可以使用。记得定期检查GitLab官方文档,因为GitLab的安装和配置步骤可能随着新版本而变化。
241 0
|
Shell Docker 容器
GitlabCI学习笔记之一:安装Gitlab和GitLabRunner
GitlabCI学习笔记之一:安装Gitlab和GitLabRunner

推荐镜像

更多