RBAC 지원 활성화

RBAC 지원 활성화

클러스터에 RBAC가 활성화된 경우 차트에서 자체 서비스 계정을 생성하거나 자체적으로 제공하도록 선택할 수 있습니다 .

rbac.create차트에서 서비스 계정을 생성하도록 하려면 true 로 설정 하세요.

rbac:
    create: true
    

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

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

최대 러너 동시성 제어

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

## Configure the maximum number of concurrent jobs
    ## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
    ##
    concurrent: 10
    

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

활성화 방법 은 러너에 대한 권한 있는 컨테이너 실행을 참조 하고 dind 실행에 대한 GitLab Runner 설명서 를 참조하십시오.

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

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

여기에는 GitLab CI/CD Runner 설명서 에서 읽을 수 있는 몇 가지 위험이 따릅니다 .

위험을 감수하고 GitLab Runner 인스턴스가 CI 작업을 신뢰하는 GitLab의 특정 프로젝트에 대해 등록된 경우 다음에서 권한 모드를 활성화할 수 있습니다 values.yaml.

runners:
    ## Run all containers with the privileged flag enabled
    ## This will allow the docker:stable-dind image to run if you need to run Docker
    ## commands. Please read the docs before turning this on:
    ## ref: https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-dind
    ##
    privileged: true
    

특권 모드 없이 컨테이너를 빌드하기 위한 모범 사례

Docker-in-Docker를 사용하여 컨테이너 내에서 컨테이너를 빌드하려면 Docker 권한 모드가 필요합니다. Google의 Kaniko 는 특권 모드 없이 작동하는 대안이며 Kubernetes GitLab Runner에서 테스트되었습니다.

GitLab 비디오에서 Kaniko를 사용한 최소 권한 컨테이너 빌드는 Kaniko Docker Build 작업 예제 프로젝트의 연습입니다. Kaniko 및 GitLab CI/CD로 이미지 빌드 에 대한 문서를 사용합니다 .

작업 예제 프로젝트는 테스트를 위해 자신의 그룹이나 인스턴스에 복사할 수 있습니다. 다른 GitLab CI 패턴에 대한 자세한 내용은 Kaniko Docker Build 프로젝트 페이지에서 확인할 수 있습니다 .

개인 레지스트리의 이미지 사용

개인 레지스트리의 이미지를 사용하려면 imagePullSecrets 구성이 필요합니다. imagePullSecrets를 만드는 방법에 대한 자세한 내용 은 설명서 를 참조하십시오 .

CI/CD 작업에 사용되는 Kubernetes 네임스페이스에 하나 이상의 비밀을 생성해야 합니다.

다음 명령을 사용하여 다음과 작동하는 비밀을 만들 수 있습니다 image_pull_secrets.

kubectl create secret docker-registry <SECRET_NAME> \
    --namespace <NAMESPACE> \
    --docker-server="https://<REGISTRY_SERVER>" \
    --docker-username="<REGISTRY_USERNAME>" \
    --docker-password="<REGISTRY_PASSWORD>"
    

를 구성 runners.imagePullSecrets하면 컨테이너가 --kubernetes-image-pull-secrets "<SECRET_NAME>"이미지 진입점 스크립트에 추가됩니다. image_pull_secrets이렇게 하면 Kubernetes 실행기 설정에서 매개변수 를 구성할 필요가 없습니다 config.toml.

runners:
    ## Specify one or more imagePullSecrets
    ##
    ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
    ##
    imagePullSecrets: [your-image-pull-secret]
    

형식을 기록해 두십시오. name값 에는 Kubernetes 리소스의 규칙과 같이 태그가 접두사로 붙지 않습니다. 여러 레지스트리 자격 증명을 사용하는지 여부에 관계없이 하나 이상의 비밀 이름 배열이 필요합니다.

GitLab에 액세스하기 위한 사용자 지정 인증서 제공

컨테이너의 디렉터리 를 채우는 데 사용할 GitLab Runner Helm 차트에 Kubernetes 비밀 을 제공할 수 있습니다 ./home/gitlab-runner/.gitlab-runner/certs

Secret의 각 키 이름은 디렉터리의 파일 이름으로 사용되며 파일 내용은 키와 연결된 값입니다.

