공식 GitLab 리포지터리를 사용하여 GitLab Runner 설치
다음 지원되는 Linux 배포판의 지원 버전에 대한 패키지를 packagecloud을 통해 제공합니다. packagecloud에서 지원되는 새로운 runner deb
또는 rpm
패키지는 새로운 OS 배포판 릴리스가 지원될 때 자동으로 추가됩니다. 추신: 다른 deb
또는 rpm
기반 배포판도 지원될 수 있습니다. 이는 지원되는 GitLab Runner 배포판의 파생되는 배포판 및 호환성 있는 패키지 리포지터리를 갖는 배포판을 의미합니다. 예를 들어, Deepin은 Debian의 파생판이므로 runner Debian 패키지가 Deepin에서 설치되고 실행될 수 있습니다. 또한 다른 Linux 배포판에도 바이너리 파일로 GitLab Runner를 설치할 수 있습니다.
배포판 | 지원 정보 |
---|---|
Debian | https://wiki.debian.org/LTS |
Ubuntu | https://wiki.ubuntu.com/Releases |
LinuxMint | https://linuxmint.com/download_all.php |
Raspbian | |
RHEL | https://access.redhat.com/product-life-cycles?product=Red%20Hat%20Enterprise%20Linux |
Oracle Linux | https://endoflife.date/oracle-linux |
Fedora | https://docs.fedoraproject.org/en-US/releases/eol/ |
Amazon Linux | https://aws.amazon.com/linux/ |
사전 요구 사항
Docker executor를 사용하려면 GitLab Runner를 사용하기 전에 Docker를 설치해야 합니다. 배포판에 따라 배포판별로 Docker를 설치하는 방법은 다릅니다.
GitLab Runner 설치
GitLab Runner를 설치하려면:
-
공식 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 핀을 사용해야 합니다. -
최신 버전의 GitLab Runner를 설치하거나 특정 버전을 설치하려면 다음 단계로 건너뛸 수 있습니다.
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
를 사용하여 이 버전을 설치할 수 있습니다. -
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
-
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
도구를 사용합니다.
이 방법은 패키지의 매뉴얼 검증만을 지원합니다.
-
dpkg-sig
설치apt-get update && apt-get install dpkg-sig
-
패키지 서명 공개 키 다운로드 및 추가
curl -JLO "https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-49F16C5CC3A0F81F.pub.gpg" gpg --import runner-gitlab-runner-49F16C5CC3A0F81F.pub.gpg
-
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.
키 속성 | 값 |
---|---|
이름 | GitLab, Inc.
|
이메일 | support@gitlab.com
|
지문 | 931D A69C FA3A FEBB C97D AA8C 6C57 C29C 6BA7 5A4E
|
만료 | 2025-04-25
|
release.sha256
파일을 서명하기 위해 GitLab Runner 프로젝트에서도 사용됩니다.
https://gitlab-runner-downloads.s3.dualstack.us-east-1.amazonaws.com 버킷에 있는 릴리스에서 사용 가능합니다.이전 GPG 공개 키
과거에 사용되었던 키는 아래 테이블에서 찾을 수 있습니다.
이전에 취소된 키에 대해서는 패키지 서명 확인 구성에서 제거하는 것이 매우 권장됩니다.
이러한 키로 작성된 서명은 더 이상 신뢰해서는 안 됩니다.
일련 번호 | 키 지문 | 상태 | 만료 날짜 | 다운로드(취소된 키만) |
---|---|---|---|---|
1 | 3018 3AC2 C4E2 3A40 9EFB E705 9CE4 5ABC 8807 21D4
| 취소됨
| 2021-06-08
| 취소된 키 다운로드 |
2 | 09E5 7083 F34C CA94 D541 BC58 A674 BF81 35DF A027
| 취소됨
| 2023-04-26
| 취소된 키 다운로드 |
매뉴얼으로 패키지 다운로드
필요한 경우 매뉴얼으로 패키지를 다운로드하고 설치할 수 있습니다.
skel
비활성화
가끔 기본 스켈레톤(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
skel
을 사용하여 $HOME
디렉터리에 추가된 셸 설정은 작업 실행을 방해하고
위에서 언급한 문제와 같은 예기치 못한 문제를 야기할 수 있습니다.