标签：kubectl kind gitlab name yaml Runner 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

标签：kubectl,kind,gitlab,name,yaml,Runner,Gitlab,runner
来源： https://www.cnblogs.com/tcy1/p/16320660.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。