- 알려진 이슈
- 마이그레이션 기간 추정하기
- 제한
- 가시성 규칙
- 멤버십
- 전제 조건
- 원본 GitLab 인스턴스 연결
- 가져올 그룹 및 프로젝트 선택
- 그룹 가져오기 이력
- 가져오기 결과 검토
- 실행 중인 가져오기 취소
- 마이그레이션된 그룹 항목
- 마이그레이션된 프로젝트 항목
- 문제 해결
GitLab 그룹 및 프로젝트를 직접 이전하여 마이그레이션하기
- 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 인스턴스, 그 중에 GitLab.com도 포함됨.
- API를 통해 다음 위치로 상위 그룹 및 하위 그룹을 복사합니다.
- 프로젝트가 있는 그룹(베타에서 사용 가능하며 운영에는 준비되지 않음) 또는 프로젝트가 없는 그룹을 복사합니다. 프로젝트를 함께 복사하는 것은 다음에서 사용할 수 있습니다:
- 기본적으로 GitLab.com에서.
모든 그룹 및 프로젝트 리소스가 복사되는 것은 아닙니다. 아래의 복사된 리소스 디렉터리을 확인하세요:
직접 전송을 통해 그룹을 마이그레이션하는 것에 대한 피드백을 피드백 이슈에 남기도록 초대합니다.
그룹을 복사하는 대신 그룹을 옮기고 싶은 경우, 그룹이 동일한 GitLab 인스턴스에 있으면 그룹을 옮길 수 있습니다. 그룹을 옮기는 것이 더 빠르고 더 완전한 옵션입니다.
알려진 이슈
- 이슈 406685로 인해 파일 이름이 255자를 초과하는 파일은 마이그레이션이 되지 않습니다.
- GitLab 16.1 이전에, 예약된 스캔 실행 정책을 사용해서는 절대로 직접 전송을 사용하면 않됩니다.
- 다른 알려진 이슈 디렉터리은 epic 6629을 참조하세요.
- GitLab 16.9 이전에, 이슈 438422로 인해
DiffNote::NoteDiffFileCreationError
오류가 발생할 수 있습니다. 이 오류가 발생하면 Merge Request의 diff에서 노트가 누락되지만, 노트와 Merge Request은 여전히 가져옵니다. - 소스 인스턴스로부터 가져올 때, 공유 멤버는 목적지에서 이미 해당 멤버십이 있는 경우를 제외하고 목적지에서 직접 멤버로 생성됩니다. 즉, 소스 상위 그룹에서 목적지 상위 그룹으로 그룹을 가져오면 소스 상위 그룹이 필요한 공유 멤버십 계층 구조 세부 정보를 포함하고 있음에도 불구하고 항상 프로젝트에서 직접 멤버가 생성됩니다. 공유 멤버십의 전체 복제 지원 제안은 이슈 458345에 있습니다.
마이그레이션 기간 추정하기
직접 전송을 통한 마이그레이션 기간을 추정하는 것은 어렵습니다. 다음 요인이 마이그레이션 기간에 영향을 미칩니다:
- 소스 및 목적지 GitLab 인스턴스에서 사용 가능한 하드웨어 및 데이터베이스 리소스. 소스 및 목적지 인스턴스에서 더 많은 리소스가 있을수록 마이그레이션 기간이 짧아질 수 있습니다. 왜냐하면:
- 소스 인스턴스는 API 요청을 받고, 추출 및 시리얼화된 엔티티를 내보냅니다.
- 목적지 인스턴스에서는 작업을 실행하고 엔티티를 데이터베이스에 생성합니다.
- 내보낼 데이터의 복잡성과 크기. 예를 들어, 1000개의 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 |
마이그레이션 기간을 정확하게 예측하는 것은 어렵지만 다음의 경우를 관찰했습니다:
- 100개의 프로젝트 (19.9k 이슈, 83k Merge Request, 100k+ 파이프라인)가 8시간에 마이그레이션되었습니다.
- 1926개의 프로젝트 (22k 이슈, 160k Merge Request, 1.1백만 파이프라인)가 34시간에 마이그레이션되었습니다.
만약 큰 프로젝트를 마이그레이션하면서 시간 초과 문제나 마이그레이션 기간에 문제가 발생한다면, 마이그레이션 기간 줄이기를 참조하세요.
제한
- 16.7에서 마이그레이션에 대한 여덟 시간 시간 제한이 제거되었습니다.
직접 전송을 통한 마이그레이션에 하드코딩된 제한이 적용됩니다.
제한 | 설명 |
---|---|
6 | 사용자당 목적지 GitLab 인스턴스에서 허용되는 최대 마이그레이션 횟수(분당). GitLab 15.9에서 도입됨. |
210초 | 아카이브 파일의 압축 해제를 위해 기다릴 수 있는 최대 초 단위 시간. |
50 MB | NDJSON 행의 최대 길이. |
5분 | 소스 인스턴스의 빈 내보내기 상태가 발생할 때까지 기다릴 수 있는 최대 초 단위 시간. |
구성 가능한 제한도 사용할 수 있습니다.
GitLab 16.3 이상에서 이전에 하드코딩된 설정으로 아래의 설정이 구성 가능해졌습니다:
- 소스 인스턴스에서 다운로드할 수 있는 최대 관련 크기(5 GiB로 설정).
- 압축 해제된 아카이브의 최대 크기(10 GiB로 설정).
다음 API를 사용하여 최대 관련 크기 제한을 테스트할 수 있습니다:
어느 API도 최대 관련 크기 제한보다 큰 파일을 생성하면 직접 전송을 통한 그룹 마이그레이션이 실패합니다.
가시성 규칙
마이그레이션 후:
- 비공개 그룹 및 프로젝트는 비공개 상태 유지
- 내부 그룹 및 프로젝트:
- 내부 그룹에 복사될 때 내부 가시성이 제한됨 경우, 해당 그룹 및 프로젝트는 비공개로 변환됨.
- 비공개 그룹에 복사될 때 비공개 상태가 됨.
- 공개 그룹 및 프로젝트:
일반 대중에게 콘텐츠를 숨기기 위해 원본 인스턴스에서 개인 네트워크를 사용한 경우, 이와 유사한 설정이나 비공개 그룹에 가져올 수 있도록 목적지 인스턴스에서 가져오도록 하십시오.
멤버십
그룹 및 프로젝트 멤버는 사용자 계정 전제조건을 충족하는 경우 가져올 수 있습니다.
모든 직접 및 간접 멤버가 가져옵니다.
다음 경우 간접 멤버는 직접 멤버로 가져오입니다:
- 대상 네임스페이스의 간접 멤버가 아닌 경우
- 간접 멤버이지만, 더 낮은 권한을 가지고 있는 경우.
공유 멤버십 이전에 영향을 미치는 알려진 문제가 있습니다.
전제 조건
- GitLab 16.0에서 Maintainer 역할 대신 Developer 역할이 필요한 요구사항이 도입되어 GitLab 15.11.1 및 GitLab 15.10.5로 백포팅되었습니다.
직접 전송을 사용하여 마이그레이션하기 전에 다음 전제 조건을 확인하십시오.
네트워크
- 인스턴스 간 또는 GitLab.com 간의 네트워크 연결은 HTTPS를 지원해야 함.
- 방화벽은 원본 및 대상 GitLab 인스턴스 간의 연결을 차단해서는 안 됨.
버전
성공적이고 성능 좋은 마이그레이션 기회를 극대화하려면 다음을 해야 함:
- 관계의 일괄적인 내보내기 및 가져오기를 활용하려면, 원본 및 대상 인스턴스를 GitLab 16.2 이상으로 업데이트하십시오.
- 가능한 최신 버전 간으로 마이그레이션하십시오. 시간이 지남에 따라 추가된 버그 수정 및 개선 사항을 활용하려면 원본 및 대상 인스턴스를 가능한 최신 버전으로 업데이트하십시오.
GitLab 16.2를 실행하는 원본 인스턴스와 GitLab 16.8을 실행하는 대상 인스턴스 간의 마이그레이션은 성공적으로 테스트되었습니다.
구성
- GitLab 인스턴스 모두가 어드민에 의해 직접 전송에 의한 그룹 마이그레이션을 활성화 하고 있어야 함.
- 원본 GitLab 인스턴스에 대한
개인 액세스 토큰을 가져야 함:
- GitLab 15.1 이상의 원본 인스턴스의 경우, 개인 액세스 토큰은
api
스코프를 가져야 함. - GitLab 15.0 및 그 이전 원본 인스턴스의 경우, 개인 액세스 토큰은
api
및read_repository
스코프를 모두 가져야 함.
- GitLab 15.1 이상의 원본 인스턴스의 경우, 개인 액세스 토큰은
- 마이그레이션할 원본 그룹의 소유자 역할을 가져야 함.
- 대상 네임스페이스에서 하위 그룹을 만들 수 있게 하는 역할을 가져야 함.
- 객체 리포지터리에 저장된 항목을 가져오려면 다음 중 하나를 해야 함:
- [프록시 다운로드]를 구성합니다(../../../administration/object_storage.md#configure-the-common-parameters).
- 대상 GitLab 인스턴스가 원본 GitLab 인스턴스의 객체 리포지터리에 액세스할 수 있도록 합니다.
- 기본 프로젝트 생성 보호가 아무도로 설정된 경우, 프로젝트가 있는 그룹을 가져올 수 없음. 필요한 경우 이 설정을 변경할 수 있음:
사용자 계정
GitLab이 사용자와 그들의 기여를 정확하게 매핑하기 위해:
- 대상 GitLab 인스턴스에 필요한 사용자를 만듭니다. 관리자 액세스가 필요하므로 Self-Managed형 인스턴스에서만 API를 통해 사용자를 만들 수 있습니다. GitLab.com이나 Self-Managed형 GitLab 인스턴스로 마이그레이션할 때 다음을 수행할 수 있음:
- 매뉴얼으로 사용자 생성
- 설정하거나 기존의 SAML SSO 공급자를 사용하고 SCIM을 통해 SAML SSO 그룹의 사용자 동기화를 활용합니다. 확인된 이메일 도메인으로 GitLab 사용자 계정 확인을 우회할 수 있습니다.
- 사용자가 대상 GitLab 인스턴스에서 확인된 이메일 주소와 일치하는 공개 이메일을 가져야 합니다. 대부분의 사용자는 이메일 확인을 위한 이메일을 받습니다.
- 사용자가 이미 대상 인스턴스에 존재하고 SAML SSO가 GitLab.com 그룹에 대해 사용된 경우, 모든 사용자가 SAML ID를 기존의 GitLab.com 계정에 연결해야 합니다.
원본 GitLab 인스턴스 연결
가져오기할 그룹을 만들고 원본 GitLab 인스턴스에 연결합니다:
- 다음 중 하나를 만드십시오:
- 새 그룹. 왼쪽 사이드바에서 위쪽에 있는 만들기 ()를 선택한 다음 새 그룹을 선택합니다. 그런 다음 그룹 가져오기를 선택합니다.
- 새 하위 그룹. 기존 그룹 페이지에서 다음을 수행하거나:
- 새 하위 그룹을 선택합니다.
- 왼쪽 사이드바에서 위쪽에 있는 만들기 ()를 선택한 다음 새 하위 그룹을 선택한 다음 기존 그룹 가져오기 링크를 선택합니다.
- GitLab 인스턴스의 기본 URL을 입력합니다.
- 소스 GitLab 인스턴스에 대한 개인 액세스 토큰을 입력합니다.
- 인스턴스 연결을 선택합니다.
가져올 그룹 및 프로젝트 선택
- GitLab 15.8에서 도입된, 프로젝트와 함께 그룹 가져오기를 위한 옵션이 있습니다.
원본 GitLab 인스턴스에 대한 액세스를 허용한 후, GitLab 그룹 가져오기 페이지로 리디렉션됩니다. 여기에서 소유자 역할을 가진 연결된 원본 인스턴스의 최상위 그룹 디렉터리을 볼 수 있습니다.
- 기본적으로 제안된 그룹 네임스페이스는 원본 인스턴스에 있는 이름과 일치하겠지만, 권한에 따라 진행하기 전에 이러한 이름을 편집할 수 있습니다.
- 가져오려는 그룹 옆에 다음 중 하나를 선택합니다:
- 프로젝트와 함께 가져오기. 사용할 수 없는 경우 전제 조건을 참조하십시오.
- 프로젝트 없이 가져오기.
- 상태 열에서 각 그룹의 가져오기 상태가 표시됩니다. 페이지를 열어 둔 채로 있으면 실시간으로 업데이트됩니다.
- 그룹이 가져오된 후에는 해당 GitLab 경로를 선택하여 해당 GitLab URL을 엽니다.
그룹 가져오기 이력
- GitLab 16.7에서 부분 완료 상태가 도입되었습니다.
직접 전송하여 그룹 가져오기 이력 페이지에 나열된 것을 통해 사용자가 가져온 모든 그룹을 볼 수 있습니다. 이 디렉터리에는 다음이 포함됩니다:
- 소스 그룹의 경로.
- 대상 그룹의 경로.
- 각 가져오기의 시작 날짜.
- 각 가져오기의 상태.
- 오류 발생 시 오류 세부 정보.
그룹 가져오기 이력을 보려면:
- GitLab에 로그인합니다.
- 왼쪽 사이드바에서 맨 위에 새로 만들기 () 및 새 그룹을 선택합니다.
- 그룹 가져오기를 선택합니다.
- 오른쪽 상단에서 이력을 선택합니다.
- 특정 가져오기에 대한 오류가 있는 경우 실패 항목 보기를 선택하여 세부 정보를 볼 수 있습니다.
가져오기 결과 검토
가져오기 결과를 검토하려면:
- 그룹 가져오기 이력 페이지로 이동합니다.
- 실패 또는 부분 완료 상태의 가져오기 중 하나의 세부 정보 보기 링크를 선택하여 실패한 가져오기의 세부 정보를 볼 수 있습니다.
- 가져오기가 부분 완료 또는 완료 상태인 경우 가져와진 항목과 가져오지 않은 항목을 보려면 세부 정보를 선택합니다.
또한 GitLab UI에서 일부 항목에 가져옴 배지가 표시되어 있는 경우 해당 항목이 가져와진 것으로 볼 수 있습니다.
실행 중인 가져오기 취소
실행 중인 가져오기를 취소하려면:
- 대상 GitLab 인스턴스에서 Rails 콘솔 세션을 시작합니다.
-
마지막 가져오기를 찾아 다음 명령을 실행합니다.
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 버전에 따라 마이그레이션된 그룹 항목이 다릅니다. 특정 그룹 항목이 마이그레이션되었는지 확인하려면:
- 모든 버전에 대한
groups/stage.rb
파일 및 대상 버전에 대한groups/stage.rb
파일을 확인하세요. 예를 들어, 버전 15.9의 경우: - 대상 버전에 대한 그룹에 대한
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.7 |
이터레이션들 | 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 |
- 에픽 자원 상태 이벤트가 GitLab 15.4에서 도입되었으며, 레이블 연관이 GitLab 13.12에서 도입되었으며, 상태와 상태 ID가 GitLab 13.7에서 도입되었으며, 시스템 노트 메타데이터가 GitLab 14.0에서 도입되었습니다.
- 그룹 라벨은 가져오기 시 연관 라벨 우선 순위를 유지할 수 없습니다. 해당 라벨은 대상 인스턴스로 프로젝트가 마이그레이션된 후 매뉴얼으로 다시 우선 순위를 지정해야 합니다.
- 멤버십을 참조하세요.
제외된 항목
일부 그룹 항목은 다음과 같은 이유로 마이그레이션에서 제외되었습니다.
- 민감한 정보를 포함할 수 있음: CI/CD 변수, 웹훅 및 배포 토큰.
- 지원되지 않음: 푸시 규칙.
마이그레이션된 프로젝트 항목
- GitLab.com에서 활성화됨 (GitLab 15.6에서).
bulk_import_projects
피처 플래그 제거됨 (GitLab 15.10에서).- 프로젝트 전용 마이그레이션 사용 API 추가됨 (GitLab 15.11에서).
그룹을 마이그레이션할 때 프로젝트를 선택하면 프로젝트 항목이 프로젝트와 함께 마이그레이션됩니다.
마이그레이션되는 프로젝트 항목은 대상으로 하는 GitLab 버전에 따라 달라집니다. 특정 프로젝트 항목이 마이그레이션되는지 확인하려면:
- 대상 버전에 대한
projects/stage.rb
(모든 에디션) 파일 및projects/stage.rb
(Enterprise Edition) 파일을 확인하십시오. 예를 들어, 15.9 버전의 경우: - 대상 버전에 대한 프로젝트의
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를 사용하여 프로젝트 전용 마이그레이션을 시작할 수 있습니다.
대상 GitLab 인스턴스로 마이그레이션되는 프로젝트 항목은 다음과 같습니다:
프로젝트 항목 | 도입된 버전 |
---|---|
프로젝트 | GitLab 14.4 |
Auto 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 |
멤버 2 | GitLab 14.8 |
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 |
각주:
- 가져온 브랜치는 대상 그룹의 기본 브랜치 보호 설정을 준수하므로 보호되지 않은 브랜치도 보호된 상태로 가져올 수 있습니다.
- 멤버십을 참조하십시오.
이슈 관련 항목
대상 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 콘솔 세션에서는 다음을 사용하여 그룹 이관 시도와 관련된 실패 또는 오류 메시지를 찾을 수 있습니다:
# 관련 있는 이관 레코드 가져오기
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)
그룹 이관의 문제 해결 시, 이관 워커가 8시간 이상 소요된 경우 status
가 3
(timeout
)인 경우 BulkImport
또는 BulkImport::Entity
의 status
를 확인할 수 있습니다:
# 관련 이관 레코드 가져오기
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import)
import.status #=> 3은 이관 시간 초과를 의미합니다.
오류: 404 그룹을 찾을 수 없음
경로가 숫자만으로 구성된 그룹(예: 5000
)을 가져오려고 할 때, GitLab은 경로가 아닌 ID로 그룹을 찾으려고 합니다. 이는 GitLab 15.4 이전 버전에서 404 그룹을 찾을 수 없음
오류를 발생시킵니다.
해결책으로는 소스 그룹 경로를 숫자 이외의 문자를 포함하도록 변경해야 합니다.
-
GitLab UI 사용 방법:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하여 그룹을 찾습니다.
- 설정 > 일반을 선택합니다.
- 고급을 확장합니다.
- 그룹 URL 변경 아래에서 그룹 URL에 숫자 이외의 문자를 포함하도록 변경합니다.
-
그룹 API 사용 방법.
기타 404
오류
그룹 가져오기를 시도할 때 기타 404
오류를 받을 수 있습니다. 예를 들어:
"exception_message": "[필터링됨] Bo...에서 불성공한 응답 404",
"exception_class": "BulkImports::NetworkError",
이 오류는 소스 인스턴스로부터의 전송 문제를 나타냅니다. 이를 해결하려면 소스 인스턴스에서 전제 조건을 충족했는지 확인합니다.
이관 기간 단축
단일 직접 전송 이관은 목적지 인스턴스에서 가능한 워커 수와 관계없이 가져오기당 5개의 엔티티(그룹 또는 프로젝트)를 실행합니다. 즉, 목적지 인스턴스에서 사용 가능한 워커 수가 많을수록 각 엔티티를 가져오는 데 걸리는 시간을 줄일 수 있습니다.
복수의 대상 인스턴스에서 사용 가능한 워커 수가 충분하면 가져오기 기간을 줄일 수 있습니다. 배치로 관계를 내보내고 가져오는 것(epic 9036에서 제안됨)은 목적지 인스턴스에서 충분한 워커를 가지고 있는 것이 더욱 유용하게 만듭니다.
소스 인스턴스의 워커 수는 가져오기 당 5개의 엔티티를 병렬로 내보내기에 충분해야 합니다. 그렇지 않으면 가져오기가 지연되거나 시간 초과가 발생할 수 있습니다.
여러 그룹에 프로젝트를 분산시키면 시간 초과를 피하는 데 도움이 됩니다. 하나의 그룹에 여러 대형 프로젝트가 있는 경우 다음을 수행할 수 있습니다:
- 대형 프로젝트를 다른 그룹이나 서브그룹으로 이동합니다.
- 별도의 이관에서 각각의 그룹 및 서브그룹을 시작합니다.
GitLab UI는 최상위 그룹만 가져올 수 있습니다. API를 사용하면 서브그룹도 이관할 수 있습니다.