GitLab Runner Helm Chart

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed

Kubernetes 클러스터에 GitLab Runner 인스턴스를 배포하는 공식 방법은 gitlab-runner Helm 차트를 사용하는 것입니다.

이 차트는 GitLab Runner를 다음과 같이 구성합니다:

GitLab Runner를 위한 Kubernetes executor를 사용하여 실행합니다.
GitLab CI/CD에서 받은 각 새 작업에 대해 지정된 네임스페이스 내에 새로운 파드를 프로비저닝하여 실행합니다.

전제 조건

Kubernetes 클러스터에서 GitLab 서버의 API에 접근할 수 있어야 합니다.
Kubernetes 1.4+ 및 베타 API가 활성화되어 있어야 합니다.
로컬에 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

values.yaml 파일에서 GitLab Runner를 구성한 후, 다음을 실행하십시오:

# 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에서 러너를 일시 중지하고 모든 작업이 완료되었는지 확인하십시오. 러너를 일시 중지하면 작업 완료 시에 발생할 수 있는 인가 오류와 같은 문제를 방지할 수 있습니다.

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 Runner 구성

GitLab Runner 구성을 위한 values.yaml 파일을 생성하십시오. 값 파일이 기본값을 재정의하는 방법에 대한 정보는 Helm 문서에서 확인할 수 있습니다.

기본 구성은 차트 리포지터리의 values.yaml에서 언제나 찾을 수 있습니다.

필수 구성

GitLab Runner가 작동하려면 구성 파일에서 반드시 다음을 지정해야 합니다:

gitlabUrl: 러너를 등록할 GitLab 서버의 전체 URL입니다. 예: https://gitlab.example.com.
rbac: { create: true }: GitLab Runner가 작업을 실행하기 위해 새로운 파드를 생성하는 RBAC 규칙을 생성합니다. 사용하려는 기존 serviceAccount가 있는 경우 rbac: { serviceAccountName: "SERVICE_ACCOUNT_NAME" }도 설정해야 합니다. serviceAccount에 필요한 최소 권한에 대한 자세한 내용은 러너(runner) API 권한 구성을 참조하십시오.
runnerToken:
- GitLab UI에서 러너를 생성할 때 획득한 인증 토큰입니다.
- 인증 토큰을 직접 설정하거나 시크릿에 저장할 수 있습니다.
- 또는 -
runnerRegistrationToken (GitLab 15.6의 deprecated):
- GitLab 인스턴스에서 검색한 등록 토큰입니다.
- 인증 토큰을 직접 설정하거나 시크릿에 저장할 수 있습니다.
- 등록 토큰은 GitLab 17.0에 삭제될 예정입니다.

추가 구성을 지정할 필요가 없는 경우, 이제 GitLab Runner를 설치할 준비가 되었습니다.

추가 구성

History

Introduced configuration template in Helm Chart 0.23.0. See deprecation issue.

구성 템플릿 파일을 사용하여 쿠버네티스 내의 GitLab Runner 빌드 pod의 동작을 구성할 수 있습니다. 헬름 차트에서 구체적인 Runner 구성 옵션을 알 필요 없이 구성 템플릿을 사용하여 러너의 어떤 필드든 구성할 수 있습니다.

차트 리포지터리의 values.yaml 파일에서 기본 설정 블록의 스니펫을 확인할 수 있습니다. config: 섹션에 대해 toml 형식이어야 하며, values.yaml에 config.toml을 삽입할 때 <parameter>: <value> 대신 <parameter> = <value> 형식이어야 함을 유념해야 합니다.

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를 구성하는 방법을 보여줍니다:

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를 구성하는 방법을 보여줍니다:

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

그 다음, GCS 애플리케이션 증명 파일을 로드하는 google-application-credentials 쿠버네티스 시크릿을 생성합니다:

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"

헬름 차트의 캐싱에 대해 자세히 알아보려면 values.yaml를 확인하세요.

RBAC 지원 활성화

클러스터에 RBAC가 활성화되어 있다면, 차트가 자체 서비스 계정을 생성하거나 사용자가 직접 제공할 수 있습니다.

차트가 대신 서비스 계정을 생성하도록 하려면 rbac.create를 true로 설정하세요:

rbac:
  create: true

이미 존재하는 서비스 계정을 사용하려면 다음을 사용하세요:

rbac:
  create: false
  serviceAccountName: your-service-account

최대 Runner 동시성 제어

