• 사전 요구 사항
• GitLab Runner 설치
  • APT 핀
• GitLab Runner 업그레이드
• 패키지 설치를 위한 GPG 서명
  • 리포지터리 메타데이터 서명
  • 패키지 서명
    • RPM 기반 배포판
    • DEB 기반 배포
    • 현재 GPG 공개 키
    • 이전 GPG 공개 키
• 매뉴얼으로 패키지 다운로드
• skel 비활성화

공식 GitLab 리포지터리를 사용하여 GitLab Runner 설치

다음 지원되는 Linux 배포판의 지원 버전에 대한 패키지를 packagecloud을 통해 제공합니다. packagecloud에서 지원되는 새로운 runner deb 또는 rpm 패키지는 새로운 OS 배포판 릴리스가 지원될 때 자동으로 추가됩니다. 추신: 다른 deb 또는 rpm 기반 배포판도 지원될 수 있습니다. 이는 지원되는 GitLab Runner 배포판의 파생되는 배포판 및 호환성 있는 패키지 리포지터리를 갖는 배포판을 의미합니다. 예를 들어, Deepin은 Debian의 파생판이므로 runner Debian 패키지가 Deepin에서 설치되고 실행될 수 있습니다. 또한 다른 Linux 배포판에도 바이너리 파일로 GitLab Runner를 설치할 수 있습니다.

사전 요구 사항

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 핀을 사용해야 합니다.

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
   

   RHEL 배포판에는 FIPS 140-2 호환 버전의 GitLab Runner가 있습니다. 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. Runner를 등록합니다.

위의 단계를 완료하면 runner가 시작되어 프로젝트에서 사용할 준비가 된 상태입니다!

GitLab Runner의 가장 일반적인 문제에 대해 설명하는 FAQ 섹션을 반드시 읽어보세요.

APT 핀

Debian Stretch에는 gitlab-ci-multi-runner라는 네이티브 패키지가 있습니다. 공식 리포지터리에서 gitlab-runner를 설치하면 공식 리포지터리에서 내려받은 해당 패키지가 높은 우선순위를 가집니다.

우리 패키지를 사용하려면 해당 패키지의 출처를 매뉴얼으로 설정해야 합니다. 가장 좋은 방법은 핀 파일 구성 파일을 추가하는 것입니다.

이렇게 하면 공식 리포지터리에 대한 다음 GitLab Runner 패키지의 업데이트는 동일한 출처를 사용하여 매뉴얼으로든 자동으로든 수행됩니다:

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 업그레이드

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 패키지 문서에서 찾을 수 있습니다. 이 문서에는 과거에 사용된 모든 키들에 대한 디렉터리도 나열되어 있습니다.

패키지 서명

리포지터리 메타데이터 서명은 다운로드된 버전 정보가 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일 것입니다. (불안정한 릴리스의 경우 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
    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.

이전 GPG 공개 키

과거에 사용되었던 키는 아래 테이블에서 찾을 수 있습니다.

이전에 취소된 키에 대해서는 패키지 서명 확인 구성에서 제거하는 것이 매우 권장됩니다.

이러한 키로 작성된 서명은 더 이상 신뢰해서는 안 됩니다.

매뉴얼으로 패키지 다운로드

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

skel 비활성화

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

가끔 기본 스켈레톤(skel) 디렉터리는 GitLab Runner에 문제를 일으키고, 작업을 실행하지 못할 수 있습니다.

GitLab Runner 12.10에서 새로운 사용자의 $HOME 디렉터리를 만들 때 GITLAB_RUNNER_DISABLE_SKEL라는 특별한 변수를 지원하도록 추가했습니다. 이를 true로 설정하면 skel을 사용하지 않고 새로운 $HOME 디렉터리를 만듭니다.

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

만약 어떠한 이유로든 skel 디렉터리를 사용하여 새로 만들어진 $HOME 디렉터리를 채우려면 패키지 설치 전에 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