云原生专栏大纲

GitLab Runner

GitLab Runner 介绍

GitLab Runner 是一个开源的持续集成/持续交付（CI/CD）工具，用于在 GitLab CI/CD 环境中执行自动化构建、测试和部署任务。它是 GitLab CI/CD 的一部分，负责管理和执行 CI/CD 作业。
以下是 GitLab Runner 的一些关键特点和功能：

1. 多平台支持：GitLab Runner 可以在多种操作系统上运行，包括 Linux、macOS 和 Windows。这使得它非常灵活，可以适应不同的开发环境。
2. 并行执行：GitLab Runner 支持并行执行作业，可以同时运行多个作业，提高构建和测试的效率。
3. 多种执行器：GitLab Runner 提供了不同类型的执行器，包括 Shell、SSH、Docker、Kubernetes 等。这些执行器可以根据需要选择，以便在不同的环境中执行作业。
4. 可扩展性：GitLab Runner 可以通过添加自定义执行器来扩展其功能。这使得它可以与各种不同的工具和服务集成，以满足特定的需求。
5. 安全性：GitLab Runner 提供了各种安全功能，包括作业隔离、安全沙盒和访问控制。这些功能可以确保作业的安全性和可靠性。
6. 配置灵活：GitLab Runner 的配置非常灵活，可以通过配置文件或命令行参数进行配置。你可以根据需要自定义执行器的行为和设置。

使用 GitLab Runner，你可以轻松地将 CI/CD 流程集成到 GitLab 中，实现自动化构建、测试和部署。它提供了强大的功能和灵活的配置选项，使得开发团队能够更高效地交付软件。无论是小型项目还是大型企业级项目，GitLab Runner 都是一个强大而可靠的 CI/CD 工具。

GitLab Runner分类

下面是专用Runner、群组Runner和共享Runner之间的对比介绍：

特性	专用Runner	群组Runner	共享Runner
运行环境	为特定项目或组织专门配置的Runner	为一组项目或组织共享的Runner	为整个GitLab实例共享的Runner
配置和管理	需要单独配置和管理每个项目的Runner	可以集中配置和管理一组项目的Runner	集中配置和管理整个GitLab实例的Runner
资源隔离	提供独立的资源，不与其他项目共享	提供一定程度的资源隔离	共享资源，可能会受到其他项目的影响
安全性	提供更高的安全性，仅用于特定项目	提供一定程度的安全性	可能存在安全隐患，需要谨慎使用
可扩展性	随着项目数量增加，需要增加专用Runner	可以共享一组Runner，减少资源需求	可以共享一组Runner，减少资源需求
灵活性	可以根据项目的特定需求进行定制	可以根据一组项目的共同需求进行定制	适用于整个GitLab实例，定制性较低
使用场景	适用于有严格隔离需求的敏感项目	适用于一组项目共享资源的情况	适用于整个GitLab实例的通用场景
部署和维护成本	需要为每个项目单独部署和维护Runner	部署和维护一组Runner	部署和维护整个GitLab实例的Runner

请注意，上述表格中的特性和使用场景只是一般情况下的概括，并不适用于所有情况。根据具体的项目要求和资源约束，您可以选择适合的Runner类型来满足您的需求。

GitLab Runner工作流程

GitLab Runner 的工作流程如下：

1. 注册 Runner：首先，你需要在 GitLab 中注册一个 Runner。这可以通过在 GitLab 项目设置中创建一个新的 Runner 配置来完成。在注册过程中，你将为 Runner 分配一个唯一的 token，用于与 GitLab 服务器进行身份验证。
2. 安装和配置 Runner：在你的执行环境中安装 GitLab Runner，并使用注册时获得的 token 进行身份验证。安装过程可能因操作系统而异，请按照官方文档提供的说明进行安装。安装完成后，你需要通过配置文件或命令行参数对 Runner 进行配置，包括指定 Runner 的名称、token、执行器类型等信息。
3. 运行和监听：启动 GitLab Runner 后，它会连接到 GitLab 服务器，并开始监听作业的出现。Runner 会定期向 GitLab 服务器发送心跳信号，以保持连接。当有新的作业出现时，GitLab 服务器会将作业分配给可用的 Runner。
4. 下载代码：当 Runner 接收到作业时，它会从 GitLab 服务器上获取项目的代码。这通常是通过克隆 Git 存储库或者拉取最新的代码变更来完成的。
5. 执行作业：一旦代码下载完成，Runner 将根据作业的定义执行相应的操作。这可以是构建项目、运行测试、生成文档、打包应用程序等等。Runner 可以使用预定义的执行器（如 Shell、Docker、Kubernetes）来运行作业。
6. 提交结果：当作业执行完成后，Runner 将结果提交回 GitLab 服务器。这包括构建日志、测试报告、生成的文件等。这些结果可以在 GitLab 的界面中查看和分析。
7. 清理和释放资源：完成作业后，Runner 将清理执行环境，并释放使用的资源。这可以包括删除临时文件、停止容器、释放服务器资源等。

