• 호스트 설정 구성
  • hostSuffix
• 수평 Pod 자동 크기 조정 설정 구성
• PodDisruptionBudget 설정 구성
• CronJob 설정 구성
• 모니터링 설정 구성
• Ingress 설정 구성
  • Ingress 경로
  • 클라우드 제공업체 LoadBalancer
  • global.ingress.configureCertmanager
  • global.ingress.useNewIngressForCerts
• GitLab 버전
• 모든 이미지 태그에 접미사 추가
• PostgreSQL 설정 구성
  • 차트별 PostgreSQL 설정
  • PostgreSQL SSL
  • PostgreSQL 로드 밸런싱
  • 여러 데이터베이스 연결 구성
• Redis 설정 구성
  • Redis 차트별 설정 구성
  • Redis Sentinel 지원
  • 여러 Redis 지원
  • 안전한 Redis 스키마(SSL) 지정
  • 비밀번호 없는 Redis 서버
• 레지스트리 설정 구성
  • 알림
• Gitaly 설정 구성
  • Gitaly 호스트
    • 내부
    • 외부
    • 혼합
  • authToken
  • 사용되지 않는 Gitaly 설정
  • TLS 설정
• Praefect 설정 구성
  • Praefect 활성화
  • Praefect의 전역 설정
• MinIO 설정 구성
• appConfig 설정 구성
  • 일반 애플리케이션 설정
    • Content Security Policy
    • defaultProjectsFeatures
  • Gravatar/Libravatar 설정
  • GitLab 인스턴스에 분석 서비스 연동
  • 통합된 객체 리포지터리
  • 버킷 지정
    • storage_options
  • LFS, 아티팩트, 업로드, 패키지, 외부 MR 차이 및 의존성 프록시
    • connection
    • when (외부 MR 차이의 경우만)
    • cdn (CI 아티팩트의 경우만)
  • 수신 이메일 설정
  • KAS 설정
    • 사용자 지정 시크릿
    • 사용자 지정 URL
    • 외부 KAS
    • TLS 설정
  • 제안된 리뷰어 설정
  • LDAP
    • LDAP 웹 로그인 비활성화
    • 사용자 정의 CA 또는 자체 서명된 LDAP 인증서 사용
  • DuoAuth
  • GitLab Duo 비밀 키 구성
  • OmniAuth
    • providers
  • Cron 작업 관련 설정
  • Sentry 설정
  • gitlab_docs 설정
  • 스마트카드 인증 설정
  • Sidekiq 라우팅 규칙 설정
• Rails 설정 구성
• Workhorse 설정 구성
  • Bootsnap Cache
• GitLab Shell 설정 구성
  • 포트
  • TCP 프록시 프로토콜
• GitLab Pages 구성
• Webservice 구성
  • workerTimeout
• 사용자 정의 인증 기관
• 애플리케이션 리소스
• GitLab 베이스 이미지
• 서비스 계정
• 어노테이션
• 노드 셀렉터
• 라벨
  • 공통 라벨
  • Pod
  • Service
• 추적
• extraEnv
• Kerberos
  • Kerberos 전용 포트
  • LDAP 사용자 지정 허용 영역
• 발신 이메일
• 플랫폼
• Affinity
• pod 우선 순위 및 선점
• 로그 로테이션
• 작업

글로벌 사용하여 차트 구성

우리의 래퍼 Helm 차트를 설치할 때 구성 중복을 줄이기 위해 values.yaml의 global 섹션에 설정할 수 있는 여러 구성 설정이 있습니다. 이러한 글로벌 설정은 여러 차트에서 사용되며, 나머지 모든 설정은 해당 차트 내에서 범위가 지정됩니다. 글로벌 변수가 작동하는 방법에 대한 자세한 내용은 글로벌에 대한 Helm 설명서를 참조하세요.

• 호스트 구성 설정
• 인그레스 구성 설정
• GitLab 버전
• PostgreSQL
• Redis
• Registry
• Gitaly
• Praefect
• MinIO
• appConfig
• Rails
• Workhorse
• GitLab Shell
• Pages
• Webservice
• Custom Certificate Authorities
• Application Resource
• GitLab 베이스 이미지
• 서비스 어카운트
• 주석
• 추적
• extraEnv
• extraEnvFrom
• OAuth
• Kerberos
• 발신 이메일
• 플랫폼
• Affinity
• Pod 우선순위 및 선점
• 로그 회전
• 작업

호스트 설정 구성

GitLab 글로벌 호스트 설정은 global.hosts 키 아래에 있습니다.

global:
  hosts:
    domain: example.com
    hostSuffix: staging
    https: false
    externalIP:
    gitlab:
      name: gitlab.example.com
      https: false
    registry:
      name: registry.example.com
      https: false
    minio:
      name: minio.example.com
      https: false
    smartcard:
      name: smartcard.example.com
    kas:
      name: kas.example.com
    pages:
      name: pages.example.com
      https: false
    ssh: gitlab.example.com

hostSuffix

hostSuffix은 기본 도메인을 사용하여 호스트명을 조립할 때 서브도메인에 추가되지만, 자체 이름이 설정된 호스트에는 사용되지 않습니다.

기본 값은 설정되지 않은 상태입니다. 설정된 경우, 접미어는 하이픈과 함께 서브도메인에 추가됩니다. 아래 예시는 gitlab-staging.example.com 및 registry-staging.example.com과 같은 외부 호스트명을 사용하게 됩니다:

global:
  hosts:
    domain: example.com
    hostSuffix: staging

수평 Pod 자동 크기 조정 설정 구성

HPA(Horizontal Pod Autoscaler)를 위한 GitLab 글로벌 호스트 설정은 global.hpa 키 아래에 있습니다:

PodDisruptionBudget 설정 구성

PDB(PodDisruptionBudget)를 위한 GitLab 글로벌 호스트 설정은 global.pdb 키 아래에 있습니다:

CronJob 설정 구성

CronJob을 위한 GitLab 글로벌 호스트 설정은 global.batch.cronJob 키 아래에 있습니다:

모니터링 설정 구성

ServiceMonitors 및 PodMonitors를 위한 GitLab 글로벌 설정은 global.monitoring 키 아래에 있습니다:

Ingress 설정 구성

Ingress를 위한 GitLab 글로벌 호스트 설정은 global.ingress 키 아래에 있습니다:

다양한 클라우드 제공업체를 위한 구성 방법은 예제 폴더에서 찾을 수 있습니다.

• AWS
• GKE

Ingress 경로

이 차트는 global.ingress.path를 사용하여 Ingress 객체의 path 정의를 수정해야 하는 사용자를 지원하는 방법으로 사용합니다. 많은 사용자가 이 설정이 필요하지 않으며, 이 설정을 구성하지 말아야 합니다.

