GitLab 그룹 및 프로젝트를 직접 이전하는 방법

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • GitLab 13.7에 도입, 기본적으로 비활성화된 bulk_import 플래그를 사용하여 그룹 리소스에 대한 그룹 항목을 지정.
  • GitLab 14.3에서 GitLab.com 및 Self-managed에서 활성화됨.
  • GitLab 14.4에 도입, 기본적으로 비활성화된 bulk_import_projects 플래그를 사용하여 프로젝트 리소스에 대한 그룹 항목을 지정.
  • GitLab 15.6에서 GitLab.com에서 활성화됨.
  • GitLab 15.8에서 새로운 애플리케이션 설정 bulk_import_enabled 도입. bulk_import 피처 플래그가 제거됨.
  • GitLab 15.10에서 bulk_import_projects 피처 플래그가 제거됨.

GitLab 그룹을 다음과 같이 마이그레이션할 수 있습니다:

  • Self-managed GitLab에서 GitLab.com으로.
  • GitLab.com에서 Self-managed GitLab으로.
  • 한 Self-managed GitLab 인스턴스에서 다른 곳으로.
  • 동일한 GitLab 인스턴스 내의 그룹 간.

그룹을 두 가지 방법으로 마이그레이션할 수 있습니다:

GitLab.com에서 Self-managed GitLab으로 마이그레이션하는 경우, 관리자는 Self-managed GitLab 인스턴스에서 사용자를 생성할 수 있습니다.

Self-managed GitLab에서 기본적으로 그룹 항목 마이그레이션이 사용할 수 없습니다. 기능 표시를 보여주려면 관리자가 애플리케이션 설정에서 이를 활성화할 수 있습니다.

직접 이전을 통해 그룹을 마이그레이션하면 해당 그룹을 한 곳에서 다른 곳으로 복사할 수 있습니다. 다음과 같은 작업을 수행할 수 있습니다:

  • 한 번에 여러 그룹을 복사.
  • GitLab UI에서 다음 위치로 상위 그룹을 복사:
    • 다른 상위 그룹.
    • 기존 상위 그룹의 하위 그룹.
    • GitLab.com을 포함한 다른 GitLab 인스턴스.
  • API에서 다음 위치로 상위 그룹 및 하위 그룹을 복사.
  • (베타)에서 프로젝트와 함께 그룹을 복사(제품 사용에는 안전하지 않음)하거나 프로젝트 없이 복사할 수 있음. 프로젝트와 함께 그룹을 복사하는 것은 다음에서 사용할 수 있음:
    • 기본적으로 GitLab.com에서.

그룹 및 프로젝트 리소스가 모두 복사되지는 않습니다. 아래 복사된 리소스 디렉터리을 참조하세요:

caution
프로젝트가 포함된 그룹을 가져오는 것은 베타 상태입니다. 이 기능은 제품 사용에 적합하지 않습니다.

직접 전송에 의한 마이그레이션에 대한 피드백을 남기고 싶다면, 피드백 이슈에 남겨주시기 바랍니다.

그룹을 복사하는 대신 이동시키고 싶을 경우, 동일한 GitLab 인스턴스 내에서 그룹을 이전할 수 있습니다. 그룹을 이전하는 것이 더 빠르고 완전한 옵션입니다.

알려진 문제

  • 이슈 406685로 인해 파일 이름이 255자보다 긴 파일은 마이그레이션되지 않습니다.
  • GitLab 16.1 및 이전 버전에서, 예정된 스캔 실행 정책을 사용해서는 직접 전송을 사용하지 않아야 합니다.
  • 다른 알려진 문제 디렉터리은 epic 6629를 참조하세요.
  • GitLab 16.9 이전에, 이슈 438422로 인해 DiffNote::NoteDiffFileCreationError 오류가 발생할 수 있습니다. 이 오류가 발생하면 Merge Request의 Diff에서 메모의 일부가 누락되지만 메모 및 Merge Request은 여전히 가져와집니다.

마이그레이션 기간 추정

