• 알려진 제한 사항 및 문제
• 요구 사항
• 구성
  • 복제본
  • 여러 가상 스토리지
  • 지속성
• defaultReplicationFactor
  • Praefect로 마이그레이션
  • 데이터베이스 생성
  • TLS를 통해 Praefect 실행하기
  • 설치 명령줄 옵션
  • serviceAccount
  • affinity

Praefect 차트 사용하기

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

알려진 제한 사항 및 문제

1. 데이터베이스는 수동으로 생성해야 합니다.
2. 클러스터 크기는 고정되어 있습니다: Gitaly 클러스터는 현재 자동 확장을 지원하지 않습니다.
3. 클러스터 외부에서 Gitaly 인스턴스를 관리하기 위해 클러스터 내에서 Praefect 인스턴스를 사용하는 것은 지원되지 않습니다.

요구 사항

이 차트는 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로 마이그레이션

독립 실행형 Gitaly 인스턴스에서 Praefect 설정으로 마이그레이션할 때, global.praefect.replaceInternalGitaly를 false로 설정할 수 있습니다.

이렇게 하면 새로운 Praefect 관리 Gitaly 인스턴스가 생성되는 동안 기존 Gitaly 인스턴스가 보존됩니다.

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

이는 항상 최소한 하나의 스토리지가 default라는 이름을 가져야 하므로, 이름이 이미 비-Praefect 구성에 의해 사용되고 있기 때문입니다.

GitLab 클러스터로 마이그레이션하는 지침을 따라 default 스토리지에서 virtualStorage2로 데이터를 이동할 수 있습니다.

추가 스토리지가 global.gitaly.internal.names 아래에 정의되어 있다면, 해당 스토리지에서 리포지토리도 마이그레이션해야 합니다.

리포지토리가 virtualStorage2로 마이그레이션된 후, Praefect 구성에 default라는 이름의 스토리지가 추가되면 replaceInternalGitaly를 다시 true로 설정할 수 있습니다.

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

원하는 경우, GitLab 클러스터로 마이그레이션하는 지침을 다시 따라 virtualStorage2에서 새로 추가된 default 스토리지로 데이터를 이동할 수 있습니다.

마지막으로, 새로운 리포지토리가 저장되는 위치를 구성하려면 리포지토리 저장 경로 문서를 참조하세요.

데이터베이스 생성

Praefect는 상태를 추적하기 위해 자체 데이터베이스를 사용합니다. Praefect가 기능을 발휘하기 위해서는 이 데이터베이스를 수동으로 생성해야 합니다.

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는 TLS를 통해 클라이언트 및 Gitaly 노드와 통신하는 것을 지원합니다. 이는 global.praefect.tls.enabled 및 global.praefect.tls.secretName 설정에 의해 제어됩니다.

TLS를 통해 Praefect를 실행하려면 다음 단계를 따르세요:

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

   사용할 호스트네임을 확인하려면 Toolbox Pod에서 /srv/gitlab/config/gitlab.yml 파일의 다양한 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 <secret name> --cert=praefect.crt --key=praefect.key
   

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

Gitaly를 TLS를 통해 실행할 때는 각 가상 스토리지에 대한 비밀 이름을 제공해야 합니다.

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

설치 명령줄 옵션

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

serviceAccount

이 섹션은 ServiceAccount가 생성되어야 하는지와 기본 액세스 토큰이 파드에 마운트되어야 하는지를 제어합니다.

affinity

자세한 내용은 affinity를 참조하세요.