• 지원되는 객체 스토리지 제공업체
• 모든 객체 유형에 대한 단일 스토리지 연결을 구성 (통합형(form))
  • 공통 매개변수 구성
  • 각 객체의 매개변수 구성
    • 특정 기능에 대한 객체 리포지터리 비활성화
• 각 객체 유형별로 자체 리포지터리 연결 구성 (리포지터리별 형식)
• 연결 설정 구성
  • Amazon S3
    • Amazon 인스턴스 프로필 사용
    • 암호화된 S3 버킷
    • 서버 측 암호화 헤더
  • Oracle Cloud S3
  • Google Cloud Storage (GCS)
    • GCS 예시
    • ADC를 사용한 GCS 예시
  • Azure Blob Storage
  • Storj Gateway (SJ)
  • Hitachi Vantara HCP
• 통합된 형식 및 Amazon S3 사용한 전체 예시
• 객체 리포지터리로 이전
• 통합 형태로 전환
• 객체를 다른 객체 리포지터리 제공자로 이전
• 파일 시스템 리포지터리 대체 방법
• 문제 해결
  • GitLab 백업에 객체가 포함되지 않음
  • 별도의 버킷 사용
  • S3 API 호환성 문제
  • 프록시 다운로드
  • ETag 불일치
  • 다중 스레드 복사
  • Rails Console을 통한 매뉴얼 테스트

객체 스토리지

GitLab은 다양한 유형의 데이터 보유를 위해 객체 스토리지 서비스를 지원합니다. 일반적으로 객체 스토리지는 NFS보다 더 성능이 우수하고 신뢰성이 있으며 확장 가능하기 때문에 대규모 설정에서 더 좋습니다.

객체 스토리지를 구성하려면 두 가지 옵션이 있습니다.

• 추천. 모든 객체 유형에 대한 단일 스토리지 연결을 구성: 모든 지원되는 객체 유형이 공유 자격 증명을 사용합니다. 이를 통칭형(form)이라고 합니다.

• 각 객체 유형을 정의하여 자체 스토리지 연결을 구성: 각 객체가 자체 객체 스토리지 연결과 구성을 정의합니다. 이를 리포지터리별(form)이라고 합니다.

  이미 리포지터리별(form)을 사용하는 경우 통합형(form)으로 전환하는 방법을 참조하세요.

데이터를 로컬에 저장하는 경우 객체 스토리지로 마이그레이션 방법을 확인하세요.

지원되는 객체 스토리지 제공업체

GitLab은 Fog 라이브러리와 긴밀하게 통합되어 있으므로 GitLab에서 사용할 수 있는 제공업체들을 확인할 수 있습니다.

구체적으로, GitLab은 몇 가지 객체 스토리지 제공업체에서 고객 및 공급업체에 의해 테스트되었습니다:

