Skip to main content

이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-07-09. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

GitHub Enterprise Server에서 GitHub Enterprise Cloud로 리포지토리 마이그레이션

GitHub CLI 또는 API를 사용하여 GitHub Enterprise Server에서 GitHub Enterprise Cloud(으)로 리포지토리를 마이그레이션할 수 있습니다.

Tool navigation

GitHub Enterprise Importer을(를) 사용하는 리포지토리 마이그레이션 정보

GitHub CLI 또는 API를 사용하여 마이그레이션을 실행할 수 있습니다.

GitHub CLI은(는) 마이그레이션 프로세스를 간소화하며 대부분의 고객에게 권장됩니다. 사용자 지정 요구 사항이 많은 고급 고객은 API를 사용하여 GitHub Enterprise Importer와 자체 통합을 빌드할 수 있습니다.

API를 사용하도록 선택하는 경우 사용자 고유의 스크립트를 작성하거나 불면증과 같은 HTTP 클라이언트를 사용해야 합니다. "REST API 시작" 및 "GraphQL을 사용하여 통화 구성"에서 GitHub의 API를 시작하는 방법에 대해 자세히 알아볼 수 있습니다.

API를 사용하여 GitHub Enterprise Server에서 GitHub Enterprise Cloud(으)로 리포지토리를 마이그레이션하려면 다음과 같이 하세요.

  1. 원본 및 대상 조직 모두에 대한 personal access token 만들기
  2. GitHub Enterprise Cloud 관련 대상 조직의 ownerId 가져오기
  3. GitHub.com의 GraphQL API를 통해 마이그레이션 원본을 설정하여 마이그레이션이 어디에서 왔는지 식별합니다
  4. 마이그레이션하려는 각 리포지토리에 대해 다음 단계를 반복합니다.
    • GitHub Enterprise Server 인스턴스의 REST API를 사용하여 리포지토리에 대한 마이그레이션 보관 파일을 생성합니다
    • GitHub.com을(를) 통해 액세스할 수 있는 위치에 마이그레이션 보관 파일을 업로드합니다
    • GitHub.com에 대한 GraphQL API를 사용하여 마이그레이션을 시작하고 보관 URL을 전달합니다
    • GraphQL API를 통해 마이그레이션 상태 확인
    • 마이그레이션 유효성 검사 및 오류 로그 검사

API 사용에 대한 지침을 보려면, 페이지 맨 위에 있는 도구 전환기를 사용합니다.

GitHub CLI을(를) 사용하는 방법에 대한 지침을 보려면 페이지 맨 위에 있는 도구 전환기를 사용합니다.

필수 조건

  • 마이그레이션의 평가판을 수행하고 곧바로 프로덕션 마이그레이션을 완료하는 것이 좋습니다. 평가판 실행에 대한 자세한 내용은 "GitHub 제품 간 마이그레이션의 개요"을(를) 참조하세요.
  • 마이그레이션될 데이터와 가져오기 도구의 알려진 지원 제한 사항을 이해했는지 확인하세요. 자세한 내용은 "GitHub 제품 간 마이그레이션 정보"을(를) 참조하세요.
  • 필수는 아니지만 프로덕션 마이그레이션 중에는 작업을 중지하는 것이 좋습니다. Importer은(는) 델타 마이그레이션을 지원하지 않으므로 마이그레이션 중에 발생하는 변경 내용은 마이그레이션되지 않습니다. 프로덕션 마이그레이션 중에 작업을 중단하지 않도록 선택하는 경우, 이러한 변경 내용을 수동으로 마이그레이션해야 합니다.
  • 원본 및 대상 조직 모두에 대해 귀하가 조직 소유자이거나 마이그레이션 역할을 부여받아야 합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.
  • GitHub Enterprise Server 3.8 이상을 사용하는 경우 내보낸 아카이브에 대한 Blob Storage를 구성하려면 관리 콘솔에 액세스할 수 있어야 합니다.

1단계. personal access token 만들기

  1. GitHub Enterprise Cloud에서 대상 조직에 대해 인증할 personal access token을(를) 만들고 기록하여 토큰이 모든 요구 사항을 충족하는지 확인합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.
  2. 원본 조직에 대해 인증할 personal access token을(를) 만들고 기록하여 이 토큰이 동일한 요구 사항을 모두 충족하는지 확인합니다.

2단계: 대상 조직에 대한 ownerId 가져오기

GitHub Enterprise Cloud의 조직 소유자는 마이그레이션된 리포지토리를 소유하려는 조직의 조직 ID라고도 하는 GetOrgInfo 쿼리를 ownerId에 반환합니다. 마이그레이션 대상을 식별하려면 ownerId이(가) 필요합니다.

GetOrgInfo 쿼리

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
쿼리 변수설명
login조직 이름

GetOrgInfo 응답

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

이 예제에서는 MDEyOk9yZ2FuaXphdGlvbjU2MTA=이(가) 다음 단계에서 사용할 조직 ID 또는 ownerId입니다.