직접 전송에 의한 마이그레이션 기간을 추정하는 것은 어렵습니다. 마이그레이션 기간에 영향을 주는 요인은 다음과 같습니다:

  • 소스 및 대상 GitLab 인스턴스에서 사용 가능한 하드웨어 및 데이터베이스 리소스. 소스 및 대상 인스턴스에 더 많은 리소스가 있으면 다음과 같은 이유로 마이그레이션 기간이 짧아질 수 있습니다:
    • 소스 인스턴스는 API 요청을 받아들이고, 엔티티를 추출하고 내보내기 위해 직렬화.
    • 대상 인스턴스는 작업을 실행하고 데이터베이스에 엔티티를 작성.
  • 내보낼 데이터의 복잡성 및 크기. 예를 들어, 1000개의 Merge Request이 있는 두 가지 다른 프로젝트를 마이그레이션하고 싶다고 가정해보십시오. 두 프로젝트는 Merge Request에서 첨부 파일, 코멘트 및 기타 항목이 훨씬 더 많은 경우 한 프로젝트가 다른 프로젝트보다 훨씬 더 오랜 시간이 걸릴 수 있습니다. 따라서 프로젝트의 Merge Request 수는 프로젝트를 마이그레이션하는 데 걸리는 시간을 예측하는 데 적합한 지표가 아닙니다.

마이그레이션을 신뢰할 수 있는 정확한 공식은 없습니다. 그러나 각 파이프라인 워커가 프로젝트 관계를 가져오는 데 걸리는 평균 시간은 다음과 같은 기간을 추정하는 데 도움이 될 수 있습니다:

프로젝트 리소스 유형 레코드를 가져오는 평균 시간(초)
빈 프로젝트 2.4
리포지터리 20
프로젝트 속성 1.5
구성원 0.2
라벨 0.1
마일스톤 0.07
뱃지 0.1
이슈 0.1
스니펫 0.05
스니펫 리포지터리 0.5
보드 0.1
Merge Request 1
외부 풀 요청 0.5
보호된 브랜치 0.1
프로젝트 기능 0.3
컨테이너 만료 정책 0.3
서비스 데스크 설정 0.3
릴리스 0.1
CI 파이프라인 0.2
커밋 노트 0.05
위키 10
업로드 0.5
LFS 객체 0.5
디자인 0.1
자동 DevOps 0.1
파이프라인 스케줄 0.5
참조 5
푸시 규칙 0.1

대규모 프로젝트를 마이그레이션하고 마이그레이션 기간 또는 타임아웃에 문제가 발생할 경우, 마이그레이션 기간을 줄이는 방법을 참조하세요.

제한

직접 전송에 의한 마이그레이션에 하드코딩된 제한이 적용됩니다.

제한 설명
6 사용자 당 대상 GitLab 인스턴스에서 허용되는 최대 마이그레이션 수. 사용자 1분당. GitLab 15.9에서 도입.
210 초 아카이브 파일을 압축해제하는 데 기다릴 수 있는 최대 시간 (초).
50 MB NDJSON 행이 가질 수 있는 최대 길이.
5 분 소스 인스턴스에서 빈 내보내기 상태가 발생할 때까지의 최대 시간 (초).

구성 가능한 제한도 사용할 수 있습니다.

GitLab 16.3 이상에서 다음과 같이 이전에는 하드코딩된 설정은 구성 가능하도록 변경되었습니다:

  • 소스 인스턴스에서 다운로드할 수있는 최대 관계 크기 (5GiB로 설정).
  • 압축 해제된 아카이브의 최대 크기 (10GiB로 설정).

다음 API를 사용하여 최대 관계 크기 제한을 테스트할 수 있습니다:

두 API 중 어느 하나라도 최대 관계 크기 제한보다 큰 파일을 생성하는 경우, 직접 전송에 의한 그룹 이주가 실패합니다.

가시성 규칙

