• GitLab 러너 오퍼레이터에 속성 전달
• 오퍼레이터 속성
• 캐시 속성
  • S3 캐시
  • GCS 캐시
  • Azure 캐시
• 프록시 환경 구성
• 구성 템플릿을 사용하여 config.toml을 사용자 정의하십시오
• 사용자 정의 TLS 인증서 구성
• 러너 팟의 CPU 및 메모리 크기 구성
• 클러스터 리소스를 기반으로 러너 팟당 작업 동시성 구성
• 문제 해결
  • 루트 vs 비 루트
    • HOME 환경 변수 변경
    • SCC 주의
    • Run As anyuid SCC
    • SETFCAP 구성
  • FIPS 호환 GitLab Runner 사용
    • 자체 서명된 인증서를 사용하여 GitLab Runner 등록
    • IP 주소를 가리키는 외부 URL로 GitLab Runner 등록

OpenShift에서 GitLab 러너 구성하기

이 문서에서는 OpenShift에서 GitLab 러너를 구성하는 방법에 대해 설명합니다.

GitLab 러너 오퍼레이터에 속성 전달

러너를 생성할 때 spec의 속성을 설정하여 구성할 수 있습니다. 예를 들어, 등록될 GitLab URL이나 등록 토큰을 포함하는 시크릿의 이름을 지정할 수 있습니다.

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
 name: dev
spec:
 gitlabUrl: https://gitlab.example.com
 token: gitlab-runner-secret # 등록 토큰을 포함하는 시크릿의 이름

오퍼레이터 속성에서 사용 가능한 모든 속성에 대해 읽어보세요.

오퍼레이터 속성

오퍼레이터에 전달할 수 있는 지원되는 속성 목록입니다.

최근 버전의 오퍼레이터에서만 사용할 수 있는 속성이 몇 가지 있습니다.

캐시 속성

S3 캐시

GCS 캐시

Azure 캐시

프록시 환경 구성

프록시 환경을 생성하려면 다음을 수행하세요:

1. custom-env.yaml 파일을 편집합니다. 예:

   apiVersion: v1
   data:
     HTTP_PROXY: example.com
   kind: ConfigMap
   metadata:
     name: custom-env
   

2. 변경 사항을 적용하려면 OpenShift를 업데이트합니다.

   oc apply -f custom-env.yaml
   

3. gitlab-runner.yml 파일을 업데이트합니다.

   apiVersion: apps.gitlab.com/v1beta2
   kind: Runner
   metadata:
     name: dev
   spec:
     gitlabUrl: https://gitlab.example.com
     token: gitlab-runner-secret # 등록 토큰을 포함하는 시크릿의 이름
     env: custom-env
   

프록시가 Kubernetes API에 연결할 수 없는 경우, CI/CD 작업에서 오류가 발생할 수 있습니다:

ERROR: Job failed (system failure): prepare environment: setting up credentials: Post https://172.21.0.1:443/api/v1/namespaces/<KUBERNETES_NAMESPACE>/secrets: net/http: TLS handshake timeout. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information

이 오류를 해결하려면 custom-env.yaml 파일의 NO_PROXY 구성에 Kubernetes API의 IP 주소를 추가하세요:

   apiVersion: v1
   data:
     NO_PROXY: 172.21.0.1
     HTTP_PROXY: example.com
   kind: ConfigMap
   metadata:
     name: custom-env

Kubernetes API의 IP 주소는 다음을 실행하여 확인할 수 있습니다:

oc get services --namespace default --field-selector='metadata.name=kubernetes' | grep -v NAME | awk '{print $3}'

구성 템플릿을 사용하여 config.toml을 사용자 정의하십시오

참고: config.toml을 사용자 정의하는 데 구성 템플릿을 사용하는 것은 현재 [runners.kubernetes.volumes] 설정을 지정하는 데로 제한되어 있습니다. 이를 다른 설정으로 확장하는 지원은 이슈 49에서 제안되었습니다.

구성 템플릿을 사용하여 러너의 config.toml 파일을 사용자 정의할 수 있습니다.

1. 사용자 정의 구성 템플릿 파일을 만듭니다. 예를 들어, 러너에게 EmptyDir 볼륨을 마운트하도록 지시합니다. custom-config.toml 파일을 만듭니다.

   [[runners]]
     [runners.kubernetes]
       [runners.kubernetes.volumes]
         [[runners.kubernetes.volumes.empty_dir]]
           name = "empty-dir"
           mount_path = "/path/to/empty_dir"
           medium = "Memory"
   

2. custom-config.toml 파일에서 ConfigMap인 custom-config-toml을 만듭니다.

    oc create configmap custom-config-toml --from-file config.toml=custom-config.toml
   

3. Runner의 config 속성을 설정합니다.

   apiVersion: apps.gitlab.com/v1beta2
   kind: Runner
   metadata:
     name: dev
   spec:
     gitlabUrl: https://gitlab.example.com
     token: gitlab-runner-secret
   
     config: custom-config-toml
   