3단계: Blob Storage 설정

GitHub Enterprise Server 3.8 버전 이상에 대한 많은 GitHub Enterprise Server 인스턴스가 방화벽 뒤에 있기 때문에 Blob Storage를 중간 위치로 사용하여 GitHub에서 액세스할 수 있는 데이터를 저장합니다.

먼저 지원되는 클라우드 공급자를 사용하여 Blob Storage를 설정한 다음 GitHub Enterprise Server 인스턴스의 관리 콘솔에서 설정을 구성해야 합니다.

참고: GitHub Enterprise Server 3.8버전 이상을 사용하는 경우, Blob Storage를 구성해야만 합니다. GitHub Enterprise Server 버전 3.7 이하를 사용하는 경우 "4단계: GitHub Enterprise Cloud에서 마이그레이션 원본 설정"으로 건너뜁니다.

Blob Storage는 큰 Git 원본 또는 메타데이터를 사용하여 리포지토리를 마이그레이션하는 데 필요합니다. GitHub Enterprise Server 3.7버전 이하를 사용하는 경우, Git 원본 또는 메타데이터 내보내기가 2GB를 초과하는 마이그레이션을 수행할 수 없습니다. 이러한 마이그레이션을 수행하려면 GitHub Enterprise Server 3.8버전 이상으로 업데이트합니다.

지원되는 클라우드 공급자를 사용한 Blob Storage 설정

GitHub CLI은(는) 다음 Blob Storage 공급자를 지원합니다.

  • Amazon Web Services (AWS) S3
  • Azure Blob Storage

AWS S3 스토리지 버킷 설정

AWS에서 S3 버킷을 설정합니다. 자세한 내용은 AWS 설명서의 버킷 만들기를 참조하세요.

또한 다음 권한이 있는 AWS 액세스 키 및 비밀 키가 필요합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

참고: GitHub Enterprise Importer은(는) 마이그레이션이 완료된 후 AWS에서 보관 파일을 삭제하지 않습니다. 스토리지 비용을 줄이려면 일정 기간 후의 보관 파일의 자동 삭제를 구성하는 것이 좋습니다. 자세한 내용은 AWS 설명서의 버킷에 대한 수명 주기 구성 설정을 참조하세요.

Azure Blob Storage 계정

Azure에서 스토리지 계정을 만들고 연결 문자열을 기록해 둡니다. 자세한 내용은 Microsoft Docs의 스토리지 계정 액세스 키 관리를 참조하세요.

참고: GitHub Enterprise Importer은(는) 마이그레이션이 완료된 후 Azure Blob Storage에서 보관 파일을 삭제하지 않습니다. 스토리지 비용을 줄이려면 일정 기간 후의 보관 파일의 자동 삭제를 구성하는 것이 좋습니다. 자세한 내용은 Microsoft Docs의 데이터 수명 주기를 자동으로 관리하여 비용 최적화를 참조하세요.

GitHub Enterprise Server 인스턴스의 관리 콘솔에서 Blob Storage 구성

AWS S3 스토리지 버킷 또는 Azure Blob Storage 스토리지 계정을 설정한 후 관리 콘솔의 GitHub Enterprise Server 인스턴스에서 Blob Storage를 구성합니다. 관리 콘솔에 대한 자세한 내용은 "관리 콘솔에서 인스턴스 등록"을 참조하세요.

  1. 페이지의 오른쪽 상단에 있는 GitHub Enterprise Server의 관리 계정에서 을 클릭합니다.

  2. "사이트 관리자" 페이지에 아직 없는 경우 왼쪽 위 모서리에서 사이트 관리자를 클릭합니다. 1. " 사이트 관리자" 사이드바에서 관리 콘솔 을 클릭합니다.

  3. 관리 콘솔 로그

  4. 위쪽 탐색 모음에서 설정을 클릭합니다.

  5. 마이그레이션에서 {% data variables.product.company_short %} 마이그레이션 사용을 클릭합니다.

  6. 필요에 따라 GitHub Actions에 대해 구성한 스토리지 설정을 가져오려면 작업에서 스토리지 설정 복사를 선택합니다. 자세한 내용은 "Azure Blob Storage에서 GitHub Actions 사용" 및 "Amazon S3 스토리지에서 GitHub Actions 사용"을 참조하세요.

    참고: 스토리지 설정을 복사한 후에도 GitHub Enterprise Importer에서 작동하도록 클라우드 스토리지 계정의 구성을 업데이트해야 할 수 있습니다. 특히 GitHub의 IP 주소가 허용 목록에 있는지 확인해야 합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.

  7. GitHub Actions에서 스토리지 설정을 가져오지 않는 경우 Azure Blob Storage 또는 Amazon S3 중 하나를 선택하고 필요한 세부 정보를 입력합니다.

    참고: Amazon S3를 사용하는 경우, 버킷이 있는 AWS 지역의 표준 엔드포인트로 "AWS 서비스 URL"을 설정해야 합니다. 예를 들어 버킷이 eu-west-1 지역에 있는 경우, "AWS 서비스 URL"이 https://s3.eu-west-1.amazonaws.com이(가) 됩니다. GitHub Enterprise Server 인스턴스의 네트워크에서 이 호스트에 대한 액세스를 허용해야 합니다. 게이트웨이 엔드포인트는 지원되지 않습니다(예: bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com). 게이트웨이 엔드포인트에 대한 자세한 내용은 AWS 설명서에서 Amazon S3용 게이트웨이 엔드포인트를 참조하세요.

  8. 스토리지 설정 테스트를 클릭합니다.

  9. 설정 저장을 클릭합니다.

