处理极狐GitLab Runner 故障 (BASIC ALL)

以下内容可以帮助您处理极狐GitLab Runner 故障。

一般故障处理提示

查看日志

  • tail -100 /var/log/syslog (Debian)
  • tail -100 /var/log/messages (RHEL)

重启服务:

  • service gitlab-runner restart

查看 Docker Machine:

  • sudo docker-machine ls
  • sudo su - && docker-machine ls

删除所有 Docker Machine:

  • docker-machine rm $(docker-machine ls -q)

更改完 config.toml 之后:

  • service gitlab-runner restart
  • docker-machine rm $(docker-machine ls -q)
  • tail -f /var/log/syslog (Debian)
  • tail -f /var/log/messages (RHEL)

确认您的极狐 GitLab 和极狐GitLab Runner 版本

极狐GitLab 旨在保障后向兼容。然而,作为故障排除的第一步,您应该确保您的极狐GitLab Runner 和极狐GitLab 的版本一致。

什么是 coordinator

coordinator 是请求作业时进行的极狐GitLab 安装。

也就是说,Runner 是一个单独的代理,从 coordinator(通过极狐GitLab API 进行安装)请求作业。

当日志在 Windows 上以服务的形式运行时存储在哪里?

  • 如果极狐GitLab Runner 在 Windows 上以服务的形式运行,系统事件日志会增加。如果您想查看日志,打开事件查看器(在运行菜单中,输入 eventvwr.msc 或搜索”事件查看器”)。然后单击 Windows 日志 > 应用。Runner 日志的gitlab-runner。如果您使用的是 Windows Server Core,请运行 get-eventlog Application -Source gitlab-runner -Newest 20 | format-table -wrap -auto PowerShell 命令获取最近 20 个日志条目。

启用调试 Logging 模式

caution调试 Logging 是很严重的安全风险。输出包含作业可用的所有变量和其他密钥的内容。

命令行中

以根用户的身份从终端登录,运行:

gitlab-runner stop
gitlab-runner --debug run

极狐GitLab Runner config.toml

您可以将 log_level 设置为 debug,在 config.toml 的全局部分启用调试 Logging。在您的 config.toml 的最上面以及并发行的前/后添加以下行:

log_level = "debug"

Helm Chart 中

如果使用极狐GitLab Runner Helm Chart 将极狐GitLab Runner 安装在 Kubernetes 集群中,您可以通过设置 values.yaml 自定义中的 logLevel 选项启用调试 Logging:

## Configure the GitLab Runner logging level. Available values are: debug, info, warn, error, fatal, panic
## ref: https://docs.gitlab.cn/runner/configuration/advanced-configuration.html#the-global-section
##
logLevel: debug

为 Docker 执行器 Runner 配置 DNS

当使用 Docker 执行器配置极狐GitLab Runner 时,可能会遇到这样的问题:主机上的 Runner Daemon 可以访问极狐GitLab,但是构建容器却无法访问。这是因为主机上配置了 DNS,但是这些配置却没有传递到容器中。

示例:

极狐GitLab 服务和极狐GitLab Runner 存在于以两种方式桥接的不同的网络中(例如,通过 Internet 或 VPN)。如果 Runner 用来查找极狐GitLab 服务所使用的路由机制查询了 DNS,容器的 DNS 配置不知道通过 VPN 使用 DNS 服务,可能会默认使用通过 Internet 提供的服务。这个配置可能会导致以下信息:

Created fresh repository.
++ echo 'Created fresh repository.'
++ git -c 'http.userAgent=gitlab-runner 15.11.0 linux/amd64' fetch origin +da39a3ee5e6b4b0d3255bfef95601890afd80709:refs/pipelines/435345 +refs/heads/master:refs/remotes/origin/master --depth 50 --prune --quiet
fatal: Authentication failed for 'https://gitlab.example.com/group/example-project.git/'

在这种情况下,Internet 和极狐GitLab 服务之间的服务会导致鉴权失败。这个服务使用单独的证书,如果它们通过 VPN 使用 DNS 服务,Runner 会进行规避。

您可以通过使用 Runner 的 config.toml 文件中的 dns 配置,指导 Docker 使用哪个 DNS 服务器。

dns           = ["192.168.xxx.xxx","192.168.xxx.xxx"]