整个过程是自动化的，GitLab Runner 负责管理作业的执行和结果的提交。它可以与 GitLab CI/CD 配合使用，为开发团队提供一个强大的持续集成和持续交付平台。通过配置不同的执行器和作业定义，你可以根据项目的需求和特定的环境设置来灵活地定义和执行作业。

Gitlab集成Gitlab Runner

GitLab CI GitLab Runner配置 - 初级篇_gitlab ci aluter-CSDN博客

GitLab Runner 版本选择

https://docs.gitlab.com/runner/
出于兼容性原因，GitLab Runner major.minor 版本 应与 GitLab 主要和次要版本保持同步。年长的跑步者可能仍然可以工作 使用较新的 GitLab 版本，反之亦然。但是，功能可能不可用或无法正常工作 如果存在版本差异。
次要版本更新之间保证向后兼容性。然而，有时轻微 GitLab 的版本更新可以引入需要 GitLab Runner 在同一个次要版本上的新功能 版本。
GitLab Runner 15.0 对 注册 API 请求格式。它可以防止 GitLab Runner 与低于 14.8 的 GitLab 版本进行通信。 您必须使用适合 GitLab 版本的 Runner 版本，或者升级 GitLab 应用程序。

查看gitlab版本

gitlab-rake gitlab:env:info

https://hub.docker.com/r/gitlab/gitlab-runner/tags查找跟gitlab版本对应的runner版本

lpine Linux 和 Ubuntu 是两种常见的 Linux 发行版，它们在一些方面有所不同。

1. 大小和资源消耗：Alpine Linux 是一个轻量级的发行版，以小巧和高效而闻名。它的基本安装映像非常小，通常只有几十兆字节，因此占用的磁盘空间和内存消耗相对较少。这使得它在容器化环境中非常受欢迎，因为它可以快速启动和部署。相比之下，Ubuntu 是一个功能更全面的发行版，提供了更多的软件包和功能。它的基本安装映像较大，通常几个几百兆字节，占用的磁盘空间和内存消耗也更高一些。
2. 软件包管理：Alpine Linux 使用 apk 包管理器来管理软件包。它的软件包库相对较小，但它专注于提供核心软件包和常用工具，以满足大多数基本需求。Ubuntu 使用 apt 包管理器来管理软件包。它的软件包库非常庞大，包含了广泛的软件选择，包括开发工具、服务器应用、桌面环境等。
3. 默认配置和用户友好性：Ubuntu 在默认配置和用户友好性方面更加注重。它提供了易于使用的图形界面和友好的安装程序，适合桌面和服务器使用。Alpine Linux 更加精简，更注重定制和自定义。它的默认配置较为简单，适合专注于特定用途的部署，如容器化环境或嵌入式系统。

选择使用 Alpine Linux 还是 Ubuntu 取决于你的具体需求。如果你需要一个轻量级、高效的发行版，适用于容器化环境或资源受限的系统，那么 Alpine Linux 是一个不错的选择。如果你需要更广泛的软件选择、更丰富的功能和更友好的用户体验，那么 Ubuntu 可能更适合你。

Runner在CitLab中位置

专用Runner在gitlab中位置

进入项目->设置->CICD->runner

群组Runner在gitlab中位置

1. 新建群组

2. 进入群组：设置->CICD->runner

共享Runner在gitlab中位置

GitLab部署

# 添加仓库
helm repo add gitlab https://charts.gitlab.io

# 安装
helm upgrade --install gitlab gitlab/gitlab \
  --namespace=gitlab \
  --create-namespace \
  --timeout 600s \
  --set global.edition=ce \
  --set gitlab-runner.install=false \
  --set global.hosts.domain=example.com \
  --set certmanager-issuer.email=me@example.com

# 对应gitlab-runner镜像
registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v16.7.0

kubesphere仓库安装：

该方式部署会按模块分布式部署：

在GitLab中，KAS（Kubernetes Agent Service）、Registry和Web Service是三个不同的功能模块。