• Amazon S3 (객체 잠금은 지원되지 않음, 자세한 정보는 이슈 #335775를 참조하세요.)
• Google Cloud Storage
• Digital Ocean Spaces (S3 호환)
• Oracle Cloud Infrastructure
• OpenStack Swift (S3 호환 모드)
• Azure Blob storage
• MinIO (S3 호환)
• 공식적으로 확립된 디렉터리이 아닌 다양한 리포지터리 공급업체의 온프레미스 하드웨어 및 기기.

모든 객체 유형에 대한 단일 스토리지 연결을 구성 (통합형(form))

• GitLab 13.2에 도입되었습니다.

CI 아티팩트, LFS 파일 및 업로드 첨부 파일과 같은 대부분의 객체 유형은 단일 자격 증명을 지정하여 객체 스토리지에 저장할 수 있습니다.

통합형(form)을 사용한 객체 스토리지 구성에는 여러 가지 이점이 있습니다:

• 객체 유형을 통해 연결 상세 정보를 공유할 수 있어 GitLab 구성을 단순화할 수 있습니다.
• 암호화된 S3 버킷을 사용할 수 있습니다.
• 올바른 Content-MD5 헤더로 S3에 파일을 업로드할 수 있습니다.

통합형(form)을 사용하면 직접 업로드가 자동으로 활성화됩니다. 따라서 다음 공급업체만 사용할 수 있습니다:

• Amazon S3 호환 제공업체
• Google Cloud Storage
• Azure Blob storage

통합형(form) 구성은 백업이나 Mattermost에 사용할 수 없습니다. 백업은 서버 측 암호화로 따로 구성할 수 있습니다. 지원되는 객체 스토리지 유형의 완전한 디렉터리은 표를 참조하세요.

통합형(form)을 활성화하면 모든 객체 유형에 대해 객체 스토리지가 활성화됩니다. 모든 버킷이 지정되지 않은 경우 다음과 같은 오류가 발생할 수 있습니다:

<객체 유형>에 대한 객체 스토리지에는 버킷을 지정해야 합니다

특정 객체 유형에 대해 로컬 스토리지를 사용하려면 특정 기능에 대한 객체 스토리지를 비활성화할 수 있습니다.

공통 매개변수 구성

통합형(form)에서 object_store 섹션은 공통 매개변수를 정의합니다.

예시는 통합형(form)과 Amazon S3 사용하기를 참조하세요.

각 객체의 매개변수 구성

각 객체 유형은 적어도 해당 유형이 저장될 버킷 이름을 정의해야 합니다.

다음 표는 사용 가능한 objects를 나열합니다.

각 객체 유형에서 세 가지 매개변수를 정의할 수 있습니다:

예시는 통합형(form)과 Amazon S3 사용하기를 참조하세요.

특정 기능에 대한 객체 리포지터리 비활성화

위와 같이 enabled 플래그를 false로 설정하여 특정 유형에 대한 객체 리포지터리를 비활성화할 수 있습니다. 예를 들어, CI artifact의 객체 리포지터리를 비활성화하려면:

gitlab_rails['object_store']['objects']['artifacts']['enabled'] = false

기능이 완전히 비활성화된 경우 버킷이 필요하지 않습니다. 예를 들어, 이 설정으로 CI artifact가 비활성화된 경우 버킷이 필요하지 않습니다:

gitlab_rails['artifacts_enabled'] = false

각 객체 유형별로 자체 리포지터리 연결 구성 (리포지터리별 형식)

리포지터리별 형식을 통해 모든 객체는 자체 객체 리포지터리 연결과 구성을 정의합니다. GitLab 13.2 이상을 사용하는 경우 통합된 형식으로 전환해야 합니다.

리포지터리별 형식에서 암호화된 S3 버킷은 지원되지 않습니다. 사용할 경우 ETag 불일치 오류가 발생할 수 있습니다.

GitLab 13.1 및 이전 버전에서 객체 리포지터리를 구성하거나, 통합된 형식에서 지원되지 않는 리포지터리 유형의 경우 다음 가이드를 참조하세요:

연결 설정 구성

통합된 형식 및 리포지터리별 형식은 모두 연결을 구성해야 합니다. 다음 섹션에서는 connection 설정에 사용할 수 있는 매개변수를 설명합니다.

Amazon S3

연결 설정은 fog-aws에서 제공하는 설정과 일치합니다:

Amazon 인스턴스 프로필 사용

객체 리포지터리 구성에서 AWS 액세스 및 비밀 키를 제공하는 대신 GitLab을 Amazon Identity Access and Management (IAM) 역할을 설정하기 위해 Amazon 인스턴스 프로필로 구성할 수 있습니다. 이를 사용하면 GitLab은 S3 버킷에 액세스할 때마다 임시 자격 증명을 가져오므로 구성 파일에 하드 코딩된 값이 필요하지 않습니다.

사전 요구 사항:

• GitLab은 인스턴스 메타데이터 엔드포인트에 연결할 수 있어야 합니다.
• GitLab이 인터넷 프록시를 사용하도록 구성된 경우, 엔드포인트 IP 주소를 no_proxy 디렉터리에 추가해야 합니다.

인스턴스 프로필을 설정하려면:

1. 필요한 권한을 부여하는 IAM 역할을 만듭니다. 다음은 test-bucket이라는 S3 버킷을 위한 역할 예시입니다:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor0",
               "Effect": "Allow",
               "Action": [
                   "s3:PutObject",
                   "s3:GetObject",
                   "s3:DeleteObject"
               ],
               "Resource": "arn:aws:s3:::test-bucket/*"
           }
       ]
   }
   

2. EC2 인스턴스에 이 역할을 부여합니다.
3. GitLab 구성 옵션 use_iam_profile을 true로 설정합니다.

암호화된 S3 버킷

• 소개는 instance profiles에만 해당되며, S3 기본 암호화가 GitLab 13.1에 도입되었습니다.
• 소개는 통합형 양식 및 S3 기본 암호화을 사용하는 경우 GitLab 13.2에 static 자격 증명에 대해 도입되었습니다.

