직접 전송을 사용하여 그룹 및 프로젝트 이관하기

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체 운영, GitLab Dedicated

GitLab 그룹 및 프로젝트를 직접 전송을 사용하여 이관하려면 다음을 수행합니다.

전제 조건 충족
소스 GitLab 인스턴스 연결
이관할 그룹 및 프로젝트 선택 및 이관 시작
가져오기 결과 검토

문제가 발생하면 다음을 수행할 수 있습니다.

이관 취소 또는 다시 시도
문제 해결 정보 확인

전제 조건

GitLab 16.0에 도입된 관리자 역할 대신 개발자 역할 요구 사항으로 되돌릴 예정이며, 이 요구 사항은 GitLab 15.11.1 및 GitLab 15.10.5에 반영될 예정입니다.

직접 전송을 사용하여 이관하기 전에 다음 전제 조건을 확인합니다.

네트워크

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

버전

성공적이고 성능 좋은 이관의 가능성을 극대화하기 위해 다음을 수행해야 합니다.

관계의 일괄 가져오기 및 내보내기를 활용하려면 소스 및 대상 인스턴스를 GitLab 16.8 이상으로 업데이트합니다.
가능한 한 최신 버전으로 이관합니다. 시간이 지남에 따라 추가된 버그 수정 및 개선 사항을 활용하려면 소스 및 대상 인스턴스를 최신 버전으로 업데이트합니다.
GitLab 16.2를 실행하는 소스 인스턴스와 GitLab 16.8을 실행하는 대상 인스턴스 간의 이관을 성공적으로 테스트했습니다.

구성

어드민 인스턴스에서 직접 전송을 사용하여 그룹 이관이 애플리케이션 설정에서 활성화되어 있어야 합니다.
소스 GitLab 인스턴스에 개인 액세스 토큰이 있어야 합니다.
- GitLab 15.1 이상의 소스 인스턴스의 경우, 개인 액세스 토큰에 api 스코프가 있어야 합니다.
- GitLab 15.0 이하의 소스 인스턴스의 경우, 개인 액세스 토큰은 api 및 read_repository 스코프를 가져야 합니다.
이관할 소스 그룹에서 소유자 역할이 있어야 합니다.
해당 네임스페이스에서 하위 그룹을 생성할 수 있는 대상 네임스페이스의 권한이 있어야 합니다.
객체 저장소에 저장된 항목을 가져오려면 다음을 수행해야 합니다.
- 프록시 다운로드를 구성합니다.
- 대상 GitLab 인스턴스가 소스 GitLab 인스턴스의 객체 저장소에 액세스할 수 있도록 합니다.
소스 인스턴스나 그룹이 기본 프로젝트 생성 보호를 아무도로 설정한 경우, 이를 가져올 수 없습니다. 필요한 경우 이 설정을 변경할 수 있습니다.
- 전체 인스턴스에 대해
- 특정 그룹에 대해

사용자 기여 및 멤버십 매핑

공유 및 상속된 공유 멤버의 매핑을 직접 멤버로 변경한 것이 GitLab 16.3에 도입되었습니다.
이미 공유되거나 상속된 공유 멤버인 경우, GitLab 16.11에서 공유 및 상속된 공유 멤버는 더 이상 직접 멤버로 매핑되지 않습니다.
상속된 멤버십을 매핑하는 완전한 지원은 GitLab 17.1에서 도입되었습니다.

이관 중에 사용자가 생성되지 않습니다. 대신, 소스 인스턴스의 사용자 기여 및 멤버십이 대상 인스턴스의 사용자에게 매핑됩니다. 사용자의 멤버십 매핑 유형은 소스 인스턴스의 멤버십 유형에 따라 달라집니다.

직접 멤버십은 대상 인스턴스에서 직접 멤버십으로 매핑됩니다.
상속된 멤버십은 대상 인스턴스에서 상속된 멤버십으로 매핑됩니다.
공유된 멤버십은 사용자가 기존의 공유된 멤버십이 없는 경우 대상 인스턴스에서 직접 멤버십으로 매핑됩니다. 공유된 멤버십의 완전한 지원은 issue 458345에서 제안되었습니다.

inherited 와 shared의 매핑을 할 때, 해당 사용자가 이미 매핑되는 권한보다 높은 역할을 가진 대상 네임스페이스의 기존 멤버십이 있는 경우, 해당 멤버십은 직접 멤버십으로 매핑됩니다. 이를 통해 멤버가 권한이 상승하지 않도록 보장합니다.

참고: 공유된 멤버십의 매핑에 영향을 주는 알려진 문제가 있습니다.

새로운 실험적 사용자 기여 및 멤버십 매핑 기능에 대한 자세한 내용은 사용자 기여 및 멤버십 매핑을 참조하세요.

대상 인스턴스에 사용자 구성

소스 및 대상 인스턴스 간에 사용자 및 그들의 기여가 올바르게 매핑되도록 하려면 다음을 수행합니다.

대상 GitLab 인스턴스에 필요한 사용자를 생성합니다. 관리자 액세스가 필요한데, 자체 운영 인스턴스에서만 API를 통해 사용자를 생성할 수 있습니다. GitLab.com이나 자체 운영 GitLab 인스턴스로 이관하는 경우 다음을 수행할 수 있습니다.
- 수동으로 사용자를 생성합니다.
- 설정 또는 기존의 SAML SSO 제공업체를 설정하고 SAML SSO 그룹의 사용자 동기화를 지원하는 SCIM을 활용합니다.
- 승인된 이메일 도메인으로 사용자 계정 확인을 우회할 수 있습니다.
사용자가 대상 GitLab 인스턴스에서 확인된 이메일 주소와 일치하는 공개 이메일을 가지고 있어야 합니다. 대부분의 사용자는 이메일 주소를 확인하기 위해 이메일을 받습니다.
대상 인스턴스에 이미 사용자가 있는 경우, SAML SSO를 GitLab.com 그룹에 사용하고자 하는 경우 모든 사용자가 SAML ID를 GitLab.com 계정에 연결해야 합니다.