ingress.class: gce를 사용하는 경우 GCP에서, ingress.class: alb를 사용하는 경우 AWS에서와 같이 로드 밸런서/프록시 동작을 일치시키기 위해 /*로 끝나는 path 정의가 필요한 사용자를 위해서입니다.

이 설정은 이 차트 전체의 Ingress 리소스의 모든 path 항목이 이와 동일하게 렌더링되도록 합니다. 유일한 예외는 gitlab/webservice 배포 설정을 채우는 경우인데, 여기서는 path를 지정해야 합니다.

클라우드 제공업체 LoadBalancer

다양한 클라우드 제공업체의 로드 밸런서 구현은 이 차트의 일부로 배포되는 Ingress 리소스 및 NGINX 컨트롤러 구성에 영향을 미칩니다. 다음 표는 예시를 제공합니다.

global.ingress.configureCertmanager

Ingress 객체에 대한 cert-manager의 자동 구성을 제어하는 전역 설정입니다. true의 경우, certmanager-issuer.email이 설정되어 있어야 합니다.

false이고 global.ingress.tls.secretName이 설정되지 않은 경우, Ingress 객체의 자동 자체 서명 인증서 생성이 활성화됩니다. 이는 모든 Ingress 객체에 대한 와일드카드 인증서를 생성합니다.

외부 cert-manager를 사용하려면 다음을 제공해야 합니다:

• gitlab.webservice.ingress.tls.secretName
• registry.ingress.tls.secretName
• minio.ingress.tls.secretName
• global.ingress.annotations

global.ingress.useNewIngressForCerts

global.ingress.useNewIngressForCerts는 cert-manager의 동작을 변경하여 ACME 챌린지 유효성 검사를 수행하는데 동적으로 생성된 새 Ingress와 함께할지를 지정하는 전역 설정입니다.

기본 논리(global.ingress.useNewIngressForCerts가 false일 때)는 유효성 검사에 기존의 Ingress를 재사용합니다. 이 기본 설정은 일부 상황에 적합하지 않습니다. 플래그를 true로 설정하면 각 유효성 검사를 위해 새 Ingress 객체가 생성됩니다.

GKE Ingress Controllers와 함께 사용될 때 global.ingress.useNewIngressForCerts를 true로 설정할 수 없습니다. 이에 대한 자세한 내용은 릴리스 노트를 참조하세요.

GitLab 버전

차트의 기본 이미지 태그에 사용된 GitLab 버전은 global.gitlabVersion 키를 사용하여 변경할 수 있습니다:

--set global.gitlabVersion=11.0.1

이는 webservice, sidekiq, migration 차트에 사용되는 기본 이미지 태그에 영향을 미칩니다. gitaly, gitlab-shell, gitlab-runner 이미지 태그는 별도로 GitLab 버전과 호환되는 버전으로 업데이트해야 합니다.

모든 이미지 태그에 접미사 추가

헬름 차트에서 사용되는 모든 이미지 이름에 접미사를 추가하려면 global.image.tagSuffix 키를 사용할 수 있습니다. 예를 들어, GitLab에서 제공하는 FIPS(연방 정보 처리 표준) 호환 컨테이너 이미지를 사용하고 싶을 때 사용 가능한 경우가 있습니다. 이 경우, 모든 이미지에 -fips 확장자가 붙도록 설정할 수 있습니다.

--set global.image.tagSuffix="-fips"

PostgreSQL 설정 구성

GitLab의 전역 PostgreSQL 설정은 global.psql 키 아래에 있습니다. GitLab은 main 데이터베이스와 ci를 위한 두 개의 데이터베이스 연결을 사용합니다. 기본적으로 이들은 동일한 PostgreSQL 데이터베이스를 가리킵니다.

global.psql 하위 값들은 기본값이며 두 데이터베이스 구성에 모두 적용됩니다. 두 개의 데이터베이스를 사용하려면 global.psql.main 및 global.psql.ci에 연결 세부 정보를 지정할 수 있습니다.

global:
  psql:
    host: psql.example.com
    # serviceName: pgbouncer
    port: 5432
    database: gitlabhq_production
    username: gitlab
    applicationName:
    preparedStatements: false
    databaseTasks: true
    connectTimeout:
    keepalives:
    keepalivesIdle:
    keepalivesInterval:
    keepalivesCount:
    tcpUserTimeout:
    password:
      useSecret: true
      secret: gitlab-postgres
      key: psql-password
      file:
    main: {}
      # host: postgresql-main.hostedsomewhere.else
      # ...
    ci: {}
      # host: postgresql-ci.hostedsomewhere.else
      # ...

차트별 PostgreSQL 설정

일부 복잡한 배포에서는 이 차트의 서로 다른 부분을 다른 PostgreSQL 구성으로 구성하는 것이 바람직할 수 있습니다. v4.2.0에서 모든 global.psql의 속성이 차트별로 설정될 수 있으며, 예를 들어 gitlab.sidekiq.psql처럼 지정할 수 있습니다. 로컬 설정은 제공되어질 때 전역 값에서 상속받으며, psql.load_balancing을 제외하고는 _상위에서 상속_됩니다.

PostgreSQL 로드 밸런싱은 의도적으로 전역에서 상속되지 않습니다.

PostgreSQL SSL

PostgreSQL 데이터베이스를 상호 TLS를 통해 GitLab에 연결하려면, 클라이언트 키, 클라이언트 인증서 및 서버 인증 기관을 서로 다른 시크릿 키로 포함하는 시크릿을 만들어야 합니다. 그런 다음 global.psql.ssl 매핑을 사용하여 시크릿의 구조를 설명합니다.

global:
  psql:
    ssl:
      secret: db-example-ssl-secrets # 시크릿의 이름
      clientCertificate: cert.pem    # 클라이언트 인증서를 저장하는 시크릿 키
      clientKey: key.pem             # 클라이언트 인증서의 키 파일을 포함하는 시크릿 키
      serverCA: server-ca.pem        # 데이터베이스 서버의 인증 기관을 포함하는 시크릿 키

또한 올바른 키를 가리키도록 환경 값을 내보내기 위해 extraEnv 값을 설정해야 할 수도 있습니다.

global:
  extraEnv:
      PGSSLCERT: '/etc/gitlab/postgres/ssl/client-certificate.pem'
      PGSSLKEY: '/etc/gitlab/postgres/ssl/client-key.pem'
      PGSSLROOTCERT: '/etc/gitlab/postgres/ssl/server-ca.pem'

PostgreSQL 로드 밸런싱

이 기능을 사용하려면 외부 PostgreSQL를 사용해야 합니다. 이 차트는 PostgreSQL을 고가용성(HA)으로 배포하지 않습니다.

GitLab의 Rails 컴포넌트는 읽기 전용 쿼리를 로드 밸런스하는 데 PostgreSQL 클러스터를 사용할 수 있습니다.

이 기능은 두 가지 방식으로 구성할 수 있습니다:

• 두 번째 서버의 호스트 이름을 사용하는 정적 디렉터리을 사용하는 방법.
• DNS 기반 서비스 검색 메커니즘을 사용하는 방법.

정적 디렉터리을 사용한 구성은 간단합니다:

global:
  psql:
    host: primary.database
    load_balancing:
       hosts:
       - secondary-1.database
       - secondary-2.database

서비스 검색으로 구성하는 것은 더 복잡할 수 있습니다. 이 구성과 관련된 자세한 내용과 동작 방식에 대해서는 서비스 검색의 GitLab Administration documentation을 참조하십시오.

global:
  psql:
    host: primary.database
    load_balancing:
      discover:
        record:  secondary.postgresql.service.consul
        # record_type: A
        # nameserver: localhost
        # port: 8600
        # interval: 60
        # disconnect_timeout: 120
        # use_tcp: false
        # max_replica_pools: 30

잘못된 읽기 처리에 대한 추가적인 조정도 가능합니다. GitLab Administration 문서에서 이러한 속성들을 자세히 다루고, 이러한 속성들은 load_balancing 아래에 직접 추가할 수 있습니다.

global:
  psql:
    load_balancing:
      max_replication_difference:  # 설명서 참조
      max_replication_lag_time:    # 설명서 참조
      replica_check_interval:      # 설명서 참조

여러 데이터베이스 연결 구성

• gitlab:db:decomposition:connection_status Rake 작업은 GitLab 15.11에서 소개되었습니다.

GitLab 16.0에서 GitLab은 동일한 PostgreSQL 데이터베이스를 가리키는 두 개의 데이터베이스 연결을 기본값으로 사용합니다.

Redis 설정 구성

GitLab 전역 Redis 설정은 global.redis 키 하위에 위치합니다.

기본적으로 우리는 단일, 복제되지 않은 Redis 인스턴스를 사용합니다. 고가용성 Redis가 필요한 경우 외부 Redis 인스턴스를 사용하는 것을 권장합니다.

redis.install=false로 설정하여 외부 Redis 인스턴스를 가져오고 설정하기 위해 고급 설명서를 따르십시오.

global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
    scheme:

Redis 차트별 설정 구성

Redis 차트를 직접 구성하기 위한 설정은 redis 키 하위에 위치합니다.

redis:
  install: true
  image:
    registry: registry.example.com
    repository: example/redis
    tag: x.y.z

자세한 정보는 설정의 전체 디렉터리을 참조하십시오.

Redis Sentinel 지원

현재 Redis Sentinel 지원은 별도로 배포된 Sentinels만 지원합니다. 결과적으로 GitLab 차트를 통한 Redis 배포를 redis.install=false로 비활성화해야 합니다. Redis 암호를 포함한 Kubernetes Secret은 GitLab 차트를 배포하기 전에 매뉴얼으로 생성해야 합니다.

GitLab 차트에서 HA Redis 클러스터의 설치는 Sentinel 지원을 지원하지 않습니다. 만약 sentinel 지원이 원하는 경우, Redis 클러스터는 GitLab 차트 설치 내부나 외부에서 별도로 생성되어야 합니다.

GitLab에서 GitLab deployed Redis cluster의 Sentinel 지원을 지원하기 위한 이슈가 추적을 위해 생성되었습니다.

redis:
  install: false
global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    sentinels:
      - host: sentinel1.example.com
        port: 26379
      - host: sentinel2.example.com
        port: 26379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password

일반 Redis 설정 구성의 이전 Redis 속성은 위의 테이블에서 다시 지정되지 않는 한 Sentinel 지원에도 계속 적용됩니다.

여러 Redis 지원

GitLab 차트에는 현재 다른 지속성 클래스를 위해 별도의 Redis 인스턴스를 실행하는 지원이 포함되어 있습니다:

인스턴스의 어떤 숫자라도 지정할 수 있습니다. 지정되지 않은 인스턴스는 global.redis.host로 처리됩니다 또는 차트에서 배포된 Redis 인스턴스를 사용합니다. GitLab 에이전트 서버 (KAS)를 위한 유일한 예외는 다음과 같이 Redis 구성을 찾습니다.

1. global.redis.kas
2. global.redis.sharedState
3. global.redis.host

예를 들어:

redis:
  install: false
global:
  redis:
    host: redis.example
    port: 6379
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password
    actioncable:
      host: cable.redis.example
      port: 6379
      password:
        enabled: true
        secret: cable-secret
        key: cable-password
    cache:
      host: cache.redis.example
      port: 6379
      password:
        enabled: true
        secret: cache-secret
        key: cache-password
    kas:
      host: kas.redis.example
      port: 6379
      password:
        enabled: true
        secret: kas-secret
        key: kas-password
    queues:
      host: queues.redis.example
      port: 6379
      password:
        enabled: true
        secret: queues-secret
        key: queues-password
    rateLimiting:
      host: rateLimiting.redis.example
      port: 6379
      password:
        enabled: true
        secret: rateLimiting-secret
        key: rateLimiting-password
    repositoryCache:
      host: repositoryCache.redis.example
      port: 6379
      password:
        enabled: true
        secret: repositoryCache-secret
        key: repositoryCache-password
    sessions:
      host: sessions.redis.example
      port: 6379
      password:
        enabled: true
        secret: sessions-secret
        key: sessions-password
    sharedState:
      host: shared.redis.example
      port: 6379
      password:
        enabled: true
        secret: shared-secret
        key: shared-password
    traceChunks:
      host: traceChunks.redis.example
      port: 6379
      password:
        enabled: true
        secret: traceChunks-secret
        key: traceChunks-password
    workhorse:
      host: workhorse.redis.example
      port: 6379
      password:
        enabled: true
        secret: workhorse-secret
        key: workhorse-password

다음 표는 각 Redis 인스턴스 사전에 있는 속성에 대해 설명합니다.

기본 Redis 정의는 추가적으로 분리되지 않은 추가 지속성 클래스가 있으므로 필수적입니다.

인스턴스 정의는 또한 Redis Sentinel 지원을 사용할 수 있습니다. Sentinel 구성은 공유되지 않습니다 및 각 Sentinels를 사용하기 위해 각각 지정되어야 합니다. Sentinel 지원을 구성하는 데 사용되는 속성에 대해 자세히 알아보려면 Sentinel configuration을 참조하십시오.

안전한 Redis 스키마(SSL) 지정

SSL을 사용하여 Redis에 연결하려면:

1. 구성을 업데이트하여 rediss (두 개의 s) 스키마 매개변수를 사용합니다.

2. 구성에서 authClients를 false로 설정하세요:

   global:
     redis:
       scheme: rediss
   redis:
     tls:
       enabled: true
       authClients: false
   

   이 구성은 Redis가 상호 TLS를 기본으로 함에 필요합니다만, 모든 차트 컴포넌트에서는 이를 지원하지 않습니다.

3. Bitnami의 TLS를 활성화하는 단계를 따르세요. 차트 컴포넌트가 Redis 인증서를 만들 때 사용한 인증 기관을 신뢰해야 합니다.
4. 선택 사항. 사용자 정의 인증 기관을 사용하는 경우 사용자 지정 인증 기관 글로벌 구성을 참조하세요.

비밀번호 없는 Redis 서버

Google Cloud Memorystore와 같은 일부 Redis 서비스는 비밀번호나 관련된 AUTH 명령을 사용하지 않을 수 있습니다. 비밀번호의 사용 및 요구 사항은 다음 구성 설정을 통해 비활성화할 수 있습니다:

global:
  redis:
    auth:
      enabled: false
    host: ${REDIS_PRIVATE_IP}
redis:
  enabled: false

레지스트리 설정 구성

전역 레지스트리 설정은 global.registry 키 아래에 있습니다.

global:
  registry:
    bucket: registry
    certificate:
    httpSecret:
    notificationSecret:
    notifications: {}
    ## registry를 참조하는 다른 서비스에서 사용되는 설정:
    enabled: true
    host:
    api:
      protocol: http
      serviceName: registry
      port: 5000
    tokenIssuer: gitlab-issuer

bucket, certificate, httpSecret, 및 notificationSecret 설정에 대한 자세한 내용은 레지스트리 차트의 문서를 참조하세요.

enabled, host, api, 및 tokenIssuer에 대한 자세한 내용은 명령줄 옵션 및 웹 서비스 문서를 참조하세요.

host는 자동 생성된 외부 레지스트리 호스트 이름을 재정의하기 위해 사용됩니다.

알림

이 설정은 레지스트리 알림을 구성하는 데 사용됩니다. 이 설정은 맵(상류 사양을 따름)과 함께 사용되지만, Kubernetes 시크릿으로 민감한 헤더를 제공하는 추가 기능이 있습니다. 예를 들어, 인증 헤더에 민감한 데이터가 포함되어 있는 다음 스니펫을 고려해 보세요:

global:
  registry:
    notifications:
      events:
        includereferences: true
      endpoints:
        - name: CustomListener
          url: https://mycustomlistener.com
          timeout: 500mx
          threshold: 5
          backoff: 1s
          headers:
            X-Random-Config: [plain direct]
            Authorization:
              secret: registry-authorization-header
              key: password

이 예에서 X-Random-Config 헤더는 일반적인 헤더이며 그 값은 values.yaml 파일이나 --set 플래그를 통해 평문으로 제공될 수 있습니다. 그러나 Authorization 헤더는 민감한 헤더이므로 Kubernetes 시크릿을 통해 마운트하는 것이 좋습니다. 시크릿 구조에 대한 자세한 내용은 시크릿 문서를 참조하세요.

Gitaly 설정 구성

전역 Gitaly 설정은 global.gitaly 키 아래에 있습니다.

global:
  gitaly:
    internal:
      names:
        - default
        - default2
    external:
      - name: node1
        hostname: node1.example.com
        port: 8075
    authToken:
      secret: gitaly-secret
      key: token
    tls:
      enabled: true
      secretName: gitlab-gitaly-tls

Gitaly 호스트

Gitaly는 Git 리포지터리에 대한 고수준의 RPC 액세스를 제공하는 서비스로, GitLab에서 수행하는 모든 Git 호출을 처리합니다.

관리자는 Gitaly 노드를 다음과 같은 방법으로 사용할 수 있습니다:

• 차트 내부(#internal)에서 StatefulSet의 일부로, Gitaly 차트를 통해.
• 차트 외부(#external)에서 외부 펫으로.
• 내외부 노드를 모두 사용하면(#mixed) 혼합 환경.

새 프로젝트에 대해 어떤 노드가 사용될 지를 관리하는 방법에 대한 자세한 내용은 리포지터리 저장 경로 문서를 참조하세요.

gitaly.host가 제공되는 경우 gitaly.internal 및 gitaly.external 속성이 무시됩니다. gitaly.deprecated-Gitaly-settings에서 더이상 사용되지 않는 Gitaly 설정을 참조하세요.

내부

internal 키는 현재 names이라는 한 가지 키만을 포함하며, 이는 차트에서 관리할 리포지터리 이름 디렉터리입니다. 각 명명된 이름에 대해 논리적인 순서대로, gitaly-${ordinal}라는 이름의 pod가 생성됩니다. 여기서 ordinal은 names 디렉터리 내의 색인입니다. 동적 프로비저닝이 활성화된 경우 PersistentVolumeClaim이 일치합니다.

이 디렉터리은 기본적으로 1개의 저장 경로에 대한 1개의 pod을 제공합니다.

이 항목의 매뉴얼 확장에는 gitaly.internal.names에 항목을 추가하거나 제거해야 합니다. 축소할 때, 다른 노드로 이동되지 않은 모든 리포지터리들은 사용 불가능해집니다. StatefulSet이기 때문에 동적으로 프로비저닝된 디스크는 회수되지 않을 것입니다. 이는 데이터 디스크가 지속될 것이며, 디렉터리에 다시 노드를 추가하여 재개해도 데이터에 액세스할 수 있습니다.

예제 다중 내부 노드 구성을 예제 폴더에서 찾을 수 있습니다.

외부

external 키는 클러스터 외부에 있는 Gitaly 노드의 구성을 제공합니다. 이 디렉터리의 각 항목은 다음과 같은 3가지 키를 가집니다:

• name: 리포지터리 이름
  • 기본 이름은 default로 정의되어 있습니다
• hostname: Gitaly 서비스의 호스트
• port: (선택 사항) 호스트에 도달하는 포트 번호. 기본값은 8075입니다.
• tlsEnabled: (선택 사항) 특정 항목을 위해 global.gitaly.tls.enabled를 재정의합니다.

외부 Gitaly 서비스 사용에 대한 고급 구성 가이드가 제공됩니다. 예제 폴더에서 다중 외부 서비스 구성의 예제도 찾을 수 있습니다.

외부 Praefect를 사용하여 고가용성 Gitaly 서비스를 제공할 수 있습니다. 두 가지의 구성은 클라이언트 관점에서 차이가 없기 때문에 서로 교차 구성이 가능합니다.

현재 내부 또는 외부 서비스에는 동일한 Gitaly 서비스에 대해 동일한 Gitaly 인증 토큰이 예상됩니다. 이를 확인하세요. 더 자세한 내용은 이슈 #1992를 참조하세요.

혼합

내부 및 외부 Gitaly 노드를 모두 사용할 수 있지만 다음 사항을 유의하십시오:

• 항상 default라는 노드가 있어야 함, 내부에서 기본으로 제공됩니다.
• 외부 노드는 먼저 채워진 후 내부 노드가 채워집니다.

혼합 내부 및 외부 노드의 구성 예는 예제 폴더에서 찾을 수 있습니다.

authToken

Gitaly의 authToken 속성에는 두 가지 하위 키가 있습니다:

• secret는 추출할 쿠버네티스 Secret의 이름을 정의합니다.
• key는 위의 secret에 포함된 authToken을 정의합니다.

모든 Gitaly 노드는 반드시 동일한 인증 토큰을 공유해야 합니다.

사용되지 않는 Gitaly 설정

TLS 설정

TLS를 통해 Gitaly를 제공하는 방법에 대한 자세한 내용은 Gitaly 차트 설명서에 나와 있습니다.

Praefect 설정 구성

전역 Praefect 설정은 global.praefect 키 아래에 있습니다.

Praefect는 기본적으로 비활성화되어 있습니다. 추가 설정 없이 활성화할 경우 3개의 Gitaly 레플리카가 생성되며 Praefect 데이터베이스는 기본 PostgreSQL 인스턴스에 매뉴얼으로 생성해야 합니다.

Praefect 활성화

기본 설정으로 Praefect를 활성화하려면 global.praefect.enabled=true로 설정하세요.

Praefect를 사용하여 Gitaly 클러스터를 운영하는 방법에 대한 자세한 내용은 Praefect 문서를 참조하세요.

Praefect의 전역 설정

global:
  praefect:
    enabled: false
    virtualStorages:
    - name: default
      gitalyReplicas: 3
      maxUnavailable: 1
    dbSecret: {}
    psql: {}

MinIO 설정 구성

GitLab 전역 MinIO 설정은 global.minio 키 아래에 있습니다. 이 설정에 대한 자세한 내용은 MinIO 차트 내에 있는 문서를 참조하세요.

global:
  minio:
    enabled: true
    credentials: {}

appConfig 설정 구성

Webservice, Sidekiq, 및 Gitaly 차트는 global.appConfig 키로 구성된 여러 설정을 공유합니다.

global:
  appConfig:
    # cdnHost:
    contentSecurityPolicy:
      enabled: false
      report_only: true
      # directives: {}
    enableUsagePing: true
    enableSeatLink: true
    enableImpersonation: true
    applicationSettingsCacheSeconds: 60
    usernameChangingEnabled: true
    issueClosingPattern:
    defaultTheme:
    defaultProjectsFeatures:
      issues: true
      mergeRequests: true
      wiki: true
      snippets: true
      builds: true
      containerRegistry: true
    webhookTimeout:
    gravatar:
      plainUrl:
      sslUrl:
    extra:
      googleAnalyticsId:
      matomoUrl:
      matomoSiteId:
      matomoDisableCookies:
      oneTrustId:
      googleTagManagerNonceId:
      bizible:
    object_store:
      enabled: false
      proxy_download: true
      storage_options: {}
      connection: {}
    lfs:
      enabled: true
      proxy_download: true
      bucket: git-lfs
      connection: {}
    artifacts:
      enabled: true
      proxy_download: true
      bucket: gitlab-artifacts
      connection: {}
    uploads:
      enabled: true
      proxy_download: true
      bucket: gitlab-uploads
      connection: {}
    packages:
      enabled: true
      proxy_download: true
      bucket: gitlab-packages
      connection: {}
    externalDiffs:
      enabled:
      when:
      proxy_download: true
      bucket: gitlab-mr-diffs
      connection: {}
    terraformState:
      enabled: false
      bucket: gitlab-terraform-state
      connection: {}
    ciSecureFiles:
      enabled: false
      bucket: gitlab-ci-secure-files
      connection: {}
    dependencyProxy:
      enabled: false
      bucket: gitlab-dependency-proxy
      connection: {}
    backups:
      bucket: gitlab-backups
    microsoft_graph_mailer:
      enabled: false
      user_id: "YOUR-USER-ID"
      tenant: "YOUR-TENANT-ID"
      client_id: "YOUR-CLIENT-ID"
      client_secret:
        secret:
        key: secret
      azure_ad_endpoint: "https://login.microsoftonline.com"
      graph_endpoint: "https://graph.microsoft.com"
    incomingEmail:
      enabled: false
      address: ""
      host: "imap.gmail.com"
      port: 993
      ssl: true
      startTls: false
      user: ""
      password:
        secret:
        key: password
      mailbox: inbox
      idleTimeout: 60
      inboxMethod: "imap"
      clientSecret:
        key: secret
      pollInterval: 60
      deliveryMethod: webhook
      authToken: {}
    
    serviceDeskEmail:
      enabled: false
      address: ""
      host: "imap.gmail.com"
      port: 993
      ssl: true
      startTls: false
      user: ""
      password:
        secret:
        key: password
      mailbox: inbox
      idleTimeout: 60
      inboxMethod: "imap"
      clientSecret:
        key: secret
      pollInterval: 60
      deliveryMethod: webhook
      authToken: {}
    
    cron_jobs: {}
    sentry:
      enabled: false
      dsn:
      clientside_dsn:
      environment:
    gitlab_docs:
      enabled: false
      host: ""
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
    sidekiq:
      routingRules: []

일반 애플리케이션 설정

일반 Rails 애플리케이션의 일반 속성을 조정할 수 있는 appConfig 설정에 대해 아래에서 설명합니다.

Content Security Policy

콘텐츠 보안 정책(CSP)을 설정하면 JavaScript 크로스 사이트 스크립팅(XSS) 공격을 방지할 수 있습니다. 구성 세부 정보는 GitLab 문서를 참조하십시오. 콘텐츠 보안 정책 문서

GitLab은 CSP에 대해 안전한 기본 값을 자동으로 제공합니다.

global:
  appConfig:
    contentSecurityPolicy:
      enabled: true
      report_only: false

사용자 지정 CSP 추가:

global:
  appConfig:
    contentSecurityPolicy:
      enabled: true
      report_only: false
      directives:
        default_src: "'self'"
        script_src: "'self' 'unsafe-inline' 'unsafe-eval' https://www.recaptcha.net https://apis.google.com"
        frame_ancestors: "'self'"
        frame_src: "'self' https://www.recaptcha.net/ https://content.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://content-cloudresourcemanager.googleapis.com"
        img_src: "* data: blob:"
        style_src: "'self' 'unsafe-inline'"

CSP 규칙을 잘못 구성하면 GitLab이 제대로 작동하지 않을 수 있습니다. 정책을 적용하기 전에 구성을 테스트하기 위해 report_only를 true로 변경할 수도 있습니다.

defaultProjectsFeatures

새 프로젝트가 기본적으로 해당 기능으로 생성되어야 하는지 여부를 결정하는 플래그입니다. 모든 플래그는 기본적으로 true입니다.

defaultProjectsFeatures:
  issues: true
  mergeRequests: true
  wiki: true
  snippets: true
  builds: true
  containerRegistry: true

Gravatar/Libravatar 설정

기본적으로 차트는 gravatar.com에서 제공되는 Gravatar 아바타 서비스와 함께 작동합니다. 그러나 필요한 경우 사용자 지정 Libravatar 서비스를 사용할 수도 있습니다:

GitLab 인스턴스에 분석 서비스 연동

Google Analytics 및 Matomo와 같은 분석 서비스를 구성하는 설정은 appConfig 아래의 extra 키 아래에 정의됩니다.

통합된 객체 리포지터리

개별 설정을 구성하는 아래 섹션 외에, 이러한 항목들에 대한 공유 구성을 용이하게 하기 위해 통합된 객체 리포지터리 구성이 추가되었습니다. object_store를 활용하여 connection을 한 번 구성하면, 개별적으로 connection 속성으로 구성되지 않은 모든 객체 리포지터리를 지원하는 기능에 대해 사용됩니다.

  enabled: true
  proxy_download: true
  storage_options:
  connection:
    secret:
    key:

속성 구조는 공유되며 여기에 모든 속성은 아래의 개별 항목들에 의해 재정의될 수 있습니다. connection 속성 구조는 동일합니다.

주의: bucket, enabled, proxy_download 속성은 기본값과 다르게 구성하려면 개별 항목별로(global.appConfig.artifacts.bucket, …) 구성해야 하는 유일한 속성입니다.

연결에 아래 (즉, 포함 된 MinIO와 같은 S3 호환 공급자) AWS 공급자를 사용할 때 GitLab Workhorse는 모든 리포지터리 관련 업로드를 오프로드할 수 있습니다. 이 설정은 통합된 구성을 사용할 때 자동으로 활성화됩니다.

버킷 지정

각 객체 유형은 다른 버킷에 저장되어야 합니다. 기본적으로 GitLab은 각 유형에 대해 다음과 같은 버킷 이름을 사용합니다.

이러한 기본값을 사용하거나 버킷 이름을 구성할 수 있습니다.

--set global.appConfig.artifacts.bucket=<버킷 이름> \
--set global.appConfig.lfs.bucket=<버킷 이름> \
--set global.appConfig.packages.bucket=<버킷 이름> \
--set global.appConfig.uploads.bucket=<버킷 이름> \
--set global.appConfig.externalDiffs.bucket=<버킷 이름> \
--set global.appConfig.terraformState.bucket=<버킷 이름> \
--set global.appConfig.ciSecureFiles.bucket=<버킷 이름> \
--set global.appConfig.dependencyProxy.bucket=<버킷 이름>

storage_options

storage_options는 S3 서버 측 암호화를 구성하는 데 사용됩니다.

기본 암호화를 S3 버킷에 설정하는 것은 암호화를 활성화하는 가장 쉬운 방법이지만, 암호화 된 객체만 업로드되도록 버킷 정책을 설정할 수도 있습니다. 이를 위해 storage_options 구성 섹션에서 적절한 암호화 헤더를 보내도록 GitLab을 구성해야 합니다.

예:

  enabled: true
  proxy_download: true
  connection:
    secret: gitlab-rails-storage
    key: connection
  storage_options:
    server_side_encryption: aws:kms
    server_side_encryption_kms_key_id: arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

LFS, 아티팩트, 업로드, 패키지, 외부 MR 차이 및 의존성 프록시

이러한 설정에 대한 자세한 내용은 아래에 있습니다. 기본값 이외에는 설정이 구조적으로 동일하기 때문에 별도로 문서화되어 있지 않습니다.

  enabled: true
  proxy_download: true
  bucket:
  connection:
    secret:
    key:

connection

connection 속성은 Kubernetes Secret로 전환되었습니다. 이 시크릿의 내용은 YAML 형식으로 되어 있어야 합니다. 기본값은 {}이며 global.minio.enabled가 true인 경우 무시됩니다.

이 속성에는 secret 및 key라는 두 개의 하위 키가 있습니다. - secret는 Kubernetes Secret의 이름입니다. 외부 객체 리포지터리를 사용하려면 이 값이 필요합니다. - key는 YAML 블록을 포함하는 시크릿 내에서의 키 이름입니다. 기본값은 connection입니다.

유효한 구성 키에 대한 정보는 GitLab Job Artifacts Administration 문서에서 찾을 수 있습니다. 이는 Fog와 일치하며 제공자 모듈간에 다릅니다.

AWS(https://fog.io/storage/#using-amazon-s3-and-fog) 및 Google(https://fog.io/storage/#google-cloud-storage) 제공자에 대한 예제는 examples/objectstorage에서 찾을 수 있습니다.

• rails.s3.yaml
• rails.gcs.yaml
• rails.azurerm.yaml

connection의 내용을 포함하는 YAML 파일을 만든 후 이 파일을 사용하여 Kubernetes에서 시크릿을 생성합니다.

kubectl create secret generic gitlab-rails-storage \
    --from-file=connection=rails.yaml

when (외부 MR 차이의 경우만)

externalDiffs 설정에는 특정 차이를 객체 리포지터리에 조건부로 저장하기 위해 추가적인 when 키가 있습니다. 이 설정은 차트에서 기본값으로 비워두어 두면 기본값이 Rails 코드에 의해 할당됩니다.

cdn (CI 아티팩트의 경우만)

아티팩트 설정에는 구글 클라우드 스토리지 버킷 앞에 구글 CDN을 구성하기 위한 추가 키 cdn이 있습니다.

수신 이메일 설정

수신 이메일 설정은 command line options page에서 설명되어 있습니다.

KAS 설정

사용자 지정 시크릿

KAS secret 이름 및 key를 Helm의 --set variable 옵션을 사용하여 선택적으로 사용자 정의할 수 있습니다.

--set global.appConfig.gitlab_kas.secret=custom-secret-name \
--set global.appConfig.gitlab_kas.key=custom-secret-key \

또는 values.yaml을 구성하여 사용자 지정할 수 있습니다.

global:
  appConfig:
    gitlab_kas:
      secret: "custom-secret-name"
      key: "custom-secret-key"

시크릿 값에 대한 사용자 지정을 원하는 경우 시크릿 문서를 참조하십시오.

사용자 지정 URL

GitLab 백엔드에서 사용하는 KAS에 대해 사용자 지정할 수 있는 URL은 Helm의 --set variable 옵션을 사용하여 구성할 수 있습니다.

--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \

또는 values.yaml을 구성하여 사용자 지정할 수 있습니다.

global:
  appConfig:
    gitlab_kas:
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"

외부 KAS

GitLab 백엔드는 명시적으로 활성화하고 필요한 URL을 구성함으로써 외부 KAS 서버(즉, 차트에서 관리되지 않음)를 인식할 수 있습니다. 이를 위해 Helm의 --set 변수 옵션을 사용할 수 있습니다:

--set global.appConfig.gitlab_kas.enabled=true \
--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \

또는 values.yaml을 구성함으로써 할 수도 있습니다:

global:
  appConfig:
    gitlab_kas:
      enabled: true
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"

TLS 설정

KAS는 kas pod과 다른 GitLab 차트 컴포넌트 간의 TLS 통신을 지원합니다.

전제 조건:

• GitLab 15.5.1 이상 사용. global.gitlabVersion: <version>을 사용하여 GitLab 버전을 설정할 수 있습니다. 초기 배포 후 이미지 업데이트를 강제해야 하는 경우 global.image.pullPolicy: Always도 설정하세요.
• kas pod에서 신뢰할 수 있는 인증서 기관 및 인증서를 생성하세요.

생성한 인증서를 사용하도록 kas를 구성하려면 다음 값을 설정하세요.

예를 들어, 다음을 values.yaml 파일에 사용하여 차트를 배포할 수 있습니다:

.internal-ca: &internal-ca gitlab-internal-tls-ca # 사용한 TLS CA의 시크릿 이름
.internal-tls: &internal-tls gitlab-internal-tls # 사용한 TLS 인증서의 시크릿 이름

global:
  certificates:
    customCAs:
    - secret: *internal-ca
  hosts:
    domain: gitlab.example.com # 귀하의 gitlab 도메인
  kas:
    tls:
      enabled: true
      secretName: *internal-tls
      caSecretName: *internal-ca

제안된 리뷰어 설정

Helm의 --set 변수 옵션을 사용하거나 values.yaml을 구성함으로써 제안된 리뷰어 secret 이름 및 key를 선택적으로 사용자 정의할 수 있습니다.:

--set global.appConfig.suggested_reviewers.secret=custom-secret-name \
--set global.appConfig.suggested_reviewers.key=custom-secret-key \

또는 다음과 같이 values.yaml을 구성할 수도 있습니다:

global:
  appConfig:
    suggested_reviewers:
      secret: "custom-secret-name"
      key: "custom-secret-key"

시크릿 값을 사용자 정의하려면 시크릿 문서를 참조하세요.

LDAP

ldap.servers 설정을 사용하여 LDAP 사용자 인증을 구성할 수 있습니다. 이는 맵으로 제시되며 소스에서의 설치와 마찬가지로 gitlab.yml에 적절한 LDAP 서버 구성으로 변환됩니다.

비밀번호를 구성하는 방법은 암호를 보유하는 secret를 제공하여 수행할 수 있습니다. 이 암호는 실행 시에 GitLab 구성에 주입됩니다.

구성 예시:

ldap:
  preventSignin: false
  servers:
    # 'main'은 이 LDAP 서버의 GitLab '공급자 ID'입니다.
    main:
      label: 'LDAP'
      host: '_your_ldap_server'
      port: 636
      uid: 'sAMAccountName'
      bind_dn: 'cn=administrator,cn=Users,dc=domain,dc=net'
      base: 'dc=domain,dc=net'
      password:
        secret: my-ldap-password-secret
        key: the-key-containing-the-password

전역 차트를 사용할 경우, 다음과 같은 --set 구성 항목 예시:

--set global.appConfig.ldap.servers.main.label='LDAP' \
--set global.appConfig.ldap.servers.main.host='your_ldap_server' \
--set global.appConfig.ldap.servers.main.port='636' \
--set global.appConfig.ldap.servers.main.uid='sAMAccountName' \
--set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net' \
--set global.appConfig.ldap.servers.main.base='dc=domain\,dc=net' \
--set global.appConfig.ldap.servers.main.password.secret='my-ldap-password-secret' \
--set global.appConfig.ldap.servers.main.password.key='the-key-containing-the-password'

LDAP 웹 로그인 비활성화

SAML과 같은 대체 방법을 선호하는 경우 웹 UI를 통해 LDAP 자격 증명을 사용하지 못하게 하는 것이 유용할 수 있습니다. 이렇게 하면 LDAP이 그룹 동기화에 사용될 수 있도록 하고, SAML ID 공급자가 사용자 정의 2FA와 같은 추가 확인을 처리할 수 있습니다.

LDAP 웹 로그인을 비활성화하면 사용자는 로그인 페이지에서 LDAP 탭을 볼 수 없습니다. 이로 인해 Git 액세스에 대한 LDAP 자격 증명 사용이 비활성화되지 않습니다.

LDAP을 웹 로그인에 사용하지 못하도록 설정하려면 global.appConfig.ldap.preventSignin을 true로 설정하세요.

사용자 정의 CA 또는 자체 서명된 LDAP 인증서 사용

LDAP 서버가 사용자 정의 CA나 자체 서명된 인증서를 사용하는 경우 다음을 수행해야 합니다:

1. 사용자 정의 CA/자체 서명된 인증서를 클러스터/네임스페이스에 시크릿 또는 ConfigMap으로 생성합니다:

   # Secret
   kubectl -n gitlab create secret generic my-custom-ca-secret --from-file=unique_name.crt=my-custom-ca.pem
      
   # ConfigMap
   kubectl -n gitlab create configmap my-custom-ca-configmap --from-file=unique_name.crt=my-custom-ca.pem
   

2. 그런 다음 다음과 같이 지정하세요:

   # Secret에서 사용자 정의 CA 구성
   --set global.certificates.customCAs[0].secret=my-custom-ca-secret
      
   # 또는 ConfigMap에서 구성
   --set global.certificates.customCAs[0].configMap=my-custom-ca-configmap
      
   # LDAP 통합에 사용자 정의 CA를 신뢰하도록 구성
   --set global.appConfig.ldap.servers.main.ca_file=/etc/ssl/certs/unique_name.pem
   

이렇게 하면 해당 CA 인증서가 관련 pod에 /etc/ssl/certs/unique_name.pem에 마운트되고 LDAP 구성에서 해당 CA 인증서를 사용하도록 지정됩니다.

자세한 내용은 사용자 정의 인증 기관을 참조하세요.

DuoAuth

GitLab Duo를 사용하여 이중 요소 인증(2FA)을 활성화하려면 이 설정을 사용하세요.

global:
  appConfig:
    duoAuth:
      enabled:
      hostname:
      integrationKey:
      secretKey:
      #  secret:
      #  key:

GitLab Duo 비밀 키 구성

GitLab Helm 차트에서 GitLab Duo 인증 통합을 구성하려면, global.appConfig.duoAuth.secretKey.secret 설정에 GitLab Duo 계정 secretKey 값을 포함하는 시크릿을 제공해야 합니다.

명령줄에서 GitLab Duo 계정 secretKey를 저장할 Kubernetes 시크릿 개체를 만들려면 다음을 실행하세요.

kubectl create secret generic <secret_object_name> --from-literal=secretKey=<duo_secret_key_value>

OmniAuth

GitLab은 OmniAuth를 활용하여 사용자가 Twitter, GitHub, Google 등 인기 있는 서비스를 사용하여 로그인할 수 있도록 할 수 있습니다. 보다 구체적인 설명은 OmniAuth 문서에서 확인할 수 있습니다.

omniauth:
  enabled: false
  autoSignInWithProvider:
  syncProfileFromProvider: []
  syncProfileAttributes: ['email']
  allowSingleSignOn: ['saml']
  blockAutoCreatedUsers: true
  autoLinkLdapUser: false
  autoLinkSamlUser: false
  autoLinkUser: ['saml']
  externalProviders: []
  allowBypassTwoFactor: []
  providers: []
  # - secret: gitlab-google-oauth2
  #   key: provider
  # - name: group_saml

providers

providers는 설치시 gitlab.yml를 채우는 데 사용되는 맵의 배열로 나타납니다. 사용 가능한 지원되는 제공자에 대한 GitLab 문서를 참조하세요. 기본값은 []입니다.

이 속성에는 secret와 key라는 두 가지 하위 키가 있습니다:

• secret: (필수) 제공자 블록을 포함하는 Kubernetes Secret의 이름.
• key: (선택 사항) Secret의 제공자 블록을 포함하는 키의 이름입니다. 기본값은 provider입니다.

제공자가 해당 이름 이외의 설정이 없는 경우, name 속성만 있는 두 번째 형식을 사용할 수 있으며, label 또는 icon 속성을 선택적으로 사용할 수 있습니다. 사용할 수 있는 제공자는 다음과 같습니다. - group_saml - kerberos

이러한 항목의 Secret에는 OmniAuth 제공자에 설명된 YAML 또는 JSON 형식의 블록이 포함됩니다. 이 시크릿을 만들려면 해당 항목을 가져오는 적절한 지침에 따라 YAML 또는 JSON 파일을 만들어야 합니다.

Google OAuth2의 구성 예시:

name: google_oauth2
label: Google
app_id: 'APP ID'
app_secret: 'APP SECRET'
args:
  access_type: offline
  approval_prompt: ''

SAML 구성 예시:

name: saml
label: 'SAML'
args:
  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback'
  idp_cert_fingerprint: 'xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
  idp_sso_target_url: 'https://SAML_IDP/app/xxxxxxxxx/xxxxxxxxx/sso/saml'
  issuer: 'https://gitlab.example.com'
  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'

Microsoft Azure OAuth 2.0 OmniAuth 제공자 구성 예시:

name: azure_activedirectory_v2
label: Azure
args:
  client_id: '<CLIENT_ID>'
  client_secret: '<CLIENT_SECRET>'
  tenant_id: '<TENANT_ID>'

이 내용은 provider.yaml로 저장되어, 다음과 같이 시크릿을 만들 수 있습니다.

kubectl create secret generic -n NAMESPACE SECRET_NAME --from-file=provider=provider.yaml

생성된 후, 아래와 같이 providers를 구성하여 맵을 제공함으로써 활성화됩니다.

omniauth:
  providers:
    - secret: gitlab-google-oauth2
    - secret: azure_activedirectory_v2
    - secret: gitlab-azure-oauth2
    - secret: gitlab-cas3

글로벌 차트를 사용할 때 예시 구성 --set 항목:

--set global.appConfig.omniauth.providers[0].secret=gitlab-google-oauth2 \

Cron 작업 관련 설정

Sidekiq에는 cron 스타일 일정을 사용하여 주기적으로 구성할 수 있는 유지 보수 작업이 포함되어 있습니다. 몇 가지 예시를 아래에 제공합니다. 더 많은 작업 예시는 샘플 gitlab.yml 파일의 cron_jobs 및ee_cron_jobs 섹션을 참조하세요.

이러한 설정은 Sidekiq, UI에서 툴팁 표시에 사용되는 Webservice 및 (디버깅 목적으로) Toolbox pods 사이에서 공유됩니다.

global:
  appConfig:
    cron_jobs:
      stuck_ci_jobs_worker:
        cron: "0 * * * *"
      pipeline_schedule_worker:
        cron: "19 * * * *"
      expire_build_artifacts_worker:
        cron: "*/7 * * * *"

