GitHub Enterprise Importer
を使ったリポジトリの移行について
GitHub CLI または API を使って、移行を実行できます。
GitHub CLI を使うと移行プロセスが簡単になるので、ほとんどのお客様に推奨されます。 カスタマイズのニーズが高い熟練したお客様は、API を使って、GitHub Enterprise Importer との独自の統合を構築できます。
API を使用することを選んだ場合は、独自のスクリプトを記述するか、Insomnia などの HTTP クライアントを使用する必要があります。 GitHub の API の概要については、「REST API を使用した作業の開始」と「GraphQLでの呼び出しの作成」を参照してください。
API を使用してリポジトリを GitHub Enterprise Server から GitHub Enterprise Cloud に移行するには、次のようにします。
- 移行元と移行先の両方の Organization に対して personal access token を作成します
- GitHub Enterprise Cloud で移行先 Organization の
ownerId
をフェッチします - GitHub の GraphQL API を使用して移行元を設定し、どこから移行するかを特定します
- 移行するリポジトリごとに、次の手順を繰り返します。
- お使いの GitHub Enterprise Server インスタンス で、REST API を使用してリポジトリの移行アーカイブを生成します
- GitHub からアクセスできる場所に移行アーカイブをアップロードします
- GitHub の GraphQL API を使用して移行を開始し、アーカイブの URL を渡します
- GraphQL API を使用して移行の状態を確認します
- 移行を検証し、エラー ログを確認します
API の使い方を確認するには、ページの上部にあるツール スイッチャーを使います。
GitHub CLI の使い方を確認するには、ページの上部にあるツール スイッチャーを使います。
前提条件
- 移行の試験的実行を行い、そのすぐ後で運用環境の移行を完了することを強くお勧めします。 試験的実行について詳しくは、「GitHub 製品間の移行に関する概要」をご覧ください。
- 移行されるデータと、Importer の既知のサポート制限事項を理解していることを確認します。 詳しくは、「GitHub 製品間の移行について」をご覧ください。
- 必須ではありませんが、運用環境の移行の間は作業を停止することをお勧めします。 Importer は差分移行をサポートしていないため、移行中に発生した変更は移行されません。 運用環境の移行の間に作業を停止しない場合は、これらの変更を手動で移行する必要があります。
- ユーザーは、移行元 Organization と移行先 Organization の両方で Organization の所有者である、または移行者ロールが付与されている必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
- GitHub Enterprise Server 3.8 以降を使用する場合は、エクスポートしたアーカイブ用の Blob Storage を設定するには、[Management Console] にアクセスできる必要があります。
手順 1. personal access token を作成する
- GitHub Enterprise Cloud 上の移行先 Organization に対して認証を行う personal access token (classic) を作成して記録し、トークンがすべての要件を満たしていることを確認します。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
- 移行元 Organization に対して認証を行う personal access token を作成して記録し、このトークンも同じ要件をすべて満たしていることを確認します。
手順 2: 移行先 Organization の ownerId
を取得する
GitHub Enterprise Cloud の Organization 所有者として、GetOrgInfo
クエリを使って、移行されたリポジトリを所有する Organization の ownerId
(Organization ID とも呼ばれます) を取得します。 移行先を識別するには、ownerId
が必要です。
GetOrgInfo
クエリ
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
クエリ変数 | 説明 |
---|---|
login | Organization の名前。 |
GetOrgInfo
の応答
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
この例では、MDEyOk9yZ2FuaXphdGlvbjU2MTA=
が Organization ID つまり ownerId
であり、次のステップでそれを使います。
手順 3: BLOB ストレージを設定する
多くの GitHub Enterprise Server インスタンスはファイアウォールの内側にあるため、GitHub Enterprise Server バージョン 3.8 以降では、GitHub がアクセスできるデータを格納するための中間的な場所として、BLOB ストレージを使用します。
最初に、サポートされているクラウド プロバイダーで BLOB ストレージを設定してから、お使いの GitHub Enterprise Server インスタンス の [Management Console] で設定を構成する必要があります。
注: BLOB ストレージを構成する必要があるのは、GitHub Enterprise Server バージョン 3.8 以降を使用している場合のみです。 GitHub Enterprise Server バージョン 3.7 以前を使用している場合は、「手順 4: GitHub Enterprise Cloud で移行元を設定する」に進んでください。
大規模な Git ソースまたはメタデータを含むリポジトリを移行するには、BLOB ストレージが必要です。 GitHub Enterprise Server バージョン 3.7 以前を使用している場合、Git ソースまたはメタデータのエクスポートが 2 GB を超える移行を実行することはできません。 これらの移行を実行するには、GitHub Enterprise Server バージョン 3.8 以降に更新してください。
サポートされているクラウド プロバイダーを使用した BLOB ストレージの設定
GitHub CLI は、次の BLOB ストレージ プロバイダーをサポートしています。
- アマゾン ウェブ サービス (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 インスタンス の [Management Console] での BLOB ストレージの構成
AWS S3 ストレージ バケットまたは Azure Blob Storage ストレージ アカウントを設定したら、お使いの GitHub Enterprise Server インスタンス の [Management Console] で BLOB ストレージを構成します。 [Management Console] について詳しくは、「管理コンソールからのインスタンスの管理」をご覧ください。
-
GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にある をクリックします。
-
[サイト管理者] ページが表示されていない場合は、左上隅の [サイト管理者] をクリックします。1. [ サイト管理者] サイドバーで [Management Console] をクリックします。
-
[Management Console] にログインします。
-
上部のナビゲーション バーで [設定] をクリックします。
-
[移行] で、 [GitHub の移行を有効にする] をクリックします。
-
GitHub Actions に構成したストレージの設定をインポートする必要がある場合は、 [Actions からストレージの設定をコピーする] をオンにします。 詳しくは、「Azure Blob ストレージで GitHub Actions を有効化する」と「Amazon S3 ストレージで GitHub Actions を有効化する」をご覧ください。
注: ストレージ設定をコピーした後も、GitHub Enterprise Importer で動作するようにクラウド ストレージ アカウントの構成を更新する必要がある場合があります。 特に、GitHub の IP アドレスを許可リストに載せる必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
-
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 ゲートウェイエンドポイントを参照してください。 -
[ストレージの設定をテストする] をクリックします。
-
Save settings をクリックします。
手順 4: GitHub Enterprise Cloud で移行元を設定する
createMigrationSource
クエリを使って、移行元を設定できます。 GetOrgInfo
クエリで収集した ownerId
つまり Organization ID を指定する必要があります。
移行元は、GitHub Enterprise Server 上の Organization です。
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
}
}
}
注: type
には必ず GITHUB_ARCHIVE
を使ってください。
クエリ変数 | 説明 |
---|---|
name | 移行元の名前。 この名前は自分の参照用であるため、任意の文字列を使用できます。 |
ownerId | GitHub Enterprise Cloud での Organization の Organization ID。 |
url | お使いの GitHub 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 で 2 つの "移行" を開始します。1 つはリポジトリの Git ソースのアーカイブを生成し、もう 1 つはリポジトリのメタデータ (issue や pull request など) のアーカイブを生成します。
Git ソース アーカイブを生成するには、https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations
に対して POST
要求を行います。HOSTNAME
は お使いの GitHub Enterprise Server インスタンス のホスト名に、ORGANIZATION
は Organization のログインに置き換えます。
本文で、移行する 1 つのリポジトリを指定します。 要求はこのようになります。
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
}
これら 2 つの API 呼び出しのそれぞれで、開始した移行の ID を含む JSON 応答が返されます。
HTTP/1.1 201 Created
{
"id": 123,
// ...
}
詳細については、「Organization の移行を開始する」を参照してください。
データの量によっては、アーカイブの生成に時間がかかる場合があります。 "Organization の移行状態を取得する" API を使用して、移行の state
が exported
に変わるまで、2 つの移行の状態を定期的に確認できます。
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",
// ...
}
詳細については、「Organization の移行状態を取得する」を参照してください。
注: 移行が exported
状態ではなく failed
状態になった場合は、もう一度移行を開始してみてください。 移行が繰り返し失敗する場合は、API の代わりに ghe-migrator
を使用してアーカイブを生成することをお勧めします。
「Enterprise から移行データをエクスポートする」の手順に従い、移行にリポジトリを 1 つだけ追加します。 このプロセスを終えると、Git ソースとメタデータを含む 1 つの移行アーカイブができ、この記事の手順 6 に進むことができます。
移行の state
が exported
に推移したら、"Organization 移行アーカイブのダウンロード" 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
応答が返されます。 2 つのファイルをダウンロードします。1 つは Git ソース、もう 1 つはメタデータのファイルです。
詳細については、「Organization の移行アーカイブをダウンロードする」を参照してください。
両方の移行が完了し、アーカイブをダウンロードしたら、次の手順に進むことができます。
手順 6: 移行アーカイブをアップロードする
GitHub Enterprise Cloud にデータをインポートするには、GraphQL API を使用して、自分のマシンから GitHub に各リポジトリの両方のアーカイブ (Git ソースとメタデータ) を渡す必要があります。
GitHub Enterprise Server 3.7 以前を使用している場合は、GitHub からアクセスできるアーカイブの URL を最初に生成する必要があります。 ほとんどのお客様は、Amazon S3 や Azure Blob Storage などのクラウド プロバイダーの BLOB ストレージ サービスにアーカイブをアップロードし、それぞれについて有効期間の短い URL を生成することを選びます。
GitHub Enterprise Server 3.8 以降を使用している場合は、インスタンスからアーカイブがアップロードされ、URL が生成されます。 前の手順の Location
ヘッダーにより、有効期間の短い URL が返されます。
GitHub の IP 範囲を許可リストに加えることが必要になる場合があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
手順 7: リポジトリの移行を開始する
移行を始める、1 つのリポジトリとそれに付随するデータが、ユーザーが指定した新しい GitHub リポジトリに移行されます。
同じ移行元 Organization から複数のリポジトリを一度に移動したい場合は、複数の移行をキューに登録できます。 同時に最大 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 | createMigrationSource ミューテーションから返された移行元の id 。 |
ownerId | GitHub Enterprise Cloud での Organization の Organization ID。 |
repositoryName | GitHub Enterprise Cloud 上で Organization が所有するどのリポジトリでも現在使われていない一意のカスタム リポジトリ名。 移行が完了または停止すると、このリポジトリにエラー ログ issue が作成されます。 |
continueOnError | 移行の失敗を引き起こさないエラーが発生したときに移行を続行できるようにする移行設定。 true または false である必要があります。 Importer が Git ソースを移動できない場合、または Importer が接続を失い、移行を完了するために再接続できない場合を除き、移行が続けられるように、continueOnError を true に設定することを強くお勧めします。 |
githubPat | GitHub Enterprise Cloud 上の移行先 Organization の personal access token。 |
accessToken | 移行元の personal access token。 |
targetRepoVisibility | 新しいリポジトリの可視性。 private 、public 、または internal にする必要があります。 設定されていない場合、リポジトリはプライベートとして移行されます。 |
gitArchiveUrl | GitHub Enterprise Cloud でアクセス可能な Git ソース アーカイブの URL。 |
metadataArchiveUrl | GitHub Enterprise Cloud でアクセス可能なメタデータ アーカイブの URL。 |
sourceRepositoryUrl | GitHub 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
}
}
}
クエリ変数 | 説明 |
---|---|
id | startRepositoryMigration ミューテーションが返した移行の id 。 |
手順 9: 移行を検証し、エラー ログを確認する
移行を完了するには、"移行ログ" の issue を確認することをお勧めします。 この issue は、移行先リポジトリの GitHub に作成されます。
最後に、移行したリポジトリで健全性チェックを確認することをお勧めします。
手順 1: GEI extension of the GitHub CLI をインストールする
これが初めての移行の場合は、GEI extension of the GitHub CLI をインストールする必要があります。 GitHub CLI について詳しくは、「GitHub CLI について」をご覧ください。
または、github/gh-gei
リポジトリの「リリース ページ」からスタンドアロン バイナリをダウンロードすることもできます。 gh
プレフィックスなしでバイナリを直接実行できます。
-
GitHub CLI をインストールします。 GitHub CLI のインストール手順については、GitHub CLI リポジトリを参照してください。
注: GitHub CLI のバージョン 2.4.0 以降が必要です。
gh --version
コマンドを使って、インストールされているバージョンを確認できます。 -
GEI extension をインストールします。
Shell gh extension install github/gh-gei
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 に移行するには、その前に、移行元と移行先の Organization にアクセスできる personal access token を作成してから、personal access token を環境変数として設定する必要があります。
-
GitHub Enterprise Cloud 上の移行先 Organization に対して認証を行う personal access token (classic) を作成して記録し、トークンがすべての要件を満たしていることを確認します。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
-
移行元 Organization に対して認証を行う personal access token を作成して記録し、このトークンも同じ要件をすべて満たしていることを確認します。
-
personal access token に対する環境変数を設定します。次のコマンドの TOKEN は、上で記録した personal access token に置き換えます。 移行先の Organization には
GH_PAT
を使い、移行元の Organization にはGH_SOURCE_PAT
を使います。-
ターミナルを使っている場合は、
export
コマンドを使います。Shell export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
-
PowerShell を使っている場合は、
$env
コマンドを使います。Shell $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
-
手順 4: BLOB ストレージを設定する
多くの GitHub Enterprise Server インスタンスはファイアウォールの内側にあるため、GitHub がアクセスできるデータを格納するための中間的なの場所として、BLOB ストレージを使用します。
まず、サポートされているクラウド プロバイダーを使用して BLOB ストレージを設定する必要があります。 次に、[Management Console] または GitHub CLI でストレージ プロバイダーの資格情報を構成する必要があります。
サポートされているクラウド プロバイダーを使用した BLOB ストレージの設定
GitHub CLI は、次の BLOB ストレージ プロバイダーをサポートしています。
- アマゾン ウェブ サービス (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 ストレージ資格情報の構成
サポートされているクラウド プロバイダーを使用して BLOB ストレージを設定した後、GitHub でストレージ プロバイダーの資格情報を構成する必要があります。
- GitHub Enterprise Server 3.8 以降を使用している場合は、[Management Console] で資格情報を構成します。
- GitHub Enterprise Server 3.7 以前を使用している場合は、GitHub CLI で資格情報を構成します。
お使いの GitHub Enterprise Server インスタンス の [Management Console] での BLOB ストレージの構成
注: GitHub Enterprise Server 3.8 以降を使用している場合にのみ、[Management Console] で BLOB ストレージを構成する必要があります。 3.7 以前を使用している場合は、代わりに GitHub CLI で資格情報を構成します。
AWS S3 ストレージ バケットまたは Azure Blob Storage ストレージ アカウントを設定したら、お使いの GitHub Enterprise Server インスタンス の [Management Console] で BLOB ストレージを構成します。 [Management Console] について詳しくは、「管理コンソールからのインスタンスの管理」をご覧ください。
-
GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にある をクリックします。
-
[サイト管理者] ページが表示されていない場合は、左上隅の [サイト管理者] をクリックします。1. [ サイト管理者] サイドバーで [Management Console] をクリックします。
-
[Management Console] にログインします。
-
上部のナビゲーション バーで [設定] をクリックします。
-
[移行] で、 [GitHub の移行を有効にする] をクリックします。
-
GitHub Actions に構成したストレージの設定をインポートする必要がある場合は、 [Actions からストレージの設定をコピーする] をオンにします。 詳しくは、「Azure Blob ストレージで GitHub Actions を有効化する」と「Amazon S3 ストレージで GitHub Actions を有効化する」をご覧ください。
注: ストレージ設定をコピーした後も、GitHub Enterprise Importer で動作するようにクラウド ストレージ アカウントの構成を更新する必要がある場合があります。 特に、GitHub の IP アドレスを許可リストに載せる必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
-
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 ゲートウェイエンドポイントを参照してください。 -
[ストレージの設定をテストする] をクリックします。
-
Save settings をクリックします。
GitHub CLI での BLOB ストレージ資格情報の構成
注: GitHub Enterprise Server 3.7 以前を使用している場合にのみ、GitHub CLI で BLOB ストレージの資格情報を構成する必要があります。 3.8 以降を使用している場合は、代わりに [Management Console] で BLOB ストレージを構成します。
GitHub CLI で BLOB ストレージの資格情報を構成した場合、Git ソースまたはメタデータのエクスポートが 2 GB を超える移行を実行することはできません。 これらの移行を実行するには、GitHub Enterprise Server 3.8 以降にアップグレードしてください。
GitHub CLI での AWS S3 資格情報の構成
移行を実行する準備ができたら、リージョン、アクセス キー、シークレット キー、セッション トークンなどの AWS 資格情報を GitHub CLI に提供します (必要な場合)。 引数として渡すことも、AWS_REGION
、AWS_ACCESS_KEY_ID
、AWS_SECRET_ACCESS_KEY
、AWS_SESSION_TOKEN
という環境変数を設定することもできます。
また、--aws-bucket-name
引数を使って S3 バケットの名前で渡す必要があります。
GitHub CLI での Azure Blob Storage アカウント資格情報の構成
移行を実行する準備ができたら、接続文字列を引数として GitHub CLI に渡すか、AZURE_STORAGE_CONNECTION_STRING
という名前の環境変数を使って渡すことができます。
手順 5: 移行スクリプトを生成する
複数のリポジトリを GitHub Enterprise Cloud に一度に移行したい場合は、GitHub CLI を使って移行スクリプトを生成します。 結果のスクリプトには、リポジトリごとに 1 つの移行コマンドのリストが含まれます。
注: スクリプトを生成すると、PowerShell スクリプトが出力されます。 ターミナルを使っている場合は、.ps1
ファイル拡張子を持つスクリプトを出力し、Mac または Linux 用の PowerShell をインストールして実行する必要があります。
1 つのリポジトリを移行する場合は、次のステップに進んでください。
移行スクリプトの生成
お使いの GitHub Enterprise Server インスタンス 用の API にアクセスできるコンピューターから、このステップを行う必要があります。 ブラウザーからインスタンスにアクセスできる場合、そのコンピューターには正しいアクセス権があります。
移行スクリプトを生成するには、gh gei generate-script
コマンドを実行します。
GitHub Enterprise Server 3.8 以降の場合、または Azure Blob Storage で 3.7 以前を使っている場合は、次のフラグを使ってください。
gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL
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 以前を使っている場合は、次のフラグを使ってください。
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
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 | 移行元の Organization の名前 |
DESTINATION | 移行先の Organization の名前 |
FILENAME | 結果の移行スクリプトのファイル名 ターミナルを使っている場合は、生成されたスクリプトの実行に PowerShell が必要なので、 .ps1 ファイル拡張子を使います。 Mac 用または Linux 用の PowerShell をインストールできます。 |
GHES-API-URL | お使いの GitHub Enterprise Server インスタンス の API の URL (例: https://myghes.com/api/v3 ) |
AWS-BUCKET-NAME | AWS S3 バケットのバケット名 |
移行スクリプトの確認
スクリプトを生成したら、ファイルを確認し、必要に応じてスクリプトを編集します。
- 移行したくないリポジトリがある場合は、対応する行を削除するかコメントにします。
- 移行先の Organization でリポジトリに別の名前を使う場合は、対応する
--target-repo
フラグの値を更新します。 - 新しいリポジトリの表示範囲を変更する場合は、対応する
--target-repo-visibility
フラグの値を更新します。 既定では、スクリプトはソース リポジトリと同じ表示範囲を設定します。
注: リポジトリに 10 GB を超えるリリース データがある場合、リリースを移行することはできません。 リリースなしでリポジトリを移行するには、--skip-releases
フラグを使います。
GEI の拡張機能としてではなく、スタンドアロン バイナリとして GitHub CLI をダウンロードした場合は、生成されたスクリプトを更新して gh gei
ではなくバイナリを実行する必要があります。
手順 6: リポジトリを移行する
移行スクリプトを使って複数のリポジトリを移行すること、または gh gei migrate-repo
コマンドを使って 1 つのリポジトリを移行することができます。
リポジトリを移行するとき、GEI extension of the GitHub CLI で次の手順が実行されます。
- お使いの GitHub Enterprise Server インスタンス に接続し、リポジトリごとに 2 つの移行アーカイブを生成します。1 つは Git ソース、もう 1 つはメタデータのファイルです
- 移行アーカイブを任意の BLOB ストレージ プロバイダーにアップロードします
- BLOB ストレージ プロバイダーに格納されているアーカイブの URL を使用して、GitHub Enterprise Cloud で移行を開始します
- ローカル コンピューターから移行アーカイブを削除します
複数のリポジトリを移行する
スクリプトを実行するために GitHub Enterprise Server 3.7 以前から移行する場合、環境変数を追加で設定して BLOB ストレージ プロバイダーに対して認証を行う必要があります。
-
Azure Blob Storage の場合は、
AZURE_STORAGE_CONNECTION_STRING
を Azure ストレージ アカウントの接続文字列に設定します。ストレージ アカウントのアクセス キーを使う接続文字列のみがサポートされています。 Shared Access Signature (SAS) を使う接続文字列はサポートされていません。 ストレージ アカウントのアクセス キーについて詳しくは、Azure のドキュメントの「ストレージ アカウント アクセス キーを管理する」をご覧ください。
-
AWS S3 の場合は、次の環境変数を設定します。
AWS_ACCESS_KEY_ID
: バケットのアクセス キー IDAWS_SECRET_ACCESS_KEY
: バケットの秘密鍵AWS_REGION
: バケットが配置されている AWS リージョンAWS_SESSION_TOKEN
: AWS の一時的な資格情報を使用している場合のセッション トークン (AWS ドキュメントの「AWS リソースで一時的な資格情報を使用する」を参照してください)
複数のリポジトリを移行するには、上で生成したスクリプトを実行します。 次のコマンドの FILENAME を、スクリプトの生成時に指定したファイル名に置き換えます。
-
ターミナルを使っている場合は、
./
を使います。Shell ./FILENAME
./FILENAME
-
PowerShell を使っている場合は、
.\
を使います。Shell .\FILENAME
.\FILENAME
1 つのリポジトリを移行する
お使いの GitHub Enterprise Server インスタンス 用の API にアクセスできるコンピューターから、このステップを行う必要があります。 ブラウザーからインスタンスにアクセスできる場合、そのコンピューターには正しいアクセス権があります。
1 つのリポジトリを移行するには、gh gei migrate-repo
コマンドを使います。
GitHub Enterprise Server 3.8 以降を使っている場合は、次のフラグを使ってください。
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
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 以前から移行していて、BLOB ストレージ プロバイダーとして Azure Blob Storage を使っている場合は、次のフラグを使って認証してください。
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"
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 以前から移行していて、BLOB ストレージ プロバイダーとして Amazon S3 を使っている場合は、次のフラグを使って認証してください。
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"
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 が検証されます。
注: リポジトリに 10 GB を超えるリリース データがある場合、リリースを移行することはできません。 リリースなしでリポジトリを移行するには、--skip-releases
フラグを使います。
リポジトリは、既定では表示範囲が非公開で移行されます。 表示範囲を設定するには、--target-repo-visibility
フラグを追加し、private
、public
、または internal
を指定します。 マネージド ユーザーを含む Enterprise に移行する場合、パブリック リポジトリは使用できません。
上のコマンドのプレースホルダーを次の値に置き換えます。
プレースホルダー | 値 |
---|---|
SOURCE | 移行元の Organization の名前 |
CURRENT-NAME | 移行するリポジトリの名前 |
DESTINATION | 移行先の Organization の名前 |
NEW-NAME | 移行されたリポジトリに設定する名前 |
GHES-API-URL | お使いの GitHub Enterprise Server インスタンス の API の URL (例: https://myghes.com/api/v3 ) |
AZURE_STORAGE_CONNECTION_STRING | Azure ストレージ アカウントの接続文字列。 接続文字列は必ず引用符で囲みます。それには、シェルで誤って解釈される可能性がある文字が含まれます。 |
AWS-BUCKET-NAME | AWS S3 バケットのバケット名 |
移行を取り消す場合は、MIGRATION-ID を abort-migration
返された( migrate-repo
から)ID に置き換えて、コマンドを使用します。
gh gei abort-migration --migration-id MIGRATION-ID
gh gei abort-migration --migration-id MIGRATION-ID
手順 7: 移行を検証し、エラー ログを確認する
移行が完了したら、移行ログを確認することをお勧めします。 詳しくは、「GitHub Enterprise Importer の移行ログへのアクセス」を参照してください。
移行したリポジトリで健全性チェックを確認することをお勧めします。
移行が完了したら、ストレージ コンテナーからアーカイブを削除することをお勧めします。 追加の移行を実行する予定の場合は、ADO2GH extension によってストレージ コンテナーに配置されたアーカイブを削除します。 移行が完了したら、コンテナー全体を削除できます。