3.3 Runner 配置

参考：https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section

GitLab Runner配置使用TOML格式。

可以在以下位置找到要编辑的文件：

• /etc/gitlab-runner/config.toml在GitLab Runner以超级用户（root）执行时
• ~/.gitlab-runner/config.toml 当以非root用户身份执行GitLab Runner时
• ./config.toml 在其他系统上

gitlab-runner 支持使用 -c 指定配置文件，config.toml 文件主要分为三个区段：

• 全局区段
• session_server 区段
• runners 区段

1. 全局区段

主要可配置如下：

//示例

concurrent = 4
log_level = "warning"

2. [session_server] 区段

[info]注意:helm chart 还不支持 session_server，但是计划提供支持。

[session_server]区段是一个系统 Runner 级别的配置，因此它应该在根级别指定，而不是在每个执行器上，也就是说，它应该在[[runners]]区段之外。会话服务器允许用户与运行程序负责的作业进行交互。交互式web终端就是一个很好的例子。

//示例

[session_server]
  listen_address = "0.0.0.0:8093" #  listen on all available interfaces on port 8093
  advertise_address = "runner-host-name.tld:8093"
  session_timeout = 1800

[info]如果使用GitLab Runner docker映像，还需要通过在docker run命令中添加-p 8093:8093来公开端口8093。

3. runners 区段

//示例

[[runners]]
  name = "ruby-2.6-docker"
  url = "https://CI/"
  token = "TOKEN"
  limit = 0
  executor = "docker"
  builds_dir = ""
  shell = ""
  environment = ["ENV=value", "LC_ALL=en_US.UTF-8"]
  clone_url = "http://gitlab.example.local"

3.1 clone_url

在GitLab实例暴露给 Runner 不能使用的URL的情况下，可以配置clone_url。

例如;GitLab暴露于 https://gitlab.example.com ，但是由于防火墙设置，Runner 无法到达该位置。如果Runner 可以到达192.168.1.23上的节点，则应该将clone_url设置为 http://192.168.1.23 。

只有在设置了clone_url之后，runner 才会以 http://gitlab-ci-token:s3cr3tt0k3n@192.168.1.23/namespace/project.git 的形式构造一个克隆URL

3.2 执行器

目前有效的执行器如下：

3.3 shells

有两对可用的shell可以在不同的平台上运行。

3.4 [runners.docker]

这定义了Docker容器参数。

(1) [[runners.docker.services]] 部分

指定应该与构建一起运行的其他服务。每个服务将在单独的容器中运行，并链接到构建。

//示例

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.6"
  memory = "128m"
  memory_swap = "256m"
  memory_reservation = "64m"
  oom_kill_disable = false
  cpuset_cpus = "0,1"
  cpus = "2"
  dns = ["8.8.8.8"]
  dns_search = [""]
  privileged = false
  userns_mode = "host"
  cap_add = ["NET_ADMIN"]
  cap_drop = ["DAC_OVERRIDE"]
  devices = ["/dev/net/tun"]
  disable_cache = false
  wait_for_services_timeout = 30
  cache_dir = ""
  volumes = ["/data", "/home/project/cache"]
  extra_hosts = ["other-host:127.0.0.1"]
  shm_size = 300000
  volumes_from = ["storage_container:ro"]
  links = ["mysql_container:mysql"]
  allowed_images = ["ruby:*", "python:*", "php:*"]
  allowed_services = ["postgres:9", "redis:*", "mysql:*"]
  [[runners.docker.services]]
    name = "mysql"
    alias = "db"
  [[runners.docker.services]]
    name = "redis:2.8"
    alias = "cache"
  [[runners.docker.services]]
    name = "postgres:9"
    alias = "postgres-db"
  [runners.docker.sysctls]
    "net.ipv4.ip_forward" = "1"

(2) [runners.docker] valuemes 使用

让我们用一些例子来解释它是如何工作的(假设您有一个工作的runner)

示例1: 添加数据卷

数据卷是绕过联合文件系统的一个或多个容器中专门指定的目录。数据卷的设计目的是持久化数据，与容器的生命周期无关。

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.6"
  privileged = false
  disable_cache = true
  volumes = ["/path/to/volume/in/container"]

这将在容器内/path/to/volume/in/container 处创建一个新卷

示例2：将主机目录挂载为数据卷

除了使用数据卷创建卷之外，还可以将目录从Docker守护进程的主机挂载到容器中。当您希望将目录存储在容器之外时，它非常有用。

[runners.docker]
  host = ""
  hostname = ""
  image = "ruby:2.6"
  privileged = false
  disable_cache = true
  volumes = ["/path/to/bind/from/host:/path/to/bind/in/container:rw"]

主机目录 /path/to/bind/from/host 和 容器目录 /path/to/bind/in/container进行了绑定

[info]GitLab Runner 11.11和更新版本也将挂载已定义服务的主机目录。

(3) 使用私有容器仓库

如果要使用私有仓库源作为构建的映像源,可以在项目的 GitLab 变量部分或config.toml 文件中设置 DOCKER_AUTH_CONFIG。

Runner 执行的步骤总结为：

• 从映像名称中找到仓库地址
• 如果该值不为空，则执行程序将为此仓库搜索验证配置
• 最后，如果找到了与指定仓库相对应的身份验证，则后续拉取将使用它。

Docker 授权解析的优先级

如上所述，GitLab Runner可以通过使用以不同方式发送的凭据来针对仓库授权Docker。为了找到适当的仓库，请考虑以下优先级：