Sentry 설정

이 설정을 사용하여 Sentry를 통한 GitLab 오류 보고를 활성화합니다.

global:
  appConfig:
    sentry:
      enabled:
      dsn:
      clientside_dsn:
      environment:

gitlab_docs 설정

이 설정을 사용하여 gitlab_docs를 활성화합니다.

global:
  appConfig:
    gitlab_docs:
      enabled:
      host:

스마트카드 인증 설정

global:
  appConfig:
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
      sanExtensions: false
      requiredForGitAccess: false

Sidekiq 라우팅 규칙 설정

GitLab은 작업을 예약하기 전에 워커에서 원하는 대기열로 작업을 라우팅하는 기능을 지원합니다. Sidekiq 클라이언트는 작업을 구성된 라우팅 규칙 디렉터리과 일치시킵니다. 규칙은 첫 번째부터 마지막까지 순서대로 평가되며 특정 워커에 대한 일치 항목이 발견되면 해당 워커의 처리가 중지됩니다(첫 번째 일치 항목이 승리합니다). 워커가 어떤 규칙과도 일치하지 않으면 워커 이름을 기반으로 생성된 대기열로 라우팅됩니다.

기본적으로 라우팅 규칙은 구성되어 있지 않습니다 (또는 빈 배열로 표시됩니다). 그 결과 모든 작업은 워커 이름에 따라 생성된 대기열로 라우팅됩니다.

