외부 객체 저장소를 사용하여 GitLab 차트 구성

GitLab은 Kubernetes에서 고가용성을 갖는 영구 데이터를 위해 객체 저장소를 활용합니다. 기본적으로 차트와 함께 minio라는 S3 호환 저장소 솔루션이 배포됩니다. 프로덕션 품질의 배포를 위해 Google Cloud Storage나 AWS S3 같은 호스팅된 객체 저장소 솔루션을 사용하는 것을 권장합니다.

MinIO를 비활성화하려면 이 옵션을 설정하고 관련 문서를 따르세요: 

--set global.minio.enabled=false

전체 구성의 예시는 예시에서 제공되었습니다.

이 문서는 AWS에 대한 액세스 및 비밀 키 사용을 명시하고 있습니다. 또한 IAM 역할을 사용하는 것도 가능합니다.

S3 암호화

GitLab은 Amazon KMS를 지원하여 S3 버킷에 저장된 데이터를 암호화할 수 있습니다. 이를 두 가지 방법으로 활성화할 수 있습니다:

이 두 옵션은 상호 배타적이지 않습니다. 기본 암호화 정책을 설정할 수 있지만 그 기본값을 재정의하기 위해 서버 측 암호화 헤더를 활성화할 수도 있습니다.

더 많은 세부 정보는 암호화된 S3 버킷에 대한 GitLab 문서를 확인하세요.

Azure Blob Storage

Azure Blob 저장소에 대한 직접적인 지원은 업로드된 첨부 파일, CI 작업 아티팩트, LFS 및 다른 객체 유형을 통한 통합 설정을 통해 가능합니다. 이전 GitLab 버전에서는 Azure MinIO 게이트웨이가 필요했습니다.

