1. Introduction
Avec Private Service Connect, vous pouvez créer des points de terminaison privés à l'aide d'adresses IP internes globales dans votre réseau VPC pour accéder aux API Google. Vous pouvez attribuer à ces adresses IP internes des noms pertinents, tels que storage-pscendpoint.p.googleapis.com et bigtable-adsteam.p.googleapis.com. Au lieu d'envoyer des requêtes API à des points de terminaison de service publics tels que storage.googleapis.com, vous pouvez les envoyer au point de terminaison Private Service Connect, qui est privé et interne à votre réseau VPC.
Ces noms et adresses IP sont internes à votre réseau VPC et à tous les réseaux sur site qui y sont connectés à l'aide de tunnels Cloud VPN ou de rattachements Cloud Interconnect (VLAN).
Vous pouvez contrôler le trafic et décider de son point de terminaison, puis démontrer que le trafic reste au sein de Google Cloud.
Points abordés
- Cas d'utilisation de Private Service Connect
- Configuration réseau requise
- API compatibles
- Créer un point de terminaison Private Service Connect
- Créer un bucket Cloud Storage
- Créer et mettre à jour des zones privées Cloud DNS
- Créer une passerelle NAT pour accéder aux API Google publiques
- Créer et mettre à jour un fichier de configuration BOTO
- Exécuter la commande gsutil list sur la VM1 résolue par rapport à votre point de terminaison de service PSC
- Exécuter la commande gsutil list sur VM2 résolue par rapport à googleapis.com public
- Utiliser Tcpdump pour valider la résolution DNS
Prérequis
- Connaissance de DNS, de l'éditeur nano ou vi
2. Cas d'utilisation de Private Service Connect
Vous pouvez créer plusieurs points de terminaison Private Service Connect dans le même réseau VPC. Aucune limite ne s'applique à la bande passante d'un point de terminaison spécifique. Étant donné que les points de terminaison Private Service Connect utilisent des adresses IP internes globales, ils peuvent être utilisés par n'importe quelle ressource de votre réseau VPC.
Avec plusieurs points de terminaison, vous pouvez spécifier différents chemins d'accès réseau à l'aide de Cloud Router et de règles de pare-feu.
- Vous pouvez créer des règles de pare-feu pour empêcher certaines VM d'accéder aux API Google via un point de terminaison Private Service Connect, tout en autorisant l'accès à d'autres VM.
- Une règle de pare-feu peut être définie sur une instance de VM qui interdit tout le trafic vers Internet. Le trafic envoyé aux points de terminaison Private Service Connect est toujours acheminé vers Google.
- Si vous disposez d'hôtes sur site connectés à un VPC à l'aide d'un tunnel Cloud VPN ou d'un rattachement Cloud Interconnect (VLAN), vous pouvez envoyer des requêtes via le tunnel ou le VLAN en envoyant d'autres demandes via le réseau Internet public. Cette configuration vous permet de contourner le tunnel ou le VLAN pour les services tels que Google Livres qui ne sont pas compatibles avec l'accès privé à Google. Pour mettre en place cette configuration, créez un point de terminaison Private Service Connect, annoncez les adresses IP du point de terminaison Private Service Connect à l'aide d'annonces de routage personnalisées Cloud Router et activez une règle de transfert entrant Cloud DNS. L'application peut envoyer des requêtes via le tunnel Cloud VPN ou un rattachement Cloud Interconnect (VLAN) en utilisant le nom du point de terminaison Private Service Connect, ainsi que d'autres via Internet à l'aide du nom DNS par défaut.
- Si vous connectez votre réseau sur site à votre réseau VPC à l'aide de plusieurs rattachements Cloud Interconnect (VLAN), vous pouvez envoyer du trafic provenant d'un réseau sur site via un VLAN et le reste via d'autres, comme l'indique la figure 2. Vous pouvez ainsi utiliser votre propre réseau étendu plutôt que celui de Google, et contrôler le déplacement des données afin de répondre aux exigences géographiques. Pour créer cette configuration, créez deux points de terminaison Private Service Connect. Créez une annonce de routage personnalisée pour le premier point de terminaison sur la session BGP du routeur cloud gérant le premier VLAN, puis créez une annonce de routage personnalisée différente pour le deuxième point de terminaison sur la session BGP du routeur cloud gérant le deuxième VLAN. Les hôtes sur site configurés pour utiliser le nom du point de terminaison Private Service Connect envoient le trafic au rattachement Cloud Interconnect correspondant (VLAN).
- Vous pouvez également utiliser plusieurs rattachements Cloud Interconnect (VLAN) dans une topologie active/active. Si vous annoncez la même adresse IP de point de terminaison Private Service Connect, à l'aide d'annonces de routage personnalisées pour les sessions BGP sur les routeurs cloud gérant les VLAN, les paquets envoyés depuis les systèmes sur site vers les points de terminaison sont acheminés via les VLAN à l'aide d'ECMP.