1. KAS（Kubernetes Agent Service）：KAS是GitLab的一个功能，用于与Kubernetes集群进行集成。它充当了一个代理服务，负责与Kubernetes集群通信，并允许你在GitLab CI/CD配置文件（如.gitlab-ci.yml）中定义和管理Kubernetes资源，例如部署、服务、Ingress等。通过KAS，你可以在GitLab中实现基于Kubernetes的持续集成和持续部署（CI/CD）流程。
2. Registry：Registry是GitLab的一个模块，用于管理和存储Docker镜像。它提供了一个私有的Docker镜像仓库，用于存储和分享容器镜像。你可以使用Registry来构建、推送和拉取Docker镜像，以便在CI/CD流程中使用。Registry还提供了访问控制和权限管理功能，可以对镜像进行安全管理。
3. Web Service：在GitLab中，Web Service指的是你的应用程序或服务，可以使用GitLab CI/CD来自动化构建、测试和部署。通过GitLab CI/CD，你可以在.gitlab-ci.yml配置文件中定义构建、测试和部署的步骤，GitLab会根据配置文件中的定义自动化执行这些步骤。你可以将你的Web服务与GitLab的KAS和Registry结合使用，实现容器化的持续集成和持续部署。

综上所述，KAS用于与Kubernetes集群集成，Registry用于管理和存储Docker镜像，而Web Service则是你的应用程序或服务，可以通过GitLab CI/CD来自动化构建、测试和部署。这三个功能模块共同为GitLab提供了容器化和持续集成部署的能力。

Gitlab Runner部署

Gitlab gitlab-ce-zh:11.1.4 持续集成-CSDN博客
Gitlab Runner安装官网文档

docker-compose方式安装

version: '3.8'
services:
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine-v11.11.4
    container_name: gitlab-runner
    restart: always
    volumes:
      - ./config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock  # 这一行是固定写法 不要随便改

kubesphere中可视化方式安装

1. 创建PVC

2. 配置镜像地址

2. 挂载配置

注意：/var/run/docker.sock挂载使用HostPath卷

helm方式安装

https://www.jianshu.com/p/2eb12252e4ee
部署 GitLab Runner | k8s 折腾笔记
注意：helm仓库中维护的版本都大于11，若想使用helm部署请升级gitlab

1. 添加仓库

# 添加 chart 存储库
$ helm repo add gitlab https://charts.gitlab.io

# 查看存储库
$ helm repo list
NAME        URL
gitlab      https://charts.gitlab.io

2. 在kubesphere应用仓库中部署

3. 修改values.yaml 文件

#以下两个在gitlab页面获取
gitlabUrl: http://gitlab.base.svc.cluster.local # 使用k8s内部gitlab svc地址
runnerRegistrationToken: "gitlab-runner-tocken" #gitlab-runner注册用到的tocken

concurrent: 10 #最大作业并发数
checkInterval: 30 #新作业检查间隔
tags: "k8s-runner" #runner的标签
#rbac权限打开
rbac:
  create: true

  ## Define specific rbac permissions.
  ## DEPRECATED: see .Values.rbac.rules
  resources: ["pods", "pods/exec", "secrets","configmaps"]
  verbs: ["get", "list", "watch", "create", "patch", "delete","update"]

Gitlab agent方式安装

1. 登录Gitlab，设置->CICD->Runner->点击在Kubernetes上安装Runer

2. 添加k8s集群信息

要获取 Kubernetes（K8s）集群的名称、API 地址、CA 证书和令牌，你可以按照以下步骤进行操作：

# 运行以下命令来获取当前连接的集群的名称：输出结果@后为集群名
kubectl config current-context
# 下述命令也能获取集群名
kubectl config get-contexts


# 运行以下命令来获取当前连接的集群的 API 地址：
kubectl cluster-info | grep 'Kubernetes master'

# 运行以下命令来获取当前连接的集群的 CA 证书：
kubectl config view --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}' | base64 --decode

# 运行以下命令来获取当前连接的集群的访问令牌（Token）：
kubectl config view --minify --flatten -o jsonpath='{.users[].user.token}' | base64 --decode
# 登录kubesphere，查找保密字典中的coredns-token能查看

注册gitlab-runner

注册-gitlab-runner官网参考，gitlab-runner register命令会修改/etc/gitlab-runner/config.toml配置，配置文件更改时不需要重启服务，每隔三秒GitLab Runner 会检查配置修改，并重新加载。config.toml配置官网 ，有的历史版本在线文档没有维护，需自行拉取，GitLab Docs历史版本

docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs:11.1

交互式注册

进入gitlab-runner pod终端执行下述命令：

/ # gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=33 revision=e828d3bc version=11.11.4
Running in system-mode.
# gitlab地址
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://xxx.xxx.shop:99/
# 项目token
Please enter the gitlab-ci token for this runner:
cp6KwLn3KDTLWN8SD3ax
# 描述也是runner名称
Please enter the gitlab-ci description for this runner:
[gitlab-runner-8575578f55-d8bfh]: ci
# 标签，建议跟gitlab-ci.yml中的阶段一致
Please enter the gitlab-ci tags for this runner (comma separated):
ci
Registering runner... succeeded                     runner=cp6KwLn3
# 选择执行器，从给出列表选择
Please enter the executor: parallels, shell, kubernetes, docker, docker-ssh, ssh, virtualbox, docker+machine, docker-ssh+machine:
[ci]: shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

如果选择 Docker 作为执行程序，系统将要求你输入默认值 图像用于未在 ：.gitlab-ci.yml

Please enter the Docker image (eg. ruby:2.1):
alpine:latest

非交互式注册

1. 进入gitlab-runner pod终端执行下述命令：

gitlab-runner register  \
--non-interactive \
--run-untagged="true" \
--locked="false" \
--executor "shell" \
--url "http://gitlab.base.svc.cluster.local" \
--registration-token "hFwboXgWNwBGgy4omYi2" \
--description "share-runner" \
--tag-list "share" \
#11.1版本一下不支持该参数，自行删除
--request-concurrency 1 \
--limit 2 \   
--access-level="not_protected" \ 

gitlab-runner register比较常用参数介绍：

• –url：GitLab 实例的 URL 地址。
• –registration-token：用于注册 Runner 的访问令牌。可以在 GitLab 项目的设置中找到。
• –executor：指定 Runner 的执行器类型。常见的执行器类型包括parallels, shell, kubernetes, docker, docker-ssh, ssh, virtualbox, docker+machine, docker-ssh+machine
• –name：指定 Runner 的名称，用于在 GitLab 中标识 Runner。
• –tag-list：为 Runner 添加标签，用于在 GitLab CI/CD 配置中选择特定的 Runner。
• –run-untagged：指定 Runner 是否允许运行没有标签的作业。
• –locked：指定 Runner 是否被锁定，锁定的 Runner 只能由项目管理员解锁。
• –access-level：指定 Runner 的访问级别。可选值为 not_protected、ref_protected、full_protected。
  1. not_protected：这是最低的访问级别，表示 Runner 可以运行任何作业，无论作业所在的分支或标签是否受保护。Runner 在任何情况下都可以被使用，包括未受保护的分支和标签。
  2. ref_protected：这个级别表示 Runner 只能运行受保护的分支和标签上的作业。受保护的分支和标签是在 GitLab 项目设置中配置的，通常用于限制对特定分支或标签的更改和部署。Runner 将只能在受保护的分支和标签上执行作业。
  3. full_protected：这是最高的访问级别，表示 Runner 只能运行受完全保护的分支和标签上的作业。完全保护的分支和标签要求作业必须通过一个合并请求（Merge Request）进行审查和合并，以确保代码的质量和安全性。Runner 将只能在受完全保护的分支和标签上执行作业。
• –limit：指定 Runner 可以同时运行的作业数量上限。
• –request-concurrency：指定 Runner 处理作业请求的并发数。

2. 验证Runner注册是否生效

或者在gitlab-runner容器中执行：

gitlab-runner verify

Runner常用命令

命令	描述
gitlab-runner register	注册一个新的 Runner
gitlab-runner start	启动 Runner
gitlab-runner stop	停止 Runner
gitlab-runner restart	重启 Runner
gitlab-runner status	查看 Runner 状态
gitlab-runner list	列出已注册的 Runner
gitlab-runner unregister --id	删除已注册的 Runner
gitlab-runner unregister --all-runners	注销所有Runner
gitlab-runner update	更新 Runner 的二进制文件
gitlab-runner verify	检查注册的runner是否可以连接，但不验证GitLab服务是否正在使用runner

执行器功能对比

GitLab Runer工具集成

1. 以springbo项目为例，在CICD过程中，会使用maven打包项目，使用docker+dockerfile构建镜像，上传到harbor
2. 以vue项目为例，在CICD过程中，会使用npm打包项目，使用docker+dockerfile构建镜像，上传到harbor

这些工具需要集成到Runer中，才能实现CI过程，这而介绍两种集成方式：

1. 在部署GitLab Runer的机器上安装这些组件（不推荐，麻烦）
2. 在gitlab-ci.yaml中通过image定义环境