참고: GitLab은 Azure MinIO 게이트웨이를 Docker 레지스트리의 저장소로 지원하지 않습니다. Docker 레지스트리를 설정할 때 관련 Azure 예제를 참조하세요(#docker-registry-images).

Azure는 Blob 컬렉션을 나타내기 위해 컨테이너라는 용어를 사용하지만, GitLab에서는 표준 용어로 버킷을 사용합니다.

Azure Blob 저장소는 통합된 객체 저장소 설정을 필요로 합니다. 단일 Azure 저장소 계정 이름 및 키를 여러 Azure Blob 컨테이너에 걸쳐 사용해야 합니다. 각각의 connection 설정은 (예: artifacts, uploads 등) 개별적으로 사용자 정의할 수 없습니다.

Azure Blob 저장소를 활성화하려면 Azure connection을 정의하는 예시인 rails.azurerm.yaml을 비밀로 로드할 수 있습니다: 

kubectl create secret generic gitlab-rails-storage --from-file=connection=rails.azurerm.yml

그런 다음 MinIO를 비활성화하고 다음 전역 설정을 지정하세요: 

--set global.minio.enabled=false
--set global.appConfig.object_store.enabled=true
--set global.appConfig.object_store.connection.secret=gitlab-rails-storage

기본 이름으로 Azure 컨테이너를 만들거나 버킷 구성에서 컨테이너 이름을 설정하세요.

참고: 로컬 네트워크로의 요청이 허용되지 않음으로 인해 요청이 실패하는 경우 문제 해결 섹션을 확인하세요.

Docker 레지스트리 이미지

registry 차트의 객체 저장소 구성은 registry.storage 키와 global.registry.bucket 키를 통해 이루어집니다. 

--set registry.storage.secret=registry-storage
--set registry.storage.key=config
--set global.registry.bucket=bucket-name

참고: 버킷 이름은 비밀 및 global.registry.bucket 두 군데에 모두 설정되어야 합니다. 비밀은 레지스트리 서버에서 사용되고 전역은 GitLab 백업에서 사용됩니다.

먼저 레지스트리 차트 저장소 설정 문서에 따라 비밀을 생성한 후에 이 비밀을 사용하도록 차트를 구성하세요.

S3(S3 호환 저장소, 하지만 Azure MinIO 게이트웨이는 지원되지 않음, Azure Blob 저장소 확인), Azure 및 GCS 드라이버에 대한 예시는 examples/objectstorage에서 찾을 수 있습니다.

레지스트리 구성

  1. 사용할 스토리지 서비스를 결정합니다.
  2. 적절한 파일을 registry-storage.yaml로 복사합니다.
  3. 환경에 맞는 올바른 값으로 편집합니다.
  4. 시크릿 생성을 위해 저장소 차트 문서를 참고하세요.
  5. 문서화된대로 차트를 구성합니다.

LFS, Artifact, 업로드, 패키지, 외부 차이, Terraform 상태, 의존성 프록시, 보안 파일

LFS, artifact, 업로드, 패키지, 외부 차이, Terraform 상태, 보안 파일, 익명화 도구의 객체 스토리지 구성은 다음 키를 통해 이루어집니다:

  • global.appConfig.lfs
  • global.appConfig.artifacts
  • global.appConfig.uploads
  • global.appConfig.packages
  • global.appConfig.externalDiffs
  • global.appConfig.dependencyProxy
  • global.appConfig.terraformState
  • global.appConfig.ciSecureFiles

또한 다음을 유의하세요:

  • 버킷 설정에서 기본 이름 또는 사용자 정의 이름에 대해 버킷을 생성해야 합니다.
  • 백업에서 복원을 수행하지 않도록 각기 다른 버킷이 필요합니다.
  • 외부 스토리지에 MR 차이를 저장하는 기능은 기본적으로 활성화되어 있지 않으므로, externalDiffs의 객체 스토리지 설정이 적용되려면 global.appConfig.externalDiffs.enabled 키에 true 값을 지정해야 합니다.
  • 의존성 프록시 기능은 기본적으로 활성화되지 않으므로, dependencyProxy의 객체 스토리지 설정이 적용되려면 global.appConfig.dependencyProxy.enabled 키에 true 값을 지정해야 합니다.

아래는 구성 옵션의 예시입니다: 

--set global.appConfig.lfs.bucket=gitlab-lfs-storage
--set global.appConfig.lfs.connection.secret=object-storage
--set global.appConfig.lfs.connection.key=connection

--set global.appConfig.artifacts.bucket=gitlab-artifacts-storage
--set global.appConfig.artifacts.connection.secret=object-storage
--set global.appConfig.artifacts.connection.key=connection

--set global.appConfig.uploads.bucket=gitlab-uploads-storage
--set global.appConfig.uploads.connection.secret=object-storage
--set global.appConfig.uploads.connection.key=connection

--set global.appConfig.packages.bucket=gitlab-packages-storage
--set global.appConfig.packages.connection.secret=object-storage
--set global.appConfig.packages.connection.key=connection

--set global.appConfig.externalDiffs.bucket=gitlab-externaldiffs-storage
--set global.appConfig.externalDiffs.connection.secret=object-storage
--set global.appConfig.externalDiffs.connection.key=connection

--set global.appConfig.terraformState.bucket=gitlab-terraform-state
--set global.appConfig.terraformState.connection.secret=object-storage
--set global.appConfig.terraformState.connection.key=connection

--set global.appConfig.dependencyProxy.bucket=gitlab-dependencyproxy-storage
--set global.appConfig.dependencyProxy.connection.secret=object-storage
--set global.appConfig.dependencyProxy.connection.key=connection

--set global.appConfig.ciSecureFiles.bucket=gitlab-ci-secure-files
--set global.appConfig.ciSecureFiles.connection.secret=object-storage
--set global.appConfig.ciSecureFiles.connection.key=connection

전체 자세한 내용은 charts/globals 문서의 appConfig 구성을 참고하세요.

접속 세부 정보 문서를 따라 시크릿을 생성한 후, 제공된 시크릿을 사용하도록 차트를 구성합니다. 동일한 시크릿을 모두 사용할 수 있습니다.

AWS (Azure의 MinIO를 사용한 Azure와 같은 S3 호환) 및 Google 공급업체에 대한 예시는 examples/objectstorage에서 찾을 수 있습니다.

appConfig 구성

  1. 사용할 스토리지 서비스를 결정합니다.
  2. 적절한 파일을 rails.yaml로 복사합니다.
  3. 환경에 맞는 올바른 값으로 편집합니다.
  4. 시크릿 생성을 위해 접속 세부 정보 문서를 참고하세요.
  5. 문서화된대로 차트를 구성합니다.

백업

백업은 객체 저장소에 저장되며, 포함된 MinIO 서비스가 아닌 외부를 가리키도록 구성되어야 합니다. 백업/복원 절차는 두 개의 별도 버킷을 사용합니다:

  • 백업을 저장하는 버킷 (global.appConfig.backups.bucket)
  • 복원 프로세스 중 기존 데이터를 보존하는 임시 버킷 (global.appConfig.backups.tmpBucket)

AWS S3 호환 객체 저장소 시스템, Google Cloud Storage 및 Azure Blob Storage를 지원합니다. 백엔드 유형은 global.appConfig.backups.objectStorage.backend를 설정하여 AWS S3의 경우 s3, Google Cloud Storage의 경우 gcs, Azure Blob Storage의 경우 azure로 설정할 수 있습니다. 또한 gitlab.toolbox.backups.objectStorage.config 키를 통해 연결 구성을 제공해야 합니다.

Google Cloud Storage를 사용하는 경우, GCP 프로젝트를 global.appConfig.backups.objectStorage.config.gcpProject 값으로 설정해야 합니다.

S3 호환 저장소를 사용하는 경우: 

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage
--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config
--set gitlab.toolbox.backups.objectStorage.config.key=config

Google Cloud Storage (GCS)를 사용하는 경우: 

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage
--set gitlab.toolbox.backups.objectStorage.backend=gcs
--set gitlab.toolbox.backups.objectStorage.config.gcpProject=my-gcp-project-id
--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config
--set gitlab.toolbox.backups.objectStorage.config.key=config

Azure Blob Storage를 사용하는 경우: 

--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage
--set gitlab.toolbox.backups.objectStorage.backend=azure
--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config
--set gitlab.toolbox.backups.objectStorage.config.key=config

자세한 내용은 백업/복원 객체 저장소 설명서를 참조하세요.

참고: 다른 객체 저장소 위치에서 파일을 백업하거나 복원하려면 구성 파일을 변경하여 모든 GitLab 버킷에 대해 읽기/쓰기에 충분한 액세스 권한을 가진 사용자로 인증하도록 구성해야 합니다.

백업 저장 예시

  1. storage.config 파일을 생성하세요:

    • Amazon S3의 경우 s3cmd 구성 파일 형식으로 내용을 입력해야 합니다. 

      [default]
access_key = AWS_ACCESS_KEY
secret_key = AWS_SECRET_KEY
bucket_location = us-east-1
multipart_chunk_size_mb = 128 # 기본값은 15 (MB)

    • Google Cloud Storage의 경우 storage.admin 역할을 가진 서비스 계정을 만들고, 그 다음에는 서비스 계정 키를 생성해야 합니다. 아래는 gcloud CLI를 사용하여 파일을 만드는 예시입니다. 

      export PROJECT_ID=$(gcloud config get-value project)
gcloud iam service-accounts create gitlab-gcs --display-name "Gitlab Cloud Storage"
gcloud projects add-iam-policy-binding --role roles/storage.admin ${PROJECT_ID} --member=serviceAccount:gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com
gcloud iam service-accounts keys create --iam-account gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com storage.config

    • Azure Storage의 경우 

      [default]
# 웹 앱의 호스트명으로 엔드포인트 설정
host_base = https://your_minio_setup.azurewebsites.net
host_bucket = https://your_minio_setup.azurewebsites.net
# 기본값으로 유지
bucket_location = us-west-1
use_https = True
multipart_chunk_size_mb = 128 # 기본값은 15 (MB)

# 액세스 키 설정
# 액세스 키 = Azure Storage 계정 이름
access_key = AZURE_ACCOUNT_NAME
# 시크릿 키 = Azure Storage 계정 키
secret_key = AZURE_ACCOUNT_KEY

# S3 v4 서명 API 사용
signature_v2 = False

  2. 시크릿 생성 

    kubectl create secret generic storage-config --from-file=config=storage.config

Google Cloud CDN

Google Cloud CDN을 사용하여 아티팩트 버킷에서 데이터를 캐시하고 검색할 수 있습니다. 이를 통해 성능을 향상시키고 네트워크 탈출 비용을 줄일 수 있습니다.

Cloud CDN의 구성은 다음 키를 통해 수행됩니다:

  • global.appConfig.artifacts.cdn.secret
  • global.appConfig.artifacts.cdn.key (기본값은 cdn)

Cloud CDN 사용 방법:

  1. Cloud CDN을 사용하여 백엔드로 아티팩트 버킷을 설정.
  2. 서명된 URL을 위한 키를 생성.
  3. Cloud CDN 서비스 계정이 버킷에서 읽을 수 있도록 권한 부여.
  4. rails.googlecdn.yaml의 예제를 사용하여 매개변수가 포함된 YAML 파일을 준비하세요. 다음 정보를 입력해야 합니다:
    • url: 단계 1의 CDN 호스트의 기본 URL
    • key_name: 단계 2의 키 이름
    • key: 단계 2에서 받은 실제 시크릿

  5. 이 YAML 파일을 cdn 키 아래의 쿠버네티스 시크릿에로드하세요. 예를 들어, gitlab-rails-cdn 시크릿을 만들려면: 

     kubectl create secret generic gitlab-rails-cdn --from-file=cdn=rails.googlecdn.yml

  6. global.appConfig.artifacts.cdn.secret를 gitlab-rails-cdn로 설정하세요. 만약 helm을 통해 설정 중이라면 다음을 사용하세요: 

     --set global.appConfig.artifacts.cdn.secret=gitlab-rails-cdn

문제 해결

Azure Blob: URL [FILTERED]이(가) 차단되었습니다: 로컬 네트워크로의 요청이 허용되지 않음

Azure Blob 호스트 이름이 RFC1918(로컬/사설) IP 주소로 해결될 때 발생합니다. 이 문제를 해결하기 위해, Azure Blob 호스트 이름(yourinstance.blob.core.windows.net)에 대한 아웃바운드 요청을 허용하세요.