1. Introdução
O peering de VPC é um método comum para os produtores oferecerem consumo de serviços aos usuários. No entanto, o uso do peering de VPC traz muitas complexidades de roteamento, como peering de VPC não transitivo, grande consumo de endereços IP e exposição excessiva de recursos em uma VPC com peering.
O Private Service Connect (PSC) é um método de conectividade que permite que os produtores exponham um serviço em um único endpoint provisionado por um consumidor em uma VPC de carga de trabalho. Isso elimina muitos problemas que os usuários enfrentam com o peering de VPC. Embora muitos serviços novos estejam sendo criados com o PSC, ainda há muitos serviços que existem como serviços de peering de VPC.
O Google Cloud tem o prazer de apresentar um caminho de migração para serviços que você criou usando o peering de VPC para mudar para uma arquitetura baseada em PSC. Ao usar esse método de migração, o endereço IP do serviço produtor exposto pelo peering de VPC é preservado até a arquitetura baseada em PSC. Assim, são necessárias mudanças mínimas para o consumidor. Siga este codelab para aprender as etapas técnicas da migração.
OBSERVAÇÃO: esse caminho de migração é válido apenas para serviços em que o produtor e o consumidor estão na mesma organização do Google Cloud. Para qualquer serviço do Google Cloud ou de terceiros que use o peering de VPC, um método de migração semelhante será usado, mas personalizado para o serviço em questão. Entre em contato com as partes relevantes para saber mais sobre o caminho de migração desses tipos de serviços.
O que você vai aprender
- Como configurar um serviço baseado em peering de VPC
- Como configurar um serviço baseado em PSC
- Usar a API Internal-Ranges para realizar a migração de sub-rede por peering de VPC e migrar um serviço de peering de VPC para PSC.
- Entender quando o tempo de inatividade precisa ocorrer para a migração de serviços
- Etapas de limpeza da migração
O que é necessário
- Projeto do Google Cloud com permissões de proprietário
2. Topologia do codelab
Para simplificar, este codelab centraliza todos os recursos em um único projeto. O codelab vai indicar quais ações precisam ser realizadas no lado do produtor e quais precisam ser realizadas no lado do consumidor caso eles estejam em projetos diferentes.
Este codelab terá quatro estados.
O estado 1 é o estado do peering de VPC. Haverá duas VPCs, consumer-vpc e producer-vpc, que serão pareadas. A "producer-vpc" terá um serviço Apache simples exposto por um balanceador de carga de rede de passagem interna. A consumer-vpc terá uma única consumer-vm para fins de teste.
O estado 2 é o estado de teste do PSC. Vamos criar uma regra de encaminhamento e usá-la para associar ao nosso anexo de serviço. Em seguida, vamos criar um endpoint de teste do PSC em consumer-vpc para verificar se o serviço do PSC está funcionando conforme o esperado.
O estado 3 é o estado da migração. Vamos reservar o intervalo de sub-rede em producer-vpc em que o serviço baseado em peering de VPC foi implantado para ser usado em consumer-vpc. Em seguida, vamos criar um novo endpoint do PSC com o mesmo endereço IP da regra de encaminhamento pré-existente em producer-vpc.
O estado 4 é o estado final do PSC. Vamos limpar o endpoint de teste do PSC e excluir o peering de VPC entre consumer-vpc e producer-vpc.
3. Configuração e requisitos
Configuração de ambiente autoguiada
- Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.
- O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
- O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como
PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto. - Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
- Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.
Inicie o Cloud Shell
Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:
O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.
4. Antes de começar
Ativar APIs
No Cloud Shell, verifique se o projeto está configurado e configure as variáveis.
gcloud auth login gcloud config list project gcloud config set project [YOUR-PROJECT-ID] export projectid=[YOUR-PROJECT-ID] export region=us-central1 export zone=$region-a echo $projectid echo $region echo $zone
Ative todos os serviços necessários
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Criar rede VPC do produtor (atividade do produtor)
Rede VPC
No Cloud Shell
gcloud compute networks create producer-vpc \
--subnet-mode=custom
Criar sub-redes
No Cloud Shell
gcloud compute networks subnets create producer-service-subnet \
--network=producer-vpc \
--range=10.0.0.0/28 \
--region=$region
gcloud compute networks subnets create producer-fr-subnet \
--network=producer-vpc \
--range=192.168.0.0/28 \
--region=$region
Criar Cloud Router e Cloud NAT do produtor
No Cloud Shell
gcloud compute routers create $region-cr \
--network=producer-vpc \
--region=$region
gcloud compute routers nats create $region-nat \
--router=$region-cr \
--region=$region \
--nat-all-subnet-ip-ranges \
--auto-allocate-nat-external-ips
Criar política de firewall de rede e regras de firewall do produtor
No Cloud Shell
gcloud compute network-firewall-policies create producer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy producer-vpc-policy \
--network producer-vpc \
--name network-producer-vpc \
--global-firewall-policy
Para permitir que o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:
- Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
- Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.
No Cloud Shell
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
Também vamos criar mais duas regras que permitem verificações de integridade do balanceador de carga para o serviço, além de permitir o tráfego de rede de VMs que se conectarão da consumer-vpc.
No Cloud Shell
gcloud compute network-firewall-policies rules create 2000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "LB healthchecks" \
--direction INGRESS \
--src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
--layer4-configs tcp:80 \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 3000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow access from consumer-vpc" \
--direction INGRESS \
--src-ip-ranges 10.0.1.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
6. Configuração do serviço de produtor (atividade do produtor)
Vamos criar um serviço de produtor com uma única VM executando um servidor da Web Apache que será adicionado a um grupo de instâncias não gerenciadas na frente de um balanceador de carga de passagem de rede interna regional.
Criar a VM e o grupo de instâncias não gerenciadas
No Cloud Shell
gcloud compute instances create producer-service-vm \
--network producer-vpc \
--subnet producer-service-subnet \
--zone $zone \
--no-address \
--metadata startup-script='#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
a2enmod ssl
sudo a2ensite default-ssl
echo "I am a Producer Service." | \
tee /var/www/html/index.html
systemctl restart apache2'
No Cloud Shell
gcloud compute instance-groups unmanaged create prod-uig \ --zone=$zone gcloud compute instance-groups unmanaged add-instances prod-uig \ --zone=$zone \ --instances=producer-service-vm
Criar o balanceador de carga de rede de passagem interna regional
No Cloud Shell
gcloud compute health-checks create http producer-hc \
--region=$region
gcloud compute backend-services create producer-bes \
--load-balancing-scheme=internal \
--protocol=tcp \
--region=$region \
--health-checks=producer-hc \
--health-checks-region=$region
gcloud compute backend-services add-backend producer-bes \
--region=$region \
--instance-group=prod-uig \
--instance-group-zone=$zone
gcloud compute addresses create producer-fr-ip\
--region $region \
--subnet producer-fr-subnet \
--addresses 192.168.0.2
gcloud compute forwarding-rules create producer-fr \
--region=$region \
--load-balancing-scheme=internal \
--network=producer-vpc \
--subnet=producer-fr-subnet \
--address=producer-fr-ip \
--ip-protocol=TCP \
--ports=80 \
--backend-service=producer-bes \
--backend-service-region=$region
7. Criar rede VPC do consumidor (atividade do consumidor)
Rede VPC
No Cloud Shell
gcloud compute networks create consumer-vpc \
--subnet-mode=custom
Criar sub-rede
No Cloud Shell
gcloud compute networks subnets create consumer-vm-subnet \
--network=consumer-vpc \
--range=10.0.1.0/28 \
--region=$region
Criar uma política de firewall de rede do consumidor e regras de firewall
Vamos criar outra política de firewall de rede para a VPC do consumidor.
No Cloud Shell
gcloud compute network-firewall-policies create consumer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy consumer-vpc-policy \
--network consumer-vpc \
--name network-consumer-vpc \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy consumer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
8. Criar peering de VPC
Atividade do produtor
No Cloud Shell
gcloud compute networks peerings create producer-vpc-peering \
--network=producer-vpc \
--peer-project=$projectid \
--peer-network=consumer-vpc
Atividade do consumidor
No Cloud Shell
gcloud compute networks peerings create consumer-vpc-peering \
--network=consumer-vpc \
--peer-project=$projectid \
--peer-network=producer-vpc
Confirme se o peering foi estabelecido verificando a lista de rotas na consumer-vpc. Você vai ver rotas para consumer-vpc e producer-vpc.
Atividade do consumidor
No Cloud Shell
gcloud compute routes list --filter="network=consumer-vpc"
Resposta esperada
NAME: default-route-49dda7094977e231 NETWORK: consumer-vpc DEST_RANGE: 0.0.0.0/0 NEXT_HOP: default-internet-gateway PRIORITY: 1000 NAME: default-route-r-10d65e16cc6278b2 NETWORK: consumer-vpc DEST_RANGE: 10.0.1.0/28 NEXT_HOP: consumer-vpc PRIORITY: 0 NAME: peering-route-496d0732b4f11cea NETWORK: consumer-vpc DEST_RANGE: 192.168.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0 NAME: peering-route-b4f9d3acc4c08d55 NETWORK: consumer-vpc DEST_RANGE: 10.0.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0
9. Criar zona de DNS (atividade do consumidor)
Vamos criar uma zona privada do Cloud DNS para chamar o serviço do produtor por DNS em vez de um endereço IP particular para mostrar um exemplo mais realista.
Vamos adicionar um registro A ao serviço de apontamento do domínio example.com para service.example.com no endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem que criamos anteriormente. O endereço IP da regra de encaminhamento é 192.168.0.2.
No Cloud Shell
gcloud dns managed-zones create "producer-service" \ --dns-name=example.com \ --description="producer service dns" \ --visibility=private \ --networks=consumer-vpc gcloud dns record-sets transaction start \ --zone="producer-service" gcloud dns record-sets transaction add 192.168.0.2 \ --name=service.example.com \ --ttl=300 \ --type=A \ --zone="producer-service" gcloud dns record-sets transaction execute \ --zone="producer-service"
10. Testar o serviço do produtor por peering de VPC (atividade do consumidor)
Neste ponto, a arquitetura do estado 1 já foi criada.
Criar VM de cliente consumidor
No Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Testar a conectividade
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da VM cliente do consumidor
curl service.example.com
Resposta esperada
I am a Producer Service.
Da VM cliente do consumidor
exit
11. Preparar o serviço para o Private Service Connect (atividade do produtor)
Agora que concluímos todas as etapas de configuração inicial, vamos começar a preparar o serviço com peering de VPC para migração para o Private Service Connect. Nesta seção, vamos fazer mudanças na producer-vpc configurando o serviço para ser exposto por um anexo de serviço. Precisamos criar uma nova sub-rede e uma nova regra de encaminhamento nela para migrar a sub-rede atual para a VPC do consumidor e manter o endereço IP do serviço intacto.
Crie a sub-rede em que o novo IP da regra de encaminhamento do balanceador de carga será hospedado.
No Cloud Shell
gcloud compute networks subnets create producer-psc-fr-subnet \
--network=producer-vpc \
--range=10.0.2.64/28 \
--region=$region
Crie o endereço IP interno da regra de encaminhamento do balanceador de carga.
No Cloud Shell
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
Crie a nova regra de encaminhamento do balanceador de carga. Essa regra está configurada para usar o mesmo serviço de back-end e as mesmas verificações de integridade que configuramos anteriormente.
No Cloud Shell
gcloud compute forwarding-rules create psc-service-fr \ --region=$region \ --load-balancing-scheme=internal \ --network=producer-vpc \ --subnet=producer-psc-fr-subnet \ --address=producer-psc-ip \ --ip-protocol=TCP \ --ports=80 \ --backend-service=producer-bes \ --backend-service-region=$region
A psc-nat-subnet será associada ao anexo de serviço do PSC para fins de conversão de endereços de rede. Para casos de uso de produção, essa sub-rede precisa ter o tamanho adequado para oferecer suporte ao número de endpoints conectados. Consulte a documentação sobre dimensionamento de sub-rede NAT do PSC para mais informações.
No Cloud Shell
gcloud compute networks subnets create psc-nat-subnet \
--network=producer-vpc \
--range=10.100.100.0/28 \
--region=$region \
--purpose=PRIVATE_SERVICE_CONNECT
É necessário adicionar outra regra de firewall à política de firewall de rede para permitir o tráfego da psc-nat-subnet. Ao acessar o serviço pelo PSC, o tráfego será originado da psc-nat-subnet.
No Cloud Shell
gcloud compute network-firewall-policies rules create 2001 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow PSC NAT subnet" \
--direction INGRESS \
--src-ip-ranges 10.100.100.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
Crie o anexo de serviço e anote o URI dele para configurar o endpoint do PSC na próxima seção.
No Cloud Shell
gcloud compute service-attachments create producer-sa \
--region=$region \
--producer-forwarding-rule=psc-service-fr \
--connection-preference=ACCEPT_MANUAL \
--consumer-accept-list=$projectid=5 \
--nat-subnets=psc-nat-subnet
No Cloud Shell
gcloud compute service-attachments describe producer-sa --region=$region
Exemplo de saída
connectionPreference: ACCEPT_MANUAL consumerAcceptLists: - connectionLimit: 5 projectIdOrNum: $projectid creationTimestamp: '2025-04-24T11:23:09.886-07:00' description: '' enableProxyProtocol: false fingerprint: xxx id: 'xxx' kind: compute#serviceAttachment name: producer-sa natSubnets: - https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/psc-nat-subnet pscServiceAttachmentId: high: 'xxx' low: 'xxx' reconcileConnections: false region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/serviceAttachments/producer-sa targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/forwardingRules/psc-service-fr
12. Conectar o endpoint do consumidor do PSC "test" ao serviço do produtor e ao teste (atividade do consumidor)
A arquitetura agora está no estado 2.
Neste ponto, o serviço do produtor exposto pelo peering de VPC ainda está ativo e funcionando corretamente em um cenário de produção. Vamos criar um endpoint de PSC de "teste" para garantir que o anexo de serviço exposto esteja funcionando corretamente antes de iniciar um período de interrupção para migrar a sub-rede de peering de VPC atual para a VPC do consumidor. A conectividade do estado final será um endpoint do PSC com o mesmo endereço IP da regra de encaminhamento atual para o serviço baseado em peering de VPC.
Criar endpoint do PSC
No Cloud Shell
gcloud compute addresses create test-psc-endpoint-ip \
--region=$region \
--subnet=consumer-vm-subnet \
--addresses 10.0.1.3
O serviço de destino abaixo será o URI do anexo de serviço que você anotou na última etapa.
No Cloud Shell
gcloud compute forwarding-rules create test-psc-endpoint \ --region=$region \ --network=consumer-vpc \ --address=test-psc-endpoint-ip \ --target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
Testar o endpoint do PSC "test"
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
De um cliente consumidor
curl 10.0.1.3
Resposta esperada
I am a Producer Service.
De um cliente consumidor
exit
13. Migrar a sub-rede da regra de encaminhamento do produtor atual
A execução dessas etapas vai iniciar uma interrupção no serviço de produtor baseado em peering de VPC ativo. Agora vamos migrar a sub-rede da regra de encaminhamento da VPC do produtor para a VPC do consumidor usando a API Internal Ranges. Isso impede que a sub-rede seja usada no período intermediário em que a excluímos na VPC do produtor e a designamos apenas para fins de migração para criação na VPC do consumidor.
A API de intervalo interno exige que você reserve a sub-rede da regra de encaminhamento de peering de VPC (producer-fr-subnet, 192.168.0.0/28) e designe um nome de sub-rede de destino na consumer-vpc (consumer-psc-subnet). Vamos criar uma sub-rede na consumer-vpc com esse nome em algumas etapas.
Reservar a sub-rede producer-fr para migração
Atividade do produtor
No Cloud Shell
gcloud network-connectivity internal-ranges create producer-peering-internal-range \
--ip-cidr-range=192.168.0.0/28 \
--network=producer-vpc \
--usage=FOR_MIGRATION \
--migration-source=projects/$projectid/regions/$region/subnetworks/producer-fr-subnet \
--migration-target=projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
Execute uma descrição no intervalo interno que criamos para conferir o estado da sub-rede.
Atividade do produtor
No Cloud Shell
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
Exemplo de saída
createTime: '2025-04-24T19:26:10.589343291Z' ipCidrRange: 192.168.0.0/28 migration: source: projects/$projectid/regions/$region/subnetworks/producer-fr-subnet target: projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet name: projects/$projectid/locations/global/internalRanges/producer-peering-internal-range network: https://www.googleapis.com/compute/v1/projects/$project/global/networks/producer-vpc peering: FOR_SELF updateTime: '2025-04-24T19:26:11.521960016Z' usage: FOR_MIGRATION
Excluir a regra de encaminhamento e a sub-rede com base no peering de VPC
Atividade do produtor
No Cloud Shell
gcloud compute forwarding-rules delete producer-fr --region=$region gcloud compute addresses delete producer-fr-ip --region=$region gcloud compute networks subnets delete producer-fr-subnet --region=$region
Migrar a sub-rede
Migre a sub-rede para a VPC do consumidor criando uma nova sub-rede usando o intervalo interno criado anteriormente. O nome dessa sub-rede precisa ser o mesmo que segmentamos anteriormente (consumer-psc-subnet). O propósito específico de PEER_MIGRATION indica que a sub-rede está reservada para migração entre VPCs com peering. Com essa flag de finalidade, a sub-rede só pode conter endereços IP estáticos reservados e endpoints do PSC.
Atividade do consumidor
No Cloud Shell
gcloud compute networks subnets create consumer-psc-subnet \ --purpose=PEER_MIGRATION \ --network=consumer-vpc \ --range=192.168.0.0/28 \ --region=$region
14. Criar o endpoint do PSC de estado final (atividade do consumidor)
Nesse ponto, o serviço do produtor ainda está inativo. A sub-rede que acabamos de criar ainda está bloqueada e só pode ser usada para a finalidade específica da migração. Para testar, tente criar uma VM nessa sub-rede. A criação da VM vai falhar.
No Cloud Shell
gcloud compute instances create test-consumer-vm \
--zone=$zone \
--subnet=consumer-psc-subnet \
--no-address
Resposta esperada
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
Só podemos usar essa sub-rede para criar um endpoint do PSC. O endereço IP que criamos usa o mesmo IP da regra de encaminhamento que nosso serviço de produtor usou no peering de VPC.
No Cloud Shell
gcloud compute addresses create psc-endpoint-ip \
--region=$region \
--subnet=consumer-psc-subnet \
--addresses 192.168.0.2
Mais uma vez, use o mesmo URI de vinculação de serviço que você anotou antes e que também foi usado para criar o endpoint do PSC "test".
No Cloud Shell
gcloud compute forwarding-rules create psc-endpoint \
--region=$region \
--network=consumer-vpc \
--address=psc-endpoint-ip \
--target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
15. Testar o endpoint do PSC de estado final (atividade do consumidor)
Neste ponto, você está na arquitetura do estado 3.
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da VM cliente do consumidor
curl service.example.com
Resposta esperada
I am a Producer Service.
Da VM cliente do consumidor
exit
Nesse momento, a interrupção do serviço terminou e o serviço está ativo novamente. Não foi necessário fazer mudanças no DNS atual. Nenhuma mudança no cliente do lado do consumidor precisa ser feita. Os aplicativos podem apenas retomar as operações para o serviço migrado.
16. Limpeza da migração
Para finalizar a migração, precisamos realizar algumas etapas de limpeza. Precisamos excluir e desbloquear recursos.
Desbloquear a sub-rede de intervalo interno
Isso vai desbloquear a sub-rede migrada para que a finalidade dela possa ser alterada de "PEER_MIGRATION" para "PRIVATE".
Atividade do produtor
No Cloud Shell
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Atividade do consumidor
No Cloud Shell
gcloud compute networks subnets update consumer-psc-subnet \
--region=$region \
--purpose=PRIVATE
gcloud compute networks subnets describe consumer-psc-subnet --region=$region
Exemplo de saída
creationTimestamp: '2025-04-24T12:29:33.883-07:00' fingerprint: xxx gatewayAddress: 192.168.0.1 id: 'xxx' ipCidrRange: 192.168.0.0/28 kind: compute#subnetwork name: consumer-psc-subnet network: https://www.googleapis.com/compute/v1/projects/$projectid/global/networks/consumer-vpc privateIpGoogleAccess: false privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS purpose: PRIVATE region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
Excluir os peers de VPC
Atividade do produtor
No Cloud Shell
gcloud compute networks peerings delete producer-vpc-peering \
--network=producer-vpc
Atividade do consumidor
No Cloud Shell
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
Excluir o endpoint do PSC "test"
Consumer-Activity
No Cloud Shell
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. Teste final após a limpeza da migração (atividade do consumidor)
Nesse ponto, a arquitetura do estado 4 (o estado final) foi alcançada.
Teste a conectividade do endpoint do PSC novamente para garantir que não haja efeitos adversos devido à limpeza da migração.
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da VM cliente do consumidor
curl service.example.com
Resposta esperada
I am a Producer Service.
Da VM cliente do consumidor
exit
SUCCESS!
18. Etapas de limpeza
No Cloud Shell
gcloud compute forwarding-rules delete psc-endpoint --region=$region -q gcloud compute addresses delete psc-endpoint-ip --region=$region -q gcloud compute instances delete consumer-client --zone=$zone --project=$projectid -q gcloud dns record-sets delete service.example.com --zone="producer-service" --type=A -q gcloud dns managed-zones delete "producer-service" -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy consumer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy --name=network-consumer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q gcloud compute networks subnets delete consumer-psc-subnet --region=$region -q gcloud compute networks subnets delete consumer-vm-subnet --region=$region -q gcloud compute networks delete consumer-vpc -q gcloud compute service-attachments delete producer-sa --region=$region -q gcloud compute forwarding-rules delete psc-service-fr --region=$region -q gcloud compute addresses delete producer-psc-ip --region=$region -q gcloud compute backend-services delete producer-bes --region=$region -q gcloud compute health-checks delete producer-hc --region=$region -q gcloud compute instance-groups unmanaged delete prod-uig --zone=$zone -q gcloud compute instances delete producer-service-vm --zone=$zone --project=$projectid -q gcloud compute network-firewall-policies rules delete 3000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy --name=network-producer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete producer-vpc-policy --global -q gcloud compute routers nats delete $region-nat --router=$region-cr --region=$region -q gcloud compute routers delete $region-cr --region=$region -q gcloud compute networks subnets delete psc-nat-subnet --region=$region -q gcloud compute networks subnets delete producer-psc-fr-subnet --region=$region -q gcloud compute networks subnets delete producer-service-subnet --region=$region -q gcloud compute networks delete producer-vpc -q
19. Parabéns!
Parabéns por concluir o codelab.
O que vimos
- Como configurar um serviço baseado em peering de VPC
- Como configurar um serviço baseado em PSC
- Usar a API Internal-Ranges para realizar a migração de sub-rede por peering de VPC e migrar um serviço de peering de VPC para PSC.
- Entender quando o tempo de inatividade precisa ocorrer para a migração de serviços
- Etapas de limpeza da migração