- 전제 조건
- Helm 차트를 사용하여 GitLab Runner 설치
- Helm 차트를 사용하여 GitLab Runner 업그레이드
- 사용 가능한 GitLab Runner Helm 차트 버전 확인
-
Helm 차트를 사용하여 GitLab 러너 구성하기
- 필수 구성
- 추가 구성
- 구성 템플릿을 사용한 캐시
- RBAC 지원 활성화
- 최대 Runner 동시성 제어
- GitLab Runner에서 Docker-in-Docker 컨테이너 실행
- 런너를 위한 권한 있는 컨테이너 실행
- 권한이 상승되지 않은 상태로 컨테이너 빌드하는 최상의 방법
- 비공개 레지스트리에서 이미지 사용
- GitLab에 액세스하는 사용자 정의 인증서 제공
- CI 환경 변수 키로 pod 레이블 설정
- 등록 토큰 또는 러너 토큰을 시크릿에 저장
- Ubuntu 기반의
gitlab-runner
Docker 이미지로 전환 - root가 아닌 사용자로 실행
- FIPS 호환 GitLab 러너 사용하기
- Helm 차트를 사용하여 GitLab 러너 제거하기
-
Kubernetes 설치 문제 해결
ERROR: Job failed (system failure): secrets is forbidden
Unable to mount volumes for pod
- Google Cloud Storage로의 느린 아티팩트 업로드
PANIC: creating directory: mkdir /nonexistent: permission denied
- FATAL: Runner configuration other than name and executor configuration is reserved (specifically –locked, –access-level, –run-untagged, –maximum-timeout, –paused, –tag-list, and –maintenance-note) and cannot be specified when registering with a runner authentication token. This configuration is specified on the GitLab server. Please try again without specifying any of those arguments
GitLab Runner Helm Chart
쿠버네티스 클러스터에 GitLab Runner 인스턴스를 배포하는 공식 방법은 gitlab-runner
Helm 차트를 사용하는 것입니다.
이 차트는 GitLab Runner를 다음과 같이 구성합니다:
- GitLab Runner를 위한 Kubernetes executor를 사용하여 실행합니다.
- GitLab CI/CD에서 받은 각 새 작업에 대해 지정된 네임스페이스 내에서 새로운 파드를 프로비저닝하여 실행합니다.
전제 조건
- 클러스터에서 GitLab 서버의 API에 접근 가능해야 합니다.
- Beta API가 활성화된 Kubernetes 1.4+가 필요합니다.
- 로컬에
kubectl
CLI가 설치되어 있고 클러스터에 대해 인증되어 있어야 합니다. - Helm 클라이언트가 로컬 머신에 설치되어 있어야 합니다.
Helm 차트를 사용하여 GitLab Runner 설치
GitLab Helm 레포지토리를 추가합니다:
helm repo add gitlab https://charts.gitlab.io
Helm 2를 사용하는 경우 Helm을 초기화해야 합니다:
helm init
만약 GitLab Runner의 최신 버전에 액세스할 수 없는 경우 차트를 업데이트해야 합니다. 차트를 업데이트하려면 다음을 실행합니다:
helm repo update gitlab
액세스할 수 있는 GitLab Runner 버전 목록을 보려면 다음을 실행합니다:
helm search repo -l gitlab/gitlab-runner
GitLab Runner를 values.yaml
파일에서 구성한 후 다음을 실행합니다:
# Helm 2의 경우
helm install --namespace <NAMESPACE> --name gitlab-runner -f <CONFIG_VALUES_FILE> gitlab/gitlab-runner
# Helm 3의 경우
helm install --namespace <NAMESPACE> gitlab-runner -f <CONFIG_VALUES_FILE> gitlab/gitlab-runner
여기서:
-
<NAMESPACE>
는 GitLab Runner를 설치하려는 Kubernetes 네임스페이스입니다. -
<CONFIG_VALUES_FILE>
은 사용자 정의 구성을 포함하는 값 파일의 경로입니다. 이를 생성하려면 Helm 차트를 사용하여 GitLab Runner 구성 섹션을 참조하세요.
특정 버전의 GitLab Runner Helm 차트를 설치하려면 --version <RUNNER_HELM_CHART_VERSION>
를 helm install
명령에 추가합니다. 이 방법으로 원하는 버전의 차트를 설치할 수 있지만, 보다 최근의 values.yml
은 이전 버전의 차트와 호환되지 않을 수 있습니다.
Helm 차트를 사용하여 GitLab Runner 업그레이드
GitLab Runner를 업그레이드하기 전에 GitLab에서 Runner를 일시 중지하고 모든 작업이 완료되었는지 확인하세요. Runner를 일시 중지하면 작업이 완료될 때 발생할 수 있는 권한 오류와 같은 문제를 방지할 수 있습니다.
GitLab Runner 차트를 설치한 후 구성 변경 및 차트 업데이트는 helm upgrade
를 사용해야 합니다:
helm upgrade --namespace <NAMESPACE> -f <CONFIG_VALUES_FILE> <RELEASE-NAME> gitlab/gitlab-runner
여기서:
-
<NAMESPACE>
는 GitLab Runner가 설치된 Kubernetes 네임스페이스입니다. -
<CONFIG_VALUES_FILE>
은 사용자 정의 구성을 포함하는 값 파일의 경로입니다. 이를 생성하려면 Helm 차트를 사용하여 GitLab Runner 구성 섹션을 참조하세요. -
<RELEASE-NAME>
은 차트를 설치할 때 지정한 이름입니다. Helm 차트를 사용하여 GitLab Runner 설치 섹션에서는gitlab-runner
로 지정했습니다.
최신 버전이 아닌 특정 버전의 GitLab Runner Helm 차트로 업그레이드하려면 --version <RUNNER_HELM_CHART_VERSION>
를 helm upgrade
명령에 추가합니다.
사용 가능한 GitLab Runner Helm 차트 버전 확인
Helm 차트와 GitLab Runner 버전은 동일한 버전 관리 체계를 사용하지 않습니다. 다음 명령을 사용하여 Helm 차트와 GitLab Runner 간의 버전 매핑을 얻을 수 있습니다:
# Helm 2의 경우
helm search -l gitlab/gitlab-runner
# Helm 3의 경우
helm search repo -l gitlab/gitlab-runner
아래는 결과의 예시입니다:
NAME CHART VERSION APP VERSION DESCRIPTION
gitlab/gitlab-runner 0.58.2 16.5.0 GitLab Runner
gitlab/gitlab-runner 0.58.1 16.5.0 GitLab Runner
gitlab/gitlab-runner 0.58.0 16.5.0 GitLab Runner
gitlab/gitlab-runner 0.57.2 16.4.2 GitLab Runner
gitlab/gitlab-runner 0.57.1 16.4.1 GitLab Runner
gitlab/gitlab-runner 0.57.0 16.4.0 GitLab Runner
...
Helm 차트를 사용하여 GitLab 러너 구성하기
GitLab 러너 구성을 위한 values.yaml
파일을 작성합니다. 기본값을 재정의하는 방법에 대한 정보는 Helm 문서를 참조하십시오.
기본 구성은 차트 저장소의 values.yaml
에서 항상 찾을 수 있습니다.
필수 구성
GitLab 러너가 작동하려면 구성 파일에서 다음을 반드시 지정해야 합니다.
-
gitlabUrl
: 러너를 등록할 GitLab 서버의 전체 URL입니다. 예:https://gitlab.example.com
. -
rbac: { create: true }
: GitLab 러너에게 작업을 실행할 파드를 생성하는 RBAC 규칙을 만듭니다. 사용하려는 기존serviceAccount
가 있는 경우,rbac: { serviceAccountName: "SERVICE_ACCOUNT_NAME" }
도 설정해야 합니다.serviceAccount
에 필요한 최소 권한에 대한 자세한 내용은 runner API 권한 구성을 참조하십시오. -
runnerToken
:- GitLab UI에서 러너를 만들 때 얻는 인증 토큰.
- 토큰을 직접 설정하거나 시크릿에 저장할 수 있습니다.
- 또는 -
-
runnerRegistrationToken
(GitLab 15.6에서 더 이상 사용되지 않음):- GitLab 인스턴스에서 검색한 등록 토큰.
- 토큰을 직접 설정하거나 시크릿에 저장할 수 있습니다.
- 등록 토큰은 향후 GitLab 17.0에서 사용되지 않게 되며 제거될 것입니다.
추가 구성을 지정할 필요가 없는 경우, 이제 Helm 차트를 사용하여 GitLab 러너를 설치할 준비가 되었습니다.
추가 구성
- Helm Chart 0.23.0에서 도입됨 구성 템플릿을 사용합니다. 특정 러너 구성 옵션을 Helm 차트가 인식할 필요 없이, Kubernetes 내에서 GitLab 러너 빌드 파드의 동작을 구성할 수 있습니다.
구성 템플릿 파일을 사용하여 러너의 동작을 구성할 수 있으며, Helm 차트가 특정 러너 구성 옵션을 인식할 필요가 없습니다.
차트 저장소의 values.yaml
파일에서 찾을 수 있는 기본 설정의 일부입니다. config:
섹션의 경우, 형식은 toml
이어야 합니다 (<parameter> = <value>
대신 <parameter>: <value>
로 표시하지 않아야 합니다) config.toml
을 values.yaml
에 임베딩하고 있기 때문입니다.
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:22.04"
특정 실행자 구성은 values.yaml
에 문서화되어 있습니다.
구성 템플릿을 사용한 캐시
구성 템플릿과 함께 캐시를 사용하려면 values.yaml
에서 다음 변수를 설정하십시오.
-
runners.cache.secretName
: 객체 스토리지 제공자 (s3access
,gcsaccess
,google-application-credentials
, 또는azureaccess
)에 대한 시크릿 이름입니다. -
runners.config
: 캐시에 대한 다른 설정과 함께 사용합니다.toml
형식으로 설정합니다.
S3
예를 들어, 정적 자격 증명을 사용하여 S3를 구성하는 예시입니다:
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:22.04"
[runners.cache]
Type = "s3"
Path = "runner"
Shared = true
[runners.cache.s3]
ServerAddress = "s3.amazonaws.com"
BucketName = "my_bucket_name"
BucketLocation = "eu-west-1"
Insecure = false
AuthenticationType = "access-key"
cache:
secretName: s3access
다음으로, accesskey
및 secretkey
를 포함하는 s3access
쿠버네티스 시크릿을 생성합니다:
kubectl create secret generic s3access \
--from-literal=accesskey="YourAccessKey" \
--from-literal=secretkey="YourSecretKey"
Google Cloud Storage (GCS)
정적 자격 증명 직접 구성
다음 예는 액세스 ID 및 개인 키로 자격 증명을 구성하는 방법을 보여줍니다. GCS with credentials with an access ID and a private key :
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:22.04"
[runners.cache]
Type = "gcs"
Path = "runner"
Shared = true
[runners.cache.gcs]
BucketName = "runners-cache"
cache:
secretName: gcsaccess
다음으로 gcs-access-id
및 gcs-private-key
를 포함하는 gcsaccess
쿠버네티스 시크릿을 만듭니다.
kubectl create secret generic gcsaccess \
--from-literal=gcs-access-id="YourAccessID" \
--from-literal=gcs-private-key="YourPrivateKey"
GCP에서 다운로드한 JSON 파일에서의 정적 자격 증명
다음 예는 구글 클라우드 플랫폼에서 다운로드한 JSON 파일로 GCS를 구성하는 방법을 보여줍니다. configure GCS with credentials in a JSON file :
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:22.04"
[runners.cache]
Type = "gcs"
Path = "runner"
Shared = true
[runners.cache.gcs]
BucketName = "runners-cache"
cache:
secretName: google-application-credentials
secrets:
- name: google-application-credentials
다음으로 google-application-credentials
를 만들고 해당 JSON 파일을로드하는 쿠버네티스 시크릿을 만듭니다.
kubectl create secret generic google-application-credentials \
--from-file=gcs-application-credentials-file=./path-to-your-google-application-credentials-file.json
Azure
다음 예는 Azure Blob Storage를 구성하는 방법을 보여줍니다 :
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:22.04"
[runners.cache]
Type = "azure"
Path = "runner"
Shared = true
[runners.cache.azure]
ContainerName = "CONTAINER_NAME"
StorageDomain = "blob.core.windows.net"
cache:
secretName: azureaccess
다음으로 azure-account-name
및 azure-account-key
를 포함하는 azureaccess
쿠버네티스 시크릿을 만듭니다.
kubectl create secret generic azureaccess \
--from-literal=azure-account-name="YourAccountName" \
--from-literal=azure-account-key="YourAccountKey"
Helm Chart에서 캐싱에 대해 자세히 알아보려면 values.yaml
을 참조하십시오.
RBAC 지원 활성화
클러스터에 RBAC가 활성화되어 있는 경우 차트가 자체 서비스 계정을 만들도록 하거나 별도로 제공할 수 있습니다.
차트가 대신 서비스 계정을 생성하도록 하려면 rbac.create
를 true로 설정하세요 :
rbac:
create: true
기존의 서비스 계정을 사용하려면 다음과 같이 사용하세요 :
rbac:
create: false
serviceAccountName: your-service-account
최대 Runner 동시성 제어
쿠버네티스에 배포된 단일 GitLab Runner는 최대 10
까지의 동시에 여러 작업을 실행할 수 있도록 자동으로 추가 Runner 팟을 시작하여 병렬로 실행합니다.
concurrent
설정은 한 번에 허용되는 팟의 최대 수를 제어하며 기본값은 10
입니다 :
## 최대 동시 작업 수를 구성합니다
## 참조: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10
GitLab Runner에서 Docker-in-Docker 컨테이너 실행
dind를 실행하는 권한이있는 컨테이너에서 활성화하는 방법 및 Docker에서 dind 실행에 대한 GitLab Runner 문서를 참조하세요.
런너를 위한 권한 있는 컨테이너 실행
GitLab Runner에게 권한 있는 컨테이너를 실행하도록 지시할 수 있습니다. GitLab CI/CD 작업에서 Docker 실행 파일을 사용해야하는 경우 이를 활성화해야 할 수 있습니다.
이것은 GitLab CI/CD Runner 문서에서 읽을 수있는 여러 위험과 함께 제공됩니다.
위험을 인정하고 GitLab Runner 인스턴스가 신뢰하는 특정 프로젝트의 CI 작업을 허용하는 경우 values.yaml
에서 권한을 활성화 할 수 있습니다 :
runners:
config: |
[[runners]]
[runners.kubernetes]
# 모든 컨테이너를 권한있게 실행합니다.
# 상세 내용은 https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerskubernetes-section를 참조하세요.
privileged = true
...
권한이 상승되지 않은 상태로 컨테이너 빌드하는 최상의 방법
Docker-in-Docker로 컨테이너를 빌드하려면 Docker의 권한이 상승된 상태여야 합니다. Google의 Kaniko는 권한이 상승되지 않은 상태에서 작동하는 대체품으로, Kubernetes GitLab Runner에서 테스트되었습니다.
GitLab에서 Kaniko로 최소 권한 컨테이너 빌드 동영상은 Kaniko Docker 빌드 실제 작업 예제 프로젝트를 안내합니다. 이 프로젝트는 Kaniko 및 GitLab CI/CD를 사용하여 이미지 빌드에 대한 문서를 활용합니다.
실제 작업 예제 프로젝트는 테스트를 위해 고객 자신의 그룹이나 인스턴스로 복사할 수 있습니다. 다른 GitLab CI 패턴이 프로젝트 페이지 Kaniko Docker Build에서 시연되는 자세한 내용을 확인할 수 있습니다.
비공개 레지스트리에서 이미지 사용
비공개 레지스트리에서 이미지를 사용하려면 imagePullSecrets을 구성해야 합니다. imagePullSecrets를 생성하는 방법에 대한 자세한 내용은 문서를 참조하세요.
CI/CD 작업에 사용되는 Kubernetes 네임스페이스에 하나 이상의 시크릿을 생성해야 합니다.
다음 명령을 사용하여 image_pull_secrets
와 호환되는 시크릿을 생성할 수 있습니다:
kubectl create secret docker-registry <시크릿_이름> \
--namespace <네임스페이스> \
--docker-server="https://<레지스트리_서버>" \
--docker-username="<레지스트리_사용자명>" \
--docker-password="<레지스트리_비밀번호>"
GitLab Runner Helm 차트 v0.53.x 이상에서는 values.yaml
에서 더 이상 사용되지 않는 속성을 지원하지 않으며, runners.imagePullSecrets
가 그 중 하나입니다. image_pull_secret
를 구성하려면 사용자가 제공된 runners.config
템플릿에 설정해야 합니다.
runners:
config: |
[[runners]]
[runners.kubernetes]
## 하나 이상의 imagePullSecrets를 지정
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
##
image_pull_secrets = [your-image-pull-secret]
GitLab Runner Helm 차트 v0.52.x 이하에서는 runners.imagePullSecrets
를 구성하면 컨테이너가 이미지 엔트리포인트 스크립트에 --kubernetes-image-pull-secrets "<시크릿_이름>"
을 추가합니다. 이렇게 하면 Kubernetes 실행기 config.toml
설정에서 image_pull_secrets
매개변수를 구성할 필요가 없어집니다.
runners:
imagePullSecrets: [your-image-pull-secret]
형식에 주목하세요. 한 개 이상의 시크릿 이름의 배열이 필요합니다. 여러 레지스트리 자격 증명을 사용하더라도 반드시 필요합니다.
GitLab에 액세스하는 사용자 정의 인증서 제공
GitLab Runner Helm 차트에 Kubernetes Secret를 제공하여 컨테이너의 /home/gitlab-runner/.gitlab-runner/certs
디렉터리를 채울 수 있습니다.
시크릿의 각 키 이름은 디렉터리에서의 파일 이름으로 사용되며, 파일 내용은 해당 키와 연결된 값입니다:
- 사용된 키/파일 이름은
<gitlab.hostname>.crt
형식이어야 합니다. 예를 들어gitlab.your-domain.com.crt
입니다. - 중간 인증서는 서버 인증서와 동일한 파일에 연결되어야 합니다.
- 사용된 호스트 이름은 인증서가 등록된 이름이어야 합니다.
GitLab Helm 차트를 자동 생성된 와일드카드 자체 서명 인증서 방법을 사용하여 설치했다면 시크릿이 자동으로 생성됩니다.
## certsSecretName을 설정하여 GitLab Runner에서 사용할 사용자 정의 인증서 전달
## 동일한 네임스페이스 내에서 Kubernetes Secret Object의 리소스 이름을 제공합니다.
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates-targeting-the-gitlab-server
##
certsSecretName: RELEASE-wildcard-tls-chain
GitLab Runner Helm 차트에서는 시크릿을 자동으로 생성하지 않습니다. 시크릿을 생성하려면 Kubernetes에게 인증서를 시크릿으로 저장하고 컨테이너에 파일로 제공하도록 지시해야 합니다. 이를 위해 다음 명령을 실행하세요:
kubectl create secret generic <시크릿_이름> \
--namespace <네임스페이스> \
--from-file=<인증서_파일이름>
여기서:
-
<네임스페이스>
는 GitLab Runner를 설치할 Kubernetes 네임스페이스입니다. -
<시크릿_이름>
은 Kubernetes Secret 리소스 이름입니다. (예:gitlab-domain-cert
.) -
<인증서_파일이름>
은 현재 디렉터리에 있는 인증서의 파일 이름입니다. (예:cert-directory/my-gitlab-certificate.crt
)
소스 파일 <인증서_파일이름>
이 현재 디렉터리에 없거나 <gitlab.hostname.crt>
형식을 따르지 않는 경우 대상에서 사용할 파일 이름을 지정해야 합니다:
kubectl create secret generic <시크릿_이름> \
--namespace <네임스페이스> \
--from-file=<타겟_파일이름>=<인증서_파일이름>
여기서:
-
<타겟_파일이름>
은 Runner 컨테이너에 제공되는 인증서 파일의 이름입니다. (예:gitlab.hostname.crt
.) -
<인증서_파일이름>
은 시크릿으로 가져올 현재 디렉터리 상대 경로에 있는 인증서 파일의 이름입니다. (예:cert-directory/my-gitlab-certificate.crt
)
그런 다음 시크릿 이름을 GitLab Runner 차트에 제공해야 합니다.
다음을 values.yaml
에 추가하세요:
## GitLab 러너가 사용할 사용자 정의 인증서를 전달하도록 certsSecretName을 설정합니다
## 동일한 네임스페이스 내에서 Kubernetes Secret Object의 리소스 이름을 제공합니다.
## 이는 /home/gitlab-runner/.gitlab-runner/certs/ 디렉토리를 채우는 데 사용됩니다
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
certsSecretName: <SECRET NAME>
여기서:
-
<SECRET_NAME>
은 Kubernetes Secret 리소스 이름으로, 위 예제에서는gitlab-domain-cert
와 같습니다.
GitLab 러너가 이러한 인증서를 사용하는 방법에 대한 자세한 정보는 러너 문서에서 찾을 수 있습니다.
CI 환경 변수 키로 pod 레이블 설정
현재 values.yaml
파일 내에서 환경 변수를 pod 레이블로 사용하는 것은 불가능합니다.
우리는 이 문제에 대해 작업 중입니다: 환경 변수 키를 pod 레이블로 설정할 수 없음.
일시적인 해결책으로 이 문제에 설명된 워크어라운드를 사용하세요.
등록 토큰 또는 러너 토큰을 시크릿에 저장
- 16.1에서 도입되었습니다.
GitLab UI에서 생성된 러너를 등록하려면 values.yml
에서 runnerToken
을 지정합니다. runnerToken
은 UI에서 러너를 만들 때 잠깐 표시됩니다.
values.yml
에 토큰을 저장하면 보안 위험이 될 수 있습니다, 특히 이를 git
에 커밋하는 경우 더 그렇습니다. 대신 Kubernetes 시크릿 내에 이러한 토큰 값을 저장한 후, values.yml
의 runners.secret
값을 시크릿의 이름으로 업데이트하세요.
이미 등록된 러너를 사용하려면 해당 러너를 식별하는 데 사용된 토큰으로 runner-token
을 설정하세요. 새 러너를 등록하려면 runner-registration-token
에 등록 토큰 (deprecated)을 설정하세요.
예:
- 등록 토큰이 있는 시크릿 생성
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
data:
runner-registration-token: "" # 호환성을 위해 빈 문자열로 남겨 둘 필요가 있습니다
runner-token: "REDACTED"
kubectl apply --namespace <NAMESPACE> -f gitlab-runner-secret.yaml
-
values.yaml
에서 다음을 구성합니다:
runners:
secret: gitlab-runner-secret
이 예시에서는 gitlab-runner-secret
시크릿을 사용하고, runner-token
의 값을 러너 등록에 사용합니다.
참고:
시크릿 관리 솔루션이 runner-registration-token
에 빈 문자열을 설정할 수 없는 경우, 어떤 문자열이라도 설정할 수 있습니다 - 이는 runner-token
이 있을 때 무시될 것입니다.
Ubuntu 기반의 gitlab-runner
Docker 이미지로 전환
기본적으로 GitLab 러너 Helm 차트는 musl libc
를 사용하는 gitlab/gitlab-runner
이미지의 Alpine 버전을 사용합니다. 경우에 따라 glibc
를 사용하는 Ubuntu 기반 이미지로 전환하고 싶을 수 있습니다.
이를 위해 values.yaml
파일을 다음과 같이 업데이트하세요:
# Ubuntu 이미지를 지정합니다. 버전을 설정하세요. `ubuntu` 또는 `latest` 태그를 사용할 수도 있습니다.
image: gitlab/gitlab-runner:v16.5.0
# 보안 컨텍스트 값을 Ubuntu 이미지의 사용자 ID로 업데이트하세요
securityContext:
fsGroup: 999
runAsUser: 999
root가 아닌 사용자로 실행
기본적으로 GitLab 러너 이미지는 root가 아닌 사용자로는 작동하지 않습니다. GitLab 러너 UBI 및 GitLab 러너 Helper UBI 이미지는 해당 시나리오를 위해 설계되었습니다. 이들을 사용하려면 GitLab 러너 및 GitLab 러너 Helper 이미지를 변경하세요:
참고:
run_as_user
가 nonroot
사용자(59417)의 사용자 ID를 가리키더라도, 이미지는 어떤 사용자 ID에서도 작동합니다.
이 사용자 ID가 root 그룹의 일부인 것이 중요합니다. root 그룹의 일부일 뿐이므로 특정 권한을 부여하지는 않습니다.
image: registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp:v16.5.0
securityContext:
runAsNonRoot: true
runAsUser: 999
runners:
config: |
[[runners]]
[runners.kubernetes]
helper_image = "registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-helper-ocp:x86_64-v16.5.0"
[runners.kubernetes.pod_security_context]
run_as_non_root = true
run_as_user = 59417
FIPS 호환 GitLab 러너 사용하기
FIPS 호환 GitLab 러너를 사용하려면 다음과 같이 GitLab 러너 이미지와 헬퍼 이미지를 변경하세요:
image: gitlab/gitlab-runner:ubi-fips
runners:
config: |
[[runners]]
[runners.kubernetes]
helper_image_flavor = "ubi-fips"
Helm 차트를 사용하여 GitLab 러너 제거하기
GitLab 러너를 제거하기 전에 GitLab에서 러너를 일시 중지하고 모든 작업이 완료되었는지 확인하세요. 러너를 일시 중지하면 작업 완료시 인가 오류와 같은 문제가 발생하는 것을 방지합니다.
GitLab 러너 차트를 제거하려면 다음을 실행하세요:
helm delete --namespace <NAMESPACE> <릴리스 이름>
여기서:
-
<NAMESPACE>
는 GitLab 러너가 설치된 Kubernetes 네임스페이스입니다. -
<릴리스 이름>
은 설치할 때 차트에 지정한 이름입니다. Helm 차트를 사용하여 GitLab 러너 설치하기에서는gitlab-runner
라고 지정했습니다.
Kubernetes 설치 문제 해결
ERROR: Job failed (system failure): secrets is forbidden
다음 오류가 표시되면:
Using Kubernetes executor with image alpine ...
ERROR: Job failed (system failure): secrets is forbidden: User "system:serviceaccount:gitlab:default" cannot create resource "secrets" in API group "" in the namespace "gitlab"
RBAC 지원을 활성화하여 오류를 수정하세요.
Unable to mount volumes for pod
필수 시크릿에 대한 볼륨 마운트 실패가 발생하는 경우, 등록 토큰이나 러너 토큰을 시크릿에 저장했는지 확인하세요.
Google Cloud Storage로의 느린 아티팩트 업로드
Google Cloud Storage로의 아티팩트 업로드는 러너 헬퍼 파드가 CPU에 바인딩되어 성능이 떨어지는 경우가 있습니다. 이는 대역폭 속도가 느려지는 형태로 나타날 것입니다.
러너 헬퍼 파드 CPU 제한을 늘려 이를 완화할 수 있습니다:
runners:
config: |
[[runners]]
[runners.kubernetes]
helper_cpu_limit = "250m"
PANIC: creating directory: mkdir /nonexistent: permission denied
이 오류를 해결하려면 Ubuntu 기반 GitLab 러너 도커 이미지로 전환하세요.
FATAL: Runner configuration other than name and executor configuration is reserved (specifically –locked, –access-level, –run-untagged, –maximum-timeout, –paused, –tag-list, and –maintenance-note) and cannot be specified when registering with a runner authentication token. This configuration is specified on the GitLab server. Please try again without specifying any of those arguments
이 오류는 GitLab 러너 Helm 차트를 설치한 후에 파드 로그에서 발생할 수 있습니다. 이는 인증 토큰을 사용하고 시크릿을 통해 토큰을 제공했을 때 발생합니다. 이 오류를 수정하려면 값을 담은 YAML 파일을 확인하고 사용되지 않는 값을 사용하지 않도록 하세요. 사용되지 않는 값에 대한 자세한 내용은 GitLab Runner와 Helm 차트 설치하기를 참고하세요.