GitLab_on_k8s
GitLab 是一个基于 Web 流行开源 Git 仓库管理工具,可以实现代码仓库的管理、代码浏览、问题跟踪、CI/CD 等功能。GitLab 还提供了自己的 CI/CD 工具,可以方便地进行持续集成和持续部署。对于中国地区我们还可以适合国产化的版本:极狐 GitLab,致力于实现一体化 DevOps 平台。
每个节点配置代理下载镜像
1 | |
1. 安装
GitLab 官方提供了 Helm 的方式在 Kubernetes 集群中来快速安装,所以我们可以直接使用 Helm 来安装 GitLab。
1.1 添加chart仓库
1 | |
1.2 下载gitlab包
1 | |
1.3 修改mini中的变量

1 | |
1.4 创建覆盖的变量文件
1 | |
1.5 应用配置文件安装
1 | |

2. 架构
由于极狐 GitLab 包含非常多的组件,包括核心组件(诸如 Registry、Gitaly 等)、可选依赖组件(诸如 PostgreSQL、Redis 等)、可选附件组件(Prometheus、Grafana 等),整体的 Helm Values 文件比较复杂,可以根据自己的需求进行配置。

GitLab Workhorse:轻量级反向代理服务器,可以处理一些大的 HTTP 请求,处理 Git Push/Pull 请求,处理到 Rails 的连接会反向代理给后端的 Puma。Puma:处理 Web 界面和 API 的请求。从 GitLab 13.0 开始,Puma 是默认的 Web 服务器。Puma 是一个 Ruby 应用程序服务器,用于运行核心 Rails 应用程序,该应用程序在 GitLab 中提供面向用户的功能。GitLab Shell:用于 SSH 交互,而不是 HTTP。Redis:缓存每个客户端的 sessions 和后台队列,负责分发任务。Gitaly:后台服务,专门负责访问磁盘以高效处理gitlab-shell和gitlab-workhorse的 git 操作,并缓存耗时操作。所有的 git 操作都通过 Gitaly 处理,并向 GitLab web 应用程序提供一个 API,以从 git 获取属性,并获取 blob 数据。Sidekiq:后台核心服务,可以从 Redis 队列中提取作业并对其进行处理。后台作业允许 GitLab 通过将工作移至后台来提供更快的请求/响应周期。
当然还有一些其他的组件,比如 Minio、KAS、Prometheus 等,这些都是可选的组件,可以根据自己的需求进行配置。其中 KAS 提供了 GitLab 代理服务器,管理 Kubernetes 的 GitLab 代理。
3. gitlab使用
3.1 访问与登录
使用gitlab.k8s.local 访问 GitLab ,要注意的是,通过 Ingress 的方式来暴露服务的,所以我们需要修改本地的 hosts 文件,将 gitlab.k8s.local 指向到 Ingress 的 IP 地址(ingress的地址为ingress控制器的地址,一般使用hostnetwork模式)

初始用户名为 root,密码是以 Secret 的形式存放的:
1 | |
前往 https://gitlab.k8s.local/-/profile/password/edit 页面修改密码,需要至少 8 位(比如 root@321),还可以修改用户名、语言等信息
3.2 创建仓库测试
创建一个实例仓库来测试下