인스턴스 프로필 또는 통합형 양식으로 구성된 경우 GitLab Workhorse는 S3 버킷에 파일을 올바르게 업로드합니다. AWS KMS 키 및 SSE-C 암호화는 요청마다 암호화 키를 전송해야 하기 때문에 요청이 필요합니다.

서버 측 암호화 헤더

• 소개는 GitLab 13.3에 도입되었습니다.

S3 버킷에 기본 암호화를 설정하는 것은 암호화를 활성화하는 가장 쉬운 방법이지만, 암호화된 객체만 업로드됨을 보장하기 위해 버킷 정책을 설정할 수 있습니다. 이를 위해 storage_options 구성 섹션에서 GitLab을 적절한 암호화 헤더를 전송하도록 구성해야 합니다:

기본 암호화의 경우와 마찬가지로, 이러한 옵션은 Workhorse S3 클라이언트가 활성화된 경우에만 작동합니다. 다음 두 가지 조건 중 하나를 충족해야 합니다:

• 연결 설정에서 use_iam_profile이 true로 설정되어 있음.
• 통합형 양식이 사용 중임.

ETag 불일치 오류는 서버 측 암호화 헤더를 사용할 때 Workhorse S3 클라이언트를 활성화하지 않고 시도할 때 발생합니다.

Oracle Cloud S3

Oracle Cloud S3는 다음 설정을 사용해야 합니다:

enable_signature_v4_streaming을 true로 설정하는 경우, production.log에서 다음과 같은 오류가 발생할 수 있습니다:

STREAMING-AWS4-HMAC-SHA256-PAYLOAD is not supported

Google Cloud Storage (GCS)

다음은 GCS의 유효한 연결 매개변수입니다:

GitLab은 google_json_key_location 값을 읽은 후 google_json_key_string, 마지막으로 google_application_default 값을 사용합니다. 이러한 설정 중 값이 있는 것을 사용합니다.

서비스 계정은 버킷에 액세스할 수 있는 권한이 있어야 합니다. 자세한 내용은 Cloud Storage 인증 문서를 참조하세요.

GCS 예시

Linux 패키지 설치의 경우, 통합형 양식의 connection 설정의 예시입니다:

gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<GOOGLE PROJECT>',
  'google_json_key_location' => '<FILENAME>'
}

ADC를 사용한 GCS 예시

• 소개는 GitLab 13.6에 도입되었습니다.

Google Cloud Application Default Credentials (ADC)는 일반적으로 기본 서비스 계정을 사용하기 위해 GitLab에서 사용됩니다. 이렇게 함으로써 인스턴스에 자격 증명을 제공하는 필요성이 제거됩니다. 예를 들어, 통합형 양식에서:

gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<GOOGLE PROJECT>',
  'google_application_default' => true
}

ADC를 사용하는 경우, 다음에 주의하세요:

• 사용하는 서비스 계정에는 iam.serviceAccounts.signBlob 권한이 있어야 합니다. 일반적으로 이 작업은 서비스 계정에 Service Account Token Creator 역할을 부여하여 수행합니다.

• 가상 머신이 Google Cloud API에 액세스하도록 올바른 액세스 범위를 가지고 있는지 확인하세요. 머신에 올바른 범위가 없으면 오류 로그에 다음과 같은 내용이 표시될 수 있습니다:

  Google::Apis::ClientError (insufficientPermissions: Request had insufficient authentication scopes.)
  

Azure Blob Storage

• 소개는 GitLab 13.4에 도입되었습니다.

Azure는 블롭의 모음을 나타내는 단어로 컨테이너를 사용하지만, GitLab은 버킷이라는 용어를 표준화합니다. Azure 블로브 스토리지의 컨테이너 이름을 bucket 설정에 구성해야 합니다.

Azure Blob Storage는 여러 컨테이너에 액세스하기 위해 하나의 자격 증명 세트를 사용하기 때문에 통합형 양식에서만 사용할 수 있습니다. 리포지터리별 양식은 지원되지 않습니다. 자세한 내용은 통합형 양식으로 전환하는 방법을 참조하세요.

다음은 Azure의 유효한 연결 매개변수입니다. 자세한 내용은 Azure Blob Storage 문서를 참조하세요.