사용자 정의 TLS 인증서 구성

1. 사용자 정의 TLS 인증서를 설정하려면 tls.crt 키를 사용하여 시크릿을 만듭니다. 이 예에서 파일의 이름은 custom-tls-ca-secret.yaml입니다.

   apiVersion: v1
   kind: Secret
   metadata:
       name: custom-tls-ca
   type: Opaque
   stringData:
       tls.crt: |
           -----BEGIN CERTIFICATE-----
           MIIEczCCA1ugAwIBAgIBADANBgkqhkiG9w0BAQQFAD..AkGA1UEBhMCR0Ix
           .....
           7vQMfXdGsRrXNGRGnX+vWDZ3/zWI0joDtCkNnqEpVn..HoX
           -----END CERTIFICATE-----
   

2. 시크릿을 생성합니다.

   oc apply -f custom-tls-ca-secret.yaml
   

3. runner.yaml의 ca 키를 시크릿의 이름과 동일하게 설정합니다.

   apiVersion: apps.gitlab.com/v1beta2
   kind: Runner
   metadata:
     name: dev
   spec:
     gitlabUrl: https://gitlab.example.com
     token: gitlab-runner-secret
     ca: custom-tls-ca
   

러너 팟의 CPU 및 메모리 크기 구성

사용자 정의 config.toml 파일에서 CPU 한도 및 메모리 한도를 설정하려면 이 항목의 지침을 따르세요.

클러스터 리소스를 기반으로 러너 팟당 작업 동시성 구성

Runner 리소스의 concurrent 속성을 설정합니다.

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
  name: dev
spec:
  gitlabUrl: https://gitlab.example.com
  token: gitlab-runner-secret
  concurrent: 2

작업 동시성은 프로젝트의 요구 사항에 따라 결정됩니다.

1. 실행할 CI 작업에 필요한 컴퓨팅 및 메모리 리소스를 결정해보세요.
2. 클러스터의 리소스를 고려하여 해당 작업을 실행할 수 있는 횟수를 계산하세요.

동시성 값을 너무 크게 설정하면 Kubernetes executor는 작업을 가능한 즉시 처리합니다. 그러나 Kubernetes 클러스터의 스케줄러 용량이 작업을 예약하는 시점을 결정합니다.

문제 해결

루트 vs 비 루트

GitLab Runner Operator 및 GitLab Runner 팟은 비 루트 사용자로 실행됩니다. 따라서 작업에 사용되는 빌드 이미지는 최소 권한으로 성공적으로 완료될 수 있도록 비 루트 사용자로 실행되어야 합니다. 이를 위해서는 CI 작업에 사용되는 빌드 이미지도 비 루트로 실행되도록 빌드되어야하며 제한적인 파일 시스템에 기록하면 안 됩니다. OpenShift 클러스터의 대부분의 컨테이너 파일 시스템은 읽기 전용일 수 있습니다.

HOME 환경 변수 변경

사용자 지정 빌드 이미지를 만들거나 환경 변수를 오버라이드하는 경우, 홈 환경 변수가 읽기 전용으로 설정되지 않도록 주의해야 합니다. 특히 작업에서 홈 디렉터리에 파일을 작성해야하는 경우입니다. 예를 들어 /home 하위 디렉터리를 만들고 Dockerfile에서 ENV HOME=/home/ci를 설정할 수 있습니다.

러너 팟에 대해서는 예상대로 HOME이 /home/gitlab-runner로 설정되어 있다고 가정됩니다. 이 변수가 변경된 경우 새 위치에는 적절한 권한이 있어야 합니다. 이러한 지침은 또한 Red Hat Container Platform Docs > 이미지 만들기 > 임의의 사용자 ID 지원에 문서화되어 있습니다.

SCC 주의

새 OpenShift 프로젝트에 설치할 때, GitLab Runner Operator는 기본적으로 비 루트로 실행됩니다. 그러나 default 프로젝트와 같이 프로젝트의 모든 서비스 계정이 anyuid 액세스 권한을 부여받은 경우에는 예외가 있습니다. 이 경우 이미지 사용자는 루트가 됩니다. 작업과 같은 컨테이너 셸 내에서 whoami를 실행하여 쉽게 확인할 수 있습니다. 자세한 내용은 Red Hat Container Platform Docs > 보안 컨텍스트 제약 관리에서 확인하세요.

Run As anyuid SCC

필요한 경우 CI 작업이 root 사용자로 실행되거나 루트 파일 시스템에 쓰여야 하는 경우가 절대적으로 필요하지만 권장되진 않습니다. GitLab Runner 컨테이너에서 사용되는 GitLab Runner 서비스 계정인 gitlab-runner-sa에 anyuid SCC를 설정해야 합니다.

OpenShift 4.3.8 및 이전:

oc adm policy add-scc-to-user anyuid -z gitlab-runner-sa -n <runner_namespace>

# anyuid SCC가 설정되어 있는지 확인하세요:
oc get scc anyuid -o yaml

