• 선행 조건
  • kubectl
  • Helm
  • PostgreSQL
  • Redis
• 기타 옵션 결정
  • Secrets
  • 네트워킹 및 DNS
    • external-dns를 사용한 동적 IP 주소
    • 정적 IP 주소
    • Istio 프로토콜 선택과의 호환성
  • 지속성
  • TLS 인증서
  • Prometheus
    • TLS 활성화된 엔드포인트를 스크랩하도록 Prometheus 구성
    • 내보내기자 엔드포인트
  • 발신 이메일
  • 수신 이메일
  • 서비스 데스크 이메일
  • RBAC
• 다음 단계

GitLab 차트 선행 조건

Kubernetes 클러스터에서 GitLab을 배포하기 전에 다음 선행 조건을 설치하고 설치할 옵션을 결정하세요.

선행 조건

kubectl

k8s 문서를 참조하여 kubectl을 설치하세요. 설치하는 버전은 클러스터에서 실행 중인 버전과 1개의 마이너 릴리스 내에 있어야 합니다.

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 주소로 gitlab, registry 및 (활성화된 경우) minio를 해석하기 위해 해당 레코드를 포함하는 도메인을 지정해야 합니다.

예를 들어, 다음을 helm install로 사용하세요:

--set global.hosts.domain=example.com

사용자 정의 도메인 지원이 활성화된 경우 기본적으로 <pages 도메인>인 *.<pages 도메인> 서브 도메인은 pages.<global.hosts.domain>이 됩니다. 해당 도메인은 --set global.pages.externalHttp 또는 --set global.pages.externalHttps에 의해 Pages에 할당된 외부 IP로 해석됩니다.

사용자 정의 도메인을 사용하려면, GitLab Pages는 해당 사용자 정의 도메인을 <namespace>.<pages 도메인> 도메인으로 지정하는 CNAME 레코드를 사용할 수 있습니다.

external-dns를 사용한 동적 IP 주소

만약 external-dns와 같은 자동 DNS 등록 서비스를 사용할 계획이라면, GitLab을 위해 추가 DNS 구성이 필요하지 않습니다. 그러나 귀하의 클러스터에 external-dns를 배포해야 합니다. 해당 프로젝트 페이지에는 각 지원되는 제공자에 대한 포괄적인 가이드가 있습니다. 자세한 내용은 프로젝트 페이지를 참고하세요.

만일 제공된 스크립트를 사용하여 GKE 클러스터를 생성한다면, external-dns가 클러스터에 자동으로 설치됩니다.

정적 IP 주소

매뉴얼으로 DNS 레코드를 구성할 계획이라면, 해당 레코드는 모두 정적 IP 주소를 가리켜야 합니다. 예를 들어, example.com을 선택하고 정적 IP 주소가 10.10.10.10이라면, gitlab.example.com, registry.example.com 및 (MinIO를 사용하는 경우) minio.example.com은 모두 10.10.10.10으로 해석되어야 합니다.

GKE를 사용 중이라면 외부 IP 및 DNS 항목 생성에 대해 더 많은 정보를 확인하세요.

상세한 과정 도움을 얻으려면 클라우드 또는 DNS 제공업체의 설명서를 참조하십시오.

예를 들어, helm install과 함께 다음을 사용하십시오:

--set global.hosts.externalIP=10.10.10.10

Istio 프로토콜 선택과의 호환성

서비스 포트 이름은 Istio의 명시적 포트 선택과 호환되는 규칙을 따릅니다. 이들은 <프로토콜>-<접미어>와 같은 모양을 가지며, 예를 들어 tls-gitaly 또는 https-metrics와 같습니다.

Gitaly와 KAS는 gRPC를 사용하지만, 이슈 #3822와 이슈 #4908에서의 결과에 따라 tcp 접두사 대신 사용됩니다.

지속성