4단계: GitHub Enterprise Cloud에서 마이그레이션 원본 설정

createMigrationSource 쿼리를 사용하여 마이그레이션 원본을 설정할 수 있습니다. GetOrgInfo 쿼리에서 수집된 조직 ID 또는 조직 ID를 ownerId에 제공해야 합니다.

마이그레이션 원본은 GitHub Enterprise Server의 조직입니다.

createMigrationSource 변형

mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

참고: typeGITHUB_ARCHIVE을(를) 사용해야 합니다.

쿼리 변수설명
name마이그레이션 원본의 이름입니다. 이 이름은 사용자 고유의 참조용이므로, 모든 문자열을 사용할 수 있습니다.
ownerIdGitHub Enterprise Cloud에 있는 조직의 조직 ID입니다.
urlGitHub Enterprise Server 인스턴스의 URL입니다. 이 URL은 GitHub Enterprise Cloud에서 액세스하지 않아도 됩니다.

createMigrationSource 응답

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
        "name": "GHES Source",
        "url": "https://my-ghes-hostname.com",
        "type": "GITHUB_ARCHIVE"
      }
    }
  }
}

이 예제에서 MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ은(는) 이후 단계에서 사용할 마이그레이션 원본 ID입니다.

5단계: GitHub Enterprise Server 인스턴스에서 마이그레이션 보관 파일 생성

REST API를 사용하여 GitHub Enterprise Server에서 두 가지 "마이그레이션"을 시작합니다. 하나는 리포지토리의 Git 원본 보관 파일을 생성하고, 다른 하나는 리포지토리의 메타데이터 보관 파일(예: 문제 및 끌어오기 요청)을 생성합니다.

Git 원본 보관 파일을 생성하려면 https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrationsPOST을(를) 요청하고, HOSTNAME을(를) GitHub Enterprise Server 인스턴스의 호스트 이름 및 조직 로그인이 포함된 ORGANIZATION으(로) 바꿉니다.

본문에서 마이그레이션할 단일 리포지토리를 지정합니다. 요청은 다음과 같이 표시됩니다.

POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net

{
  "repositories": ["repository_to_migrate"],
  "exclude_metadata": true
}

메타데이터 보관 파일을 생성하려면 다음 본문을 사용하여 동일한 URL에 유사한 요청을 보냅니다.

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

이러한 두 API 호출은 각각 시작한 마이그레이션의 ID를 포함하여 JSON 응답을 반환합니다.

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

자세한 내용은 "조직 마이그레이션 시작"을 참조하세요.

데이터 양에 따라 보관 파일을 생성하는 데 시간이 걸릴 수 있습니다. 마이그레이션의 state이(가) exported(으)로 변경될 때까지 "조직 마이그레이션 상태 가져오기" API를 사용하여 두 마이그레이션의 상태를 정기적으로 검사할 수 있습니다.

GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "state": "exported",
  // ...
}

자세한 내용은 "조직 마이그레이션 상태 가져오기"를 참조하세요.

참고: 마이그레이션이 exported 상태가 아닌 failed 상태로 이동하는 경우 마이그레이션을 다시 시작합니다. 마이그레이션이 반복적으로 실패하는 경우 API 대신 ghe-migrator을(를) 사용하여 보관 파일을 생성하는 것이 좋습니다.

"엔터프라이즈에서 마이그레이션 데이터 내보내기"의 단계를 수행하여 마이그레이션에 리포지토리를 하나만 추가합니다. 프로세스가 끝나면 Git 원본 및 메타데이터가 포함된 단일 마이그레이션이 있으며 이 문서의 6단계로 이동할 수 있습니다.

마이그레이션의 state이(가) exported(으)로 이동한 후 "조직 마이그레이션 보관 다운로드" API를 사용하여 마이그레이션의 URL을 가져올 수 있습니다.

GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 302 Found
Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6

API는 다운로드 가능한 보관 파일이 있는 URL로 리디렉션되는 Location 헤더와 함께 302 Found 응답을 반환합니다. Git 원본용 파일과 메타데이터용 파일의 두 파일을 다운로드합니다.

자세한 내용은 "조직 마이그레이션 보관 파일 다운로드"를 참조하세요.

두 마이그레이션이 모두 완료되고 보관 파일을 다운로드한 후에는 다음 단계로 이동할 수 있습니다.

