• 지원되는 배포판
• GitLab Runner 설치
• GitLab Runner 업그레이드
• 패키지 설치를 위한 GPG 서명
  • 리포지토리 메타데이터 서명
  • 패키지 서명
    • RPM 기반 배포판
    • DEB 기반 배포판
    • 현재 GPG 공개 키
    • 이전 GPG 공개 키
• 문제 해결
  • 오류: No such file or directory 작업 실패

GitLab Runner 설치 공식 GitLab 저장소 사용

GitLab Runner를 설치하려면 GitLab 저장소에서 패키지를 사용할 수 있습니다.

지원되는 배포판

GitLab은 Packagecloud와 함께 지원되는 Linux 배포판 버전의 패키지를 제공합니다. 지원되는 새로운 OS 배포판 릴리스에 대한 새로운 runner deb 또는 rpm 패키지가 자동으로 추가됩니다.

설정에 따라 다른 DEB 또는 RPM 기반 배포판도 지원될 수 있습니다. 이는 지원되는 GitLab Runner 배포판의 파생 배포판과 호환되는 패키지 저장소를 의미합니다. 예를 들어, Deepin은 Debian 파생판인 관계로 runner Debian 패키지가 Deepin에 설치되고 실행될 수 있어야 합니다. 다른 Linux 배포판에서 GitLab Runner를 바이너리로 설치할 수도 있습니다.

GitLab Runner 설치

GitLab Runner를 설치하려면:

1. 공식 GitLab 저장소 추가:

   Debian/Ubuntu/Mint

   curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
   

   RHEL/CentOS/Fedora/Amazon Linux

   curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
   

2. GitLab Runner의 최신 버전을 설치하거나, 특정 버전을 설치하려면 다음 단계로 건너뜁니다:

   skel 디렉토리 사용은 기본적으로 비활성화되어 있으며, 이는 No such file or directory 작업 실패를 방지하기 위함입니다.
   Debian/Ubuntu/Mint

   sudo apt install gitlab-runner
   

   RHEL/CentOS/Fedora/Amazon Linux

   sudo yum install gitlab-runner
   
   or
   
   sudo dnf install gitlab-runner
   

   RHEL 배포판용 FIPS 140-2 준수 버전의 GitLab Runner가 제공됩니다. gitlab-runner 대신 패키지 이름으로 gitlab-runner-fips를 사용하여 이 버전을 설치할 수 있습니다.

3. GitLab Runner의 특정 버전을 설치하려면:

   Debian/Ubuntu/Mint

   apt-cache madison gitlab-runner
   sudo apt install gitlab-runner=16.5.0
   

   RHEL/CentOS/Fedora/Amazon Linux

   yum list gitlab-runner --showduplicates | sort -r
   sudo yum install gitlab-runner-16.5.0-1
   

4. 러너 등록.

위 단계를 완료한 후에, 러너를 시작하고 귀하의 프로젝트에서 사용할 준비가 완료됩니다!

GitLab Runner와 관련된 가장 일반적인 문제를 설명하는 FAQ 섹션을 반드시 읽어보세요.

GitLab Runner 업그레이드

최신 버전의 GitLab Runner를 설치하려면:

sudo apt update
sudo apt install gitlab-runner

sudo yum update
sudo yum install gitlab-runner

패키지 설치를 위한 GPG 서명

GitLab Runner 프로젝트는 패키지 설치 방법을 위해 두 가지 유형의 GPG 서명을 제공합니다:

• 리포지토리 메타데이터 서명
• 패키지 서명

리포지토리 메타데이터 서명

원격 리포지토리에서 다운로드한 패키지 정보를 신뢰할 수 있는지 확인하기 위해, 패키지 관리자는 리포지토리 메타데이터 서명을 사용합니다.

apt-get update와 같은 명령을 사용할 때 서명이 검증되므로, 사용 가능한 패키지에 대한 정보를 어떤 패키지가 다운로드되고 설치되기 전에 업데이트됩니다. 검증 실패는 패키지 관리자가 메타데이터를 거부하도록 해야 합니다. 이는 서명 불일치 문제를 발견하고 해결할 때까지 리포지토리에서 패키지를 다운로드하고 설치할 수 없음을 의미합니다.

패키지 메타데이터 서명 검증에 사용되는 GPG 공개 키는 위의 지침에 따라 첫 설치 시 자동으로 설치됩니다. 향후 키 업데이트를 위해 기존 사용자는 새로운 키를 수동으로 다운로드하고 설치해야 합니다.

우리는 https://packages.gitlab.com에서 호스팅되는 모든 프로젝트에 대해 하나의 키를 사용합니다. 현재 사용 중인 키에 대한 세부 정보는 Linux 패키지 문서에서 확인할 수 있습니다. 이 문서 페이지에는 과거에 사용된 모든 키도 나열되어 있습니다.

패키지 서명

리포지토리 메타데이터 서명은 다운로드된 버전 정보가 https://packages.gitlab.com에서 유래함을 증명합니다. 이는 패키지 자체의 무결성을 증명하지는 않습니다.

https://packages.gitlab.com에 업로드된 모든 것 - 승인된 것이든 아니든 -은 메타데이터 전송이 사용자에게 영향을 미치지 않은 한 적절하게 검증됩니다.

여기서 패키지 서명이 필요합니다.

패키지 서명 시, 각 패키지는 빌드될 때 서명됩니다. 따라서 빌드 환경과 사용된 GPG 키의 비밀을 신뢰할 수 있을 때까지, 패키지에 대한 유효 서명은 그 출처가 인증되었고 무결성이 손상되지 않았음을 증명합니다.

