Gitlab-Runner
Git-Runner
前期说明
对于gitlab Runner是什么这里不做过多介绍，这里仅对runner部署方式，以及如何使用展开说明。
实现功能：
配置文件存储位置为gitlab，当代码提交，自动触发apply操作
背景说明：
当前gitlab版本： 13.9.3-ee
使用runner版本：v13.9.0
k8s集群版本：v1.20.11
kubectl版本：v1.20
gitlab-runner部署方式：
gitlab-runner可支持部署方式有多种，如docker，本地，或者运行在pod中，这里的部署使用k8s方式。
runner运行方式：
runner可以理解为agent，可以指定.gitlab.yaml文件中定义的指定运行环境，可以为docker，kubernetes，或者shell，这里围绕kubernetes。
gitlab-runner部署
因为gitlab账号并不是管理员权限，仅对group具备Maintainer权限，所以gitlab-runner使用group作为绑定方式。
绑定关系：
gitlab --> gitlab-runner --> 创建pod运行gitlab-runner中的stages
- 1.RBAC授权
# 1. 授权，让后续gitlab-runner具有创建pod权限
[root@pi-cloud-cpu-test-jyl01 gitlab-runner]# cat RBAC.yaml
apiVersion: v1
kind: Namespace
metadata:
name: base
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: executor
namespace: base
imagePullSecrets:
- name: dockersecret
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: base
name: executor-role
rules:
- apiGroups: [""]
resources: ["pods", "pods/exec"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: base
name: executor-rolebinding
subjects:
- kind: ServiceAccount
name: executor
namespace: cicd
roleRef:
kind: Role
name: executor
apiGroup: rbac.authorization.k8s.io
- 2.gitlab-runner配置文件使用configmap方式挂载
[root@pi-cloud-cpu-test-jyl01 gitlab-runner]# cat runner-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
namespace: monitoring
labels:
app: gitlab-deployer
name: gitlab-runner-cm
data:
REGISTRATION_TOKEN: "gitlab-CICD-Runner中获取到的token"
REGISTER_NON_INTERACTIVE: "true"
REGISTER_LOCKED: "false"
CI_SERVER_URL: "gitlab-CICD-Runner中获取到的Url"
METRICS_SERVER: "0.0.0.0:9100"
RUNNER_CONCURRENT_BUILDS: "4"
RUNNER_REQUEST_CONCURRENCY: "4"
RUNNER_TAG_LIST: "prometheus-runner"
RUNNER_EXECUTOR: "kubernetes" # 指定后续runner使用什么方式运行指令
KUBERNETES_NAMESPACE: "base"
KUBERNETES_SERVICE_ACCOUNT: "executor"
KUBERNETES_PULL_POLICY: "if-not-present"
- 3.gitlab-runner in kubernetes 部署
[root@pi-cloud-cpu-test-jyl01 gitlab-runner]# cat runner-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: runner
namespace: monitoring
labels:
app: runner
spec:
replicas: 1
selector:
matchLabels:
app: runner
template:
metadata:
labels:
app: runner
spec:
containers:
- name: ci-builder
image: registry.cn-hangzhou.aliyuncs.com/lindytom/gitlab-runner:latest
command:
- /bin/bash
- -c
- "/usr/bin/gitlab-runner unregister -n $RUNNER_NAME || true; /usr/bin/gitlab-runner register; exec /usr/bin/gitlab-runner run"
imagePullPolicy: IfNotPresent
envFrom:
- configMapRef:
name: gitlab-runner-cm
ports:
- containerPort: 9100
name: http-metrics
protocol: TCP
lifecycle:
preStop:
exec:
command:
- /bin/bash
- -c
- "/usr/bin/gitlab-runner unregister -n $RUNNER_NAME"
restartPolicy: Always
出现如下界面，则表示gitlab-runner和gitlab已经是绑定关系，.gitlab.yaml可以使用tag名称，对gialb-runner实现控制。
gitlab-runner使用
在代码项目目录中书写.gitlab.yaml文件，在代码提交时，对文件扫描，执行yaml文件中的流程。
既然上面说到是触发对k8s的apply操作，必然少不了的就是kubectl的控制方式，将kubectl文件挂载到runner中不太现实，而且可能需要对多个集群生效，这里使用gitlab中的变量方式，将kube-config文件写入到gitlab中
# .gitlab.yaml文件内容
image: docker:stable
stages: # 主要流程为两步
- code_check # 第一步代码检测
- deploy_prometheus # 第二步部署应用
variables:
GIT_SUBMODULE_STRATEGY: recursive # 自动代码拉取
code_check_job:
stage: code_check # stage: 和主流程中指定的一致，这里为第一个流程
image: registry.cn-hangzhou.aliyuncs.com/lindytom/promtool:latest # 使用镜像具备语法检测功能
only:
- huya-master # 仅代码提交到huya-master分支生效
tags:
- prometheus-runner # runner的tag，需要和runner tag保持一致
script: # prometheus operator的yaml规则检测方式
- cat manifests/configuration-files/prometheus-rule/*.yaml|yq --yaml-output .spec|promtool check rules /dev/stdin
deploy_prometheus_job:
stage: deploy_prometheus # stage: 和主流程中指定的一致，这里为第二个流程
image: bitnami/kubectl:1.20.15 # 通过kubectl镜像，生成kubectl环境
only:
- huya-master
tags:
- prometheus-runner
script: # 这里为执行指令，对yaml检测，并apply
- mkdir $HOME/.kube/ && cat $huya_kube_config > $HOME/.kube/config
- kubectl apply -f manifests/configuration-files --dry-run
- kubectl apply -f manifests/configuration-files