라우팅 규칙 디렉터리은 쿼리 및 해당 대기열의 순서가 있는 튜플의 순서 배열입니다:

• 쿼리는 워커 일치 쿼리 구문을 따릅니다.
• <queue_name>은 sidekiq.pods[].queues에 정의된 유효한 Sidekiq 대기열 이름과 일치해야 합니다. 대기열 이름이 nil이거나 빈 문자열인 경우 워커는 대기열 대신 워커 이름에서 생성된 대기열로 라우팅됩니다. 참조용으로 Sidekiq 구성의 전체 예시를 확인하세요.

쿼리는 모든 워커와 일치하는 와일드카드 일치 *을 지원합니다. 결과적으로 와일드카드 쿼리는 디렉터리의 마지막에 유지되어야 하며 나중 규칙은 무시됩니다.

global:
  appConfig:
    sidekiq:
      routingRules:
      - ["resource_boundary=cpu", "cpu-boundary"]
      - ["feature_category=pages", null]
      - ["feature_category=search", "search"]
      - ["feature_category=memory|resource_boundary=memory", "memory-bound"]
      - ["*", "default"]

Rails 설정 구성

GitLab 스위트의 대부분은 Rails를 기반으로 합니다. 따라서 이 프로젝트 내의 많은 컨테이너가 이 스택으로 작동합니다. 이러한 설정은 모든 컨테이너에 적용되며 이들을 전체적으로 개별적으로 설정하는 간단한 액세스 방법을 제공합니다.

