GitLab Runner 문제 해결

자세한 내용은 거래처 문제 해결을 위해 도움을 줄 수 있습니다.

caution
A Critical Security release will reset runner registration tokens for your group and projects. If you use an automated process (scripts that encode the value of the registration token) to register runners, this update will break that process. However, it should have no affect on previously registered runners. > 중요 보안 릴리즈는 귀하의 그룹 및 프로젝트의 러너 등록 토큰을 재설정할 것입니다. 등록된 러너를 등록하는 자동화된 프로세스(등록 토큰의 값을 인코딩하는 스크립트)를 사용하는 경우,이 업데이트는 해당 프로세스를 중단시킵니다. 그러나 이전에 등록된 러너에는 영향을 미치지 않아야합니다.

일반적인 문제 해결 팁

로그 보기:

  • tail -100 /var/log/syslog (Debian)
  • tail -100 /var/log/messages (RHEL)
  • docker logs gitlab-runner-container (Docker)
  • kubectl logs gitlab-runner-pod (Kubernetes)

서비스 재시작:

  • service gitlab-runner restart

도커 머신 확인:

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

모든 도커 머신 삭제:

  • 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 설치입니다.

다시 말하면, 러너는 coordinator(GitLab 설치에서 GitLab API를 통해)에게 작업을 요청하는 격리된 에이전트입니다.

Windows에서 서비스로 실행 중일 때 로그가 저장되는 위치는 어디입니까?

  • Windows에서 GitLab Runner가 서비스로 실행 중이면 시스템 이벤트 로그가 생성됩니다. 이를 보려면 이벤트 뷰어를 열고(실행 메뉴에서 eventvwr.msc를 입력하거나 “이벤트 뷰어”를 검색하여) Windows Logs > Application로 이동하십시오. Runner 로그의 Source은 gitlab-runner입니다. Windows Server Core를 사용하는 경우 마지막 20개의 로그 항목을 가져오려면 다음 PowerShell 명령을 실행하십시오.get-eventlog Application -Source gitlab-runner -Newest 20 | format-table -wrap -auto.

디버그 로깅 모드 활성화

caution
디버그 로깅은 심각한 보안 위험일 수 있습니다. 출력에는 작업에 사용 가능한 모든 변수 및 기타 비밀 정보의 내용이 포함됩니다. 제3자에게 비밀 정보를 전송할 수있는 로그 집계를 비활성화해야합니다. 마스크된 변수의 사용을 통해 작업 로그 출력에서 비밀 정보를 보호할 수 있지만 컨테이너 로그에는 보호되지 않습니다.

명령줄에서

터미널에서 root로 로그인 한 상태에서 다음을 실행하십시오: 

gitlab-runner stop
gitlab-runner --debug run

GitLab Runner config.toml에서

global section of the config.toml에서 log_level 설정을 debug로 설정하여 디버그 로깅을 활성화할 수 있습니다. config.toml의 맨 위에 다음 라인을 추가하십시오. concurrent 줄의 전후에 위치시키십시오. 

log_level = "debug"

Helm Chart에서

만약 GitLab Runner가 GitLab Runner Helm Chart를 사용하여 Kubernetes 클러스터에 설치된 경우, values.yaml customization에서 logLevel 옵션을 설정하여 디버그 로깅을 활성화할 수 있습니다. 

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

Docker 실행자 러너를 위한 DNS 구성

Docker 실행자와 함께 GitLab Runner를 구성할 때, 호스트의 Runner 데몬이 GitLab에 액세스할 수 있지만 빌드된 컨테이너는 액세스할 수 없을 수 있습니다. 이는 호스트에서 DNS가 구성되었지만 해당 구성이 컨테이너로 전달되지 않은 경우 발생할 수 있습니다.

예시:

GitLab 서비스와 GitLab Runner가 두 가지 다른 네트워크에 존재하고 두 가지 방법으로 브릿지되는 경우 (예: 인터넷 및 VPN을 통해) (예: 인터넷 및 VPN을 통해) 러너가 GitLab 서비스를 찾기 위해 사용하는 라우팅 메커니즘이 DNS를 쿼리하는 경우 컨테이너의 DNS 구성은 VPN을 통해 DNS 서비스를 사용해야한다는 것을 알지 못하고 인터넷을 통해 제공된 DNS를 기본값으로 사용할 수 있습니다. 이 구성은 다음 메시지로 이어집니다. 

Created fresh repository.
++ echo 'Created fresh repository.'
++ git -c 'http.userAgent=gitlab-runner 16.5.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/'

이 경우 인증 실패는 인터넷과 GitLab 서비스 간에있는 서비스에 의해 발생합니다. 이 서비스는 러너가 VPN을 통해 DNS 서비스를 사용한다면 우회 할 수 있습니다.

config.toml 파일의 [runners.docker] 섹션에서 dns 구성을 사용하여 Docker에게 사용할 DNS 서버를 알릴 수 있습니다. 

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

x509: unknown authority에 의해 서명된 인증서가 표시됩니다

자체 서명 된 인증서를 확인하십시오. self-signed certificates를 참조하십시오.

/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.