Kubernetes에 배포된 단일 GitLab Runner는 추가적인 Runner pod를 자동으로 시작함으로써 병렬로 여러 작업을 실행할 수 있습니다. concurrent 설정은 한 번에 허용되는 pod의 최대 수를 제어하며 기본값은 10입니다.

## 최대 동시 작업 수를 구성합니다
## 참조: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10

GitLab Runner로 Docker-in-Docker 컨테이너 실행

실행 가능한 방법에 대한 자세한 내용은 실행 권한있는 컨테이너에 대한 러너를 참조하고, GitLab Runner 설명서에서 dind를 실행하는 방법을 확인하세요.

러너를 위한 실행 권한있는 컨테이너 실행

GitLab Runner에게 실행 권한있는 컨테이너를 사용하여 실행하도록 지시할 수 있습니다. GitLab CI/CD 작업 내에서 Docker 실행 파일을 사용해야 하는 경우에는 이 기능을 활성화해야 할 수 있습니다.

이에는 여러 가지 리스크가 따르며, 이에 대한 자세한 내용은 GitLab CI/CD Runner 설명서에서 확인할 수 있습니다.

위험이 허용 가능하고, GitLab Runner 인스턴스가 신뢰할 수 있는 GitLab 프로젝트에 등록되어 있다면 values.yaml에서 권한있는 모드를 활성화할 수 있습니다.

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        # 모든 컨테이너에 권한 있는 플래그를 사용하여 실행합니다.
        # 자세한 내용은 https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerskubernetes-section을 확인하세요.
        privileged = true
        ...

GitLab Runner Helm Chart v0.53.x 이후로는 values.yaml에서 사용되지 않는 프로퍼티는 더 이상 지원되지 않으며, runners.imagePullSecrets 또한 이에 속합니다. image_pull_secret를 구성하려면 사용자가 runners.config에 제공된 config.toml 템플릿에 설정해야 합니다.

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        ## 하나 이상의 imagePullSecrets를 지정합니다
        ## 참조: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
        ##
        image_pull_secrets = [your-image-pull-secret]

GitLab Runner Helm Chart v0.52.x 및 이전버전에서는 runners.imagePullSecrets를 구성하면, 컨테이너가 이미지 entrypoint 스크립트에 --kubernetes-image-pull-secrets "<SECRET_NAME>"를 추가합니다. 이를 통해 Kubernetes executor config.toml 설정의 image_pull_secrets 파라미터를 구성할 필요가 없어집니다.

runners:
  imagePullSecrets: [your-image-pull-secret]

포맷을 유의해야 합니다. 값에는 Kubernetes 리소스에서의 관례인 name 태그가 접두어로 붙지 않습니다. 여러 개의 레지스트리 자격 증명을 사용하더라도 하나 이상의 비밀 이름 배열이 필요합니다.

GitLab에서 액세스하는데 사용하는 사용자 정의 인증서 제공

GitLab Runner Helm Chart에 Kubernetes Secret를 제공하여 컨테이너의 /home/gitlab-runner/.gitlab-runner/certs 디렉터리를 채우도록 할 수 있습니다.

시크릿의 각 키 이름은 시크릿 내용인 파일명으로 사용되며, 파일 내용은 키와 연결된 값으로 채워집니다:

사용된 키/파일 이름은 <gitlab.hostname>.crt 형식이어야 하며 예를 들어 gitlab.your-domain.com.crt입니다.
중간 인증서를 서버 인증서와 동일한 파일에 연결해야 합니다.
사용된 호스트 이름은 인증서가 등록된 호스트여야 합니다.

GitLab Helm Chart를 자동 생성된 자체 서명 와일드카드 인증서 방법으로 설치한 경우 자동으로 시크릿이 생성됩니다.

## certsSecretName을 설정하여 GitLab Runner에서 사용할 사용자 정의 인증서를 전달합니다.
## 동일한 네임스페이스의 Kubernetes Secret 오브젝트의 리소스 이름을 제공하세요.
## 참조: 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 차트는 시크릿을 자동으로 생성하지 않습니다. 시크릿을 만들려면 쿠버네티스에게 인증서를 시크릿으로 저장하여 GitLab Runner 컨테이너에 파일로 제공하도록 지시해야 합니다. 이를 위해 다음 명령을 실행하세요:

kubectl create secret generic <SECRET_NAME> \
  --namespace <NAMESPACE> \
  --from-file=<CERTIFICATE_FILENAME>