GitLab UI 또는 API에는 사용자의 공개 이메일 주소를 자동으로 설정하는 방법이 없습니다. 많은 사용자 계정에 대해 공개 이메일 주소를 설정해야 하는 경우, issue 284495에서 잠재적인 해결책을 확인하실 수 있습니다.

소스 GitLab 인스턴스 연결

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

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

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

GitLab 15.8에 도입됨, 프로젝트를 포함하거나 제외하면서 그룹을 가져올 수 있는 옵션.

소스 GitLab 인스턴스에 대한 액세스를 승인한 후, GitLab 그룹 가져오기 페이지로 리디렉션됩니다. 여기에서 Owner 역할을 가지고 있는 소스 인스턴스의 최상위 그룹 목록을 볼 수 있습니다.

기본적으로 제안된 그룹 네임스페이스는 소스 인스턴스에 있는 것과 동일한 이름과 일치하지만, 권한에 따라서 이들의 이름을 편집할 수 있습니다. 이러한 그룹 및 프로젝트 경로는 제한 사항에 따라야 하며, 필요한 경우 정규화되어 가져오기 실패를 피합니다.
가져오려는 그룹 옆에 다음 중 하나를 선택하세요:
- 프로젝트와 함께 가져오기. 이 옵션이 제공되지 않으면 전제 조건을 확인하세요.
- 프로젝트 없이 가져오기.
상태 열은 각 그룹의 가져오기 상태를 보여줍니다. 페이지를 열어두면 실시간으로 업데이트됩니다.
그룹이 가져온 후, 해당 GitLab 경로를 선택하여 해당 그의 GitLab URL을 엽니다.

경고: 프로젝트를 포함하여 그룹 가져오기는 베타 상태입니다. 이 기능은 아직 운영에서 사용할 준비가 되지 않았습니다.

그룹 가져오기 히스토리

GitLab 16.7에 소개된 부분 완료 상태.

직접 전송된 모든 그룹을 그룹 가져오기 히스토리 페이지에서 볼 수 있습니다. 이 목록에는 다음이 포함됩니다:

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

그룹 가져오기 히스토리를 보려면:

GitLab에 서명합니다.
왼쪽 사이드바에서 맨 위에서 새로 만들기()를 선택하고 새 그룹을 선택합니다.
그룹 가져오기를 선택합니다.
오른쪽 상단에서 히스토리를 선택합니다.
특정 가져오기에 대한 오류가 있는 경우, 해당 가져오기의 세부 정보를 보려면 오류 표시를 선택하세요.

가져오기 결과 검토

GitLab 16.6에 bulk_import_details_page라는 플래그로 도입됨. 기본적으로 활성화됨.
GitLab 16.8에서 bulk_import_details_page 플래그 제거.
GitLab 16.9에 부분 완료 및 완료된 가져오기의 세부 정보 추가.
GitLab 17.0에, 디자인, epic, 이슈, 병합 요청, 노트(시스템 노트 및 코멘트), 스니펫 및 사용자 프로필 활동이 가져옴을 나타내는 Imported 배지 추가.

가져오기 결과를 검토하려면:

그룹 가져오기 히스토리 페이지로 이동하세요.
실패한 가져오기의 세부 정보를 보려면 실패 또는 부분 완료 상태의 가져오기에서 세부 정보 보기를 선택하세요.
가져오기가 부분 완료 또는 완료 상태인 경우 가져온 항목 및 가져오지 못한 항목을 확인하려면 세부 정보 보기를 선택하세요.

또한 GitLab UI에서 일부 항목에 Imported 배지가 표시되어 있는 경우 해당 항목이 가져옴을 확인할 수 있습니다.

실행 중인 마이그레이션 취소

필요한 경우, REST API 또는 레일즈 콘솔 둘 중 하나를 사용하여 실행 중인 마이그레이션을 취소할 수 있습니다.

REST API로 취소

REST API를 사용하여 실행 중인 마이그레이션을 취소하는 방법에 대한 정보는 마이그레이션 취소를 참조하십시오.

레일즈 콘솔로 취소

레일즈 콘솔을 사용하여 실행 중인 마이그레이션을 취소하려면:

대상 GitLab 인스턴스에서 레일즈 콘솔 세션을 시작하세요.
다음 명령을 실행하여 마지막 가져오기를 찾으세요. USER_ID를 해당 가져오기를 시작한 사용자의 사용자 ID로 바꿉니다:
```
bulk_import = BulkImport.where(user_id: USER_ID).last
```

다음 명령을 실행하여 가져오기 및 해당 항목의 모든 항목을 실패하도록 만드세요:

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 UI 또는 GitLab REST API를 사용합니다.
특정 하위 그룹 또는 프로젝트, GitLab REST API를 사용합니다.

직접 전송을 사용하여 그룹 및 프로젝트 이관하기

전제 조건

네트워크

버전

구성

사용자 기여 및 멤버십 매핑

대상 인스턴스에 사용자 구성

소스 GitLab 인스턴스 연결

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

그룹 가져오기 히스토리

가져오기 결과 검토

실행 중인 마이그레이션 취소

REST API로 취소

레일즈 콘솔로 취소

실패한 또는 부분적으로 성공한 마이그레이션 다시 시도하기

도움말

기능 사용 가능성과 제품 평가판

도움받기