참고
Enterprise Live Migrations 가 있으며 공개 미리 보기 변경될 수 있습니다.
팁
이 가이드를 따르면 기업용 라이브 마이그레이션 CLI 참고 문서 을 참조하여 자세한 사용 정보를 확인할 수 있습니다. 오류가 발생하면 GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 문제 해결을 참조하세요.
사전 요구 사항
마이그레이션할 준비가 되었는지 확인합니다. GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 준비을(를) 참조하세요.
1. 액세스 토큰 만들기
마이그레이션의 원본 및 대상 모두에 대해 인증 personal access token (classic) 해야 합니다. 자세한 지침은 개인용 액세스 토큰 관리을 참조하세요.
다음 단계에서 필요하므로 두 토큰을 모두 기록해 둡니다.
-
다음 범위를 사용하여 personal access token (classic) 에 GitHub Enterprise Server을 만드십시오.
repoadmin:orgadmin:repo_hookadmin:org_hook
-
다음 범위를 사용하여 personal access token (classic) 에서 GHE.com을 만드십시오.
repoworkflowadmin:orgadmin:repo_hookadmin:enterprise
-
대상 조직에 단일 로그인이 GHE.com 적용될 경우, GHE.com 토큰에 권한을 부여하십시오.
2. 구성 GitHub Enterprise Server
마이그레이션을 수행하기 전에 인스턴스에서 GitHub Enterprise Server 일부 구성을 설정해야 합니다. 이러한 구성 값은 모든 ELM 마이그레이션에 적용됩니다. 개발자는 GitHub Enterprise Server 새 구성을 적용할 때 짧은 가동 중지 시간이 발생할 수 있습니다.
-
SSH를 GitHub Enterprise Server 통해 관리 셸에 액세스합니다. 관리 셸(SSH)에 액세스을(를) 참조하세요.
-
를 사용하여 다음 구성 변수를
ghe-config설정합니다.예를 들어:
ghe-config app.elm-exporter.enabled true변수 이 값으로 설정합니다. app.elm-exporter.enabledtrueapp.elm.internal-webhooks-enabledtrueapp.elm-exporter.webhooks-loopback-address-enabledtruesecrets.elm-exporter.migration-target-url대상 엔터프라이즈의 API URL입니다(예: https://api.octocorp.ghe.com). URL의 끝에 후행 슬래시를 포함하지 마세요 .secrets.elm-exporter.migration-target-tokenGHE.com에 대해 만든 액세스 토큰입니다. ||
secrets.elm-exporter.source-token| GitHub Enterprise Server에 대해 만든 액세스 토큰입니다. | |secrets.elm-exporter.source-user| 토큰과 GitHub Enterprise Server 연결된 사용자 이름(예:ghe-admin)입니다. | -
인스턴스에서 마이그레이션을 사용하도록 설정하고 Blob Storage를 구성 하지 않은 경우 지금 구성할 수 있습니다. 관리 콘솔(
HOSTNAME/setup/settings)의 "마이그레이션" 섹션에서 기존 설정을 확인할 수 있습니다.예기치 않은 기능을 도입하지 않는 다음 기본값을 사용할 수 있습니다.
Shell ghe-config app.migrations.enabled true
ghe-config app.migrations.enabled trueShell ghe-config secrets.migrations.blob-storage-type local-storage
ghe-config secrets.migrations.blob-storage-type local-storage -
구성을 적용하세요.
Shell ghe-config-apply
ghe-config-apply
3. 필요한 환경 변수 설정
구성이 적용된 경우 마이그레이션을 시작하기 전에 필요한 환경 변수를 설정합니다. 다음은 그 예입니다.
export API_URL='http://localhost:1738'
중요
API_URL 및 MIGRATION_MANAGER_HMAC_KEY의 값을 그대로 복사합니다. 다른 변수는 사용자 환경에 따라 다릅니다.
| 변수 | 필수 값 |
|---|---|
| API_URL | http://localhost:1738 |
| MIGRATION_MANAGER_HMAC_KEY | $(ghe-config secrets.elm-exporter.elm-exporter-hmac-keys) |
| MIGRATION_TARGET_URL | 대상 엔터프라이즈의 API URL입니다(예: https://api.octocorp.ghe.com). URL의 끝에 후행 슬래시를 포함하지 마세요 . |
| MIGRATION_TARGET_TOKEN | personal access token (classic) 을 위한 GHE.com |
이러한 값은 모든 elm 명령에서 CLI 플래그로 제공될 수도 있습니다. 이 플래그는 변수보다 우선합니다. 예: --api-url http://localhost:1738.
4. 마이그레이션 만들기
원본 및 대상 리포지토리 세부 정보를 지정하여 새 마이그레이션을 만듭니다.
--pat-name은 system-pat로 정적 값으로 설정해야 합니다. 다른 값은 사용자 환경과 관련된 자리 표시자입니다.
참고
새 target-org 항목 또는 기존 항목일 수 있습니다. 대상 조직이 아직 없는 경우 마이그레이션 중에 만들어집니다. 그러나 원본 조직의 설정은 마이그레이션되지 않습니다.
elm migration create \ --source-org EXISTING-GHES-ORG \ --source-repo EXISTING-GHES-REPO \ --target-org GHEC-ORG \ --target-repo NEW-GHEC-REPO \ --target-api GHEC-API-URL \ --pat-name system-pat
elm migration create \
--source-org EXISTING-GHES-ORG \
--source-repo EXISTING-GHES-REPO \
--target-org GHEC-ORG \
--target-repo NEW-GHEC-REPO \
--target-api GHEC-API-URL \
--pat-name system-pat
다음은 그 예입니다.
elm migration create \
--source-org my-ghes-org \
--source-repo my-ghes-repo \
--target-org my-dr-org \
--target-repo my-dr-repo \
--target-api $MIGRATION_TARGET_URL \
--pat-name system-pat
선택적 플래그:
--start: 마이그레이션을 즉시 시작할 준비가 되었는지 확인합니다.--target-visibility: 마이그레이션된 리포지토리는 기본적으로 내부 표시 유형으로 만들어지지만 지정할private수 있습니다.
마이그레이션 ID 저장
다음과 같은 응답이 표시됩니다.
{
"migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
"expiresAt": "2026-02-11T21:49:33.619162159Z"
}
`migrationId` 다음 명령에 필요하므로 변수로 내보냅니다. 다음은 그 예입니다.
export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'
5. 마이그레이션 시작
마이그레이션을 아직 시작하지 않은 경우 방금 저장한 마이그레이션 ID를 사용하여 지금 시작합니다.
elm migration start --migration-id $MIGRATION_ID
elm migration start --migration-id $MIGRATION_ID
그러면 백필 및 라이브 업데이트 프로세스가 시작됩니다. ELM 는 이제 원본 리포지토리에서 데이터를 수집하고 지원되는 웹후크 이벤트를 수신 대기합니다.
6. 마이그레이션 모니터링
마이그레이션이 시작되면 새 리포지토리가 표시됩니다 GHE.com. 마이그레이션하는 동안 개발자가 원본 리포지토리에서 계속 작업할 때 초기 데이터 로드로 리포지토리가 채워지고 업데이트가 수신됩니다.
마이그레이션 상태를 모니터링하려면 다음 명령을 정기적으로 실행합니다. 원본 및 대상의 상태 분석과 마이그레이션 중인 라이브 데이터에 대한 정보가 표시됩니다.
elm migration status --migration-id $MIGRATION_ID
elm migration status --migration-id $MIGRATION_ID
응답에서 가장 중요한 지표는 combinedState 개체의 상태입니다. 상태가 COMBINED_STATUS_READY_FOR_CUTOVER에 도달하면 다음 단계로 진행할 준비를 해야 합니다. 그러나 개별 리소스가 displayMessage에서 마이그레이션에 실패하면 조사가 필요할 수 있다는 경고가 표시됩니다.
다음은 그 예입니다.
"combinedState": {
"status": "COMBINED_STATUS_READY_FOR_CUTOVER",
"displayMessage": "Ready for cutover (1 resources failed)",
"repositories": [
{
"repositoryNwo": "new-test-org/my-new-repo",
"phase": "REPOSITORY_PHASE_READY_FOR_CUTOVER",
"displayStatus": "Ready for cutover (1 failed)"
}
],
"readyForCutover": true,
"cutoverBlockers": []
},
팁:
- 여러 마이그레이션을 실행하는 경우 .를 사용하여 모든
elm migration list마이그레이션의 상태를 확인할 수 있습니다. 이 명령은 기본적으로 진행 중인 마이그레이션을 표시하지만 다음을 통해--status필터링할 수도 있습니다. - 주의가 필요한 실패 상태가 발생하는 경우 GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 문제 해결을 참조하세요.
7. 마이그레이션 완료
마이그레이션을 중단할 준비가 되면 마이그레이션을 완료할 수 있습니다. 단독형 프로세스는 원본 리포지토리를 잠그므로 관리자가 잠금을 해제하지 않는 한 개발자가 영구적으로 사용할 수 없게 됩니다.
elm migration cutover-to-destination --migration-id $MIGRATION_ID
elm migration cutover-to-destination --migration-id $MIGRATION_ID
마이그레이션을 계속 모니터링합니다. 응답 맨 위에 상태가 표시 MIGRATION_STATUS_COMPLETED 되면 마이그레이션이 완료되지만 사용자에게 GitHub Enterprise Server액세스 권한을 부여하는 몇 가지 후속 작업이 있습니다.
다음 단계
사용자에게 새 리포지토리에 대한 액세스 권한을 부여하고 사용자 계정과 작업을 조정합니다. GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 완료을(를) 참조하세요.