• 전제 조건
• GitLab Runner 설치
  • APT pinning
• GitLab Runner 업데이트
• 패키지 설치용 GPG 서명
  • 리포지토리 메타데이터 서명
  • 패키지 서명
    • RPM 기반 배포판
    • DEB 기반 배포판
    • 현재 GPG 공개 키
    • 이전 GPG 공개 키
• 패키지 수동 다운로드
• skel 비활성화

공식 GitLab 리포지토리를 사용하여 GitLab 러너 설치

packagecloud에서 지원되는 Linux 배포 버전의 패키지를 제공합니다. 새 OS 배포 릴리스에 대한 새로운 러너 deb 또는 rpm 패키지는 packagecloud에서 지원되면 자동으로 추가됩니다. 설정에 따라 다른 deb 또는 rpm 기반 배포본도 지원할 수 있습니다. 이는 지원되는 GitLab Runner 배포판의 파생본이며 호환되는 패키지 리포지토리를 가진 배포본을 참조합니다. 예를 들어 Deepin은 Debian의 파생본이므로 러너 Debian 패키지가 Deepin에 설치되고 실행될 수 있습니다. 또한 다른 Linux 배포본에서 바이너리로 GitLab 러너를 설치할 수도 있습니다.

전제 조건

Docker executor를 사용하려면 GitLab Runner를 사용하기 전에 Docker를 설치해야 합니다. 배포본에 따라 배포별 Docker 설치 방법을 읽어보세요.

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의 경우:

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

   Debian 사용자는 APT pinning을 사용해야 합니다.

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

   GitLab Runner 14.0부터 skel 디렉터리 사용이 기본적으로 비활성화되어 있어서 No such file or directory 작업 실패가 발생합니다.

   Debian/Ubuntu/Mint의 경우:

   sudo apt-get install gitlab-runner
   

   RHEL/CentOS/Fedora의 경우:

   sudo yum install gitlab-runner
   

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

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

   DEB 기반 시스템의 경우:

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

   RPM 기반 시스템의 경우:

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

4. 러너 등록.

위 단계를 완료한 후에 러너를 시작하고 프로젝트에서 사용할 수 있도록 준비가 되어야 합니다!

GitLab Runner의 가장 흔한 문제 몇 가지에 대한 설명은 FAQ 섹션을 반드시 읽어보세요.

APT pinning

Debian Stretch에는 gitlab-ci-multi-runner라는 네이티브 패키지가 있습니다. 기본적으로 gitlab-runner를 설치할 때 공식 리포지토리에서 제공하는 해당 패키지가 더 높은 우선 순위를 갖습니다.

저희의 패키지를 사용하려면 패키지의 소스를 수동으로 설정해야 합니다. 가장 좋은 방법은 pinning 구성 파일을 추가하는 것입니다.

이렇게 하면 패키지의 다음 업데이트 - 수동 또는 자동으로 수행될 업데이트 -은 동일한 소스를 사용하여 수행됩니다.

cat <<EOF | sudo tee /etc/apt/preferences.d/pin-gitlab-runner.pref
Explanation: Prefer GitLab provided packages over the Debian native ones
Package: gitlab-runner
Pin: origin packages.gitlab.com
Pin-Priority: 1001
EOF

GitLab Runner 업데이트

최신 버전을 설치하려면 간단히 다음을 실행하십시오:

Debian/Ubuntu/Mint용:

sudo apt-get update
sudo apt-get install gitlab-runner

RHEL/CentOS/Fedora용:

sudo yum update
sudo yum install gitlab-runner

패키지 설치용 GPG 서명

설치된 소프트웨어에 대한 사용자의 신뢰도를 높이기 위해 GitLab Runner 프로젝트는 패키지 설치 방법에 대해 리포지토리 메타데이터 서명 및 패키지 서명 두 가지 유형의 GPG 서명을 제공합니다.

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

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

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

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

우리는 https://packages.gitlab.com에 호스팅된 모든 프로젝트에 대해 하나의 키를 사용합니다. 현재 사용 중인 키 세부 정보 및 필요할 때 키를 업데이트하는 기술적 설명은 Linux package documentation 에서 찾을 수 있습니다. 이 문서 페이지에는 또한 과거에 사용된 모든 키도 나열되어 있습니다.

패키지 서명

리포지토리 메타데이터 서명은 다운로드한 버전 정보가 https://packages.gitlab.com에서 유래함을 증명합니다. 그것 자체의 패키지 무결성을 증명하지는 않습니다. https://packages.gitlab.com에 업로드된 모든 것 - 인증된 것든 아니든 - 메타데이터가 사용자에게 전달될 때까지 적절하게 검증됩니다.

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

패키지 서명을 사용하면 각 패키지가 빌드될 때 서명됩니다. 따라서 사용한 GPG 키의 빌드 환경 및 비밀 유지를 신뢰할 수 있는 한, 패키지의 유효한 서명은 그 원본이 인증되었고 무결성이 훼손되지 않았음을 증명합니다.

패키지 서명 검증은 DEB/RPM 기반의 일부 배포판에서만 기본적으로 활성화되므로 이러한 종류의 검증을 원하는 사용자는 설정을 조정해야 할 수 있습니다.

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

RPM 기반 배포판

RPM 형식에는 GPG 서명 기능의 완전한 구현이 포함되어 있으므로 해당 형식을 기반으로 한 패키지 관리 시스템과 완전히 통합됩니다.

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

• 설치해야 하는 공개 키 패키지는 gpg-pubkey-35dfa027-60ba0235라고 명명됩니다.

• 안정 버전의 경우 리포지토리 파일은 /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 도구를 사용합니다. 이 방법은 패키지의 수동 검증만 지원합니다.

1. dpkg-sig 설치

    apt-get update && apt-get 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 프로젝트에서 S3 릴리스의 release.sha256 파일에 서명하기 위해 <https://gitlab-runner-downloads.s3.dualstack.us-east-1.amazonaws.com> 버킷에서 사용됩니다.

이전 GPG 공개 키

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

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

이러한 키로 생성된 서명은 미래에 믿을 수 없게 됩니다.

패키지 수동 다운로드

필요한 경우 수동으로 패키지를 다운로드하고 설치할 수 있습니다.

skel 비활성화

• GitLab Runner 12.10에서 도입.
• GitLab Runner 14.0에서 기본값으로 설정됨.

가끔씩 기본 스켈레톤(skel) 디렉터리가 GitLab Runner에게 문제를 일으키고 작업 실행에 실패하는 경우가 있습니다.

GitLab Runner 12.10에서는 새로 생성된 사용자의 $HOME 디렉터리를 만들 때 skel의 사용을 방지하는 특수 변수인 GITLAB_RUNNER_DISABLE_SKEL을 지원하게 되었습니다.

GitLab Runner 14.0부터는 GITLAB_RUNNER_DISABLE_SKEL이 기본적으로 true로 설정됩니다.

어떠한 이유로든 새로 생성된 $HOME 디렉터리를 채우기 위해 skel 디렉터리를 사용해야 하는 경우 패키지 설치 전에 GITLAB_RUNNER_DISABLE_SKEL 변수를 명시적으로 false로 설정해야 합니다. 예를 들어:

Debian/Ubuntu/Mint의 경우:

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

RHEL/CentOS/Fedora의 경우:

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

참고: skel을 사용하여 $HOME 디렉터리에 추가된 셸 구성은 작업 실행에 방해를 주고 위에서 언급된 문제와 같은 예상치 못한 문제를 일으킬 수 있습니다.