• 凭证配置为DOCKER_AUTH_CONFIG。
• 使用 ~/.docker/config.json 或 ~/.dockercfg 文件在Runner主机上本地配置的凭据（例如，通过docker login在主机上运行）。
• 默认情况下随作业的有效负载发送的凭证（例如，上述集成注册表的凭证）。

将使用第一个找到的仓库凭据。因此，例如，如果使用变量为集成注册表添加一些凭据DOCKER_AUTH_CONFIG，则默认凭据将被覆盖。

allowed_images

我们可以使用该选项定义，只能使用允许的私有 Docker 仓库。

[runners.docker]
  ...
  allowed_images = ["my.registry.tld:5000/*:*"]

3.5 [runners.ssh] 区段

//示例

[runners.ssh]
  host = "my-production-server"
  port = "22"
  user = "root"
  password = "production-server-password"
  identity_file = ""

3.6 [runners.cache] 区段

GitLab Runner 1.1.0 中引入。

（1）[runners.cache.s3]

允许配置S3存储用于缓存。本节包含与S3相关的设置，这些设置以前在该[runners.cache]节中全局存在。

//示例

[runners.cache]
  Type = "s3"
  Path = "path/to/prefix"
  Shared = false
  [runners.cache.s3]
    ServerAddress = "s3.amazonaws.com"
    AccessKey = "AMAZON_S3_ACCESS_KEY"
    SecretKey = "AMAZON_S3_SECRET_KEY"
    BucketName = "runners-cache"
    BucketLocation = "eu-west-1"
    Insecure = false

参考：https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section

3.7 [runners.kubernetes] 区段

GitLab Runner v1.6.0 中添加

//示例

[runners.kubernetes]
  host = "https://45.67.34.123:4892"
  cert_file = "/etc/ssl/kubernetes/api.crt"
  key_file = "/etc/ssl/kubernetes/api.key"
  ca_file = "/etc/ssl/kubernetes/ca.crt"
  image = "golang:1.8"
  privileged = true
  image_pull_secrets = ["docker-registry-credentials"]
  [runners.kubernetes.node_selector]
    gitlab = "true"

更多参考：https://docs.gitlab.com/runner/executors/kubernetes.html

4. Helper image

当使用docker、docker+machine或kubernetes执行器之一时，GitLab Runner使用特定的容器来处理Git、工件和缓存操作。这个容器是由一个名为helper映像的特殊映像创建的。

helper 映像基于Alpine Linux，它提供amd64和arm架构。它包含一个gitLab-run-helper二进制文件，这是GitLab Runner二进制文件的特殊编译，只包含可用命令的一个子集，以及Git、Git LFS、SSL证书存储和Alpine的基本配置。

当从DEB/RPM包中安装GitLab Runner时，两个映像(amd64和基于arm的)都安装在主机上。当运行器为作业执行准备好环境时，如果在Docker引擎上没有找到指定版本(基于Runner的Git修订版)中的映像，则会自动加载它。它对docker和docker+machine执行器都是这样工作的。

对于kubernetes executor或手动安装GitLab Runner时，情况略有不同。对于手动安装，gitlab-runner-helper二进制文件不包括在其中，对于kubernetes executor, kubernetes的API不允许从本地存档加载gitlab-runner-helper映像。在这两种情况下，GitLab Runner都将从Docker Hub (GitLab的官方存储库GitLab / GitLab -run -helper)下载帮助器映像，方法是使用Runner的修订和架构来定义应该下载哪个标记

4.1 覆盖 helper image

在某些情况下，您可能需要覆盖帮助器映像。这样做的原因有很多:

（1）加快作业执行: 在internet连接速度较慢的环境中，从Docker Hub一次又一次地下载相同的映像可能会显著增加作业的时间。从本地注册表(其中存储 gitlab/gitlab-runner-helper:XYZ 的精确副本)下载帮助程序映像可能会加快速度。

（2）安全考虑：许多人不喜欢下载以前没有检查过的外部依赖项。可能有一个业务规则只使用被审查并存储在本地存储库中的依赖项。

（3）构建没有internet访问的环境：在某些情况下，作业是在一个具有专用的、封闭的网络的环境中执行的(这不适用于kubernetes执行程序，因为映像仍然需要从外部注册中心下载，至少kubernetes集群可以从外部注册中心下载映像)。

（4）额外的软件：有些用户可能希望在帮助映像中安装一些额外的软件，比如openssh，以支持通过git+ssh而不是git+http访问的子模块。

在上面描述的任何情况下，都可以使用helper_image配置字段来配置自定义映像，该字段可用于docker、docker+machine和kubernetes执行器:

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:tag"

请注意，助手映像的版本应该与GitLab Runner的版本严格耦合。就像上面所描述的那样,提供这样的的一个主要原因是 Runner 使用gitlab-runner-helper二进制图像,这编译二进制GitLab runner的一部分来源是使用一个内部API,预计在二进制文件都是相同的。

Runner 默认引用 gitlab/gitlab-run-helper:XYZ 映像，其中XYZ基于运行器的体系结构和Git修订。从GitLab Runner 11.3开始，通过使用版本变量之一，可以自动定义使用过的图像的版本:

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:x86_64-${CI_RUNNER_REVISION}"

有了这个配置，GitLab Runner将指示执行程序使用基于其编译数据的版本x86_64-${CI_RUNNER_REVISION}中的映像。在将运行程序更新到新版本之后，这将确保运行程序尝试下载正确的映像。当然，这意味着在升级Runner 之前应该将图像上传到注册表，否则作业将开始失败，出现“没有这样的图像”错误