6단계: 마이그레이션 보관 파일 업로드

데이터를 GitHub Enterprise Cloud(으)로 가져오려면 GraphQL API를 사용하여 컴퓨터의 각 리포지토리(Git 원본 및 메타데이터)에 대한 보관 파일을 GitHub.com(으)로 전달해야 합니다.

GitHub Enterprise Server 3.7 이하를 사용하는 경우 먼저 GitHub.com에 따라 액세스할 수 있는 보관 파일에 대한 URL을 생성해야 합니다. 대부분의 고객은 Amazon S3 또는 Azure Blob Storage와 같은 클라우드 공급자의 Blob Storage 서비스에 보관 파일을 업로드한 다음 각각에 대해 단기 URL을 생성하도록 선택합니다.

GitHub Enterprise Server 3.8 이상을 사용하는 경우 인스턴스는 보관 파일을 업로드하고 URL을 생성합니다. 이전 단계의 Location 헤더는 단기 URL을 반환합니다.

GitHub의 IP 범위가 허용 목록에 필요할 수 있습니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.

7단계: 리포지토리 마이그레이션 시작

마이그레이션을 시작하면 단일 리포지토리와 함께 제공되는 데이터가 사용자가 식별하는 새로운 GitHub 리포지토리로 마이그레이션됩니다.

동일한 원본 조직에서 한 번에 여러 리포지토리를 이동하려는 경우 여러 마이그레이션을 큐에 대기시킬 수 있습니다. 최대 5개까지의 리포지토리 마이그레이션을 동시에 실행할 수 있습니다.

startRepositoryMigration 변형

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $gitArchiveUrl: String!,
  $metadataArchiveUrl: String!,
  $sourceRepositoryUrl: URI!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    gitArchiveUrl: $gitArchiveUrl,
    metadataArchiveUrl: $metadataArchiveUrl,
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
쿼리 변수설명
sourceId마이그레이션 원본 id이(가) createMigrationSource 변경에서 반환되었습니다.
ownerIdGitHub Enterprise Cloud에 있는 조직의 조직 ID입니다.
repositoryNameGitHub Enterprise Cloud에서 조직이 소유한 리포지토리 내의 현재 사용되지 않는 사용자 지정 고유 리포지토리 이름입니다. 마이그레이션이 완료되었거나 중지되었을 경우, 오류 로깅 문제가 이 리포지토리에 생성됩니다.
continueOnError마이그레이션이 실패하지 않는 오류가 발생할 경우, 마이그레이션을 계속할 수 있도록 하는 마이그레이션 설정입니다. true 또는 false이어야 합니다. Importer에서 Git 원본을 이동할 수 없거나 Importer이(가) 연결을 끊고 마이그레이션을 완료하기 위해 다시 연결할 수 없는 한 마이그레이션이 계속되도록 continueOnError을(를) true(으)로 설정하는 것이 좋습니다.
githubPatpersonal access token의 대상 조직에 대한 GitHub Enterprise Cloud입니다.
accessToken원본에 대한 personal access token입니다.
targetRepoVisibility새로운 리포지토리의 표시 여부 변경 private, public 또는 internal여야 합니다. 설정하지 않은 경우, 리포지토리가 프라이빗으로 마이그레이션됩니다.
gitArchiveUrlGit 원본 보관 파일에 대한 GitHub Enterprise Cloud에 액세스할 수 있는 URL입니다.
metadataArchiveUrl메타데이터 보관 파일에 대한 GitHub Enterprise Cloud에 액세스할 수 있는 URL입니다.
sourceRepositoryUrlGitHub Enterprise Server 인스턴스의 리포지토리 URL입니다. 필수이지만 GitHub Enterprise Cloud은(는) GitHub Enterprise Server 인스턴스와 직접 통신하지 않습니다.

personal access token 요구 사항은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을 참조하세요.

다음 단계에서는 startRepositoryMigration 변형에서 반환된 마이그레이션 ID를 사용하여 마이그레이션 상태를 검사합니다.

8단계: 마이그레이션 상태 확인

마이그레이션 오류를 감지하고 마이그레이션이 작동하는지 확인하려면 getMigration 쿼리를 사용하여 마이그레이션 상태를 검사할 수 있습니다. getMigrations(으)로 여러 마이그레이션의 상태를 검사할 수도 있습니다.

getMigration 쿼리는 상태를 반환하여 마이그레이션이 queued, in progress, failed 또는 completed일지 알려줍니다. 마이그레이션에 실패한 경우 Importer은(는) 실패의 원인을 제공합니다.

getMigration 쿼리

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
쿼리 변수설명
idstartRepositoryMigration변형이 반환된 id 마이그레이션입니다.

9단계: 마이그레이션 유효성 검사 및 오류 로그 검사

마이그레이션이 완료되면, 마이그레이션 로그 리포지토리를 검사하는 것이 좋습니다. 이 문제는 대상 리포지토리의 GitHub에서 생성됩니다.

"마이그레이션 로그"라는 제목의 문제 스크린샷. 문제의 두 번째 주석에 마이그레이션에 대한 로그가 포함됩니다.

마지막으로, 마이그레이션된 리포지토리에서 건전성 검사를 검토하는 것이 좋습니다.

1단계: GEI extension of the GitHub CLI 설치

첫 번째 마이그레이션인 경우 GEI extension of the GitHub CLI을(를) 설치해야 합니다. GitHub CLI에 대한 자세한 내용은 "GitHub CLI 정보"을 참조하세요.

또는 github/gh-gei 리포지토리의 릴리스 페이지에서 독립 실행형 이진 파일을 다운로드할 수 있습니다. gh 접두사 없이 이진 파일을 직접 실행할 수 있습니다.

  1. GitHub CLI을(를) 설치하세요. GitHub CLI에 대한 설치 지침은 GitHub CLI 리포지토리를 참조하세요.

    참고: GitHub CLI 버전 2.4.0 이상이 필요합니다. gh --version 명령을 사용하여 설치한 버전을 검사할 수 있습니다.

  2. GEI extension을(를) 설치합니다.

    Shell
    gh extension install github/gh-gei
    

GEI extension에 대한 도움이 필요할 때마다 명령과 함께 --help 플래그를 사용할 수 있습니다. 예를 들어, gh gei --help은(는) 사용 가능한 모든 명령을 나열하고 gh gei migrate-repo --help은(는) migrate-repo 명령에 사용할 수 있는 모든 옵션을 나열합니다.

2단계: GEI extension of the GitHub CLI 업데이트

GEI extension은(는) 매주 업데이트됩니다. 최신 버전의 확장을 사용하고 있는지 확인합니다.

gh extension upgrade github/gh-gei

3단계: 환경 변수 설정

GEI extension을(를) 사용하여 GitHub Enterprise Cloud으로 마이그레이션하려면 먼저 원본 및 대상 조직에 액세스할 수 있는 personal access token을(를) 만든 다음, personal access token을(를) 환경 변수로 설정해야 합니다.

  1. GitHub Enterprise Cloud에서 대상 조직에 대해 인증할 personal access token을(를) 만들고 기록하여 토큰이 모든 요구 사항을 충족하는지 확인합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.

  2. 원본 조직에 대해 인증할 personal access token을(를) 만들고 기록하여 이 토큰이 동일한 요구 사항을 모두 충족하는지 확인합니다.

  3. personal access token에 대한 환경 변수를 설정하고, 아래 명령의 토큰을 위에서 기록한 personal access token(으)로 바꿉니다. 대상 조직에 대한 GH_PAT 및 원본 조직에 대한 GH_SOURCE_PAT을(를) 사용합니다.

    • Terminal을 사용하는 경우 export 명령을 사용합니다.

      Shell
      export GH_PAT="TOKEN"
      export GH_SOURCE_PAT="TOKEN"
      
    • PowerShell을 사용하는 경우 $env 명령을 사용합니다.

      Shell
      $env:GH_PAT="TOKEN"
      $env:GH_SOURCE_PAT="TOKEN"
      

4단계: Blob Storage 설정

많은 GitHub Enterprise Server 인스턴스가 방화벽 뒤에 있기 때문에 Blob Storage를 중간 위치로 사용하여 GitHub에서 액세스할 수 있는 데이터를 저장합니다.

먼저 지원되는 클라우드 공급자를 사용하여 Blob Storage를 설정해야 합니다. 그런 다음 관리 콘솔 또는 GitHub CLI에서 스토리지 공급자에 대한 자격 증명을 구성해야 합니다.

지원되는 클라우드 공급자를 사용한 Blob Storage 설정

GitHub CLI은(는) 다음 Blob Storage 공급자를 지원합니다.

  • Amazon Web Services (AWS) S3
  • Azure Blob Storage

AWS S3 스토리지 버킷 설정

AWS에서 S3 버킷을 설정합니다. 자세한 내용은 AWS 설명서의 버킷 만들기를 참조하세요.

또한 다음 권한이 있는 AWS 액세스 키 및 비밀 키가 필요합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

참고: GitHub Enterprise Importer은(는) 마이그레이션이 완료된 후 AWS에서 보관 파일을 삭제하지 않습니다. 스토리지 비용을 줄이려면 일정 기간 후의 보관 파일의 자동 삭제를 구성하는 것이 좋습니다. 자세한 내용은 AWS 설명서의 버킷에 대한 수명 주기 구성 설정을 참조하세요.

Azure Blob Storage 스토리지 계정 설정

Azure에서 스토리지 계정을 만들고 연결 문자열을 기록해 둡니다. 자세한 내용은 Microsoft Docs의 스토리지 계정 액세스 키 관리를 참조하세요.

참고: GitHub Enterprise Importer은(는) 마이그레이션이 완료된 후 Azure Blob Storage에서 보관 파일을 삭제하지 않습니다. 스토리지 비용을 줄이려면 일정 기간 후의 보관 파일의 자동 삭제를 구성하는 것이 좋습니다. 자세한 내용은 Microsoft Docs의 데이터 수명 주기를 자동으로 관리하여 비용 최적화를 참조하세요.

Blob Storage 자격 증명 구성

지원되는 클라우드 공급자를 사용하여 Blob Storage를 설정한 후 GitHub에서 스토리지 공급자에 대한 자격 증명을 구성해야 합니다.

  • GitHub Enterprise Server 3.8 이상을 사용하는 경우 관리 콘솔에서 자격 증명을 구성합니다.
  • 에서 자격 증명을 구성합니다.

GitHub Enterprise Server 인스턴스의 관리 콘솔에서 Blob Storage 구성

참고: GitHub Enterprise Server 3.8 이상을 사용하는 경우 관리 콘솔에서 Blob Storage를 구성하기만 하면 됩니다. 3.7 이하를 사용하는 경우 대신 GitHub CLI에서 자격 증명을 구성합니다.

AWS S3 스토리지 버킷 또는 Azure Blob Storage 스토리지 계정을 설정한 후 관리 콘솔의 GitHub Enterprise Server 인스턴스에서 Blob Storage를 구성합니다. 관리 콘솔에 대한 자세한 내용은 "관리 콘솔에서 인스턴스 등록"을 참조하세요.

  1. 페이지의 오른쪽 상단에 있는 GitHub Enterprise Server의 관리 계정에서 을 클릭합니다.

  2. "사이트 관리자" 페이지에 아직 없는 경우 왼쪽 위 모서리에서 사이트 관리자를 클릭합니다. 1. " 사이트 관리자" 사이드바에서 관리 콘솔 을 클릭합니다.

  3. 관리 콘솔 로그

  4. 위쪽 탐색 모음에서 설정을 클릭합니다.

  5. 마이그레이션에서 {% data variables.product.company_short %} 마이그레이션 사용을 클릭합니다.

  6. 필요에 따라 GitHub Actions에 대해 구성한 스토리지 설정을 가져오려면 작업에서 스토리지 설정 복사를 선택합니다. 자세한 내용은 "Azure Blob Storage에서 GitHub Actions 사용" 및 "Amazon S3 스토리지에서 GitHub Actions 사용"을 참조하세요.

    참고: 스토리지 설정을 복사한 후에도 GitHub Enterprise Importer에서 작동하도록 클라우드 스토리지 계정의 구성을 업데이트해야 할 수 있습니다. 특히 GitHub의 IP 주소가 허용 목록에 있는지 확인해야 합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.

  7. GitHub Actions에서 스토리지 설정을 가져오지 않는 경우 Azure Blob Storage 또는 Amazon S3 중 하나를 선택하고 필요한 세부 정보를 입력합니다.

    참고: Amazon S3를 사용하는 경우, 버킷이 있는 AWS 지역의 표준 엔드포인트로 "AWS 서비스 URL"을 설정해야 합니다. 예를 들어 버킷이 eu-west-1 지역에 있는 경우, "AWS 서비스 URL"이 https://s3.eu-west-1.amazonaws.com이(가) 됩니다. GitHub Enterprise Server 인스턴스의 네트워크에서 이 호스트에 대한 액세스를 허용해야 합니다. 게이트웨이 엔드포인트는 지원되지 않습니다(예: bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com). 게이트웨이 엔드포인트에 대한 자세한 내용은 AWS 설명서에서 Amazon S3용 게이트웨이 엔드포인트를 참조하세요.

  8. 스토리지 설정 테스트를 클릭합니다.

  9. 설정 저장을 클릭합니다.

GitHub CLI에서 미확인 개체 스토리지 자격 증명 구성

참고: GitHub Enterprise Server 3.7 이하를 사용하는 경우 GitHub CLI에서만 Blob Storage 자격 증명을 구성해야 합니다. 3.8 이상을 사용하는 경우 대신 관리 콘솔에서 Blob Storage를 구성합니다.

GitHub CLI에서 Blob Storage 자격 증명을 구성하는 경우 Git 원본 또는 메타데이터 내보내기가 2GB를 초과한다면 마이그레이션을 수행할 수 없습니다. 이러한 마이그레이션을 수행하려면 GitHub Enterprise Server 3.8 이상으로 업그레이드합니다.

GitHub CLI에서 AWS S3 자격 증명 구성

마이그레이션을 실행할 준비가 되면 지역, 액세스 키, 비밀 키 및 세션 토큰(필요한 경우)과 같은 GitHub CLI에 AWS 자격 증명을 제공해야 합니다. 인수로 전달하거나 AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEYAWS_SESSION_TOKEN(으)로 불리는 환경 변수를 설정할 수 있습니다.

또한 --aws-bucket-name 인수를 사용하여 S3 버킷의 이름을 전달해야 합니다.

GitHub CLI에서 Azure Blob Storage 계정 자격 증명 구성