• Linux 패키지 설치의 경우, 통합형 양식의 connection 설정의 예시입니다:

  gitlab_rails['object_store']['connection'] = {
    'provider' => 'AzureRM',
    'azure_storage_account_name' => '<AZURE STORAGE ACCOUNT NAME>',
    'azure_storage_access_key' => '<AZURE STORAGE ACCESS KEY>',
    'azure_storage_domain' => '<AZURE STORAGE DOMAIN>'
  }
  

• 소스 컴파일된 설치의 경우, Workhorse도 Azure 자격 증명으로 구성되어야 합니다. 이는 Linux 패키지 설치에서는 필요하지 않습니다. 왜냐하면 Workhorse 설정이 이전 설정에서 자동으로 채워지기 때문입니다.

  1. /home/git/gitlab-workhorse/config.toml을 편집하고 다음 줄을 추가하거나 수정하세요:

     [object_storage]
       provider = "AzureRM"
          
     [object_storage.azurerm]
       azure_storage_account_name = "<AZURE STORAGE ACCOUNT NAME>"
       azure_storage_access_key = "<AZURE STORAGE ACCESS KEY>"
     

  사용자 정의 Azure 스토리지 도메인을 사용하는 경우, Workhorse 구성에서 azure_storage_domain을 설정할 필요가 없습니다. 이 정보는 GitLab Rails와 Workhorse 간의 API 호출로 교환됩니다.

Storj Gateway (SJ)

Storj Network는 S3 호환 API 게이트웨이를 제공합니다. 다음 구성 예시를 사용하세요:

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'endpoint' => 'https://gateway.storjshare.io',
  'path_style' => true,
  'region' => 'eu1',
  'aws_access_key_id' => 'ACCESS_KEY',
  'aws_secret_access_key' => 'SECRET_KEY',
  'aws_signature_version' => 2,
  'enable_signature_v4_streaming' => false
}

시그니처 버전은 2여야 합니다. v4를 사용하면 HTTP 411 Length Required 오류가 발생합니다. 자세한 정보는 이슈 #4419를 참조하세요.

Hitachi Vantara HCP

HCP는 S3 호환 API를 제공합니다. 다음 구성 예시를 사용하세요:

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'endpoint' => 'https://<tenant_endpoint>',
  'path_style' => true,
  'region' => 'eu1',
  'aws_access_key_id' => 'ACCESS_KEY',
  'aws_secret_access_key' => 'SECRET_KEY',
  'aws_signature_version' => 4,
  'enable_signature_v4_streaming' => false
}

# <namespace_name/bucket_name> 형식의 예시
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = '<namespace_name>/<bucket_name>'

통합된 형식 및 Amazon S3 사용한 전체 예시

다음 예시는 모든 지원되는 서비스에 대해 객체 리포지터리를 활성화하기 위해 AWS S3를 사용합니다:

객체 리포지터리로 이전

기존 로컬 데이터를 객체 리포지터리로 이전하려면 다음 가이드를 참조하세요:

• 작업 artifacts(객체 리포지터리로 이전) 및 아카이브된 작업 로그
• LFS(objects)(객체 리포지터리로 이전)
• 업로드(객체 리포지터리로 이전)
• Merge Request diffs(객체 리포지터리 사용)
• 패키지(객체 리포지터리로 로컬 패키지 이전) (선택적 기능)
• 의존성 프록시(로컬 의존성 프록시 blobs 및 manifest 이전)
• 테라폼 상태 파일(객체 리포지터리로 이전)
• 페이지 콘텐츠(페이지 배포를 객체 리포지터리로 이전)
• 프로젝트 별 보안 파일(객체 리포지터리로 이전)

통합 형태로 전환

GitLab 13.2 이전:

• 모든 유형의 객체에 대한 오브젝트 스토리지 구성(CI/CD artifacts, LFS files, 업로드 첨부 파일 등)은 독립적으로 구성해야 했습니다.
• 패스워드 및 엔드포인트 URL과 같은 객체 리포지터리 연결 매개변수는 각 유형별로 중복되어 구성되어야 했습니다.

예를 들어, Linux 패키지 설치는 다음과 같은 구성을 가질 수 있습니다:

# 원본 객체 리포지터리 구성
gitlab_rails['artifacts_object_store_enabled'] = true
gitlab_rails['artifacts_object_store_direct_upload'] = true
gitlab_rails['artifacts_object_store_proxy_download'] = true
gitlab_rails['artifacts_object_store_remote_directory'] = 'artifacts'
gitlab_rails['artifacts_object_store_connection'] = { 'provider' => 'AWS', 'aws_access_key_id' => 'access_key', 'aws_secret_access_key' => 'secret' }
gitlab_rails['uploads_object_store_enabled'] = true
gitlab_rails['uploads_object_store_direct_upload'] = true
gitlab_rails['uploads_object_store_proxy_download'] = true
gitlab_rails['uploads_object_store_remote_directory'] = 'uploads'
gitlab_rails['uploads_object_store_connection'] = { 'provider' => 'AWS', 'aws_access_key_id' => 'access_key', 'aws_secret_access_key' => 'secret' }

이는 GitLab이 서로 다른 클라우드 제공자 간에 객체를 저장할 수 있도록 유연성을 제공하지만, 추가 복잡성과 불필요한 중복을 초래합니다. GitLab Rails 및 Workhorse 컴포넌트가 모두 객체 리포지터리에 액세스해야 하는데, 통합된 형태는 자격 증명의 과도한 중복을 피합니다.

통합 형태는 원본 형태의 모든 라인이 생략된 경우에만 사용됩니다. 통합 형태로 이동하려면 원본 구성을 제거하세요(예: artifacts_object_store_enabled, 또는 uploads_object_store_connection).

객체를 다른 객체 리포지터리 제공자로 이전

객체 리포지터리에 있는 GitLab 데이터를 다른 객체 리포지터리 제공자로 이전해야 할 수 있습니다. 다음 단계는 Rclone을 사용하여 이렇게 하는 방법을 보여줍니다.

이 단계는 uploads 버킷을 이동한다고 가정하지만, 동일한 절차가 다른 버킷에도 작동합니다.

전제 조건:

• Rclone을 실행할 컴퓨터를 선택하세요. 이전할 데이터의 양에 따라 Rclone이 오랜 시간 실행될 수 있으므로 노트북이나 데스크탑 컴퓨터를 사용하지 않는 것이 좋습니다. GitLab 서버를 사용하여 Rclone을 실행할 수 있습니다.

1. Rclone 설치.

2. 다음을 실행하여 Rclone을 구성하세요:

   rclone config
   

   구성 과정은 대화형입니다. 현재 데이터가 있는 객체 리포지터리 제공자(old)와 이동할 제공자(new) 각각 최소한 두 개의 “원격지”를 추가하세요.

3. 이전 데이터를 읽을 수 있는지 확인하세요. 다음 예제는 uploads 버킷을 참조하지만, 사용 중인 버킷 이름이 다를 수 있습니다:

   rclone ls old:uploads | head
   

   이 명령은 현재 uploads 버킷에 저장된 객체의 부분 디렉터리을 출력해야 합니다. 오류가 발생하거나 디렉터리이 비어 있으면 rclone config을 사용하여 Rclone 구성을 업데이트하세요.

4. 초기 복사를 수행하세요. 이 단계에서 GitLab 서버를 오프라인으로 가져갈 필요는 없습니다.

   rclone sync -P old:uploads new:uploads
   

5. 첫 번째 동기화가 완료되면 새로운 버킷에 객체가 있는지 새로운 객체 리포지터리 제공자의 웹 UI 또는 명령줄 인터페이스를 사용하여 확인하세요. 객체가 없거나 rclone sync 실행 중에 오류가 발생하면 Rclone 구성을 확인하고 다시 시도하세요.

적어도 한 번의 성공적인 Rclone 복사가 완료된 후 유지 보수를 예약하고 GitLab 서버를 오프라인으로 전환하세요. 유지 보수 창에서 다음 작업을 수행해야 합니다:

1. 최종 rclone sync를 수행하세요. 사용자가 새로운 객체를 추가할 수 없으므로 이전 버킷에 어떤 객체도 남기지 않도록 해야 합니다.
2. GitLab 서버의 오브젝트 스토리지 구성을 uploads에 대해 새 제공자를 사용하도록 업데이트하세요.

파일 시스템 리포지터리 대체 방법

GitLab 구현의 확장 또는 장애 허용 및 중복성 추가를 위해 블록 또는 네트워크 파일 시스템에 대한 의존성을 제거하고 있는 경우, 다음 추가 가이드를 참조하세요:

1. git 사용자 홈 디렉터리가 로컬 디스크에 있는지 확인하세요.
2. 공유 authorized_keys 파일의 필요성을 제거하기 위해 SSH 키의 데이터베이스 조회 구성하세요.
3. 작업 로그의 로컬 디스크 사용 방지.
4. 페이지 로컬 저장 공간 비활성화.

문제 해결

GitLab 백업에 객체가 포함되지 않음

백업 설명서에 언급된 바와 같이, 객체는 GitLab 백업에 포함되지 않습니다. 대신 객체 리포지터리 제공자와 함께 백업을 활성화할 수 있습니다.

별도의 버킷 사용

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab의 권장 사항입니다. GitLab이 저장하는 다양한 유형의 데이터 간 충돌이 없도록 합니다. Issue 292958에서 단일 버킷 사용을 활성화하는 것을 제안합니다.

Linux 패키지 및 자체 컴파일 설치의 경우 단일 실제 버킷을 여러 가상 버킷으로 분할할 수 있습니다. 객체 리포지터리 버킷이 my-gitlab-objects라면 업로드는 my-gitlab-objects/uploads, artifacts는 my-gitlab-objects/artifacts 등으로 구성할 수 있습니다. 응용 프로그램은 이러한 것들이 별도의 버킷인 것처럼 작동합니다. 버킷 접두사 사용은 Helm 백업에서 제대로 작동하지 않을 수 있습니다.

