- 호스트 설정 구성
- 수평 Pod 자동 확장기 설정 구성
- PodDisruptionBudget 설정 구성
- CronJob 설정 구성
- 모니터링 설정 구성
- Ingress 설정 구성
- GitLab 버전
- 모든 이미지 태그에 접미사 추가
- PostgreSQL 설정 구성
- Redis 설정 구성하기
- 레지스트리 설정 구성
- Gitaly 설정 구성
- Praefect 설정 구성
- MinIO 설정 구성
- appConfig 설정 구성
- Rails 설정 구성
- Workhorse 설정 구성
- GitLab Shell 구성
- GitLab Pages 구성
- 웹서비스 구성
- 사용자 지정 인증 기관
- 애플리케이션 리소스
- GitLab 기본 이미지
- 서비스 계정
- 주석
- 노드 선택기
- 라벨
- 추적
- extraEnv
- extraEnvFrom
- OAuth 설정 구성
- Kerberos
- 발신 이메일
- 플랫폼
- 친화도
- 파드 우선 순위 및 선제적 제거
- 로그 순환
- 작업
- Traefik
글로벌을 사용한 차트 구성
우리의 래퍼 Helm 차트를 설치할 때 구성 중복을 줄이기 위해 여러 가지
구성 설정을 values.yaml
의 global
섹션에 설정할 수 있습니다.
이 글로벌 설정은 여러 차트에서 사용되며, 다른 모든 설정은 해당 차트 내에서 범위가 지정됩니다.
글로벌 변수가 작동하는 방식에 대한 자세한 내용은 Helm 문서에서 globals를 참조하세요.
- 호스트 설정 구성
- Ingress 설정 구성
- GitLab 버전
- PostgreSQL 설정 구성
- Redis 설정 구성
- 레지스트리 설정 구성
- Gitaly 설정 구성
- Praefect 설정 구성
- MinIO 설정 구성
- appConfig 설정 구성
- Rails 설정 구성
- Workhorse 설정 구성
- GitLab Shell 설정 구성
- Pages 설정 구성
- Webservice 설정 구성
- 사용자 정의 인증 기관
- 애플리케이션 리소스
- GitLab 기본 이미지
- 서비스 계정
- 주석
- 추적
- extraEnv 설정 구성
- extraEnvFrom 설정 구성
- OAuth 설정 구성
- Kerberos 설정 구성
- 발신 이메일
- 플랫폼 설정
- Affinity 설정 구성
- Pod 우선 순위 및 선점
- 로그 회전
- 작업
- Traefik 설정 구성
호스트 설정 구성
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
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
domain |
문자열 | example.com |
기본 도메인입니다. GitLab과 Registry는 이 설정의 하위 도메인에서 노출됩니다. 기본값은 example.com 이지만 name 속성이 구성된 호스트에는 사용되지 않습니다. 아래의 gitlab.name , minio.name , 및 registry.name 섹션을 참조하세요. |
externalIP |
nil |
프로바이더로부터_claim_할 외부 IP 주소를 설정합니다. 이 값은 더 복잡한 nginx.service.loadBalancerIP 대신 NGINX 차트에서 템플릿화됩니다. |
|
externalGeoIP |
nil |
NGINX Geo 차트에 대한 externalIP 와 동일합니다. 통합 URL을 사용하여 GitLab Geo 사이트의 정적 IP를 구성하기 위해 필요합니다. externalIP 와 다르지 않아야 합니다. |
|
https |
부울 | true |
true로 설정되면 NGINX 차트가 인증서에 접근할 수 있어야 합니다. Ingress 앞에서 TLS 종료가 있는 경우, 아마도 global.ingress.tls.enabled 를 확인해야 할 것입니다. 외부 URL에서 http:// 를 사용하려면 false로 설정합니다. |
hostSuffix |
문자열 | 아래 참조. | |
gitlab.https |
부울 | false |
hosts.https 또는 gitlab.https 가 true 인 경우, GitLab 외부 URL은 http:// 대신 https:// 를 사용합니다. |
gitlab.name |
문자열 | GitLab의 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
|
gitlab.hostnameOverride |
문자열 | Webservice의 Ingress 구성에 사용되는 호스트 이름을 재정의합니다. GitLab이 내부 호스트 이름 (예: gitlab.example.com –> gitlab.cluster.local )으로 호스트 이름을 재작성하는 WAF 뒤에서 접근할 수 있어야 할 때 유용합니다. |
|
gitlab.serviceName |
문자열 | webservice |
GitLab 서버를 운영하는 service 의 이름입니다. 차트는 서비스의 호스트 이름(및 현재 .Release.Name )을 템플릿화하여 적절한 내부 serviceName을 생성합니다. |
gitlab.servicePort |
문자열 | workhorse |
GitLab 서버에 접근할 수 있는 service 의 명명된 포트입니다. |
keda.enabled |
부울 | false |
KEDA ScaledObjects 를 사용하여 HorizontalPodAutoscalers 를 대신합니다. |
minio.https |
부울 | false |
hosts.https 또는 minio.https 가 true 인 경우, MinIO 외부 URL은 http:// 대신 https:// 를 사용합니다. |
minio.name |
문자열 | minio |
MinIO의 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
minio.serviceName |
문자열 | minio |
MinIO 서버를 운영하는 service 의 이름입니다. 차트는 서비스의 호스트 이름(및 현재 .Release.Name )을 템플릿화하여 적절한 내부 serviceName을 생성합니다. |
minio.servicePort |
문자열 | minio |
MinIO 서버에 접근할 수 있는 service 의 명명된 포트입니다. |
registry.https |
부울 | false |
hosts.https 또는 registry.https 가 true 인 경우, Registry 외부 URL은 http:// 대신 https:// 를 사용합니다. |
registry.name |
문자열 | registry |
레지스트리의 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
registry.serviceName |
문자열 | registry |
Registry 서버를 운영하는 service 의 이름입니다. 차트는 서비스의 호스트 이름(및 현재 .Release.Name )을 템플릿화하여 적절한 내부 serviceName을 생성합니다. |
registry.servicePort |
문자열 | registry |
Registry 서버에 접근할 수 있는 service 의 명명된 포트입니다. |
smartcard.name |
문자열 | smartcard |
스마트 카드 인증을 위한 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
kas.name |
문자열 | kas |
KAS의 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
kas.https |
부울 | false |
hosts.https 또는 kas.https 가 true 인 경우, KAS 외부 URL은 wss:// 대신 ws:// 를 사용합니다. |
pages.name |
문자열 | pages |
GitLab Pages의 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
pages.https |
문자열 |
global.pages.https 또는 global.hosts.pages.https 또는 global.hosts.https 가 true 인 경우, 프로젝트 설정 UI의 GitLab Pages에 대한 URL은 http:// 대신 https:// 를 사용합니다. |
|
ssh |
문자열 | SSH를 통해 리포지토리를 복제하기 위한 호스트 이름입니다. 설정된 경우, 이 호스트 이름이 사용되며 global.hosts.domain 및 global.hosts.hostSuffix 설정과 관계없이 사용됩니다. |
hostSuffix
hostSuffix
는 기본 domain
을 사용하여 호스트 이름을 조립할 때 서브 도메인에 추가되지만, 고유한 name
이 설정된 호스트에는 사용되지 않습니다.
기본값은 설정되지 않은 상태입니다. 설정할 경우, 접미사가 하이픈과 함께 서브 도메인에 추가됩니다.
아래의 예시는 gitlab-staging.example.com
및 registry-staging.example.com
과 같은 외부 호스트 이름을 사용하는 결과를 초래합니다:
global:
hosts:
domain: example.com
hostSuffix: staging
수평 Pod 자동 확장기 설정 구성
HPA에 대한 GitLab 글로벌 호스트 설정은 global.hpa
키 아래에 위치합니다:
이름 | 유형 | 기본 값 | 설명 |
---|---|---|---|
apiVersion |
문자열 | HorizontalPodAutoscaler 객체 정의에서 사용할 API 버전. |
PodDisruptionBudget 설정 구성
PDB에 대한 GitLab 글로벌 호스트 설정은 global.pdb
키 아래에 위치합니다:
이름 | 유형 | 기본 값 | 설명 |
---|---|---|---|
apiVersion |
문자열 | PodDisruptionBudget 객체 정의에서 사용할 API 버전. |
CronJob 설정 구성
CronJobs에 대한 GitLab 글로벌 호스트 설정은 global.batch.cronJob
키 아래에 위치합니다:
이름 | 유형 | 기본 값 | 설명 |
---|---|---|---|
apiVersion |
문자열 | CronJob 객체 정의에서 사용할 API 버전. |
모니터링 설정 구성
ServiceMonitors 및 PodMonitors에 대한 GitLab 글로벌 설정은 global.monitoring
키 아래에 위치합니다:
이름 | 유형 | 기본 값 | 설명 |
---|---|---|---|
enabled |
부울 | false |
monitoring.coreos.com/v1 API의 가용성과 관계없이 모니터링 리소스를 활성화. |
Ingress 설정 구성
Ingress에 대한 GitLab 글로벌 호스트 설정은 global.ingress
키 아래에 위치합니다:
이름 | 유형 | 기본 값 | 설명 |
---|---|---|---|
apiVersion |
문자열 | Ingress 객체 정의에서 사용할 API 버전. | |
annotations.*annotation-key* |
문자열 | 여기서 annotation-key 는 모든 Ingress에서 주석으로 사용될 값이 있는 문자열입니다. 예: global.ingress.annotations."nginx\.ingress\.kubernetes\.io/enable-access-log"=true . 기본적으로 전역 주석은 제공되지 않습니다. |
|
configureCertmanager |
부울 | true |
아래 보기. |
useNewIngressForCerts |
부울 | false |
아래 보기. |
class |
문자열 | gitlab-nginx |
kubernetes.io/ingress.class 주석 또는 Ingress 리소스의 spec.IngressClassName 을 제어하는 전역 설정. 비활성화하려면 none 으로 설정하거나 빈 문자열("" )로 설정합니다. 참고: none 또는 "" 의 경우, 불필요한 Ingress 리소스의 배포를 방지하기 위해 nginx-ingress.enabled=false 를 설정하세요. |
enabled |
부울 | true |
서비스에 대한 Ingress 객체를 생성할지 여부를 제어하는 전역 설정. |
tls.enabled |
부울 | true |
false 로 설정하면 GitLab에서 TLS를 비활성화합니다. 이는 Ingress Controller 이전에 TLS 종료 프록시를 사용할 수 없는 경우에 유용합니다. HTTPS를 완전히 비활성화하려면 global.hosts.https 와 함께 false 로 설정해야 합니다. |
tls.secretName |
문자열 |
global.hosts.domain 에 사용되는 와일드카드 인증서와 키가 포함된 Kubernetes TLS Secret의 이름. |
|
path |
문자열 | / |
Ingress 객체에서 path 항목의 기본값 |
pathType |
문자열 | Prefix |
경로가 어떻게 일치해야 하는지를 지정할 수 있는 Path Type입니다. 현재 기본값은 Prefix 이지만 사용 사례에 따라 ImplementationSpecific 또는 Exact 를 사용할 수 있습니다. |
provider |
문자열 | nginx |
사용해야 할 Ingress 공급자를 정의하는 전역 설정. nginx 가 기본 공급자로 사용됩니다. |
다양한 클라우드 공급자를 위한 샘플 구성은 예제 폴더에서 찾을 수 있습니다.
인그레스 경로
이 차트는 global.ingress.path
를 사용하여 Ingress 객체에 대한 path
항목의 정의를 변경해야 하는 사용자를 지원합니다.
많은 사용자는 이 설정이 필요 없으며, 구성하지 않아야 합니다.
path
정의가 GCP에서 ingress.class: gce
, AWS에서 ingress.class: alb
와 같은 로드 밸런서 / 프록시 동작과 일치하기 위해 /*
로 끝나야 하는 사용자에게 이 설정이 필요합니다.
이 설정은 이 차트 전반에 걸쳐 Ingress 리소스의 모든 path
항목이 이 설정으로 렌더링되도록 보장합니다.
유일한 예외는 gitlab/webservice
배포 설정을 채울 때로, 이 경우 path
를 명시해야 합니다.
클라우드 공급자 로드 밸런서
다양한 클라우드 공급자의 로드 밸런서 구현은 이 차트의 일환으로 배포되는 Ingress 리소스 및 NGINX 컨트롤러 구성에 영향을 미칩니다. 다음 표는 예시를 제공합니다.
공급자 | 레이어 | 예시 스니펫 |
---|---|---|
AWS | 4 | aws/elb-layer4-loadbalancer |
AWS | 7 | aws/elb-layer7-loadbalancer |
AWS | 7 | aws/alb-full |
global.ingress.configureCertmanager
Ingress 객체에 대한 cert-manager의 자동 구성을 제어하는 전역 설정입니다.
true
인 경우, certmanager-issuer.email
이 설정된 것에 의존합니다.
false
이고 global.ingress.tls.secretName
이 설정되지 않은 경우, 자동
자체 서명 인증서 생성을 활성화하며, 이는 모든 Ingress 객체에 대한 와일드카드 인증서를 생성합니다.
외부 cert-manager
를 사용하려는 경우, 다음을 제공해야 합니다:
gitlab.webservice.ingress.tls.secretName
registry.ingress.tls.secretName
minio.ingress.tls.secretName
global.ingress.annotations
global.ingress.useNewIngressForCerts
ACME 챌린지 검증을 수행하기 위해 매번 동적으로 생성된 새로운 Ingress를 사용하는 cert-manager
의 동작을 변경하는 전역 설정입니다.
기본 논리(global.ingress.useNewIngressForCerts
가 false
일 때)는
검증을 위해 기존 Ingress를 재사용합니다. 이 기본값은 일부 상황에서는 적절하지 않습니다.
플래그를 true
로 설정하면 각 검증을 위해 새로운 Ingress 객체가 생성됩니다.
GKE Ingress 컨트롤러와 함께 사용될 때 global.ingress.useNewIngressForCerts
를 true
로 설정할 수 없습니다. 이를 활성화하는 방법은 릴리스 노트를 참조하십시오.
GitLab 버전
참고: 이 값은 개발 목적으로만 사용해야 하며, GitLab 지원팀의 명시적인 요청에 의해 사용되어야 합니다. 이 값을 프로덕션 환경에서 사용하지 않도록 하며, Helm을 사용한 배포에서 설명한 대로 버전을 설정하세요.
차트의 기본 이미지 태그에서 사용되는 GitLab 버전은 global.gitlabVersion
키를 사용하여 변경할 수 있습니다:
--set global.gitlabVersion=11.0.1
이는 webservice
, sidekiq
, 및 migration
차트에서 사용되는 기본 이미지 태그에 영향을 미칩니다.
gitaly
, gitlab-shell
, 및 gitlab-runner
이미지 태그는 GitLab 버전과 호환되는 버전으로 별도로 업데이트해야 한다는 점에 유의하십시오.
모든 이미지 태그에 접미사 추가
Helm 차트에서 사용되는 모든 이미지의 이름에 접미사를 추가하려면 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
# ...
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host |
String | 사용할 데이터베이스가 있는 PostgreSQL 서버의 호스트 이름입니다. 이 차트에 의해 배포된 PostgreSQL을 사용하는 경우 생략할 수 있습니다. | |
serviceName |
String | PostgreSQL 데이터베이스를 운영하는 service 의 이름입니다. 이것이 존재하고 host 가 없으면 차트는 host 값 대신 서비스의 호스트 이름을 템플릿화합니다. |
|
database |
String | gitlabhq_production |
PostgreSQL 서버에서 사용할 데이터베이스의 이름입니다. |
password.useSecret |
Boolean | true |
PostgreSQL의 비밀번호를 비밀 또는 파일에서 읽도록 설정합니다. |
password.file |
String | PostgreSQL 비밀번호가 포함된 파일의 경로를 정의합니다. password.useSecret 가 true인 경우 무시됩니다. |
|
password.key |
String | PostgreSQL의 password.key 속성은 비밀번호를 포함하는 비밀에서의 키 이름을 정의합니다. password.useSecret 가 false인 경우 무시됩니다. |
|
password.secret |
String | PostgreSQL의 password.secret 속성은 가져올 Kubernetes Secret 의 이름을 정의합니다. password.useSecret 가 false인 경우 무시됩니다. |
|
port |
Integer | 5432 |
PostgreSQL 서버에 연결하는 포트입니다. |
username |
String | gitlab |
데이터베이스에 인증하는 데 사용할 사용자 이름입니다. |
preparedStatements |
Boolean | false |
PostgreSQL 서버와 통신할 때 준비된 문을 사용할지 여부입니다. |
databaseTasks |
Boolean | true |
GitLab이 주어진 데이터베이스에 대해 데이터베이스 작업을 수행해야 하는지 여부입니다. main 과 호스트/포트/데이터베이스를 공유할 때 자동으로 비활성화됩니다. |
connectTimeout |
Integer | 데이터베이스 연결을 기다리는 초 수입니다. | |
keepalives |
Integer | 클라이언트 측 TCP keepalives를 사용할지 여부를 제어합니다 (1 - 사용, 0 - 사용 안 함). | |
keepalivesIdle |
Integer | TCP가 서버로 keepalive 메시지를 보내기 전 비활동 상태의 초 수입니다. 값이 0이면 시스템 기본값을 사용합니다. | |
keepalivesInterval |
Integer | 서버에서 확인되지 않은 TCP keepalive 메시지 후 재전송해야 하는 초 수입니다. 값이 0이면 시스템 기본값을 사용합니다. | |
keepalivesCount |
Integer | 클라이언트와 서버 간의 연결이 끊어진 것으로 간주되기 전에 손실될 수 있는 TCP keepalive의 수입니다. 값이 0이면 시스템 기본값을 사용합니다. | |
tcpUserTimeout |
Integer | 전송된 데이터가 인식되지 않을 수 있는 밀리초 수로, 연결이 강제로 닫히기 전입니다. 값이 0이면 시스템 기본값을 사용합니다. | |
applicationName |
String | 데이터베이스에 연결하는 애플리케이션의 이름입니다. 비활성화하려면 빈 문자열("" )로 설정합니다. 기본적으로 현재 프로세스의 이름(예: sidekiq , puma )으로 설정됩니다. |
|
ci.enabled |
Boolean | true |
두 데이터베이스 연결을 활성화합니다. |
PostgreSQL 차트
복잡한 배포에서는 이 차트의 서로 다른 부분을 PostgreSQL에 대한 서로 다른 구성으로 설정할 수도 있습니다. v4.2.0
부터는 global.psql
내에서 사용 가능한 모든 속성을 차트별로 설정할 수 있으며, 예를 들어 gitlab.sidekiq.psql
와 같은 방식입니다. 로컬 설정은 제공된 경우 글로벌 값을 재정의하며, global.psql
에서 존재하지 않는 값은 상속받습니다. 단, psql.load_balancing
은 예외입니다.
PostgreSQL 로드 밸런싱은 설계상 글로벌에서 결코 상속되지 않습니다.
PostgreSQL SSL
알림:
SSL 지원은 상호 TLS만 가능합니다.
이슈 #2034 및
이슈 #1817를 참조하세요.
GitLab을 상호 TLS를 통해 PostgreSQL 데이터베이스와 연결하려면 클라이언트 키, 클라이언트 인증서 및 서버 인증서 권한을 서로 다른 비밀 키로 포함하는 비밀을 생성하십시오. 그런 다음 global.psql.ssl
매핑을 사용하여 비밀 구조를 설명합니다.
global:
psql:
ssl:
secret: db-example-ssl-secrets # 비밀 이름
clientCertificate: cert.pem # 인증서를 저장하는 비밀 키
clientKey: key.pem # 인증서 키의 비밀 키
serverCA: server-ca.pem # 데이터베이스 서버의 CA를 포함하는 비밀 키
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
secret |
문자열 | 다음 키를 포함하는 Kubernetes Secret 의 이름 |
|
clientCertificate |
문자열 | 클라이언트 인증서를 포함하는 Secret 내의 키 이름. |
|
clientKey |
문자열 | 클라이언트 인증서의 키 파일을 포함하는 Secret 내의 키 이름. |
|
serverCA |
문자열 | 서버 인증서를 위한 인증 기관을 포함하는 Secret 내의 키 이름. |
올바른 키를 가리키도록 환경 값을 내보내기 위해 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의 사용을 요구하며, 이 차트는 HA 방식으로 PostgreSQL을 배포하지 않습니다.
GitLab의 Rails 구성 요소는
PostgreSQL 클러스터를 사용하여 읽기 전용 쿼리를 로드 밸런싱할 수 있습니다.
이 기능은 두 가지 방식으로 구성될 수 있습니다:
- 세컨더리를 위한 _호스트명_의 정적 목록 사용
- DNS 기반 서비스 검색 메커니즘 사용
정적 호스트 목록을 사용하는 구성은 간단합니다:
global:
psql:
host: primary.database
load_balancing:
hosts:
- secondary-1.database
- secondary-2.database
서비스 검색 구성은 더 복잡할 수 있습니다. 이 구성에 대한 전체 세부정보와 매개변수 및 관련 동작은
서비스 검색
에서 확인할 수 있으며, GitLab 관리 문서에서 확인할 수 있습니다.
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 관리 문서에서는 이러한 항목을 자세히 다루고 있으며 해당 속성을 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:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
connectTimeout |
Integer | Redis 연결을 기다리는 초 수입니다. 값이 지정되지 않으면 클라이언트는 기본적으로 1초를 사용합니다. | |
readTimeout |
Integer | Redis 읽기를 기다리는 초 수입니다. 값이 지정되지 않으면 클라이언트는 기본적으로 1초를 사용합니다. | |
writeTimeout |
Integer | Redis 쓰기를 기다리는 초 수입니다. 값이 지정되지 않으면 클라이언트는 기본적으로 1초를 사용합니다. | |
host |
String | 사용하려는 데이터베이스가 있는 Redis 서버의 호스트 이름입니다. serviceName 대신 생략할 수 있습니다. |
|
serviceName |
String | redis |
Redis 데이터베이스를 운영하는 service 의 이름입니다. 이 값이 존재하고 host 가 없으면, 차트는 host 값을 대체할 서비스의 호스트 이름(및 현재 .Release.Name )을 템플릿합니다. Redis를 GitLab 차트의 일부로 사용할 때 유용합니다. |
port |
Integer | 6379 |
Redis 서버에 연결할 포트입니다. |
user |
String | Redis에 대해 인증하는 데 사용되는 사용자(Redis 6.0+). | |
auth.enabled |
Boolean | true |
auth.enabled 는 Redis 인스턴스에서 비밀번호 사용을 위한 토글을 제공합니다. |
auth.key |
String | Redis의 auth.key 속성은 비밀번호가 포함된 비밀의 이름을 정의합니다. |
|
auth.secret |
String | Redis의 auth.secret 속성은 가져올 Kubernetes Secret 의 이름을 정의합니다. |
|
scheme |
String | redis |
Redis URL을 생성하는 데 사용되는 URI 스킴입니다. 유효한 값은 redis , rediss , tcp 입니다. rediss (SSL 암호화 연결) 스킴을 사용하는 경우, 서버가 사용하는 인증서는 시스템의 신뢰하는 체인에 포함되어야 합니다. 이는 사용자 정의 인증 기관 목록에 추가하여 수행할 수 있습니다. |
Redis 차트 별 설정 구성
Redis 차트를 직접 구성하는 설정은 redis
키 아래에 있습니다:
redis:
install: true
image:
registry: registry.example.com
repository: example/redis
tag: x.y.z
자세한 정보는 설정의 전체 목록을 참조하세요.
Redis Sentinel 지원
현재 Redis Sentinel 지원은 GitLab 차트와 별도로 배포된 Sentinel만 지원합니다. 결과적으로 GitLab 차트를 통한 Redis 배포는 redis.install=false
로 비활성화해야 합니다.
Redis 비밀번호를 포함하는 Kubernetes Secret은 GitLab 차트를 배포하기 전에 수동으로 생성해야 합니다.
GitLab 차트에서 HA Redis 클러스터 설치는 센티널 사용을 지원하지 않습니다. 센티널 지원이 필요한 경우 Redis 클러스터는 GitLab 차트 설치와 별도로 생성해야 합니다. 이는 Kubernetes 클러스터 내외부에서 수행할 수 있습니다.
GitLab 배포 Redis 클러스터에서 센티널 지원을 추적하기 위한 이슈가 생성되었습니다.
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
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host |
문자열 |
host 속성은 sentinel.conf 에 지정된 클러스터 이름으로 설정해야 합니다. |
|
sentinels.[].host |
문자열 | Redis HA 설정을 위한 Redis Sentinel 서버의 호스트 이름입니다. | |
sentinels.[].port |
정수 | 26379 |
Redis Sentinel 서버에 연결하는 포트입니다. |
일반 Redis 설정 구성에서 이전의 모든 Redis 속성은 센티널 지원과 함께 계속 적용되며, 위의 표에서 다시 지정되지 않는 한 적용됩니다.
Redis Sentinel 비밀번호 지원
- GitLab 17.1에서 도입됨.
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
sentinelAuth:
enabled: false
secret: gitlab-redis-sentinel
key: sentinel-password
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
sentinelAuth.enabled |
부울 | false |
sentinelAuth.enabled 는 Redis Sentinel 인스턴스와 함께 비밀번호를 사용할 수 있는 토글을 제공합니다. |
sentinelAuth.key |
문자열 | Redis에 대한 sentinelAuth.key 속성은 비밀번호가 포함된 비밀의 키 이름을 정의합니다(아래). |
|
sentinelAuth.secret |
문자열 | Redis에 대한 sentinelAuth.secret 속성은 가져올 Kubernetes Secret 의 이름을 정의합니다. |
global.redis.sentinelAuth
는 모든 Sentinel 인스턴스에 대한 Sentinel 비밀번호를 구성하는 데 사용할 수 있습니다.
sentinelAuth
는 Redis 인스턴스별 설정 또는 global.redis.redisYmlOverride
로 재정의할 수 없습니다.
여러 Redis 지원
GitLab 차트는 현재 서로 다른 지속성 클래스에 대해 별도의 Redis 인스턴스를 실행하는 것을 지원합니다:
인스턴스 | 목적 |
---|---|
actioncable |
ActionCable의 Pub/Sub 큐 백엔드 |
cache |
캐시된 데이터 저장 |
kas |
kas 특정 데이터 저장 |
queues |
Sidekiq 백그라운드 작업 저장 |
rateLimiting |
RackAttack와 애플리케이션 제한을 위한 비율 제한 사용 저장 |
repositoryCache |
저장소 관련 데이터 저장 |
sessions |
사용자 세션 데이터 저장 |
sharedState |
분산 잠금과 같은 다양한 지속 데이터 저장 |
traceChunks |
작업 추적을 일시적으로 저장 |
workhorse |
Workhorse의 Pub/sub 큐 백엔드 |
인스턴스 수는 제한이 없습니다. 지정되지 않은 인스턴스는 global.redis.host
로 지정된 기본 Redis 인스턴스 또는 차트에서 배포된 Redis 인스턴스에 의해 처리됩니다.
유일한 예외는 GitLab 에이전트 서버 (KAS)로, 다음 순서로 Redis 구성을 찾습니다:
global.redis.kas
global.redis.sharedState
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 인스턴스의 속성을 설명합니다.
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
.host |
문자열 | 사용하는 데이터베이스가 있는 Redis 서버의 호스트 이름. | |
.port |
정수 | 6379 |
Redis 서버에 연결하는 포트. |
.password.enabled |
불린 | true |
password.enabled 는 Redis 인스턴스에서 비밀번호 사용 여부를 조정합니다. |
.password.key |
문자열 | Redis의 password.key 속성은 비밀번호가 포함된 비밀의 이름을 정의합니다. |
|
.password.secret |
문자열 | Redis의 password.secret 속성은 가져올 Kubernetes Secret 의 이름을 정의합니다. |
기본 Redis 정의는 추가적인 지속성 클래스가 분리되지 않았기 때문에 필요합니다.
각 인스턴스 정의는 Redis Sentinel 지원도 사용할 수 있습니다. Sentinel 구성은 공유되지 않으며 Sentinel을 사용하는 각 인스턴스에 대해 지정해야 합니다. Sentinel 서버를 구성하는 데 사용하는 속성에 대해서는 Sentinel 구성을 참조하세요.
보안 Redis 스킴 지정 (SSL)
SSL을 사용하여 Redis에 연결하려면:
-
구성에서
rediss
(두 개의s
) 스킴 매개변수를 사용하도록 업데이트합니다. -
구성에서
authClients
를false
로 설정합니다:global: redis: scheme: rediss redis: tls: enabled: true authClients: false
이 구성은 Redis가 상호 TLS를 기본값으로 사용하기 때문에 필요하며, 모든 차트 구성 요소가 지원하지 않을 수 있습니다.
-
Bitnami의 TLS 활성화 단계를 따릅니다. 차트 구성 요소가 Redis 인증서를 생성하는 데 사용된 인증 기관을 신뢰하는지 확인하세요.
-
선택 사항입니다. 사용자 정의 인증 기관을 사용하는 경우 사용자 정의 인증 기관 글로벌 구성을 참조하세요.
비밀번호 없는 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: {}
## 다른 서비스에서 사용하는 설정, 레지스트리를 참조:
enabled: true
host:
api:
protocol: http
serviceName: registry
port: 5000
tokenIssuer: gitlab-issuer
bucket
, certificate
, httpSecret
, 및 notificationSecret
설정에 대한 자세한 내용은 레지스트리 차트 내 문서를 참조하세요.
enabled
, host
, api
및 tokenIssuer
에 대한 자세한 내용은 명령 줄 옵션 및 웹 서비스 문서를 참조하세요.
host
는 자동으로 생성된 외부 레지스트리 호스트 이름 참조를 덮어쓰는 데 사용됩니다.
알림 설정
이 설정은 레지스트리 알림을 구성하는 데 사용됩니다. 이는 맵(업스트림 사양에 따름)을 사용하되, 민감한 헤더를 Kubernetes 비밀로 제공하는 추가 기능이 있습니다. 예를 들어, 아래의 예제에서 Authorization 헤더에는 민감한 데이터가 포함되어 있고 다른 헤더는 일반 데이터를 포함합니다:
global:
registry:
notifications:
events:
includereferences: true
endpoints:
- name: CustomListener
url: https://mycustomlistener.com
timeout: 500mx
# DEPRECATED: use `maxretries` instead https://gitlab.com/gitlab-org/container-registry/-/issues/1243.
# `maxretries`를 사용할 때는 `threshold`가 무시됩니다: https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints
threshold: 5
maxretries: 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는 GitLab에서 수행한 모든 Git 호출을 처리하는 Git 리포지토리에 대한 고급 RPC 접근을 제공하는 서비스입니다.
관리자는 다음과 같은 방법으로 Gitaly 노드를 선택하여 사용할 수 있습니다:
새 프로젝트에 사용할 노드를 관리하는 방법에 대한 자세한 내용은 레포지토리 저장소 경로 문서를 참조하세요.
gitaly.host
가 제공되면, gitaly.internal
및 gitaly.external
속성은 무시됩니다.
더 이상 지원하지 않는 Gitaly 설정을 참조하세요.
Gitaly 인증 토큰은 현재 모든 Gitaly 서비스에 대해 동일해야 합니다. 내부 또는 외부 모두 일치하도록 하세요. 더 자세한 내용은 이슈 #1992를 참조하세요.
내부
internal
키는 현재 하나의 키인 names
로 구성되어 있으며, 이는 차트에 의해 관리될
스토리지 이름의 목록입니다.
나열된 각 이름에 대해 논리적 순서로, 하나의 파드가 생성되며, 이름은 ${releaseName}-gitaly-${ordinal}
입니다.
여기서 ordinal
은 names
목록 내의 인덱스입니다. 동적 프로비저닝이 활성화된 경우,
PersistentVolumeClaim
이 일치합니다.
이 목록의 기본값은 ['default']
이며, 이는 하나의
스토리지 경로와 관련된 1개의 파드를 제공합니다.
이 항목의 수동 크기 조정은 gitaly.internal.names
에 항목을 추가하거나 제거하여 필요합니다.
크기를 축소할 경우, 다른 노드로 이동되지 않은 모든 리포지토리는 사용할 수 없게 됩니다.
Gitaly 차트는 StatefulSet
이므로, 동적으로 프로비저닝된 디스크는 회수되지 않습니다.
이는 데이터 디스크가 지속되고, 나중에 names
목록에 노드를 다시 추가하면 데이터에 접근할 수 있음을 의미합니다.
다수의 내부 노드에 대한 샘플 구성은 예제 폴더에서 찾을 수 있습니다.
외부
external
키는 클러스터 외부의 Gitaly 노드를 위한 구성을 제공합니다.
이 목록의 각 항목에는 3개의 키가 있습니다:
-
name
: 스토리지의 이름입니다.name: default
항목이 필요합니다. -
hostname
: Gitaly 서비스의 호스트입니다. -
port
: (선택 사항) 호스트에 도달할 포트 번호. 기본값은8075
입니다. -
tlsEnabled
: (선택 사항) 이 특정 항목에 대해global.gitaly.tls.enabled
를 재정의합니다.
외부 Gitaly 서비스를 사용하기 위한 고급 구성 가이드를 제공합니다. 샘플 다수의 외부 서비스 구성도 예제 폴더에서 찾을 수 있습니다.
높가용성 Gitaly 서비스를 제공하기 위해 외부 Praefect를 사용할 수 있습니다. 이 두 가지의 구성은 상호 교환 가능하며, 클라이언트 관점에서는 차이가 없습니다.
혼합
내부 및 외부 Gitaly 노드를 모두 사용할 수 있지만, 다음 사항에 유의하세요:
- 항상
default
라는 이름의 노드가 있어야 하며, 이는 기본적으로 Internal에서 제공합니다. - 외부 노드가 먼저 채워진 후, 내부 노드가 채워집니다.
혼합된 내부 및 외부 노드의 샘플 구성은 예제 폴더에서 확인할 수 있습니다.
authToken
Gitaly의 authToken
속성에는 두 개의 하위 키가 있습니다:
-
secret
은 가져올 KubernetesSecret
의 이름을 정의합니다. -
key
는 authToken을 포함하고 있는 위의 비밀에서 키의 이름을 정의합니다.
모든 Gitaly 노드는 같은 인증 토큰을 공유해야 합니다.
사용 중단된 Gitaly 설정
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host (사용 중단)
|
문자열 | 사용할 Gitaly 서버의 호스트 이름입니다. serviceName 대신 생략할 수 있습니다. 이 설정을 사용하면 internal 또는 external 의 어떤 값도 무시됩니다. |
|
port (사용 중단)
|
정수 | 8075 |
Gitaly 서버에 연결할 포트입니다. |
serviceName (사용 중단)
|
문자열 | Gitaly 서버를 운영하는 service 의 이름입니다. 이것이 존재하고 host 가 없으면, 차트는 host 값 대신 서비스의 호스트 이름(및 현재 .Release.Name )을 템플릿합니다. Gitaly를 전체 GitLab 차트의 일부로 사용할 때 편리합니다. |
TLS 설정
Gitaly를 TLS를 통해 제공하도록 구성하는 방법은 Gitaly 차트 문서에 자세히 설명되어 있습니다.
Praefect 설정 구성
전역 Praefect 설정은 global.praefect
키 아래에 있습니다.
Praefect는 기본적으로 비활성화되어 있습니다. 추가 설정 없이 활성화하면 3개의 Gitaly 복제본이 생성되며, 기본 PostgreSQL 인스턴스에서 Praefect 데이터베이스를 수동으로 생성해야 합니다.
Praefect 활성화
기본 설정으로 Praefect를 활성화하려면 global.praefect.enabled=true
로 설정하세요.
Gitaly 클러스터를 Praefect를 사용하여 운영하는 방법에 대한 세부정보는 Praefect 문서를 참조하세요.
Praefect의 전역 설정
global:
praefect:
enabled: false
virtualStorages:
- name: default
gitalyReplicas: 3
maxUnavailable: 1
dbSecret: {}
psql: {}
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled | 불리언 | false | Praefect 활성화 여부 |
virtualStorages | 목록 | 위의 다중 가상 저장소 참조. | 원하는 가상 저장소 목록 (각각 Gitaly StatefulSet에 의해 지원됨) |
dbSecret.secret | 문자열 | 데이터베이스와 인증할 때 사용할 비밀의 이름 | |
dbSecret.key | 문자열 | 사용할 dbSecret.secret 의 키 이름 |
|
psql.host | 문자열 | 외부 데이터베이스를 사용할 때 사용할 데이터베이스 서버의 호스트 이름 | |
psql.port | 문자열 | 외부 데이터베이스를 사용할 때 데이터베이스 서버의 포트 번호 | |
psql.user | 문자열 | praefect |
사용할 데이터베이스 사용자 |
psql.dbName | 문자열 | praefect |
사용할 데이터베이스의 이름 |
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:
defaultColorMode:
defaultSyntaxHighlightingTheme:
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
설정은 아래에 설명되어 있습니다:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
cdnHost |
문자열 | (비어 있음) | 정적 자산을 제공하기 위한 CDN의 기본 URL을 설정합니다 (예: https://mycdnsubdomain.fictional-cdn.com ). |
contentSecurityPolicy |
구조체 | 아래 참조. | |
enableUsagePing |
불리언 | true |
사용 통계 지원을 비활성화하는 플래그입니다. |
enableSeatLink |
불리언 | true |
좌석 링크 지원을 비활성화하는 플래그입니다. |
enableImpersonation |
nil |
관리자에 의한 사용자 impersonation을 비활성화하는 플래그입니다. | |
applicationSettingsCacheSeconds |
정수 | 60 | 애플리케이션 설정 캐시를 무효화하는 간격 값(초 단위)입니다. |
usernameChangingEnabled |
불리언 | true |
사용자가 자신의 사용자 이름을 변경할 수 있는지 결정하는 플래그입니다. |
issueClosingPattern |
문자열 | (비어 있음) | 이슈를 자동으로 닫기 위한 패턴. |
defaultTheme |
정수 | GitLab 인스턴스의 기본 테마의 숫자 ID. 테마의 ID를 나타내는 숫자를 사용합니다. | |
defaultColorMode |
정수 | GitLab 인스턴스의 기본 색상 모드. 색상 모드의 ID를 나타내는 숫자를 사용합니다. | |
defaultSyntaxHighlightingTheme |
정수 | GitLab 인스턴스의 기본 구문 하이라이팅 테마. 구문 하이라이팅 테마의 ID를 나타내는 숫자를 사용합니다. | |
defaultProjectsFeatures.*feature* |
불리언 | true |
아래 참조. |
webhookTimeout |
정수 | (비어 있음) | 훅이 실패한 것으로 간주되기 전 대기 시간 (초 단위)입니다. |
graphQlTimeout |
정수 | (비어 있음) | Rails가 GraphQL 요청을 완료해야 하는 시간 (초 단위)입니다. |
콘텐츠 보안 정책
콘텐츠 보안 정책(CSP)을 설정하면 자바스크립트 교차 사이트 스크립팅(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
로 변경하여 구성을 테스트할 수도 있습니다.
기본 프로젝트 기능
새 프로젝트가 기본적으로 특정 기능과 함께 생성되어야 하는지 여부를 결정하는 플래그입니다. 모든 플래그의 기본값은 true
입니다.
defaultProjectsFeatures:
issues: true
mergeRequests: true
wiki: true
snippets: true
builds: true
containerRegistry: true
Gravatar/Libravatar 설정
기본적으로 차트는 gravatar.com에서 사용할 수 있는 Gravatar 아바타 서비스와 함께 작동합니다.
그러나 필요에 따라 사용자 정의 Libravatar 서비스도 사용할 수 있습니다:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
gravatar.plainURL |
문자열 | (빈 값) | Gravatar.com 대신 Libravatar 인스턴스에 대한 HTTP URL. |
gravatar.sslUrl |
문자열 | (빈 값) | Gravatar.com 대신 Libravatar 인스턴스에 대한 HTTPS URL. |
GitLab 인스턴스에 분석 서비스 연결
Google Analytics 및 Matomo와 같은 분석 서비스를 구성하기 위한 설정은 appConfig
아래의 extra
키에서 정의됩니다:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
extra.googleAnalyticsId |
문자열 | (빈 값) | Google Analytics의 추적 ID. |
extra.matomoSiteId |
문자열 | (빈 값) | Matomo 사이트 ID. |
extra.matomoUrl |
문자열 | (빈 값) | Matomo URL. |
extra.matomoDisableCookies |
불리언 | (빈 값) | Matomo 쿠키 비활성화(매트모 스크립트의 disableCookies 에 해당) |
extra.oneTrustId |
문자열 | (빈 값) | OneTrust ID. |
extra.googleTagManagerNonceId |
문자열 | (빈 값) | Google Tag Manager ID. |
extra.bizible |
불리언 | false |
Bizible 스크립트를 활성화하려면 true로 설정하세요. |
통합 객체 저장소
개별 설정을 구성하는 방법을 설명하는 다음 섹션에 추가하여, 이러한 항목에 대한 공유 구성을 사용하기 쉽게 하기 위해 통합 객체 저장소 구성을 추가했습니다. object_store
를 사용하면 connection
을 한 번 구성할 수 있으며, 이는 개별적으로 connection
속성으로 구성되지 않은 모든 객체 저장소 기반 기능에 사용됩니다.
enabled: true
proxy_download: true
storage_options:
connection:
secret:
key:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
enabled |
Boolean | false |
통합 객체 저장소 사용을 활성화합니다. |
proxy_download |
Boolean | true |
bucket 에서 직접 다운로드하는 대신 GitLab을 통한 모든 다운로드의 프록시를 활성화합니다. |
storage_options |
String | {} |
아래를 참조하세요. |
connection |
String | {} |
아래를 참조하세요. |
속성 구조는 공유되며, 여기 있는 모든 속성은 아래 개별 항목에 의해 재정의될 수 있습니다. connection
속성 구조는 동일합니다.
알림: bucket
, enabled
, proxy_download
속성은 기본값에서 벗어나려는 경우에 항목 수준(global.appConfig.artifacts.bucket
, …)에서 구성해야 하는 유일한 속성입니다.
connection
을 위한 AWS 공급자를 사용할 때(포함된 MinIO와 같이 S3 호환 공급자), GitLab Workhorse는 모든 저장소 관련 업로드를 오프로드할 수 있습니다. 이 통합 구성을 사용할 때 자동으로 활성화됩니다.
버킷 지정
각 객체 유형은 서로 다른 버킷에 저장되어야 합니다. 기본적으로 GitLab은 각 유형에 대해 다음 버킷 이름을 사용합니다:
객체 유형 | 버킷 이름 |
---|---|
CI 아티팩트 | gitlab-artifacts |
Git LFS | git-lfs |
패키지 | gitlab-packages |
업로드 | gitlab-uploads |
외부 병합 요청 diffs | gitlab-mr-diffs |
Terraform 상태 | gitlab-terraform-state |
CI 보안 파일 | gitlab-ci-secure-files |
의존성 프록시 | gitlab-dependency-proxy |
페이지 | gitlab-pages |
이 기본값을 사용하거나 버킷 이름을 구성할 수 있습니다:
--set global.appConfig.artifacts.bucket=<BUCKET NAME> \
--set global.appConfig.lfs.bucket=<BUCKET NAME> \
--set global.appConfig.packages.bucket=<BUCKET NAME> \
--set global.appConfig.uploads.bucket=<BUCKET NAME> \
--set global.appConfig.externalDiffs.bucket=<BUCKET NAME> \
--set global.appConfig.terraformState.bucket=<BUCKET NAME> \
--set global.appConfig.ciSecureFiles.bucket=<BUCKET NAME> \
--set global.appConfig.dependencyProxy.bucket=<BUCKET NAME>
storage_options
storage_options
는
S3 서버 측 암호화를 구성하는 데 사용됩니다.
S3 버킷에 대한 기본 암호화를 설정하는 것이 암호화를 활성화하는 가장 쉬운 방법이지만,
암호화된 객체만 업로드되도록 버킷 정책을 설정하고 싶을 수 있습니다.
이를 위해서는 GitLab이 storage_options
구성 섹션에서 적절한 암호화 헤더를 보내도록 구성해야 합니다:
설정 | 설명 |
---|---|
server_side_encryption |
암호화 모드 (AES256 또는 aws:kms ) |
server_side_encryption_kms_key_id |
Amazon 리소스 이름. server_side_encryption 에서 aws:kms 를 사용할 때만 필요합니다. KMS 암호화 사용에 대한 Amazon 문서를 참조하세요. |
예제:
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 차이 및 종속성 프록시
이 설정에 대한 세부정보는 아래에 있습니다. 문서는 개별적으로 반복되지 않으며, bucket
속성의 기본값을 제외하고는 구조적으로 동일합니다.
enabled: true
proxy_download: true
bucket:
connection:
secret:
key:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled |
Boolean | LFS, 아티팩트, 업로드 및 패키지의 경우 기본적으로 true
|
객체 저장소와 함께 이러한 기능을 사용하도록 활성화합니다. |
proxy_download |
Boolean | true |
bucket 에서 직접 다운로드하는 대신 GitLab을 통해 모든 다운로드의 프록시를 활성화합니다. |
bucket |
String | 다양함 | 객체 저장소 공급자로부터 사용할 버킷의 이름. 서비스를 기준으로 기본값은 git-lfs , gitlab-artifacts , gitlab-uploads , 또는 gitlab-packages 입니다. |
connection |
String | {} |
아래 참조. |
connection
connection
속성은 Kubernetes Secret으로 전환되었습니다. 이 비밀의 내용은 YAML 형식의 파일이어야 합니다. 기본값은 {}
이며, global.minio.enabled
가 true
인 경우 무시됩니다.
이 속성에는 두 개의 하위 키가 있습니다: secret
와 key
.
-
secret
는 Kubernetes Secret의 이름입니다. 이 값은 외부 객체 저장소를 사용하기 위해 필요합니다. -
key
는 YAML 블록을 포함하는 비밀의 키 이름입니다. 기본값은connection
입니다.
유효한 구성 키는 GitLab Job Artifacts Administration 문서에서 확인할 수 있습니다. 이는 Fog와 일치하며 공급자 모듈 간에 다릅니다.
AWS 및 Google 공급자에 대한 예제는 examples/objectstorage
에서 확인할 수 있습니다.
connection
의 내용을 포함하는 YAML 파일이 생성되면 이 파일을 사용하여 Kubernetes에서 비밀을 생성합니다.
kubectl create secret generic gitlab-rails-storage \
--from-file=connection=rails.yaml
when (외부 MR 차이에만 해당)
externalDiffs
설정에는 객체 저장소에 특정 차이를 조건부로 저장하기 위한 추가 키 when
가 있습니다. 이 설정은 차트의 기본값이 Rails 코드에 의해 할당되도록 기본적으로 비워 둡니다.
cdn (오직 CI 아티팩트 전용)
artifacts
설정에는 Google Cloud Storage 버킷 앞에 Google CDN을 구성하기 위한 추가 키 cdn
이 있습니다. 여기를 참조하세요.
수신 이메일 설정
수신 이메일 설정은 명령어 줄 옵션 페이지에서 설명되어 있습니다.
KAS 설정
사용자 정의 비밀번호
사용자는 Helm의 --set variable
옵션을 사용하여 KAS secret
이름과 key
를 사용자 정의할 수 있습니다:
--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 백엔드는 외부 KAS 서버(즉, 차트에 의해 관리되지 않는)에 대해 인식할 수 있으며, 이를 명시적으로 활성화하고 필요한 URL을 구성해야 합니다. Helm의 --set variable
옵션을 사용하여 설정할 수 있습니다:
--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
팟과 기타 GitLab 차트 구성 요소 간의 TLS 통신을 지원합니다.
사전 요구 사항:
-
GitLab 15.5.1 이상을 사용하세요.
global.gitlabVersion: <version>
으로 GitLab 버전을 설정할 수 있습니다. 초기 배포 후 이미지 업데이트를 강제하려면global.image.pullPolicy: Always
도 설정하십시오. -
인증 기관 생성하기 및
kas
팟이 신뢰할 인증서를 만들어야 합니다.
생성한 인증서를 사용하도록 kas
를 구성하려면 다음 값을 설정하십시오.
값 | 설명 |
---|---|
global.kas.tls.enabled |
인증서 볼륨을 장착하고 kas 끝점에 대한 TLS 통신을 활성화합니다. |
global.kas.tls.secretName |
Kubernetes TLS 비밀이 인증서를 저장하는 위치를 지정합니다. |
global.kas.tls.caSecretName |
Kubernetes TLS 비밀이 여러분의 커스텀 CA를 저장하는 위치를 지정합니다. |
예를 들어, 다음을 사용하여 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
제안된 리뷰어 설정
참고:
제안된 리뷰어 비밀은 자동으로 생성되며 GitLab SaaS에서만 사용됩니다.
이 비밀은 셀프 관리 GitLab 인스턴스에서는 필요하지 않습니다.
제안된 리뷰어의 secret
이름과 key
를 Helm의 --set variable
옵션을 사용하여 선택적으로 사용자 정의할 수 있습니다:
--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 사용자 인증을 구성할 수 있습니다. 이는 맵으로 표시되며, 소스에서 설치할 때와 마찬가지로 적절한 LDAP 서버 구성으로 변환됩니다.
비밀번호는 비밀번호를 포함하는 secret
을 제공하여 구성할 수 있습니다.
이 비밀번호는 런타임에 GitLab 구성에 주입됩니다.
예제 구성 스니펫:
ldap:
preventSignin: false
servers:
# 'main'은 이 LDAP 서버의 GitLab 'provider 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'
참고:
쉼표는 Helm --set
항목 내에서 특수 문자로 간주됩니다. bind_dn
와 같은 값에서 쉼표를 이스케이프하는 것을 잊지 마세요:
--set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net'
.
LDAP 웹 로그인 비활성화
SAML과 같은 대체 수단이 선호될 때 웹 UI를 통해 LDAP 자격 증명의 사용을 방지하는 것이 유용할 수 있습니다. 이렇게 하면 LDAP를 그룹 동기화에 사용할 수 있으며, SAML ID 공급자가 사용자 정의 2FA와 같은 추가 검사를 처리할 수 있습니다.
LDAP 웹 로그인이 비활성화되면 사용자는 로그인 페이지에서 LDAP 탭을 볼 수 없습니다. 이는 Git 액세스를 위한 LDAP 자격 증명 사용을 비활성화하지 않습니다.
웹 로그인에 대한 LDAP 사용을 비활성화하려면 global.appConfig.ldap.preventSignin: true
로 설정하십시오.
사용자 정의 CA 또는 자체 서명된 LDAP 인증서 사용
LDAP 서버가 사용자 정의 CA 또는 자체 서명된 인증서를 사용하는 경우 다음을 수행해야 합니다:
-
사용자 정의 CA/자체 서명된 인증서를 클러스터/네임스페이스에서 비밀 또는 ConfigMap으로 생성합니다:
# 비밀 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
-
그런 다음, 지정합니다:
# 비밀에서 사용자 정의 CA 구성 --set global.certificates.customCAs[0].secret=my-custom-ca-secret # 또는 ConfigMap에서 --set global.certificates.customCAs[0].configMap=my-custom-ca-configmap # 사용자 정의 CA를 신뢰하도록 LDAP 통합 구성 --set global.appConfig.ldap.servers.main.ca_file=/etc/ssl/certs/unique_name.pem
이렇게 하면 CA 인증서가 관련된 포드에 /etc/ssl/certs/unique_name.pem
에 탑재되고 LDAP 구성에서 사용이 지정됩니다.
참고:
GitLab 15.9 및 이후 버전에서는 /etc/ssl/certs/
의 인증서가 더 이상 ca-cert-
로 접두사되지 않습니다.
이것은 인증서 비밀을 준비한 컨테이너에 Alpine을 사용하면서 일어난 이전 동작이었습니다.
이제 gitlab-base
컨테이너가 이 작업에 사용되며, 이는 Debian 기반입니다.
더 많은 정보는 사용자 정의 인증 기관을 참조하세요.
DuoAuth
다음 설정을 사용하여 GitLab Duo와 함께 다단계 인증(2FA)를 활성화합니다.
global:
appConfig:
duoAuth:
enabled:
hostname:
integrationKey:
secretKey:
# secret:
# key:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled |
불리언 | false |
GitLab Duo와의 통합 활성화 또는 비활성화 |
hostname |
문자열 | GitLab Duo API 호스트명 | |
integrationKey |
문자열 | GitLab Duo API 통합 키 | |
secretKey |
GitLab Duo API 비밀 키는 비밀 및 키 이름으로 구성해야 합니다 |
GitLab Duo 비밀 키 구성
GitLab Helm 차트에서 GitLab Duo 인증 통합을 구성하려면 global.appConfig.duoAuth.secretKey.secret
설정에 GitLab Duo 인증 비밀 키 값을 포함하는 비밀을 제공해야 합니다.
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
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
allowBypassTwoFactor |
사용자가 특정 공급자를 통해 두 단계 인증 없이 로그인할 수 있도록 허용합니다. true , false 또는 공급자 배열로 설정할 수 있습니다. 두 단계 인증 우회를 참조하세요. |
||
allowSingleSignOn |
배열 | ['saml'] |
OmniAuth로 로그인할 때 계정의 자동 생성을 활성화합니다. OmniAuth 공급자의 이름을 입력합니다. |
autoLinkLdapUser |
불리언 | false |
LDAP / ActiveDirectory 통합이 활성화되어 있는 경우 사용할 수 있습니다. 활성화하면 OmniAuth를 통해 자동 생성된 사용자가 LDAP 항목과 연결됩니다. |
autoLinkSamlUser |
불리언 | false |
SAML 통합이 활성화되어 있는 경우 사용할 수 있습니다. 활성화하면 OmniAuth를 통해 자동 생성된 사용자가 SAML 항목과 연결됩니다. |
autoLinkUser |
OmniAuth 공급자를 통해 인증하는 사용자가 이메일이 일치하는 경우 현재 GitLab 사용자와 자동으로 연결됩니다. true , false 또는 공급자 배열로 설정할 수 있습니다. |
||
autoSignInWithProvider |
nil |
자동으로 로그인할 수 있는 단일 공급자 이름입니다. 이 이름은 saml 또는 google_oauth2 와 같은 공급자의 이름과 일치해야 합니다. |
|
blockAutoCreatedUsers |
불리언 | true |
true 로 설정된 경우 자동으로 생성된 사용자는 기본적으로 차단되어 있으며, 로그인하기 전에 관리자가 차단을 해제해야 합니다. |
enabled |
불리언 | false |
GitLab에서 OmniAuth 사용을 활성화/비활성화합니다. |
externalProviders |
[] |
원하는 OmniAuth 공급자를 외부 로 정의할 수 있습니다. 이들 공급자를 통해 계정을 생성하거나 로그인하는 모든 사용자는 내부 프로젝트에 접근할 수 없습니다. ‘google_oauth2’와 같이 공급자의 전체 이름을 사용해야 합니다. 외부로 OmniAuth 공급자 구성을 참조하세요. |
|
providers |
[] |
아래를 참조하세요. | |
syncProfileAttributes |
['email'] |
로그인 시 공급자로부터 동기화할 프로필 속성 목록입니다. OmniAuth 사용자 프로필 최신 상태 유지에서 옵션을 확인하세요. | |
syncProfileFromProvider |
[] |
GitLab이 자동으로 프로필 정보를 동기화해야 하는 공급자 이름 목록입니다. 항목은 saml 또는 google_oauth2 와 같은 공급자의 이름과 일치해야 합니다. OmniAuth 사용자 프로필 최신 상태 유지에서 확인하세요. |
공급자
providers
는 gitlab.yml
을 채우는 데 사용되는 맵의 배열로 제공됩니다.
소스에서 설치할 때와 마찬가지로 GitLab 문서를 참조하여 사용 가능한 지원 공급자 목록을 확인하세요. 기본값은 []
입니다.
이 속성에는 두 개의 하위 키가 있습니다: secret
및 key
:
-
secret
: (필수) 공급자 블록을 포함하는 KubernetesSecret
의 이름입니다. -
key
: (선택적) 공급자 블록을 포함하는Secret
내의 키 이름입니다. 기본값은provider
입니다.
또는 공급자가 이름 외에 다른 구성 요소가 없는 경우, ‘name’ 속성만 있는 두 번째 형식을 사용할 수 있으며, 선택적으로 label
또는 icon
속성을 사용할 수 있습니다. 적합한 공급자는 다음과 같습니다:
이 항목의 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'
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
그룹 SAML 구성 예제:
omniauth:
providers:
- name: group_saml
전역 차트를 사용할 때 구성 --set
항목 예제:
--set global.appConfig.omniauth.providers[0].secret=gitlab-google-oauth2 \
--set
인수를 사용하는 복잡성으로 인해, 사용자는 YAML 스니펫을 사용하여 helm
에 -f omniauth.yaml
옵션으로 전달하기를 원할 수 있습니다.
크론 작업 관련 설정
Sidekiq는 주기적으로 실행되도록 구성할 수 있는 유지 관리 작업을 포함합니다.
아래에 몇 가지 예시가 포함되어 있습니다.
샘플 gitlab.yml
의 cron_jobs
및 ee_cron_jobs
섹션에서 더 많은 작업 예시를 확인하세요.
이 설정은 Sidekiq, Webservice(UI에서 툴팁 표시용) 및 Toolbox(디버깅 용도) 파드 간에 공유됩니다.
global:
appConfig:
cron_jobs:
stuck_ci_jobs_worker:
cron: "0 * * * *"
pipeline_schedule_worker:
cron: "3-59/10 * * * *"
expire_build_artifacts_worker:
cron: "*/7 * * * *"
Sentry 설정
이 설정을 사용하여 GitLab 오류 보고를 Sentry로 활성화합니다.
global:
appConfig:
sentry:
enabled:
dsn:
clientside_dsn:
environment:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled |
Boolean | false |
통합 활성화 또는 비활성화 |
dsn |
String | 백엔드 오류를 위한 Sentry DSN | |
clientside_dsn |
String | 프론트엔드 오류를 위한 Sentry DSN | |
environment |
String | Sentry 환경 참조 |
gitlab_docs
설정
이 설정을 사용하여 gitlab_docs
를 활성화합니다.
global:
appConfig:
gitlab_docs:
enabled:
host:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled |
Boolean | false |
gitlab_docs 활성화 또는 비활성화 |
host |
String | ”” | docs 호스트 |
스마트카드 인증 설정
global:
appConfig:
smartcard:
enabled: false
CASecret:
clientCertificateRequiredHost:
sanExtensions: false
requiredForGitAccess: false
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled |
Boolean | false |
스마트카드 인증 활성화 또는 비활성화 |
CASecret |
String | CA 인증서를 포함하는 비밀의 이름 | |
clientCertificateRequiredHost |
String | 스마트카드 인증을 위해 사용할 호스트명. 기본적으로 제공된 또는 계산된 스마트카드 호스트명이 사용됩니다. | |
sanExtensions |
Boolean | false |
인증서와 일치하는 사용자를 위해 SAN 확장 사용 활성화 |
requiredForGitAccess |
Boolean | false |
Git 액세스를 위한 스마트카드 로그인의 브라우저 세션 요구 |
Sidekiq 라우팅 규칙 설정
GitLab은 작업을 스케줄링되기 전에 원하는 큐로 라우팅하는 것을 지원합니다.
Sidekiq 클라이언트는 구성된 라우팅 규칙 목록에 따라 작업을 맞춥니다.
규칙은 처음부터 마지막까지 평가되며, 주어진 워커에 대한 일치 항목이 발견되는 즉시 해당 워커의 처리가 중지됩니다(첫 번째 일치가 우선합니다).
워커가 어떤 규칙과도 일치하지 않으면 워커 이름에서 생성된 큐 이름으로 돌아갑니다.
기본적으로 라우팅 규칙은 구성되지 않거나 빈 배열로 표시되어 있으며, 모든 작업은 워커 이름에서 생성된 큐로 라우팅됩니다.
라우팅 규칙 목록은 쿼리와 해당 큐의 튜플로 구성된 정렬된 배열입니다.
-
쿼리는 워커 일치 쿼리 구문을 따릅니다.
-
<queue_name>
은sidekiq.pods
에서 정의된 유효한 Sidekiq 큐 이름sidekiq.pods[].queues
와 일치해야 합니다.
큐 이름이 nil
이거나 빈 문자열인 경우, 워커는 대신 워커 이름으로 생성된 큐로 라우팅됩니다.
쿼리는 모든 워커와 일치하는 와일드카드 일치를 지원하며 *
로 표시됩니다.
결과적으로 와일드카드 쿼리는 목록의 끝에 있어야 하며, 그렇지 않으면 이후 규칙이 무시됩니다.
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
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
serviceName | 문자열 | webservice-default |
내부 API 트래픽을 지시할 서비스의 이름입니다. 릴리스 이름을 포함하지 마세요, 템플릿에서 설정됩니다. gitlab.webservice.deployments 의 항목과 일치해야 합니다. gitlab/webservice 차트를 참조하세요. |
scheme | 문자열 | http |
API 엔드포인트의 스킴 |
host | 문자열 | API 엔드포인트의 완전한 호스트 이름 또는 IP 주소입니다. serviceName 의 존재를 덮어씁니다. |
|
port | 정수 | 8181 |
관련 API 서버의 포트 번호입니다. |
tls.enabled | 불리언 | false |
true 로 설정하면 Workhorse의 TLS 지원이 활성화됩니다. |
Bootsnap 캐시
우리의 Rails 코드베이스는 Shopify의 Bootsnap 젬을 사용합니다. 이 곳의 설정은 해당 동작을 구성하는 데 사용됩니다.
bootsnap.enabled
는 이 기능의 활성화를 제어합니다. 기본값은 true
입니다.
테스트 결과 Bootsnap을 활성화하면 애플리케이션의 전체 성능이 향상되었습니다. 사전 컴파일된 캐시가 있을 경우 일부 애플리케이션 컨테이너는 33% 이상의 향상을 보입니다. 현재 GitLab은 이 사전 컴파일된 캐시를 컨테이너에 제공하지 않으므로 “단지” 14%의 향상이 발생합니다. 사전 컴파일된 캐시가 없는 상태에서 이 이점을 얻는 데는 비용이 발생하며, 각 Pod의 초기 시작 시 작은 IO가 급증하게 됩니다. 이로 인해 문제가 될 수 있는 환경에서는 Bootsnap 사용을 비활성화하는 방법을 제공하게 되었습니다.
가능할 경우, 이 기능을 활성화된 상태로 두는 것을 권장합니다.
GitLab Shell 구성
GitLab Shell 차트의 전 세계 구성을 위한 여러 항목이 있습니다.
global:
shell:
port:
authToken: {}
hostKeys: {}
tcp:
proxyProtocol: false
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
port |
정수 | 22 |
특정 문서를 보려면 port를 참조하세요. |
authToken |
GitLab Shell 차트 특정 문서의 authToken을 참조하세요. | ||
hostKeys |
GitLab Shell 차트 특정 문서의 hostKeys을 참조하세요. | ||
tcp.proxyProtocol |
불리언 | false |
특정 문서를 보려면 TCP proxy protocol를 참조하세요. |
포트
SSH 트래픽을 전달하기 위해 Ingress에서 사용하는 포트와 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 Ingress에서 프록시 프로토콜 처리를 활성화하여 프록시 프로토콜 헤더를 추가하는 업스트림 프록시에서의 연결을 적절하게 처리할 수 있습니다.
이렇게 하면 SSH가 추가 헤더를 수신하지 않도록 하여 SSH가 중단되지 않도록 막을 수 있습니다.
프록시 프로토콜 처리를 활성화해야 하는 일반적인 환경은 AWS를 사용하여 클러스터로의 인바운드 연결을 처리하는 ELB를 사용하는 경우입니다. 이를 적절하게 설정하려면 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:
namespaceInPath: false
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled |
Boolean | False | 클러스터에 GitLab Pages 차트를 설치할지를 결정합니다. |
accessControl |
Boolean | False | GitLab Pages 접근 제어를 활성화합니다. |
path |
String | /srv/gitlab/shared/pages |
Pages 배포 관련 파일이 저장될 경로입니다. 주의: 기본적으로 사용되지 않으며, 객체 스토리지를 사용합니다. |
host |
String | Pages 루트 도메인입니다. | |
port |
String | UI에서 Pages URL 생성을 위해 사용할 포트입니다. 설정하지 않을 경우 기본값으로 80 또는 443이 HTTPS 상황에 따라 설정됩니다. | |
https |
Boolean | True | GitLab UI에서 Pages의 HTTPS URL을 표시할 것인지를 결정합니다. global.hosts.pages.https 및 global.hosts.https 보다 우선합니다. 기본값은 True입니다. |
externalHttp |
List | [] |
HTTP 요청이 Pages 데몬에 도달하는 IP 주소 목록입니다. 사용자 지정 도메인을 지원합니다. |
externalHttps |
List | [] |
HTTPS 요청이 Pages 데몬에 도달하는 IP 주소 목록입니다. 사용자 지정 도메인을 지원합니다. |
artifactsServer |
Boolean | True | GitLab Pages에서 아티팩트를 볼 수 있도록 활성화합니다. |
objectStore.enabled |
Boolean | True | Pages에 대한 객체 스토리지를 사용할 수 있도록 활성화합니다. |
objectStore.bucket |
String | gitlab-pages |
Pages와 관련된 콘텐츠를 저장할 버킷입니다. |
objectStore.connection.secret |
String | 객체 스토리지의 연결 세부정보를 포함하는 비밀입니다. | |
objectStore.connection.key |
String | 연결 세부정보가 저장된 연결 비밀 내의 키입니다. | |
localStore.enabled |
Boolean | False | 페이지와 관련된 콘텐츠에 대한 로컬 스토리지 사용을 활성화합니다. (객체 스토리지와 반대) |
localStore.path |
String | /srv/gitlab/shared/pages |
지역 저장소가 true로 설정될 경우 파일이 저장될 경로입니다. |
apiSecret.secret |
String | Base64로 인코딩된 32비트 API 키를 포함하는 비밀입니다. | |
apiSecret.key |
String | API 키가 저장된 API 키 비밀 내의 키입니다. | |
namespaceInPath |
Boolean | False | (베타) 와일드카드 DNS 설정 없이 지원하기 위해 URL 경로에 네임스페이스를 활성화하거나 비활성화합니다. 추가 정보는 와일드카드 DNS 없는 Pages 도메인 문서를 참조하십시오. |
웹서비스 구성
다른 차트에서도 사용되는 전역 웹서비스 설정은
global.webservice
키 아래에 있습니다.
global:
webservice:
workerTimeout: 60
workerTimeout
웹서비스 워커 프로세스가 웹서비스 마스터 프로세스에 의해 종료되는 요청 시간 초과(초 단위)를 구성합니다. 기본값은 60초입니다.
global.webservice.workerTimeout
설정은 최대 요청 지속 시간에 영향을 미치지 않습니다. 최대 요청 지속 시간을 설정하려면 다음 환경 변수를 설정하십시오:
gitlab:
webservice:
workerTimeout: 60
extraEnv:
GITLAB_RAILS_RACK_TIMEOUT: "60"
GITLAB_RAILS_WAIT_TIMEOUT: "90"
사용자 지정 인증 기관
주의:
이 설정은 requirements.yaml
를 통해 이 리포지토리 외부의 차트에 영향을 미치지 않습니다.
일부 사용자는 TLS 서비스에 대해 내부에서 발급된 SSL 인증서를 사용할 때와 같이 사용자 지정 인증 기관을 추가해야 할 수 있습니다. 이 기능을 제공하기 위해, 우리는 이러한 사용자 지정 루트 인증 기관을 Secrets 또는 ConfigMaps를 통해 애플리케이션에 주입할 수 있는 메커니즘을 제공합니다.
Secret 또는 ConfigMap을 생성하려면:
# 인증서 파일에서 Secret 생성
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
Secret 또는 ConfigMap 또는 둘 다를 구성하려면 globals에 지정하십시오:
global:
certificates:
customCAs:
- secret: secret-custom-CAs # Secret의 모든 키 마운트
- secret: secret-custom-CAs # Secret의 지정된 키만 마운트
keys:
- unique_name.crt
- configMap: cm-custom-CAs # ConfigMap의 모든 키 마운트
- configMap: cm-custom-CAs # ConfigMap의 지정된 키만 마운트
keys:
- unique_name_1.crt
- unique_name_2.crt
주의:
Secret의 키 이름에서 .crt
확장자는
Debian update-ca-certificates 패키지에 중요합니다.
이 단계는 사용자 지정 CA 파일이 해당 확장자로 마운트되고, 인증서 initContainers에서 처리되도록 보장합니다.
이전에 인증서 헬퍼 이미지가 Alpine 기반일 때는
파일 확장자가 실제로 필요하지 않았지만
문서에서는
그렇다고 합니다.
UBI 기반의 update-ca-trust
유틸리티는 같은 요구 사항이 없는 것 같습니다.
여러 개의 Secrets 또는 ConfigMaps를 제공할 수 있으며, 각 Secrets 또는 ConfigMaps는 PEM-인코딩된 CA 인증서를 보유하는 여러 키를 포함할 수 있습니다.
이들은 global.certificates.customCAs
아래 항목으로 구성됩니다.
모든 키는 특정 키의 목록이 제공되지 않는 한 마운트됩니다.
모든 Secrets와 ConfigMaps의 모든 마운트된 키는 고유해야 합니다.
Secrets와 ConfigMaps는 어떤 방식으로든 명명할 수 있지만,
충돌하는 키 이름을 포함해서는 안 됩니다.
애플리케이션 리소스
GitLab은 선택적으로 Application 리소스를 포함할 수 있으며,
이를 생성하여 클러스터 내에서 GitLab 애플리케이션을 식별할 수 있습니다.
Application CRD,
버전 v1beta1
,을 클러스터에 이미 배포해야 합니다.
활성화하려면 global.application.create
를 true
로 설정하십시오:
global:
application:
create: true
Google GKE Marketplace와 같은 일부 환경에서는 ClusterRole 리소스의 생성을 허용하지 않습니다. 다음 값을 설정하여 애플리케이션 사용자 정의 리소스 정의 및 Cloud Native GitLab과 함께 패키지된 관련 차트에서 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 차트는 포드가 사용자 지정 Service Accounts를 사용하여 실행될 수 있도록 합니다.
이는 global.serviceAccount
의 다음 설정으로 구성됩니다:
global:
serviceAccount:
enabled: false
create: true
annotations: {}
automountServiceAccountToken: false
## ServiceAccount에 사용될 이름, 그렇지 않으면 차트 전체 이름이 기본값으로 사용됩니다.
# name:
-
global.serviceAccount.enabled
설정은 각 구성 요소에 대한 ServiceAccount 참조를spec.serviceAccountName
을 통해 제어합니다. -
global.serviceAccount.create
설정은 Helm을 통해 ServiceAccount 객체 생성을 제어합니다. -
global.serviceAccount.name
설정은 ServiceAccount 객체 이름과 각 구성 요소에서 참조되는 이름을 제어합니다. -
global.serviceAccount.automountServiceAccountToken
설정은 기본 ServiceAccount 액세스 토큰이 포드에 마운트되어야 하는지 여부를 제어합니다.특정 사이드카가 제대로 작동하기 위해 필요하지 않는 한 이 기능은 활성화하지 않아야 합니다 (예: Istio).
참고:
global.serviceAccount.create=true
와 global.serviceAccount.name
을 함께 사용하지 마십시오. 이는 차트가 동일한 이름을 가진 여러 ServiceAccount 객체를 생성하도록 지시합니다.
대신, 전역 이름을 지정하는 경우 global.serviceAccount.create=false
를 사용하십시오.
주석
사용자 지정 주석은 Deployment, Service 및 Ingress 객체에 적용할 수 있습니다.
global:
deployment:
annotations:
environment: production
service:
annotations:
environment: production
ingress:
annotations:
environment: production
노드 선택기
사용자 지정 nodeSelector
를 모든 구성 요소에 전역적으로 적용할 수 있습니다.
모든 전역 기본값은 각 서브차트에서 개별적으로 재정의될 수 있습니다.
global:
nodeSelector:
disktype: ssd
참고:
현재 외부에서 유지 관리되는 차트는 global.nodeSelector
를 준수하지 않으며, 사용 가능한 차트 값을 기반으로 별도로 구성해야 할 수 있습니다.
여기에는 Prometheus, cert-manager, Redis 등이 포함됩니다.
라벨
공통 라벨
라벨은 다양한 객체에 의해 생성된 거의 모든 객체에 적용할 수 있습니다.
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 구성 요소 서브 차트만 이러한 추가 라벨을 받게 됩니다.
포드
사용자 지정 라벨은 다양한 Deployment 및 Job에 적용할 수 있습니다.
이 라벨은 이 Helm 차트에 의해 구성된 기존 또는 미리 구성된 라벨에 보완적입니다.
이 보완 라벨은 matchSelectors
에 사용되지 않습니다.
global:
pod:
labels:
environment: production
서비스
사용자 정의 레이블은 서비스에 적용할 수 있습니다. 이러한 레이블은 이 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 차트를 통해 배포되는 모든 컨테이너에서 추가 환경 변수를 노출할 수 있도록 합니다 (charts/gitlab/charts
). 전역 수준에서 설정된 추가 환경 변수는 차트 수준에서 제공된 변수와 병합되며, 차트 수준에서 제공된 변수가 우선합니다.
다음은 extraEnv
의 사용 예입니다:
global:
extraEnv:
SOME_KEY: some_value
SOME_OTHER_KEY: some_other_value
extraEnvFrom
extraEnvFrom
은 다른 데이터 소스로부터 추가 환경 변수를 모든 컨테이너에서 노출할 수 있도록 합니다. 추가 환경 변수는 global
수준(global.extraEnvFrom
)과 서브 차트 수준(<subchart_name>.extraEnvFrom
)에서 설정할 수 있습니다.
Sidekiq 및 Webservice 차트는 추가 로컬 오버라이드를 지원합니다. 자세한 내용은 해당 문서를 참조하세요.
다음은 extraEnvFrom
의 사용 예입니다:
global:
extraEnvFrom:
MY_NODE_NAME:
fieldRef:
fieldPath: spec.nodeName
MY_CPU_REQUEST:
resourceFieldRef:
containerName: test-container
resource: requests.cpu
gitlab:
kas:
extraEnvFrom:
CONFIG_STRING:
configMapKeyRef:
name: useful-config
key: some-string
# 선택적: boolean
참고:
구현은 내용 유형이 다른 값 이름을 재사용하는 것을 지원하지 않습니다. 유사한 내용으로 동일한 이름을 재정의할 수 있지만, secretKeyRef
, configMapKeyRef
등과 같은 소스를 혼합할 수는 없습니다.
OAuth 설정 구성
OAuth 통합은 이를 지원하는 서비스에 대해 기본적으로 구성됩니다. global.oauth
에 지정된 서비스는 배포 중에 GitLab에서 OAuth 클라이언트 애플리케이션으로 자동 등록됩니다. 기본적으로 이 목록에는 액세스 제어가 활성화된 경우 GitLab Pages가 포함됩니다.
global:
oauth:
gitlab-pages: {}
# secret
# appid
# appsecret
# redirectUri
# authScope
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
secret |
문자열 | 서비스에 대한 OAuth 자격 증명이 포함된 비밀의 이름입니다. | |
appIdKey |
문자열 | 서비스의 App ID가 저장된 비밀의 키입니다. 기본값은 appid 입니다. |
|
appSecretKey |
문자열 | 서비스의 App Secret이 저장된 비밀의 키입니다. 기본값은 appsecret 입니다. |
|
redirectUri |
문자열 | 사용자에게 성공적인 인증 후 리디렉션될 URI입니다. | |
authScope |
문자열 | api |
GitLab API와의 인증에 사용되는 범위입니다. |
비밀에 대한 자세한 내용은 비밀 문서를 참조하세요.
Kerberos
GitLab Helm 차트에서 Kerberos 통합을 구성하려면, GitLab 호스트에 대한 서비스 주체와 함께 Kerberos keytab을 포함하는 비밀을 global.appConfig.kerberos.keytab.secret
설정에 제공해야 합니다. 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
를 설정하여 활성화됩니다. 이렇게 하면 티켓 기반 인증을 위한 활성화된 OmniAuth 제공업체 목록에 kerberos
제공업체가 추가됩니다.
false
로 설정하면 Helm 차트는 여전히 toolbox, Sidekiq 및 웹 서비스 Pods에 keytab
을 마운트하며, 이를 Kerberos에 대한 수동으로 구성된 OmniAuth 설정과 함께 사용할 수 있습니다.
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 협상 전용 포트를 지원합니다. 이는 인증 교환에서 negotiate
헤더가 제공될 경우 Git이 Basic Authentication으로 되돌아가는 제한을 우회하기 위함입니다.
GitLab CI/CD를 사용할 때는 GitLab Runner 헬퍼가 GitLab에서 클론하기 위해 URL 내 자격 증명에 의존하므로 전용 포트를 사용하는 것이 현재 요구됩니다.
이는 global.appConfig.kerberos.dedicatedPort
설정으로 활성화할 수 있습니다:
global:
appConfig:
kerberos:
[...]
dedicatedPort:
enabled: true
port: 8443
https: true
이 설정은 Kerberos 협상 전용으로 GitLab UI에서 추가 클론 URL을 활성화합니다. https: true
설정은 URL 생성을 위한 것만이며, 추가 TLS 구성을 노출하지 않습니다. TLS는 GitLab의 Ingress에서 종료되고 구성됩니다.
nginx-ingress
Helm 차트 포크의 제한으로 인해 dedicatedPort
를 지정하면 현재 차트의 nginx-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"
사용 가능한 구성 옵션에 대한 추가 정보는 발신 이메일 문서에서 확인할 수 있습니다.
보다 자세한 예제는 리눅스 패키지 SMTP 설정 문서에서 확인할 수 있습니다.
플랫폼
platform
키는 GKE 또는 EKS와 같은 특정 플랫폼을 대상으로 하는 특정 기능을 위해 예약되어 있습니다.
친화도
친화도 구성은 global.antiAffinity
및 global.affinity
를 통해 사용 가능합니다.
친화도를 사용하면 노드 레이블 또는 이미 노드에서 실행 중인 포드의 레이블을 기반으로 포드가 예약될 수 있는 노드를 제한할 수 있습니다. 이를 통해 클러스터 전반에 포드를 분산시키거나 특정 노드를 선택하여 고장 노드의 경우 더 높은 복원력을 보장할 수 있습니다.
global:
antiAffinity: soft
affinity:
podAntiAffinity:
topologyKey: "kubernetes.io/hostname"
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
antiAffinity |
문자열 | soft |
포드에 적용할 포드 반대 친화도. |
affinity.podAntiAffinity.topologyKey |
문자열 | kubernetes.io/hostname |
포드 반대 친화도 토폴로지 키. |
-
global.antiAffinity
는 두 가지 값을 취할 수 있습니다:-
soft
: Kubernetes 스케줄러가 규칙을 시행하려고 시도하지만 결과를 보장하지 않는preferredDuringSchedulingIgnoredDuringExecution
반대 친화도를 정의합니다. -
hard
: 포드가 노드에 예약되기 위해 충족되어야 하는 규칙인requiredDuringSchedulingIgnoredDuringExecution
반대 친화도를 정의합니다.
-
-
global.affinity.podAntiAffinity.topologyKey
는 이를 논리적 영역으로 나누는 데 사용되는 노드 속성을 정의합니다. 가장 일반적인topologyKey
값은:kubernetes.io/hostname
topology.kubernetes.io/zone
topology.kubernetes.io/region
Kubernetes에 대한 참조는 인터 포드 친화도 및 반대 친화도에서 확인하세요.
파드 우선 순위 및 선제적 제거
파드 우선 순위는 global.priorityClassName
또는 서브 차트별로 priorityClassName
을 통해 구성할 수 있습니다.
파드 우선 순위를 설정하면 스케줄러에게 더 낮은 우선 순위의 파드를 퇴거시켜 대기 중인 파드의 스케줄링을 가능하게 할 수 있습니다.
global:
priorityClassName: system-cluster-critical
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
priorityClassName |
문자열 | 파드에 할당된 우선 순위 클래스입니다. |
로그 순환
기본적으로 GitLab Helm 차트는 로그를 순환하지 않습니다. 이로 인해 오랜 시간 동안 실행되는 컨테이너의 일시적인 저장소 문제를 일으킬 수 있습니다.
로그 순환을 활성화하려면 GITLAB_LOGGER_TRUNCATE_LOGS
환경 변수를 true
로 설정하십시오. 자세한 내용은 GitLab Logger의 문서를 참조하십시오. 특히 다음에 대한 정보를 참조하십시오:
작업
원래 GitLab의 작업은 Helm .Release.Revision
으로 접미사가 붙어 있었으나, 이는 변화가 없더라도 helm upgrade --install
을 실행할 때 작업이 항상 업데이트되기 때문에 이상적이지 않았습니다. 또한 helm template
을 기반으로 한 워크플로우와의 적절한 작업을 방해했습니다. 작업이 한 번만 실행될 수 있다는 전제 조건과 helm uninstall
이 작업을 삭제하지 않는다는 전제를 기반으로 .Release.Revision
을 이름에 사용하는 결정이 내려졌으나 이는 (현재는) 잘못되었습니다.
GitLab Helm 차트 7.9 이상에서는 기본적으로 작업 이름에 차트의 앱 버전 및 차트의 값(여기에는 global.gitlabVersion
이 포함될 수 있음)을 기반으로 한 해시가 접미사로 붙습니다. 이 접근 방식은 여러 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)
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
nameSuffixOverride |
문자열 | 자동 생성된 해시를 대체할 사용자 정의 접미사입니다. |
Traefik
Traefik 설정은 globals.traefik
를 통해 구성할 수 있습니다.
global:
traefik:
apiVersion: ""
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
apiVersion |
문자 | Traefik 리소스의 기본 apiVersion 을 재정의합니다. |