x509: certificate signed by unknown authority

详情请参见自签名证书

访问 /var/run/docker.sock 时获取 Permission Denied

如果您想使用 Docker 执行器并且连接了安装在服务器上的 Docker Engine, 您可以看见 Permission Denied 错误。 最可能的原因是您的系统使用了 SELinux(在 CentOS、Fedora 和 RHEL 上默认启用)。 查看您系统上的 SELinux 策略以查找可能的拒绝行为。

Docker-machine 错误:Unable to query docker version: Cannot connect to the docker engine endpoint.

如果发生了 Unable to query docker version: Cannot connect to the docker engine endpoint 错误,可能与 TLS 错误有关。如果安装了 docker-machine,会导致一些证书无法正常使用。

为解决这个问题,您需要清除这些证书并重启 Runner。重启之后,Runner 会发现证书为空,随即重新创建证书。

sudo su -
rm -r /root/.docker/machine/certs/*
service gitlab-runner restart

在弹性伸缩 Runner 上添加 AWS 实例配置文件

创建 AWS IAM 角色之后,在您的 IAM 控制台中,角色会拥有角色 ARN实例配置文件 ARN。您必须使用实例配置文件名称,而不是角色名称

向您的 [runners.machine] 部分中添加以下值: "amazonec2-iam-instance-profile=<instance-profile-name>",

构建 Java 项目时 Docker 执行器超时

AUFS 存储驱动损坏很可能会导致这件事情的发生。 最好的解决方法是将存储驱动 更改为 OverlayFS(更快)或 DeviceMapper(更慢)。

请参阅配置和运行 Docker用 Systemd 进行控制和配置

上传产物时出现 411

这是因为极狐GitLab Runner 使用了早期 NGINX (https://serverfault.com/questions/164220/is-there-a-way-to-avoid-nginx-411-content-length-required-errors) 版本上损坏的 Transfer-Encoding: chunked

升级 NGINX 到新版本。

错误:warning: You appear to have cloned an empty repository.

当使用 HTTP(通过极狐GitLab Runner 或手动测试)运行 git clone, 您会看见如下输出:

$ git clone https://git.example.com/user/repo.git

Cloning into 'repo'...
warning: You appear to have cloned an empty repository.

确保您的极狐GitLab 服务器安装中的 HTTP 代理 配置正确。特别是如果您通过它们自身的配置使用 HTTP 代理时,请确保极狐GitLab 请求被代理到极狐GitLab Workhorse Socket,而不是 极狐GitLab Unicorn Socket

极狐GitLab Workhorse 解决了通过 HTTP 的 Git 协议 ,所以它是极狐GitLab 的主要入口点

如果您使用的是极狐 Omnibus GitLab,并且不想使用捆绑的 NGINX 服务器,请阅读使用非捆绑网页服务器

极狐GitLab Recipes 仓库中有 Apache 和 NGINX 的网页服务器配置示例。

如果您使用从源安装的极狐GitLab,您也需要阅读以上文档和示例,并确保所有 HTTP 流量都流经极狐GitLab Workhorse

错误:使用 TimezoneOffPeakTimezone 时出现 zoneinfo.zip: no such file or directory 错误

可以配置描述 [[docker.machine.autoscaling]] 周期的时区,此功能应该可以在大多数 Unix 系统上开箱即用。然而在一些 Unix 系统及大多数非 Unix 系统上(包括我们提供极狐GitLab Runner 二进制文件的 Windows)使用这个功能的时候,Runner 在启动时会崩溃,并出现类似于以下的错误:

Failed to load config Invalid OffPeakPeriods value: open /usr/local/go/lib/time/zoneinfo.zip: no such file or directory

该错误是由 Go 中的 time 包引起的。Go 使用 IANA 时区数据库加载指定时区的配置。在大多数 Unix 系统上,这个数据库已经存在于大家都熟知的路径之一(/usr/share/zoneinfo/usr/share/lib/zoneinfo/usr/lib/locale/TZ/)。 Go 的 time 包在所有这三个路径中查找时区数据库。如果一个都没有找到 ,但是机器已经配置了 Go 开发环境,那么它将回退到 $GOROOT/lib/time/zoneinfo.zip 文件。

如果这些路径都不存在(例如在生产 Windows 主机上),则会引发上述错误。

如果您的系统支持 IANA 时区数据库,但默认情况下不可用,您可以尝试安装它。对于 Linux 系统,可以通过以下方式完成:

# on Debian/Ubuntu based systems
sudo apt-get install tzdata

# on RPM based systems
sudo yum install tzdata

# on Linux Alpine
sudo apk add -U tzdata

如果您的系统没有以 native 的方式提供此数据库,那么您可以按照以下步骤使 OffPeakTimezone 生效:

  1. 下载zoneinfo.zip。从 v9.1.0 版本开始,您可以从标签路径下载文件。在这种情况下,您应该在 zoneinfo.zip 下载 URL 中,将 latest 替换为标签名称(例如,v9.1.0)。

  2. 将此文件存储在大家都熟知的目录中。我们建议您使用存储 config.toml 文件的那个目录。 例如,如果您在 Windows 机器上托管 Runner 并且配置文件存储在 C:\gitlab-runner\config.toml,那么将 zoneinfo.zip 保存到 C:\gitlab-runner\zoneinfo.zip
  3. 设置包含 zoneinfo.zip 文件完整路径的 ZONEINFO 环境变量。如果您使用 run 命令启动 Runner,那么您可以这样做:

    ZONEINFO=/etc/gitlab-runner/zoneinfo.zip gitlab-runner run <other options ...>
    

    或使用 Windows:

    C:\gitlab-runner> set ZONEINFO=C:\gitlab-runner\zoneinfo.zip
    C:\gitlab-runner> gitlab-runner run <other options ...>
    

    如果您将极狐GitLab Runner 作为系统服务进行启动,则需要以服务管理器软件提供的方式(Unix 系统)或通过将 ZONEINFO 变量添加到极狐GitLab Runner 用户通过系统设置可以使用的环境变量列表中(Windows 系统)来更新/覆盖服务配置。

为什么不能运行多个极狐GitLab Runner 实例?

您可以这样做,但是不能共享同一个 config.toml 文件。

使用同一个配置文件运行多个极狐GitLab Runner 实例会导致不可预测和难以调试的行为。

Job failed (system failure): preparing environment:

这个错误通常由您的 Shell 加载配置文件而导致,并且是由一个脚本引发的失败。

已知能引发失败的 Dotfile 示例为:

  • .bash_logout
  • .condarc
  • .rvmrc

SELinux 也是引发这个错误的一个原因。您可以查看 SELinux 审计日志进行确定:

sealert -a /var/log/audit/audit.log

Cleaning up 阶段后 Runner 突然停止

当启用“容器漂移检测”设置时,CrowdStrike Falcon Sensor 会在作业的 Cleaning up files 阶段后停止 Pod。为了确保作业能够完成,您必须禁用此设置。

作业失败,错误信息 remote error: tls: bad certificate (exec.go:71:0s)

在作业创建产物期间系统时间发生显着变化时,可能会出现此错误。由于系统时间发生变化,SSL 证书已过期,会导致 Runner 上传产物时出现错误。

为了确保在产物上传期间 SSL 验证能够成功,在作业结束时将系统时间改回有效的日期和时间。 由于产物文件的创建时间也发生了变化,它们会自动存档。

Helm Chart: ERROR .. Unauthorized

在卸载或升级使用 Helm 部署的 Runner 之前,请在极狐GitLab 中暂停它们并等待任意作业完成。

如果您在运行作业时使用 helm uninstallhelm upgrade 移除 Runner Pod,当作业完成时,可能会出现类似如下内容的 Unauthorized 错误:

ERROR: Error cleaning up pod: Unauthorized
ERROR: Error cleaning up secrets: Unauthorized
ERROR: Job failed (system failure): Unauthorized

这可能是因为移除 Runner 时,角色绑定也一同被移除了。Runner Pod 在作业完成前会一直运行,然后 Runner 会尝试删除它。 如果没有角色绑定,Runner Pod 将不再具有访问权限。

Elasticsearch 服务容器启动错误 max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

Elasticsearch 对 vm.max_map_count 有一个要求:其必须设置在运行 Elasticsearch 的实例上。

关于如何基于平台正确设置此值,请参见 Elasticsearch 文档