global:
  rails:
    bootsnap:
      enabled: true

Workhorse 설정 구성

GitLab 스위트의 여러 컴포넌트는 GitLab Workhorse를 통해 API에 연결합니다. 이는 현재 Webservice 차트의 일부입니다. 이러한 설정은 GitLab Workhorse에 연락해야 하는 모든 차트에서 사용되며, 개별적으로 설정하는 것보다 전체적으로 설정하는 간단한 액세스를 제공합니다.

global:
  workhorse:
    serviceName: webservice-default
    host: api.example.com
    port: 8181

Bootsnap Cache

저희의 Rails 코드베이스는 Shopify의 Bootsnap Gem을 활용합니다. 여기서의 설정은 해당 동작을 구성합니다.

bootsnap.enabled는 이 기능의 활성화를 제어합니다. 기본값은 true입니다.

테스트 결과, Bootsnap을 활성화하면 전체적인 애플리케이션 성능 향상이 있습니다. 사전 컴파일된 캐시가 있는 경우, 일부 응용프로그램 컨테이너에서 33% 이상의 성능 향상이 있습니다. 현재 GitLab은 컨테이너에 이 사전 컴파일된 캐시를 제공하지 않기 때문에 “only” 14%의 이득이 있습니다. 이로 인해 각 Pod의 초기 시작 시간에 소량의 IO의 강한 상승이 있습니다. 따라서 이 문제가 발생할 수 있는 환경에서 Bootsnap 사용을 비활성화하는 방법을 노출시켰습니다.