Helm 기반 설치에는 백업 복원을 처리하기 위해 별도의 버킷이 필요합니다 [합니다(https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-terraform-state-dependency-proxy).

S3 API 호환성 문제

일부 S3 제공업체는 GitLab이 사용하는 Fog 라이브러리와 완전히 호환되지 않을 수 있습니다. 증상으로는 production.log에 오류가 표시됩니다:

411 Length Required

프록시 다운로드

클라이언트는 사전 서명 및 시간 제한이 있는 URL을 받거나 GitLab이 객체 리포지터리에서 데이터를 클라이언트로 프록시하는 방식으로 객체 리포지터리에서 파일을 다운로드할 수 있습니다. 객체 리포지터리에서 파일을 직접 다운로드하면 GitLab이 처리해야 하는 트래픽 양이 줄어듭니다.

로컬 블록 리포지터리나 NFS에 파일이 저장된 경우 GitLab은 프록시로 작동해야 합니다. 객체 리포지터리의 경우에는 기본 동작이 아닙니다.

proxy_download 설정은 이러한 동작을 제어합니다. 기본값은 일반적으로 false입니다. 각 사용 사례에 대한 문서를 확인하여 이를 확인하세요. 파일을 프록시로 사용하려면 true로 설정하세요.

파일을 프록시로 사용하지 않을 경우 GitLab은 HTTP 302 redirect와 함께 사전 서명 및 시간 제한 객체 리포지터리 URL을 반환합니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다:

• GitLab이 안전하지 않은 HTTP를 사용하여 객체 리포지터리에 액세스하는 경우 클라이언트는 https->http 다운그레이드 오류를 생성하고 리디렉트를 처리하지 않을 수 있습니다. 이 문제의 해결책은 GitLab이 HTTPS를 사용하는 것입니다. 예를 들어 LFS는 다음과 같은 오류를 생성합니다:

  LFS: lfsapi/client: refusing insecure redirect, https->http
  

• 클라이언트는 객체 리포지터리 인증서를 발급한 인증 기관을 신뢰해야 하거나 다음과 같은 일반적인 TLS 오류를 반환할 수 있습니다:

  x509: certificate signed by unknown authority
  

• 클라이언트는 객체 리포지터리에 대한 네트워크 액세스가 필요합니다. 네트워크 방화벽이 액세스를 차단할 수 있습니다. 이러한 액세스가 설정되지 않으면 발생할 수 있는 오류에는 다음이 있습니다:

  Received status code 403 from server: Forbidden
  

• 객체 리포지터리 버킷은 GitLab 인스턴스의 URL에서 Cross-Origin Resource Sharing (CORS) 액세스를 허용해야 합니다. 리포지터리 페이지에서 PDF를 로드하려고 하면 다음과 같은 오류가 표시될 수 있습니다:

  파일 로드 중 오류가 발생했습니다. 나중에 다시 시도하세요.
  

  자세한 내용은 LFS 문서를 참조하십시오.

또한 잠깐의 기간 동안 사용자들은 인증 없이 다른 사람과 사전 서명 및 시간 제한 객체 리포지터리 URL을 공유할 수 있습니다. 또한 객체 리포지터리 공급자와 클라이언트 간에 대역폭 요금이 발생할 수 있습니다.

ETag 불일치

기본 GitLab 설정을 사용하는 경우, MinIO와 알리바바와 같은 일부 객체 리포지터리 백엔드에서 ETag 불일치 오류가 발생할 수 있습니다.

Amazon Web Services S3에서 이러한 ETag 불일치 오류가 발생하는 경우, 이는 버킷의 암호화 설정 때문일 가능성이 높습니다. 이 문제를 해결하려면 두 가지 옵션이 있습니다:

• 통합형 양식으로 단일 리포지터리 연결 구성.
• Amazon 인스턴스 프로필 사용.

첫 번째 옵션은 MinIO에 추천됩니다. 그렇지 않으면 MinIO의 해결책은 서버에서 --compat 매개변수를 사용하는 것입니다.

통합형 양식이나 인스턴스 프로필이 활성화되지 않은 경우, GitLab Workhorse는 Content-MD5 HTTP 헤더가 계산되지 않은 사전 서명 URL을 사용하여 S3에 파일을 업로드합니다. 데이터가 손상되지 않도록 하기 위해 Workhorse는 전송된 데이터의 MD5 해시가 S3 서버에서 반환된 ETag 헤더와 일치하는지 확인합니다. 암호화가 활성화된 경우 이는 사실이 아니기 때문에 업로드 중에 Workhorse가 ETag 불일치 오류를 보고합니다.

통합형 양식이:

• S3 호환 객체 리포지터리나 인스턴스 프로필과 함께 사용되는 경우 Workhorse는 내부 S3 클라이언트를 사용하여 S3 자격 증명을 갖기 때문에 Content-MD5 헤더를 계산할 수 있습니다. 이로써 S3 서버에서 반환된 ETag 헤더를 비교할 필요가 없어집니다.
• S3 호환 객체 리포지터리와 함께 사용되지 않는 경우 Workhorse는 사전 서명 URL을 사용하도록 되돌아갑니다.

GCS의 버킷을 Cloud Key Management Service (KMS)로 암호화하는 것은 지원되지 않으며 ETag 불일치 오류가 발생합니다.

다중 스레드 복사

GitLab은 버킷 내에서 파일을 복사하는 것을 가속화하기 위해 S3 Upload Part Copy API를 사용합니다. Ceph S3는 Kraken 11.0.2 이전에 이를 지원하지 않으며 업로드 프로세스 중에 파일을 복사하면 404 오류가 반환됩니다.

이 기능은 :s3_multithreaded_uploads 피처 플래그를 사용하여 비활성화할 수 있습니다. 기능을 비활성화하려면 피처 플래그 뒤에 숨겨진 기능을 사용하고 비활성화하는 방법에서 설명한 대로 GitLab 관리자에게 요청하여 다음 명령을 실행하세요:

Feature.disable(:s3_multithreaded_uploads)

Rails Console을 통한 매뉴얼 테스트

일부 상황에서는 Rails Console을 사용하여 객체 리포지터리 설정을 테스트하는 것이 도움이 될 수 있습니다. 다음 예제는 주어진 연결 설정을 테스트하고 테스트 객체를 작성한 후 이를 읽는 방법을 보여줍니다.

1. Rails console을 시작합니다.
2. 다음 예제 양식으로 /etc/gitlab/gitlab.rb에서 설정한 매개 변수를 사용하여 객체 리포지터리 연결을 설정합니다.

액세스 키를 사용한 연결 예제:

  connection = Fog::Storage.new(
    {
      provider: 'AWS',
      region: `eu-central-1`,
      aws_access_key_id: '<AWS_ACCESS_KEY_ID>',
      aws_secret_access_key: '<AWS_SECRET_ACCESS_KEY>'
    }
  )

AWS IAM Profiles를 사용한 연결 예제:

  connection = Fog::Storage.new(
    {
      provider: 'AWS',
      use_iam_profile: true,
      region: 'us-east-1'
    }
  )

1. 테스트할 버킷 이름을 지정하고 테스트 파일을 작성한 후 이를 읽습니다.

  dir = connection.directories.new(key: '<bucket-name-here>')
  f = dir.files.create(key: 'test.txt', body: 'test')
  pp f
  pp dir.files.head('test.txt')