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

공식 GitLab 저장소를 사용하여 GitLab Runner 설치하기

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

지원되는 배포

GitLab은 Packagecloud의 지원되는 Linux 배포 버전에 대한 패키지를 제공합니다. Packagecloud에서 지원하는 새로운 runner deb 또는 rpm 패키지는 새 OS 배포 버전이 지원될 때 자동으로 추가됩니다.

설치에 따라 다른 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
   
   또는
   
   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 기반 배포 중 일부에서만 사용됩니다. 이 유형의 검증이 필요하다면 구성을 조정해야 할 수 있습니다.

https://packages.gitlab.com에서 호스팅된 리포지토리마다 패키지 서명 검증을 위한 다른 GPG 키를 사용할 수 있습니다. 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
   gitlab-runner_amd64.deb 처리 중...
   GOODSIG _gpgbuilder 931DA69CFA3AFEBBC97DAA8C6C57C29C6BA75A4E 1623755049
   

   패키지의 서명이 잘못되었거나 잘못된 키(예: 폐기된 키)로 서명된 경우 다음과 유사한 출력이 나타납니다:

   dpkg-sig --verify gitlab-runner_amd64.deb
   gitlab-runner_amd64.deb 처리 중...
   BADSIG _gpgbuilder
   

   사용자의 키 링에 키가 없는 경우 다음과 유사한 출력이 나타납니다:

   dpkg-sig --verify gitlab-runner_amd64.v13.1.0.deb
   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에서 다운로드합니다.

참고: 동일한 키는 S3 릴리스의 release.sha256 파일을 위해 사용되며 해당 파일은 <https://gitlab-runner-downloads.s3.dualstack.us-east-1.amazonaws.com> 버킷에서 제공됩니다.

이전 GPG 공개 키

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

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

다음 키로 생성된 서명은 더 이상 신뢰해서는 안 됩니다.

문제 해결

GitLab Runner를 설치하는 동안 문제가 발생하는 경우 문제 해결 및 문제 해결에 대한 몇 가지 팁이 여기에 있습니다.

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

가끔 기본 스켈 (skel) 디렉토리가 GitLab Runner에 문제를 일으키고 작업을 실행하지 못하는 경우가 있습니다. 이슈 4449 및 이슈 1379를 참조하세요.

이를 피하기 위해 GitLab Runner를 설치할 때 gitlab-runner 사용자가 생성되며 기본적으로 스켈레톤이 없는 홈 디렉터리가 생성됩니다. skel을 사용하여 홈 디렉터리를 채우면 작업 실행에 방해가 될 수 있고 위에서 언급된 문제와 같은 예기치 않은 문제가 발생할 수 있습니다.

skel 피하도록 기본 동작이 변경되기 전에 runner를 만든 경우 다음 닷 파일을 삭제해 볼 수 있습니다:

sudo rm /home/gitlab-runner/.profile
sudo rm /home/gitlab-runner/.bashrc
sudo rm /home/gitlab-runner/.bash_logout

새로 생성된 $HOME 디렉터리를 채우기 위해 skel 디렉토리를 사용해야 하는 경우 runner를 설치하기 전에 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