Google Cloud プロジェクトの移行は、リソース階層内のプロジェクトのロケーションを変更するメタデータ オペレーションです。このページでは、プロジェクトを新しい組織に移動する際の移行の仕組み、変更されない点、変更される点について説明します。
リソース階層内のプロジェクト
プロジェクト リソースは、 Google Cloud組織リソースでの基本レベルの構成エンティティです。プロジェクトは組織リソースの下に作成され、フォルダまたは組織リソース自体の下に配置でき、リソース階層を形成します。
組織リソース間では、買収、規制要件、事業部門の分離などにより、プロジェクトの移行が必要な場合があります。Resource Manager API を使用してこれらのプロジェクトを移行できます。また、API を使用すると、必要に応じて移行をロールバックし、プロジェクトを階層内の元の場所に移動することもできます。
移行のシナリオ
プロジェクトの場所によって、次の 2 つのパスのどちらを使用するかが決まります。
- プロジェクトを組織リソース間で移行します。
- スタンドアロン プロジェクト（組織なしで作成されたプロジェクト）を組織リソースの階層に移行します。
プロジェクトの現在の状態を特定する
始める前に、プロジェクトが組織リソースに関連付けられているかどうかを確認する必要があります。これにより、組織から組織へのパスまたは組織なしのパスのどちらをたどるかが決まります。
プロジェクトの親組織リソースに対する resourcemanager.organizations.get 権限がない場合、プロジェクトがGoogle Cloud コンソールの実際の組織のもとで反映されていない可能性があります。これにより、プロジェクトがどの組織リソースにも関連付けられていないように見えます。
プロジェクトが組織リソースに関連付けられているかどうかを確認するには、次のコマンドを実行します。
gcloud
gcloud projects describe PROJECT_ID
PROJECT_ID は、移行するプロジェクトの ID に置き換えます。
出力に parent フィールドが含まれている場合、プロジェクトはすでに組織階層の一部です。
parent フィールドがないか空の場合、プロジェクトは組織リソースのないスタンドアロン プロジェクトです。
プロジェクトの状態に応じて、次のガイドを参照してください。
- 関連する組織なしで作成されたプロジェクトを移行する場合は、組織リソースに関連付けられていないプロジェクトを移行するをご覧ください。
- プロジェクトを組織リソース間で移行する場合は、組織リソース間でプロジェクトを移行するをご覧ください。
移行の仕組み
プロジェクトの移行はデータ転送ではありません。サービス、データベース、仮想マシン（VM）インスタンスはアクティブな状態が維持され、ダウンタイムは発生しません。代わりに、移行によってプロジェクトの親リソースが更新されます。 Google Cloud は階層的な継承モデルに従うため、プロジェクトのセキュリティ ポスチャーは新しい親に関連付けられた瞬間に変化します。
| 機能 | ステータス | 影響 |
|---|---|---|
| プロジェクト ID と番号 | 変更なし | API キー、サービス名、ハードコードされた ID は変更されません。 |
| データとリソース | 変更なし | VM、ストレージ バケット、データベースはオンラインのままです。 |
| 直接 IAM ロール | 変更なし | プロジェクトに直接付与されたロールは、プロジェクトとともに移動します。 |
| 継承された IAM ロール | 変更点 | 移行元の組織またはフォルダレベルで付与されたロールは失われます。 |
| 組織のポリシー | 変更点 | ソースの制約は宛先の制約に置き換えられます。 |
| 割り当て | 変更点 | 継承された組織レベルの割り当ては失われますが、プロジェクト レベルの割り当ては残ります。 |
| 請求先アカウント | 変更なし | プロジェクトは元の請求先アカウントにリンクされたままになります。 |
割り当ての影響
特定のリソースレベルで割り当てが定義されている場合、移行後に次の要素が適用されます。
- プロジェクト レベルで定義された割り当ては変更されません。
- 組織リソースレベルで定義された割り当ては転送されません。組織は継承された割り当てを失います。
次のページを使用して、組織リソースに適用する割り当てを判断できます。
例
$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"
...
- defaultLimit: '600'
dimensions:
region: us-central1
effectiveLimit: '650'
...
重要な考慮事項
移行を開始する前に、サービスの中断を防ぐために、次のリスクの高い領域を確認してください。
割り当て上限: 宛先組織の割り当て上限が移行元より低い場合、プロジェクトが移行後に割り当てを超える可能性があります。
共有 VPC: 共有 VPC に接続されているプロジェクトを移行することはできません。プロジェクトを移行する前に、移行元の共有 VPC からプロジェクトを切り離す必要があります。
カスタムロール: プロジェクトが組織レベルで定義されたカスタム IAM ロールに依存している場合、これらのロールは移行先に存在しません。移行する前に、移行先組織で再作成します。
移行のロードマップ
次のロードマップを使用して、プロジェクトの移行プロセスをナビゲートします。
- 準備: タイミングを調整するために移行計画を作成します。
- 実行: IAM ロールを割り当て、組織のポリシーを構成して、移行を実行します。
- 確認: 継承されたポリシーの監査や課金の更新など、移行後のタスクを完了します。