如何安装 runner？
案例使用的都是 docker 部署，gitlab 使用的是gitlab/gitlab-ce:12.10.14-ce.0所以安装使用的gitlab runner版本是gitlab/gitlab-runner:v12.10.3。
查看信息
先在 gitlab 上查看添加 runner 时需要配置的 token（版本不一样，查看位置也会不同）。
注册
运行
gitlab-runner register命令进行注册
gitlab-runner register1
输入 gitlab 的 url 地址：
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): http://192.168.1.xxxxx/12
输入注册的 token：
Please enter the gitlab-ci token for this runner: pnsBhDZy_iYH_xxxxxx12
输入对这个Runner的表述（同时也是这个Runner的名字），可以在GitLab page上修改它：
Please enter the gitlab-ci description for this runner:[96b8ba5db706]: test_runner12
输入Runner的tag，同样可以在GitLab page上修改它：
Please enter the gitlab-ci tags for this runner (comma separated):test 12
输入Runner的executor：
Please enter the executor: ssh, kubernetes, shell, docker, docker-ssh, parallels, virtualbox, docker+machine, docker-ssh+machine, custom:docker12
这里选择 docker 那么还需要选择默认的docker image来运行job（可以在.gitlab-ci.yml里修改你需要用的image）：
Please enter the default Docker image (e.g. ruby:2.6): docker:19.03.1312
注册完成后，生成 /etc/gitlab-runner/config.toml 文件，该文件是Runner的配置文件.
文件内容如下：
concurrent = 1check_interval = 0[session_server] session_timeout = 1800[[runners]] name = "test_runner" url = "http://192.168.xxxxxxx/" token = "jcFVsWbpovxxxxxxxx" executor = "docker" [runners.custom_build_dir] [runners.cache] [runners.cache.s3] [runners.cache.gcs] [runners.docker] tls_verify = false image = "docker:19.03.13" privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] shm_size = 0123456789101112131415161718192021222324
在 gitlab 上查看可以看到刚刚添加的runner信息。
至此，runner 就添加完成。
在容器中执行gitlab-runner list 可以看到保存在配置文件中的所有运行程序
runner 常用命令如下：
gitlab-runner register #默认交互模式下使用，非交互模式添加 --non-interactivegitlab-runner list #此命令列出了保存在配置文件中的所有运行程序gitlab-runner verify #此命令检查注册的runner是否可以连接，但不验证GitLab服务是否正在使用runner。 --delete 删除gitlab-runner unregister #该命令使用GitLab取消已注册的runner。 #使用令牌注销gitlab-runner unregister --url http://gitlab.example.com/ --token t0k3n #使用名称注销（同名删除第一个）gitlab-runner unregister --name test-runner #注销所有gitlab-runner unregister --all-runners12345678910111213
如何配置 runner？
配置 runner，可以通过修改 config.toml 文件。文件更改时不需要重启服务，每隔三秒GitLab Runner 会检查配置修改，并重新加载。
全局配置
| concurrent | 限制可以同时运行的作业数量。如果concurrent值为1并且有一个worker已经在工作了，那么即使其他worker达到了可以工作的条件也只能“pending”。 |
| log_level | 日志级别 |
| log_format | 日志格式 |
| check_interval | 检查新作业的间隔长度，默认为3秒。如果有多个 |
| sentry_dsn | 启用Sentry错误跟踪 |
| listen_address | http服务监听地址 |
关于check_interval 作用的解释：
如果 config.toml 中存在多个 [[runners]]，则对 GitLab 的请求的间隔会比较频繁。
会将 check_interval 的值除以 [[runners]] 的数量。循环遍历所有，为每个部分安排一个请求，并休眠计算的时间量。
如果您设置 check_interval = 10，并且有两个运行器（runners-1 runners-2），则每 10 秒发出一个请求。以下是这种情况下的循环示例：
获取 check_interval 值（10s）。
获取跑步者列表（runner-1、runner-2）。
计算睡眠间隔（10s / 2 = 5s）。
开始一个无限循环：
为 runner-1 申请工作。
睡5秒。
为 runner-2 申请工作。
睡5秒。
重复。
因此，Runner 进程每 5 秒发出一次请求。如果 runner-1 和 runner-2 连接到同一个 GitLab 实例，这意味着对这个 GitLab 实例的请求也会每 5 秒收到一个来自这个 Runner 的新请求。在第一次对 runner-1 的请求和对 runner-1 的第二次请求之间，有两次睡眠需要 5 秒，所以最后在对 runner-1 的后续请求之间大约有 10 秒。 runner-2 也是如此。如果您定义更多的runner，睡眠间隔会更小，但在调用其他 runner 的所有请求+他们的睡眠后，将重复对 runner 的请求。
参考地址：How check_interval works
[session_server]
| listen_address | 会话服务器的内部 URL |
| advertise_address | 访问会话服务器的 URL |
| session_timeout | 作业完成后会话可以保持活动状态的秒数，默认值为1800秒 |
[[runners]]
每个runners部分定义一个runner服务
| name | 描述 |
| url | GitLab 实例 URL |
| token | runner的的特殊令牌（不是注册令牌） |
| tls-ca-file | 使用 HTTPS 时验证对等方的证书的文件 |
| tls-cert-file | 使用 HTTPS 时与对等方进行身份验证的证书的文件 |
| tls-key-file | 使用 HTTPS 时要与对等方进行身份验证的私钥的文件 |
| limit | 限制同时处理作业数量，0（默认）表示不限制 |
| executor | 选择应如何构建项目 |
| shell | 生成脚本的 shell 的名称，默认值取决于平台。 |
| builds_dir | 构建存储在所选执行程序上下文中的目录的绝对路径。例如，本地、Docker 或 SSH。 |
| cache_dir | 构建缓存存储在所选执行程序上下文中的目录的绝对路径。例如，本地、Docker 或 SSH。如果使用dockerexecutor，则需要在其volumes参数中包含该目录 |
| environment | 追加或覆盖环境变量。 |
| request_concurrency | 限制来自 GitLab 的新作业的并发请求数，默认为1 |
| output_limit | 最大构建日志大小，默认值为4096(4MB) |
| pre_clone_script | 在克隆 Git 存储库之前执行的命令 |
| pre_build_script | 在克隆 Git 存储库之后但在执行构建之前执行的命令 |
| post_build_script | 在执行构建之后执行的命令 |
| clone_url | 覆盖 GitLab 实例的 URL |
| debug_trace_disabled | 禁用CI_DEBUG_TRACE特性。当设置为true时，即使用户将CI_DEBUG_TRACE设置为true，调试日志(跟踪)也将保持禁用状态 |
| referees | 将结果作为工作工件传递给 GitLab |
例子：
[[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"12345678910
tips: 如果想一些固定的变量，比如 registry 仓库地址，可以通过一个变量的形式传递到这个 environment 变量里面，比如 environment = ["CI_REGISTRY=registry.aliyuncs.com"]
executors
executors 简单的解释就是：executors 决定了 runner 用什么方式在什么环境上完成 gitlab 给下来的CI Job。一个觉得挺不错的解释地址：GitLab CI 之 Runner 的 Executor 該如何選擇？
| shell | 默认执行器 | |
| docker | [runners.docker] and Docker Engine | docker容器 |
| docker-windows | [runners.docker] and Docker Engine | Windows Docker 容器 |
| docker-ssh | [runners.docker], [runners.ssh], 和Docker 引擎 | Docker 容器，使用 SSH 连接 |
| ssh | [runners.ssh] | 远程SSH |
| parallels | [runners.parallels] 和 [runners.ssh] | Parallels VM，使用 SSH 连接 |
| virtualbox | [runners.virtualbox] 和 [runners.ssh] | VirtualBox VM，但使用 SSH 连接 |
| docker+machine | [runners.docker] 和 [runners.machine] | 类似docker，但使用自动缩放的 Docker 机器 |
| docker-ssh+machine | [runners.docker] 和 [runners.machine] | 类似docker-ssh，但使用自动缩放的 Docker 机器 |
| kubernetes | [runners.kubernetes] | Kubernetes pods |
[runners.custom_build_dir]
设置自定义构建目录参数，如果没有明确配置，对于kubernetes、docker、docker-ssh、docker+machine和docker-ssh+machine执行器将被默认启用。对于所有其他的执行器，它将被默认为禁用。更多细节可以在[runners.custom_build_dir]文档中找到。
| enabled | 布尔值 | 允许用户为JOB定义自定义构建目录 |
[runners.cache]
这定义了分布式缓存功能。更多细节可以在runners autoscale文档中找到。
| Type | 字符串 | s3 和 gcs 两者其中之一。 |
| Path | 字符串 | 附加到缓存 URL 的路径的名称。 |
| Shared | 布尔值 | 启用 runner 之间的缓存共享，默认为 false。 |
[runners.docker]
定义了 Docker 容器参数
| allowed_images | 可以在.gitlab-ci.yml文件中指定的镜像的通配符列表；如果不存在，则允许所有镜像（相当于[“*/ *: *”]） |
| allowed_services | 可以在.gitlab-ci.yml文件中指定的服务的通配符列表；如果不存在，则允许所有镜像（相当于[“*/ *: *”]） |
| cache_dir | 缓存目录，此路径可以是绝对路径，也可以是路径 |
| cap_add | 向容器添加额外的 Linux 功能 |
| cap_drop | 从容器中删除其他 Linux 功能 |
| cpuset_cpus | 对照组的CpusetCpus |
| cpu_shares | 用于设置相对 CPU 使用率的 CPU 份额数，默认为1024 |
| cpus | CPU 数量（在 Docker 1.13 或更高版本中可用） |
| devices | 与容器共享其他主机设备 |
| disable_cache | Docker 执行器有两个级别的缓存：全局缓存和基于 Docker 卷的本地缓存，此配置标志仅作用于禁用自动创建（未映射到主机目录）缓存卷的本地配置标志 |
| disable_entrypoint_overwrite | 禁用镜像覆盖entrypoint |
| dns | 供容器使用的 DNS 服务器列表 |
| dns_search | DNS 搜索域列表 |
| extra_hosts | 应该在容器环境中定义的主机 |
| gpus | Docker 容器的 GPU 设备使用与dockercli相同的格式查看Docker 文档中的详细信息 |
| helper_image | （高级）用于克隆存储库和上传工件的默认帮助程序镜像 |
| host | 自定义 Docker 端点默认为DOCKER_HOST环境或unix:///var/run/docker.sock. |
| hostname | Docker 容器的自定义主机名 |
| image | 用于运行作业的镜像（也可以在.gitlab-ci.yml里指明你需要用的image） |
| links | 应与运行作业的容器链接的容器 |
| memory | 内存限制 |
| memory_swap | 总内存限制 |
| memory_reservation | 内存软限制 |
| network_mode | 将容器添加到自定义网络 |
| oom_kill_disable | 如果发生内存不足 (OOM) 错误，不终止容器中的进程 |
| oom_score_adjust | OOM 分数调整阳性意味着更早杀死 |
| privileged | 使容器以特权模式运行不安全 |
| pull_policy | 镜像拉取策略：never，if-not-present或always（默认）查看拉取策略文档中的详细信息您还可以添加多个拉取策略 |
| runtime | Docker 容器的运行时 |
| security_opt | 安全选项（–security-opt in docker run）获取:分隔键/值的列表 |
| shm_size | 镜像的共享内存大小（以字节为单位） |
| sysctls | sysctl选项 |
| tls_cert_path | 存储 ca.pem、cert.pem 或 key.pem 的目录，用于与 Docker 建立安全的 TLS 连接。在 boot2docker 中很有用。 |
| tls_verify | 启用或禁用对 Docker 守护程序连接的 TLS 验证，默认禁用 |
| userns_mode | 启用用户命名空间重新映射选项时，容器和 Docker 服务的用户命名空间模式，在 Docker 1.10 或更高版本中可用 |
| volumes | 安装挂载卷与 Docker-v标志的语法相同 |
| volumes_from | 从另一个容器继承挂载卷，访问级别默认为读写，但可以手动设置为ro（只读）或rw（读写） |
| volume_driver | 用于容器的挂载卷驱动程序 |
| wait_for_services_timeout | 等待 Docker 服务的时间设置0为禁用默认为30 |
例子：
[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"123456789101112131415161718192021222324252627282930313233343536373839
当我的Runner采用docker作为executor时，无法build docker image
这是个“dind(docker in docker)” 问题，一般pipeline会报如下错误：
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?time="2018-12-17T11:12:33Z" level=error msg="failed to dial gRPC: cannot connect to the Docker daemon. Is 'docker daemon' running on this host?: dial unix12
有两种解决办法：
第一种解决办法：将本地的docker socket绑定到container里来解决这个问题，具体方法是将volumes = ["/var/run/docker.sock:/var/run/docker.sock"]配置增加到config.toml文件的[runners.docker]里。
第二种解决办法：.gitlab-ci.yml文件中增加如下设置
services: - docker:dind12
如果想在这个 docker in docker 的环境下，进行自动 login 操作，和 进行 ssh 远程连接其他机器进行版本更新的话，其中一种方法是在这个 volumes = ["/root/.docker/config.json:/root/.docker/config.json","/root/.ssh/:/root/.ssh/"] 添加到config.toml文件的[runners.docker]里。
Docker Executor：
所有jobs的执行环境为指定的docker image所生成的container，每个job都会生成一个container并且在job结束后立即销毁。这个说的就是config.toml文件和.gitlab-ci.yml中指定的image。
Docker executor默认将所有的builds存储在/builds/(这里的路径是container里的路径，Runner配置文件config.toml里的build_dir字段可以重新指明build的目录，默认对应于宿主机的目录是在宿主机的docker volume下：/var/lib/docker/volumes/_data/)，默认将所有的caches存储在container里的/cache目录(config.toml里的cache_dir字段可以重新指明cache的目录)，注意build_dir和cache_dir指向的均是container里的目录，要想将container里的数据持久化，需要用到volumes字段，这个字段的使用和docker volume的使用是类似的，只需在config.toml的[runner.docker]部分添加volumes = [“/cache”, “:rw”]即可实现container里/cache目录数据的永久保存以及将host目录挂载到相应的container目录并具有读写的功能。
参考地址：
https://www.cnblogs.com/sanduzxcvbnm/p/14681532.html
https://www.jianshu.com/p/19fe0ce7ecec
https://docs.gitlab.com/12.10/runner/configuration/advanced-configuration.html
如何使用runner？
.gitlab-ci.yml 用来配置 CI 用你的项目中做哪些操作，这个文件位于仓库的根目录。
当有新内容 push 到仓库，或者有代码合并后， GitLab 会查找是否有 .gitlab-ci.yml 文件，如果文件存在， Runners 将会根据该文件的内容开始 build 本次 commit 。
.gitlab-ci.yml 使用 YAML 语法， 你需要格外注意缩进格式，要用空格来缩进，不能用 tabs 来缩进。
原文档
Job
YAML 文件定义了一系列带有约束说明的 job, job 至少需要要包含 script：
示例：
job1: script: "execute-script-for-job1"job2: script: "execute-script-for-job2"12345
上面这个例子是一个最简单且带有两个 job 的 CI 配置，每个任务分别执行不同的命令。
script 可以直接执行系统命令 (如：./configure;make;make install) 或者直接执行脚本 (test.sh)。
任务是由 CI 接管并且在服务器执行，并且每一个任务的执行都是独立的。
job 的名称具有唯一性在文件中只能出现一次，并且下列词汇被保留不能被使用：
image
services
stages
types
before_script
after_script
variables
cache
include
job 可以配置的参数列表
| script | 定义Runner需要执行的脚本或命令 |
| image | 需要使用的docker镜像 |
| services | 定义了所需的docker服务 |
| before_script | 定义在每个job之前运行的命令 |
| after_script | 定义在每个job之后运行的命令 |
| stages | 定义哪些stage可以被job调用的，相同stage的job可以平行执行，下一个stage的job会在前一个stage的job成功后开始执行。 |
| stage | 定义当前 job 运行的阶段名字 (默认: test) |
| only | 定义了job需要执行的所在分支或者标签 |
| except | 定义了job不会执行的所在分支或者标签 |
| rules | 评估和确定作业的选定属性以及是否创建的条件列表。不能与 only/except 一起使用。 |
| tags | 定义了哪些runner适用该job |
| allow_failure | 允许任务失败，但是如果失败，将不会改变提交状态 |
| when | 定义 job 在什么时候运行。 |
| environment | 用于定义作业部署到特定环境。如果指定了 environment 并且不存在该名称下的环境，则会自动创建一个新环境。 |
| cache | 在后续运行之间应该被缓存的文件列表。 |
| artifacts | 用于指定一个文件和目录的列表，当作业成功、失败或总是成功时，这些文件和目录应该被附加到作业中。工作完成后，工件将被发送到GitLab，并可在GitLab用户界面上下载。 |