プロジェクト移行計画を使用すると、組織リソース間でプロジェクトを移動する前に、組織の準備状況を評価し、サービスの中断を防ぐことができます。アクティブなサービスと依存関係のインベントリは、移行先のリソース階層がワークロードにどのように影響するかを予測する際にも役立ちます。
移動中、Cloud Resource Manager API は、プロジェクトとその基盤となるサービスを、内部構成の変更なしで単一のユニットとして扱います。ただし、継承された許可ポリシー、拒否ポリシー、組織のポリシーはプロジェクトとともに移行されませんが、直接適用されたポリシーとサービス アカウントは保持されます。この階層の変更により、予期しない動作が発生したり、移行先の組織で組織のポリシー違反がトリガーされたりする可能性があります。
インベントリの概要
Cloud Asset Inventory を使用して、許可ポリシーを含む、使用中のリソースの概要を作成します。この概要は、移行計画の概要をまとめる際に役立ちます。
Cloud Asset Inventory を使用して、このデータを BigQuery に転送することもできます。これにより、SQL を使用してデータをクエリできます。これは、JSON 形式のデータに比べて解釈が容易です。このデータをエクスポートする方法については、BigQuery へのエクスポートをご覧ください。
プロジェクトへのアクセスに影響するすべての許可ポリシーと拒否ポリシーのリストを取得するには、リソースに適用される許可ポリシーと拒否ポリシーをすべて表示するをご覧ください。
ポリシーの確認
プロジェクトを移行すると、リソース階層の現在の場所からポリシーが継承されなくなり、移行先で有効なポリシー評価の対象になります。プロジェクトの移行先の有効なポリシーが、そのプロジェクトの元の場所にあるポリシーとできる限り一致するようにすることをおすすめします。
プロジェクトに直接適用されるポリシーは、移行の完了後も引き続きアタッチされます。移行が完了した時点から適切なポリシーが適用されていることを確認するには、プロジェクトに直接ポリシーを適用するのが最適な方法です。
許可ポリシー、拒否ポリシー、組織のポリシーはリソース階層によって継承され、正しく設定されていない場合はサービスが機能しなくなることがあります。リソース階層内のプロジェクトの移行先で有効なポリシーを特定し、ポリシーがガバナンス目標に沿っていることを確認します。
暗号鍵を管理する
プロジェクトで顧客管理の暗号鍵や他の Cloud Key Management Service が有効になっているかどうかを確認する必要があります。暗号鍵はプロジェクトで所有されます。したがって、そのプロジェクトへの owner アクセス権を持つユーザーは、そのプロジェクトの Cloud KMS の鍵の管理と暗号オペレーションを実行できます。
詳細については、職掌分散をご覧ください。
プレビュー機能
組織のリソース、フォルダ、またはプロジェクトでプレビュー機能を有効にできます。プロジェクトのアルファ版またはベータ版の機能を移行できるようにしている場合、移行後もこの機能は引き続き機能します。プレビュー機能が非公開で、移動先の組織リソースの許可リストに追加されていない場合は、移行の完了後に設定を変更できなくなります。
新しい請求先アカウントを特定する
Cloud 請求先アカウントは、組織リソース全体で使用できます。プロジェクトをある組織リソースから別の組織リソースに移行しても課金に影響はありません。料金は、古い請求先アカウントに対して継続して課せられます。ただし、組織リソース間でプロジェクトを移行する場合は、しばしば新しい請求先アカウントへの移行要件があることもあります。
移行計画の一環として、既存の請求先アカウントを保持するかどうかを決定します。プロジェクトを、移行先の組織リソースの新しい請求先アカウントに関連付けることもできます。
請求先アカウントを変更または移行する方法については、請求先アカウントを変更するをご覧ください。
ロールバック プラン
移行したどのプロジェクトでも機能していない何かがあることがわかった場合は、元の場所に戻すことができます。実行するには、必要な 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 のロールと権限を割り当てるをご覧ください。