GitLab 컨테이너 레지스트리 관리

Tier: Free, Premium, Ultimate Offering: Self-Managed
note
새로운 세대 컨테이너 레지스트리가 이제 Self-Managed 인스턴스에서 업그레이드할 수 있는 상태입니다. 이 업그레이드된 레지스트리는 온라인 가비지 수집을 지원하며, bet성능과 신뢰성이 크게 향상되었습니다.

GitLab 컨테이너 레지스트리를 사용하면 모든 프로젝트가 Docker 이미지를 저장할 수 있는 공간을 갖게 됩니다.

Distribution Registry에 대한 자세한 내용:

이 문서는 관리자 가이드입니다. GitLab 컨테이너 레지스트리의 사용 방법에 대해서는 사용자 설명서를 참조하세요.

컨테이너 레지스트리 활성화

컨테이너 레지스트리를 활성화하는 프로세스는 사용 중인 설치 유형에 따라 다릅니다.

Linux 패키지 설치

Linux 패키지를 사용하여 GitLab을 설치한 경우 컨테이너 레지스트리는 기본적으로 사용 가능할 수도 있고 그렇지 않을 수도 있습니다.

내장된 Let’s Encrypt 통합을 사용하고 있다면 컨테이너 레지스트리는 GitLab 도메인의 5050번 포트에서 자동으로 활성화되어 사용할 수 있습니다.

그렇지 않다면, 컨테이너 레지스트리는 비활성화됩니다. 활성화하려면:

컨테이너 레지스트리는 기본적으로 HTTPS에서 작동합니다. HTTP를 사용할 수 있지만 권장되지 않으며 이 문서의 범위를 벗어납니다.

Helm Charts 설치

Helm Charts 설치의 경우, 헬름 차트 문서에서 컨테이너 레지스트리 사용을 참조하세요.

자체 컴파일된 설치

GitLab 설치를 자체 컴파일한 경우:

  1. 설치하는 GitLab 버전에 해당하는 이미지를 사용하여 레지스트리를 배포해야 합니다 (예: registry.gitlab.com/gitlab-org/build/cng/gitlab-container-registry:v3.15.0-gitlab)
  2. 설치가 완료되면, gitlab.yml에서 레지스트리의 설정을 구성해 활성화해야 합니다.
  3. lib/support/nginx/registry-ssl에서 샘플 NGINX 구성 파일을 사용하고 host, port, 및 TLS 인증서 경로를 일치시켜야 합니다.

gitlab.yml의 내용은 다음과 같습니다: 

registry:
  enabled: true
  host: registry.gitlab.example.com
  port: 5005
  api_url: http://localhost:5000/
  key: config/registry.key
  path: shared/registry
  issuer: gitlab-issuer

여기서:

매개변수 설명
enabled true 또는 false. GitLab에서 레지스트리를 활성화하거나 비활성화합니다. 기본적으로는 false입니다.
host 레지스트리가 실행되고 사용자가 사용할 수 있는 호스트 URL입니다.
port 외부 레지스트리 도메인이 수신하는 포트입니다.
api_url 레지스트리가 노출되는 내부 API URL입니다. 기본값은 http://localhost:5000입니다. 이는 외부 Docker 레지스트리 설정을 구성하는 것이 아니라면 변경하지 마십시오.
key rootcertbundle의 쌍인 레지스트리의 개인 키 위치입니다.
path 이 경로는 레지스트리의 rootdirectory에서 지정한 것과 동일해야 합니다. 이 경로는 GitLab 사용자, 웹 서버 사용자, 그리고 레지스트리 사용자가 읽을 수 있어야 합니다.
issuer 이 값은 레지스트리의 issuer에서 구성한 것과 동일해야 합니다.

소스로부터 GitLab을 설치한 경우 레지스트리 init 파일이 함께 제공되지 않습니다. 따라서 GitLab 다시 시작은 레지스트리를 다시 시작시키지 않습니다. 설정을 수정해야 하는 경우에는 상류 문서를 참조하세요.

최소한 다음과 같은 레지스트리 구성을 필수로 설정하세요 서비스가 container_registry이고 영역이 https://gitlab.example.com/jwt/auth임: 

auth:
  token:
    realm: https://gitlab.example.com/jwt/auth
    service: container_registry
    issuer: gitlab-issuer
    rootcertbundle: /root/certs/certbundle

경고: auth가 설정되지 않은 경우 사용자는 인증없이 Docker 이미지를 가져올 수 있습니다.

컨테이너 레지스트리 도메인 구성

