Para uma migração de projeto, é necessário avaliar como ela afetarão os serviços executados dentro do projeto. A API Resource Manager trata o recurso do projeto e todos os serviços em execução como uma única unidade. Isso significa que nenhuma alteração de configuração será aplicada dentro do projeto.
Embora a migração não faça alterações de configuração diretas no projeto, a alteração na hierarquia de recursos provavelmente terá um impacto na função do projeto e nos serviços em execução. Políticas herdadas, como o Identity and Access Management ou políticas da organização, não serão migradas com o projeto durante a migração. A organização As políticas e as contas de serviço anexadas diretamente ao recurso serão migradas. Isso pode causar um comportamento não intencional depois que a migração é concluída.
A migração do projeto também pode resultar em violações da política da organização, dependendo das políticas da organização do recurso de destino.
Antes de migrar seu projeto entre os recursos da organização, considere criar um plano de migração para determinar a prontidão do recurso da sua organização e dos projetos que você deseja migram. Neste plano de migração, faça um inventário de cada um dos serviços que o projeto está executando e quaisquer outros serviços que possam estar afetadas pela migração ou pela hierarquia de recursos no destino da sua em um projeto de IA.
Visão geral do inventário
Use o Inventário de recursos do Cloud para criar uma visão geral dos recursos em uso, incluindo as políticas de gerenciamento de identidade e acesso. Use-a para ajudar a descrever seu plano de migração.
Também é possível usar o Inventário de recursos do Cloud para transferir esses dados para o BigQuery. Isso permitirá que você consulte os dados usando SQL, que é mais fácil de ler em comparação com a interpretação de dados formatados em JSON. Para informações sobre como exportar esses dados, consulte Como exportar para o BigQuery.
Verificação da política
Quando você migrar seu projeto, ele não herdará mais as políticas do local atual na hierarquia de recursos e estará sujeito à avaliação de política vigente no destino. Verifique se as políticas em vigor no destino do projeto correspondem ao máximo possível das políticas que o projeto tinha no local de origem.
Todas as políticas aplicadas diretamente ao projeto ainda serão anexadas depois que a migração for concluída. Aplicar políticas diretamente ao projeto é uma boa de verificar se as políticas corretas são aplicadas desde o momento em que a migração é concluído.
As políticas de gerenciamento de identidade e acesso e as políticas da organização são herdadas pela hierarquia de recursos e podem bloquear o funcionamento de um serviço se não forem definidas corretamente. Determine a política efetiva no destino do projeto na hierarquia de recursos para garantir que a política esteja alinhada aos seus objetivos de governança.
Gerenciar chaves criptografadas
Verifique se o projeto tem uma chave criptografada gerenciada pelo cliente ou outro
serviço de gerenciamento de chaves do Cloud ativado. As chaves criptográficas são de propriedade do projeto, e um
usuário com acesso owner a esse projeto, portanto, poderá gerenciar e
executar operações criptográficas em chaves no Cloud KMS nesse
projeto.
Para mais informações, consulte Separação de deveres.
Prévia dos recursos
Você pode ativar os recursos de visualização em recursos, pastas ou projetos da organização. Se você ativou um recurso Alfa ou Beta no projeto a ser migrado, ele continuará funcionando após a migração. Se o recurso de visualização for particular e não estiver na lista de permissões do recurso da organização de destino, você não vai poder fazer alterações na configuração após a migração.
Plano de reversão
Se você descobrir que algo não está funcionando em nenhum dos projetos migrados, restaure-os para o local original. Para fazer isso, é preciso ter as permissões de IAM necessárias e definir as políticas da organização necessárias para executar a migração do projeto de maneira inversa.
Para uma lista de permissões necessárias, consulte Atribuir permissões. Para as políticas da organização que você precisa configurar para permitir uma migração de projeto, 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 você está migrando um projeto, tanto nos recursos da organização de origem quanto nos de destino. Você pode reduza esse risco criando pastas específicas para reter apenas projetos para exportação e importar e garantindo que as mesmas políticas sejam herdadas pelas pastas os recursos da organização. Você também pode definir permissões nessas pastas que serão herdadas pelos projetos movidos nelas, ajudando a acelerar no processo de migração do projeto.
Ao planejar uma migração, primeiro configure uma pasta de origem dedicada.
Para fazer isso, crie uma pasta para cada recurso da organização de destino para a qual você planeja
exportar projetos. Em seguida, defina uma política da organização nessas pastas, cada uma com
a restrição constraints/resourcemanager.allowedExportDestinations definida como o único recurso da organização para o qual você quer exportar projetos.
Por exemplo, é possível configurar pastas Export to Marketing Org e Export to Sales Org, cada uma com as restrições de política da organização definidas.
Da mesma forma, configure pastas de importação dedicadas na organização de destino
um para cada recurso da organização que será importado
projetos. Para isso, crie uma pasta para cada recurso da organização de origem do qual
que você planeja importar projetos. Em seguida, defina uma política da organização nessas pastas
cada um com a restrição constraints/resourcemanager.allowedImportSources definida
para o único recurso da organização do qual você quer importar projetos.
Por exemplo, é possível configurar pastas Import from Marketing Org e Import from App Development Org, cada uma com as restrições de política da organização adequadas.
Em cada uma das pastas de importação e exportação, atribua o papel roles/resourcemanager.projectMover à pessoa que moverá os projetos. Esse papel será herdado por todos os projetos contidos nessas pastas, permitindo que o usuário execute as operações de movimentação em qualquer projeto que seja movido para essas pastas.
Depois de concluir a migração do projeto, remova essas pastas dedicadas.
Para mais informações sobre como definir políticas da organização, consulte Configurar políticas da organização.
A seguir
Para atribuir papéis e permissões do Identity and Access Management para a migração de projetos entre organizações, consulte Atribuir papéis e permissões do Identity and Access Management.