# Enterprise Live Migrations를 사용하여 리포지토리 마이그레이션 GitHub Enterprise Server에서 GHE.com으로 전환하면서 가동 중지 시간을 최소화합니다. > \[!NOTE] > Enterprise Live Migrations 가 있으며 공개 미리 보기 변경될 수 있습니다. > \[!TIP] 이 가이드를 따르면 [기업용 라이브 마이그레이션 CLI 참고 문서](/ko/enterprise-server@3.22/migrations/elm/elm-cli-reference) 을 참조하여 자세한 사용 정보를 확인할 수 있습니다. 오류가 발생하면 [GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 문제 해결](/ko/enterprise-server@3.22/migrations/elm/troubleshooting)을 참조하세요. ## 사전 요구 사항 마이그레이션할 준비가 되었는지 확인합니다. [GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 준비](/ko/enterprise-server@3.22/migrations/elm/prepare-for-your-migration)을(를) 참조하세요. ## 1. 액세스 토큰 만들기 마이그레이션의 원본 및 대상 모두에 대해 인증 personal access token (classic) 해야 합니다. 자세한 지침은 [개인용 액세스 토큰 관리](/ko/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)을 참조하세요. 다음 단계에서 필요하므로 **두 토큰을 모두 기록**해 둡니다. 1. 다음 범위를 사용하여 personal access token (classic)에 GitHub Enterprise Server을 만드십시오. * `repo` * `admin:org` * `admin:repo_hook` * `admin:org_hook` 2. 다음 범위를 사용하여 personal access token (classic)에 GHE.com을 만드십시오. * `repo` * `workflow` * `admin:org` * `admin:repo_hook` * `admin:enterprise` 3. 대상 조직에 단일 로그인이 GHE.com 적용될 경우, GHE.com 토큰에 권한을 부여하십시오. ## 2. 구성 GitHub Enterprise Server 마이그레이션을 수행하기 전에 인스턴스에서 GitHub Enterprise Server 일부 구성을 설정해야 합니다. 이러한 구성 값은 모든 ELM 마이그레이션에 적용됩니다. 개발자는 GitHub Enterprise Server 새 구성을 적용할 때 짧은 가동 중지 시간이 발생할 수 있습니다. 1. SSH를 GitHub Enterprise Server 통해 관리 셸에 액세스합니다. [관리 셸(SSH)에 액세스](/ko/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)을(를) 참조하세요. 2. 를 사용하여 다음 구성 변수를 `ghe-config`설정합니다. 예를 들어: `ghe-config app.elm-exporter.enabled true` | 변수 | 이 값으로 설정합니다. | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------- | | `app.elm-exporter.enabled` | `true` | | `app.elm.internal-webhooks-enabled` | `true` | | `app.elm-exporter.webhooks-loopback-address-enabled` | `true` | | `secrets.elm-exporter.migration-target-url` | 대상 엔터프라이즈의 API URL입니다(예: `https://api.octocorp.ghe.com`). URL의 끝에 후행 슬래시를 포함하지 **마세요** . | | `secrets.elm-exporter.migration-target-token` | | GHE.com에 대해 만든 액세스 토큰입니다. | \| `secrets.elm-exporter.source-token` | GitHub Enterprise Server에 대해 만든 액세스 토큰입니다. | \| `secrets.elm-exporter.source-user` | 토큰과 GitHub Enterprise Server 연결된 사용자 이름(예: `ghe-admin`)입니다. | \| `app.migrations.enabled` | 인스턴스에서 마이그레이션을 사용하도록 설정하지 않은 경우 이를 `true`.로 설정해야 합니다. | 1. 구성을 적용하세요. ```shell copy ghe-config-apply ``` ## 3. 필요한 환경 변수 설정 구성이 적용된 경우 마이그레이션을 시작하기 전에 필요한 환경 변수를 설정합니다. 다음은 그 예입니다. ```shell export API_URL='http://localhost:1738' ``` > \[!IMPORTANT] > `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`로 정적 값으로 설정해야 합니다. 다른 값은 사용자 환경과 관련된 자리 표시자입니다. > \[!NOTE] 새 `target-org` 항목 또는 기존 항목일 수 있습니다. 대상 조직이 아직 없는 경우 마이그레이션 중에 만들어집니다. 그러나 원본 조직의 설정은 마이그레이션되지 않습니다. ```shell copy 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 ``` 다음은 그 예입니다. ```shell 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 저장 다음과 같은 응답이 표시됩니다. ```json { "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9", "expiresAt": "2026-02-11T21:49:33.619162159Z" } ``` `migrationId` 다음 명령에 필요하므로 변수로 내보냅니다. 다음은 그 예입니다. ```shell export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9' ``` ## 5. 마이그레이션 시작 마이그레이션을 아직 시작하지 않은 경우 방금 저장한 마이그레이션 ID를 사용하여 지금 시작합니다. ```shell copy elm migration start --migration-id $MIGRATION_ID ``` 그러면 백필 및 라이브 업데이트 프로세스가 시작됩니다. ELM 는 이제 원본 리포지토리에서 데이터를 수집하고 지원되는 웹후크 이벤트를 수신 대기합니다. ## 6. 마이그레이션 모니터링 마이그레이션이 시작되면 새 리포지토리가 표시됩니다 GHE.com. 마이그레이션하는 동안 개발자가 원본 리포지토리에서 계속 작업할 때 초기 데이터 로드로 리포지토리가 채워지고 업데이트가 수신됩니다. 마이그레이션 상태를 모니터링하려면 다음 명령을 정기적으로 실행합니다. 원본 및 대상의 상태 분석과 마이그레이션 중인 라이브 데이터에 대한 정보가 표시됩니다. ```shell copy elm migration status --migration-id $MIGRATION_ID ``` 응답에서 가장 중요한 지표는 **combinedState** 개체의 상태입니다. 상태가 `COMBINED_STATUS_READY_FOR_CUTOVER`에 도달하면 다음 단계로 진행할 준비를 해야 합니다. 그러나 개별 리소스가 `displayMessage`에서 마이그레이션에 실패하면 조사가 필요할 수 있다는 경고가 표시됩니다. 다음은 그 예입니다. ```json "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 실시간 마이그레이션 문제 해결](/ko/enterprise-server@3.22/migrations/elm/troubleshooting#statuses-and-recommended-actions)을 참조하세요. ## 7. 마이그레이션 완료 마이그레이션을 중단할 준비가 되면 마이그레이션을 완료할 수 있습니다. 컷오버 프로세스는 원본 리포지토리를 보관 처리하므로, 리포지토리 관리자가 보관 해제하지 않는 한 **영구적으로 읽기 전용** 상태가 됩니다. ```shell copy elm migration cutover-to-destination --migration-id $MIGRATION_ID ``` 마이그레이션을 계속 모니터링합니다. 응답 맨 위에 상태가 표시 `MIGRATION_STATUS_COMPLETED` 되면 마이그레이션이 완료되지만 사용자에게 GitHub Enterprise Server액세스 권한을 부여하는 몇 가지 후속 작업이 있습니다. ## 다음 단계 사용자에게 새 리포지토리에 대한 액세스 권한을 부여하고 사용자 계정과 작업을 조정합니다. [GitHub Enterprise Server에서 GHE.com 실시간 마이그레이션 완료](/ko/enterprise-server@3.22/migrations/elm/complete-your-migration)을(를) 참조하세요.