Data Center Migration
Data Center Migration は、次のことができる管理者向けのツールです。
- 複数の Bitbucket インスタンスを集約する
- Bitbucket Server から Bitbucket Data Center に移行する
- ある Bitbucket Data Center インスタンスから別の Bitbucket Data Center インスタンスにプロジェクトとリポジトリを選択的にエクスポート/インポートする
Git データを、別の Bitbucket Server または Data Center デプロイメントから、プル リクエスト、コメント、および添付ファイル履歴とともに、Bitbucket Data Center にインポートまたはエクスポートできます。
この機能は Bitbucket Data Center インスタンスを持つお客様のみが使用できます。
移行を開始する前に、次の情報を慎重に確認する必要があります。トラブルシューティング、キャンセル、クリーンアップやエラーおよび警告メッセージについての情報もあります。
始める前に
これは、移行の実行前に確認および完了するタスクに関連する考慮事項の、大まかな概要です。移行を開始する前に、以降のセクションを注意深くご確認ください。
ユーザー インターフェース
この機能の初回 (Bitbucket Server 5.14) リリースにはグラフィカル ユーザー インターフェイスはありません。代わりに REST コールを行って移行プロセスを制御できます。
移行を実行するには、次のいずれかが必要です。
- 任意のツールを使用して REST コールを行う
- refer to the provided sample cURL commands for import and sample cURL commands for export.
cURL コマンドの使用を予定している場合は、.netrc ファイルをセットアップ (サンプル コマンドでは -n フラグを使用) し、自身のマシンに jq をインストールすることを推奨します。
プレビュー REST エンドポイントを使用する
プレビュー機能を使用して、移行の前にエクスポート範囲を確認できます。
プレビューは、常に完全に移行される、フォーク階層を考慮します。
ディスク容量の要件
移行するファイルに対して十分なディスク空き容量があることを必ず確認します。エクスポート中に必要な大まかなディスク空き容量は、エクスポートされる Git データと添付ファイルのサイズです。
ElasticSearch およびデータベース サーバー用に追加の領域が必要です。
利用可能なスペースが不明な場合、次のナレッジベース記事で Bitbucket のリポジトリ ID を特定し、それを使用して、利用可能なディスク空き容量を確認できます。
プロジェクト名の競合の問題
移行前に、移行元インスタンスと宛先先インスタンスの両方でプロジェクト名を確認します。移行先インスタンスでプロジェクト名が使用中の場合、インポートされるプロジェクトの名前が変更されます。
これを回避するには、次のいずれかを行います。
- すべてのプロジェクト名を確認し、移行前に名前を変更する
- 移行後にインポート ジョブの警告を確認し、プロジェクトの名前を手動で変更する
同じロジックが、個人プロジェクトのリポジトリ名にも適用されます。
エクスポートに必要な時間
エクスポートに必要な時間は、データ セット、個別の負荷、およびトラフィックによる影響を受けるため、この時間を予測する現実的な方法はありません。
一部のテストでは 200 GB のエクスポートに 2 ～ 4 時間がかかったことが確認されていますが、これよりも時間がかかる可能性があります。
インポートに必要な時間
インポートに必要な時間は、インポートされるエクスポート アーカイブのサイズ、プル リクエストの数、およびリポジトリの数の影響を受けるため、この時間を予測する現実的な方法はありません。
インポートにはエクスポートよりも長い時間がかかります (およそ 4 倍) 。これは、エクスポートでは、インポート時に実行されるインデックス作成と検証が行われず、データ セット、個別の負荷、およびトラフィックにのみ依存するためです。
ユーザーおよびライセンス管理の推奨事項
エクスポート時、非アクティブなユーザーは生成された「削除済みのユーザー」リスト追加され、移行時にライセンスを消費しません。
移行前に、ソース インスタンスと宛先インスタンスの両方を同じユーザー ディレクトリに接続しておくことを強くおすすめします。
ユーザーは移行されませんが、プロジェクトおよびリポジトリ上のそのユーザーの権限は移行され、権限はユーザー名で照合されます。宛先インスタンスにユーザーが見つからない場合、権限は移行されない可能性があり、警告が記録されます。
両方のインスタンスでユーザー ディレクトリが異なる場合、同じユーザー名のユーザーが宛先インスタンスに存在するが、ソース インスタンスの実際のユーザーとは異なる可能性があります。これにより、インポート時にそのユーザーに誤った権限が付与される可能性があります。
サードパーティ製のプラグイン
サードパーティ製のプラグイン、およびそのデータは移行されない点にご注意ください。
プラグイン側でこの API を使用して独自の移行を実装できます。
プル リクエストのコメント
プル リクエストのコメントが別のリポジトリにアップロードされた添付ファイルを参照している場合は、その添付ファイルが正常にインポートされない可能性があります。
例: ユーザーが 1 つのリポジトリのプル リクエストでコメントに添付ファイルをアップロードし、リンクをコピーして、別のリポジトリのプル リクエストにある別のコメントにペーストしたとします。
これは残りのコメントのインポートには影響せず、添付ファイルにのみ影響します。
詳細は、「トラブルシューティング、キャンセルおよびクリーンアップ」ページを参照してください。
移行に含まれるエンティティ
次の表は、移行時にインポートおよびエクスポートされるエンティティの一覧です。
Git LFS objects migration needs to be run separately. You can use this Git LFS migration process to export these objects.
カテゴリ | 項目 | インポート | エクスポート |
|---|---|---|---|
| Git | ファイル システムの Git リポジトリ |  | |
| Git LFS | LFS objects on file system |  | |
| プル リクエスト | プル リクエストのメタデータ | | |
| PR のユーザー情報 | | | |
| PR のコメント | | | |
| PR の添付ファイル | | | |
| PR ファイルのコメント | | | |
| プロジェクト設定 | 説明 | | |
| プロジェクト権限 (ユーザー アクセス) | | | |
| プロジェクト権限 (グループ アクセス) | | | |
| プロジェクト権限 (公開) | | | |
| プロジェクト権限 (既定の権限) | | | |
| リポジトリ設定 | 既定のブランチ | | |
| フォーク | | | |
| トランスコード差分 | | | |
| LFS 有効 | | | |
| リポジトリ権限 (ユーザー アクセス) | | | |
| リポジトリ権限 (グループ アクセス) | | | |
| リポジトリ権限 (公開アクセス) | | | |
| ディスク上の Git フック | | | |
| Repository hooks | | |