마이그레이션을 실행할 준비가 되면 GitHub CLI에 인수로 연결 문자열을 전달하거나 AZURE_STORAGE_CONNECTION_STRING 환경 변수를 사용하여 전달할 수 있습니다.

5단계: 마이그레이션 스크립트 생성

여러 리포지토리를 한 번에 GitHub Enterprise Cloud으로 마이그레이션하려면 GitHub CLI을(를) 사용하여 마이그레이션 스크립트를 생성합니다. 결과 스크립트에는 리포지토리당 하나씩의 마이그레이션 명령 목록이 포함됩니다.

참고: 스크립트를 생성하면 PowerShell 스크립트가 출력됩니다. 터미널을 사용하는 경우 .ps1 파일 확장과 함께 스크립트를 출력하고 Mac 또는 Linux용 PowerShell을 설치하여 실행해야 합니다.

단일 리포지토리를 마이그레이션하려면 다음 단계로 건너뜁니다.

마이그레이션 스크립트 생성

GitHub Enterprise Server 인스턴스에 대한 API에 액세스할 수 있는 컴퓨터에서 이 단계를 수행해야 합니다. 브라우저에서 인스턴스에 액세스할 수 있는 경우, 컴퓨터에 올바른 액세스 권한이 있습니다.

마이그레이션 스크립트를 생성하려면 gh gei generate-script 명령을 실행합니다.

GitHub Enterprise Server 3.8 이상 또는 Azure Blob Storage를 사용하여 3.7 이하를 사용하는 경우 다음 플래그를 사용합니다.

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL

AWS S3에서 GitHub Enterprise Server 3.7 이하를 사용하는 경우 다음 플래그를 사용합니다.

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL \
  --aws-bucket-name AWS-BUCKET-NAME

GitHub Enterprise Server 인스턴스이(가) 자체 서명되었거나 잘못된 SSL 인증서를 사용하는 경우--no-ssl-verify 플래그를 사용합니다. 이 플래그를 사용하면 GitHub CLI은(는) 인스턴스에서만 데이터를 추출할 때 SSL 인증서 확인을 건너뜁니다. 다른 모든 호출에서는 SSL을 확인합니다.

스크립트가 마이그레이션된 각 리포지토리에 대한 마이그레이션 로그를 다운로드하려면 --download-migration-logs 플래그를 추가합니다. 마이그레이션 로그에 대한 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"를 참조하세요.

명령 내의 자리 표시자를 다음 값으로 바꿉니다.

자리 표시자
SOURCE원본 조직의 이름
대상대상 조직의 이름
FILENAME결과 마이그레이션 스크립트의 파일 이름

터미널을 사용하는 경우 생성된 스크립트에서 PowerShell을 실행해야 하므로 .ps1 파일 확장을 사용합니다. Mac 또는 Linux용 PowerShell을 설치할 수 있습니다.
GHES-API-URLGitHub Enterprise Server 인스턴스' URL의 https://myghes.com/api/v3와(과) 같은 API
AWS-BUCKET-NAMEAWS S3 버킷의 버킷 이름

마이그레이션 스크립트 검토

스크립트를 생성한 후, 파일을 검토하고 필요에 따라 스크립트를 편집합니다.

  • 마이그레이션하지 않으려는 리포지토리가 있는 경우, 해당 줄을 삭제하거나 주석 처리합니다.
  • 리포지토리가 대상 조직에 다른 이름을 갖도록 하려면 해당 --target-repo 플래그 값을 업데이트합니다.

참고: 리포지토리에 10GB 이상의 릴리스 데이터가 있으면 릴리스를 마이그레이션할 수 없습니다. --skip-releases 플래그를 사용하여 릴리스 없이 리포지토리를 마이그레이션합니다.

GEI을(를) GitHub CLI의 확장이 아닌 독립 실행형 이진으로 다운로드한 경우 gh gei 대신 이진 파일을 실행하려면 생성된 스크립트를 업데이트해야 합니다.

6단계: 리포지토리 마이그레이션

gh gei migrate-repo 명령을 사용하여 마이그레이션 스크립트 또는 단일 리포지토리를 사용하여 여러 리포지토리를 마이그레이션할 수 있습니다.

리포지토리를 마이그레이션할 때 GEI extension of the GitHub CLI은(는) 다음 단계를 수행합니다.

  1. GitHub Enterprise Server 인스턴스에 연결하고 리포지토리당 두 개의 마이그레이션 보관 파일(Git 원본용 및 메타데이터용)을 생성합니다
  2. 선택한 Blob 스토리지 공급자에 대한 마이그레이션 보관 파일을 업로드합니다
  3. Blob 스토리지 공급자와 함께 저장된 보관 파일의 URL을 사용하여 GitHub Enterprise Cloud에서 마이그레이션을 시작합니다
  4. 로컬 컴퓨터에서 마이그레이션 보관 파일을 삭제합니다

여러 리포지토리 마이그레이션

GitHub Enterprise Server 3.7 이하에서 마이그레이션하는 경우 스크립트를 실행하기 전에 Blob 스토리지 공급자에게 인증할 추가 환경 변수를 설정해야 합니다.

  • Azure Blob Storage의 경우 AZURE_STORAGE_CONNECTION_STRING을(를) Azure 스토리지 계정에 대한 연결 문자열에 설정합니다.

    스토리지 계정 액세스 키를 사용하는 연결 문자열만이 지원됩니다. SAS(공유 액세스 서명)를 사용하는 연결 문자열은 지원되지 않습니다. 스토리지 계정 액세스 키를 검색하는 방법에 대한 자세한 내용은 Azure 설명서의 스토리지 계정 액세스 키 관리를 참조하세요.

  • AWS S3의 경우, 다음 환경 변수를 설정합니다.

    • AWS_ACCESS_KEY: 버킷에 대한 액세스 키
    • AWS_SECRET_KEY: 버킷의 비밀 키
    • AWS_REGION: 버킷이 있는 AWS 지역
    • AWS_SESSION_TOKEN: AWS 임시 자격 증명을 사용하는 경우 세션 토큰(AWS 설명서에서 AWS 리소스와 함께 임시 자격 증명 사용 참조)

여러 리포지토리를 동시에 마이그레이션하려면 이 위에서 생성한 스크립트를 실행합니다. 아래 명령의 FILENAME을 스크립트를 생성할 때 제공받은 파일 이름으로 바꿉니다.

  • 터미널을 사용하는 경우, ./을(를) 사용하세요.

    Shell
    ./FILENAME
    
  • PowerShell을 사용하는 경우 .\을(를) 사용하세요.

    Shell
    .\FILENAME
    

단일 리포지토리 마이그레이션

GitHub Enterprise Server 인스턴스에 대한 API에 액세스할 수 있는 컴퓨터에서 이 단계를 수행해야 합니다. 브라우저에서 인스턴스에 액세스할 수 있는 경우, 컴퓨터에 올바른 액세스 권한이 있습니다.

단일 리포지토리를 마이그레이션하려면 gh gei migrate-repo 명령을 사용하세요.

GitHub Enterprise Server 3.8 이상을 사용하는 경우 다음 플래그를 사용합니다.

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL

GitHub Enterprise Server 3.7 이하에서 마이그레이션하고 Azure Blob Storage를 Blob 스토리지 공급자로 사용하는 경우 다음 플래그를 사용하여 인증합니다.

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
    --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"

GitHub Enterprise Server 3.7 이하에서 마이그레이션하고 Amazon S3을 Blob 스토리지 공급자로 사용하는 경우 다음 플래그를 사용하여 인증합니다.

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
    --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"

GitHub Enterprise Server 인스턴스이(가) 자체 서명되었거나 잘못된 SSL 인증서를 사용하는 경우--no-ssl-verify 플래그를 사용합니다. 이 플래그를 사용하면 GitHub CLI은(는) 인스턴스에서만 데이터를 추출할 때 SSL 인증서 확인을 건너뜁니다. 다른 모든 호출에서는 SSL을 확인합니다.

참고: 리포지토리에 10GB 이상의 릴리스 데이터가 있으면 릴리스를 마이그레이션할 수 없습니다. --skip-releases 플래그를 사용하여 릴리스 없이 리포지토리를 마이그레이션합니다.

명령 내의 자리 표시자를 다음 값으로 바꿉니다.

자리 표시자
SOURCE원본 조직의 이름
CURRENT-NAME마이그레이션할 리포지토리의 이름
대상대상 조직의 이름
NEW-NAME마이그레이션된 리포지토리에서 사용할 이름
GHES-API-URLGitHub Enterprise Server 인스턴스' URL의 https://myghes.com/api/v3와(과) 같은 API
AZURE_STORAGE_CONNECTION_STRINGAzure 스토리지 계정에 대한 연결 문자열입니다.

셸에서 해석될 가능성이 있는 문자가 포함된 연결 문자열을 인용해야 합니다.
AWS-BUCKET-NAMEAWS S3 버킷의 버킷 이름

마이그레이션을 취소하려면 abort-migration 명령을 사용하여 MIGRATION-ID를 migrate-repo에서 반환된 ID로 바꿔야 합니다.

Shell
gh gei abort-migration --migration-id MIGRATION-ID

7단계: 마이그레이션 유효성 검사 및 오류 로그 검사

마이그레이션이 완료되면, 마이그레이션 로그를 검토하는 것이 좋습니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"을(를) 참조하세요.

마이그레이션된 리포지토리에서 건전성 검사를 검토하는 것이 좋습니다.

마이그레이션이 완료되면 스토리지 컨테이너에서 보관 파일을 삭제하는 것이 좋습니다. 추가 마이그레이션을 완료하려는 경우 ADO2GH extension에 따라 스토리지 컨테이너에 배치된 보관 파일을 삭제합니다. 마이그레이션이 완료되면 전체 컨테이너를 삭제할 수 있습니다.