- 호스트 설정 구성
- Horizontal Pod Autoscaler 설정 구성
- PodDisruptionBudget 설정 구성
- CronJob 설정 구성
- 모니터링 설정 구성
- Ingress 설정 구성
- GitLab 버전
- 모든 이미지 태그에 접미사 추가
- PostgreSQL 설정 구성
- Redis 설정 구성
- 레지스트리 설정 구성
- 기타 Gitaly 설정 구성
- Praefect 설정 구성
- MinIO 설정 구성
- appConfig 설정 구성
- Rails 설정 구성
- Workhorse 설정 구성
- GitLab Shell 구성
- GitLab 페이지 구성
- 웹 서비스 구성
- 사용자 정의 인증 기관
- 애플리케이션 리소스
- GitLab 기본 이미지
- 서비스 계정
- 어노테이션
- 노드 선택기
- 라벨
- 추적
- extraEnv
- extraEnvFrom
- OAuth 설정 구성
- Kerberos
- 발신 이메일
- 플랫폼
- Affinity
- Pod 우선순위 및 선점
- 로그 로테이션
전역 변수를 사용하여 차트 구성하기
저희의 래퍼 Helm 차트를 설치할 때 구성 중복을 줄이기 위해 values.yaml
의 global
섹션에 설정할 수 있는 여러 구성 설정이 있습니다. 이러한 전역 설정은 여러 차트에서 사용되는 반면, 다른 모든 설정은 해당 차트 내에서 범위가 지정됩니다. 전역 변수가 작동하는 방식에 대한 자세한 정보는 전역 변수에 대한 Helm 문서를 참조하세요.
- 호스트 구성
- 인그레스 구성
- GitLab 버전
- PostgreSQL
- Redis
- 레지스트리
- Gitaly
- Praefect
- MinIO
- appConfig
- Rails
- Workhorse
- GitLab Shell
- 페이지
- 웹 서비스
- 사용자 정의 인증 기관
- 응용 프로그램 리소스
- GitLab 기본 이미지
- 서비스 계정
- 주석
- 추적
- extraEnv
- extraEnvFrom
- OAuth
- Kerberos
- 소 ausge email
- 플랫폼
- 페네유티
- Pod priority and preemption
- 로그 회전
호스트 설정 구성
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 및 레지스트리는이 설정의 하위 도메인에서 노출됩니다. 이 기본값은 example.com 이지만 name 속성이 구성된 호스트에는 사용되지 않습니다. 아래의 gitlab.name , minio.name , 및 registry.name 섹션을 참조하세요.
|
externalIP
| nil
| 공급 업체에서 요구되는 외부 IP 주소를 설정합니다. 이는 더 복잡한 nginx.service.loadBalancerIP 를 대체하기 위해 NGINX 차트에 템플릿화됩니다.
| |
… (중략) … |
hostSuffix
hostSuffix
은 기본 domain
을 사용하여 호스트 이름을 조립할 때 하위 도메인에 추가되지만, 자체 name
이 설정된 호스트에는 사용되지 않습니다.
기본적으로 미설정 상태입니다. 설정된 경우 하이픈과 함께 하위 도메인에 접미어가 추가됩니다.
아래 예시는 외부 호스트 이름으로 gitlab-staging.example.com
및 registry-staging.example.com
을 사용하게 됩니다.
global:
hosts:
domain: example.com
hostSuffix: staging
Horizontal Pod Autoscaler 설정 구성
HPA(Horizontal Pod Autoscaler)를 위한 GitLab 전역 호스트 설정은 global.hpa
키 하에 있습니다:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
apiVersion
| 문자열 | HorizontalPodAutoscaler 객체 정의에 사용할 API 버전. |
PodDisruptionBudget 설정 구성
PDB(PodDisruptionBudget)를 위한 GitLab 전역 호스트 설정은 global.pdb
키 하에 있습니다:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
apiVersion
| 문자열 | PodDisruptionBudget 객체 정의에 사용할 API 버전. |
CronJob 설정 구성
CronJob을 위한 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를 종료할 수 없는 경우와 같이 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
항목을 수정해야 하는 사용자들을 돕습니다.
많은 사용자들은 이 설정이 필요하지 않으며, 구성하지 말아야 합니다.
ingress.class: gce
를 사용할 때와 같이 로드 밸런서/프록시 동작과 일치하도록 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 객체에 대해 자동으로 셀프사인 인증서를 생성합니다.
이는 모든 Ingress 객체에 대해 와일드카드 인증서를 생성합니다.
외부 cert-manager
를 사용하려면 다음을 제공해야 합니다:
- gitlab.webservice.ingress.tls.secretName
- registry.ingress.tls.secretName
- minio.ingress.tls.secretName
- global.ingress.annotations
global.ingress.useNewIngressForCerts
cert-manager
의 동작 방식을 변경하여 새로운 Ingress를 동적으로 생성하여 ACME 도전 검증을 수행하도록 하는 글로벌 설정입니다.
기본 로직(글로벌로 global.ingress.useNewIngressForCerts
가 false
인 경우)은 검증을 위해 기존의 Ingress를 재사용합니다.
이 기본값은 일부 상황에 적합하지 않을 수 있습니다. 이 플래그를 true
로 설정하면 각 도전 검증을 위해 새로운 Ingress 객체가 생성됩니다.
global.ingress.useNewIngressForCerts
는 GKE Ingress 컨트롤러와 함께 사용할 때 true
로 설정할 수 없습니다.
이를 활성화하는 전체 정보는 릴리스 노트에서 확인하세요.
GitLab 버전
주의: 이 값을 개발 목적으로만 사용하거나 GitLab 지원팀의 명시적 요청에 따라 사용해야 합니다. 프로덕션 환경에서는 이 값을 사용하지 말고 버전을 Helm을 사용하여 배포하는 대로 설정하세요.
차트의 기본 이미지 태그에 사용된 GitLab 버전은 다음과 같이 global.gitlabVersion
키를 사용하여 변경할 수 있습니다:
--set global.gitlabVersion=11.0.1
이는 webservice
, sidekiq
, 및 migration
차트에 사용된 기본 이미지 태그에 영향을 줍니다.
gitaly
, gitlab-shell
, 및 gitlab-runner
이미지 태그는 별도로 업데이트해야 함을 유의하세요.
모든 이미지 태그에 접미사 추가
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
| 문자열 | 사용할 PostgreSQL 서버의 호스트 이름. 이 차트에서 배포된 PostgreSQL을 사용하는 경우에는 이 값은 생략할 수 있습니다. | |
serviceName
| 문자열 | PostgreSQL 데이터베이스를 운영하는 서비스 의 이름. 이 값이 존재하고, host 가 존재하지 않으면, 차트는 host 값 대신 서비스의 호스트 이름을 템플릿화합니다.
| |
database
| 문자열 | gitlabhq_production
| PostgreSQL 서버에서 사용할 데이터베이스의 이름. |
password.useSecret
| 부울 | true
| PostgreSQL의 암호가 비밀 또는 파일에서 읽히는지를 제어합니다. |
password.file
| 문자열 | PostgreSQL의 암호가 포함된 파일의 경로를 정의합니다. password.useSecret 가 true인 경우 무시됩니다.
| |
password.key
| 문자열 | PostgreSQL의 password.key 속성은 비밀의 키 이름을 정의하며, 이 비밀을 담고 있는 시크릿(아래)에 있습니다. password.useSecret 가 false인 경우 무시됩니다.
| |
password.secret
| 문자열 | PostgreSQL의 password.secret 속성은 Kubernetes Secret 의 이름을 정의하며, 이 비밀을 가져오게 됩니다. password.useSecret 가 false인 경우 무시됩니다.
| |
port
| 정수 | 5432
| PostgreSQL 서버에 연결할 포트 번호. |
username
| 문자열 | gitlab
| 데이터베이스에 인증할 사용자 이름. |
preparedStatements
| 부울 | false
| PostgreSQL 서버와의 통신에 준비된 문장이 사용될지 여부 |
databaseTasks
| 부울 | true
| 주어진 데이터베이스에 대해 GitLab이 데이터베이스 작업을 수행할지 여부. 호스트/포트/데이터베이스가 main 과 일치할 경우 자동으로 비활성화됩니다.
|
connectTimeout
| 정수 | 데이터베이스 연결을 기다리는 시간(초) | |
keepalives
| 정수 | 클라이언트 측 TCP keepalive 사용 여부(1은 on, 0은 off) | |
keepalivesIdle
| 정수 | 비활동 후 TCP가 서버로 keepalive 메시지를 전송할 초 수. 값이 0인 경우 시스템 기본값을 사용함 | |
keepalivesInterval
| 정수 | 서버가 확인하지 않는 TCP keepalive 메시지를 몇 초 후에 재전송해야 하는지. 값이 0인 경우 시스템 기본값을 사용함 | |
keepalivesCount
| 정수 | 클라이언트와 서버 간의 TCP keepalive 연결 손실 횟수. 값이 0인 경우 시스템 기본값을 사용함 | |
tcpUserTimeout
| 정수 | 연결이 강제로 닫히기 전에 전송된 데이터가 응답을 받기까지 얼마나 머물 수 있는지(밀리초). 값이 0인 경우 시스템 기본값을 사용함 | |
applicationName
| 문자열 | 데이터베이스에 연결하는 응용 프로그램의 이름. 비어 있는 문자열("" )로 설정하여 비활성화합니다. 기본적으로 실행 중인 프로세스의 이름(e.g. sidekiq , puma )으로 설정됩니다.
| |
ci.enabled
| 부울 | true
| 두 개의 데이터베이스 연결을 활성화합니다. |
PostgreSQL per chart
복잡한 배포에서는 PostgreSQL의 다른 구성에 대해 서로 다른 구성을 설정하는 것이 바람직할 수 있습니다. v4.2.0
부터는 모든 프로퍼티(gitlab.sidekiq.psql과 같은)가 per-chart 기반으로 설정될 수 있습니다. 지역 설정은 supplied될 때 전역 값에서 상속 받아 _not present_인 경우를 제외하고 재정의하며, 이때 psql.load_balancing
을 예외로 취급합니다.
PostgreSQL load balancing은 설계에 의해 전역에서 상속받지 않을 것입니다.
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
| 문자열 | 다음 키가 포함된 쿠버네티스 시크릿 의 이름
| |
clientCertificate
| 문자열 |
시크릿 내의 클라이언트 인증서를 포함한 키의 이름
| |
clientKey
| 문자열 |
시크릿 내의 클라이언트 인증서의 키 파일을 포함한 키의 이름
| |
serverCA
| 문자열 | 서버의 Certificate Authority를 포함한 시크릿 내의 키의 이름
|
또한 올바른 키를 가리키도록 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 load balancing
이 기능을 사용하려면 이 차트가 HA 형태로 PostgreSQL을 배포하지 않기 때문에 외부 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
stale reads 처리에 대한 추가 조정도 가능합니다. 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 데이터베이스를 가리키는 두 개의 데이터베이스 연결을 기본값으로 사용합니다.
단일 데이터베이스 연결로 전환하려면 ci.enabled
키를 false
로 설정하세요.
global:
psql:
ci:
enabled: false
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:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host
| 문자열 | 사용할 데이터베이스의 Redis 서버의 호스트 이름입니다. 이는 serviceName 대신에 사용할 수 있습니다.
| |
serviceName
| 문자열 | redis
| Redis 데이터베이스를 운영하는 service 의 이름입니다. 이 속성이 존재하고, host 가 없는 경우 차트는 .Release.Name 과 함께 현재 서비스의 호스트 이름을 템플릿화합니다. 이 속성은 전체 GitLab 차트의 일부로 Redis를 사용할 때 편리합니다.
|
port
| 정수 | 6379
| Redis 서버에 연결할 포트입니다. |
user
| 문자열 | Redis 인증에 사용되는 사용자입니다 (Redis 6.0 이상). | |
auth.enabled
| 부울 | true |
auth.enabled 는 Redis 인스턴스에 암호를 사용하는 토글을 제공합니다.
|
auth.key
| 문자열 | Redis의 auth.key 속성은 비밀번호를 포함하고 있는 secret의 키 이름을 정의합니다.
| |
auth.secret
| 문자열 | Redis의 auth.secret 속성은 사용할 Kubernetes Secret 의 이름을 정의합니다.
| |
scheme
| 문자열 | redis
| Redis URL을 생성하는 데 사용될 URI scheme입니다. 유효한 값은 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 차트에서 따로 배포된 Sentinels를 지원합니다. 결과적으로, GitLab 차트를 통한 Redis 배포는 redis.install=false
로 비활성화되어야 합니다. Redis 암호를 포함하는 Kubernetes Secret은 GitLab 차트를 배포하기 전에 수동으로 생성되어야 합니다.
GitLab 차트에서 HA Redis 클러스터의 설치는 Sentinels를 지원하지 않습니다. Sentinel 지원이 필요한 경우, Redis 클러스터는 GitLab 차트 설치 외부에서 생성되어야 합니다. 이는 Kubernetes 클러스터 내부 또는 외부에서 수행할 수 있습니다.
GitLab로 배포된 Redis 클러스터에서 Sentinels를 지원하는 데 대한 지원 여부 및 추적 목적의 이슈가 생성되었습니다.
redis:
install: false
global:
redis:
host: redis.example.com
serviceName: redis
port: 6379
sentinels:
- host: sentinel1.example.com
port: 26379
- host: sentinel2.exeample.com
port: 26379
auth:
enabled: true
secret: gitlab-redis
key: redis-password
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host
| 문자열 |
sentinel.conf 에서 지정한 클러스터 이름으로 설정해야 합니다.
| |
sentinels.[].host
| 문자열 | Redis HA 설정에 대한 Redis Sentinel 서버의 호스트 이름입니다. | |
sentinels.[].port
| 정수 | 26379
| Redis Sentinel 서버에 연결할 포트입니다. |
Sentinel 지원이 포함된 일반 Redis 설정 구성의 이전 Redis 속성은 테이블에서 다시 지정되지 않는 한 계속 적용됩니다.
다중 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 configuration을 참조하세요.
안전한 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 시크릿으로 제공하는 추가 기능도 제공합니다. 예를 들어, 인증 헤더에 민감한 데이터가 포함된 경우:
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) Internal, Gitaly 차트를 통해
StatefulSet
의 일부로. - 차트 외부에서(external) External, 외부 펫으로.
- 혼합 환경(mixed)으로 내부 및 외부 노드를 함께 사용합니다.
새 프로젝트에 사용될 노드를 관리하는 방법에 대한 자세한 내용은 저장소 저장 경로 문서를 참조하세요.
gitaly.host
가 제공된 경우, gitaly.internal
및 gitaly.external
속성은 무시됩니다. 폐지된 Gitaly 설정을 참조하세요.
Gitaly 인증 토큰은 현재 모든 내부 또는 외부 Gitaly 서비스에 대해 동일해야 합니다. 이를 확인하세요. 자세한 내용은 이슈 #1992를 참조하세요.
Internal
internal
키는 현재 names
이라는 하나의 키로만 구성되어 있으며, 이는 차트에서 관리할 저장 이름 목록입니다. 나열된 각 이름에 대해 논리적 순서대로 ${releaseName}-gitaly-${ordinal}
이라는 이름의 Pod가 생성되고, 여기서 ordinal
은 names
목록 내 색인입니다. 동적 프로비저닝이 활성화된 경우, PersistentVolumeClaim
이 일치합니다.
이 목록은 기본적으로 1개의 저장 경로와 관련된 1개의 Pod를 제공합니다.
이 항목의 수동 확장은 gitaly.internal.names
에 항목을 추가하거나 제거함으로써 수행되어야 합니다. 축소하려면 다른 노드로 이동되지 않은 리포지토리는 사용할 수 없게 됩니다. Gitaly 차트가 StatefulSet
이므로 동적으로 프로비저닝된 디스크는 다시 사용될 때까지 재사용되지 않습니다. 이는 데이터 디스크가 유지되어 있고 세트를 다시 확장하면 다시 추가된 노드를 names
목록에 추가함으로써 다시 액세스할 수 있음을 의미합니다.
예제 다중 내부 노드 구성은 예제 폴더에서 찾을 수 있습니다.
외부
external
키는 클러스터 외부에 있는 Gitaly 노드의 구성을 제공합니다. 이 목록의 각 항목에는 3개의 키가 있습니다:
-
name
: 저장소의 이름입니다.name: default
항목은 필수입니다. -
hostname
: Gitaly 서비스의 호스트입니다. -
port
: (옵션) 호스트에 연결할 포트 번호입니다. 기본값은8075
입니다. -
tlsEnabled
: (옵션) 특정 항목에 대해global.gitaly.tls.enabled
를 재정의합니다.
외부 Gitaly 서비스 사용에 대한 고급 구성 가이드를 제공합니다. 또한 예제 폴더에서 다중 외부 서비스 구성을 찾을 수 있습니다. (https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/gitaly/values-multiple-external.yaml)
고가용성 Gitaly 서비스를 제공하기 위해 외부 Praefect를 사용할 수 있습니다. 두 가지의 구성은 클라이언트 관점에서 차이가 없기 때문에 서로 교체할 수 있습니다.
혼합
내부 및 외부 Gitaly 노드를 모두 사용하는 것이 가능하지만 다음 사항을 유의해야 합니다:
-
항상
default
라는 노드가 있어야 합니다, 기본적으로 내부에서 제공됩니다. - 외부 노드가 먼저 채워지고 나서 내부 노드가 채워집니다.
예제 내부 및 외부 노드 혼합 구성을 예제 폴더에서 찾을 수 있습니다.
authToken
Gitaly의 authToken
속성에는 두 개의 하위 키가 있습니다:
-
secret
: 불러올 쿠버네티스Secret
의 이름을 정의합니다. -
key
: 위의 비밀 키에 포함된 authToken의 이름을 정의합니다.
모든 Gitaly 노드가 반드시 동일한 인증 토큰을 공유해야 합니다.
사용되지 않는 Gitaly 설정
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
host (사용되지 않음)
| 문자열 | 사용할 Gitaly 서버의 호스트명입니다. serviceName 대신에 이 설정을 생략할 수 있습니다. 이 설정이 사용되면 internal 또는 external 의 모든 값보다 우선합니다.
| |
port (사용되지 않음)
| 정수 | 8075
| Gitaly 서버에 연결할 포트입니다. |
serviceName (사용되지 않음)
| 문자열 | Gitaly 서버를 운영하는 service 의 이름입니다. 이 값이 있는 경우 host 가 아닌 경우 차트는 host 값 대신에 서비스의 호스트명 (및 현재 .Release.Name )을 템플릿화합니다. 이것은 전반적인 GitLab 차트의 일부로 Gitaly를 사용하는 경우 편리합니다.
|
TLS 설정
Gitaly를 TLS를 통해 서비스하도록 구성하는 방법에 대한 자세한 내용은 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: {}
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
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:
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: []
일반 애플리케이션 설정
appConfig
설정을 사용하여 Rails 애플리케이션의 일반 속성을 조정할 수 있습니다. 아래에서 설명하는 appConfig
설정을 사용하여 일반 속성을 조정할 수 있습니다:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
cdnHost
| 문자열 | (빈 값) | 정적 자산을 제공하기 위한 CDN의 기본 URL을 설정합니다 (예: https://mycdnsubdomain.fictional-cdn.com ).
|
contentSecurityPolicy
| 구조체 | 아래 참조 | |
enableUsagePing
| 부울 | true
| 사용 통계 지원을 비활성화하는 플래그입니다. |
enableSeatLink
| 부울 | true
| Seat 링크 지원을 비활성화하는 플래그입니다. |
enableImpersonation
| nil
| 관리자에 의한 사용자 타살을 비활성화하는 플래그입니다. | |
applicationSettingsCacheSeconds
| 정수 | 60 | 애플리케이션 설정 캐시를 무효화하는데 사용하는 시간 간격 값(초)입니다. |
usernameChangingEnabled
| 부울 | true
| 사용자가 자신의 사용자 이름을 변경할 수 있는지 여부를 결정하는 플래그입니다. |
issueClosingPattern
| 문자열 | (빈 값) | 자동으로 이슈를 닫기 위한 패턴입니다. |
defaultTheme
| 정수 | GitLab 인스턴스의 기본 테마의 숫자 ID를 가져옵니다. 이곳에서 ID를 나타내는 숫자를 가져 옵니다. | |
defaultProjectsFeatures.*feature*
| 부울 | true
| 아래 참조 |
webhookTimeout
| 정수 | (빈 값) | 훅이 실패로 간주되기 전의 대기 시간 (초)입니다. |
graphQlTimeout
| 정수 | (빈 값) | 레일즈가 GraphQL 요청을 완료해야 하는 시간(초)입니다. |
콘텐츠 보안 정책
콘텐츠 보안 정책(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 서비스도 사용할 수 있습니다:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
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 쿠키 비활성화 (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
| 부울 | false
| 통합된 객체 저장 사용 여부를 설정합니다. |
proxy_download
| 부울 | true
|
bucket 에서 직접 다운로드 대신 GitLab을 통한 모든 다운로드 프록시를 활성화합니다.
|
storage_options
| 문자열 | {}
| 아래 참조. |
connection
| 문자열 | {}
| 아래 참조. |
이 속성 구조는 공유되며, 여기에 있는 모든 속성은 개별 항목에서 재정의할 수 있습니다. 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
|
외부 병합 요청 차이 | gitlab-mr-diffs
|
Terraform 상태 | gitlab-terraform-state
|
CI 보안 파일 | gitlab-ci-secure-files
|
의존성 프록시 | gitlab-dependency-proxy
|
페이지 | gitlab-pages
|
기본값을 사용하거나 다음과 같이 버킷 이름을 구성할 수 있습니다.
--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 서버 측 암호화를 구성하는 데 사용됩니다.
기본 암호화를 설정하는 것이 암호화를 활성화하는 가장 쉬운 방법이지만, 암호화된 객체만 업로드되도록 버킷 정책을 설정할 수 있습니다.
이를 위해 storage_options
구성 섹션에서 적절한 암호화 헤더를 GitLab에 전송하도록 설정해야 합니다.
설정 | 설명 |
---|---|
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 차이 및 Dependency Proxy
이 설정에 대한 자세한 내용은 아래에서 제공됩니다. 문서는 개별적으로 반복되지 않으며,
기본값인 bucket
속성을 제외하고는 구조적으로 동일합니다.
enabled: true
proxy_download: true
bucket:
connection:
secret:
key:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled
| 부울 | LFS, 아티팩트, 업로드 및 패키지의 경우 기본값은 true
| 객체 저장소를 사용하여 이러한 기능을 활성화합니다. |
proxy_download
| 부울 | true
|
bucket 에서 직접 다운로드하는 대신 GitLab을 통한 모든 다운로드의 프록시를 활성화합니다.
|
bucket
| 문자열 | 다양 | 객체 저장소 제공자에서 사용할 버킷의 이름. 서비스에 따라 기본값은 git-lfs , gitlab-artifacts , gitlab-uploads 또는 gitlab-packages 가 됩니다.
|
connection
| 문자열 | {}
| 아래 참조. |
connection
connection
속성은 Kubernetes Secret로 전환되었습니다. 이 시크릿의 내용은 YAML 형식 파일이어야 합니다. 기본값은 {}
이며 global.minio.enabled
가 true
인 경우 무시됩니다.
이 속성에는 secret
와 key
두 가지 하위 키가 있습니다.
-
secret
는 Kubernetes Secret의 이름입니다. 외부 객체 저장소를 사용하려면 이 값이 필요합니다. -
key
는 YAML 블록을 포함하는 시크릿 내의 키의 이름입니다. 기본값은connection
입니다.
유효한 구성 키는 GitLab 작업 아티팩트 관리 문서에서 찾을 수 있습니다. 이는 Fog에 해당하며 제공자 모듈 간에 다릅니다.
Amazon 및 Google 제공자의 예시는 examples/objectstorage
에서 찾을 수 있습니다.
connection
의 내용을 포함하는 YAML 파일을 생성한 후 이 파일을 사용하여 Kubernetes에서 시크릿을 생성하세요.
kubectl create secret generic gitlab-rails-storage \
--from-file=connection=rails.yaml
External MR Diffs(외부 MR 차이점에 대해서만)
externalDiffs
설정에는 특정 차이점을 조건부로 객체 저장소에 저장하기 위한 추가 키 when
이 있습니다. 이 설정은 차트에서 기본값이 비워져 있어 Rails 코드에서 기본값이 할당됩니다.
CI 아티팩트(only for CI Artifacts)의 cdn
artifacts
설정에는 Google Cloud Storage 버킷 앞에 Google CDN을 구성하기 위한 추가 키 cdn
이 있습니다.
수신 이메일 설정
수신 이메일 설정은 command line options page에서 설명되어 있습니다.
KAS 설정
사용자 지정 비밀
Helm의 --set 변수
옵션을 사용하여 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 변수
옵션을 사용하여 사용자 정의할 수 있습니다:
--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 변수
옵션을 사용하여 이 작업을 수행할 수 있습니다:
--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 이상 사용.
GitLab 버전을
global.gitlabVersion: <version>
으로 설정할 수 있습니다. 초기 배포 후 이미지 업데이트를 강제해야 하는 경우global.image.pullPolicy: Always
도 설정합니다. -
트러스트할
kas
팟의 인증 기관 및 인증서를 생성합니다.
kas
를 사용자가 생성한 인증서를 사용하도록 구성하려면 다음 값을 설정합니다.
값 | 설명 |
---|---|
global.kas.tls.enabled
|
kas 엔드포인트로의 TLS 통신을 위해 인증서 볼륨을 마운트하고 활성화합니다.
|
global.kas.tls.secretName
| 인증서를 저장하는 쿠버네티스 TLS 시크릿을 지정합니다. |
global.kas.tls.caSecretName
| 사용자 정의 CA를 저장하는 쿠버네티스 TLS 시크릿을 지정합니다. |
예를 들어, 다음과 같이 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에서만 사용됩니다. 이 시크릿은 self-managed GitLab 인스턴스에서는 필요하지 않습니다.
Helm의 --set 변수
옵션을 사용하여 추천 리뷰어 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 사용자 인증을 구성할 수 있습니다. 이는 적절한 LDAP 서버 구성으로 변환될 것이며, 이와 같은 경우 gitlab.yml
에서 소스 설치와 같이 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과 같은 대안을 기본으로 사용할 때 LDAP 자격 증명을 웹 UI를 통해 사용하는 것을 방지하는 것이 유용할 수 있습니다. 이렇게 하면 LDAP를 그룹 동기화에 사용할 수 있으며, 동시에 사용자의 SAML ID 공급자가 사용자 정의 2단계 인증과 같은 추가 확인을 처리할 수 있습니다.
LDAP 웹 로그인이 비활성화되면 사용자는 로그인 페이지에서 LDAP 탭을 볼 수 없습니다. 이렇게 하면 Git 액세스에 대한 LDAP 자격 증명 사용이 비활성화되지 않습니다.
웹 로그인을 위해 LDAP 사용을 비활성화하려면 global.appConfig.ldap.preventSignin: true
로 설정하세요.
사용자 정의 CA 또는 자체 서명된 LDAP 인증서 사용
LDAP 서버가 사용자 정의 CA 또는 자체 서명된 인증서를 사용하는 경우:
-
사용자 정의 CA/자체 서명된 인증서가 cluster/namespace에서 Secret 또는 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
-
그런 다음, 지정하세요:
# 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 인증서가 관련 팟에 /etc/ssl/certs/unique_name.pem
에 마운트되고 LDAP 구성에서 그 사용을 지정합니다.
참고:
GitLab 15.9와 그 이후 버전에서는 /etc/ssl/certs/
에 있는 인증서는 더 이상 ca-cert-
로 접두어가 붙지 않습니다.
이는 배포된 팟용으로 인증서 비밀을 준비하는 컨테이너로 Alpine을 사용했기 때문에 예전 동작이었습니다. 이 작업은 이제 Debian을 기반으로 하는 gitlab-base
컨테이너가 사용됩니다.
자세한 내용은 사용자 정의 인증서 기관를 참조하세요.
DuoAuth
이 설정을 사용하여 GitLab Duo와 2단계 인증(2FA)를 활성화하세요.
global:
appConfig:
duoAuth:
enabled:
hostname:
integrationKey:
secretKey:
# secret:
# key:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
enabled
| Boolean | false
| GitLab Duo 통합을 활성화하거나 비활성화합니다 |
hostname
| String | GitLab Duo API 호스트 이름 | |
integrationKey
| String | GitLab Duo API 통합 키 | |
secretKey
| GitLab Duo API의 비밀 키는 비밀 이름과 키 이름으로 구성되어야 합니다 |
GitLab Duo 시크릿 키 구성
GitLab Helm 차트에서 GitLab Duo 인증 통합을 구성하려면 global.appConfig.duoAuth.secretKey.secret
설정에 GitLab Duo 인증 secret_key 값을 포함한 시크릿을 제공해야 합니다.
명령 줄에서 Kubernetes 시크릿 객체를 생성하여 GitLab Duo 계정의 secretKey
를 저장하는 방법은 다음과 같습니다.
kubectl create secret generic <secret_object_name> --from-literal=secretKey=<duo_secret_key_value>
OmniAuth
GitLab은 OmniAuth를 활용하여 사용자가 Twitter, GitHub, Google 등 인기 있는 서비스를 사용하여 로그인할 수 있도록 지원할 수 있습니다. 확장된 문서는 GitLab의 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
: (필수) 공급자 블록을 포함하는 KubernetesSecret
의 이름 -
key
: (선택 사항) 공급자 블록을 포함하는 시크릿의 키의 이름입니다. 기본값은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
글로벌 차트를 사용할 때 사용자가 예상치 못하게 --set
인수를 사용하는 복잡성 때문에, 사용자는 -f omniauth.yaml
를 사용하여 helm
에 전달되는 YAML 조각을 사용하기를 원할 수 있습니다.
Cron 작업 관련 설정
Sidekiq에는 cron 스타일 일정에 따라 구성할 수 있는 유지보수 작업이 포함되어 있습니다. 몇 가지 예는 아래에 포함되어 있습니다. 더 많은 작업 예시를 보려면 샘플 gitlab.yml
의 cron_jobs
및 ee_cron_jobs
섹션을 참조하십시오.
이러한 설정은 Sidekiq, Webservice(원도우의 툴팁 표시를 위한), Toolbox(디버깅 목적) 포드 사이에서 공유됩니다.
global:
appConfig:
cron_jobs:
stuck_ci_jobs_worker:
cron: "0 * * * *"
pipeline_schedule_worker:
cron: "19 * * * *"
expire_build_artifacts_worker:
cron: "*/7 * * * *"
Sentry 설정
GitLab 에러 보고를 Sentry와 함께 사용하려면 이 설정을 사용하십시오.
global:
appConfig:
sentry:
enabled:
dsn:
clientside_dsn:
environment:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
enabled
| 부울 | false
| 통합을 활성화 또는 비활성화 |
dsn
| 문자열 | 백엔드 오류를 위한 Sentry DSN | |
clientside_dsn
| 문자열 | 프론트엔드 오류를 위한 Sentry DSN | |
environment
| 문자열 | Sentry 환경 참조 |
gitlab_docs
설정
이 설정을 사용하여 gitlab_docs
를 활성화합니다.
global:
appConfig:
gitlab_docs:
enabled:
host:
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
enabled
| 부울 | false
|
gitlab_docs 를 활성화 또는 비활성화
|
host
| 문자열 | ”” | 문서 호스트 |
스마트카드 인증 설정
global:
appConfig:
smartcard:
enabled: false
CASecret:
clientCertificateRequiredHost:
sanExtensions: false
requiredForGitAccess: false
이름 | 타입 | 기본값 | 설명 |
---|---|---|---|
enabled
| 부울 | false
| 스마트카드 인증을 활성화 또는 비활성화 |
CASecret
| 문자열 | CA 인증서를 포함하는 시크릿명 | |
clientCertificateRequiredHost
| 문자열 | 스마트카드 인증에 사용할 호스트명. 기본적으로 제공된 또는 계산된 스마트카드 호스트명이 사용됩니다. | |
sanExtensions
| 부울 | false
| 사용자와 인증서를 일치시키기 위해 SAN 확장 사용 여부 |
requiredForGitAccess
| 부울 | false
| Git 접근을 위해 스마트카드 로그인을 브라우저 세션에 필수로 설정. |
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
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
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’s Bootsnap Gem을 사용합니다. 여기서의 설정은 그 동작을 구성하는 데 사용됩니다.
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을 참조하세요. |
Port
Ingress가 사용하는 포트 및 GitLab이 제공하는 SSH URL에서 사용되는 포트를 제어할 수 있습니다. global.shell.port
에서 사용됩니다. 이것은 서비스가 수신하는 포트와 프로젝트 UI에서 제공되는 SSH 클론 URL에 반영됩니다.
global:
shell:
port: 32022
global.shell.port
와 nginx-ingress.controller.service.type=NodePort
를 결합하여 NGINX 컨트롤러 Service 객체에 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가 연결을 올바르게 처리하도록 할 수 있습니다.
프록시 프로토콜 처리를 활성화해야 하는 일반적인 환경 중 하나는 클러스터로의 들어오는 연결을 처리하는 ELB를 사용하는 AWS 환경입니다. 올바르게 설정하려면 AWS layer 4 loadbalancer example를 참조하세요.
global:
shell:
tcp:
proxyProtocol: true # 기본값 false
GitLab 페이지 구성
다른 차트에서 사용되는 전역 GitLab 페이지 설정은 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:
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
enabled
| 부울 | False | 클러스터에 GitLab 페이지 차트를 설치할지 여부를 결정합니다. |
accessControl
| 부울 | False | GitLab 페이지 액세스 제어를 활성화합니다. |
path
| 문자열 | /srv/gitlab/shared/pages
| 페이지 배포 관련 파일이 저장될 경로입니다. 참고: 기본적으로 사용되지 않으며, 오브젝트 스토리지가 사용됩니다. |
host
| 문자열 | 페이지 루트 도메인입니다. | |
port
| 문자열 | UI에서 페이지 URL을 구성하는 데 사용될 포트입니다. 설정되지 않으면, 페이지의 HTTPS 상황에 따라 80 또는 443의 기본값이 설정됩니다. | |
https
| 부울 | True | GitLab UI에서 페이지의 HTTPS URL을 표시해야 하는지 여부를 나타냅니다. global.hosts.pages.https 및 global.hosts.https 보다 우선합니다. 기본적으로 True로 설정됩니다.
|
externalHttp
| 목록 | []
| 페이지 데몬에 도달하는 HTTP 요청의 IP 주소 목록입니다. 사용자 정의 도메인을 지원하기 위해 필요합니다. |
externalHttps
| 목록 | []
| 페이지 데몬에 도달하는 HTTPS 요청의 IP 주소 목록입니다. 사용자 정의 도메인을 지원하기 위해 필요합니다. |
artifactsServer
| 부울 | True | GitLab 페이지에서 아티팩트 보기를 활성화합니다. |
objectStore.enabled
| 부울 | True | 페이지에 대한 오브젝트 스토리지 사용을 활성화합니다. |
objectStore.bucket
| 문자열 | gitlab-pages
| 페이지 관련 컨텐츠를 저장하는 데 사용될 버킷입니다. |
objectStore.connection.secret
| 문자열 | 오브젝트 스토리지의 연결 세부 정보를 포함하는 시크릿입니다. | |
objectStore.connection.key
| 문자열 | 연결 세부 정보가 저장된 시크릿 내의 키입니다. | |
localStore.enabled
| 부울 | False | 페이지 관련 컨텐츠에 로컬 스토리지 사용을 활성화합니다 (오브젝트 스토리지와 대비됨). |
localStore.path
| 문자열 | /srv/gitlab/shared/pages
| 페이지 파일이 저장될 경로입니다. localStore가 true로 설정된 경우에만 사용됩니다. |
apiSecret.secret
| 문자열 | Base64로 인코딩된 32비트 API 키를 포함하는 시크릿입니다. | |
apiSecret.key
| 문자열 | API 키가 저장된 시크릿 내의 키입니다. |
웹 서비스 구성
다른 차트에서도 사용되는 전역 웹 서비스 설정은 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 인증서를 사용할 때와 같이 사용자 정의 인증 기관을 추가해야 할 수 있습니다. 이러한 기능을 제공하기 위해 애플리케이션에 이러한 사용자 정의 루트 인증 기관을 시크릿 또는 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 # 특정 ConfigMap의 지정된 키만 마운트
keys:
- unique_name_1.crt
- unique_name_2.crt
참고:
Secret의 키 이름에 .crt
확장자는 Debian update-ca-certificates 패키지에 중요합니다.
이 단계는 사용자 정의 CA 파일이 해당 확장명으로 마운트되고 Certificates initContainers에서 처리되도록 합니다.
이전에는 Alpine 기반이었던 인증서 도우미 이미지인 경우 실제로 확장명이 필요하지 않았습니다. (문서에는 필요하다고 나와 있지만)
UBI 기반의 update-ca-trust
유틸리티는 동일한 요구 사항이 없는 것으로 보입니다.
Secret 또는 ConfigMap을 제공할 수 있으며, 각각의 키에는 PEM으로 인코딩된 CA 인증서를 보유하는 임의의 수의 시크릿 또는 ConfigMap을 구성할 수 있습니다. 이들은 global.certificates.customCAs
의 항목으로 구성됩니다. 모든 시크릿 및 ConfigMap의 모든 키가 고유해야 합니다. 시크릿 및 ConfigMap은 모든 형식의 이름을 가질 수 있지만 키 이름이 충돌해서는 안 됩니다.
애플리케이션 리소스
GitLab은 옵션으로 애플리케이션 리소스를 포함할 수 있으며, 클러스터 내에서 GitLab 애플리케이션을 식별하는 데 사용될 수 있습니다. 클러스터에 애플리케이션 CRD 버전 ‘v1beta1’이 이미 배포되어 있어야 합니다.
활성화하려면 global.application.create
를 true
로 설정하세요:
global:
application:
create: true
Google GKE Marketplace와 같은 일부 환경에서는 ClusterRole 리소스의 생성이 허용되지 않을 수 있습니다. Application Custom Resource Definition 및 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 빌드를 지원하며 다른 이미지와 레이어를 공유합니다. 이제 폐기된 busybox 이미지를 대체합니다.
참고:
사용자 정의 busybox 설정이 정의된 경우 차트는 레거시 busybox로 변경됩니다. 이 busybox
구성 후퇵은 최종적으로 제거될 예정입니다. 설정을 global.gitlabBase
로 마이그레이션하세요.
서비스 계정
GitLab Helm 차트를 사용하면 각각의 서비스 계정을 사용하여 파드를 실행할 수 있습니다. 이는 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.serviceAccount.create=true
을 사용하여 global.serviceAccount.name
과 함께 사용하지 마세요. 같은 이름을 가진 여러 ServiceAccount 객체를 생성하도록 차트에 지시하는 것입니다. 전역 이름을 지정하는 경우 대신에 global.serviceAccount.create=false
를 사용하세요.
어노테이션
사용자 정의 어노테이션은 배포, 서비스 및 인그레스 객체에 적용할 수 있습니다.
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 컴포넌트 서브차트만이 이러한 추가 라벨을 받게 됩니다.
파드
다양한 배포 및 작업에 사용자 정의 레이블을 적용할 수 있습니다. 이러한 보충 레이블은 이 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
은 파드의 모든 컨테이너에 다른 데이터 출처에서 추가 환경 변수를 노출시킬 수 있습니다. 추가 환경 변수는 globabl
레벨(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
# optional: boolean
참고:
구현은 서로 다른 콘텐츠 유형을 가진 같은 이름의 값을 재사용하지 않습니다. 비슷한 콘텐츠로 동일한 이름을 재정의할 수 있지만, secretKeyRef
, configMapKeyRef
등과 같이 다른 출처를 혼합해서 사용할 수 없습니다.
OAuth 설정 구성
OAuth 통합은 지원하는 서비스에 대해 즉시 구성됩니다. global.oauth
에서 지정된 서비스는 배포 중 GitLab에 OAuth 클라이언트 응용 프로그램으로 자동 등록됩니다. 기본적으로 이 목록에는 GitLab Pages가 포함되어 있습니다(액세스 제어가 활성화된 경우).
global:
oauth:
gitlab-pages: {}
# secret
# appid
# appsecret
# redirectUri
# authScope
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
secret
| 문자열 | 서비스의 OAuth 자격 증명이 포함된 시크릿의 이름. | |
appIdKey
| 문자열 | 서비스의 앱 ID가 저장된 시크릿 내의 키. 기본값은 appid 입니다.
| |
appSecretKey
| 문자열 | 서비스의 앱 비밀이 저장된 시크릿 내의 키. 기본값은 appsecret 입니다.
| |
redirectUri
| 문자열 | 권한 부여 성공 후 사용자가 리디렉션될 URI. | |
authScope
| 문자열 | api
| GitLab API와의 인증에 사용되는 스코프. |
자세한 내용은 비밀 문서를 확인하세요.
Kerberos
GitLab Helm 차트에서 Kerberos 통합을 구성하려면, GitLab 호스트를 위한 서비스 주체를 포함하는 Kerberos 키탭이 포함된 시크릿을 global.appConfig.kerberos.keytab.secret
설정에 제공해야 합니다. 키탭 파일이 없는 경우 Kerberos 관리자에게 도움을 요청할 수 있습니다.
다음 스니펫을 사용하여 시크릿을 생성할 수 있습니다(gitlab
네임스페이스에 차트를 설치하고 gitlab.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 차트는 여전히 툴박스, Sidekiq 및 webservice 파드에 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은 HTTP 프로토콜을 사용할 때 Git 작업을 위해 전용 Kerberos 협상을 위한 전용 포트를 지원하며, 해당 포트를 사용하여 기본 인증으로 떨어지는 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에서 해제되고 구성됩니다.
참고:
현재 우리의 nginx-ingress
Helm 차트 포크에 제한이 있어서 dedicatedPort
를 지정하면 현재 차트의 nginx-ingress
컨트롤러에서 해당 포트를 노출시키지 않습니다. 클러스터 운영자는 해당 포트를 직접 노출해야 합니다. 자세한 내용 및 잠재적인 해결책은 이 차트 issue를 따르세요.
LDAP 사용자 지정 허용된 영역
global.appConfig.kerberos.simpleLdapLinkingAllowedRealms
를 사용하여 사용자의 LDAP DN이 사용자의 Kerberos 영역과 일치하지 않을 때 LDAP와 Kerberos 식별을 함께 연결하는 데 사용할 수 있습니다. 추가 정보는 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를 사용하면 노드 레이블 또는 이미 실행 중인 팟의 레이블을 기반으로 팟이 예약될 수 있는 노드를 제약할 수 있습니다. 이를 통해 클러스터 전체에 팟을 분산하거나 특정 노드를 선택하여 더 강력한 내성을 제공할 수 있습니다.
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 참조 자료: 팟 간 안티-어피니티
Pod 우선순위 및 선점
Pod 우선순위는 global.priorityClassName
또는 priorityClassName
을 통해 전역적으로 또는 하위 차트별로 구성할 수 있습니다.
Pod 우선순위를 설정하면 스케줄러에게 낮은 우선순위 Pod를 비우고 보류 중인 Pod를 스케줄링할 수 있도록 하는 지시를 할 수 있습니다.
global:
priorityClassName: system-cluster-critical
이름 | 유형 | 기본값 | 설명 |
---|---|---|---|
priorityClassName
| 문자열 | Pod에 할당된 우선순위 클래스. |
로그 로테이션
기본적으로, GitLab Helm 차트는 로그를 로테이션하지 않습니다. 이는 오랜 시간 실행되는 컨테이너들에 대하여 순간적인 저장소 문제를 일으킬 수 있습니다.
로그 로테이션을 활성화하려면 GITLAB_LOGGER_TRUNCATE_LOGS
환경 변수를 true
로 설정하십시오. 자세한 정보는
GitLab Logger의 문서를 참조하십시오. 특히,
다음 정보를 확인하십시오: