Para uma migração de projeto, é necessário avaliar o impacto da migração nos serviços em execução no projeto. A API Resource Manager trata o recurso do projeto e todos os serviços executados no mesmo como uma única unidade, o que significa que não são aplicadas alterações de configuração no projeto.
Embora a migração não faça alterações diretas à configuração do projeto, é provável que a alteração na hierarquia de recursos tenha um impacto no funcionamento do projeto e dos respetivos serviços em execução. As políticas de permissão, negação ou organização que são herdadas em vez de anexadas diretamente ao projeto não são migradas com o projeto durante a migração. As políticas da organização e as contas de serviço anexadas diretamente ao recurso são migradas. Isto pode causar um comportamento não intencional após a conclusão da migração.
A migração do seu projeto também pode resultar em violações da política da organização, dependendo das políticas da organização do recurso da organização de destino.
Antes de migrar o seu projeto entre recursos da organização, deve considerar criar um plano de migração para determinar a prontidão do recurso da organização e dos projetos que quer migrar. Neste plano de migração, faça o inventário de cada um dos serviços que o seu projeto está a executar e de quaisquer outros serviços que possam ser afetados pela migração ou pela hierarquia de recursos no destino do seu projeto.
Vista geral do inventário
Use o Cloud Asset Inventory para criar uma vista geral dos recursos em utilização, incluindo políticas de permissão. Pode usar esta vista geral para ajudar a descrever o seu plano de migração.
Também pode usar o Cloud Asset Inventory para transferir estes dados para o BigQuery. Isto permite-lhe consultar os dados através de SQL, que é mais fácil de ler em comparação com a interpretação de dados formatados em JSON. Para obter informações sobre a exportação destes dados, consulte o artigo Exportar para o BigQuery.
Para ver uma lista de todas as políticas de permissão e negação que afetam o acesso a um projeto, consulte o artigo Veja todas as políticas de permissão e negação que se aplicam a um recurso.
Validação de políticas
Quando migra o seu projeto, este deixa de herdar as políticas da sua localização atual na hierarquia de recursos e fica sujeito à avaliação de políticas eficaz no seu destino. Recomendamos que se certifique de que as políticas eficazes no destino do projeto correspondem tanto quanto possível às políticas que o projeto tinha na respetiva localização de origem.
Qualquer política aplicada diretamente ao projeto continua anexada após a conclusão da migração. A aplicação de políticas diretamente ao projeto é uma boa forma de verificar se as políticas corretas são aplicadas a partir do momento em que a migração é concluída.
As políticas de organização, de permissão e de recusa são herdadas através da hierarquia de recursos e podem impedir o funcionamento de um serviço se não forem definidas corretamente. Determine a política em vigor no destino do projeto na hierarquia de recursos para garantir que a política está alinhada com os seus objetivos de governação.
Faça a gestão das chaves encriptadas
Deve verificar se o seu projeto tem uma chave encriptada gerida pelo cliente ou outro
Cloud Key Management Service ativado. As chaves criptográficas são propriedade do projeto e, por isso, um utilizador com acesso owner a esse projeto vai poder gerir e realizar operações criptográficas em chaves no Cloud KMS nesse projeto.
Para mais informações, consulte o artigo Separação de funções.
Funcionalidades de pré-visualização
Pode ativar funcionalidades de pré-visualização em recursos de organização, pastas ou projetos. Se tiver ativado uma funcionalidade alfa ou beta no projeto a migrar, esta funcionalidade deve continuar a funcionar após a migração. Se a funcionalidade de pré-visualização for privada e não estiver na lista de autorizações para o recurso da organização de destino, não poderá fazer alterações de configuração após a conclusão da migração.
Plano de reversão
Se descobrir que algo não está a funcionar em qualquer um dos projetos que migrou, pode restaurá-los para a respetiva localização original. Para isso, tem de ter as autorizações de IAM necessárias e definir as políticas da organização necessárias para poder executar a migração do projeto na ordem inversa.
Para ver uma lista das autorizações necessárias, consulte o artigo Atribua autorizações. Para ver as políticas da organização que tem de configurar para permitir uma migração de projetos, consulte Configurar políticas da organização.
Pastas de importação e exportação dedicadas
A herança de políticas pode causar efeitos não intencionais quando migra um projeto, tanto nos recursos da organização de origem como de destino. Pode mitigar este risco criando pastas específicas para conter apenas projetos para exportação e importação, e garantindo que as mesmas políticas são herdadas pelas pastas nos recursos de organização. Também pode definir autorizações nestas pastas que serão herdadas pelos projetos movidos para as mesmas, o que ajuda a acelerar o processo de migração de projetos.
Ao planear uma migração, considere configurar primeiro uma pasta de origem dedicada.
Para tal, crie uma pasta para cada recurso da organização de destino para o qual planeia
exportar projetos. Em seguida, defina uma política da organização nestas pastas, cada uma com a restrição constraints/resourcemanager.allowedExportDestinations definida para o recurso de organização único para o qual quer exportar projetos.
Por exemplo, pode configurar pastas Export to Marketing Org e Export to Sales Org, cada uma com restrições de políticas de organização adequadas definidas.
Da mesma forma, configure pastas de importação dedicadas no recurso da organização de destino, uma para cada recurso da organização a partir do qual quer importar projetos. Para tal, crie uma pasta para cada recurso da organização de origem a partir do qual
planeia importar projetos. Em seguida, defina uma política organizacional nestas pastas,
cada uma com a restrição constraints/resourcemanager.allowedImportSources definida
para o recurso de organização único a partir do qual quer importar projetos.
Por exemplo, pode configurar pastas Import from Marketing Org e Import from App Development Org, cada uma com restrições de políticas de organização adequadas.
Em cada uma das pastas de importação e exportação, atribua à pessoa que vai mover os projetos a função de roles/resourcemanager.projectMover. Esta função é
herdada por todos os projetos contidos nestas pastas, o que dá ao
utilizador a capacidade de realizar as operações de movimentação em qualquer projeto que seja movido
para essas pastas.
Depois de concluir a migração do projeto, deve remover estas pastas dedicadas.
Para ver informações sobre a definição de políticas de organização, consulte o artigo Configure políticas de organização.
O que se segue?
Para atribuir funções e autorizações de gestão de identidades e acessos para migrar projetos entre organizações, consulte o artigo Atribua funções e autorizações de gestão de identidades e acessos.