기본적으로 GitLab 차트는 기대하는 바와 같이 볼륨 클레임을 생성하고, 이에 기반한 지속성 볼륨은 동적 프로비저너에서 생성되도록 만듭니다. storageClass를 사용자 정의하거나 볼륨을 매뉴얼으로 생성 및 할당하려면 리포지터리 문서를 확인하십시오.

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의 메트릭 수집 범위를 제한하기 위해 자체 기본값을 override하지 않습니다. 그러나 기본적으로 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/* 주석은 여전히 적절한 Pods 및 Services에 추가됩니다. 이를 통해 기존 사용자의 메트릭 수집이 연속적으로 유지되며 기본 Prometheus 구성을 사용하여 Kubernetes 클러스터에서 실행되는 GitLab 애플리케이션 및 기타 응용 프로그램의 메트릭을 모두 캡처할 수 있는 기능을 제공합니다.

전체적인 구성 옵션 디렉터리 및 이를 요구 사항 차트로 사용하는 방법에 대해서는 상위 스트림 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 및 Kubernetes Service Discovery를 사용할 때 몇 가지 주의해야 할 점이 있습니다:

• Pod 및 서비스 엔드포인트 발견 역할에 대해, Prometheus는 스크랩 대상의 주소를 설정하기 위해 Pod의 내부 IP 주소를 사용합니다. TLS 인증서를 확인하려면, Prometheus는 메트릭 엔드포인트에 대해 생성된 인증서의 공통 이름(CN) 또는 Subject Alternative Name (SAN) 확장에 포함된 이름 중 하나로 구성되어야 합니다. 이름은 해결될 필요가 없으며, 유효한 DNS 이름이 될 수 있는 임의의 문자열일 수 있습니다.
• 내보내기자 엔드포인트에 사용된 인증서가 자체 서명되었거나 다른 방법으로 Prometheus 기본 이미지에 존재하지 않는 경우, Prometheus pod은 내보내기자 엔드포인트에 사용된 인증서를 서명한 인증 기관(CA)의 인증서를 마운트해야 합니다. Prometheus는 Debian의 ca-bundle을 기본 이미지에서 사용합니다.
• Prometheus는 스크랩 구성 각각에 적용되는 tls_config를 설정하는 것을 지원합니다. Prometheus는 Pod 주석 및 기타 발견된 속성을 기반으로 Prometheus 대상 라벨을 설정하는 강력한 relabel_config 매커니즘을 가지고 있지만, tls_config.server_name 및 tls_config.ca_file을 relabel_config를 사용하여 설정하는 것은 불가능합니다. 세부 내용은 Prometheus 프로젝트 이슈를 참조하세요.

이러한 주의사항을 고려하면, 가장 간단한 구성은 모든 내보내기자 엔드포인트에 사용된 인증서에 대해 “이름”과 CA를 공유하는 것입니다:

1. tls_config.server_name에 사용하기 위한 단일 임의의 이름을 선택합니다(예: metrics.gitlab).
2. 해당 이름을 내보내기자 엔드포인트를 TLS로 암호화하는 데 사용된 각 인증서의 SAN 디렉터리에 추가합니다.
3. 동일한 CA에서 모든 인증서를 발급하세요:
   • CA 인증서를 클러스터 시크릿으로 추가합니다.
   • Prometheus 서버 컨테이너에 해당 시크릿을 마운트합니다. 이는 Prometheus 차트의 extraSecretMounts: 구성을 사용하여 수행합니다.
   • Prometheus scrape_config의 tls_config.ca_file로 설정합니다.

Prometheus TLS 값 예제는 이러한 공유 구성을 위해 다음과 같은 예제를 제공합니다:

1. tls_config.server_name을 metrics.gitlab로 설정하여 pod/endpoint scrape_config 역할에 대한 설정.
2. metrics.gitlab이 내보내기자 엔드포인트에 사용된 각 인증서의 SAN 디렉터리에 추가되었다고 가정합니다.
3. CA 인증서가 metrics.gitlab.tls-ca라는 이름의 시크릿에 추가되었다고 가정합니다. 또한 이 시크릿 키는 gitlab이 배포된 동일한 네임스페이스에 생성되었다고 가정합니다(예: kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem).
4. metrics.gitlab.tls-ca 시크릿을 /etc/ssl/certs/metrics.gitlab.tls-ca에 extraSecretMounts: 항목을 사용하여 마운트합니다.
5. tls_config.ca_file을 /etc/ssl/certs/metrics.gitlab.tls-ca로 설정합니다.

내보내기자 엔드포인트

GitLab 차트에 포함된 모든 메트릭 엔드포인트가 TLS를 지원하는 것은 아닙니다. 엔드포인트가 TLS로 활성화가 가능하고 활성화된 경우, gitlab.com/prometheus_scheme: "https" 및 prometheus.io/scheme: "https" 주석이 설정됩니다. 이 둘 중 어느 것이든 사용할 수 있으며, relabel_config를 사용하여 Prometheus __scheme__ 대상 라벨을 설정할 수 있습니다. Prometheus TLS 값 예제는 gitlab.com/prometheus_scheme: "https" 주석을 사용하는 relabel_config를 포함합니다.

다음 표는 gitlab.com/prometheus_scrape: true 주석이 적용된 Deployments(또는 Gitaly 및 Praefect 중 하나 또는 모두를 사용하는 경우: StatefulSets) 및 서비스 엔드포인트를 나열합니다.

아래의 링크에서 모듈이 SAN 항목을 추가하는 것이 언급된 경우, Prometheus tls_config.server_name으로 사용하기로 결정한 SAN도 추가하는지 확인하십시오.

webservice 파드에서 노출된 포트는 webservice 컨테이너의 독립형 webrick 내보내기자입니다. workhorse 컨테이너 포트는 스크랩되지 않습니다. 추가 정보는 Webservice Metrics 문서를 참조하십시오.

발신 이메일

기본적으로, 발신 이메일은 비활성화되어 있습니다. 이를 활성화하려면 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

다음 단계

클라우드 제공업체 설정 및 클러스터 생성을(를) 설정하세요.