• 사용된 키/파일 이름은 형식이어야 합니다( <gitlab-hostname>.crt예: gitlab.your-domain.com.crt.
• 모든 중간 인증서는 동일한 파일의 서버 인증서에 연결해야 합니다.
• 사용되는 호스트 이름은 인증서가 등록된 호스트 이름이어야 합니다.

GitLab Runner Helm Chart는 비밀을 생성하지 않습니다. 비밀을 생성하기 위해 Kubernetes에 인증서를 비밀로 저장하고 이를 파일로 GitLab Runner 컨테이너에 제공하도록 지시합니다. 이렇게 하려면 다음 명령을 실행합니다.

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

어디에:

• <NAMESPACE> GitLab Runner를 설치하려는 Kubernetes 네임스페이스입니다.
• <SECRET_NAME>Kubernetes 비밀 리소스 이름입니다. (예: 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.

## Set the certsSecretName in order to pass custom certificates for GitLab Runner to use
    ## Provide resource name for a Kubernetes Secret Object in the same namespace,
    ## this is used to populate the /home/gitlab-runner/.gitlab-runner/certs/ directory
    ## 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 Runner가 이러한 인증서를 사용하는 방법에 대한 자세한 내용은 Runner 설명서 에서 찾을 수 있습니다 .

포드 레이블을 CI 환경 변수 키로 설정

values.yaml현재로서는 파일 내에서 환경 변수를 포드 레이블로 사용할 수 없습니다 . 이 문제에서 작업 중입니다 . 환경 변수 키를 pod 레이블로 설정할 수 없습니다 . 문제에 설명된 해결 방법 을 임시 솔루션으로 사용합니다 .

비밀에 등록 토큰 또는 러너 토큰 저장

runnerRegistrationToken새 주자를 등록하려면 에서 지정할 수 있습니다 values.yml. 기존 러너를 등록하려면 를 사용할 수 있습니다 runnerToken. values.yml토큰을 에 저장하는 것은 보안 위험이 될 수 있습니다 git.

대신 이러한 토큰의 값을 Kubernetes 비밀 내에 저장한 다음 비밀 이름으로 runners.secret값 을 업데이트할 수 있습니다.values.yml

기존에 등록된 러너가 있고 이를 사용하려면 runner-token해당 러너를 식별하는 데 사용되는 토큰으로 설정하십시오. 새 주자를 등록하려면 원하는 등록 토큰runner-registration-token 으로 설정할 수 있습니다 .

예를 들어:

apiVersion: v1
    kind: Secret
    metadata:
    name: gitlab-runner-secret
    type: Opaque
    data:
    runner-registration-token: "NlZrN1pzb3NxUXlmcmVBeFhUWnIK" #base64 encoded registration token
    runner-token: ""
    

runners:
    secret: gitlab-runner-secret
    

이 예에서는 비밀 gitlab-runner-secret을 사용하고 값을 사용 runner-registration-token하여 새 러너를 등록합니다.

Ubuntu 기반 gitlab-runnerDocker 이미지 로 전환

기본적으로 GitLab Runner Helm 차트는 알파인 버전의 gitlab/gitlab-runner이미지를 사용하며 musl libc. 경우에 따라 를 사용하는 Ubuntu 기반 이미지로 전환할 수 있습니다 glibc.

이렇게 하려면 values.yaml다음 값으로 파일을 업데이트하십시오.

# Specify the Ubuntu image. Remember to set the version. You can also use the `ubuntu` or `latest` tags.
    image: gitlab/gitlab-runner:v13.0.0
    
    # Update the security context values to the user ID in the ubuntu image
    securityContext:
    fsGroup: 999
    runAsUser: 999
    

루트가 아닌 사용자로 실행

기본적으로 GitLab Runner 이미지는 루트가 아닌 사용자와 작동하지 않습니다. GitLab Runner UBI 및 GitLab Runner Helper UBI 이미지는 해당 시나리오를 위해 설계되었습니다. 이를 사용하려면 GitLab Runner 및 GitLab Runner Helper 이미지를 변경하십시오.

이미지는 모든 사용자 ID로 작업할 수 있도록 디자인되었습니다. 이 사용자 ID가 루트 그룹의 일부인 것이 중요합니다. 루트 그룹의 일부가 된다고 해서 특정 권한이 부여되는 것은 아닙니다.

image: registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp:v13.11.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-v13.11.0"
    [runners.kubernetes.pod_security_context]
    run_as_non_root = true
    run_as_user = 59417
    

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

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

GitLab Runner Chart를 제거하려면 다음을 실행하십시오.

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 지원을 활성화하십시오 .