1. Introduction
L'appairage de VPC est une méthode courante utilisée par les producteurs pour proposer la consommation de services à leurs utilisateurs. Cependant, l'utilisation de l'appairage VPC s'accompagne de nombreuses complexités liées au routage, telles que l'appairage de VPC non transitif, la consommation d'adresses IP volumineuses et la surexposition des ressources dans un VPC appairé.
Private Service Connect (PSC) est une méthode de connectivité qui permet aux producteurs d'exposer un service sur un seul point de terminaison qu'un client provisionne dans un VPC de charge de travail. Cela élimine de nombreux problèmes rencontrés par les utilisateurs avec l'appairage de VPC. Bien que de nombreux services soient créés avec PSC, de nombreux services existent encore en tant que services d'appairage de VPC.
Google Cloud est heureux de vous présenter un processus de migration pour les services que vous avez créés via l'appairage de VPC afin de passer à une architecture PSC. Avec cette méthode de migration, l'adresse IP du service producteur exposé via l'appairage de VPC est conservée dans l'architecture basée sur PSC, de sorte que les modifications requises soient minimes pour le client. Suivez cet atelier de programmation pour connaître les étapes techniques permettant d'effectuer cette migration.
REMARQUE: Ce chemin de migration ne concerne que les services pour lesquels le producteur et le client existent dans la même organisation Google Cloud. Les services Google Cloud ou les services tiers qui utilisent l'appairage de VPC utiliseront une méthode de migration similaire, mais celle-ci sera personnalisée pour le service lui-même. Pour en savoir plus sur le processus de migration pour ce type de services, veuillez contacter les personnes concernées.
Points abordés
- Configurer un service basé sur l'appairage de VPC
- Configurer un service basé sur PSC
- Effectuer une migration de sous-réseau via l'appairage de VPC à l'aide de l'API Internal-Ranges afin de migrer l'appairage VPC vers le service PSC
- Comprendre quand un temps d'arrêt doit se produire pour la migration de services
- Étapes de nettoyage de la migration
Prérequis
- Projet Google Cloud avec autorisations de propriétaire
2. Topologie de l'atelier de programmation
Par souci de simplicité, cet atelier de programmation centralise toutes les ressources dans un seul projet. Cet atelier de programmation indiquera les actions à effectuer côté producteur et celles à effectuer côté consommateur si le producteur et le consommateur se trouvent dans des projets différents.
Cet atelier de programmation comporte quatre états.
L'état 1 correspond à l'état de l'appairage de VPC. Deux VPC, "consumer-vpc" et "producer-vpc", seront appairés. Producer-vpc disposera d'un service Apache simple exposé via un équilibreur de charge réseau passthrough interne. Consumer-vpc disposera d'une seule consumer-vm à des fins de test.
L'état 2 est l'état de test PSC. Nous allons créer une règle de transfert et l'associer à notre rattachement de service. Nous créerons ensuite un point de terminaison PSC de test dans "consumer-vpc" afin de vérifier que notre service PSC fonctionne comme prévu.
L'état 3 correspond à l'état de migration. Nous allons réserver la plage de sous-réseau dans "producteur-vpc" où le service basé sur l'appairage de VPC a été déployé pour être utilisé dans le VPC "consumer-vpc". Nous créerons ensuite un point de terminaison PSC avec la même adresse IP que la règle de transfert préexistante dans producer-vpc.
L'état 4 est l'état PSC final. Nous allons nettoyer le point de terminaison PSC de test et supprimer l'appairage de VPC entre consumer-vpc et producer-vpc.
3. Préparation
Configuration de l'environnement au rythme de chacun
- Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. Si vous n'avez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.
- Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pourrez toujours le modifier.
- L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par
PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet. - Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
- Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.
Démarrer Cloud Shell
Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.
Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :
Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :
Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.
4. Avant de commencer
Activer les API
Dans Cloud Shell, assurez-vous que votre projet est bien configuré et que les variables sont configurées.
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
Activer tous les services nécessaires
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Créer le réseau VPC du producteur (activité de producteur)
Réseau VPC
Depuis Cloud Shell
gcloud compute networks create producer-vpc \
--subnet-mode=custom
Créer des sous-réseaux
Depuis 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
Créer un routeur Cloud Router et un Cloud NAT de producteur
Depuis 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
Créer une stratégie de pare-feu de réseau et des règles de pare-feu de producteur
Depuis 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
Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui:
- S'applique à toutes les instances de VM auxquelles vous souhaitez rendre accessibles à l'aide d'IAP.
- Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP pour le transfert TCP.
Depuis 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
Nous allons également créer deux autres règles qui autorisent les vérifications de l'état de l'équilibreur de charge vers le service et autoriseront le trafic réseau provenant de VM qui se connecteront depuis "consumer-vpc".
Depuis 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. Configuration du service de producteur (activité de producteur)
Nous allons créer un service producteur avec une VM unique exécutant un serveur Web Apache. Ce service sera ajouté à un groupe d'instances non géré doté d'un équilibreur de charge Passthrough réseau interne régional.
Créer la VM et le groupe d'instances non géré
Depuis 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'
Depuis 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
Créer l'équilibreur de charge réseau passthrough interne régional
Depuis 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. Créer le réseau VPC du consommateur (activité du consommateur)
Réseau VPC
Depuis Cloud Shell
gcloud compute networks create consumer-vpc \
--subnet-mode=custom
Créer un sous-réseau
Depuis Cloud Shell
gcloud compute networks subnets create consumer-vm-subnet \
--network=consumer-vpc \
--range=10.0.1.0/28 \
--region=$region
Créer une stratégie de pare-feu de réseau consommateur et des règles de pare-feu
Nous allons créer une autre règle de pare-feu réseau pour "consumer-vpc".
Depuis 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. Créer un pair VPC
Activité du producteur
Depuis Cloud Shell
gcloud compute networks peerings create producer-vpc-peering \
--network=producer-vpc \
--peer-project=$projectid \
--peer-network=consumer-vpc
Activité des consommateurs
Depuis Cloud Shell
gcloud compute networks peerings create consumer-vpc-peering \
--network=consumer-vpc \
--peer-project=$projectid \
--peer-network=producer-vpc
Vérifiez que l'appairage est établi en vérifiant la liste des routes dans le VPC "consumer-vpc". Les routes s'affichent normalement pour "consumer-vpc" et "product-vpc".
Activité des consommateurs
Depuis Cloud Shell
gcloud compute routes list --filter="network=consumer-vpc"
Résultat attendu
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. Créer une zone DNS (activité client)
Pour illustrer un exemple plus réaliste, nous allons créer une zone privée Cloud DNS pour appeler le service producteur via DNS plutôt que via une adresse IP privée.
Nous allons ajouter un enregistrement A au domaine example.com qui pointe service.example.com vers l'adresse IP de la règle de transfert de l'équilibreur de charge passthrough réseau que nous avons créée précédemment. Cette adresse IP de règle de transfert est 192.168.0.2.
Depuis 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. Tester le service producteur via un pair VPC (activité du consommateur)
À ce stade, l'architecture State 1 a été créée.
Créer la VM consommateur-client
Depuis Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Tester la connectivité
Depuis Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Depuis la VM consommateur-client
curl service.example.com
Résultat attendu
I am a Producer Service.
Depuis la VM consommateur-client
exit
11. Préparer le service pour Private Service Connect (activité de producteur)
Maintenant que nous avons terminé toutes les étapes de configuration initiales, nous allons commencer à préparer le service appairé par VPC pour la migration vers Private Service Connect. Dans cette section, nous allons modifier le VPC "producteur" en configurant le service à exposer via un rattachement de service. Nous devons créer un nouveau sous-réseau et une nouvelle règle de transfert au sein de ce sous-réseau afin de pouvoir migrer le sous-réseau existant vers consumer-vpc et conserver l'adresse IP existante du service intacte.
Créez le sous-réseau dans lequel la nouvelle adresse IP de la règle de transfert de l'équilibreur de charge sera hébergée.
Depuis Cloud Shell
gcloud compute networks subnets create producer-psc-fr-subnet \
--network=producer-vpc \
--range=10.0.2.64/28 \
--region=$region
Créez l'adresse IP interne de la règle de transfert de l'équilibreur de charge.
Depuis Cloud Shell
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
Créez la règle de transfert de l'équilibreur de charge. Cette règle est configurée pour utiliser le même service de backend et les mêmes vérifications d'état que ceux configurés précédemment.
Depuis 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
Le sous-réseau psc-nat-subnet sera associé au rattachement de service PSC pour la traduction des adresses réseau. Pour les cas d'utilisation en production, ce sous-réseau doit être dimensionné de manière appropriée pour pouvoir gérer le nombre de points de terminaison connectés. Pour en savoir plus, consultez la documentation sur le dimensionnement du sous-réseau NAT PSC.
Depuis 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
Nous devons ajouter une règle de pare-feu supplémentaire à la stratégie de pare-feu du réseau pour autoriser le trafic provenant du sous-réseau psc-nat-subnet. Lorsque vous accédez au service via PSC, le sous-réseau psc-nat-subnet est la source du trafic.
Depuis 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
Créez le rattachement de service et notez l'URI du rattachement de service pour configurer le point de terminaison PSC dans la section suivante.
Depuis 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
Depuis Cloud Shell
gcloud compute service-attachments describe producer-sa --region=$region
Exemple de résultat
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. Connecter le point de terminaison PSC du client "test" au service Producer et effectuer un test (activité du consommateur)
L'architecture est maintenant à l'état 2.
À ce stade, le service producteur existant exposé via l'appairage de VPC est toujours actif et fonctionne correctement dans un scénario de production. Nous allons créer un point de terminaison PSC "test" pour nous assurer que le rattachement de service exposé fonctionne correctement avant de lancer une période d'indisponibilité pour migrer le sous-réseau d'appairage de VPC actuel vers le VPC du client. La connectivité à l'état final sera un point de terminaison PSC possédant la même adresse IP que la règle de transfert actuelle pour le service basé sur l'appairage de VPC.
Créer un point de terminaison PSC
Depuis Cloud Shell
gcloud compute addresses create test-psc-endpoint-ip \
--region=$region \
--subnet=consumer-vm-subnet \
--addresses 10.0.1.3
Le service cible ci-dessous sera l'URI du rattachement de service que vous avez noté à la dernière étape.
Depuis 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
Tester le point de terminaison PSC "test"
Depuis Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Du consommateur-client
curl 10.0.1.3
Résultat attendu
I am a Producer Service.
Du consommateur-client
exit
13. Migrer le sous-réseau de règle de transfert du producteur existant
Ces étapes entraîneront l'indisponibilité du service de producteur basé sur l'appairage de VPC en direct. Nous allons maintenant migrer le sous-réseau de règle de transfert de "producer-vpc" vers "consumer-vpc" à l'aide de l'API Internal Ranges. Cela empêchera l'utilisation du sous-réseau pendant la période provisoire lorsque nous supprimerons le sous-réseau dans le VPC "producteur" et le désignerons uniquement à des fins de migration pour la création dans le VPC "consumer-vpc".
L'API de plage interne nécessite que vous réserviez le sous-réseau existant de la règle de transfert d'appairage de VPC (producer-fr-subnet, 192.168.0.0/28) et que vous désignez un nom de sous-réseau cible dans le VPC "consumer-vpc" (consumer-psc-subnet). Nous allons créer un sous-réseau portant ce nom dans le VPC "consumer-vpc" en quelques étapes.
Réserver le sous-réseau producer-fr-subnet pour la migration
Activité du producteur
Depuis 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
Exécutez une description sur la plage interne que nous avons créée pour afficher l'état du sous-réseau.
Activité du producteur
Depuis Cloud Shell
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
Exemple de résultat
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
Supprimer la règle de transfert basée sur l'appairage de VPC et le sous-réseau
Activité du producteur
Depuis 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
Migrer le sous-réseau
Migrez le sous-réseau vers "consumer-vpc" en créant un nouveau sous-réseau à l'aide de la plage interne que nous avons créée précédemment. Le nom de ce sous-réseau doit être identique au nom que nous avons ciblé précédemment (consumer-psc-subnet). L'objectif spécifique de PEER_MIGRATION indique que le sous-réseau est réservé à la migration de sous-réseau entre les VPC appairés. Avec cette option d'objectif, ce sous-réseau ne peut contenir que des adresses IP statiques réservées et des points de terminaison PSC.
Activité des consommateurs
Depuis 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. Créer le point de terminaison PSC à l'état final (activité du consommateur)
À ce stade, le service Producer est toujours en panne. Le sous-réseau que nous venons de créer est toujours verrouillé et ne peut être utilisé que dans le cadre spécifique de la migration. Vous pouvez tester cela en essayant de créer une VM dans ce sous-réseau. La création de la VM échouera.
Depuis Cloud Shell
gcloud compute instances create test-consumer-vm \
--zone=$zone \
--subnet=consumer-psc-subnet \
--no-address
Résultat attendu
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
Nous ne pouvons utiliser ce sous-réseau que pour créer un point de terminaison PSC. Notez que l'adresse IP que nous créons utilise la même adresse IP que la règle de transfert utilisée par notre service producteur sur le pair VPC.
Depuis Cloud Shell
gcloud compute addresses create psc-endpoint-ip \
--region=$region \
--subnet=consumer-psc-subnet \
--addresses 192.168.0.2
Là encore, vous devez utiliser le même URI de rattachement de service que vous avez noté précédemment et qui a également été utilisé pour créer le point de terminaison PSC "test".
Depuis 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. Tester le point de terminaison PSC à l'état final (activité du consommateur)
À ce stade, vous vous trouvez dans l'architecture State 3.
Depuis Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Depuis la VM consommateur-client
curl service.example.com
Résultat attendu
I am a Producer Service.
Depuis la VM consommateur-client
exit
À ce stade, l'indisponibilité a pris fin et le service est de nouveau opérationnel. Notez que nous n'avons pas eu à modifier le DNS existant. Aucune modification du client côté consommateur n'est nécessaire. Les applications peuvent simplement reprendre les opérations sur le service migré.
16. Nettoyage de la migration
Pour finaliser la migration, nous devons effectuer quelques opérations de nettoyage. Nous devons supprimer et déverrouiller des ressources.
Déverrouiller le sous-réseau de plage interne
Le sous-réseau migré sera ainsi déverrouillé afin que son objectif puisse passer de "PEER_MIGRATION" à "PRIVATE".
Activité du producteur
Depuis Cloud Shell
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Activité des consommateurs
Depuis Cloud Shell
gcloud compute networks subnets update consumer-psc-subnet \
--region=$region \
--purpose=PRIVATE
gcloud compute networks subnets describe consumer-psc-subnet --region=$region
Exemple de résultat
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
Supprimer les pairs VPC
Activité du producteur
Depuis Cloud Shell
gcloud compute networks peerings delete producer-vpc-peering \
--network=producer-vpc
Activité des consommateurs
Depuis Cloud Shell
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
Supprimer le point de terminaison PSC "test"
Activité-consommateur
Depuis Cloud Shell
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. Test final après le nettoyage de la migration (activité du consommateur)
À ce stade, l'architecture de l'état 4 (état final) a été atteinte.
Testez à nouveau la connectivité du point de terminaison PSC pour vous assurer qu'aucun effet négatif n'est observé lors du nettoyage de la migration.
Depuis Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Depuis la VM consommateur-client
curl service.example.com
Résultat attendu
I am a Producer Service.
Depuis la VM consommateur-client
exit
OPÉRATION RÉUSSIE !
18. Étapes de nettoyage
Depuis 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. Félicitations !
Bravo ! Vous avez terminé cet atelier de programmation.
Points abordés
- Configurer un service basé sur l'appairage de VPC
- Configurer un service basé sur PSC
- Effectuer une migration de sous-réseau via l'appairage de VPC à l'aide de l'API Internal-Ranges afin de migrer l'appairage VPC vers le service PSC
- Comprendre quand un temps d'arrêt doit se produire pour la migration de services
- Étapes de nettoyage de la migration