이 오류는 기계 프로비저닝과 관련이 있으며 다음과 같은 이유로 발생할 수 있습니다:

  • TLS 실패가 있을 수 있습니다. docker-machine을 설치하면 일부 인증서가 유효하지 않을 수 있습니다. 이 문제를 해결하려면 인증서를 제거하고 러너를 다시 시작하세요: 

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

    러너를 다시 시작한 후에는 인증서가 비어 있는 것으로 확인되고 다시 생성됩니다.

  • 프로비저닝된 머신의 호스트명이 지원되는 길이보다 길 수 있습니다. 예를 들어, Ubuntu 머신의 HOST_NAME_MAX에는 64자 제한이 있습니다. 호스트명은 docker-machine ls에 의해 보고됩니다. 러너 구성에서 MachineName을 확인하고 필요하면 호스트명 길이를 줄이세요.

note
이 오류는 Docker가 머신에 설치되기 전에 발생했을 수 있습니다.

dialing environment connection: ssh: rejected: connect failed (open failed)

이 오류는 Docker 오토스케일러가 SSH 터널을 통해 대상 시스템의 Docker 데몬에 연결하지 못할 때 발생할 수 있습니다. 대상 시스템에 SSH로 연결하고 docker info와 같은 Docker 명령을 성공적으로 실행할 수 있는지 확인하세요.

autoscaled 러너에 AWS 인스턴스 프로필 추가하기

AWS IAM 역할을 작성한 후 IAM 콘솔에서 역할에는 역할 ARN 및 인스턴스 프로필 ARN이 있습니다. 인스턴스 프로필 이름을 사용해야 하며 역할 이름을 사용하면 안 됩니다.

다음 값을 [runners.machine] 섹션에 추가하세요: "amazonec2-iam-instance-profile=<instance-profile-name>",

Java 프로젝트 빌드 시 Docker 실행 시간이 초과됨

이는 아마도 중단된 AUFS 스토리지 드라이버 때문일 가능성이 가장 높습니다: Java process hangs on inside container. 가장 좋은 해결책은 오버레이FS(빠름) 또는 DeviceMapper(느림) 중 하나로 스토리지 드라이버를 변경하는 것입니다.

도커 구성 및 실행에 대한 이 기사 또는 systemd로 제어 및 구성에 대한 이 기사를 확인하세요.

아티팩트를 업로드할 때 411 오류가 발생함

이는 GitLab 러너가 이전 버전의 NGINX에서 깨진 Transfer-Encoding: chunked를 사용하기 때문에 발생합니다 (https://serverfault.com/questions/164220/is-there-a-way-to-avoid-nginx-411-content-length-required-errors).

NGINX를 새 버전으로 업그레이드하세요. 자세한 내용은 이 이슈를 참조하세요: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1031

No URL provided, cache will not be download/uploaded

작업에 대해 캐싱이 구성되어 있지만 GitLab 러너 도우미에게 액세스할 수있는 원격 캐시용 사전 서명 된 URL이나 잘못된 URL이 없을 때 발생합니다. 각 캐시 관련 config.toml 항목 및 공급자별 키와 값을 검토하세요. 유효하지 않은 URL은 URL 구문 요구 사항을 준수하지 않는 항목에서 생성될 수 있습니다.

또한 도우미 image 및 helper_image_flavor가 일치하고 최신 상태인지 확인하세요.

자격 증명 구성에 문제가 있는 경우 GitLab 러너 프로세스 로그에 진단 오류 메시지가 추가됩니다.

오류: warning: You appear to have cloned an empty repository.

HTTP(s)를 사용하여 git clone을 실행할 때(예: GitLab 러너 또는 테스트를 위해 매뉴얼으로) 다음 출력이 표시되면: 

$ 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 소켓이 아니라 GitLab Unicorn 소켓으로 프록시되지 않도록 하세요.

Git 프로토콜을 HTTP(S)를 통해 전달하면 GitLab Workhorse가 이를 해결하기 때문에 이것은 GitLab의 주요 엔트리포인트입니다.

Linux 패키지 설치를 사용하지만 번들로 묶인 NGINX 서버를 사용하고 싶지 않은 경우 번들로 묶이지 않은 웹 서버 사용 방법를 참조하세요.

GitLab 레시피 리포지터리에는 Apache 및 NGINX를 위한 웹 서버 구성 예제가 있습니다.

소스에서 설치한 GitLab을 사용하는 경우 위의 문서와 예제를 읽고 모든 HTTP(S) 트래픽이 GitLab Workhorse를 통해 전송되도록 하세요.

이 사용자 이슈 예제를 참조하세요.

오류: zoneinfo.zip: no such file or directory error when using Timezone or OffPeakTimezone

[[docker.machine.autoscaling]] 기간에서 시간대를 구성할 수 있습니다. 대부분의 Unix 시스템에서 기본적으로 작동해야하지만 특정 Unix 시스템 및 (Windows와 같이 GitLab Runner 이진 파일을 제공하는) 대부분의 비-Unix 시스템에서 시작 시 러너가 유사한 오류와 함께 중단될 수 있습니다.

이 오류는 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 호스트) 위의 오류가 발생합니다.

