• 준비 사항
  • kubectl
  • Helm
  • PostgreSQL
  • Redis
  • Gitaly
• 다른 옵션 결정
  • Secrets
  • 네트워킹 및 DNS
    • external-dns를 사용하여 동적 IP 주소
    • 정적 IP 주소
    • Istio 프로토콜 선택과의 호환성
  • 지속성
  • TLS 인증서
  • Prometheus
    • TLS 활성화 엔드포인트 스크랩 설정
    • Exporter endpoints
  • 발신 이메일
  • 수신 이메일
  • 서비스 데스크 이메일
  • RBAC
• 다음 단계

GitLab 차트 준비 사항

Kubernetes 클러스터에 GitLab을 배포하기 전에, 다음을 설치하고 설치할 때 사용할 옵션을 결정하세요.

준비 사항

kubectl

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

Helm

Helm 문서를 참고하여 Helm v3.10.3 이상을 설치하세요.

PostgreSQL

기본적으로 GitLab 차트에는 시험용으로 제공되는 클러스터 내 PostgreSQL 배포가 포함되어 있습니다. 이 배포는 운영 환경에서 사용을 권장하지 않습니다.

외부, 운영 준비가 된 PostgreSQL 인스턴스를 설정해야 합니다. 권장하는 기본 버전:

• GitLab 차트 6.0부터 PostgreSQL 13.
• GitLab 차트 8.0부터 PostgreSQL 14.

GitLab 차트 4.0.0부터 복제는 내부적으로 사용 가능하지만 기본적으로 비활성화되어 있습니다. 이러한 기능은 GitLab에서 로드 테스트되지 않았습니다.

Redis

기본적으로 GitLab 차트에는 시험용으로 제공되는 클러스터 내 Redis 배포가 포함되어 있습니다. 이 배포는 운영 환경에서 사용을 권장하지 않습니다.

외부, 운영 준비가 된 Redis 인스턴스를 설정해야 합니다. 사용 가능한 모든 구성 설정은 Redis 글로벌 문서를 참조하세요.

GitLab 차트 4.0.0부터 복제는 내부적으로 사용 가능하지만 기본적으로 비활성화되어 있습니다. 이러한 기능은 GitLab에서 로드 테스트되지 않았습니다.

Gitaly

기본적으로 GitLab 차트에는 클러스터 내부에서 Gitaly 배포가 포함되어 있습니다. Kubernetes에서 운영 중인 Gitaly는 지원되지 않습니다. Gitaly는 전통적인 가상 머신에서만 지원됩니다.

외부, 운영 준비가 된 Gitaly 인스턴스를 설정해야 합니다. 사용 가능한 모든 구성 설정은 Gitaly 글로벌 문서를 참조하세요.

다른 옵션 결정

GitLab을 배포할 때 helm install과 함께 다음 옵션을 사용합니다.

Secrets

SSH 키와 같은 일부 비밀을 생성해야 합니다. 기본적으로 배포 중에 이러한 비밀은 자동으로 생성되지만, 지정하려면 비밀 문서를 참고하세요.

네트워킹 및 DNS

기본적으로 GitLab은 Ingress 객체로 구성된 이름 기반 가상 서버를 사용하여 서비스를 노출합니다. 이러한 객체는 type: LoadBalancer인 Kubernetes Service 객체입니다.

차트에 맞는 IP 주소로 gitlab, registry, minio를 해결할 레코드가 포함된 도메인을 지정해야 합니다.

예를 들어, 다음을 helm install과 함께 사용하세요: shell --set global.hosts.domain=example.com

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

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

external-dns를 사용하여 동적 IP 주소

자동 DNS 등록 서비스인 external-dns를 사용할 계획인 경우, GitLab에 대한 추가적인 DNS 구성이 필요하지 않습니다. 그러나, 클러스터에 external-dns를 배포해야 합니다. 각 지원되는 제공자에 대한 포괄적인 가이드는 프로젝트 페이지에 있습니다.

참고: GitLab Pages에 대한 사용자 정의 도메인 지원을 활성화하면, external-dns는 더 이상 Pages 도메인(기본적으로 pages.<global.hosts.domain>)에 대해 작동하지 않습니다. Pages에 할당된 외부 IP 주소를 도메인에 가리키도록 DNS 항목을 수동으로 구성해야 합니다.

GKE 클러스터를 프로비저닝하는 경우, external-dns가 클러스터에 자동으로 설치됩니다.

정적 IP 주소

DNS 레코드를 수동으로 구성할 계획인 경우, 모두 정적 IP 주소를 가리켜야 합니다. 예를 들어, example.com을 선택하고 정적 IP 주소가 10.10.10.10이면, gitlab.example.com, registry.example.com 및 (미니오를 사용하는 경우) minio.example.com 모두 10.10.10.10로 해결해야 합니다.

GKE를 사용하는 경우, 외부 IP 및 DNS 항목 만들기에서 자세히 읽어보세요. 이 프로세스에 대한 추가 도움을 위해 클라우드 또는 DNS 제공업체 문서를 참고하세요.

예를 들어, 다음을 helm install과 함께 사용하세요: shell --set global.hosts.externalIP=10.10.10.10

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

서비스 포트 이름은 이스티오의 명시적 포트 선택과 호환되는 규칙을 따릅니다. 예를 들어 tls-gitaly 또는 https-metrics와 같이 보입니다.

Gitaly와 KAS는 gRPC를 사용하지만, Issue #3822 및 Issue #4908에서 발견된 바에 따라 tcp 접두사를 사용합니다.

지속성

