Para migrar un proyecto, es necesario evaluar cómo la migración afectará a los servicios que se ejecutan dentro del proyecto. El La API de Resource Manager trata el recurso del proyecto y todos los servicios que se ejecutan en él. como una sola unidad, lo que significa que no se aplicarán cambios de configuración dentro del proyecto.
Si bien la migración no hará cambios directos en la configuración del proyecto, es probable que el cambio en la jerarquía de recursos tenga un impacto en el función del proyecto y sus servicios en ejecución. Políticas heredadas, como Identity and Access Management o políticas de la organización, no migrarán con el proyecto durante la migración. Se migrarán las políticas de la organización y las cuentas de servicio que se adjuntan directamente al recurso. Esta puede provocar comportamientos no deseados después de que se complete la migración.
Migrar tu proyecto también puede generar una política de la organización incumplimientos, según las políticas de la organización del recurso de destino.
Antes de migrar tu proyecto entre los recursos de la organización, debes considerar crear un plan de migración para determinar la preparación tanto del recurso de la organización como de los proyectos que deseas migrar. En este plan de migración, haz un inventario de cada uno de los servicios que ejecuta tu proyecto y de cualquier otro servicio que pueda verse afectado por la migración o por la jerarquía de recursos en el destino de tu proyecto.
Descripción general de Inventory
Usa Cloud Asset Inventory para crear una descripción general de los recursos en uso, incluidas las políticas de Identity and Access Management. Puedes usar esta descripción general para ayudarte a definir tu plan de migración.
También puedes usar Cloud Asset Inventory para transferir estos datos en BigQuery. Esto te permitirá consultar los datos con SQL, que es más fácil de leer en comparación con la interpretación de datos con formato JSON. Información sobre cómo exportar estos datos, consulta Cómo exportar a BigQuery.
Verificación de políticas
Cuando migres tu proyecto, ya no heredará las políticas de su ubicación actual en la jerarquía de recursos y estará sujeto a la evaluación de políticas vigentes en su destino. Te recomendamos asegurarte de que las políticas vigentes en el destino del proyecto coincidan en la medida de lo posible con las políticas que tenía el proyecto en su ubicación de origen.
Cualquier política que se aplique directamente al proyecto se adjuntará después de se complete la migración. Aplicar políticas directamente al proyecto es una buena de verificación de que se aplican las políticas correctas desde el momento en que se realiza la migración que se completó.
Las políticas de Identity and Access Management y las políticas de la organización se heredan a través del de recursos y puede bloquear el funcionamiento de un servicio si no está configurado correctamente. Determinar la política vigente en el destino del proyecto en tu de recursos para garantizar que la política se alinee con tus objetivos de administración.
Administra claves encriptadas
Debes verificar si tu proyecto tiene una clave de encriptación administrada por el cliente o algún otro
Cloud Key Management Service habilitado en ella Las claves criptográficas son propiedad del proyecto y una
usuario con acceso de owner a ese proyecto podrá administrar y
realizar operaciones criptográficas en claves de Cloud KMS en las que
en un proyecto final.
Consulta Separación de obligaciones para obtener más información.
Funciones de vista previa
Puedes habilitar las funciones de vista previa en los recursos, carpetas o proyectos de la organización. Si habilitaste una función alfa o beta en el proyecto que se migrará, esta función debería seguir funcionando después de la migración. Si la función de vista previa es privada y no está incluida en la lista de entidades permitidas del recurso de la organización de destino, no podrá realizar cambios en la configuración una vez que se complete la migración.
Plan de reversión
Si descubres que algo no está funcionando en ninguno de los proyectos que tienes migrado, puedes restablecerlos a su ubicación original. Para ello, debes tener los permisos de IAM necesarios y establecer las políticas de la organización requeridas para que puedas ejecutar la migración del proyecto de forma inversa.
Para obtener una lista de los permisos necesarios, consulta Cómo asignar permisos. Para las políticas de la organización que debes configurar para permitir la migración de un proyecto, consulta Configura las políticas de la organización.
Carpetas dedicadas para importar y exportar
La herencia de políticas puede causar efectos no deseados cuando migras un proyecto, tanto en los recursos de la organización de origen como en los de destino. Para mitigar este riesgo, puedes crear carpetas específicas que contengan solo proyectos para exportar e importar, y asegurarte de que las carpetas de ambos recursos de la organización hereden las mismas políticas. También puedes establecer permisos en estas carpetas que se heredarán a los proyectos trasladados dentro de ellos, lo que ayudará a acelerar el de migración del proyecto.
Cuando planifiques una migración, considera configurar primero una carpeta fuente dedicada.
Para ello, crea una carpeta para cada recurso de la organización de destino al que planeas
proyectos de exportación. Luego, establece una política de la organización en estas carpetas, cada una con
la restricción constraints/resourcemanager.allowedExportDestinations establecida en
el único recurso de la organización al que quieres exportar proyectos.
Por ejemplo, puedes configurar Export to Marketing Org y
Export to Sales Org carpetas, cada una con la política de la organización adecuada
restricciones establecidas.
Del mismo modo, configura carpetas de importación dedicadas en la organización de destino
uno para cada recurso de la organización desde el que quieres importar
proyectos. Para ello, crea una carpeta para cada recurso de la organización de origen del que
planeas importar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con la restricción constraints/resourcemanager.allowedImportSources establecida en el único recurso de la organización desde el que deseas importar proyectos.
Por ejemplo, puedes configurar las carpetas Import from Marketing Org y
Import from App Development Org, cada una con las restricciones de políticas de organización
apropiadas establecidas.
En cada carpeta de importación y exportación, asigna la persona que realizará la transferencia.
a los proyectos la función roles/resourcemanager.projectMover. Cualquier proyecto que se encuentre dentro de estas carpetas heredará este rol, lo que le permitirá al usuario realizar las operaciones de traslado en cualquier proyecto que se mueva a esas carpetas.
Después de completar la migración del proyecto, debes quitar estas y carpetas específicas.
Para obtener información sobre cómo configurar las políticas de la organización, consulta Configura políticas de la organización.
¿Qué sigue?
Para asignar roles y permisos de administración de identidades y accesos para migrar proyectos entre organizaciones, consulta Cómo asignar roles y permisos de administración de identidades y accesos.