Figure 1. En configurant Private Service Connect, Cloud Router et les hôtes sur site, vous pouvez contrôler le rattachement Cloud Interconnect (VLAN) utilisé pour envoyer du trafic vers les API Google.
3. Configuration réseau requise
Pour utiliser Private Service Connect, l'interface principale des instances de machine virtuelle (VM) sans adresse IP externe doit se trouver dans un sous-réseau sur lequel l'accès privé à Google est activé.
Une VM avec une adresse IP externe peut accéder aux API et services Google à l'aide des points de terminaison Private Service Connect, que l'accès privé à Google soit activé ou non pour son sous-réseau. La connectivité au point de terminaison Private Service Connect reste dans le réseau de Google.
Les points de terminaison Private Service Connect ne sont pas accessibles à partir des réseaux VPC appairés.
API compatibles
Lorsque vous créez un point de terminaison Private Service Connect, vous choisissez le bundle d'API auquel vous avez besoin d'accéder : all-apis ou vpc-sc.
Les groupes d'API donnent accès aux mêmes API disponibles via les adresses IP virtuelles de l'Accès privé à Google.
- Le groupe "all-apis" permet d'accéder aux mêmes API que private.googleapis.com.
- Le groupe vpc-sc permet d'accéder aux mêmes API que restricted.googleapis.com.
4. Topologie et cas d'utilisation de l'atelier de programmation

Figure 1 : Topologie de l'atelier de programmation
Cas d'utilisation de l'atelier de programmation :
Notre client a besoin d'un accès mixte (interconnecté et public) à googleapis pour le transfert de données Cloud Storage. Pour répondre aux exigences de nos clients, nous allons déployer Private Service Connect, qui se compose d'une adresse /32 unique, d'une configuration BOTO et de mises à jour des enregistrements DNS. La machine virtuelle 1 utilisera PSC pour accéder au bucket de stockage cloud, tandis que la VM 2 utilisera les plages d'adresses IP googleapis.com publiques via la passerelle NAT.
Tous les aspects de l'atelier sont déployés dans Google Cloud Platform. Toutefois, le même cas d'utilisation s'applique au déploiement dans le cloud hybride nécessitant une séparation du trafic.
5. Préparation
Configuration de l'environnement d'auto-formation
- Connectez-vous à la console Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)



