GitLab 차트용 저장소 구성

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

GitLab 차트 내의 다음 애플리케이션은 상태를 유지하기 위해 지속적인 저장소가 필요합니다.

  • Gitaly (Git 리포지토리 유지)
  • PostgreSQL (GitLab 데이터베이스 데이터 유지)
  • Redis (GitLab 작업 데이터 유지)
  • MinIO (객체 저장소 데이터 유지)

관리자는 이 저장소를 동적 또는 정적 볼륨 프로비저닝을 사용하여 할당할 수 있습니다.

중요: 설치 후 추가 저장소 이전 작업을 최소화하기 위해 사전 계획을 통해 실행됩니다. 첫 배포 후 변경 사항은 helm upgrade를 실행하기 전에 기존 Kubernetes 개체를 수동으로 편집해야 합니다.

일반적인 설치 동작

설치 프로그램은 기본 저장소 클래스와 동적 볼륨 프로비저닝을 사용하여 저장소를 생성합니다. 애플리케이션은 지속적 볼륨 클레임을 통해 이 저장소에 연결합니다. 관리자는 사용 가능할 때 동적 볼륨 프로비저닝을 사용하는 것이 좋습니다. 대신 정적 볼륨 프로비저닝을 사용합니다.

관리자는 제공자 마다 Amazon EKS와 같은 일부 환경에서 kubectl get storageclass를 사용하여 프로덕션 환경의 기본 저장소 클래스를 확인한 후 kubectl describe storageclass *STORAGE_CLASS_NAME*를 사용하여 확인해야 합니다.

클러스터 저장소 구성

권장사항

기본 저장소 클래스는 다음과 같아야 합니다:

  • 사용 가능한 경우 빠른 SSD 저장소 사용
  • reclaimPolicy를 Retain로 설정

reclaimPolicy가 Retain로 설정되지 않은 상태에서 GitLab을 제거하면 자동화된 작업이 볼륨, 디스크 및 데이터를 완전히 삭제합니다. 일부 플랫폼은 기본 reclaimPolicy를 Delete로 설정합니다. gitaly 지속 볼륨 클레임은 StatefulSet에 따라 이 규칙을 따르지 않습니다.

최소한의 저장소 클래스 구성

다음 YAML 구성은 GitLab을 위해 사용자 정의 저장소 클래스를 생성하는 데 필요한 최소한의 구성을 제공합니다. 목표 설치 환경에 적합한 값을 사용하여 CUSTOM_STORAGE_CLASS_NAME을 대체하세요.

일부 사용자는 Amazon EKS에서 예시 활용 시 노드 생성이 항상 동일한 존에 있지 않을 수도 있다고 보고하고 있습니다. 위의 zone 매개변수를 설정하면 어떠한 위험도 완화됩니다.

사용자 정의 저장소 클래스 사용

사용자 정의 저장소 클래스를 클러스터 기본값으로 설정하면 모든 동적 프로비저닝에 사용됩니다. 

kubectl patch storageclass CUSTOM_STORAGE_CLASS_NAME -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

대안으로 사용자 정의 저장소 클래스와 기타 옵션은 설치 중에 Helm에 제공될 수 있습니다. 환경에 맞게 수정하여 제공된 예제 구성 파일을 확인하세요. 

helm install -upgrade gitlab gitlab/gitlab -f HELM_OPTIONS_YAML_FILE

추가 지속성 옵션 및 자세한 내용은 아래 링크를 참조하세요:

참고: PostgreSQL 및 기타 애플리케이션 간에 일부 고급 지속성 옵션이 다름으로 변경하기 전에 각각에 대한 특정 문서를 확인하는 것이 중요합니다.

정적 볼륨 프로비저닝 사용

동적 볼륨 프로비저닝은 권장됩니다. 그러나 일부 클러스터 또는 환경에서 지원하지 않을 수 있습니다. 관리자는 지속적 볼륨을 수동으로 생성해야 합니다.

Google GKE 사용

  1. 클러스터에서 지속적 디스크를 생성합니다. 
gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME*
  1. 예시 YAML 구성을 수정한 뒤 Persistent Volume를 생성합니다. 
kubectl create -f *PV_YAML_FILE*

Amazon EKS 사용

참고: 여러 존에 배포해야 하는 경우 저장소 클래스를 정의할 때 Amazon의 저장소 클래스 문서를 검토해야 합니다.

  1. 클러스터에서 지속적 디스크를 생성합니다.](https://kubernetes.io/docs/concepts/storage/volumes/#creating-an-ebs-volume) 
aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2
  1. 예시 YAML 구성을 수정한 뒤 Persistent Volume를 생성합니다. 
kubectl create -f *PV_YAML_FILE*

수동으로 PersistentVolumeClaims 생성

Gitaly 서비스는 StatefulSet을 사용하여 배포됩니다. 제대로 인식 및 사용되기 위해 다음 명명 규칙을 사용하여 PersistentVolumeClaim을 생성해야 합니다. 

<mount-name>-<statefulset-pod-name>

Gitaly의 mount-name은 repo-data입니다. StatefulSet 파드 이름은 다음과 같이 생성됩니다: 

<statefulset-name>-<pod-index>

GitLab 차트는 statefulset-name을 사용하여 올바른 이름을 결정합니다: 

<chart-release-name>-<service-name>

Gitaly PersistentVolumeClaim의 올바른 이름은:repo-data-gitlab-gitaly-0입니다.

참고: 여러 가상 저장소를 사용하는 경우 Praefect와 함께 사용해야 할 복제본당 하나의 PersistentVolumeClaim이 필요합니다. 예를 들어 default 및 vs2 Virtual Storage가 각각 2개의 복제본과 함께 정의된 경우 다음 PersistentVolumeClaims가 필요합니다:

  • repo-data-gitlab-gitaly-default-0
  • repo-data-gitlab-gitaly-default-1
  • repo-data-gitlab-gitaly-vs2-0
  • repo-data-gitlab-gitaly-vs2-1

환경에 맞게 예제 YAML 구성을 수정하고 helm을 호출할 때 참조하세요.

StatefulSet을 사용하지 않는 다른 서비스들은 설정에 volumeName을 제공할 수 있습니다. 이 차트는 여전히 volume claim를 생성하고 수동으로 생성된 볼륨에 바인드를 시도합니다. 각 포함된 애플리케이션에 대한 차트 문서를 확인하세요.

대부분의 경우 예제 YAML 구성을 수정하고 수동으로 생성된 디스크 볼륨을 사용할 서비스만 유지하세요.

```plaintext

설치 후 저장소 변경

초기 설치 후에는 새 볼륨으로 이전하거나 디스크 크기를 변경하는 등의 저장소 변경이 Helm 업그레이드 명령어 외부에서 쿠버네티스 오브젝트를 편집해야 합니다.

영구 볼륨 관리 문서를 참조하세요.

선택적 볼륨

대규모 설치의 경우 백업/복원을 작동시키려면 툴박스에 영구 저장소를 추가해야 할 수 있습니다. 이 작업 방법에 대한 안내는 문제 해결 문서를 참조하세요.