시스템이 이 데이터베이스를 기본 제공하지 않는 경우를 대비하여 설치할 수 있습니다. Linux 시스템의 경우 다음과 같이 수행할 수 있습니다: 

# Debian/Ubuntu 기반의 시스템에서
sudo apt-get install tzdata

# RPM 기반의 시스템에서
sudo yum install tzdata

# Linux Alpine에서
sudo apk add -U tzdata

시스템이 이 데이터베이스를 네이티브 방식으로 제공하지 않는 경우 아래 단계를 따라 OffPeakTimezone을 작동시킬 수 있습니다:

  1. zoneinfo.zip을 다운로드하세요. 버전 v9.1.0부터는태그 된 경로에서 파일을 다운로드할 수 있습니다. 이 경우 latest를 tag 이름(예: v9.1.0)으로 바꿔서 zoneinfo.zip 다운로드 URL에 사용하세요.

  2. 이 파일을 잘 알려진 디렉터리에 저장하세요. 예를 들어, Windows 기계에서 Runner를 호스팅하고 구성 파일이 C:\gitlab-runner\config.toml에 저장되어 있는 경우 zoneinfo.zip을 C:\gitlab-runner\zoneinfo.zip에 저장하세요.

  3. ZONEINFO 환경 변수를 설정하여 전체 경로가 포함된 zoneinfo.zip 파일을 설정하세요. 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를 시작하는 경우 서비스 구성을 업데이트하거나 재정의하여 서비스 관리자 소프트웨어(유닉스 시스템)에서 또는 System Settings(Windows)을 통해 GitLab Runner 사용자를 위한 환경 변수 디렉터리에 ZONEINFO 변수를 추가하세요.

왜 GitLab Runner를 하나 이상 실행할 수 없을까요?

가능합니다. 그러나 동일한 config.toml 파일을 공유하지는 마십시오.

동일한 구성 파일을 사용하여 GitLab Runner를 여러 개 실행하면 예상치 못한 결과 및 디버그하기 어려운 동작이 발생할 수 있습니다. 특정 config.toml 파일을 한 번에 하나의 GitLab Runner 인스턴스만 사용할 수 있습니다.

작업 실패(시스템 오류): 환경 준비 중:

이 오류는 종종 쉘에서 프로필을 로드하고 스크립트 중 하나가 실패하는 경우에 발생합니다.

실패의 원인이 되는 dotfiles의 예시:

  • .bash_logout
  • .condarc
  • .rvmrc

또한 이 오류의 원인으로 SELinux가 있을 수 있습니다. SELinux 감사 로그를 확인하여 확인할 수 있습니다. 

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

Runner가 정리 중 단계 후 갑자기 종료됨

“CrowdStrike Falcon Sensor”가 “컨테이너 드리프트 감지” 설정이 활성화되어 있을 때 작업의 파일 정리 단계 이후에 pod를 종료시킨다고 보고되었습니다. 작업이 완료될 수 있도록 이 설정을 비활성화해야 합니다.

작업이 원격 오류: tls: 잘못된 인증서 (exec.go:71:0s)와 함께 실패함

이 오류는 작업 중에 시스템 시간이 크게 변경될 때 발생할 수 있습니다. 시스템 시간이 변경됨에 따라 SSL 인증서가 만료되어 실행자가 아티팩트를 업로드하려 할 때 오류가 발생합니다.

SSL 확인이 아티팩트 업로드 중에 성공하도록 하려면, 작업을 마칠 때 시스템 시간을 유효한 날짜와 시간으로 변경하세요. 아티팩트 파일의 생성 시간도 변경되었기 때문에, 이들은 자동으로 아카이브됩니다.

Helm 차트: 오류 .. 허가되지 않음

Helm으로 배포된 실행자(runner)를 제거하기 전에 GitLab에서 일시 중지하고 작업이 완료될 때까지 기다리세요.

작업이 실행 중인 동안 helm uninstall 또는 helm upgrade로 실행자 pod를 제거하면, 다음과 같은 허가되지 않음 오류가 발생할 수 있습니다. 

오류: Pod 정리 중에 오류 발생: 허가되지 않음
오류: 보안 정보 정리 중에 오류 발생: 허가되지 않음
작업 실패(시스템 오류): 허가되지 않음

이는 실행자가 제거되면 역할 바인딩도 제거될 수 있기 때문입니다. 작업이 완료되기 전까지 실행자 pod는 계속됩니다. 그리고 실행자가 이를 삭제하려고 합니다. 역할 바인딩이 없으면 실행자 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 문서를 참조하세요.

docker+machine 실행자 준비 중 오류: 준비 실패: 종료 상태 1 3초 후 다시 시도될 것

이 오류는 Docker 머신이 실행자 가상 머신을 성공적으로 만들지 못했을 때 발생할 수 있습니다. 오류에 대한 자세한 내용을 확인하려면 설정한 MachineOptions와 동일한 가상 머신을 매뉴얼으로 만듭니다.

예: docker-machine create --driver=google --google-project=GOOGLE-PROJECT-ID --google-zone=GOOGLE-ZONE ....