プロジェクトの移行では、移行がプロジェクト内で実行されているサービスに与える影響を評価する必要があります。Resource Manager API は、プロジェクト リソースとその下位にあるすべてのサービスを単一のユニットとして扱います。つまり、構成変更がプロジェクト内で適用されることはありません。
移行によって直接プロジェクトの構成が変更されることはありませんが、リソース階層の変更はプロジェクトの機能と実行中のサービスに影響する可能性があります。Identity and Access Management や組織のポリシーなどの継承されたポリシーは、移行時にプロジェクトと一緒に移行されません。リソースに直接接続されている組織のポリシーとサービス アカウントは移行されます。このため、移行の完了後に意図しない動作が発生することがあります。
プロジェクトの移動は、移行先の組織リソースの組織のポリシーによっては、組織のポリシー違反になることもあります。
組織リソース間でプロジェクトを移行する前に、移行計画を作成して、組織リソースと移行するプロジェクトの両方で準備状況を判断する必要があります。この移行計画では、プロジェクトで実行されている各サービスや、移行またはプロジェクトの移行先のリソース階層によって影響を受ける可能性のあるその他のサービスのインベントリを利用します。
インベントリの概要
Cloud Asset Inventory を使用して、Identity and Access Management ポリシーなど、使用中のリソースの概要を作成します。この概要は、移行計画の概要を示すのに活用できます。
Cloud Asset Inventory を使用して、このデータを BigQuery に転送することもできます。これにより、SQL を使用してデータをクエリできます。これは、JSON 形式のデータに比べて解釈が容易です。このデータをエクスポートする方法については、BigQuery へのエクスポートをご覧ください。
ポリシーの確認
プロジェクトを移行すると、リソース階層内の現在の場所からポリシーが継承されなくなり、移行先の有効なポリシー評価の対象となります。プロジェクトの移行先の有効なポリシーが、そのプロジェクトの元の場所にあるポリシーとできる限り一致するようにすることをおすすめします。
プロジェクトに直接適用されるポリシーは、移行の完了後も引き続きアタッチされます。移行が完了した時点から適切なポリシーが適用されていることを確認するには、プロジェクトに直接ポリシーを適用するのが最適な方法です。
Identity and Access Management のポリシーと組織のポリシーはリソース階層によって継承され、正しく設定されていない場合はサービスが機能しなくなることがあります。リソース階層のプロジェクトの移行先で有効なポリシーを決定し、ポリシーがガバナンスの目的に適合していることを確認します。
暗号鍵を管理する
プロジェクトで顧客管理の暗号鍵や他の Cloud Key Management Service が有効になっているかどうかを確認する必要があります。暗号鍵はプロジェクトで所有されます。したがって、そのプロジェクトへの owner アクセス権を持つユーザーは、そのプロジェクトの Cloud KMS の鍵の管理と暗号オペレーションを実行できます。
詳細については、職掌分散をご覧ください。
プレビューの機能
組織のリソース、フォルダ、またはプロジェクトでプレビュー機能を有効にできます。プロジェクトのアルファ版またはベータ版の機能を移行できるようにしている場合、移行後もこの機能は引き続き機能します。プレビュー機能が非公開で、移動先の組織リソースの許可リストに含まれていない場合は、移行の完了後に設定を変更できなくなります。
ロールバック プラン
移行したどのプロジェクトでも機能していない何かがあることがわかった場合は、元の場所に戻すことができます。実行するには、必要な IAM 権限を持ち、必要な組織のポリシーを設定する必要があります。そうすることで、プロジェクトの逆への移行を実行できます。
必要な権限のリストについては、権限を割り当てるをご覧ください。プロジェクトの移行を許可するように構成する必要がある組織のポリシーについては、組織のポリシーを構成するをご覧ください。
専用のインポート フォルダとエクスポート フォルダ
ポリシーを継承すると、プロジェクトを移行するときに、移行元と移行先の両方の組織リソースで不測の影響が生じる可能性があります。このリスクを軽減するために、エクスポートとインポート用のプロジェクトのみを保持する特定のフォルダを作成し、両方の組織リソースのフォルダに同じポリシーが継承されるようにします。これらのフォルダ内で移動したプロジェクトに継承される権限をそれらのフォルダで設定すると、プロジェクトの移行プロセスが加速します。
移行を計画する場合は、最初に専用のソースフォルダを設定するようにしてください。これを行うために、プロジェクトをエクスポートする予定の保存先の組織リソースごとにフォルダを作成します。次に、これらのフォルダに組織ポリシーを設定します。各フォルダーには、プロジェクトのエクスポート先の単一の組織リソースに constraints/resourcemanager.allowedExportDestinations 制約が設定されています。
たとえば、Export to Marketing Org と Export to Sales Org のフォルダを設定し、それぞれに適切な組織ポリシー制約を設定できます。
同様に、宛先組織リソースに専用のインポートフォルダを設定し、プロジェクトのインポート元組織リソースにも 1 つ設定します。これを行うために、プロジェクトをインポートする予定の組織リソースごとにフォルダを作成します。次に、これらのフォルダに組織ポリシーを設定します。各フォルダーには、プロジェクトのインポート元の単一の組織リソースに constraints/resourcemanager.allowedImportSources 制約が設定されています。
たとえば、Import from Marketing Org と Import from App Development Org のフォルダを設定し、それぞれに適切な組織ポリシー制約を設定できます。
それぞれのインポート フォルダとエクスポート フォルダで、プロジェクトを移行するユーザーに roles/resourcemanager.projectMover ロールを割り当てます。このロールは、これらのフォルダ内に含まれるすべてのプロジェクトに継承され、ユーザーはこれらのフォルダに移行されたプロジェクトに対して移行オペレーションを実行できます。
プロジェクトの移行が完了したら、これらの専用フォルダを削除する必要があります。
組織のポリシーの設定については、組織のポリシーの構成をご覧ください。
次のステップ
組織間でプロジェクトを移行するために Identity and Access Management のロールと権限を割り当てるには、Identity and Access Management のロールと権限を割り当てるをご覧ください。