- S3 암호화
- Azure Blob Storage
- Docker 레지스트리 이미지
- LFS, 아티팩트, 업로드, 패키지, 외부 차이, 테라폼 상태, 의존성 프록시, 보안 파일
- 백업
- Google Cloud CDN
- 문제 해결
외부 오브젝트 리포지터리로 GitLab 차트 구성하기
GitLab은 Kubernetes에서 고가용성의 지속적인 데이터를 위해 오브젝트 리포지터리를 사용합니다.
기본적으로 minio라는 S3 호환 리포지터리 솔루션이 차트와 함께 배포됩니다.
프로덕션 환경용 배포를 위해 Google Cloud Storage 또는 AWS S3와 같은 호스팅된 오브젝트 리포지터리 솔루션을 사용하는 것을 권장합니다.
MinIO를 비활성화하려면 이 옵션을 설정한 다음 아래와 관련된 설명을 따르세요:
--set global.minio.enabled=false
전체 구성의 예시는 예시에서 확인할 수 있습니다.
이 문서는 AWS의 액세스 및 시크릿 키 사용을 명시하고 있습니다. 또한 IAM 역할을 사용하는 것도 가능합니다.
S3 암호화
GitLab은 Amazon KMS를 지원하여 S3 버킷에 저장된 데이터를 암호화할 수 있습니다. 두 가지 방법으로 이를 활성화할 수 있습니다:
- AWS에서 기본 암호화를 사용하도록 S3 버킷 구성.
- GitLab에서 서버 측 암호화 헤더를 활성화합니다.
이 두 옵션은 상호 배타적이지 않습니다. 기본 암호화 정책을 설정할 수도 있지만, 이러한 기본 설정을 무시하고 서버 측 암호화 헤더를 활성화할 수도 있습니다.
더 많은 세부 정보를 보려면 암호화된 S3 버킷에 대한 GitLab 설명서를 참조하세요.
Azure Blob Storage
Azure Blob storage에 대한 직접 지원은 업로드된 첨부 파일, CI 작업 아티팩트, LFS 및 다른 통합 설정을 통해 사용할 수 있습니다. 이전 GitLab 버전에서는 Azure MinIO 게이트웨이가 필요했습니다.
Azure는 블롭의 컬렉션을 나타내기 위해 “컨테이너”라는 용어를 사용하지만, GitLab은 표준적으로 “버킷”이라는 용어를 사용합니다.
Azure Blob storage는 통합 오브젝트 리포지터리 설정의 사용을 요구합니다.
단일 Azure 스토리지 계정 이름 및 키를 여러 Azure 블롭 컨테이너에 걸쳐 사용해야 합니다. 개별 connection 설정을 오브젝트 유형(예: 아티팩트, 업로드 등)별로 사용자 정의하는 것은 허용되지 않습니다.
Azure Blob storage를 활성화하려면 다음과 같이 하세요:
rails.azurerm.yaml을 사용하여 Azure connection을 정의하는 예시를 확인하세요. 이를 비밀로 로드할 수 있습니다.
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
기본 이름을 사용하거나 버킷 구성에서 컨테이너 이름을 설정하세요.
로컬 네트워크로의 요청이 허용되지 않음 오류가 발생하는 경우 문제 해결 섹션을 참조하십시오.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 백업에 사용됩니다.이 시크릿을 생성하고 저장에 대한 레지스트리 차트 설명서를 따라 이 차트를 구성하세요.
AWS(S3 호환), Azure 및 GCS 드라이버에 대한 예시는
examples/objectstorage에서 찾을 수 있습니다.
레지스트리 구성
- 사용할 저장 서비스를 결정합니다.
- 적절한 파일을
registry-storage.yaml로 복사합니다. - 환경에 맞는 올바른 값을 편집합니다.
- 설명서에 따라 시크릿을 만들기 위해 저장에 관한 레지스트리 차트 문서를 따릅니다.
- 문서화된 대로 차트를 구성합니다.
LFS, 아티팩트, 업로드, 패키지, 외부 차이, 테라폼 상태, 의존성 프록시, 보안 파일
LFS, 아티팩트, 업로드, 패키지, 외부 차이, 테라폼 상태, 보안 파일 및 익명화기능의 오브젝트 리포지터리 구성은 아래 키를 통해 수행됩니다:
global.appConfig.lfsglobal.appConfig.artifactsglobal.appConfig.uploadsglobal.appConfig.packagesglobal.appConfig.externalDiffsglobal.appConfig.dependencyProxyglobal.appConfig.terraformStateglobal.appConfig.ciSecureFiles
또한:
- 기본 이름 또는 버킷 구성에서 사용자 정의 이름을 생성해야 합니다.
- 복원을 수행할 때 각각에 대해 다른 버킷이 필요합니다.
- 외부 리포지터리에 MR diffs를 저장하는 것은 기본적으로 활성화되어 있지 않습니다. 따라서
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
appConfig 설정에 대한 차트/글로벌 문서에서 전체 내용을 참조하세요.
연결 세부 정보 문서에 따라 시크릿을 생성한 다음 제공된 시크릿을 사용하도록 차트를 구성하세요. 동일한 시크릿이 모두에 사용될 수 있습니다.
AWS(S3 호환), Azure 및 Google 프로바이더에 대한 예시는
examples/objectstorage에서 찾을 수 있습니다.
appConfig 구성
- 어떤 스토리지 서비스를 사용할지 결정하세요.
- 적절한 파일을
rails.yaml로 복사하세요. - 환경에 맞는 올바른 값으로 편집하세요.
- 시크릿을 생성하기 위해 연결 세부 사항 문서를 참고하세요.
- 문서화된 대로 차트를 구성하세요.
백업
백업은 객체 스토리지에도 저장되어 있으며, 포함된 MinIO 서비스가 아닌 외부를 가리키도록 구성해야 합니다. 백업/복원 절차는 두 개의 별도 버킷을 사용합니다.
- 백업을 저장하기 위한 버킷 (
global.appConfig.backups.bucket) - 복원 프로세스 중 기존 데이터를 보존하기 위한 임시 버킷 (
global.appConfig.backups.tmpBucket)
AWS S3 호환 객체 스토리지 시스템, Google Cloud Storage, Azure Blob Storage를 지원합니다. global.appConfig.backups.objectStorage.backend를 s3로 설정하여 AWS S3용, gcs로 설정하여 Google Cloud Storage용, 또는 azure로 설정하여 Azure Blob Storage용 백엔드 유형을 구성할 수 있습니다. 또한 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
Workload Identity Federation for GKE를 사용하는 Google Cloud Storage (GCS)의 경우 백엔드와 버킷만 설정하면 됩니다. 클러스터가 Google의 애플리케이션 기본 자격 증명을 사용하도록 하려면 gitlab.toolbox.backups.objectStorage.config.secret 및 gitlab.toolbox.backups.objectStorage.config.key가 설정되지 않도록 해야 합니다.
--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage
--set gitlab.toolbox.backups.objectStorage.backend=gcs
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
자세한 내용은 백업/복원 객체 스토리지 문서를 참조하세요.
백업 스토리지 예시
-
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역할을 가진 서비스 계정을 생성한 다음, 서비스 계정 키를 만들어야 합니다. 아래는gcloudCLI를 사용하여 파일을 만드는 예시입니다.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 스토리지 계정 이름 access_key = AZURE_ACCOUNT_NAME # 시크릿 키 = Azure 스토리지 계정 키 secret_key = AZURE_ACCOUNT_KEY # S3 v4 시그니처 API 사용 signature_v2 = False
-
-
시크릿 생성
kubectl create secret generic storage-config --from-file=config=storage.config
Google Cloud CDN
- 도입 완료 in GitLab 15.5.
Google Cloud CDN을 사용하여 아티팩트 버킷에서 데이터를 캐시하고 검색할 수 있습니다. 이를 통해 성능을 향상시키고 네트워크 탈출 비용을 줄일 수 있습니다.
Cloud CDN의 구성은 다음 키를 통해 수행됩니다.
global.appConfig.artifacts.cdn.secret-
global.appConfig.artifacts.cdn.key(기본값은cdn)
Cloud CDN을 사용하려면:
- Cloud CDN를 사용하여 백엔드로 아티팩트 버킷을 설정.
- 서명된 URL을 위한 키를 생성.
- Cloud CDN 서비스 계정이 버킷에서 읽을 수 있는 권한을 부여.
-
rails.googlecdn.yaml의 예제를 사용하여 파라미터가 포함된 YAML 파일을 준비하세요. 다음 정보를 입력해야 합니다.-
url: 단계 1의 CDN 호스트의 기본 URL -
key_name: 단계 2의 키 이름 -
key: 단계 2의 실제 시크릿
-
-
이 YAML 파일을
cdn키 아래의 Kubernetes 시크릿으로 로드하세요. 예를 들어,gitlab-rails-cdn이라는 시크릿を 만들려면:kubectl create secret generic gitlab-rails-cdn --from-file=cdn=rails.googlecdn.yml -
global.appConfig.artifacts.cdn.secret를gitlab-rails-cdn로 설정하세요.helm파라미터를 통해 설정하는 경우:--set global.appConfig.artifacts.cdn.secret=gitlab-rails-cdn
문제 해결
Azure Blob: URL [FILTERED] is blocked: Requests to the local network are not allowed
Azure Blob 호스트명이 RFC1918 (로컬 / 사설) IP 주소로 해결될 때 발생합니다. 이를 해결하려면 로컬 네트워크로의 아웃바운드 요청를 허용해야 합니다. 즉, Azure Blob 호스트명(yourinstance.blob.core.windows.net)에 대한 아웃바운드 요청을 허용해야 합니다.
도움말