GitHub Actions 외부 스토리지 마이그레이션

GitHub Actions 외부 스토리지 마이그레이션 정보

클라우드 계정을 통합 GitHub Actions 하거나, 상주 요구 사항을 충족하거나, 스토리지 테넌트를 다시 구성할 때 동일한 공급자의 새 버킷, 계정 또는 지역으로 외부 스토리지를 마이그레이션할 수 있습니다.

마이그레이션은 버킷 또는 계정 이름이 아닌 버킷 또는 컨테이너 내의 키(경로)로 저장된 개체를 식별하기 때문에 GitHub Actions 작동합니다. 내부 키 레이아웃을 유지하고 새 위치를 가리키도록 구성을 업데이트하는 한 기존 워크플로 로그 및 아티팩트는 중단 없이 계속 액세스할 수 있습니다.

Considerations

시작하기 전에 다음 제약 조건을 검토합니다. 각각은 마이그레이션 방식을 형성하고, 무시하면 몇 가지 데이터 손실이 발생할 수 있습니다.

동일한 공급자만 해당합니다. 이 절차는 동일한 스토리지 공급자 유형 내 마이그레이션(예: Amazon S3에서 Amazon S3로, Azure Blob에서 Azure Blob으로, Google Cloud Storage에서 Google Cloud Storage로, 또는 MinIO에서 MinIO로)을 지원합니다. 공급자 간 마이그레이션은 여기서 다루지 않습니다. 서비스 제공업체 간 마이그레이션의 경우 GitHub Enterprise 지원에 문의하세요.
마이그레이션하는 동안 인증 방법을 변경하지 마세요. 현재 자격 증명 기반 인증을 사용하는 경우 대상 구성에서도 자격 증명 기반 인증을 사용해야 합니다. OpenID Connect도 마찬가지입니다. 스토리지 구성을 변경하는 동안 인증 방법을 전환하면 데이터가 손실될 수 있습니다. 자세한 내용은 GitHub Actions 스토리지에 대한 자격 증명 업데이트을(를) 참조하세요. 인증 방법을 변경하려면 먼저 스토리지 마이그레이션을 완료한 다음 별도의 변경을 계획합니다.
버킷 또는 컨테이너 내의 키 레이아웃은 유지되어야 합니다. 원본 버킷 또는 컨테이너 내의 개체 키(경로)는 대상에서 동일하게 유지되어야 합니다. 대상 버킷 이름, 스토리지 계정, 지역 및 기타 연결 매개 변수를 변경할 수 있습니다. 컷오버 시 관리 콘솔에서 이 항목들을 업데이트합니다. 대부분의 네이티브 공급자 복사 도구는 전체 버킷 또는 컨테이너를 복사할 때 자동으로 키 레이아웃을 유지하지만, 중단 전에 대상이 원본과 일치하는지 확인합니다.
GitHub Packages 에는 추가 제약 조건이 있습니다. 또한 사용하는 GitHub Packages경우 시작하기 전에 아래 고려 사항 섹션을 참조GitHub Packages하세요.

사전 요구 사항

귀하는 GitHub Enterprise Server 인스턴스에 대한 사이트 관리자 액세스 권한이 있습니다.
원하는 계정, 지역 또는 테넌시에서 원본과 동일한 공급자에 대상 스토리지를 프로비전했습니다.
대상이 비어 있습니다.
대상은 원본과 GitHub Enterprise Server 인스턴스 동일한 권한을 부여합니다. 필요한 권한은 관련 구성 문서를 참조하세요.
원본 및 대상 스토리지 모두에 대한 관리 자격 증명이 있으므로 모든 원본 개체를 읽고 대상에 쓸 수 있습니다.
의 최근 백업이 있습니다 GitHub Enterprise Server 인스턴스. 자세한 내용은 Backup 유틸리티를 사용하여 인스턴스에서 백업 구성을(를) 참조하세요.
스테이징 환경에서 마이그레이션을 연습했습니다. 다음 섹션을 확인하세요.

프로덕션에 대해 마이그레이션을 수행하기 전에 스테이징 인스턴스에서 전체 프로시저를 연습합니다. 최근 프로덕션 백업에서 스테이징 GitHub Enterprise Server 인스턴스를 프로비저닝하고, 이를 의도한 프로덕션 대상을 미러링하는 임시 대상에 연결한 다음, 이 문서의 모든 단계를 처음부터 끝까지 수행하세요. 자세한 내용은 스테이징 인스턴스 설정 및 스테이징 환경 사용하기을(를) 참조하세요.

스테이징 리허설은 다음 사항을 검증합니다:

대상에 대한 공급자 쪽 권한, 네트워크 액세스 및 정책이 정확합니다.
선택한 복사 도구가 대표적인 데이터 볼륨에 대해 성공적으로 완료됩니다.
예상 개체 수와 총 크기가 원본과 대상에서 일치합니다.
기존 워크플로 실행 로그 및 아티팩트가 중단 후 UI를 통해 검색할 수 있습니다.

경고

스테이징 인스턴스는 프로덕션 인스턴스와 다른 스토리지를 사용해야 합니다. 스토리지 구성을 변경하지 않으면 스테이징 인스턴스가 프로덕션 스토리지에 기록되어 데이터 손실이 발생할 수 있습니다. 자세한 내용은 스테이징 환경 사용하기을(를) 참조하세요.

마이그레이션 수행

다음 단계를 순서대로 수행합니다. GitHub Actions 는 유지 관리 모드를 사용하도록 설정할 때까지 트래픽을 계속 제공할 수 있습니다.

초기 데이터 복사를 수행합니다. 공급자 네이티브 도구를 사용하여 원본에서 대상으로 모든 개체를 복사합니다. 복사 중에 원본에 새로 기록되는 개체는 컷오버 후 최종 델타 동기화에 반영됩니다.

예제 명령을 시작점으로 사용합니다. 자격 증명, 암호화 및 처리량 튜닝을 비롯한 전체 옵션 집합은 업스트림 설명서를 참조하세요.

Amazon S3의 경우 AWS 명령줄 인터페이스에서 사용합니다aws s3 sync. 먼저 드라이 런을 실행하여 작업의 유효성을 검사한 다음 복사를 수행합니다.

aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET --dryrun
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET

Azure Blob Storage 경우 원본에서 공유 액세스 서명과 함께 사용합니다azcopy copy.

azcopy copy 'https://SOURCE-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER?SAS-TOKEN' 'https://DESTINATION-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER' --recursive

Google Cloud Storage의 경우 Google Cloud 명령줄 인터페이스에서 사용합니다gcloud storage rsync.

gcloud storage rsync --recursive gs://SOURCE-BUCKET gs://DESTINATION-BUCKET

MinIO의 경우 MinIO 클라이언트에서 사용합니다mc mirror.

mc mirror SOURCE-ALIAS/SOURCE-BUCKET DESTINATION-ALIAS/DESTINATION-BUCKET

복사가 완료되면 공급자의 표준 목록 도구를 사용하여 대상의 개체 수와 총 크기를 확인합니다. 계속하기 전에 불일치를 조사합니다.

유지 관리 모드를 사용하도록 설정합니다. 컷오버 중 원본에 새 개체가 기록되지 않도록 하려면 GitHub Enterprise Server 인스턴스에서 유지 관리 모드를 사용하도록 설정합니다. 이렇게 하면 최종 사용자가 인스턴스를 오프라인으로 전환할 수 있습니다. 자세한 내용은 유지 관리 모드 사용 설정 및 예약을(를) 참조하세요.
최종 델타 동기화를 수행합니다. 유지 관리 모드를 사용하도록 설정하면 초기 복사 단계에서 동일한 복사 명령을 다시 실행합니다. 초기 복사가 시작된 후 원본에 기록된 모든 개체를 캡처합니다.

예를 들어 Amazon S3의 경우:
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
스토리지 구성을 업데이트합니다. 새 스토리지 위치를 가리키도록 업데이트 GitHub Enterprise Server 인스턴스 합니다. 이전과 동일한 인증 방법을 유지합니다.
1. 관리 콘솔에 로그인하세요. 자세한 내용은 관리 콘솔에 액세스을(를) 참조하세요.
2. "설정" 사이드바에서 작업을 클릭합니다.
3. "Artifact & Log Storage"에서 스토리지 위치를 식별하는 필드(예: 버킷 이름, 계정 이름, 리전, 역할 ARN 또는 연결 문자열)를 업데이트합니다. 인증 방법을 변경하지 마세요.
4. 스토리지 설정 테스트를 클릭하여 새 구성의 유효성을 검사합니다.
  
  경고
  
  테스트가 실패하면 설정을 저장하지 마세요. 계속하기 전에 오류를 조사하고 다시 테스트합니다. 잘못된 스토리지 구성을 저장하면 중단이 발생할 수 있습니다.
5. 설정 저장을 클릭하고 서비스가 완전히 다시 시작될 때까지 기다립니다.
또는 자격 증명 기반 인증을 사용하여 ghe-actions-precheck 명령줄에서 구성을 업데이트할 수 있습니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.
마이그레이션의 유효성을 검사합니다. 구성이 변경된 후 새 스토리지 위치에서 읽을 수 있음을 GitHub Actions 확인합니다.
1. 유지 관리 모드 사용 중지. 자세한 내용은 유지 관리 모드 사용 설정 및 예약을(를) 참조하세요.
2. 웹 UI에서 GitHub Enterprise Server 인스턴스마이그레이션 전에 완료된 최근 워크플로 실행을 엽니다. 다음을 확인합니다:
  - 워크플로 실행 로그를 불러오는 중입니다.
  - 빌드 아티팩트가 성공적으로 다운로드됩니다.
