• 알려진 제한 사항 및 문제점
• 요구 사항
• 구성
  • 레플리카
  • 여러 가상 저장소
  • 지속성
• defaultReplicationFactor
  • Praefect로 이동
  • 데이터베이스 생성
  • TLS를 통한 Praefect 실행
  • 설치 명령줄 옵션

Praefect 차트 사용

경고: Praefect 차트는 아직 개발 중입니다. 알파 버전은 아직 제품 사용에 적합하지 않습니다. 업그레이드에는 중요한 수동 개입이 필요할 수 있습니다. 자세한 내용은 Praefect GA 릴리스 Epic를 참조하십시오.

Praefect 차트는 Helm 차트로 배포된 GitLab 설치 내에서 Gitaly 클러스터를 관리하는 데 사용됩니다.

알려진 제한 사항 및 문제점

1. 데이터베이스는 수동으로 생성해야 합니다.
2. 클러스터 크기는 고정되어 있습니다: Gitaly 클러스터는 현재 오토스케일링을 지원하지 않습니다.
3. 클러스터 내의 Praefect 인스턴스를 사용하여 클러스터 외부의 Gitaly 인스턴스를 관리하는 것은 지원되지 않습니다.
4. 차트의 버전 4.8 (GitLab 13.8)로 업그레이드하면 저장소 데이터가 손실된 것으로 보이는 문제가 발생합니다. 데이터는 손실되지 않지만 수동 개입이 필요합니다 (해결 방법).

요구 사항

이 차트는 Gitaly 차트에서 데이터를 소비합니다. 이 차트로 생성된 인스턴스를 구성하는 데 global.gitaly의 설정이 사용됩니다. 이러한 설정의 설명은 Gitaly 차트 문서에서 찾을 수 있습니다.

중요 사항: global.gitaly.tls는 global.praefect.tls와 독립적입니다. 이들은 별도로 구성됩니다.

기본적으로 이 차트는 3개의 Gitaly 레플리카를 생성합니다.

구성

차트는 기본적으로 비활성화되어 있습니다. 차트 배포의 일환으로 활성화하려면 global.praefect.enabled=true를 설정하십시오.

레플리카

배포할 기본 레플리카 수는 3입니다. 원하는 레플리카 수로 변경하려면 global.praefect.virtualStorages[].gitalyReplicas를 설정하십시오. 예:

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1

여러 가상 저장소

여러 가상 저장소를 구성할 수 있습니다 (Gitaly 클러스터 문서 참조). 예:

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2

이렇게 하면 Gitaly를 위한 두 종류의 리소스가 생성됩니다. 이에는 두 가지 Gitaly StatefulSet(가상 저장소 당 하나씩)이 포함됩니다.

그런 다음 관리자는 새 저장소를 저장하는 위치를 구성할 수 있습니다.

지속성

가상 저장소별로 지속성 구성이 가능합니다.

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
      persistence:
        enabled: true
        size: 50Gi
        accessMode: ReadWriteOnce
        storageClass: storageclass1
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2
      persistence:
        enabled: true
        size: 100Gi
        accessMode: ReadWriteOnce
        storageClass: storageclass2

defaultReplicationFactor

defaultReplicationFactor는 각 가상 저장소에서 구성할 수 있습니다. (자세한 내용은 복제 요소 구성 문서 참조).

global:
  praefect:
    enabled: true
    virtualStorages:
    - name: default
      gitalyReplicas: 5
      maxUnavailable: 2
      defaultReplicationFactor: 3
    - name: secondary
      gitalyReplicas: 4
      maxUnavailable: 1
      defaultReplicationFactor: 2

Praefect로 이동

참고: 현재 그룹 수준 위키는 API를 사용하여 이동할 수 없습니다.

독립형 Gitaly 인스턴스에서 Praefect 설정으로 마이그레이션할 때 global.praefect.replaceInternalGitaly를 false로 설정할 수 있습니다. 이렇게 하면 기존 Gitaly 인스턴스가 보존되고 새 Praefect로 관리되는 Gitaly 인스턴스가 생성됩니다.

global:
  praefect:
    enabled: true
    replaceInternalGitaly: false
    virtualStorages:
    - name: virtualStorage2
      gitalyReplicas: 5
      maxUnavailable: 2

참고: Praefect로 마이그레이션할 때 Praefect의 가상 저장소 중 하나도 default로 이름을 지을 수 없습니다. 모든 시점에 적어도 하나의 저장소가 항상 default로 이름이 지어져 있어야 하기 때문입니다. 따라서 기존의 Praefect 구성에서 이름이 default로 이미 사용 중이기 때문입니다.

