GitLab 차트 사전 요구 사항
GitLab을 Kubernetes 클러스터에 배포하기 전에 다음 사전 요구 사항을 설치하고 설치할 때 사용할 옵션을 결정하세요.
사전 요구 사항
kubectl
Kubernetes 문서를 참고하여 kubectl
을 설치하세요.
설치하는 버전은 클러스터에서 실행 중인 버전과 마이너 릴리스 내에 있어야 합니다.
Helm
Helm 문서를 참고하여 Helm v3.9.4 이상을 설치하세요.
PostgreSQL
기본적으로 GitLab 차트에는 클러스터 내 PostgreSQL 배포가 포함되어 있으며 bitnami/PostgreSQL
에서 제공됩니다.
이 배포는 평가용으로만 제공되며 운영 환경에서 사용하기에는 권장하지 않습니다.
외부 운영 준비가 된 PostgreSQL 인스턴스를 설정해야 합니다. GitLab 차트 6.0부터는 PostgreSQL 13이 권장 기본 버전입니다.
GitLab 차트 4.0.0부터는 복제가 내부에서 가능하지만 기본적으로 활성화되어 있지 않습니다. 해당 기능은 GitLab에서 로드 테스트되지 않았습니다.
Redis
기본적으로 GitLab 차트에는 클러스터 내 Redis 배포가 포함되어 있으며 bitnami/Redis
에서 제공됩니다.
이 배포는 평가용으로만 제공되며 운영 환경에서 사용하기에는 권장하지 않습니다.
외부 운영 준비가 된 Redis 인스턴스를 설정해야 합니다. 모든 사용 가능한 구성 설정에 대해서는 Redis 글로벌 문서를 참조하세요.
GitLab 차트 4.0.0부터는 복제가 내부에서 가능하지만 기본적으로 활성화되어 있지 않습니다. 해당 기능은 GitLab에서 로드 테스트되지 않았습니다.
기타 옵션 결정
GitLab을 배포할 때 helm install
과 함께 다음 옵션을 사용합니다.
Secrets
기본적으로 배포 중에 SSH 키와 같은 일부 시크릿이 자동으로 생성되지만, 직접 지정하려면 시크릿 문서를 참고하세요.
네트워킹 및 DNS
기본적으로 GitLab은 Ingress
객체로 구성된 이름 기반 가상 서버를 사용하여 서비스를 노출합니다.
이러한 객체는 type: LoadBalancer
인 Kubernetes Service
객체입니다.
차트에 대한 올바른 IP 주소로 해석할 레코드가 포함된 도메인을 지정해야 합니다.
예를 들어, helm install
과 함께 다음을 사용하세요:
--set global.hosts.domain=example.com
…
Istio 프로토콜 선택과의 호환성
서비스 포트 이름은 Istio의 명시적 포트 선택과 호환되는 규칙을 따릅니다. 이는 <프로토콜>-<접미어>
형식을 갖습니다. 예를 들어 tls-gitaly
나 https-metrics
와 같은 형태입니다.
참고로, Gitaly와 KAS는 gRPC를 사용하지만 이슈 #3822와 이슈 #4908에서의 조사 결과로 인해 tcp
접두어를 사용하고 있습니다.
지속성
기본적으로 GitLab 차트는 동적 프로비저너가 배경에서 지속적인 볼륨을 만들도록 하는 볼륨 클레임을 생성합니다. storageClass
를 사용자 정의하거나 수동으로 볼륨을 생성하고 할당하려면 스토리지 문서를 검토하세요.
참고: 초기 배포 후에 스토리지 설정을 변경하려면 Kubernetes 객체를 수동으로 편집해야 합니다. 따라서 생산 환경에 배포하기 전에 추가 스토리지 이동 작업을 피하기 위해 미리 계획을 세우는 것이 가장 좋습니다.
TLS 인증서
HTTPS로 GitLab을 실행해야 하며, 이를 위해 TLS 인증서가 필요합니다. 기본적으로 GitLab 차트는 무료 TLS 인증서를 얻기 위해 cert-manager
를 설치하고 구성합니다.
자체 와일드카드 인증서가 있는 경우, 또는 이미 cert-manager
가 설치된 경우, 또는 다른 방법으로 TLS 인증서를 획들할 수 있는 경우 TLS 옵션에 대해 더 읽어보세요.
기본 구성에는 TLS 인증서를 등록하기 위해 이메일 주소를 지정해야 합니다. 예를 들어 다음과 같이 helm install
을 사용하세요:
--set certmanager-issuer.email=me@example.com
Prometheus
우리는 상위 Prometheus 차트를 사용하며, Kubernetes API 및 GitLab 차트에서 생성된 객체의 메트릭 수집을 제한하기 위해 고유한 prometheus.yml
파일 이외에 자체 기본값을 재정의하지 않습니다. 그러나 기본적으로 alertmanager
, nodeExporter
, pushgateway
를 비활성화합니다.
prometheus.yml
파일은 Prometheus가 gitlab.com/prometheus_scrape
어노테이션을 가진 리소스로부터 메트릭을 수집하도록 지시합니다. 또한 gitlab.com/prometheus_path
와 gitlab.com/prometheus_port
어노테이션은 메트릭을 발견하는 방법을 구성하는 데 사용할 수 있습니다. 이러한 각 어노테이션은 prometheus.io/{scrape,path,port}
어노테이션과 비교 가능합니다.
Prometheus를 통해 GitLab 애플리케이션을 모니터링하거나 모니터링하려는 경우, 기존 사용자를 위해 일부 기본 prometheus.io/*
어노테이션이 여전히 해당하는 Pod 및 서비스에 추가됩니다. 이는 기존 사용자에 대한 메트릭 수집의 연속성을 유지하고 Kubernetes 클러스터에서 실행 중인 기존 응용 프로그램 및 GitLab 애플리케이션 메트릭을 모두 캡처하는 데 사용되는 기본 Prometheus 구성을 제공합니다.
상세한 구성 옵션 목록 및 이를 requirement chart로 사용하기 때문에, 이 요구 사항 차트를 사용하고 있는지 상위 Prometheus 차트 설명서를 참조하세요.
예를 들어, 지속적인 저장소 요청은 다음과 같이 제어될 수 있습니다:
prometheus:
alertmanager:
enabled: false
persistentVolume:
enabled: false
size: 2Gi
pushgateway:
enabled: false
persistentVolume:
enabled: false
size: 2Gi
server:
persistentVolume:
enabled: true
size: 8Gi
TLS 활성화된 엔드포인트의 Prometheus 스크랩 구성
만약 주어진 익스포터가 TLS를 허용하고 차트 구성이 익스포터의 엔드포인트에 대한 TLS 구성을 노출하는 경우, Prometheus는 TLS 활성화된 엔드포인트에서 메트릭을 스크랩하도록 구성할 수 있습니다.
Prometheus 스크래이프 구성의 경우 TLS 및 쿠버네티스 서비스 디스커버리를 사용할 때 몇 가지 주의사항이 있습니다:
- Pod 및 서비스 엔드포인트 디스커버리 역할에 대해 Prometheus는 스크랩 대상의 내부 IP 주소를 설정하기 위해 Pod의 내부 IP 주소를 사용합니다. TLS 인증서를 검증하려면, Prometheus는 메트릭 엔드포인트에 대해 생성된 인증서에서 설정된 공통 이름 (CN) 또는 Subject Alternative Name (SAN) 확장에 포함된 이름 중 하나를 구성해야 합니다. 해당 이름은 해결될 필요가 없으며 유효한 DNS 이름이어야 합니다.
- 익스포터 엔드포인트에 사용된 인증서가 자체 서명 또는 기본 이미지에 존재하지 않은 경우, Prometheus 팟은 익스포터 엔드포인트에 사용된 인증서를 서명한 인증 기관 (CA)의 인증서를 마운트해야 합니다. Prometheus는 베이스 이미지의 Debian ca-bundle을 사용합니다.
- Prometheus는 이러한 항목 모두를 각 스크래이프 구성에 적용하는 tls_config을 지원합니다. 스크래이프 구성에 대한
tls_config.server_name
및tls_config.ca_file
을 설정하려면relabel_config
를 사용하는 것은 불가능합니다. 더 많은 세부 정보는 이 Prometheus 프로젝트 이슈를 참조하세요.
위의 주의사항을 고려하면, 가장 간단한 구성은 모든 익스포터 엔드포인트에 사용되는 “이름”과 CA를 공유하는 것입니다:
-
tls_config.server_name
에 사용할 단일 임의의 이름 선택(예:metrics.gitlab
)합니다. - Pod/엔드포인트
스크래이프 구성
역할에 사용되는 모든 인증서의 SAN 목록에 해당 이름 추가합니다. - 모든 인증서를 동일한 CA에서 발급합니다.
- CA 인증서를 클러스터 시크릿으로 추가합니다.
- Prometheus 서버 컨테이너에 해당 시크릿을
extraSecretMounts
구성을 사용하여 마운트합니다. - Prometheus의
scrape_config
에 대한tls_config.ca_file
으로 설정합니다.
- Pod/엔드포인트
스크래이프 구성
역할에tls_config.server_name
을metrics.gitlab
로 설정합니다. - 모든 익스포터 엔드포인트에 사용된 각 인증서에
metrics.gitlab
가 SAN 목록에 추가되었다고 가정합니다. - CA 인증서가
metrics.gitlab.tls-ca
로 이름 지어진 클러스터 시크릿으로 추가되고, 동일한 네임스페이스에 생성되었다고 가정합니다. (예:kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem
) -
extraSecretMounts:
항목을 사용하여metrics.gitlab.tls-ca
시크릿을/etc/ssl/certs/metrics.gitlab.tls-ca
에 마운트합니다. -
tls_config.ca_file
을/etc/ssl/certs/metrics.gitlab.tls-ca
로 설정합니다.
Exporter endpoints
GitLab 차트에 포함된 모든 메트릭 엔드포인트가 TLS를 지원하는 것은 아닙니다.
엔드포인트가 TLS로 활성화될 수 있고 그렇게 된 경우, gitlab.com/prometheus_scheme: "https"
어노테이션과
prometheus.io/scheme: "https"
어노테이션을 설정하며, 둘 중 어느 것이든 relabel_config
와 함께 사용하여 Prometheus __scheme__
대상 레이블을 설정할 수 있습니다.
Prometheus TLS 값 예제에는 relabel_config
가 포함되어 있으며, gitlab.com/prometheus_scheme: "https"
어노테이션을 사용하여 __scheme__
을 대상으로 지정합니다.
다음 표에는 gitlab.com/prometheus_scrape: true
어노테이션이 적용된 배치(또는 Gitaly와 Praefect 중 하나 이상을 사용할 때: StatefulSets) 및 서비스 엔드포인트가 나열되어 있습니다.
아래 문서 링크에서, 컴포넌트가 SAN 항목을 추가하는 것을 언급하는 경우, Prometheus tls_config.server_name
으로 사용하려고 결정한 SAN도 추가하는지 확인하세요.
서비스 | 메트릭 포트(기본) | TLS 지원 여부 | 참고/문서/이슈 |
---|---|---|---|
Gitaly | 9236 | YES |
global.gitaly.tls.enabled=true 을 사용하여 활성화됨 기본 시크릿: RELEASE-gitaly-tls 문서: TLS로 Gitaly 실행하기 |
GitLab Exporter | 9168 | YES |
gitlab.gitlab-exporter.tls.enabled=true 을 사용하여 활성화됨 기본 시크릿: RELEASE-gitlab-exporter-tls
|
GitLab Pages | 9235 | YES |
gitlab.gitlab-pages.metrics.tls.enabled=true 을 사용하여 활성화됨 기본 시크릿: RELEASE-pages-metrics-tls 문서: 일반 설정 |
GitLab Runner | 9252 | NO | 이슈 - 메트릭 엔드포인트에 대한 TLS 지원 추가 |
GitLab Shell | 9122 | NO | GitLab Shell 메트릭 익스포터는 gitlab-sshd 을 사용할 때에만 활성화됩니다. TLS가 필요한 환경에서는 OpenSSH를 권장합니다
|
KAS | 8151 | YES |
global.kas.customConfig.observability.listen.certificate_file 및 global.kas.customConfig.observability.listen.key_file 옵션을 사용하여 구성 가능
|
Praefect | 9236 | YES |
global.praefect.tls.enabled=true 을 사용하여 활성화됨 기본 시크릿: RELEASE-praefect-tls 문서: TLS로 Praefect 실행하기 |
Registry | 5100 | YES |
registry.debug.tls.enabled=true 을 사용하여 활성화됨 문서: 디버그 포트에 대한 TLS 구성 |
Sidekiq | 3807 | YES |
gitlab.sidekiq.metrics.tls.enabled=true 을 사용하여 활성화됨 기본 시크릿: RELEASE-sidekiq-metrics-tls 문서: 설치 명령줄 옵션 |
Webservice | 8083 | YES |
gitlab.webservice.metrics.tls.enabled=true 을 사용하여 활성화됨 기본 시크릿: RELEASE-webservice-metrics-tls 문서: 설치 명령줄 옵션 |
Ingress-NGINX | 10254 | NO | 메트릭/헬스체크 포트에서는 TLS를 지원하지 않음 |
웹서비스 파드의 경우, 노출된 포트는 웨브릭 익스포터입니다. 워크호스 컨테이너 포트는 스크랩되지 않습니다. 자세한 내용은 웹서비스 메트릭 문서를 참조하세요.
발신 이메일
기본적으로 발신 이메일은 비활성화되어 있습니다. 활성화하려면 global.smtp
및 global.email
설정을 사용하여 SMTP 서버에 대한 세부 정보를 제공하십시오. 이러한 설정의 자세한 내용은 명령줄 옵션에서 찾을 수 있습니다.
SMTP 서버가 인증을 필요로 하는 경우, 비밀 코드 문서의 패스워드 제공 섹션을 꼭 확인하십시오.
--set global.smtp.authentication=""
을(를) 사용하여 인증 설정을 비활성화할 수 있습니다.
만약 Kubernetes 클러스터가 GKE에 있다면, SMTP 포트 25가 차단되어 있음을 유의하십시오.
수신 이메일
수신 이메일의 구성은 mailroom 차트에 문서화되어 있습니다.
서비스 데스크 이메일
서비스 데스크 이메일의 구성은 mailroom 차트에 문서화되어 있습니다.
RBAC
GitLab 차트는 기본적으로 RBAC을(를) 생성하고 사용합니다. 클러스터에 RBAC이 활성화되어 있지 않은 경우, 다음 설정을 비활성화해야 합니다:
--set certmanager.rbac.create=false
--set nginx-ingress.rbac.createRole=false
--set prometheus.rbac.create=false
--set gitlab-runner.rbac.create=false
다음 단계
클라우드 공급업체 설정 및 클러스터 생성를 진행해주세요.