다음과 같습니다:

<NAMESPACE>는 GitLab Runner를 설치할 쿠버네티스 네임스페이스입니다.
<SECRET_NAME>은 쿠버네티스 시크릿 리소스 이름입니다. (예: gitlab-domain-cert.)
<CERTIFICATE_FILENAME>은 시크릿으로 가져올 현재 디렉터리의 인증서 파일 이름입니다.

소스 파일 <CERTIFICATE_FILENAME>이 현재 디렉터리에 없거나 <gitlab.hostname.crt> 형식을 따르지 않는다면 대상에서 사용할 파일 이름을 지정해야 합니다:

kubectl create secret generic <SECRET_NAME> \
  --namespace <NAMESPACE> \
  --from-file=<TARGET_FILENAME>=<CERTIFICATE_FILENAME>

다음과 같습니다:

<TARGET_FILENAME>은 Runner 컨테이너에 제공되는 인증서 파일 이름입니다. (예: gitlab.hostname.crt.)
<CERTIFICATE_FILENAME>은 시크릿으로 가져올 현재 디렉터리의 인증서 파일 이름입니다. (예: cert-directory/my-gitlab-certificate.crt)

그런 다음 시크릿 이름을 GitLab Runner 차트에 제공해야 합니다. 다음을 values.yaml에 추가하세요:

## 사용자 정의 인증서를 GitLab Runner에서 사용하도록 certsSecretName을 설정합니다
## 동일한 네임스페이스 내에 쿠버네티스 시크릿 오브젝트의 리소스 이름을 제공합니다.
## /home/gitlab-runner/.gitlab-runner/certs/ 디렉터리에 해당 리소스가 채워집니다
## 참조: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
certsSecretName: <SECRET NAME>

여기서:

<SECRET_NAME>은 위 예제와 같이 쿠버네티스 시크릿 리소스 이름입니다, gitlab-domain-cert.

이러한 인증서를 GitLab Runner가 어떻게 사용하는지에 대한 자세한 정보는 Runner Documentation에서 찾을 수 있습니다.

CI 환경 변수 키로 pod 라벨 설정

현재 values.yaml 파일에서 환경 변수를 pod 라벨로 사용하는 것은 불가능합니다. 다음 이슈에서 작업 중입니다: Can’t set environment variable key as pod label. 일시적인 해결책으로 이슈에 설명된 해결책을 사용하세요.

등록 토큰 또는 러너 토큰을 시크릿으로 저장

16.1에 도입되었습니다.

GitLab UI에서 생성된 러너를 등록하려면 values.yml에서 runnerToken을 지정해야 합니다. runnerToken은 UI에서 러너를 생성할 때 잠깐 표시됩니다.

git에 커밋하는 경우 values.yml에 토큰을 저장하는 것은 보안 리스크가 될 수 있습니다. 대신 이러한 토큰의 값을 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` 도커 이미지로 전환

기본적으로 GitLab Runner 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 Runner 이미지는 root 이외의 사용자로 작동하지 않습니다. GitLab Runner UBI 및 GitLab Runner Helper UBI 이미지는 해당 시나리오를 위해 설계되었습니다. 이를 사용하려면 GitLab Runner 및 GitLab Runner Helper 이미지를 변경하세요:

run_as_user가 nonroot 사용자 (59417)의 사용자 ID를 가리키더라도 이미지는 모든 사용자 ID와 작동합니다. 이 사용자 ID가 루트 그룹의 일부임이 중요합니다. 루트 그룹의 일부가 되는 것에는 특정 권한이 부여되지 않습니다.

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 Runner 사용하기

FIPS 호환 GitLab Runner를 사용하려면 GitLab Runner 이미지와 Helper 이미지를 다음과 같이 변경하세요:

image: gitlab/gitlab-runner:ubi-fips

runners:
    config: |
        [[runners]]
          [runners.kubernetes]
            helper_image_flavor = "ubi-fips"

Helm 차트를 사용하여 GitLab Runner 제거하기

GitLab Runner를 제거하기 전에 GitLab에서 Runner를 일시 중지하고 모든 작업이 완료되었는지 확인하세요. Runner를 일시 중지하면 작업이 완료될 때 발생할 수 있는 권한 부여 오류와 같은 문제를 예방할 수 있습니다.

GitLab Runner 차트를 제거하려면 다음을 실행하세요:

helm delete --namespace <NAMESPACE> <RELEASE-NAME>

여기서:

<NAMESPACE>은 GitLab Runner가 설치된 Kubernetes 네임스페이스입니다.
<RELEASE-NAME>은 설치할 때 차트에 지정한 이름입니다. Helm 차트를 사용하여 GitLab Runner 설치에서는 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`

