GitLab Runner 문제 해결

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed

이 섹션은 GitLab Runner의 문제 해결에 도움이 될 수 있습니다.

note
중요 보안 릴리스는 귀하의 그룹 및 프로젝트의 러너 등록 토큰을 재설정합니다. 러너를 등록하는 자동화된 프로세스(값을 인코드하는 스크립트)를 사용하는 경우,이 업데이트는 해당 프로세스를 중단시킬 것입니다. 그러나, 이전에 등록된 러너에는 영향을 미치지 않아야 합니다.

일반적인 문제 해결 팁

로그 보기

GitLab Runner 서비스는 로그를 syslog로 보냅니다. 로그를 보려면 배포 문서를 참조하세요. journalctl 명령이 포함된 배포에서는 다음 명령을 사용하여 로그를 볼 수 있습니다. 

journalctl --unit=gitlab-runner.service -n 100 --no-pager
docker logs gitlab-runner-container # 도커
kubectl logs gitlab-runner-pod # 쿠버네티스

서비스 재시작 

systemctl restart gitlab-runner.service

도커 머신 확인 

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

모든 도커 머신 삭제 

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

config.toml에 변경 사항 적용 

systemctl restart gitlab-runner.service
docker-machine rm $(docker-machine ls -q) # 도커 머신
journalctl --unit=gitlab-runner.service -f # 잠재적인 오류를 확인하기 위해 로그 따라가기

GitLab 및 GitLab Runner 버전 확인

GitLab은 역 호환성을 보장하기 위해 노력합니다. 그러나 첫 번째 문제 해결 단계로써, GitLab Runner의 버전이 GitLab 버전과 동일한지 확인해야 합니다.

coordinator란 무엇을 의미합니까?

coordinator는 작업이 요청된 GitLab 설치입니다.

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

