1. Introduction
L'appairage de VPC est une méthode courante permettant aux producteurs de proposer la consommation de services à leurs utilisateurs. Toutefois, l'utilisation de l'appairage de VPC entraîne de nombreuses complexités de routage, comme l'appairage de VPC non transitif, la forte consommation d'adresses IP 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 point de terminaison unique qu'un consommateur provisionne dans un VPC de charge de travail. Cela élimine de nombreux problèmes rencontrés par les utilisateurs avec l'appairage de réseaux VPC. Bien que de nombreux nouveaux services soient créés avec PSC, il existe encore de nombreux services qui sont des services d'appairage de réseaux VPC.
Google Cloud est heureux de vous présenter un chemin de migration pour les services que vous avez créés via l'appairage de VPC vers une architecture basée sur PSC. Avec cette méthode de migration, l'adresse IP du service de producteur exposé via l'appairage de VPC est conservée jusqu'à l'architecture basée sur PSC. Le consommateur n'a donc que très peu de modifications à apporter. Suivez cet atelier de programmation pour découvrir les étapes techniques à suivre pour effectuer cette migration.
REMARQUE : Ce chemin de migration ne concerne que les services dont le producteur et le consommateur existent dans la même organisation Google Cloud. Pour tous les services Google Cloud ou services tiers qui utilisent l'appairage de VPC, une méthode de migration similaire sera utilisée, mais elle sera personnalisée pour le service lui-même. Veuillez contacter les parties concernées pour en savoir plus sur le chemin de migration de ces types de services.
Points abordés
- Configurer un service basé sur l'appairage de réseaux VPC
- Configurer un service basé sur PSC
- Utiliser l'API Internal-Ranges pour migrer des sous-réseaux via l'appairage de VPC afin de migrer un service d'appairage de VPC vers PSC.
- Comprendre quand un temps d'arrêt est nécessaire pour la migration de service
- Étapes de nettoyage de la migration
Prérequis
- Projet Google Cloud avec des 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. Le codelab indiquera les actions à effectuer côté producteur et côté consommateur si les producteurs et les consommateurs 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. Le VPC du producteur disposera d'un service Apache simple exposé via un équilibreur de charge réseau passthrough interne. Le réseau VPC consommateur ne comportera qu'une seule VM consommateur à des fins de test.
L'état 2 correspond à l'état de test du PSC. Nous allons créer une règle de transfert et l'utiliser pour l'associer à notre rattachement de service. Nous allons ensuite créer un point de terminaison PSC de test dans consumer-vpc pour 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 producer-vpc où le service basé sur l'appairage de réseaux VPC a été déployé pour l'utiliser dans consumer-vpc. Nous allons ensuite créer 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 final du PSC. Nous allons nettoyer le point de terminaison PSC de test et supprimer l'appairage 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 configuré et configurez les variables.
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
Activez 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 un réseau VPC de producteur (activité du 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 et Cloud NAT pour le 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 et des règles de pare-feu pour le réseau de producteurs
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 permettre à IAP de 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 être accessible à l'aide d'IAP.
- Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise 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 règles supplémentaires qui autorisent les vérifications de l'état de l'équilibreur de charge sur le service, ainsi que le trafic réseau provenant des VM qui se connecteront à partir du VPC consommateur.
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 producteur (activité du producteur)
Nous allons créer un service de producteur avec une seule VM exécutant un serveur Web Apache qui sera ajouté à un groupe d'instances non géré, en façade d'un équilibreur de charge réseau passthrough 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 un réseau VPC 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 réseau et des règles de pare-feu pour les consommateurs
Nous allons créer une autre stratégie de pare-feu réseau pour le VPC consommateur.
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 consultant la liste des routes dans le VPC de consommateur. Vous devriez voir des routes pour consumer-vpc et producer-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é du consommateur)
Nous allons créer une zone privée Cloud DNS pour appeler le service de production via DNS plutôt que via une adresse IP privée, afin de présenter un exemple plus réaliste.
Nous allons ajouter un enregistrement A au service de pointage du domaine example.com vers l'adresse IP de la règle de transfert de l'équilibreur de charge réseau passthrough que nous avons créée précédemment. L'adresse IP de la 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 de producteur via l'appairage de VPC (activité du consommateur)
L'architecture de l'état 1 est désormais créée.
Créer une VM cliente consommateur
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 cliente grand public
curl service.example.com
Résultat attendu
I am a Producer Service.
Depuis la VM cliente grand public
exit
11. Préparer un service pour Private Service Connect (activité du producteur)
Maintenant que nous avons terminé toutes les étapes de configuration initiale, nous allons commencer à préparer le service avec peering VPC pour la migration vers Private Service Connect. Dans cette section, nous allons apporter des modifications au VPC du producteur en configurant le service pour qu'il soit exposé via un rattachement de service. Nous devrons créer un sous-réseau et une règle de transfert dans ce sous-réseau afin de pouvoir migrer le sous-réseau existant vers le VPC consommateur et conserver l'adresse IP existante du service.
Créez le sous-réseau dans lequel l'adresse IP de la nouvelle 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 que nous avons 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 à des fins de traduction d'adresse réseau. Pour les cas d'utilisation en production, ce sous-réseau doit être dimensionné de manière appropriée pour prendre en charge le nombre de points de terminaison associés. Pour en savoir plus, consultez la documentation sur le dimensionnement des sous-réseaux PSC NAT.
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 réseau pour autoriser le trafic provenant du sous-réseau psc-nat-subnet. Lorsque vous accédez au service via PSC, le trafic est généré à partir du sous-réseau NAT PSC.
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 son URI 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 client "test" au service producteur et tester (activité client)
L'architecture est désormais à l'état 2.
À ce stade, le service de producteur existant exposé via l'appairage de réseaux VPC est toujours actif et fonctionne correctement dans un scénario de production. Nous allons créer un point de terminaison PSC de 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 consommateur. Notre connectivité finale sera un point de terminaison PSC avec 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 correspond à 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
Depuis un client consommateur
curl 10.0.1.3
Résultat attendu
I am a Producer Service.
Depuis un client consommateur
exit
13. Migrer le sous-réseau de la règle de transfert du producteur existant
En effectuant ces étapes, vous provoquerez une indisponibilité du service producteur basé sur l'appairage de réseaux VPC en direct. Nous allons maintenant migrer le sous-réseau de la règle de transfert du VPC du producteur vers le VPC du consommateur à l'aide de l'API Internal Ranges. Cela empêchera le sous-réseau d'être utilisé pendant la période intermédiaire où nous le supprimerons du VPC du producteur et le désignerons uniquement à des fins de migration pour la création dans le VPC du consommateur.
L'API de plage interne exige que vous réserviez le sous-réseau de règle de transfert d'appairage VPC existant (producer-fr-subnet, 192.168.0.0/28) et que vous désigniez un nom de sous-réseau cible dans le VPC consommateur (consumer-psc-subnet). Nous allons créer un sous-réseau dans le consumer-vpc avec ce nom en quelques étapes.
Réserver le sous-réseau producer-fr 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 de 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 et le sous-réseau basés sur l'appairage de VPC
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 le VPC consommateur en créant un 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 le même que celui 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 cet indicateur 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 de l'état final (activité du consommateur)
À ce stade, le service Producer est toujours indisponible. Le sous-réseau que nous venons de créer est toujours verrouillé et ne peut être utilisé que pour la migration. Pour le vérifier, essayez 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
Une fois de plus, vous devez utiliser le même URI de rattachement de service que celui 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 de l'état final (activité du consommateur)
À ce stade, vous vous trouvez dans l'architecture de l'état 3.
Depuis Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Depuis la VM cliente grand public
curl service.example.com
Résultat attendu
I am a Producer Service.
Depuis la VM cliente grand public
exit
À ce stade, la panne est terminée et le service est à nouveau opérationnel. Notez que nous n'avons pas eu à modifier le DNS existant. Aucune modification n'est nécessaire côté client. Les applications peuvent simplement reprendre leurs opérations vers le service migré.
16. Nettoyage de la migration
Pour finaliser la migration, nous devons effectuer quelques étapes de nettoyage. Nous devons supprimer et déverrouiller les ressources.
Déverrouiller le sous-réseau de la plage interne
Cette action déverrouille le sous-réseau migré afin que son objectif puisse être modifié 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"
Consumer-Activity
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)
L'architecture de l'état 4 (l'état final) est alors atteinte.
Testez à nouveau la connectivité du point de terminaison PSC pour vous assurer qu'aucun effet indésirable n'est observé après le nettoyage de la migration.
Depuis Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Depuis la VM cliente grand public
curl service.example.com
Résultat attendu
I am a Producer Service.
Depuis la VM cliente grand public
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 réseaux VPC
- Configurer un service basé sur PSC
- Utiliser l'API Internal-Ranges pour migrer des sous-réseaux via l'appairage de VPC afin de migrer un service d'appairage de VPC vers PSC.
- Comprendre quand un temps d'arrêt est nécessaire pour la migration de service
- Étapes de nettoyage de la migration