패키지 서명 검증은 기본적으로 일부 DEB/RPM 기반 배포판에서만 활성화되어 있으므로, 이러한 검증을 원하시면 구성 조정을 해야 할 수 있습니다.

패키지 서명 검증에 사용되는 GPG 키는 https://packages.gitlab.com에 호스팅되는 각 리포지토리마다 다를 수 있습니다. GitLab Runner 프로젝트는 이러한 유형의 서명에 대해 자체 키 쌍을 사용합니다.

RPM 기반 배포판

RPM 형식은 GPG 서명 기능의 전체 구현을 포함하고 있으며, 따라서 해당 형식을 기반으로 하는 패키지 관리 시스템에 완전히 통합되어 있습니다.

RPM 기반 배포판의 패키지 서명 검증을 구성하는 방법에 대한 기술 설명은 Linux 패키지 문서에서 찾을 수 있습니다. GitLab Runner의 차이점은 다음과 같습니다:

• 설치해야 할 공개 키 패키지의 이름은 gpg-pubkey-35dfa027-60ba0235입니다.
• RPM 기반 배포판의 리포지토리 파일 이름은 /etc/yum.repos.d/runner_gitlab-runner.repo (안정 버전의 경우) 또는 /etc/yum.repos.d/runner_unstable.repo (불안정 버전의 경우)입니다.
• 패키지 서명 공개 키는 https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-49F16C5CC3A0F81F.pub.gpg에서 가져올 수 있습니다.

DEB 기반 배포판

DEB 형식은 공식적으로 패키지를 서명하는 기본 및 포함된 방법을 포함하지 않습니다.

GitLab Runner 프로젝트는 패키지에 대한 서명 및 서명 검증을 위해 dpkg-sig 도구를 사용합니다.

이 방법은 패키지에 대한 수동 검증만 지원합니다.

DEB 기반 패키지를 검증하려면:

1. dpkg-sig 설치:

   apt update && apt install dpkg-sig
   

2. 패키지 서명 공개 키 다운로드 및 가져오기:

   curl -JLO "https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-49F16C5CC3A0F81F.pub.gpg"
   gpg --import runner-gitlab-runner-49F16C5CC3A0F81F.pub.gpg
   

3. dpkg-sig로 다운로드한 패키지 검증:

   dpkg-sig --verify gitlab-runner_amd64.deb
   Processing gitlab-runner_amd64.deb...
   GOODSIG _gpgbuilder 931DA69CFA3AFEBBC97DAA8C6C57C29C6BA75A4E 1623755049
   

   패키지에 잘못된 서명이 있거나 잘못된 키(예: 폐기된 키)로 서명된 경우, 출력은 다음과 비슷합니다:

   dpkg-sig --verify gitlab-runner_amd64.deb
   Processing gitlab-runner_amd64.deb...
   BADSIG _gpgbuilder
   

   사용자의 키링에 키가 없는 경우, 출력은 다음과 비슷합니다:

   dpkg-sig --verify gitlab-runner_amd64.v13.1.0.deb
   Processing gitlab-runner_amd64.v13.1.0.deb...
   UNKNOWNSIG _gpgbuilder 880721D4
   

현재 GPG 공개 키

패키지 서명에 사용되는 현재 공개 GPG 키를 다운로드하려면 https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-49F16C5CC3A0F81F.pub.gpg에서 다운로드하세요.

참고: 같은 키가 GitLab Runner 프로젝트에서 release.sha256 파일을 서명하는 데 사용됩니다.

이는 <https://gitlab-runner-downloads.s3.dualstack.us-east-1.amazonaws.com> 버킷에서 사용할 수 있습니다.

이전 GPG 공개 키

과거에 사용된 키는 아래 표에서 찾을 수 있습니다.

폐기된 키는 패키지 서명 검증 구성에서 제거하는 것이 매우 권장됩니다.

다음 키로 서명된 서명은 더 이상 신뢰하지 않아야 합니다.

문제 해결

GitLab Runner 설치 시 문제를 해결하기 위한 몇 가지 팁입니다.

오류: No such file or directory 작업 실패

경우에 따라 기본 스켈(skelt) 디렉토리가 GitLab Runner에 문제를 일으켜 작업이 실행되지 않을 수 있습니다.

문제 4449 및

문제 1379를 참조하세요.

이를 피하기 위해, GitLab Runner를 설치하면 gitlab-runner 사용자가 생성되고 기본적으로 홈 디렉토리는 스켈 없이 생성됩니다.

skel을 사용하여 홈 디렉토리에 추가된 셸 구성은 작업 실행을 방해하고 위에서 언급한 문제와 같은 예기치 않은 문제를 일으킬 수 있습니다.

만약 skel을 피하는 것이 기본 동작으로 설정되기 전에 러너를 생성했었다면, 다음의 숨김 파일을 제거해보세요:

sudo rm /home/gitlab-runner/.profile

sudo rm /home/gitlab-runner/.bashrc

sudo rm /home/gitlab-runner/.bash_logout

만약 새로 생성된 $HOME 디렉토리를 채우기 위해 skel 디렉토리를 사용해야 한다면, 러너를 설치하기 전에 GITLAB_RUNNER_DISABLE_SKEL 변수를 명시적으로 false로 설정해야 합니다:

export GITLAB_RUNNER_DISABLE_SKEL=false; sudo -E apt-get install gitlab-runner

export GITLAB_RUNNER_DISABLE_SKEL=false; sudo -E yum install gitlab-runner