필수 시크릿에 대한 볼륨 마운트 실패가 표시된다면, 등록 토큰이나 Runner 토큰을 시크릿에 저장했는지 확인하세요.

Google Cloud Storage에 대한 느린 아티팩트 업로드

Google Cloud Storage로의 아티팩트 업로드는 Helper pod가 CPU에 바인딩되어 성능이 저하될 수 있습니다. 이는 대역폭 속도가 느린 형태로 나타납니다.

Helper pod CPU Limit를 증가시킴으로써 이를 완화할 수 있습니다:

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        helper_cpu_limit = "250m"

`PANIC: creating directory: mkdir /nonexistent: permission denied`

이 오류를 해결하려면 Ubuntu 기반 GitLab Runner Docker 이미지로 전환하세요.

이 오류는 GitLab Runner Helm 차트를 설치한 후에 pod 로그에서 발생할 수 있습니다. 이 오류는 인증 토큰을 사용하고 시크릿을 통해 토큰을 제공한 경우 발생합니다. 이 오류를 수정하려면 값을 나타내는 YAML 파일을 검토하여 사용되고 있지 않은 값이 있는지 확인하세요. 사용되고 있지 않은 값에 대한 자세한 내용은 Helm 차트를 사용하여 GitLab Runner 설치를 참조하세요.

GitLab Runner Helm Chart

전제 조건

Helm 차트를 사용하여 GitLab Runner 설치

Helm 차트를 사용하여 GitLab Runner 업그레이드

사용 가능한 GitLab Runner Helm 차트 버전 확인

Helm 차트를 사용하여 GitLab Runner 구성

필수 구성

추가 구성

구성 템플릿으로 캐시 사용하기

S3

Google Cloud Storage (GCS)

정적 자격 증명 직접 구성

GCP에서 다운로드한 JSON 파일에 정적 자격 증명

Azure

RBAC 지원 활성화

최대 Runner 동시성 제어

GitLab Runner로 Docker-in-Docker 컨테이너 실행

러너를 위한 실행 권한있는 컨테이너 실행

GitLab에서 액세스하는데 사용하는 사용자 정의 인증서 제공

CI 환경 변수 키로 pod 라벨 설정

등록 토큰 또는 러너 토큰을 시크릿으로 저장

Ubuntu 기반 `gitlab-runner` 도커 이미지로 전환

root 이외의 사용자로 실행

FIPS 호환 GitLab Runner 사용하기

Helm 차트를 사용하여 GitLab Runner 제거하기

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`

도움말

기능 사용 가능성과 제품 평가판

도움받기

GitLab Runner Helm Chart

전제 조건

Helm 차트를 사용하여 GitLab Runner 설치

Helm 차트를 사용하여 GitLab Runner 업그레이드

사용 가능한 GitLab Runner Helm 차트 버전 확인

Helm 차트를 사용하여 GitLab Runner 구성

필수 구성

추가 구성

구성 템플릿으로 캐시 사용하기

S3

Google Cloud Storage (GCS)

정적 자격 증명 직접 구성

GCP에서 다운로드한 JSON 파일에 정적 자격 증명

Azure

RBAC 지원 활성화

최대 Runner 동시성 제어

GitLab Runner로 Docker-in-Docker 컨테이너 실행

러너를 위한 실행 권한있는 컨테이너 실행

GitLab에서 액세스하는데 사용하는 사용자 정의 인증서 제공

CI 환경 변수 키로 pod 라벨 설정

등록 토큰 또는 러너 토큰을 시크릿으로 저장

Ubuntu 기반 gitlab-runner 도커 이미지로 전환

root 이외의 사용자로 실행

FIPS 호환 GitLab Runner 사용하기

Helm 차트를 사용하여 GitLab Runner 제거하기

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

도움말

기능 사용 가능성과 제품 평가판

도움받기

Ubuntu 기반 `gitlab-runner` 도커 이미지로 전환

`ERROR: Job failed (system failure): secrets is forbidden`

`Unable to mount volumes for pod`

`PANIC: creating directory: mkdir /nonexistent: permission denied`