이 가이드에서는 모든 정보를 포함한 Git 저장소를 Google의 Cloud Source Repositories (CSR)에서 Secure Source Manager (SSM)로 이전하는 방법을 설명합니다. 이 이전에서는 표준 Git 명령어를 사용하여 저장소 데이터를 클론하고 푸시합니다.
기본 요건
마이그레이션을 시작하기 전에 다음 기본 요건을 충족하는지 확인하세요.
- 권한: 사용자 또는 서비스 계정에 마이그레이션을 실행할 수 있는 다음 권한이 있어야 합니다.
source.repos.get: 소스 CSR 저장소에서roles/source.reader역할로 사용할 수 있습니다.roles/securesourcemanager.instanceAccessor역할에서 사용할 수 있는securesourcemanager.instances.access와 대상 SSM 인스턴스 및 저장소의roles/securesourcemanager.repoWriter역할에서 사용할 수 있는securesourcemanager.repositories.fetch새 저장소를 만드는 경우 저장소 만들기를 참고하세요.
- Git 클라이언트: Git 명령줄 도구가 설치된 컴퓨터가 필요합니다.
- Google Cloud SDK: HTTPS를 사용할 때 인증하려면 Git 도구를 설치한 컴퓨터에 버전 395.0.0 이상을 설치해야 합니다. Google Cloud SDK가 없는 경우 SSH 키를 사용하여 CSR과 SSM에 모두 연결해야 합니다.
- SSM 인스턴스: 컴퓨터에서 SSM 인스턴스에 액세스할 수 있는지 확인합니다. Private Service Connect를 사용하여 인스턴스를 구성한 경우 액세스 세부정보는 비공개 인스턴스 액세스를 참고하세요.
- 로컬 스토리지: 이전하는 저장소의 클론을 임시로 저장할 충분한 로컬 디스크 공간이 필요합니다.
마이그레이션 단계
마이그레이션 프로세스에는 CSR에서 로컬 컴퓨터로 전체 저장소를 클론한 다음 클론을 SSM 저장소로 푸시하는 작업이 포함됩니다.
CSR, SSM 저장소의 액세스 주 구성원 및 방법 결정
사용자 보안 주체로 인증할 때는 HTTP 또는 SSH 전송을 사용하여 CSR에 연결할 수 있고, 서비스 계정으로 인증할 때는 HTTP를 통해 연결할 수 있습니다. 사용자 또는 서비스 계정 보안 주체로서 HTTP 또는 SSH 트랜스포트를 사용하여 SSM에 연결하고 인증할 수 있습니다.
CSR과 SSM에서 동일한 전송 또는 주체를 사용할 필요는 없습니다. 각 플랫폼에 사용할 주 구성원과 전송을 결정합니다. 서비스 계정 가장에 대한 자세한 내용은 서비스 계정 가장을 참고하세요.
CSR 저장소가 읽기 전용인지 확인
이 이전 가이드에서는 자동 미러링이나 동기화를 사용하지 않습니다.
따라서 마이그레이션 중이나 마이그레이션 후에는 아무도 CSR 저장소에 쓰지 않아야 합니다. 어떤 사용자도 저장소에서 roles/source.reader 이외의 역할을 갖지 않도록 IAM 권한을 업데이트합니다. 또는 사용자와 협력하여 이전 중에 모든 커밋을 중지합니다.
Secure Source Manager 저장소 만들기
관리자가 이미 저장소를 만든 경우 이 단계를 건너뛸 수 있습니다.
SSM 인스턴스에서 빈 저장소를 만들려면 새 저장소 만들기 가이드를 따르세요. 다음 사항을 확인하세요.
- UI를 사용하는 경우 저장소 초기화를 선택하지 마세요. 비어 있지 않은 저장소가 생성되기 때문입니다.
- Google Cloud CLI를 사용하는 경우
--gitignores,--readme,--licenses플래그를 설정하지 마세요. 비어 있지 않은 저장소가 생성되기 때문입니다. - API를 사용하는 경우
InitialConfig의gitignores,license,readme필드를 설정하지 마세요. 이렇게 하면 비어 있지 않은 저장소가 생성됩니다.
SSM 저장소 설정 확인
UI를 확인하거나 저장소를 클론하고 git show-ref을 실행하여 저장소가 비어 있는지 확인합니다. 저장소가 비어 있으면 출력도 비어 있습니다.
UI를 확인하거나 API를 사용하여 활성 브랜치 보호 규칙이 없는지 확인합니다. 이전을 차단하지 않도록 규칙이 없거나 모든 규칙이 사용 중지되어야 합니다.
로컬 및 원격 디스크 공간 확인
CSR 저장소를 클론하기 전에 총 크기를 확인합니다. gcloud source repos describe <var>CSR_REPO_NAME</var>를 실행합니다. 이 명령어는 저장소의 총 바이트 수를 표시합니다. Linux 시스템에서 사용 가능한 디스크 공간을 평가하려면 df .을 실행하여 현재 디렉터리에서 사용 가능한 바이트 수를 확인합니다.
SSM의 인스턴스당 기본 저장용량 한도는 100GB입니다. CSR 저장소를 클론하기 전에 적합한지 확인하세요.
CSR 저장소 클론
CSR에서 로컬 컴퓨터로 전체 저장소 기록을 클론합니다.
- 저장소를 임시로 저장할 로컬 디렉터리로 이동합니다.
- 저장소를 클론합니다.
sh git clone <var>CSR_REPO_URL</var> --mirror
이 명령어는 전체 저장소 콘텐츠를 다른 원격으로 푸시하는 데 최적화된 베어 클론을 만듭니다. 디렉터리에는 저장소 콘텐츠 대신 config, HEAD과 같은 파일만 포함되어 있습니다.
이는 예상된 동작입니다. 모든 저장소 콘텐츠가 클론되어 objects 디렉터리 등에 있지만 작업 사본은 없습니다.
Secure Source Manager 저장소를 새 원격으로 추가
다음 명령어를 실행합니다.
git remote add ssm <var>SSM_REPOSITORY_URL</var>
전체 저장소를 Secure Source Manager에 푸시
로컬 클론의 모든 브랜치, 태그, 참조를 SSM 원격으로 푸시합니다.
git push --mirror ssm
검증
푸시 작업이 완료되면 SSM 저장소를 다른 디렉터리로 클론합니다. 그런 다음 저장소의 CSR 및 SSM 사본을 비교합니다.
- 브랜치 수: 각 저장소에서
git branch -r를 실행하고 브랜치 수가 동일한지 확인합니다. Linux 또는 macOS 시스템에서 명령어를wc -l로 파이프하면 출력 줄 수가 계산됩니다. - 태그 수: 각 저장소에서
git tag를 실행하고 태그 수가 동일한지 확인합니다. Linux 또는 macOS 시스템에서 명령어를wc -l로 파이프하면 출력 줄 수가 계산됩니다. - HEAD 커밋: 각 저장소에서
git rev-parse HEAD를 실행하고 커밋 해시가 동일한지 확인합니다. - 커밋 수: 각 저장소에서
git rev-list --all --count를 실행하고 커밋 수가 동일한지 확인합니다.
삭제
- 이전 중에 서비스 계정을 가장한 경우
gcloud config set account를 실행하여 사용자 인증 정보를 재설정합니다. - 브랜치 보호 규칙을 사용 중지한 경우 SSM 저장소에서 브랜치 보호 규칙을 다시 사용 설정합니다.
- 이전하는 데 사용한 컴퓨터에서 CSR 저장소의 베어 복사본을 삭제합니다.
- 원본 CSR 저장소를 삭제합니다.