가능한 경우, 이 기능을 활성화하는 것이 좋습니다.

GitLab Shell 설정 구성

GitLab Shell 차트의 전역 구성 항목이 몇 가지 있습니다.

global:
  shell:
    port:
    authToken: {}
    hostKeys: {}
    tcp:
      proxyProtocol: false

포트

SSH 트래픽을 전달하는 인그레스에서 사용하는 포트 및 GitLab을 통해 제공되는 SSH URL에서 사용되는 포트를 global.shell.port를 통해 제어할 수 있습니다. 이는 서비스가 수신 대기하는 포트 및 프로젝트 UI에서 제공되는 SSH 복제 URL에서 반영됩니다.

global:
  shell:
    port: 32022

global.shell.port와 nginx-ingress.controller.service.type=NodePort를 결합하여 NGINX 컨트롤러 서비스 객체에 대한 NodePort를 설정할 수 있습니다. nginx-ingress.controller.service.nodePorts.gitlab-shell이 설정된 경우 NGINX의 NodePort를 설정할 때 global.shell.port를 덮어씁니다.

global:
  shell:
    port: 32022

nginx-ingress:
  controller:
    service:
      type: NodePort

TCP 프록시 프로토콜

SSH 인그레스에서 프록시 프로토콜을 활성화하여 프록시 프로토콜 헤더를 추가하는 상위 프록시에서 연결을 올바르게 처리할 수 있습니다. 이를 통해 SSH가 추가 헤더를 수신하지 않고 SSH가 손상되지 않도록 할 수 있습니다.

