【devops】git-runner介绍与使用

 本站以分享各种运维经验和运维所需要的技能为主

《python零基础入门》：python零基础入门学习

《python运维脚本》： python运维脚本实践

《shell》：shell学习

《terraform》持续更新中：terraform_Aws学习零基础入门到最佳实战

《k8》从问题中去学习k8s

《docker学习》暂未更新

《ceph学习》ceph日常问题解决分享

《日志收集》ELK+各种中间件

《运维日常》运维日常

《linux》运维面试100问

《DBA》db的介绍使用（mysql、redis、mongodb...）

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