레지스트리의 외부 도메인을 다음 중 하나의 방법으로 구성할 수 있습니다.

  • 기존 GitLab 도메인 사용. 레지스트리는 포트에서 리스닝하고 기존의 GitLab TLS 인증서를 재사용합니다.
  • 완전히 별개의 도메인 사용](#자체-도메인-아래-컨테이너-레지스트리-구성). 해당 도메인을 위한 새 TLS 인증서를 사용합니다.

컨테이너 레지스트리는 TLS 인증서가 필요하기 때문에 비용이 발생할 수 있습니다.

첫 번째로 컨테이너 레지스트리를 구성하기 전에 이를 고려해 보세요.

기존 GitLab 도메인 아래 컨테이너 레지스트리 구성

컨테이너 레지스트리가 기존의 GitLab 도메인을 사용하도록 구성된 경우, 레지스트리를 포트에서 노출시킬 수 있습니다. 이렇게 하면 기존의 GitLab TLS 인증서를 재사용할 수 있습니다.

GitLab 도메인이 https://gitlab.example.com이고 외부 세계로 노출되는 포트가 5050인 경우, 컨테이너 레지스트리를 구성하려면:

  • 리눅스 패키지 설치를 사용하는 경우 gitlab.rb를 편집합니다.
  • 자체 컴파일된 설치를 사용하는 경우 gitlab.yml을 편집합니다.

레지스트리가 기본적으로 사용하는 5000번 포트와 충돌을 피하려면 반드시 다른 포트를 선택하세요.

참고: 호스트 및 컨테이너 방화벽 규칙은 registry_external_url 줄 아래에 나열된 포트를 통해 트래픽을 허용하도록 구성되어 있어야 합니다. 이것은 gitlab_rails['registry_port'] (기본값인 5000) 아래에 나열된 포트보다 훨씬 중요합니다.

리눅스 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb 파일에 레지스트리 URL과 GitLab에서 사용하는 기존 TLS 인증서 및 키의 경로가 포함되어 있어야 합니다: 

    registry_external_url 'https://gitlab.example.com:5050'

    registry_external_url은 기존 GitLab URL 아래에서 HTTPS로 리스닝하나 다른 포트를 사용합니다.

    TLS 인증서가 /etc/gitlab/ssl/gitlab.example.com.crt에 있지 않거나 키가 /etc/gitlab/ssl/gitlab.example.com.key에 없다면 아래의 줄을 주석 처리하세요: 

    registry_nginx['ssl_certificate'] = "/path/to/certificate.pem"
registry_nginx['ssl_certificate_key'] = "/path/to/certificate.key"

  2. 변경 사항이 적용되도록 파일을 저장하고 GitLab을 다시 구성하세요.

  3. 다음 명령을 사용하여 유효성을 검사합니다: 

    openssl s_client -showcerts -servername gitlab.example.com -connect gitlab.example.com:5050 > cacert.pem

SSL 인증서 제공업체가 CA 번들 인증서를 제공하는 경우 이를 TLS 인증서 파일에 추가하세요.

관리자는 레지스트리를 5678과 같은 임의의 포트로 듣게 하고 싶을 수도 있습니다. 그러나 레지스트리와 애플리케이션 서버는 AWS 애플리케이션 로드 밸런서 뒤에 있으며 80 포트와 443 포트만 수신합니다. 관리자는 registry_external_url의 포트 번호를 삭제하여 HTTP 또는 HTTPS가 가정되도록 할 수 있습니다. 그런 다음 규칙이 작동하여 로드 밸런서를 임의의 포트로 설정합니다. 이는 사용자가 컨테이너 레지스트리의 docker login 예제에 의존할 경우 중요합니다. 다음은 예시입니다: 

registry_external_url 'https://registry-gitlab.example.com'
registry_nginx['redirect_http_to_https'] = true
registry_nginx['listen_port'] = 5678
자체 컴파일 (소스)

  1. /home/git/gitlab/config/gitlab.yml을 열고 registry 항목을 찾아 다음과 같이 구성하세요: 

    registry:
  enabled: true
  host: gitlab.example.com
  port: 5050
  2. 변경 사항이 적용되도록 파일을 저장하고 GitLab을 다시 시작하세요.
  3. NGINX에서도 관련된 변경을 수행하세요 (도메인, 포트, TLS 인증서 경로).

이제 사용자는 GitLab 자격 증명을 사용하여 다음 명령을 사용하여 컨테이너 레지스트리에 로그인할 수 있어야 합니다: 

docker login gitlab.example.com:5050

별도의 도메인에 컨테이너 레지스트리 구성

레지스트리가 자체 도메인을 사용하도록 구성된 경우 해당 특정 도메인(예: registry.example.com)에 대한 TLS 인증서가 필요합니다. 기존 GitLab 도메인의 하위 도메인으로 호스팅되는 경우 와일드카드 인증서가 필요할 수 있습니다. 예를 들어 *.gitlab.example.com은 registry.gitlab.example.com과 일치하는 와일드카드이며 *.example.com과는 구별됩니다.

수동으로 생성된 SSL 인증서 뿐만 아니라 Let’s Encrypt에서 자동으로 생성된 인증서도 Linux 패키지 설치에서 지원됩니다.

컨테이너 레지스트리가 https://registry.gitlab.example.com에서 접근 가능하도록 하려면 다음과 같이 합시다.

Linux 패키지 (Omnibus)

  1. TLS 인증서와 키를 /etc/gitlab/ssl/registry.gitlab.example.com.crt 및 /etc/gitlab/ssl/registry.gitlab.example.com.key에 위치시키고 올바른 권한이 있는지 확인하세요: 

    chmod 600 /etc/gitlab/ssl/registry.gitlab.example.com.*

  2. TLS 인증서가 준비되면 /etc/gitlab/gitlab.rb를 편집하여 다음을 추가하세요: 

    registry_external_url 'https://registry.gitlab.example.com'

    registry_external_url이 HTTPS로 처리되도록 합니다.

  3. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요.

와일드카드 인증서(와일드카드 인증서)가 있는 경우 URL 외에 인증서의 경로를 명시해야 합니다. 이 경우 /etc/gitlab/gitlab.rb는 다음과 같이 보일 것입니다: 

registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/certificate.pem"
registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
직접 컴파일(소스)

  1. /home/git/gitlab/config/gitlab.yml을 열고 registry 항목을 찾아 다음 설정으로 구성하세요: 

    registry:
  enabled: true
  host: registry.gitlab.example.com
  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 시작하세요.
  3. NGINX에서도 관련 변경 사항을 적용하세요(도메인, 포트, TLS 인증서 경로).

이제 사용자는 GitLab 자격 증명을 사용하여 컨테이너 레지스트리에 로그인할 수 있어야 합니다: 

docker login registry.gitlab.example.com

전체 사이트에서 컨테이너 레지스트리 비활성화

이러한 단계를 따라 레지스트리를 비활성화하면 기존 Docker 이미지가 제거되지는 않습니다. Docker 이미지 제거는 레지스트리 응용 프로그램 자체에서 처리합니다.

Linux 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb를 열고 registry['enable']를 false로 설정하세요: 

    registry['enable'] = false

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요.

직접 컴파일(소스)

  1. /home/git/gitlab/config/gitlab.yml을 열고 registry 항목을 찾아 enabled를 false로 설정하세요: 

    registry:
  enabled: false

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 시작하세요.

전체 사이트에서 새 프로젝트용 컨테이너 레지스트리 비활성화

컨테이너 레지스트리가 활성화된 경우 모든 새 프로젝트에서 사용할 수 있어야 합니다. 이 기능을 비활성화하고 프로젝트 소유자가 개별적으로 컨테이너 레지스트리를 활성화할 수 있도록하려면 다음 단계를 따르세요.

Linux 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb를 편집하고 다음 라인을 추가하세요: 

    gitlab_rails['gitlab_default_projects_features_container_registry'] = false

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요.

직접 컴파일(소스)

  1. /home/git/gitlab/config/gitlab.yml을 열고 default_projects_features 항목을 찾아 container_registry를 false로 설정하세요: 

    ## Default project features settings
default_projects_features:
  issues: true
  merge_requests: true
  wiki: true
  snippets: false
  builds: true
  container_registry: false

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 시작하세요.

토큰 기간 연장

GitLab에서 컨테이너 레지스트리 토큰은 매 5분마다 만료됩니다. 토큰 기간을 연장하려면 다음을 수행하세요.

  1. 왼쪽 사이드바에서 가장 아래에서 관리자를 선택하세요.
  2. 설정 > CI/CD를 선택하세요.
  3. 컨테이너 레지스트리를 확장하세요.
  4. 인가 토큰 기간(분)에 대한 값을 업데이트하세요.
  5. 변경 사항 저장을 선택하세요.

컨테이너 레지스트리의 저장소 구성

참고: 지원하는 저장소 백엔드를 사용하는 경우, 버킷에 저장된 각 객체의 이전 버전을 보존, 검색 및 복원하기 위해 객체 버전 관리를 사용할 수 있습니다. 그러나 이로 인해 저장 공간 사용량 및 비용이 증가할 수 있습니다. 레지스트리의 작동 방식 때문에 이미지 업로드는 먼저 임시 경로에 저장되고 그 후에 최종 위치로 전송됩니다. S3 및 GCS를 포함한 객체 저장소 백엔드에서는 이 전송을 복사 후 삭제로 수행합니다. 객체 버전 관리가 활성화된 경우 삭제된 임시 업로드 아티팩트는 비현재 버전으로 유지되어 저장 버킷 크기가 증가합니다. 비현재 버전이 일정 기간 후에 삭제되도록 보장하려면 저장소 공급자와 객체 수명주기 정책을 구성해야 합니다.

경고: 컨테이너 레지스트리에 의해 저장된 파일이나 객체를 직접 수정하지 마십시오. 이러한 항목은 레지스트리가 작성하거나 삭제하기 전에는 위험한 데이터 무결성 및 불안정성 문제를 일으킬 수 있으며 이러한 문제로부터 복구할 수 없을 수 있습니다.

컨테이너 레지스트리를 다양한 저장소 백엔드를 사용하도록 구성할 수 있습니다. 이를 위해 저장소 드라이버를 구성합니다. 기본적으로 GitLab 컨테이너 레지스트리는 파일 시스템 드라이버 구성되어 있습니다.

다음과 같은 다른 지원되는 드라이버가 있습니다:

드라이버 설명
filesystem 로컬 파일 시스템의 경로 사용
azure Microsoft Azure Blob Storage
gcs Google Cloud Storage
s3 Amazon Simple Storage Service. S3 Permission Scopes를 올바르게 구성해야 합니다.

대부분의 S3 호환 서비스(MinIO와 같은)는 컨테이너 레지스트리에서 작동해야 하지만, AWS S3에 대해 문제가 재현될 때까지는 문제를 해결할 수 없습니다.

파일 시스템 사용

이미지를 파일 시스템에 저장하려면 컨테이너 레지스트리의 저장 경로를 변경할 수 있습니다. 아래 단계를 따르세요.

이 경로는 다음과 같이 접근할 수 있습니다:

  • 컨테이너 레지스트리 데몬을 실행하는 사용자.
  • GitLab을 실행하는 사용자.

모든 GitLab, 레지스트리 및 웹 서버 사용자는 이 디렉터리에 접근해야 합니다.

Linux 패키지 (Omnibus)

Linux 패키지 설치의 기본 위치는 /var/opt/gitlab/gitlab-rails/shared/registry이며, 변경하려면 다음을 수행하세요:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다: 

    gitlab_rails['registry_path'] = "/path/to/registry/storage"

  2. 변경 사항이 적용되려면 파일을 저장하고 GitLab을 재구성하십시오.

:::

직접 컴파일한 경우 (소스)

직접 컴파일한 설치의 기본 위치는 /home/git/gitlab/shared/registry이며, 변경하려면 다음을 수행하세요:

  1. /home/git/gitlab/config/gitlab.yml을 열고 registry 항목을 찾아 path 설정을 변경합니다: 

    registry:
  path: shared/registry

  2. 변경 사항이 적용되려면 파일을 저장하고 GitLab을 다시 시작하십시오.

:::

객체 저장소 사용

이미지를 객체 저장소에 저장하려면 컨테이너 레지스트리의 저장 드라이버를 변경할 수 있습니다.

GitLab에서 객체 저장소 사용에 대해 자세히 알아보기.

경고: 파일 시스템에 저장되지 않은 Docker 이미지는 GitLab이 백업하지 않습니다. 원하는 경우 객체 저장소 제공 업체와 백업을 활성화하세요.

Linux 패키지 설치를 위한 s3 및 gcs 저장 드라이버 구성

다음 구성 단계는 s3 및 gcs 저장 드라이버를 위한 것입니다. 다른 저장 드라이버도 지원됩니다.

Linux 패키지 설치에서 s3 저장 드라이버를 구성하려면 다음을 수행하세요:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다: 

    registry['storage'] = {
  's3' => {
    'accesskey' => 's3-access-key',
    'secretkey' => 's3-secret-key-for-access-key',
    'bucket' => 'your-s3-bucket',
    'region' => 'your-s3-region',
    'regionendpoint' => 'your-s3-regionendpoint'
  }
}

    정적 자격 증명을 사용하지 않으려면 IAM 역할을 사용하고 accesskey 및 secretkey를 생략하세요. IAM 프로필이 Docker에서 문서화한 권한을 따르도록 확인하세요. 

    registry['storage'] = {
  's3' => {
    'bucket' => 'your-s3-bucket',
    'region' => 'your-s3-region'
  }
}

    AWS S3 VPC 엔드포인트를 사용하는 경우 regionendpoint를 VPC 엔드포인트 주소로 설정하고 pathstyle을 false로 설정하세요: 

    registry['storage'] = {
  's3' => {
    'accesskey' => 's3-access-key',
    'secretkey' => 's3-secret-key-for-access-key',
    'bucket' => 'your-s3-bucket',
    'region' => 'your-s3-region',
    'regionendpoint' => 'your-s3-vpc-endpoint',
    'pathstyle' => false
  }
}
    • regionendpoint는 MinIO와 같은 S3 호환 서비스를 구성하거나 AWS S3 VPC 엔드포인트를 사용할 때에만 필요합니다.
    • your-s3-bucket은 존재하는 버킷의 이름이어야 하며, 하위 디렉터리를 포함할 수 없습니다.
    • pathstyle은 host/bucket_name/object 스타일 경로 대신 bucket_name.host/object을 사용하려면 false로 설정하세요. AWS S3의 경우 false로 설정.

    S3 API에서 503 오류를 피하기 위해 S3에 대한 연결의 요청 속도 제한을 설정할 수 있습니다. 이를 위해 maxrequestspersecond을 S3 요청 속도 임계값 내의 숫자로 설정하세요: 

    registry['storage'] = {
  's3' => {
    'accesskey' => 's3-access-key',
    'secretkey' => 's3-secret-key-for-access-key',
    'bucket' => 'your-s3-bucket',
    'region' => 'your-s3-region',
    'regionendpoint' => 'your-s3-regionendpoint',
    'maxrequestspersecond' => 100
  }
}

  2. 변경 사항이 적용되려면 파일을 저장하고 GitLab을 재구성하십시오.

Linux 패키지 설치에서 gcs 저장 드라이버를 구성하려면 다음을 수행하세요:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다: 

    registry['storage'] = {
  'gcs' => {
    'bucket' => 'BUCKET_NAME',
    'keyfile' => 'KEYFILE/TO/PATH',
    # 레지스트리 이외의 다른 앱에서 버킷을 공유하는 경우 다음을 주석 처리하세요:
    # 'rootdirectory' => '/gcs/object/name/prefix'
  }
}

    GitLab은 사용 가능한 모든 매개변수를 지원합니다.

  2. 변경 사항이 적용되려면 파일을 저장하고 GitLab을 재구성하십시오.

직접 컴파일한 설치

저장 드라이버를 구성하는 작업은 Docker 레지스트리를 배포할 때 생성된 레지스트리 구성 YAML 파일에서 수행합니다.

s3 저장 드라이버 예시: 

storage:
  s3:
    accesskey: 's3-access-key'                # IAM 역할을 사용하는 경우 필요 없음
    secretkey: 's3-secret-key-for-access-key' # IAM 역할을 사용하는 경우 필요 없음
    bucket: 'your-s3-bucket'
    region: 'your-s3-region'
    regionendpoint: 'your-s3-regionendpoint'
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true

your-s3-bucket은 존재하는 버킷의 이름이어야 하며, 하위 디렉터리를 포함할 수 없습니다.

다운타임 없이 객체 스토리지로 이전하기

경고: S3 버킷에 있는 레지스트리 데이터를 복사할 때 또는 S3 버킷 간에 데이터를 복사할 때 AWS DataSync를 사용하면 버킷에 유효하지 않은 메타데이터가 생성됩니다. 자세한 내용은 empty name 태그를 참조하십시오. S3 버킷으로 데이터를 이동하려면 AWS CLI의 sync 작업을 권장합니다.

컨테이너 레지스트리를 중지하지 않고 저장소를 이관하려면 컨테이너 레지스트리를 읽기 전용 모드로 설정하세요. 대규모 인스턴스의 경우, 컨테이너 레지스트리가 잠시 동안 읽기 전용 모드여야 할 수 있습니다. 이 기간 동안 컨테이너 레지스트리에서는 가져오기만 가능하지만 푸시는 할 수 없습니다.

  1. 선택 사항: 이관할 데이터 양을 줄이려면 다운타임 없이 가비지 수집 도구 실행.

  2. 이 예시는 aws CLI를 사용합니다. CLI를 이전에 구성하지 않은 경우 sudo aws configure를 실행하여 자격 증명을 구성해야 합니다. 관리자가 아닌 사용자는 아마도 컨테이너 레지스트리 폴더에 액세스할 수 없을 것이므로 sudo를 사용하는지 확인하세요. 자격 증명 구성을 확인하려면 모든 버킷을 나열하려면 ls를 실행하세요. 

    sudo aws --endpoint-url https://your-object-storage-backend.com s3 ls

    AWS를 백엔드로 사용하는 경우에는 --endpoint-url이 필요하지 않습니다.

  3. 초기 데이터를 S3 버킷으로 복사합니다. 예: aws CLI의 cp 또는 sync 명령을 사용합니다. 상위 수준 폴더로 docker 폴더를 유지해야 합니다. 

    sudo aws --endpoint-url https://your-object-storage-backend.com s3 sync registry s3://mybucket

    참고: 많은 양의 데이터가 있는 경우 병렬 동기화 작업 실행으로 성능을 향상시킬 수 있습니다.

  4. 최종 데이터 동기화를 수행하려면컨테이너 레지스트리를 읽기 전용 모드로 설정하고 GitLab 구성을 다시 설정하세요.

  5. 초기 데이터 로드 이후의 변경 사항을 S3 버킷에 동기화하고 출처에는 없지만 대상 버킷에 있는 파일을 삭제하세요: 

    sudo aws --endpoint-url https://your-object-storage-backend.com s3 sync registry s3://mybucket --delete --dryrun

    명령이 예상대로 작동하는지 확인한 후에는 --dryrun 플래그를 제거하고 명령을 실행하세요.

    경고: --delete 플래그는 대상에는 있지만 출처에는 없는 파일을 삭제합니다. 출처와 대상을 바꾸면 레지스트리의 모든 데이터가 삭제됩니다.

  6. 모든 컨테이너 레지스트리 파일이 객체 스토리지로 업로드되었는지 확인하기 위해 다음 두 명령의 반환된 파일 수를 확인하세요: 

    sudo find registry -type f | wc -l

    sudo aws --endpoint-url https://your-object-storage-backend.com s3 ls s3://mybucket --recursive | wc -l

    이러한 명령의 출력은 _uploads 디렉터리 및 하위 디렉터리의 내용을 제외하고 일치해야 합니다.

  7. 레지스트리를 S3 버킷을 사용하도록 구성하세요.
  8. 변경 사항이 적용되려면 레지스트리를 읽기-쓰기 모드로 다시 설정하고 GitLab을 다시 구성하세요.

Azure 객체 스토리지로 이동

Linux 패키지 (Omnibus)
registry['storage'] = {
  'azure' => {
    'accountname' => '<your_storage_account_name>',
    'accountkey' => '<base64_encoded_account_key>',
    'container' => '<container_name>',
    'trimlegacyrootprefix' => true
  }
}
직접 컴파일된 (소스)
storage:
  azure:
    accountname: <your_storage_account_name>
    accountkey: <base64_encoded_account_key>
    container: <container_name>
    trimlegacyrootprefix: true

기본적으로 Azure Storage Driver는 core.windows.net 렘을 사용합니다. azure 섹션에서 realm에 다른 값을 설정할 수 있습니다(예: Azure Government Cloud의 경우 core.usgovcloudapi.net).

스토리지 드라이버에 대한 리디렉션 비활성화

기본적으로 원격 백엔드로 구성된 레지스트리에 액세스하는 사용자는 저장소 드라이버의 기본 백엔드로 리디렉션됩니다. 예를 들어 레지스트리는 요청을 리디렉션하여 GitLab 서버의 부하를 경감하기 위해 원격 S3 버킷을 사용하는 저장소 드라이버로 구성할 수 있습니다.

그러나 이 동작은 일반적으로 공용 서버에 액세스할 수 없는 내부 호스트가 사용하는 레지스트리에는 원치 않습니다. 리디렉션을 비활성화하고 프록시 다운로드를 설정하려면 다음과 같이 disable 플래그를 true로 설정하세요. 이렇게 하면 모든 트래픽이 항상 레지스트리 서비스를 통해 전달됩니다. 이로써 보안이 향상(저장소 백엔드에 공개적으로 액세스할 수 없으므로 공격 표면이 줄어듦)하지만 성능은 저하됩니다(모든 트래픽이 서비스를 통해 리디렉트되므로).

Linux 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb를 편집합니다. 

    registry['storage'] = {
  's3' => {
    'accesskey' => '<s3_access_key>',
    'secretkey' => '<s3_secret_key_for_access_key>',
    'bucket' => '<your_s3_bucket>',
    'region' => '<your_s3_region>',
    'regionendpoint' => '<your_s3_regionendpoint>'
  },
  'redirect' => {
    'disable' => true
  }
}

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.

직접 컴파일된 (소스)

  1. 레지스트리 구성 YAML 파일에 redirect 플래그를 추가합니다. 

    storage:
  s3:
    accesskey: '<s3_access_key>'
    secretkey: '<s3_secret_key_for_access_key>'
    bucket: '<your_s3_bucket>'
    region: '<your_s3_region>'
    regionendpoint: '<your_s3_regionendpoint>'
  redirect:
    disable: true
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 시작합니다.

암호화된 S3 버킷

SSE-S3 또는 SSE-KMS 암호화가 기본으로 활성화된 S3 버킷에 대해 AWS KMS와 함께 서버 측 암호화를 사용할 수 있습니다. 고객 마스터 키(CMK) 및 SSE-C 암호화는 모든 요청에 암호화 키를 전송해야 하기 때문에 지원되지 않습니다.

SSE-S3의 경우 레지스트리 설정에서 encrypt 옵션을 활성화해야 합니다. 이 작업은 GitLab을 설치한 방법에 따라 달라집니다. 설치 방법에 맞는 지침을 따르세요.

Linux 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb를 편집하세요: 

    registry['storage'] = {
  's3' => {
    'accesskey' => '<s3_access_key>',
    'secretkey' => '<s3_secret_key_for_access_key>',
    'bucket' => '<your_s3_bucket>',
    'region' => '<your_s3_region>',
    'regionendpoint' => '<your_s3_regionendpoint>',
    'encrypt' => true
  }
}

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요.

직접 컴파일(소스)

  1. 레지스트리 구성 YAML 파일을 편집하세요: 

    storage:
  s3:
    accesskey: '<s3_access_key>'
    secretkey: '<s3_secret_key_for_access_key>'
    bucket: '<your_s3_bucket>'
    region: '<your_s3_region>'
    regionendpoint: '<your_s3_regionendpoint>'
    encrypt: true

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 시작하세요.

저장소 제한

사용자는 무제한의 Docker 이미지를 임의의 크기로 업로드할 수 있기 때문에 저장소 제한이 없습니다. 이 설정은 향후 릴리스에서 구성 가능해야 합니다.

레지스트리의 내부 포트 변경

기본적으로 레지스트리 서버는 로컬호스트에서 포트 5000에서 수신 대기합니다. 아래 예제에서는 레지스트리의 포트를 5010으로 설정합니다.

Linux 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb을 열고 registry['registry_http_addr']를 설정하세요: 

    registry['registry_http_addr'] = "localhost:5010"

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요.

직접 컴파일(소스)

  1. 레지스트리 서버의 구성 파일을 열고 http:addr 값을 편집하세요: 

    http:
  addr: localhost:5010

  2. 파일을 저장하고 레지스트리 서버를 다시 시작하세요.

프로젝트 단위로 컨테이너 레지스트리 비활성화

GitLab 인스턴스에서 레지스트리가 활성화되어 있지만 프로젝트에는 필요하지 않은 경우 프로젝트 설정에서 비활성화할 수 있습니다.

GitLab를 인증 엔드포인트로 사용하는 외부 컨테이너 레지스트리 사용

경고: GitLab 15.8에서 GitLab에서 제3자 컨테이너 레지스트리의 사용이 폐지되었으며, GitLab 16.0에서 지원이 종료되었습니다. GitLab 컨테이너 레지스트리 대신 제3자 컨테이너 레지스트리를 사용해야 하는 경우 피드백 이슈 958에서 사용 사례를 알려주세요.

외부 컨테이너 레지스트리를 사용할 경우 컨테이너 레지스트리와 관련된 일부 기능이 사용할 수 없거나 내재적인 리스크가 있을 수 있습니다.

통합 작업을 위해 외부 레지스트리는 GitLab과의 인증을 위해 JSON Web Token을 사용하도록 구성되어야 합니다. 외부 레지스트리의 런타임 구성에는 다음과 같은 항목이 반드시 있어야 합니다: 

auth:
  token:
    realm: https://gitlab.example.com/jwt/auth
    service: container_registry
    issuer: gitlab-issuer
    rootcertbundle: /root/certs/certbundle

이러한 항목이 없으면 레지스트리 로그인이 GitLab과 인증할 수 없습니다. 또한 GitLab은 프로젝트 계층 구조 아래의 nested image names을 알지 못하며, registry.example.com/group/project/image-name:tag 또는 registry.example.com/group/project/my/image-name:tag와 같은 것만 인식합니다.

Linux 패키지 설치

외부 컨테이너 레지스트리를 GitLab의 인증 엔드포인트로 사용할 수 있습니다.

  1. /etc/gitlab/gitlab.rb을 열고 필요한 구성을 설정하세요: 

    gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_api_url'] = "https://<external_registry_host>:5000"
gitlab_rails['registry_issuer'] = "gitlab-issuer"
    • gitlab_rails['registry_enabled'] = true는 GitLab 컨테이너 레지스트리 기능과 인증 엔드포인트를 활성화하기 위해 필요합니다. 이를 활성화해도 GitLab 번들 컨테이너 레지스트리 서비스는 시작되지 않습니다.
    • gitlab_rails['registry_api_url'] = "http://<external_registry_host>:5000"은 레지스트리가 설치된 호스트와 일치하도록 변경해야 합니다. 외부 레지스트리가 TLS를 사용하도록 구성되어 있는 경우 https를 지정해야 합니다.

  2. GitLab과 외부 컨테이너 레지스트리가 안전하게 통신하려면 인증서-키 쌍이 필요합니다. 공개 인증서(rootcertbundle)로 외부 컨테이너 레지스트리를 구성하고, 개인 키로 GitLab을 구성해야 합니다. 이를 위해 /etc/gitlab/gitlab.rb에 다음을 추가하세요: 

    # registry['internal_key']에는 사용자 정의 키 파일의 내용이 들어 있어야 합니다. 키 파일의 줄 바꿈은 `\n` 문자를 사용하여 표시해야 합니다.
# 예시:
registry['internal_key'] = "---BEGIN RSA PRIVATE KEY---\nMIIEpQIBAA\n"

# Linux 패키지 설치용 커스텀 파일에 registry['internal_key']의 내용을 쓸 수 있도록 선택적으로 정의하세요.
gitlab_rails['registry_key_path'] = " /custom/path/to/registry-key.key"

    재구성을 실행할 때마다 registry_key_path에서 지정한 파일에 internal_key로 지정한 내용이 채워집니다.
    파일이 지정되지 않으면 Linux 패키지 설치는 이를 기본적으로 /var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key로 설정하고 채우게 됩니다.

  3. GitLab 컨테이너 레지스트리 페이지에 표시되는 컨테이너 레지스트리 URL을 변경하려면 다음 구성을 설정하세요: 

    gitlab_rails['registry_host'] = "registry.gitlab.example.com"
gitlab_rails['registry_port'] = "5005"

  4. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요.

자체 컴파일 설치

  1. /home/git/gitlab/config/gitlab.yml을 열고 registry 아래의 구성 설정을 편집하십시오: 

    ## 컨테이너 레지스트리

registry:
  enabled: true
  host: "registry.gitlab.example.com"
  port: "5005"
  api_url: "https://<external_registry_host>:5000"
  path: /var/lib/registry
  key: /path/to/keyfile
  issuer: gitlab-issuer

    더 보기 : 이러한 매개변수의 의미에 대해 더 알아보세요.

  2. 파일을 저장하고 변경 사항이 적용되려면 GitLab을 재시작하십시오.

컨테이너 레지스트리 통지 구성

컨테이너 레지스트리를 구성하여 레지스트리에서 발생하는 이벤트에 대한 웹훅 통지를 보낼 수 있습니다.

Docker Registry 통지 설명서에서 컨테이너 레지스트리 통지 구성 옵션에 대해 자세히 알아보세요.

경고: threshold 매개변수의 지원이 폐지되었으며, GitLab 17.0에서는 제거될 예정이며 18.0에서 제거될 예정입니다. 대신 maxretries를 사용하십시오.

컨테이너 레지스트리에 대해 여러 엔드포인트를 구성할 수 있습니다.

Linux 패키지 (Omnibus)

Linux 패키지 설치에 대한 통지 엔드포인트를 구성하려면:

  1. /etc/gitlab/gitlab.rb을 편집하십시오. 

    registry['notifications'] = [
  {
    'name' => 'test_endpoint',
    'url' => 'https://gitlab.example.com/api/v4/container_registry_event/events',
    'timeout' => '500ms',
    'threshold' => 5, # DEPRECATED: use `maxretries` instead.
    'maxretries' => 5,
    'backoff' => '1s',
    'headers' => {
      "Authorization" => ["AUTHORIZATION_EXAMPLE_TOKEN"]
    }
  }
]

gitlab_rails['registry_notification_secret'] = 'AUTHORIZATION_EXAMPLE_TOKEN' # Must match the auth token in registry['notifications']

    참고: AUTHORIZATION_EXAMPLE_TOKEN을 대소문자와 숫자로 시작하는 알파벳 문자열로 교체하십시오. < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo로 생성할 수 있습니다.

  2. 파일을 저장하고 변경 사항이 적용되려면 GitLab을 다시 구성하십시오.

자체 컴파일 (소스)

알림 엔드포인트를 구성하는 방법은 Docker 레지스트리를 배포할 때 생성된 레지스트리 구성 YAML 파일에 있습니다.

예시: 

notifications:
  endpoints:
    - name: alistener
      disabled: false
      url: https://my.listener.com/event
      headers: <http.Header>
      timeout: 500
      threshold: 5 # DEPRECATED: use `maxretries` instead.
      maxretries: 5
      backoff: 1000

지금 정책 삭제 실행

경고: 분산 아키텍처를 사용하고 Sidekiq이 다른 노드에서 실행 중인 경우 정책 삭제 기능이 작동하지 않습니다. 이를 해결하려면:

  1. Sidekiq 노드의 gitlab.rb 파일을 구성하여 올바른 레지스트리 URL을 가리키도록 합니다.
  2. registry.key 파일을 각 Sidekiq 노드로 복사합니다.

자세한 내용은 Sidekiq 구성 페이지를 참조하십시오.

특정 프로젝트에서 컨테이너 레지스트리 디스크 공간 사용량을 줄이려면, 관리자는 정책 삭제를 설정하고 가비지 수집을 실행할 수 있습니다.

프로젝트별 레지스트리 디스크 공간 사용

각 프로젝트에서 사용된 디스크 공간을 찾으려면 GitLab Rails 콘솔에서 다음을 실행하십시오: 

projects_and_size = [["project_id", "creator_id", "registry_size_bytes", "project path"]]
# 검토하려는 프로젝트를 지정해야 합니다. 여기에 가져올 수 있습니다.
projects = Project.last(100)

projects.each do |p|
   project_total_size = 0
   container_repositories = p.container_repositories

   container_repositories.each do |c|
       c.tags.each do |t|
          project_total_size = project_total_size + t.total_size unless t.total_size.nil?
       end
   end

   if project_total_size > 0
      projects_and_size << [p.project_id, p.creator&.id, project_total_size, p.full_path]
   end
end

# 콤마로 구분된 출력 형식으로 출력하십시오
projects_and_size.each do |ps|
   puts "%s,%s,%s,%s" % ps
end

정책 삭제를 실행하여 이미지 태그를 제거하려면 GitLab Rails 콘솔에서 다음 명령을 실행하십시오: 

# 컨테이너 레지스트리를 정리해야 하는 프로젝트의 숫자 ID
P = <project_id>

# 프로젝트에 대한 Developer, Maintainer 또는 Owner 역할을 가진 사용자의 숫자 ID
U = <user_id>

# 필요한 세부 정보 / 객체 가져오기
user    = User.find_by_id(U)
project = Project.find_by_id(P)
policy  = ContainerExpirationPolicy.find_by(project_id: P)

# 각 컨테이너 레지스트리를 반복해서 실행합니다.
project.container_repositories.find_each do |repo|
  puts repo.attributes

  # 태그 정리 시작
  puts Projects::ContainerRepository::CleanupTagsService.new(container_repository: repo, current_user: user, params: policy.attributes.except("created_at", "updated_at")).execute
end

일정에 맞춰 정책 삭제를 실행하려면 여기를 참조하십시오.

모든 프로젝트에 대해 정책 삭제를 활성화하려면, 정책 삭제가 비활성화된 컨테이너 레지스트리를 가진 모든 프로젝트를 찾아야 합니다: 

# 컨테이너 레지스트리가 활성화되고 정책 삭제가 비활성화된 모든 프로젝트 찾기

projects = Project.find_by_sql ("SELECT * FROM projects WHERE id IN (SELECT project_id FROM container_expiration_policies WHERE enabled=false AND id IN (SELECT project_id FROM container_repositories))")

# 각 프로젝트를 반복합니다.
projects.each do |p|

# 프로젝트 ID 및 프로젝트 전체 이름 출력
    puts "#{p.id},#{p.full_name}"
end

컨테이너 레지스트리 메타데이터 데이터베이스

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

메타데이터 데이터베이스는 온라인 가비지 수집과 많은 레지스트리 작업의 효율성을 높이는 등 많은 새로운 레지스트리 기능을 제공합니다. 자세한 내용은 컨테이너 레지스트리 메타데이터 데이터베이스 페이지를 참조하십시오.

컨테이너 레지스트리 가비지 수집

note
Amazon S3 Lifecycle과 같은 객체 스토리지 제공 업체의 보존 정책은 객체를 제대로 삭제하지 못할 수 있습니다.

컨테이너 레지스트리는 상당량의 저장 공간을 사용할 수 있으며, 저장 공간 사용량을 줄이기를 원할 수 있습니다. 나열된 옵션 중 태그 삭제가 가장 효과적인 옵션입니다. 그러나 태그 삭제만으로는 이미지 레이어가 삭제되지 않으며, 레이어는 언더라이인 이미지 매니페스트만 언태깅합니다.

보다 효율적으로 공간을 확보하려면 컨테이너 레지스트리에는 참조되지 않는 레이어 및 (선택적으로) 언태깅된 매니페스트를 삭제할 수 있는 가비지 컬렉터가 있습니다.

가비지 컬렉터를 시작하려면 gitlab-ctl에서 제공하는 registry-garbage-collect 명령을 사용하십시오.

caution
이 명령은 가비지 수집 전에 컨테이너 레지스트리를 중지하며, 가비지 수집이 완료된 후에만 다시 시작합니다. 다운타임을 피하길 원하는 경우 컨테이너 레지스트리를 수동으로 읽기 전용 모드로 설정하고 gitlab-ctl을 우회하세요.

가비지 수집을 수행하는 데 필요한 시간은 컨테이너 레지스트리 데이터 크기에 비례합니다.

전제 조건:

  • 리눅스 패키지나 GitLab Helm 차트를 사용하여 GitLab을 설치했어야 합니다.

콘텐츠 주소 지정 레이어 이해

다음 예제를 고려해보겠습니다. 먼저 이미지를 빌드한 후: shell # sha256:111111의 컨텐츠로 이미지를 빌드합니다. docker build -t my.registry.com/my.group/my.project:latest . docker push my.registry.com/my.group/my.project:latest

이제 :latest를 새 버전으로 덮어씁니다: shell # sha256:222222의 컨텐츠로 이미지를 빌드합니다. docker build -t my.registry.com/my.group/my.project:latest . docker push my.registry.com/my.group/my.project:latest

이제 :latest 태그가 sha256:222222의 매니페스트를 가리킵니다. 레지스트리 아키텍처로 인해, 이 데이터는 여전히 :latest 태그로 직접 액세스하는 것은 아니지만 이미지 my.registry.com/my.group/my.project@sha256:111111을 끌어올 때에는 이 데이터에 여전히 액세스할 수 있습니다.

참조되지 않는 레이어 삭제

이미지 레이어는 컨테이너 레지스트리 저장 공간의 대부분입니다. 이미지 매니페스트가 참조하지 않는 레이어는 참조되지 않는 레이어로 간주됩니다. 참조되지 않는 레이어는 컨테이너 레지스트리 가비지 컬렉터의 기본 대상입니다.

구성 파일의 기본 위치를 변경하지 않은 경우 다음 명령을 실행하십시오: shell sudo gitlab-ctl registry-garbage-collect

컨테이너 레지스트리 config.yml의 위치를 변경한 경우: 

sudo gitlab-ctl registry-garbage-collect /path/to/config.yml

또한 모든 언태깅된 매니페스트 및 참조되지 않는 레이어를 제거하여 추가 공간을 회복할 수 있습니다.

모든 언태깅된 매니페스트 및 참조되지 않는 레이어 제거

기본적으로 컨테이너 레지스트리 가비지 컬렉터는 언태그된 이미지를 무시하며, 사용자는 다이제스트를 사용하여 계속해서 언테그된 이미지를 끌어올 수 있습니다. 사용자는 미래에 이미지를 다시 태그하여 GitLab UI 및 API에서 다시 볼 수 있습니다.

언태그된 이미지 및 이러한 이미지에 유일하게 참조되는 레이어에만 관심이 없는 경우 이들을 모두 삭제할 수 있습니다. registry-garbage-collect 명령에 -m 플래그를 사용하십시오: shell sudo gitlab-ctl registry-garbage-collect -m

언태그된 이미지를 삭제할지 확신이 없는 경우 진행하기 전에 레지스트리 데이터를 백업하십시오.

다운타임 없이 가비지 수집 수행

컨테이너 레지스트리를 온라인 상태로 유지하면서 가비지 수집을 하려면 레지스트리를 읽기 전용 모드로 설정하고 내장된 gitlab-ctl registry-garbage-collect 명령을 우회하십시오.

컨테이너 레지스트리가 읽기 전용 모드에 있을 때는 이미지를 끌어올 수 있지만 이미지를 업로드할 수는 없습니다. 컨테이너 레지스트리는 가비지 수집하는 동안 계속해서 읽기 전용 상태여야 합니다.

기본적으로 레지스트리 저장 위치는 /var/opt/gitlab/gitlab-rails/shared/registry입니다.

읽기 전용 모드를 활성화하려면:

  1. /etc/gitlab/gitlab.rb에 읽기 전용 모드를 지정하십시오: 

    registry['storage'] = {
  'filesystem' => {
    'rootdirectory' => "<your_registry_storage_path>"
  },
  'maintenance' => {
    'readonly' => {
      'enabled' => true
    }
  }
}

  2. 변경 사항을 저장하고 GitLab을 재구성하십시오: 

    sudo gitlab-ctl reconfigure

    이 명령은 컨테이너 레지스트리를 읽기 전용 모드로 설정합니다.

  3. 다음으로 가비지 수집 명령 중 하나를 트리거하십시오: 

    # 참조되지 않는 레이어 삭제
sudo /opt/gitlab/embedded/bin/registry garbage-collect /var/opt/gitlab/registry/config.yml

# 언태그된 매니페스트 및 참조되지 않는 레이어 삭제
sudo /opt/gitlab/embedded/bin/registry garbage-collect -m /var/opt/gitlab/registry/config.yml

    이 명령은 가비지 수집을 시작합니다. 완료하는 데 필요한 시간은 레지스트리 데이터 크기에 비례합니다.

  4. 완료되면 /etc/gitlab/gitlab.rb에서 다시 쓰기 모드로 변경하십시오: 

    registry['storage'] = {
  'filesystem' => {
    'rootdirectory' => "<your_registry_storage_path>"
  },
  'maintenance' => {
    'readonly' => {
      'enabled' => false
    }
  }
}

  5. 변경 사항을 저장하고 GitLab을 재구성하십시오: 

    sudo gitlab-ctl reconfigure

일정에 따른 가비지 수집 실행

이상적으로 레지스트리의 가비지 수집은 레지스트리를 사용하지 않을 시간에 정기적으로 주간 기준으로 실행할 수 있어야 합니다. 가장 간단한 방법은 주간으로 주기적으로 실행되도록 새로운 crontab 작업을 추가하는 것입니다.

/etc/cron.d/registry-garbage-collect에 파일을 생성하십시오: 

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# 매주 일요일 새벽 4:05에 실행
5 4 * * 0  root gitlab-ctl registry-garbage-collect

언탱된 매니페스트 및 참조되지 않는 레이어를 제거하기 위해 -m 플래그를 추가하는 것이 좋습니다.

쓰레기 수집 중지

쓰레기 수집을 중지할 예정이라면 가동 중지 없는 쓰레기 수집 실행에 설명된대로 수동으로 쓰레기 수집을 실행해야 합니다. 그런 다음 Control+C를 눌러 쓰레기 수집을 중지할 수 있습니다.

그렇지 않으면 gitlab-ctl을 중단하면 레지스트리 서비스가 다운 상태가 될 수 있습니다. 이 경우 gitlab-ctl 명령이 레지스트리 서비스를 다시 가동할 수 있도록 시스템에서 쓰레기 수집 프로세스를 찾아야 합니다.

또한 프로세스의 마킹 단계 동안 진행 상황이나 결과를 저장하는 방법이 없습니다. 삭제가 시작된 후에만 영구 작업이 수행됩니다.

지속적인 중단 없는 쓰레기 수집

메타데이터 데이터베이스로 이전하면 스케줄링할 필요 없이 배경에서 쓰레기 수집을 실행하고 읽기 전용 모드도 필요하지 않습니다. (메타데이터 데이터베이스로 마이그레이션한다면)

GitLab 및 Registry를 별도 노드(Linux 패키지 설치)에서 실행하도록 구성

기본적으로 패키지는 두 서비스가 동일한 노드에서 실행중이라고 가정합니다. GitLab 및 Registry를 별도의 노드에서 실행하려면 Registry 및 GitLab에 대해 별도의 구성이 필요합니다.

레지스트리 구성

Registry가 GitLab과 별도로 실행되도록 하려면 /etc/gitlab/gitlab.rb에서 설정해야 하는 구성 옵션을 찾을 수 있습니다:

  • registry['registry_http_addr'], 기본 프로그래밍적으로 설정. Web 서버(또는 LB)에서 접근 가능해야 합니다.
  • registry['token_realm'], 기본 프로그래밍적으로 설정. 일반적으로 GitLab URL인 인증을 수행할 엔드포인트를 지정합니다. 이 엔드포인트는 사용자가 접근할 수 있어야 합니다.
  • registry['http_secret'], 랜덤 문자열. 클라이언트에서 데이터 탐지를 방지하기 위해 저장될 수 있는 상태를 서명하는 데 사용되는 무작위 데이터 조각입니다.
  • registry['internal_key'], 기본 자동으로 생성됨. GitLab이 토큰을 서명하는 데 사용하는 키의 내용입니다. 이 키는 Registry 서버에서 생성되지만 여기서 사용되지는 않습니다.
  • gitlab_rails['registry_key_path'], 기본 프로그래밍적으로 설정. internal_key 내용이 디스크에 기록되는 경로입니다.
  • registry['internal_certificate'], 기본 자동으로 생성됨. GitLab이 토큰을 서명하는 데 사용하는 인증서의 내용입니다.
  • registry['rootcertbundle'], 기본 프로그래밍적으로 설정. 인증서 내용이 디스크에 기록되는 경로입니다.
  • registry['health_storagedriver_enabled'], 기본 프로그래밍적으로 설정. 구성된 스토리지 드라이버의 상태 확인이 활성화되는지 구성합니다.
  • gitlab_rails['registry_issuer'], 기본값. 이 설정은 Registry와 GitLab 간에 동일하게 설정해야 합니다.

GitLab 구성

GitLab이 Registry와 별도로 실행되도록 하려면 /etc/gitlab/gitlab.rb에서 설정해야 하는 구성 옵션을 찾을 수 있습니다:

  • gitlab_rails['registry_enabled'], true로 설정해야 합니다. 이 설정은 GitLab에게 레지스트리 API 요청을 허용해야 함을 나타냅니다.
  • gitlab_rails['registry_api_url'], 기본 프로그래밍적으로 설정. 사용자가 상호작용할 필요가 없는 Registry URL입니다. registry['registry_http_addr']로 시작합니다.
  • gitlab_rails['registry_host'], 예: registry.gitlab.example. 스킴 없는 레지스트리 엔드포인트, 최종 사용자에게 표시되는 주소입니다.
  • gitlab_rails['registry_port']. 최종 사용자에게 표시되는 레지스트리 엔드포인트 포트입니다.
  • gitlab_rails['registry_issuer]`, Registry 구성의 발급자와 일치해야 합니다.
  • gitlab_rails['registry_key_path'], Registry 측 인증서와 일치하는 키의 경로입니다.
  • gitlab_rails['internal_key'], GitLab이 토큰을 서명하는 데 사용하는 키의 내용입니다.

GitLab 컨테이너 레지스트리 아키텍처

GitLab 레지스트리는 사용자가 자체 Docker 이미지를 저장하는 데 사용됩니다. 그러므로 Registry는 클라이언트를 대상으로 하므로 웹 서버(또는 로드 밸런서, LB)에 직접 노출됩니다.

GitLab Registry 다이어그램

위 다이어그램에 설명된 흐름:

  1. 사용자가 클라이언트에서 docker login registry.gitlab.example을 실행합니다. 이는 443번 포트로 웹 서버(또는 LB)에 도달합니다.
  2. 웹 서버가 Registry 백엔드 풀(기본적으로 5000번 포트를 사용)에 연결합니다. 사용자가 유효한 토큰을 제공하지 않았기 때문에 Registry는 401 HTTP 코드와 토큰을 얻을 수 있는 URL(Registry configuration의 token_realm)을 제공합니다. 이 URL은 GitLab API를 가리킵니다.
  3. Docker 클라이언트가 GitLab API에 연결하고 토큰을 얻습니다.
  4. API는 토큰을 레지스트리 키로 서명하고 Docker 클라이언트에 전달합니다.
  5. 이제 Docker 클라이언트가 API에서 받은 토큰으로 다시 로그인합니다. 이제 Docker 이미지를 푸시하고 끌어올릴 수 있습니다.

참고: https://distribution.github.io/distribution/spec/auth/token/

GitLab과 레지스트리 간 통신

레지스트리는 내부 사용자를 인증할 수 있는 방법이 없으므로 자격 증명을 확인하기 위해 GitLab에 의존합니다. 레지스트리와 GitLab 간의 연결은 TLS로 암호화됩니다. 키는 GitLab이 토큰에 서명하는 데 사용되며, 인증서는 레지스트리가 서명을 확인하는 데 사용됩니다. 기본적으로 모든 설치에 대해 자체 서명 인증서 키 쌍이 생성됩니다. 필요에 따라 이를 재정의할 수 있습니다.

GitLab은 레지스트리와 상호 작용할 때 레지스트리의 개인 키를 사용합니다. 레지스트리 요청이 발생하면 새로운 단기간(10분)의 네임스페이스 제한 토큰이 생성되고 개인 키로 서명됩니다. 그런 다음 레지스트리는 서명이 레지스트리 구성에서 지정된 레지스트리 인증서와 일치하는지 확인하고 작업을 허용합니다. 또한 GitLab 백그라운드 작업 처리(통해 Sidekiq)도 레지스트리와 상호 작용합니다. 이러한 작업은 이미지 삭제를 처리하기 위해 레지스트리로 직접 통신합니다.

제3자 레지스트리에서 마이그레이션

GitLab 15.8에서 GitLab을 통한 외부 컨테이너 레지스트리 사용이 폐기(dprecated)되었으며, 지원 종료는 GitLab 16.0에서 발생했습니다. 자세한 내용은 폐기 통지를 참조하십시오.

GitLab 16.0에서는 통합이 비활성화되었지만 디버깅 및 문제 해결 지원은 더 이상 제공되지 않습니다. 게다가, 통합은 더 이상 개발되거나 새로운 기능으로 개량되지 않습니다. 제3자 레지스트리 기능은 새로운 GitLab 컨테이너 레지스트리 버전이 자체 관리 되는 경우 완전히 제거될 수 있습니다(에픽 5521 참조). 계획대로 GitLab 컨테이너 레지스트리만 지원할 예정입니다.

본 섹션에서는 관리자가 제3자 레지스트리에서 GitLab 컨테이너 레지스트리로 마이그레이션하는 지침을 제공합니다. 사용 중인 제3자 컨테이너 레지스트리가 여기에 나열되어 있지 않은 경우 피드백 이슈에서 사용 사례를 설명할 수 있습니다.

아래 제공된 모든 지시 사항에 대해 먼저 테스트 환경에서 시도해 보십시오. 제대로 작동하는지 확인한 후 복제하기 전에 모든 것이 예상대로 작동하도록 하십시오.

Docker 분배 레지스트리

Docker 분산 레지스트리가 CNCF에 기증되었으며 이제 분산 레지스트리로 알려져 있습니다. 이 레지스트리는 GitLab 컨테이너 레지스트리가 기반으로 한 오픈 소스 구현체입니다. GitLab 컨테이너 레지스트리는 분산 레지스트리에서 제공하는 기본 기능과 모든 지원하는 저장소 백엔드를 포함하여 호환됩니다. GitLab 컨테이너 레지스트리로 마이그레이션하려면 이 페이지의 지침을 따르고 분산 레지스트리와 동일한 저장소 백엔드를 사용하십시오. GitLab 컨테이너 레지스트리는 분산 레지스트리에 사용 중인 구성을 허용해야 합니다.