프록시 프로토콜 처리를 활성화해야 하는 일반적인 환경은 클러스터로 들어오는 연결을 처리하는 ELB를 사용하는 AWS입니다. 이를 올바르게 설정하려면 AWS 레이어 4 로드 밸런서 예제를 참조할 수 있습니다.

global:
  shell:
    tcp:
      proxyProtocol: true # 기본값은 false

GitLab Pages 구성

다른 차트에서 사용되는 전역 GitLab Pages 설정은 global.pages 키 아래에 문서화되어 있습니다.

global:
  pages:
    enabled:
    accessControl:
    path:
    host:
    port:
    https:
    externalHttp:
    externalHttps:
    artifactsServer:
    objectStore:
      enabled:
      bucket:
      proxy_download: true
      connection: {}
        secret:
        key:
    localStore:
      enabled: false
      path:
    apiSecret: {}
      secret:
      key:

Webservice 구성

다른 차트에서도 사용되는 전역 Webservice 설정은 global.webservice 키 아래에 있습니다.

global:
  webservice:
    workerTimeout: 60

workerTimeout

Webservice 워커 프로세스가 Webservice 마스터 프로세스에 의해 종료되는 요청 제한 시간(초)을 구성합니다. 기본값은 60초입니다.

global.webservice.workerTimeout 설정은 최대 요청 기간에 영향을 주지 않습니다. 최대 요청 기간을 설정하려면 다음과 같이 환경 변수를 설정하면 됩니다:

gitlab:
  webservice:
    workerTimeout: 60
    extraEnv:
      GITLAB_RAILS_RACK_TIMEOUT: "60"
      GITLAB_RAILS_WAIT_TIMEOUT: "90"

사용자 정의 인증 기관

일부 사용자는 내부에서 발급 된 SSL 인증서를 사용할 때와 같이 사용자 정의 루트 인증 기관을 추가해야 할 수 있습니다. 이 기능을 제공하기 위해이 응용 프로그램으로 사용자 정의 루트 인증 기관을 시크릿 또는 ConfigMap을 통해 애플리케이션에 삽입 할 수 있는 메커니즘을 제공합니다.

시크릿 또는 ConfigMap을 만들려면:

# 인증서 파일에서 시크릿 생성
kubectl create secret generic secret-custom-ca --from-file=unique_name.crt=/path/to/cert

# 인증서 파일에서 ConfigMap 생성
kubectl create configmap cm-custom-ca --from-file=unique_name.crt=/path/to/cert

시크릿 또는 ConfigMap 또는 둘 다를 구성하려면 globals에 지정하십시오:

global:
  certificates:
    customCAs:
      - secret: secret-custom-CAs           # 시크릿의 모든 키를 마운트
      - secret: secret-custom-CAs           # 특정 키만 마운트
        keys:
          - unique_name.crt
      - configMap: cm-custom-CAs            # ConfigMap의 모든 키를 마운트
      - configMap: cm-custom-CAs            # 특정 키만 마운트
        keys:
          - unique_name_1.crt
          - unique_name_2.crt

애플리케이션 리소스

GitLab은 옵션으로 애플리케이션 리소스를 포함할 수 있으며, 클러스터 내에서 GitLab 애플리케이션을 식별할 수 있도록 만들 수 있습니다. 클러스터에 이미 버전 v1beta1의 애플리케이션 CRD가 배포되어 있어야 합니다.

활성화하려면 global.application.create를 true로 설정하세요:

global:
  application:
    create: true

Google GKE Marketplace와 같은 일부 환경에서는 ClusterRole 리소스의 생성이 허용되지 않을 수 있습니다. 이 경우 Cloud Native GitLab과 함께 제공되는 Application Custom Resource 정의에서 ClusterRole 컴포넌트를 비활성화하려면 다음 값을 설정하세요.

global:
  application:
    allowClusterRoles: false
nginx:
  controller:
    scope:
      enabled: true
gitlab-runner:
  rbac:
    clusterWideAccess: false
certmanager:
  install: false

GitLab 베이스 이미지

GitLab Helm 차트는 다양한 초기화 작업에 공통 GitLab 베이스 이미지를 사용합니다. 이 이미지는 UBI 빌드를 지원하며, 다른 이미지와 레이어를 공유합니다.

서비스 계정

GitLab Helm 차트를 사용하면 커스텀 서비스 계정을 사용하여 pod을 실행할 수 있습니다. 이는 다음 설정으로 구성됩니다: global.serviceAccount.

global:
  serviceAccount:
    enabled: false
    create: true
    annotations: {}
    ## Name to be used for serviceAccount, otherwise defaults to chart fullname
    # name:

• global.serviceAccount.enabled 설정은 각 컴포넌트에 대한 ServiceAccount 참조를 spec.serviceAccountName을 통해 제어합니다.
• global.serviceAccount.create 설정은 Helm을 통한 ServiceAccount 객체 생성을 제어합니다.
• global.serviceAccount.name 설정은 ServiceAccount 객체 이름과 각 컴포넌트에서 참조되는 이름을 제어합니다.

어노테이션

맞춤 어노테이션을 배포, 서비스 및 인그레스 객체에 적용할 수 있습니다.

global:
  deployment:
    annotations:
      environment: production
  
  service:
    annotations:
      environment: production
  
  ingress:
    annotations:
      environment: production

노드 셀렉터

모든 컴포넌트에 사용자 정의 nodeSelector를 전역적으로 적용할 수 있습니다. 전역 기본값은 각 서브차트에서도 재정의할 수 있습니다.

global:
  nodeSelector:
    disktype: ssd

라벨

공통 라벨

common.labels 구성을 사용하여 생성된 거의 모든 객체에 라벨을 적용할 수 있습니다. 이 설정은 global 키 또는 특정 차트의 구성 아래에 적용할 수 있습니다. 예시:

global:
  common:
    labels:
      environment: production
gitlab:
  gitlab-shell:
    common:
      labels:
        foo: bar

위의 예시 구성으로 Helm 차트에 의해 배포된 거의 모든 컴포넌트에 environment: production 라벨 세트가 제공됩니다. GitLab Shell 차트의 모든 컴포넌트는 foo: bar 라벨 세트를 받습니다. 일부 차트는 추가적인 중첩을 허용합니다. 예를 들어, Sidekiq 및 Webservices 차트는 구성 요구사항에 따라 추가 배포를 허용합니다:

gitlab:
  sidekiq:
    pods:
      - name: pod-0
        common:
          labels:
            baz: bat

위의 예시에서 pod-0 Sidekiq 배포와 관련된 모든 컴포넌트에도 baz: bat 라벨 세트가 적용됩니다. 추가 정보는 Sidekiq 및 Webservice 차트를 참조하세요.

의존하는 일부 차트는 이 라벨 구성에서 제외됩니다. GitLab 컴포넌트 서브차트만 이러한 추가 라벨을 받게 됩니다.

Pod

다양한 배포 및 작업에 사용자 정의 라벨을 적용할 수 있습니다. 이러한 보조 라벨은 이 Helm 차트에 의해 구성된 기존 또는 사전 구성된 라벨에 대한 보충적인 역할을 합니다. 이러한 보충 라벨은 matchSelectors에 사용되지 않습니다.

global:
  pod:
    labels:
      environment: production

Service

서비스에 사용자 정의 라벨을 적용할 수 있습니다. 이러한 라벨은 이 Helm 차트에 의해 구성된 기존 또는 사전 구성된 라벨에 대해 보충적인 역할을 합니다.

global:
  service:
    labels:
      environment: production

추적

GitLab Helm 차트는 추적을 지원하며 다음과 같이 구성할 수 있습니다:

global:
  tracing:
    connection:
      string: 'opentracing://jaeger?http_endpoint=http%3A%2F%2Fjaeger.example.com%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1'
    urlTemplate: 'http://jaeger-ui.example.com/search?service={{ service }}&tags=%7B"correlation_id"%3A"{{ correlation_id }}"%7D'

• global.tracing.connection.string은 추적 스팬이 전송될 위치를 구성하는 데 사용됩니다. 자세한 내용은 GitLab 추적 문서를 참조하세요.
• global.tracing.urlTemplate은 GitLab 성능 막대에서 추적 정보 URL 렌더링을 위한 템플릿으로 사용됩니다.

extraEnv

extraEnv를 사용하면 GitLab 차트를 통해 배포된 pod의 모든 컨테이너에 추가 환경 변수를 노출할 수 있습니다. 전역 수준에서 설정된 추가 환경 변수는 차트 수준에서 제공된 것과 Merge되어 차트 수준에서 제공된 환경 변수에 우선순위가 부여됩니다.

아래는 extraEnv의 사용 예시입니다:

global:
  extraEnv:
    SOME_KEY: some_value
    SOME_OTHER_KEY: some_other_value