그런 다음 Gitaly 클러스터로 마이그레이션하는 방법을 따라 default 스토리지에서 virtualStorage2로 데이터를 옮기세요. 추가 스토리지가 global.gitaly.internal.names 아래에서 정의되었더라도 해당 저장소에서 저장소를 마이그레이션하는 것을 잊지 마세요.

리포지토리가 virtualStorage2로 마이그레이션되면 replaceInternalGitaly를 원래대로 true로 설정할 수 있습니다. 저장소가 default로 추가되었을 경우 Praefect 구성에서 replaceInternalGitaly를 다시 true로 설정하세요.

global:
  praefect:
    enabled: true
    replaceInternalGitaly: true
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
    - name: virtualStorage2
      gitalyReplicas: 5
      maxUnavailable: 2

리포지토리 저장 경로 문서를 참조하여 새 리포지토리가 저장될 위치를 구성하세요.

데이터베이스 생성

Praefect는 자체 데이터베이스를 사용하여 상태를 추적합니다. Praefect가 작동하려면 데이터베이스를 수동으로 생성해야 합니다.

참고: 이 지침은 번들로 제공된 PostgreSQL 서버를 사용하는 것으로 가정합니다. 만약 사용자의 서버를 사용하는 경우 연결 방법에 약간의 차이가 있을 수 있습니다.

1. 데이터베이스 인스턴스에 로그인합니다.

   kubectl exec -it $(kubectl get pods -l app.kubernetes.io/name=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash
   

   PGPASSWORD=$(echo $POSTGRES_POSTGRES_PASSWORD) psql -U postgres -d template1
   

2. 데이터베이스 사용자를 생성합니다.

   CREATE ROLE praefect WITH LOGIN; 
   

3. 데이터베이스 사용자 암호를 설정합니다.

   기본적으로 shared-secrets 작업은 사용자를 위해 비밀을 생성합니다.

   1. 암호를 가져옵니다.

      kubectl get secret RELEASE_NAME-praefect-dbsecret -o jsonpath="{.data.secret}" | base64 --decode
      

   2. psql 프롬프트에서 암호를 설정합니다.

      \password praefect
      

4. 데이터베이스를 생성합니다.

   CREATE DATABASE praefect WITH OWNER praefect;
   

TLS를 통한 Praefect 실행

Praefect는 클라이언트와 Gitaly 노드 간에 TLS를 통해 통신을 지원합니다. 이는 설정 global.praefect.tls.enabled 및 global.praefect.tls.secretName에 의해 제어됩니다. TLS를 통해 Praefect를 실행하려면 다음 단계를 따르세요:

1. Helm 차트는 Praefect와 TLS를 통해 통신하기 위해 제공된 인증서를 예상합니다. 이 인증서는 모든 Praefect 노드에 적용되어야 합니다. 따라서 각 노드의 모든 호스트 이름을 대체 주석(SAN)으로 추가해야 합니다. 대체로, 와일드카드를 사용할 수도 있습니다.

   사용할 호스트 이름을 알아보려면 Toolbox Pod의 /srv/gitlab/config/gitlab.yml 파일을 확인하고, 그 내부의 repositories.storages 키 아래로 지정된 다양한 gitaly_address 필드를 확인하세요.

   kubectl exec -it <Toolbox Pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml
   

참고: 내부 Praefect Pods에 대한 사용자 지정 서명된 인증서를 생성하기 위한 기본적인 스크립트는 이 저장소에서 찾을 수 있습니다. 사용자는 해당 스크립트를 사용하거나 참조하여 올바른 SAN 속성으로 인증서를 생성할 수 있습니다.

1. 생성된 인증서를 사용하여 TLS Secret를 생성합니다.

   kubectl create secret tls <시크릿 이름> --cert=praefect.crt --key=praefect.key
   

2. --set global.praefect.tls.enabled=true를 전달하여 Helm 차트를 다시 배포합니다.

TLS로 Gitaly를 실행하는 경우, 각 가상 저장소에 대해 비밀 이름을 제공해야 합니다.

global:
  gitaly:
    tls:
      enabled: true
  praefect:
    enabled: true
    tls:
      enabled: true
      secretName: praefect-tls
    virtualStorages:
    - name: default
      gitalyReplicas: 4
      maxUnavailable: 1
      tlsSecretName: default-tls
    - name: vs2
      gitalyReplicas: 5
      maxUnavailable: 2
      tlsSecretName: vs2-tls

설치 명령줄 옵션

아래 표에는 helm install 명령을 사용하여 --set 플래그를 통해 제공할 수 있는 모든 가능한 차트 구성이 포함되어 있습니다.