기본적으로 GitLab 차트는 기대하는 바와 같이 동적 프로비저너가 기본 지속 볼륨을 생성하도록 볼륨 클레임을 만듭니다. storageClass를 사용자 정의하거나 볼륨을 수동으로 만들고 할당하려는 경우, 저장소 문서를 확인하세요.

참고: 처음 배포한 후에 저장소 설정을 변경하면 추가적인 저장소 이전 작업을 피하기 위해 Kubernetes 객체를 수동으로 편집해야 합니다. 따라서 별도의 저장소 이전 작업을 피하려면 본사 인스턴스를 배포하기 전에 미리 계획하는 것이 좋습니다.

TLS 인증서

GitLab을 HTTPS로 실행해야 하며, 이를 위해서는 TLS 인증서가 필요합니다. 기본적으로 GitLab 차트는 무료 TLS 인증서를 얻기 위해 cert-manager를 설치하고 구성합니다.

당신만의 와일드카드 인증서가 있거나 이미 cert-manager가 설치되어 있거나 다른 방법으로 TLS 인증서를 얻을 수 있는 경우 TLS 옵션에 대해 더 읽어보세요.

기본 구성의 경우 TLS 인증서를 등록하려면 이메일 주소를 지정해야 합니다. 예를 들어, 다음과 같이 helm install을 사용하여 지정하세요.

--set certmanager-issuer.email=me@example.com

Prometheus

우리는 상류 Prometheus 차트를 사용하며, 쿠버네티스 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 및 서비스에 여전히 추가됩니다. 이로써 기존 사용자들의 메트릭 수집을 유지하고 쿠버네티스 클러스터에서 실행되는 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 활성화 엔드포인트 스크랩 설정

만약 주어진 익스포터가 TLS를 허용하고 차트 구성이 익스포터의 엔드포인트를 위한 TLS 구성을 노출한다면 Prometheus는 TLS 활성화 엔드포인트로부터 메트릭을 스크랩하도록 구성될 수 있습니다.

프로메테우스는 TLS 및 쿠버네티스 서비스 디스커버리를 사용할 때 몇 가지 주의해야 할 사항들이 있습니다. 예를 들어 포드 및 서비스 엔드포인트 스크랩 구성에서는 Prometheus가 포드의 내부 IP 주소를 스크래핑 대상의 주소로 설정합니다. TLS 인증서를 확인하려면 Prometheus는 메트릭 엔드포인트에 대한 인증서를 위해 발급된 Common Name (CN) 또는 Subject Alternative Name (SAN) 확장에 포함된 이름으로 구성되어야 합니다. 이 이름은 해결될 필요가 없으며 유효한 DNS 이름일 수 있습니다.

만약 익스포터 엔드포인트에 사용된 인증서가 자체 서명되었거나 프로메테우스 기본 이미지에 존재하지 않는 경우, 프로메테우스 팟은 익스포터 엔드포인트에 사용된 인증서를 서명한 인증 기관(CA)에 대한 CA 인증서를 마운트해야 합니다. Prometheus는 기본 이미지에서 Debian의 ca-bundle를 사용합니다.

프로메테우스는 각 스크랩 구성에 적용되는 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. 해당 이름을 익스포터 엔드포인트에 사용된 모든 인증서의 SAN 목록에 추가합니다.
3. 모든 인증서를 동일한 CA에서 발급합니다.
   • CA 인증서를 클러스터 시크릿으로 추가합니다.
   • Prometheus 차트의 extraSecretMounts: 구성을 사용하여 해당 시크릿을 Prometheus 서버 컨테이너에 마운트합니다.
   • 이를 프로메테우스 scrape_config의 tls_config.ca_file로 설정합니다.

프로메테우스 TLS 값 예제에서는 이러한 공유 구성을 위한 예제를 제공합니다.

1. 포드/엔드포인트 scrape_config 역할에 tls_config.server_name을 metrics.gitlab로 설정합니다.
2. metrics.gitlab이 익스포터 엔드포인트에 사용된 모든 인증서의 SAN 목록에 추가되었다고 가정합니다.
3. CA 인증서가 metrics.gitlab.tls-ca라는 시크릿 이름으로 추가되어 있다고 가정합니다. 이 시크릿은 Prometheus 차트가 배포된 동일한 네임스페이스에 생성되었으며(예: kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem), 시크릿 키도 metrics.gitlab.tls-ca로 되어있습니다.
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로 설정합니다.

Exporter endpoints

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 어노테이션이 적용된 배포 (또는 Gitaly와 Praefect를 사용하는 경우: StatefulSets) 및 서비스 엔드포인트를 나열합니다.

아래 문서 링크에서, 구성 요소에서 SAN 항목을 추가해야 한다면 Prometheus tls_config.server_name으로 사용하기로 결정한 SAN도 추가해야 합니다.

Webservice 팟의 경우 노출된 포트는 webservice 컨테이너의 standalone webrick 익스포터입니다. workhorse 컨테이너 포트가 스크랩되지 않습니다. 추가 세부 정보는 Webservice 메트릭 문서를 참조하세요.

발신 이메일

기본적으로 발신 이메일이 비활성화되어 있습니다. 이를 활성화하려면 SMTP 서버에 대한 세부 정보를 global.smtp 및 global.email 설정에 제공하십시오. 이러한 설정에 대한 자세한 내용은 명령줄 옵션에서 찾을 수 있습니다.

SMTP 서버가 인증을 요구하는 경우, 비밀번호 제공에 대한 섹션을 읽으십시오. --set global.smtp.authentication=""로 인증 설정을 비활성화할 수 있습니다.

GKE에서 Kubernetes 클러스터를 사용하는 경우 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

다음 단계

클라우드 공급업체를 설정하고 클러스터를 생성하세요.