Kerberos

GitLab Helm 차트에서 Kerberos 통합을 구성하려면 global.appConfig.kerberos.keytab.secret 설정에 Kerberos keytab을 포함하는 시크릿을 제공해야 합니다. 이 keytab에는 GitLab 호스트를 위한 서비스 주체가 포함되어 있어야 합니다. keytab 파일이 없는 경우 Kerberos 관리자의 도움을 받을 수 있습니다.

다음 스니펫을 사용하여 시크릿을 생성할 수 있습니다 (gitlab 네임스페이스에 차트를 설치하고 gitlab.keytab이 서비스 주체를 포함하는 keytab 파일이라고 가정함):

kubectl create secret generic gitlab-kerberos-keytab --namespace=gitlab --from-file=keytab=./gitlab.keytab

Git의 Kerberos 통합은 global.appConfig.kerberos.enabled=true로 설정하여 활성화됩니다. 이렇게 하면 브라우저에서 티켓 기반 인증을 위한 kerberos 공급자가 활성화된 OmniAuth 공급자 디렉터리에 추가됩니다.

false로 설정하면 Helm 차트는 여전히 toolbox, Sidekiq 및 webservice Pod에 keytab을 마운트하지만 매뉴얼으로 구성된 OmniAuth 설정을 사용하여 Kerberos를 사용할 수 있습니다.

global.appConfig.kerberos.krb5Config에서 Kerberos 클라이언트 구성을 제공할 수 있습니다.

global:
  appConfig:
    kerberos:
      enabled: true
      keytab:
        secret: gitlab-kerberos-keytab
        key: keytab
      servicePrincipalName: ""
      krb5Config: |
        [libdefaults]
            default_realm = EXAMPLE.COM
      dedicatedPort:
        enabled: false
        port: 8443
        https: true
      simpleLdapLinkingAllowedRealms:
        - example.com

자세한 내용은 Kerberos 문서를 확인하세요.

Kerberos 전용 포트

GitLab은 Git 작업에 HTTP 프로토콜을 사용할 때 Kerberos 협상을 위한 전용 포트 사용을 지원합니다. 이는 Git이 인증 교환에서 negotiate 헤더를 제시하면 기본 인증으로 되돌아가는 Git의 제한을 해결하기 위한 것입니다.

이 전용 포트는 GitLab CI/CD를 사용할 때 현재 필요합니다. GitLab Runner 헬퍼는 GitLab에서 복제하기 위해 URL 크레덴셜을 사용합니다.

이는 global.appConfig.kerberos.dedicatedPort 설정으로 활성화할 수 있습니다.

global:
  appConfig:
    kerberos:
      [...]
      dedicatedPort:
        enabled: true
        port: 8443
        https: true

이로써 GitLab UI에 Kerberos 협상 전용 복제 URL이 활성화됩니다. https: true 설정은 URL 생성 전용이며 추가 TLS 구성을 노출하지 않습니다. TLS는 GitLab의 Ingress에서 종료되고 구성됩니다.

LDAP 사용자 지정 허용 영역

global.appConfig.kerberos.simpleLdapLinkingAllowedRealms을 사용하여 사용자의 LDAP DN이 사용자의 Kerberos 영역과 일치하지 않을 때 LDAP 및 Kerberos ID를 연결하는 데 사용할 도메인 세트를 지정할 수 있습니다. 추가 정보는 Kerberos 통합 문서의 사용자 지정 허용 영역 섹션에서 확인할 수 있습니다.

발신 이메일

발신 이메일 구성은 global.smtp.*, global.appConfig.microsoft_graph_mailer.* 및 global.email.*을 통해 사용할 수 있습니다.

global:
  email:
    display_name: 'GitLab'
    from: 'gitlab@example.com'
    reply_to: 'noreply@example.com'
  smtp:
    enabled: true
    address: 'smtp.example.com'
    tls: true
    authentication: 'plain'
    user_name: 'example'
    password:
      secret: 'smtp-password'
      key: 'password'
  appConfig:
    microsoft_graph_mailer:
      enabled: false
      user_id: "YOUR-USER-ID"
      tenant: "YOUR-TENANT-ID"
      client_id: "YOUR-CLIENT-ID"
      client_secret:
        secret:
        key: secret
      azure_ad_endpoint: "https://login.microsoftonline.com"
      graph_endpoint: "https://graph.microsoft.com"

사용 가능한 구성 옵션에 대한 자세한 내용은 발신 이메일 문서에서 확인할 수 있습니다.

더 자세한 예제는 Linux 패키지 SMTP 설정 문서에서 찾을 수 있습니다.

플랫폼

platform 키는 GKE 또는 EKS와 같은 특정 플랫폼을 대상으로 하는 특정 기능을 위해 예약되어 있습니다.

Affinity

Affinity 구성은 global.antiAffinity 및 global.affinity를 통해 사용할 수 있습니다. Affinity를 사용하면 노드 레이블 또는 이미 실행 중인 pod의 레이블을 기반으로하여 pod이 예약될 수 있는 노드를 제한할 수 있습니다. 이는 클러스터 전체에 pod을 분산하거나 특정 노드를 선택하여 노드의 장애에 대비하여 더 많은 견고성을 보장합니다.

global:
  antiAffinity: soft
  affinity:
    podAntiAffinity:
      topologyKey: "kubernetes.io/hostname"

• global.antiAffinity에는 두 가지 값이 있습니다:
  • soft: 쿠버네티스 스케줄러가 규칙을 강제할 수는 있지만 결과를 보장하지는 않는 preferredDuringSchedulingIgnoredDuringExecution 안티 어피니티를 정의합니다.
  • hard: pod을 노드에 예약하기 위해 규칙을 반드시 준수해야 하는 requiredDuringSchedulingIgnoredDuringExecution 안티 어피니티를 정의합니다.
• global.affinity.podAntiAffinity.topologyKey는 노드를 논리적인 영역으로 분할하는 데 사용되는 노드 속성을 정의합니다. 가장 일반적인 topologyKey 값은 다음과 같습니다:
  • kubernetes.io/hostname
  • topology.kubernetes.io/zone
  • topology.kubernetes.io/region

쿠버네티스 참조 자료: pod 간 근접성 및 안티-근접성

pod 우선 순위 및 선점

pod 우선 순위는 global.priorityClassName, 또는 priorityClassName을 통해 서브 차트별로 구성할 수 있습니다. pod 우선 순위 설정을 통해 스케줄러에게 낮은 우선 순위의 pod을 제거하도록 알려 스케줄링을 할 수 있습니다.

global:
  priorityClassName: system-cluster-critical

로그 로테이션

• GitLab 15.6에서 소개되었습니다.

기본적으로 GitLab Helm 차트는 로그를 로테이션하지 않습니다. 이는 오랫동안 실행되는 컨테이너의 일시적인 리포지터리 문제를 야기할 수 있습니다.

로그 로테이션을 활성화하려면 GITLAB_LOGGER_TRUNCATE_LOGS 환경 변수를 true로 설정하십시오. 자세한 내용은 GitLab Logger의 문서를 참조하십시오. 특히, 다음 정보를 확인하십시오:

• GITLAB_LOGGER_TRUNCATE_INTERVAL.
• GITLAB_LOGGER_MAX_FILESIZE.

작업

원래 GitLab의 작업은 기본적으로 Helm .Release.Revision으로 접미사가 붙여졌으며 이는 항상 helm upgrade --install을 실행할 때 작업을 업데이트 시키고, 아무 변화가 없어도 업데이트를 유발하는 비이상적인 동작을 합니다. 또한 이는 helm template을 기반으로 한 워크플로우와의 적절한 작업을 방해했습니다. 예를 들어 ArgoCD를 사용할 때의 경우입니다. .Release.Revision을 이름에 사용하는 결정은 작업이 한 번만 실행될 수 있고 helm uninstall이 작업을 삭제하지 않을 것으로 예상한 것에 기반합니다. 이는 (지금은) 잘못된 가정이었습니다.

GitLab Helm 차트 7.9 이후로 기본적으로 작업 이름은 차트 앱 버전과 차트 값에 기반한 해시로 접미사가 붙어 안정적인 작업 이름을 유지하며, 아무것도 변경되지 않는 여러helm template 및 helm upgrade --install 실행에 걸쳐 작업 이름을 보장합니다(변경 사항이 없는 경우). 심지어 작업의 불변 필드 값을 수정해도 배포 중에 오류가 발생하지 않고 새로운 작업으로 교체됩니다(새 이름 때문입니다).

global.job.nameSuffixOverride를 설정하여 기본적으로 생성되는 해시를 사용자 정의 접미사로 오버라이드할 수 있습니다. 이 필드는 템플릿을 지원하므로 .Release.Revision을 이름 접미사로 사용하는 이전 동작을 재현할 수 있습니다:

global:
  job:
    nameSuffixOverride: '{{ .Release.Revision }}'

예를 들어, 모든 버전에 대해 latest와 같은 부동태그를 사용하기 때문에 의도적으로 항상 변경을 유발하려는 경우 타임스탬프와 같은 동적 값을 사용하여 기본적으로 생성되는 해시를 오버라이드할 수 있습니다:

global:
  job:
    nameSuffixOverride: '{{ dateInZone "2006-01-02-15-04-05" (now) "UTC" }}'

또는 아래와 같이 helm의 명령줄에서 사용할 수 있습니다:

helm <command> <options> --set global.job.nameSuffixOverride=$(date +%Y-%m-%d-%H-%M-%S)