3.3 添加 SSH-KEY
添加本地用户的一个 SSH-KEY,这样我们就可以通过 SSH 来拉取或者推送代码了。SSH 公钥通常包含在 ~/.ssh/id_rsa.pub文件中,并以 ssh-rsa 开头。如果没有的话可以使用 ssh-keygen 命令来生成,id_rsa.pub 里面的内容就是我们需要的 SSH 公钥,然后添加到 Gitlab 中。
如果我们通过 SSH 方式去获取代码,这里需要注意我们服务的暴露方式,我们这里是通过 ingress-nginx 来暴露的服务,属于 7 层服务,而且我们这里本地是通过 LoadBalancer 去接入的 Ingress 流量,要通过 SSH 方式去获取代码,实际上是通过 gitlab-shell 组件来实现的,所以我们需要通过 ingress-nginx 去暴露 gitlab-shell 组件的 TCP 服务,这样我们才能通过 SSH 方式去获取代码。
可以看到 gitlab-shell 的端口是 22,所以我们需要在 ingress-nginx 中添加一个 TCP 的暴露规则,上面使用 Helm Chart 方式安装后会自动创建:
而且该配置文件是不能被你自己的 ingress-nginx 识别的,所以上面这个 ConfigMap 其实并没有生效,而且如果你使用的是 hostNetwork 模式则可能会和宿主机的 22 端口冲突,这里我们可以修改一下端口,比如修改为 2222,比如我们这里的 ingress-nginx 监听的 tcp 配置的 ConfigMap 名为 ingress-nginx-tcp,则修改为如下内容:
1 | |
然后在本地的 ~/.ssh/config 文件中添加如下配置:
1 | |
现在我们就可以通过 SSH 方式去获取代码了
同样现在我们也可以提交代码到 GitLab 了
4. gitlab与jenkins结合使用
到这里我们完成了 GitLab 和 Jenkins 的安装,其实我们还可以将 GitLab 和 Jenkins 结合起来使用,这样当我们提交代码到 GitLab 时,就可以触发 Jenkins 的构建了。
我们可以通过 GitLab 的 Web 界面来触发 Jenkins 的构建,首先我们需要在 Jenkins 中创建一个 Pipeline 项目,然后在 GitLab 中配置 Webhook,这样当我们提交代码到 GitLab 时,就会触发 Jenkins 的构建。
首先需要在 Jenkins 中安装插件 Generic Webhook Trigger。

安装完成后,我们重新创建一个新的 Pipeline 任务,然后就可以选择这个触发器了。

勾选 Generic Webhook Trigger 后, 相当于给 Jenkins 加了一个新的接口 [http://JENKINS_URL/generic-webhook-trigger/invoke。](http://jenkins_url/generic-webhook-trigger/invoke`。)

在使用的时候我们需要把 JENKINS_URL 换成自己真实的 Jenkins 服务器地址,有端口就加上端口,是域名就写域名。比如我们这里就是 http://jenkins.k8s.local/generic-webhook-trigger/invoke。
此外我们还可以为该触发器添加一个 Token,这样可以增加安全性,比如我们这里的 Token 是 youdianzhishi。

一共有 3 种方式可以使用这个 Token:
- 在 URL 中使用
token参数,比如http://jenkins.k8s.local/generic-webhook-trigger/invoke?token=youdianzhishi。 - 在 HTTP Header 中使用
token参数,比如token: youdianzhishi。 - 通过 HTTP Header 的 Bearer Token 传递,比如
Authorization: Bearer youdianzhishi。
此外还可以配置触发条件等等。然后定义流水线代码后保存即可。
这样 Jenkins 就开启 trigger 了,开启后,就可以实现其他系统通过一个指定的 URL 进行自动触发构建了。
就比如我们这里还是使用上面的 gitlab-demo 这个仓库。进入 GitLab 项目设置, 进入 Webhook 配置页面;
添加新的 webhook,配置要触发的 URL,即 Jenkins 触发器接口 URL:http://jenkins.k8s.local/generic-webhook-trigger/invoke?token=youdianzhishi。然后选择发生哪种 GitLab 事件后触发此 Webhook,例如:Push 提交代码、Tag 创建标签等等;

添加后如果出现 Url is blocked: Requests to the local network are not allowed 这样的错误信息,则需要进入管理中心 -> 网络页面,路径 http://gitlab.k8s.local/admin/application_settings/network,z 找到出站请求,勾选允许来自 webhooks 和集成对本地网络的请求。

保存后重新再去添加 webhook,就可以成功了,然后我们可以通过测试按钮来测试下是否可以触发 Jenkins 的构建。

正常情况下,我们可以看到 Jenkins 的构建已经触发了:

在 GitLab Webhook 这边我们也可以查看到请求日志,如果出现了错误,可以根据日志来进行排查
到这里我们就完成了 GitLab 和 Jenkins 的集成,当我们提交代码到 GitLab 时,就可以触发 Jenkins 的构建了
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!