OpenShift 4.3.8 및 이후:

oc create -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: scc-anyuid
  namespace: <runner_namespace>
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - anyuid
  resources:
  - securitycontextconstraints
  verbs:
  - use
EOF

oc create -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-to-scc-anyuid
  namespace: <runner_namespace>
subjects:
  - kind: ServiceAccount
    name: gitlab-runner-sa
roleRef:
  kind: Role
  name: scc-anyuid
  apiGroup: rbac.authorization.k8s.io
EOF

SETFCAP 구성

Red Hat OpenShift Container Platform (RHOCP) 4.11 이상을 사용하는 경우 다음 오류 메시지를 받을 수 있습니다.

error reading allowed ID mappings:error reading subuid mappings for user

일부 작업(buildah 예시)은 올바르게 실행되려면 SETFCAP 기능이 부여되어야 합니다. 이 문제를 해결하려면 다음을 수행하세요:

1. GitLab Runner가 사용하는 SCC에 SETFCAP 기능을 추가합니다 (gitlab-scc를 GitLab Runner 팟에 할당된 SCC로 바꿉니다):

   oc patch scc gitlab-scc --type merge -p '{"allowedCapabilities":["SETFCAP"]}'
   

2. config.toml을 업데이트하고 kubernetes 섹션에 SETFCAP 기능을 추가합니다:

   [[runners]]
     [runners.kubernetes]
     [runners.kubernetes.pod_security_context]
       [runners.kubernetes.build_container_security_context]
       [runners.kubernetes.build_container_security_context.capabilities]
         add = ["SETFCAP"]
   

3. GitLab Runner가 배포된 namespace에서 이 config.toml을 사용하여 configmap을 생성합니다:

   oc create configmap custom-config-toml --from-file config.toml=config.toml
   

4. 수정하려는 runner에 최근에 만든 configmap을 가리키는 config: 파라미터를 추가합니다 (my-runner를 올바른 runner 팟 이름으로 바꿉니다):

   oc patch runner my-runner --type merge -p '{"spec": {"config": "custom-config-toml"}}'
   

자세한 내용은 Red Hat 문서를 참조하세요.

FIPS 호환 GitLab Runner 사용

참고: 현재 Operator에서는 도우미 이미지만 변경할 수 있습니다. 이슈가 있음 (GitLab Runner 이미지 변경).

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

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
 name: dev
spec:
 gitlabUrl: https://gitlab.example.com
 token: gitlab-runner-secret
 helperImage: gitlab/gitlab-runner-helper:ubi-fips
 concurrent: 2

자체 서명된 인증서를 사용하여 GitLab Runner 등록

GitLab 자체 관리 설치에서 자체 서명된 인증서를 사용하는 경우, 프라이빗 인증서를 서명한 사용자 정의 CA 인증서가 포함된 시크릿을 생성해야 합니다.

시크릿 이름은 Runner spec 섹션의 CA로 제공됩니다:

KIND:     Runner
VERSION:  apps.gitlab.com/v1beta2

FIELD:    ca <string>

DESCRIPTION:
     커스텀 CA (Certificate Authority) 인증서를 포함하는 시크릿의 이름

다음 명령을 사용하여 시크릿을 생성할 수 있습니다:

oc create secret generic mySecret --from-file=tls.crt=myCert.pem -o yaml

IP 주소를 가리키는 외부 URL로 GitLab Runner 등록

GitLab 자체 관리 서버에서 자체 서명된 인증서와 호스트 이름이 일치하지 않으면 오류 메시지를 받을 수 있습니다. 이는 GitLab 자체 관리 인스턴스가 호스트 이름 대신 IP 주소에서 액세스하도록 구성된 경우 발생할 수 있습니다 (###.##.##.##은 GitLab 서버 IP 주소입니다):

[31;1mERROR: Registering runner... failed               [0;m  [31;1mrunner[0;m=A5abcdEF [31;1mstatus[0;m=couldn't execute POST against https://###.##.##.##/api/v4/runners:
Post https://###.##.##.##/api/v4/runners: x509: cannot validate certificate for ###.##.##.## because it doesn't contain any IP SANs
[31;1mPANIC: Failed to register the runner. You may be having network problems.[0;m

이 문제를 해결하려면:

1. GitLab 자체 관리 서버에서 openssl을 수정하여 IP 주소를 subjectAltName 매개변수에 추가합니다:

   # vim /etc/pki/tls/openssl.cnf
   
   [ v3_ca ]
   subjectAltName=IP:169.57.64.36 <---- 이 줄을 추가합니다. 169.57.64.36은 GitLab 서버 IP입니다.
   

2. 그런 다음 다음 명령으로 새로운 CA를 다시 만듭니다:

   # cd /etc/gitlab/ssl
   # openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/gitlab/ssl/169.57.64.36.key -out /etc/gitlab/ssl/169.57.64.36.crt
   # openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 4096
   # gitlab-ctl restart
   

3. 새로운 인증서를 사용하여 새로운 시크릿을 생성합니다.