3. 새 워크플로 실행을 트리거하고 다음을 확인합니다.
  - 실행이 성공적으로 완료됩니다.
  - 실행에서 생성된 로그 및 아티팩트가 표시됩니다.
이러한 유효성 검사 중 어느 것이라도 실패하면 원본 스토리지를 유지하고 아래 의 롤백 섹션을 참조하세요.
원본 스토리지를 서비스 해제합니다. 유효성 검사가 성공적으로 완료되고 새 스토리지 위치가 정상임을 확신할 수 있는 충분한 시간을 허용한 후에만 계속 진행합니다. 지침으로 삭제하기 전에 하나 이상의 전체 백업 주기 동안 원본 스토리지를 읽기 전용 상태로 유지합니다.

원본 스토리지를 제거할 준비가 되면 버킷 또는 컨테이너를 삭제하기 위한 공급자의 표준 절차를 따릅니다.

롤백 중

유효성 검사에 실패하거나 전환 후 문제가 발생하면 GitHub Enterprise Server 인스턴스이(가) 원본 스토리지 위치를 다시 가리키도록 하여 롤백하세요. 원본 스토리지는 정상으로 알려진 복사본입니다. 롤백 과정에서 대상의 데이터를 소스로 다시 복사하지 마세요. 컷오버 실패 중 대상에 기록된 데이터는 일부만 기록되었거나 일관성이 없을 수 있으며, 이를 소스에 다시 쓰면 유일하게 정상인 복사본이 손상될 위험이 있습니다.

경고

롤백하면 전환 이후에 기록되었거나 삭제된 모든 데이터가 폐기됩니다. 유효성 검사에 실패하면 확장된 문제 해결을 시도하지 않고 즉시 롤백합니다. 더 오래 기다릴수록 더 많은 데이터가 위험에 처하게 됩니다.

유효성 검사에 실패하거나 문제가 발생하는 경우:

유지 관리 모드를 즉시 사용하도록 설정합니다.
관리 콘솔에서 원래 스토리지 구성 값을 복원하고 스토리지 설정 테스트를 클릭한 다음 , 설정을 저장합니다.
유지 관리 모드를 사용하지 않도록 설정하고 원래 스토리지를 사용하여 유효성 검사 단계를 다시 실행합니다.

성공적인 롤백 후 실패를 조사하고 새 마이그레이션 시도를 계획합니다.

GitHub Packages 고려 사항

다음과 같은 중요한 차이점이 있지만, 동일한 마이그레이션 접근 방식을 GitHub Packages 외부 스토리지에도 적용할 수 있습니다. 사용하도록 설정된 인스턴스 GitHub Packages 에서 스토리지를 마이그레이션하기 전에 이 섹션을 전체적으로 읽어보십시오.

OpenID Connect를 사용할 수 GitHub Packages없습니다. GitHub Packages 는 외부 스토리지에 대한 자격 증명 기반 인증만 지원합니다. 이 문서의 인증 방법 제약 조건은 여전히 적용됩니다. 마이그레이션 중에 인증 방법을 변경하지 않고 유지합니다.
GitHub Packages 은 타이밍 불일치에 더 민감합니다. 마이그레이션 기간 동안 패키지가 게시되면 시스템은 새 스토리지 개체와 데이터베이스 레코드를 모두 만듭니다. 불일치를 방지하려면 새 구성의 성공적인 유효성 검사를 통해 최종 델타 동기화가 시작될 때부터 유지 관리 모드를 계속 사용하도록 설정합니다.
동일한 공급자가 두 제품을 모두 제공하는 경우 두 구성을 함께 업데이트합니다. GitHub Actions 및 GitHub Packages이 동일한 공급자 유형을 사용하도록 구성되어 있고 둘 다 마이그레이션할 경우, 전환을 단일 유지 관리 기간으로 계획하고 유지 관리 모드를 해제하기 전에 두 구성을 모두 업데이트하세요.
스토리지의 GitHub Packages 공급자 간 마이그레이션은 다음으로 문의하세요 GitHub Enterprise 지원. 공급자 간 이동은 여기서 다루지 않습니다.

스토리지 구성 GitHub Packages 에 대한 자세한 내용은 엔터프라이즈용 GitHub 패키지 시작을 참조하세요.

누가 이 기능을 사용할 수 있나요?

이 기사에서