Windows에서 서비스로 실행할 때 로그 저장 위치

  • Windows에서 GitLab Runner가 서비스로 실행되는 경우, 시스템 이벤트 로그가 생성됩니다. 이를 보려면 이벤트 뷰어를 엽니다(Run 메뉴에서 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.

디버그 로깅 모드 활성화

경고: 디버그 로깅은 심각한 보안 위험을 초래할 수 있습니다. 출력에는 작업에서 사용 가능한 모든 변수 및 기타 비밀들이 포함됩니다. 제3자에게 비밀을 전송할 수 있는 모든 로그 집계를 해제해야 합니다. 마스크 처리된 변수의 사용은 작업 로그 출력에서 비밀을 보호하지만 컨테이너 로그에서는 보호하지 않습니다.

명령줄에서

터미널에서 root로 로그인하여 다음을 실행하세요.

경고: 이 작업은 Shell executor가 있는 러너에서 수행해서는 안 됩니다. 왜냐하면 이것은 systemd 서비스를 재정의하고 모든 작업을 root로 실행하기 때문에 보안 위험을 초래하며 파일 소유권 변경으로 인해 비특권 계정으로 되돌리기가 어려워집니다. 

gitlab-runner stop
gitlab-runner --debug run

GitLab Runner의 config.toml에서

전역 섹션의 config.toml에 디버그 로깅을 활성화할 수 있습니다. 다음 줄을 추가하세요. 이것은 concurrent 줄 이전/이후에 넣으세요: 

log_level = "debug"

Helm 차트에서

Kubernetes 클러스터에 GitLab Runner를 설치한 경우 Helm Chart를 사용하여 values.yaml 커스터마이즈에서 logLevel 옵션을 설정하여 디버그 로깅을 활성화할 수 있습니다: 

## GitLab Runner 로깅 수준 구성. 사용 가능한 값: debug, info, warn, error, fatal, panic
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
logLevel: debug

Docker executor 러너를 위한 DNS 구성

Docker executor로 GitLab Runner를 구성할 때, 호스트에서 러너 데몬이 GitLab에 액세스할 수 있지만 빌드된 컨테이너가 액세스할 수 없는 문제가 발생할 수 있습니다. 이는 호스트에서 DNS가 구성되었지만 해당 구성이 컨테이너로 전달되지 않아 발생할 수 있습니다.

예:

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

새 리포지토리 생성
++ 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: 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.

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

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

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

    실행자를 다시 시작하면 인증서가 비어 있는 것으로 감지하고 재생성합니다.

  • 프로비저닝된 머신의 호스트 이름이 지원되는 길이를 초과합니다. 예를 들어, 우분투 머신의 경우 HOST_NAME_MAX는 64자입니다. 호스트 이름은 docker-machine ls에서 보고됩니다. 실행자 구성의 MachineName을 확인하고 필요한 경우 호스트 이름의 길이를 줄이십시오.

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

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

이 오류는 Docker 자동 스케일러가 SSH를 통해 터널링된 연결에서 대상 시스템의 Docker 데몬에 연결하지 못할 때 발생할 수 있습니다. 대상 시스템에 SSH로 연결할 수 있고 예를 들어 docker info 명령을 성공적으로 실행할 수 있는지 확인하십시오.

자동 스케일된 실행자에 AWS 인스턴스 프로파일 추가

AWS IAM 역할을 작성한 후 IAM 콘솔에서 역할은 Role ARN 및 Instance Profile ARN을 가집니다. 인스턴스 프로파일 이름을 사용해야 하며 역할 이름을 사용해서는 안 됩니다.

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

Java 프로젝트 빌드 중 Docker 실행자가 타임아웃 오류를 반환합니다

가장 가능성이 높은 이유는 손상된 AUFS 저장소 드라이버로 인한 것입니다: Java process hangs on inside container. 가장 좋은 해결책은 저장소 드라이버 변경로 OverlayFS(빠름) 또는 DeviceMapper(느림) 중 하나로 변경하는 것입니다.

이 Docker 구성 및 실행에 대한 기사를 확인하거나 이 systemd로 제어 및 구성에 대한 기사를 확인하십시오.

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

이는 이전 버전의 NGINX에서 깨진 Transfer-Encoding: chunked를 사용하여 GitLab Runner가 발생시킨 것입니다 (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 Runner 도우미가 원격 캐시에 액세스할 수 있는 사전 서명된 URL이나 잘못된 URL이 없을 때 발생합니다. 각 캐시 관련 config.toml 항목 및 공급자별 키 및 값에 대해 검토하십시오. 잘못된 URL은 URL 구문 요구 사항을 따르지 않는 항목에서 구성될 수 있습니다.

또한 도우미의 image 및 helper_image_flavor가 일치하고 최신 상태인지 확인하십시오.

자격 증명 구성에 문제가 있으면 GitLab Runner 프로세스 로그에 진단 오류 메시지가 추가됩니다.

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

HTTP(s)를 통해 git clone을 실행할 때 (GitLab Runner 또는 테스트를 위해 수동으로) 다음과 같은 출력이 나타나면: 

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

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

GitLab 서버에서의 HTTP Proxy 구성이 올바르게 수행되었는지 확인하십시오. 특히 별도 구성된 HTTP Proxy를 사용하는 경우 GitLab 요청이 GitLab Workhorse 소켓으로 프록시될 수 있도록하며 GitLab Unicorn 소켓으로 프록시되지 않도록 하십시오.

HTTP(S)를 통한 Git 프로토콜은 GitLab Workhorse에서 해결되므로 이것이 GitLab의 주요 진입점입니다.

Linux 패키지 설치를 사용하지만 번들된 NGINX 서버를 사용하지 않으려는 경우, 번들되지 않은 웹 서버 사용를 참조하십시오.

GitLab 레시피 저장소에는 Apache 및 NGINX에 대한 웹 서버 구성 예제가 있습니다.

원본에서 GitLab이 소스에서 설치된 경우 위의 문서와 예제를 참조하고 모든 HTTP(S) 트래픽이 GitLab Workhorse를 통해 전달되는지 확인하십시오.

사용자 문제의 예를 확인하십시오.

오류: zoneinfo.zip: no such file or directory 오류를 사용하여 Timezone 또는 OffPeakTimezone

[[docker.machine.autoscaling]] 기간에 설명된 시간대를 구성하는 것이 가능합니다. 이 기능은 대부분의 Unix 시스템에서 기본적으로 작동해야 합니다. 그러나 일부 Unix 시스템 및 아마도 대부분의 비-Unix 시스템(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 시스템에서는 다음과 같이 수행할 수 있습니다. 

# 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를 태그 이름(예: v9.1.0)으로 대체하십시오.
  2. 이 파일을 알려진 디렉토리에 저장하십시오. 우리는 config.toml 파일이 있는 디렉토리와 동일한 디렉토리를 사용하는 것을 제안합니다. 예를 들어, Windows 머신에서 Runnern의 구성 파일이 C:\gitlab-runner\config.toml에 저장되어 있으면 zoneinfo.zip을 C:\gitlab-runner\zoneinfo.zip에 저장합니다.

  3. 전체 경로를 포함하는 ZONEINFO 환경 변수를 설정하십시오. run 명령을 사용하여 실행자를 시작하는 경우 다음과 같이 수행할 수 있습니다: 

    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의 인스턴스는 하나뿐입니다.

Job failed (system failure): preparing environment:

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

실패의 원인이 될 수 있는 dotfiles의 예시:

  • .bash_logout
  • .condarc
  • .rvmrc

또한 SELinux도 이 오류의 원인이 될 수 있습니다. 이를 확인하려면 SELinux 감사 로그를 확인하세요: 

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

Cleaning up 단계 후 Runner가 갑작스럽게 종료됨

“CrowdStrike Falcon Sensor”가 “container drift detection” 설정이 활성화된 상태에서 작업의 Cleaning up files 단계 이후에 Pod를 종료시킬 수 있다고 보고되었습니다. 작업이 완료될 수 있도록 이 설정을 비활성화해야 합니다.

remote error: tls: bad certificate (exec.go:71:0s)로 작업이 실패함

시스템 시간이 변경되며 아티팩트를 생성하는 작업 중에 이 오류가 발생할 수 있습니다. 시스템 시간 변경으로 SSL 인증서가 만료되어 Runner가 아티팩트를 업로드하려고 할 때 오류가 발생합니다.

아티팩트 업로드 중에 SSL 확인을 성공하려면 작업의 끝에 시스템 시간을 유효한 날짜와 시간으로 변경하십시오. 아티팩트 파일의 생성 시간도 변경되어 자동으로 아카이브됩니다.

Helm Chart: ERROR .. Unauthorized

Helm으로 배포된 Runner를 제거하거나 업그레이드하기 전에 GitLab에서 일시 중지하고 작업이 완료될 때까지 기다려야 합니다.

작업이 실행 중일 때 helm uninstall 또는 helm 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는 해당 Pod을 삭제하려고 시도합니다. 롤 바인딩이 없으면 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 문서를 참조하십시오.

Preparing the "docker+machine" executor ERROR: Preparation failed: exit status 1 Will be retried in 3s

이 오류는 Docker 머신이 실행기 가상 머신을 성공적으로 생성하지 못할 때 발생할 수 있습니다. 오류에 대한 추가 정보를 얻으려면, config.toml에서 정의한 것과 동일한 MachineOptions로 가상 머신을 수동으로 생성하십시오.

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

No unique index found for name

이 오류는 Runner를 생성하거나 업데이트할 때 발생할 수 있으며, 데이터베이스에 tags 테이블에 대한 고유한 인덱스가 없을 때 발생할 수 있습니다. GitLab UI에서는 Response not successful: Received status code 500 오류를 받을 수 있습니다.

다음과 같이 이 문제를 해결할 수 있습니다:

  1. Rails 콘솔에서 dedupe.rb 스크립트를 실행하여 테이블에 존재할 수 있는 중복 태그를 통합하세요.

  2. tags 테이블에 대한 고유한 인덱스를 생성하세요: 

    DROP INDEX IF EXISTS index_tags_on_name; -- 잠재적으로 유효하지 않은 인덱스 삭제
CREATE UNIQUE INDEX index_tags_on_name ON tags USING btree (name);