GitLab 차트 사전 요구 사항

Tier: Free, Premium, Ultimate Offering: Self-Managed

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-gitalyhttps-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_pathgitlab.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_nametls_config.ca_file을 설정하려면 relabel_config를 사용하는 것은 불가능합니다. 더 많은 세부 정보는 이 Prometheus 프로젝트 이슈를 참조하세요.

위의 주의사항을 고려하면, 가장 간단한 구성은 모든 익스포터 엔드포인트에 사용되는 “이름”과 CA를 공유하는 것입니다:

  1. tls_config.server_name에 사용할 단일 임의의 이름 선택(예: metrics.gitlab)합니다.
  2. Pod/엔드포인트 스크래이프 구성 역할에 사용되는 모든 인증서의 SAN 목록에 해당 이름 추가합니다.
  3. 모든 인증서를 동일한 CA에서 발급합니다.
    • CA 인증서를 클러스터 시크릿으로 추가합니다.
    • Prometheus 서버 컨테이너에 해당 시크릿을 extraSecretMounts 구성을 사용하여 마운트합니다.
    • Prometheus의 scrape_config에 대한 tls_config.ca_file으로 설정합니다.

Prometheus TLS 값 예제는:

  1. Pod/엔드포인트 스크래이프 구성 역할에 tls_config.server_namemetrics.gitlab로 설정합니다.
  2. 모든 익스포터 엔드포인트에 사용된 각 인증서에 metrics.gitlab가 SAN 목록에 추가되었다고 가정합니다.
  3. CA 인증서가 metrics.gitlab.tls-ca로 이름 지어진 클러스터 시크릿으로 추가되고, 동일한 네임스페이스에 생성되었다고 가정합니다. (예: kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem)
  4. extraSecretMounts: 항목을 사용하여 metrics.gitlab.tls-ca 시크릿을 /etc/ssl/certs/metrics.gitlab.tls-ca에 마운트합니다.
  5. 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_fileglobal.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.smtpglobal.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

다음 단계

클라우드 공급업체 설정 및 클러스터 생성를 진행해주세요.