이주 후:

  • 비공개 그룹 및 프로젝트는 비공개 상태를 유지합니다.
  • 내부 그룹 및 프로젝트 :
    • 내부 그룹에 복사되었을 때 내부 상태를 유지합니다. 내부 가시성이 [제한될 때] (../../../administration/settings/visibility_and_access_controls.md#restrict-visibility-levels).그런 경우, 그룹 및 프로젝트가 비공개로 전환됩니다.
    • 비공개 그룹에 복사되었을 때 비공개 상태가됩니다.
  • 공개 그룹 및 프로젝트 :
    • 공개 그룹에 복사되는 경우 공개 상태를 유지합니다. 공개 가시성이 [제한될 때] (../../../administration/settings/visibility_and_access_controls.md#restrict-visibility-levels).그런 경우, 그룹 및 프로젝트가 내부로 전환됩니다.
    • 내부 그룹에 복사되는 경우 내부 상태를 유지합니다. 내부 가시성이 [제한될 때] (../../../administration/settings/visibility_and_access_controls.md#restrict-visibility-levels).그런 경우, 그룹 및 프로젝트가 비공개로 전환됩니다.
    • 비공개 그룹에 복사되는 경우 비공개 상태가됩니다.

소스 인스턴스에서 일반 대중에게 콘텐츠를 숨기기 위해 개인 네트워크를 사용한 경우 대상 인스턴스에서 유사한 설정이나 비공개 그룹으로 가져오기위합니다.

사전 요구 사항

  • GitLab 16.0에서 Developer 역할 대신 Maintainer 역할을 필요로 함. GitLab 15.11.1 및 GitLab 15.10.5에 백포트됨.

직접 전송을 사용하여 마이그레이션하기 전에 다음 사전 요구 사항을 확인하세요.

네트워크

  • 인스턴스 또는 GitLab.com 간의 네트워크 연결은 HTTPS를 지원해야합니다.
  • 방화벽이 소스 및 대상 GitLab 인스턴스 간의 연결을 차단해서는 안됩니다.

버전

소스 GitLab 인스턴스는 그룹을 가져오려면 GitLab 14.0 이상, 프로젝트를 가져오려면 GitLab 14.4 이상이어야합니다. 그러나 성공적이고 성능이 향상된 마이그레이션을 보장하기 위해 다음을 권장합니다:

  • 일괄적인 내보내기 및 가져오기를 활용하기 위해 소스 및 대상 인스턴스를 GitLab 16.2 이상으로 업데이트합니다.
  • 가능한 최신 버전 간에 이주합니다. 시간이 경과함에 따라 추가 된 버그 수정 및 개선 기능을 활용하려면 소스 및 대상 인스턴스를 최신 버전으로 업데이트하세요.

16.2에서 실행중인 소스 인스턴스와 16.8에서 실행중인 대상 인스턴스 간에 마이그레이션을 성공적으로 테스트했습니다.

구성

  • 두 GitLab 인스턴스에서 인스턴스 관리자에 의해 직접 전송에 의한 그룹 마이그레이션이 활성화되어 있어야합니다.
  • 소스 GitLab 인스턴스에 대한 개인 액세스 토큰이 있어야합니다.
    • GitLab 15.1 이상 소스 인스턴스의 경우, 개인 액세스 토큰에는 api 스코프가 있어야합니다.
    • GitLab 15.0 및 이전 소스 인스턴스의 경우, 개인 액세스 토큰에는 apiread_repository 스코프가 모두 있어야합니다.
  • 마이그레이션할 소스 그룹의 소유자 역할이 있어야합니다.
  • 그룹에서 서브 그룹을 생성할 수있는 대상 네임 스페이스에서 역할이 있어야합니다.
  • 객체 리포지터리에 저장된 항목을 가져 오려면 다음 중 하나를해야합니다:
    • proxy_download구성합니다.
    • 대상 GitLab 인스턴스가 소스 GitLab 인스턴스의 개체 리포지터리에 액세스 할 수 있도록 합니다.
  • 소스 인스턴스 또는 그룹에 기본 프로젝트 생성 보호아무도로 설정되어 있지 않으면 프로젝트로 그룹을 가져올 수 없습니다. 필요한 경우이 설정을 다음과 같이 변경할 수 있습니다:

사용자 계정

GitLab이 사용자 및 해당 기여를 올바르게 매핑하도록하려면 다음을 보증해야합니다:

  1. 대상 GitLab 인스턴스에 필요한 사용자를 만듭니다. 관리자 액세스가 필요하기 때문에 Self-managed 인스턴스에서는 API로만 사용자를 만들 수 있습니다. GitLab.com이나 Self-managed GitLab 인스턴스로 마이그레이션하는 경우 다음을 수행 할 수 있습니다:
    • 매뉴얼으로 사용자를 만듭니다.
    • 설정 또는 기존 [SAML SSO 공급자] (../saml_sso/index.md)를 설정하거나 사용하고 SCIM을 지원하는 SAML SSO 그룹의 사용자 동기화를 활용합니다. [확인된 이메일 도메인으로 사용자 이메일 확인을 우회합니다] (../saml_sso/index.md#bypass-user-email-confirmation-with-verified-domains).
  2. 사용자가 대상 GitLab 인스턴스에서 확인 된 이메일 주소와 일치하는 [공개 이메일] (../../profile/index.md#set-your-public-email)을 가지고 있는지 확인합니다. 대부분의 사용자는 이메일 주소를 확인하라는 이메일을받습니다.
  3. 사용자가 대상 인스턴스에 이미 존재하고 [SAML SSO를 사용하여 GitLab.com 그룹] (../../group/saml_sso/index.md)에 대한 경우 모든 사용자가 기존의 GitLab.com 계정에 SAML ID를 연결해야합니다.

소스 GitLab 인스턴스 연결

원하는 그룹을 생성하고 소스 GitLab 인스턴스를 연결하세요:

  1. 다음 중 하나를 생성하세요:
    • 새 그룹. 왼쪽 사이드바에서 맨 위에서 새로 만들기 ()를 선택하고 새 그룹을 선택합니다. 그런 다음 그룹 가져오기를 선택합니다.
    • 새 하위 그룹. 기존 그룹 페이지에서 다음을 수행하세요:
      • 새 하위 그룹을 선택합니다.
      • 왼쪽 사이드바에서 맨 위에서 새로 만들기 ()를 선택하고 새 하위 그룹을 선택합니다. 그런 다음 기존 그룹 가져오기 링크를 선택합니다.
  2. GitLab 14.0 이상 버전을 실행 중인 GitLab 인스턴스의 기본 URL을 입력합니다.
  3. 소스 GitLab 인스턴스의 개인 액세스 토큰을 입력합니다.
  4. 인스턴스 연결을 선택합니다.

가져올 그룹 및 프로젝트 선택

  • GitLab 15.8에서 소개, 프로젝트를 포함하거나 제외하고 그룹을 가져오는 옵션.

소스 GitLab 인스턴스에 대한 액세스 권한을 승인하면 GitLab 그룹 가져오기 페이지로 리디렉션됩니다. 여기서 소유자 역할을 가진 연결된 소스 인스턴스의 최상위 그룹 디렉터리을 볼 수 있습니다.

  1. 기본적으로 제안된 그룹 네임스페이스는 소스 인스턴스에 있는 것과 동일한 이름과 일치하지만, 권한에 따라 진행하기 전에 이러한 이름을 편집할 수 있습니다.
  2. 가져올 그룹 옆에 다음 중 하나를 선택합니다:
    • 프로젝트를 포함하여 가져오기. 가능하지 않으면 필수 조건을 확인하세요.
    • 프로젝트를 제외하고 가져오기.
  3. 상태 열에는 각 그룹의 가져오기 상태가 표시됩니다. 페이지를 열어두면 실시간으로 업데이트됩니다.
  4. 그룹이 가져온 후에는 해당 GitLab 경로를 선택하여 그의 GitLab URL을 여십시오.
caution
프로젝트를 포함하여 그룹을 가져오는 기능은 베타 상태입니다. 이 기능은 아직 제품으로 사용할 준비가 되지 않았습니다.

그룹 가져오기 이력

직접 이관한 모든 그룹을 그룹 가져오기 이력 페이지에서 볼 수 있습니다. 이 디렉터리에는 다음이 포함됩니다:

  • 소스 그룹의 경로.
  • 대상 그룹의 경로.
  • 각 가져오기의 시작 날짜.
  • 각 가져오기의 상태.
  • 오류가 발생한 경우 오류 세부 정보.

그룹 가져오기 이력을 보려면:

  1. GitLab에 로그인합니다.
  2. 왼쪽 사이드바에서 맨 위에서 새로 만들기 ()를 선택하고 새 그룹을 선택합니다.
  3. 그룹 가져오기를 선택합니다.
  4. 오른쪽 상단에서 이력을 선택합니다.
  5. 특정 가져오기에 오류가 있는 경우 세부 정보를 보려면 실패 사항 보기를 선택합니다.

가져오기 결과 검토

  • GitLab 16.6에 플래그bulk_import_details_page를 사용하여 소개되었으며 기본적으로 활성화되었습니다.
  • 플래그 bulk_import_details_page는 GitLab 16.8에서 제거되었습니다.
  • 부분 완료 및 완료된 가져오기에 대한 세부 정보가 GitLab 16.9에서 추가되었습니다.

가져온 결과를 검토하려면:

  1. 그룹 가져오기 이력 페이지로 이동합니다.
  2. 실패한 가져오기의 세부 정보를 보려면 실패 사항 보기 링크를 선택하여 실패 또는 부분 완료 상태의 가져오기에서 선택합니다.
  3. 가져오기가 부분 완료 또는 완료 상태인 경우 가져온 항목과 가져오지 않은 항목을 보려면 세부 정보를 선택합니다.

실행 중인 가져오기 취소

실행 중인 가져오기를 취소하려면:

  1. 대상 GitLab 인스턴스에서 Rails 콘솔 세션을 시작합니다.
  2. 다음 명령을 실행하여 마지막 가져오기를 찾습니다. USER_ID를 가져오기를 시작한 사용자의 사용자 ID로 교체합니다:

    bulk_import = BulkImport.where(user_id: USER_ID).last
    
  3. 다음 명령을 실행하여 가져온 항목과 관련된 모든 항목을 실패하게 만듭니다:

    bulk_import.entities.each do |entity|
      entity.trackers.each do |tracker|
        tracker.batches.each(&:fail_op!)
      end
      entity.trackers.each(&:fail_op!)
      entity.fail_op!
    end
    bulk_import.fail_op!
    

bulk_import를 취소해도 출발지 인스턴스의 프로젝트를 내보내는 워커를 중지시키지 않지만:

  • 대상이 더 많은 프로젝트를 내보내도록 요청하는 것을 방지합니다.
  • 대상이 출처로 더 많은 API 호출을 하지 못하게 합니다.

이관된 그룹 항목

이관되는 그룹 항목은 대상에서 사용하는 GitLab 버전에 따라 다릅니다. 특정 그룹 항목이 이관되었는지 확인하려면:

  1. 대상 버전에 대한 모든 버전용 groups/stage.rb 파일을 확인합니다.
  2. 대상 버전에 대한 모든 버전용 groups/stage.rb 파일(Enterprise Edition)을 확인합니다. 예를 들어, 15.9 버전의 경우:
  3. 대상 버전에 대한 그룹용 group/import_export.yml 파일을 확인합니다. 예를 들어, 15.9 버전의 경우: https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/group/import_export.yml.

그 외에도 다른 그룹 항목은 이관되지 않습니다.

대상 GitLab 인스턴스로 이관되는 그룹 항목은 다음과 같습니다:

그룹 항목 소개된 버전
뱃지 GitLab 13.11
보드 GitLab 13.7
보드 디렉터리 GitLab 13.7
에픽 1 GitLab 13.7
그룹 레이블 2 GitLab 13.9
이터레이션 GitLab 13.10
이터레이션 캐딘스 GitLab 15.4
멤버 3 GitLab 13.9
그룹 마일스톤 GitLab 13.10
네임스페이스 설정 GitLab 14.10
릴리스 마일스톤 GitLab 15.0
서브그룹 GitLab 13.7
업로드 GitLab 13.7
  1. 에픽 리소스 상태 이벤트는 GitLab 15.4에서 소개, 라벨 연결은 GitLab 13.12에서 소개, 상태 및 상태 ID는 GitLab 13.7에서 소개, 시스템 노트 메타데이터는 GitLab 14.0에서 소개되었습니다.
  2. 그룹 레이블은 가져올 때 연관된 레이블 우선 순위를 유지할 수 없습니다. 이러한 레이블은 대상 인스턴스로 프로젝트가 이관된 후 매뉴얼으로 우선 순위를 다시 지정해야 합니다.
  3. 그룹 멤버는 사용자가:
    • 대상 GitLab 인스턴스에 이미 있습니다.
    • 소스 GitLab 인스턴스에서 공개 이메일이 대상 GitLab 인스턴스의 확인된 이메일과 일치하는 경우 가져오기된 그룹과 연관되어 있습니다.

제외된 항목

일부 그룹 항목은 마이그레이션이 제외됩니다. 그 이유는 다음과 같습니다:

  • 민감한 정보가 포함될 수 있음: CI/CD 변수, 웹훅 및 배포 토큰.
  • 지원되지 않음: 푸시 규칙.

마이그레이션된 프로젝트 항목

상태: Beta

그룹을 마이그레이션하려면 프로젝트를 마이그레이션하도록 선택하는 경우 프로젝트 항목은 프로젝트와 함께 마이그레이션됩니다.

마이그레이션되는 프로젝트 항목은 목적지에서 사용하는 GitLab 버전에 따라 다릅니다. 특정 프로젝트 항목이 마이그레이션되는지 확인하려면:

  1. 모든 에디션을 위한 projects/stage.rb 파일을 확인하고, 목적지 버전에 대한 기업 에디션의 경우 projects/stage.rb 파일을 확인하세요. 예를 들어, 버전 15.9의 경우:
  2. 프로젝트에 대한 버전별 project/import_export.yml 파일을 확인하세요. 예를 들어, 버전 15.9의 경우: https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/project/import_export.yml.

기타 프로젝트 항목은 마이그레이션되지 않습니다.

그룹과 함께 프로젝트를 마이그레이션하지 않기로 선택하거나 프로젝트 마이그레이션을 다시 시도하려는 경우, API를 사용하여 프로젝트 전용 마이그레이션을 시작할 수 있습니다.

caution
직접 전송하여 그룹을 마이그레이션할 때 프로젝트를 마이그레이션하는 것은 Beta 상태이며 상용 환경에 사용하기에 적합하지 않습니다.

목적지 GitLab 인스턴스로 마이그레이션된 프로젝트 항목은 다음과 같습니다:

프로젝트 항목 소개된 버전
프로젝트 GitLab 14.4
자동 DevOps GitLab 14.6
뱃지들 GitLab 14.6
브랜치(보호된 브랜치 포함) 1 GitLab 14.7
CI 파이프라인 GitLab 14.6
커밋 코멘트 GitLab 15.10
디자인들 GitLab 15.1
이슈들 GitLab 14.4
이슈 보드들 GitLab 14.4
라벨들 GitLab 14.4
LFS 오브젝트 GitLab 14.8
멤버들 GitLab 14.8
MR(Merge Request) GitLab 14.5
푸시 규칙들 GitLab 14.6
마일스톤들 GitLab 14.5
외부 풀 리퀘스트들 GitLab 14.5
파이프라인 히스토리 GitLab 14.6
파이프라인 스케줄들 GitLab 14.8
프로젝트 기능들 GitLab 14.6
릴리즈들 GitLab 15.1
릴리즈 증거들 GitLab 15.1
리포지터리들 GitLab 14.4
스니펫들 GitLab 14.6
설정들 GitLab 14.6
업로드 파일들 GitLab 14.5
위키들 GitLab 14.6
각주:
  1. 가져온 브랜치는 목적지 그룹의 기본 브랜치 보호 설정을 존줍니다. 이는 보호되지 않은 브랜치가 보호된 상태로 가져올 수 있음을 의미합니다.

이슈 관련 항목

대상 GitLab 인스턴스로 이관된 이슈 관련 프로젝트 항목은 다음과 같습니다.

이슈 관련 프로젝트 항목 도입 버전
이슈 이터레이션 GitLab 15.4
이슈 리소스 상태 이벤트 GitLab 15.4
이슈 리소스 마일스톤 이벤트 GitLab 15.4
이슈 리소스 이터레이션 이벤트 GitLab 15.4
Merge Request URL 참조 GitLab 15.6
시간 추적 GitLab 14.4

Merge Request 관련 항목

대상 GitLab 인스턴스로 이관된 Merge Request 관련 프로젝트 항목은 다음과 같습니다.

Merge Request 관련 프로젝트 항목 도입 버전
다중 Merge Request 담당자 GitLab 15.3
Merge Request 리뷰어 GitLab 15.3
Merge Request 승인자 GitLab 15.3
Merge Request 리소스 상태 이벤트 GitLab 15.4
Merge Request 리소스 마일스톤 이벤트 GitLab 15.4
이슈 URL 참조 GitLab 15.6
시간 추적 GitLab 14.5

설정 관련 항목

대상 GitLab 인스턴스로 이관된 설정 관련 프로젝트 항목은 다음과 같습니다.

설정 관련 프로젝트 항목 도입 버전
아바타 GitLab 14.6
컨테이너 만료 정책 GitLab 14.6
프로젝트 속성 GitLab 14.6
서비스 데스크 GitLab 14.6

제외된 항목

일부 프로젝트 항목은 민감한 정보를 포함하거나 지원되지 않기 때문에 이관에서 제외됩니다:

  • 민감한 정보 포함 가능성:
    • CI/CD 변수
    • 배포 키
    • 배포 토큰
    • 파이프라인 스케줄 변수
    • 파이프라인 트리거
    • 웹훅
  • 지원되지 않음:
    • 에이전트
    • 컨테이너 레지스트리
    • 환경
    • 피처 플래그
    • 인프라 레지스트리
    • 패키지 레지스트리
    • 페이지 도메인
    • 원격 미러

문제 해결

rails console session에서 그룹 가져오기 시도의 실패 또는 오류 메시지를 찾을 수 있습니다. 다음 코드를 사용하세요:

# 관련 가져오기 레코드 가져오기
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import).last

# 사용자별 대체 조회
import = BulkImport.where(user_id: User.find(...)).last

# 가져오기 엔티티 디렉터리 가져오기. 각 엔티티는 그룹 또는 프로젝트를 나타냅니다.
entities = import.entities

# 엔티티 실패 디렉터리 가져오기
entities.map(&:failures).flatten

# 상태에 따른 대체 실패 조회
entities.where(status: [-1]).pluck(:destination_name, :destination_namespace, :status)

또한 API 엔드포인트를 사용하여 모든 대상 엔티티 및 관련 실패를 볼 수 있습니다.

만료된 가져오기

그룹 이관을 해결하는 경우, 가져오기 작업자가 8시간 이상 소요되어 완료되지 않을 수 있습니다. 이 경우, BulkImport 또는 BulkImport::Entitystatus3 (타임아웃)임을 나타냅니다:

# 관련 가져오기 레코드 가져오기
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import)

import.status #=> 3는 가져오기가 시간 초과되었음을 의미.

오류: 404 그룹을 찾을 수 없음

숫자만으로 구성된 경로를 가진 그룹(예: 5000)을 가져오려고 시도하는 경우, GitLab은 경로 대신 그룹을 ID로 찾으려고 시도하여 GitLab 15.4 및 이전 버전에서 404 그룹을 찾을 수 없음 오류가 발생합니다.

이를 해결하려면 다음 중 하나를 사용하여 소스 그룹 경로에 숫자 이외의 문자를 포함시켜야 합니다:

  • GitLab UI:

    1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
    2. 설정 > 일반을 선택합니다.
    3. 고급을 확장합니다.
    4. 그룹 URL 변경 아래에서 그룹 URL을 숫자 이외의 문자를 포함하도록 변경합니다.
  • 그룹 API.

기타 404 오류

그룹을 가져오는 동안 기타 404 오류를 받을 수 있습니다. 예를 들어:

"exception_message": "Unsuccessful response 404 from [FILTERED] Bo...",
"exception_class": "BulkImports::NetworkError",

이 오류는 소스 인스턴스로의 전송에 문제가 있음을 나타냅니다. 이를 해결하려면 소스 인스턴스에서 준비 사항을 충족했는지 확인하세요.

마이그레이션 기간 단축

단일 직접 전송 마이그레이션은 한 번에 5개의 엔터티(그룹 또는 프로젝트)를 가져오며, 대상 인스턴스에서 사용 가능한 워커의 수와는 관계 없이 수행됩니다. 이와 같이 대상 인스턴스에서 더 많은 워커를 가지고 있으면 각 엔터티를 가져오는 데 걸리는 시간을 단축시켜 마이그레이션 속도를 높일 수 있습니다.

대상 인스턴스의 워커 수를 늘리면 소스 인스턴스 하드웨어 리소스가 포화될 때까지 마이그레이션 기간을 줄일 수 있습니다. (제안된 에픽 9036에서 제안된) 일괄적으로 관계를 내보내고 가져오는 것은 대상 인스턴스에 충분한 워커를 가지고 있는 것이 더욱 유용하게 만듭니다.

소스 인스턴스의 워커 수는 병렬로 5개의 동시 엔터티를 내보낼 수 있을 정도로 충분해야 합니다. 그렇지 않으면 가져오기 대상에서 내보낸 데이터를 기다리는 지연 및 잠재적인 타임아웃이 발생할 수 있습니다.

다른 그룹에 프로젝트를 분산하는 것은 타임아웃을 피하는 데 도움이 됩니다. 동일한 그룹에 여러 대형 프로젝트가 있는 경우 다음을 수행할 수 있습니다:

  1. 대형 프로젝트를 다른 그룹이나 하위 그룹으로 이동합니다.
  2. 각 그룹 및 하위 그룹에 별도의 마이그레이션을 시작합니다.

GitLab UI는 최상위 그룹만 마이그레이션할 수 있습니다. API를 사용하면 서브그룹도 마이그레이션할 수 있습니다.