Mémorisez l'ID du projet. Il s'agit d'un nom unique permettant de différencier chaque projet Google Cloud (le nom ci-dessus est déjà pris ; vous devez en trouver un autre). Il sera désigné par le nom PROJECT_ID tout au long de cet atelier de programmation.
- Vous devez ensuite activer la facturation dans Cloud Console pour pouvoir utiliser les ressources Google Cloud.
L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Veillez à suivre les instructions de la section "Nettoyer" qui indique comment désactiver les ressources afin d'éviter les frais une fois ce tutoriel terminé. 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.
Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :

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 réaliser toutes les activités de cet atelier dans un simple navigateur.
6. Avant de commencer
Activer les API
Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname
Activez tous les services nécessaires.
gcloud services enable compute.googleapis.com gcloud services enable servicedirectory.googleapis.com gcloud services enable dns.googleapis.com
7. Créer un réseau VPC
Réseau VPC
Depuis Cloud Shell
gcloud compute networks create psc-lab --subnet-mode custom
Créer un sous-réseau
Depuis Cloud Shell
gcloud compute networks subnets create psclab-subnet \ --network psc-lab --range 10.0.0.0/24 --region us-central1 --enable-private-ip-google-access
Créer des règles de pare-feu
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 firewall-rules create psclab-ssh \
--network psc-lab --allow tcp:22 --source-ranges=35.235.240.0/20
Créer une instance Cloud NAT
Créer un routeur cloud
Depuis Cloud Shell
gcloud compute routers create crnat \
--network psc-lab \
--asn 65000 \
--region us-central1
Créer Cloud NAT
Depuis Cloud Shell
gcloud compute routers nats create cloudnat \
--router=crnat \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--enable-logging \
--region us-central1
8. Créer un point de terminaison Private Service Connect
Lorsque vous configurez l'adresse IP du point de terminaison Private Service Connect <pscendpointip>, vous devez fournir une adresse IP unique qui n'est pas définie dans votre VPC.
Depuis Cloud Shell
gcloud compute addresses create psc-ip \
--global \
--purpose=PRIVATE_SERVICE_CONNECT \
--addresses=192.168.255.250 \
--network=psc-lab
Stockez "pscendpointip" pendant toute la durée de l'atelier.
pscendpointip=$(gcloud compute addresses list --filter=name:psc-ip --format="value(address)") echo $pscendpointip
Créez une règle de transfert pour connecter le point de terminaison aux API et services Google.
Depuis Cloud Shell
gcloud compute forwarding-rules create pscendpoint \
--global \
--network=psc-lab \
--address=psc-ip \
--target-google-apis-bundle=all-apis
Lister les points de terminaison Private Service Connect configurés
Depuis Cloud Shell
gcloud compute forwarding-rules list \ --filter target="(all-apis OR vpc-sc)" --global
Décrire les points de terminaison Private Service Connect configurés
Depuis Cloud Shell
gcloud compute forwarding-rules describe \
pscendpoint --global
9. Créer un bucket
Créez un bucket Cloud Storage et remplacez BUCKET_NAME par un nom unique de votre choix.
Depuis Cloud Shell
gsutil mb -l us-central1 -b on gs://BUCKET_NAME
Stocker "BUCKET_NAME" pendant la durée de l'atelier
BUCKET_NAME=YOUR BUCKET NAME echo $BUCKET_NAME
10. Configuration DNS
Lorsque vous créez un point de terminaison Private Service Connect, l'annuaire de services génère un enregistrement DNS pour les API et les services rendus disponibles à l'aide de ce point de terminaison.
Les enregistrements DNS pointent vers l'adresse IP du point de terminaison Private Service Connect et sont au format suivant : SERVICE-ENDPOINT.p.googleapis.com.
Vous pouvez utiliser ces noms DNS dans vos requêtes API pour diriger la requête vers votre point de terminaison Private Service Connect. Vous pouvez également utiliser ces noms DNS dans l'en-tête "Host" de votre requête.
Si vous souhaitez utiliser un point de terminaison Private Service Connect avec un client ou une application qui accède aux API et aux services Google, mettez à jour votre client ou votre application de sorte qu'il utilise les noms DNS p.googleapis.com.
Pour en savoir plus, consultez la documentation de votre client ou bibliothèque cliente. Exemple :
- Python : vous pouvez configurer api_endpoint dans la classe d'options client du package google-api-core.
- Go : vous pouvez configurer WithEndpoint dans le package d'options client du package d'API.
- gcloud: You can configure api_endpoint_overrides using this command. gcloud config set api_endpoint_overrides/SERVICE ENDPOINT_URL
Par exemple : gcloud config set api_endpoint_overrides/storage https://storage-xyz.p.googleapis.com/storage/v1/
Si vous ne pouvez pas configurer votre client ou votre application pour utiliser un point de terminaison différent, créez des enregistrements DNS afin qu'ils correspondent aux noms DNS par défaut. Par exemple, storage.googleapis.com. Consultez Créer des enregistrements DNS à l'aide de noms DNS par défaut.
Valider l'enregistrement DNS
Dans la console Cloud, validez l'entrée DNS générée sous Services réseau → Cloud DNS. Notez le nom DNS généré "p.googleapis.com".
11. Créer des machines virtuelles
Créez la machine virtuelle (psc-instance-1) utilisée pour valider Private Service Connect.
Depuis Cloud Shell
gcloud compute instances create psc-instance-1 \
--subnet psclab-subnet \
--zone us-central1-a \
--image=centos-7-v20210122 \
--image-project=centos-cloud \
--no-address \
--metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y
Connectez-vous à l'instance de VM (psc-instance-1).
Se connecter en SSH à la VM via Cloud Shell
gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"
Créez trois terminaux Cloud Shell supplémentaires en cliquant sur + (capture d'écran ci-dessous).

Créer une machine virtuelle (psc-instance-2) utilisée pour valider les API Google publiques
Depuis l'onglet 2
gcloud compute instances create psc-instance-2 \
--subnet psclab-subnet \
--zone us-central1-a \
--image=centos-7-v20210122 \
--image-project=centos-cloud \
--no-address \
--metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y
Dans l'onglet 2, connectez-vous en SSH à la VM via Cloud Shell.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"
Dans l'onglet 3, connectez-vous à l'instance psc-instance-1 via SSH dans Cloud Shell.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"
Dans l'onglet 4, connectez-vous à psc-instance-2 via SSH dans Cloud Shell.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] projectname=YOUR-PROJECT-NAME echo $projectname gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"
12. Vérifier le comportement existant de Gsutil
Dans l'onglet 4 (psc-instance-2), démarrez tcpdump et surveillez le trafic DNS.
sudo tcpdump -vv -i eth0 port 53
Inspecter la résolution DNS du bucket de stockage depuis l'onglet 2 (psc-instance-2)
BUCKET_NAME=YOUR BUCKET NAME echo $BUCKET_NAME gsutil -D ls gs://$BUCKET_NAME
Inspecter le débogage gsutil, l'hôte storage.googleapis.com est utilisé pour la résolution DNS
<snip> send: 'GET /storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\nHost: storage.googleapis.com\r\ncontent-length: 0\r\nauthorization: Bearer ya29.c.KpkB7wfaMjfc_WXEKCeNF4Md0fEHnfDU7tqBf3cd0u43yEmYXqj8fX_X5wWdNdDVH6k1EkjeAeIJDzKGvyjPOkf1Io2kVeUqYX69sDv53huW1NslffjAHKchbZ0CP3Cg83TS3Pa55jLcuE0TLbYycVrgSbD3H90LaapUGbWD3kj4IsJLf9J8R98Bqobu8HZwwqk92hlZ4zVzRqOM\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\n\r\n' reply: 'HTTP/1.1 200 OK\r\n' <snip>
Dans l'onglet 4 (psc-instance-2), vérifiez que les enregistrements A DNS publics GoogleAPI.com sont utilisés pour accéder au bucket Storage.
metadata.google.internal.domain > psc-instance-2.c.yourprojectname.internal.33973: [udp sum ok] 36442 q: A? storage.googleapis.com. 11/0/0 storage.googleapis.com. A 108.177.111.128, storage.googleapis.com. A 142.250.128.128, storage.googleapis.com. A 74.125.70.128, storage.googleapis.com. A 74.125.201.128, storage.googleapis.com. A 64.233.183.128, storage.googleapis.com. A 173.194.198.128, storage.googleapis.com. A 172.217.219.128, storage.googleapis.com. A 142.250.136.128, storage.googleapis.com. A 209.85.234.128, storage.googleapis.com. A 172.217.212.128, storage.googleapis.com. A 172.217.214.128
13. Modifier le comportement de Gsutil
Rappelez-vous que, lors d'une étape précédente, vous avez créé une zone DNS privée et un enregistrement A mappé à l'adresse IP du point de terminaison PSC. Dans l'étape suivante, nous allons contrôler le comportement de gsutil en mettant à jour le fichier BOTO de la VM sur psc-instance-1.
Affichez la configuration BOTO par défaut à partir du terminal de l'instance de VM dans l'onglet 1 (psc-instance-1).
[psc-instance ~]$ more /etc/boto.cfg
Résultat (votre project_id sera différent)
[GSUtil] default_project_id = [your project number] default_api_version = 2 [GoogleCompute] service_account = default
Mettez à jour la configuration BOTO à l'aide de l'éditeur nano ou VI. Veillez à copier et coller toutes les entrées.
Exemple : sudo nano /etc/boto.cfg
ou
Exemple : sudo vi /etc/boto.cfg
Dans l'onglet du terminal de l'instance de VM 1(psc-instance-1)
[Credentials] gs_host = storage-pscendpoint.p.googleapis.com gs_host_header = storage.googleapis.com gs_json_host = storage-pscendpoint.p.googleapis.com gs_json_host_header = www.googleapis.com
Validez la configuration. L'ordre des [identifiants] est essentiel pour la recherche DNS.
more /etc/boto.cfg [Credentials] gs_host = storage-pscendpoint.p.googleapis.com gs_host_header = storage.googleapis.com gs_json_host = storage-pscendpoint.p.googleapis.com gs_json_host_header = www.googleapis.com [GSUtil] default_project_id = [your project number default_api_version = 2 [GoogleCompute] service_account = default
14. Vérifier le comportement de recherche gsutil mis à jour
Dans l'onglet 3 (psc-instance-1), démarrez tcpdump et surveillez le trafic DNS.
sudo tcpdump -vv -i eth0 port 53
Inspecter la recherche gsutil du bucket de stockage à partir de l'onglet 1 (psc-instance-1)
BUCKET_NAME=YOUR BUCKET NAME echo $BUCKET_NAME gsutil -D ls gs://$BUCKET_NAME
Les journaux de débogage confirment que le bucket de stockage est accessible via le point de terminaison Private Service Connect "pscendpoint".
Résultat :
<snip>
INFO 0131 22:14:18.795986 base_api.py] Making http GET to https://storage-pscendpoint.p.googleapis.com/storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000
INFO 0131 22:14:18.796415 base_api.py] Headers: {u'Host': 'www.googleapis.com',
'accept': 'application/json',
'accept-encoding': 'gzip, deflate',
'content-length': '0',
'user-agent': 'apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0'}
INFO 0131 22:14:18.796502 base_api.py] Body: (none)
connect: (storage-pscendpoint.p.googleapis.com, 443)
send: 'GET /storage/v1/b/psc-bucket/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\ncontent-length: 0\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\nhost: www.googleapis.com\r\nauthorization: Bearer ya29.c.KpkB7wd3XWiYeRyTuth5_HPlNV-hPwc2Nn7RSIeMpzrpa_j4EsMPl2m_mDGKAcGHvYIgiC5bT2UVQirAPpSbbpToa6G6lkaBbH5SZwHwgNXYfisp5Ww1UjXe4rTa69a_Wp0WesafcwPNnYzDo3xf5VGh3iGhySA04kTXuyT--MgOU8U-XLII2LJQxUWlV8KEdrvyCuqRb-jsDdk_\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
<snip>
Dans l'onglet 3 (psc-instance-1), vérifiez que l'adresse IP de votre point de terminaison PSC correspond à l'enregistrement DNS A utilisé lorsque vous essayez d'accéder à votre bucket de stockage.
@psc-instance-1 ~]$ sudo tcpdump -vv -i eth0 port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:02:33.936256 IP (tos 0x0, ttl 64, id 55416, offset 0, flags [DF], proto UDP (17), length 82)
psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0xcceb!] 34796+ A? storage-pscendpoint.p.googleapis.com. (54)
05:02:33.936269 IP (tos 0x0, ttl 64, id 55417, offset 0, flags [DF], proto UDP (17), length 82)
psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0x3ebd!] 5632+ AAAA? storage-pscendpoint.p.googleapis.com. (54)
05:02:33.944018 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 98)
metadata.google.internal.domain > psc-instance-1.c.yourprojectname.42296: [udp sum ok] 34796 q: A? storage-pscendpoint.p.googleapis.com. 1/0/0 storage-pscendpoint.p.googleapis.com. A 10.10.110.10 (70)
05:02:33.946005 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 175)
Vérifier que l'adresse IP du point de terminaison Private Service Connect est désormais utilisée pour la résolution DNS
Depuis l'onglet 1
nslookup storage-pscendpoint.p.googleapis.com
Sortie
@psc-instance ~]$ nslookup storage-pscendpoint.p.googleapis.com Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: storage-pscendpoint.p.googleapis.com Address: <pscip>
15. Étapes de nettoyage
Quitter l'instance de VM (tous les onglets)
exit
Supprimer les composants de l'atelier à partir d'un seul terminal Cloud Shell
gcloud compute routers nats delete cloudnat --router=crnat --region=us-central1 --quiet gcloud compute routers delete crnat --region=us-central1 --quiet gcloud compute forwarding-rules delete pscendpoint --global --quiet gcloud compute addresses delete psc-ip --global --quiet gsutil rm -r gs://$BUCKET_NAME gcloud compute instances delete psc-instance-1 --zone=us-central1-a --quiet gcloud compute instances delete psc-instance-2 --zone=us-central1-a --quiet gcloud compute firewall-rules delete psclab-ssh --quiet gcloud compute networks subnets delete psclab-subnet --region us-central1 --quiet gcloud compute networks delete psc-lab --quiet
Dans la console, assurez-vous d'afficher le bon projet, puis sélectionnez Services réseau → Cloud DNS.
16. Félicitations !
Bravo ! Vous avez terminé cet atelier de programmation.
Points abordés
- Cas d'utilisation de Private Service Connect
- Configuration réseau requise
- API compatibles
- Création d'un point de terminaison Private Service Connect
- Création d'un bucket Cloud Storage
- Mise à jour d'un fichier de configuration BOTO
- Création d'une passerelle NAT
- Exécutez la commande gsutil list sur la VM1 qui est résolue par rapport à votre point de terminaison de service PSC.
- Exécutez la commande gsutil list sur VM2 qui est résolue par rapport à googleapis.com public.
- Utiliser Tcpdump pour valider la résolution DNS