Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Sortie VPC directe

La sortie VPC directe fournit une solution de mise en réseau hautes performances pour que votre service App Engine envoie du trafic vers un réseau cloud privé virtuel (VPC). La sortie VPC directe permet aux charges de travail d'accéder facilement aux ressources du réseau VPC et élimine la nécessité de configurer des connecteurs d'accès au VPC sans serveur.

Principaux avantages

Gestion simplifiée : élimine la surcharge opérationnelle liée à la gestion des instances de connecteur, des types de machines et des paramètres de scaling. App Engine gère les configurations directement dans le fichier app.yaml de votre service.
Rentabilité : l'utilisation de la sortie VPC directe n'entraîne aucuns frais supplémentaires, et vous n'avez pas à payer de frais mensuels fixes pour les VM de connecteur.
Amélioration des performances et de la fiabilité : en éliminant la nécessité d'utiliser un connecteur, la sortie VPC directe offre une connexion plus rapide et plus fiable aux ressources de votre réseau VPC. Il évolue aussi rapidement que votre service App Engine et évite les pertes de connexion qui peuvent se produire avec les connecteurs pendant la maintenance.
Sécurité précise : vous pouvez appliquer des tags réseau directement à vos versions de service App Engine, ce qui permet d'appliquer des règles de pare-feu et des règles de réseau précises et spécifiques au service.
Compatibilité avec les journaux de flux VPC : vous pouvez activer les journaux de flux VPC sur votre sous-réseau pour consigner le trafic de sortie de votre service App Engine.

Limites

Consommation d'adresses IP : l'utilisation des adresses IP de votre service évolue directement en fonction du nombre d'instances en cours d'exécution, et votre capacité de scaling est limitée par le nombre d'adresses IP disponibles dans le sous-réseau que vous avez choisi.
Événements de maintenance : votre service peut rencontrer de brèves interruptions de connexion lors d'événements de maintenance de l'infrastructure de mise en réseau. Nous vous recommandons d'utiliser des bibliothèques clientes pour gérer les réinitialisations occasionnelles des connexions.
Démarrages à froid : les temps de démarrage à froid initiaux dépendent de la région et du cas d'utilisation spécifique. Dans de rares cas, les démarrages à froid peuvent durer jusqu'à une minute.
Entrée VPC directe : App Engine n'est pas compatible avec l'entrée VPC directe.
Nombre d'instances : vous ne pouvez configurer que 100 instances maximum par version d'App Engine pour utiliser la sortie VPC directe.
Journaux de flux VPC : n'affiche pas la version de votre service App Engine dans les enregistrements de journaux. Le nom du service s'affiche dans le champ AppEngineServiceDetails.

Allocation d'adresses IP

Pour placer votre service App Engine sur un réseau VPC, spécifiez un réseau VPC, un sous-réseau ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau porte le même nom que le réseau. App Engine alloue les adresses IP de votre sous-réseau.

Les adresses IP étant éphémères, ne créez pas de règles basées sur des adresses IP individuelles. Si vous devez créer une règle basée sur les adresses IP, par exemple dans les règles de pare-feu, vous devez utiliser la plage d'adresses IP de l'ensemble du sous-réseau.

Pour modifier le réseau ou le sous-réseau utilisé par votre service, déployez une nouvelle version qui utilise les nouvelles valeurs de réseau et de sous-réseau.

Scaling à la hausse et à la baisse

Pour un scaling à la hausse plus rapide lors d'une surcharge du trafic, App Engine réserve des adresses IP par blocs de 16 (masque de sous-réseau 28) à la fois. Pour vous assurer que vous disposez de suffisamment d'adresses IPv4 à utiliser dans App Engine, la plage d'adresses IPv4 de votre sous-réseau doit être de /26 ou plus.

Pour optimiser l'attribution d'adresses IP et simplifier la gestion, placez plusieurs ressources sur le même sous-réseau. Si votre espace d'adresses IPv4 est limité, consultez la section Plages d'adresses IPv4 compatibles pour plus d'options.

Pour supprimer le sous-réseau, vous devez d'abord supprimer ou redéployer votre service App Engine afin de cesser d'utiliser le sous-réseau, puis attendre une à deux heures.

Consommation d'adresses IP pour les services

À l'état stable, App Engine utilise deux fois (x 2) plus d'adresses IP que le nombre d'instances. Lorsqu'une version effectue un scaling à la baisse, App Engine conserve ses adresses IP pendant 20 minutes au maximum. Au total, réservez au moins deux fois le nombre d'adresses IP, plus une marge pour tenir compte des mises à jour de version.

Par exemple, si vous mettez à niveau des versions de sorte que version 1 passe de 100 instances à zéro tandis que version 2 passe de zéro à 100, App Engine conserve l'adresse IP version 1 jusqu'à 20 minutes après le scaling à la baisse. Pendant la période de conservation de 20 minutes, vous devez réserver au moins 400 adresses IP ((100 + 100) * 2).

Plages IPv4 compatibles

App Engine accepte les plages IPv4 suivantes pour votre sous-réseau :

RFC 1918
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
RFC 6598
- 100.64.0.0/10
Classe E
- 240.0.0.0/4

Avant de commencer

Assurez-vous de disposer d'un réseau VPC et d'un sous-réseau existants dans votre projet. Si vous ne disposez pas d'un VPC existant, suivez les instructions pour en créer un dans Créer un réseau VPC.
Activez l'API Compute Engine et l'API Cloud Build :

Activer les API
Pour utiliser la sortie VPC directe, assurez-vous d'exécuter la version la plus récente de la Google Cloud CLI :
```
gcloud components update
```

Rôles requis

Assurez-vous qu'App Engine a accès au réseau VPC en attribuant les rôles suivants à votre compte de service de déploiement :

Rôle d'agent de service App Engine : par défaut, l'agent de service App Engine dispose du rôle Agent de service App Engine (roles/appengine.serviceAgent) contenant les autorisations nécessaires.
Autorisations personnalisées : pour un contrôle plus précis, accordez à l'agent de service App Engine les autorisations supplémentaires suivantes sur le projet :
- compute.networks.get
- compute.subnetworks.get
- compute.subnetworks.use sur le projet ou le sous-réseau spécifique
- compute.addresses.get
- compute.addresses.list
- compute.addresses.create
- compute.addresses.delete
- compute.addresses.createInternal
- compute.addresses.deleteInternal
- compute.regionOperations.get
Rôle d'utilisateur de réseau Compute : si vous n'utilisez pas le rôle d'agent de service App Engine par défaut ou les autorisations personnalisées, attribuez le rôle d'utilisateur de réseau Compute (roles/compute.networkUser) sur le compte de service de l'agent de service App Engine. Les sous-réseaux avec IPv6 externe nécessitent également le rôle Administrateur d'adresse IP publique Compute (roles/compute.publicIpAdmin).

Par exemple, pour accorder le rôle d'utilisateur de réseau Compute, exécutez la commande suivante :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service." \
--role "roles/compute.networkUser"
```
Remplacez les éléments suivants :
- PROJECT_ID : par l'ID du projet.
- PROJECT_NUMBER : numéro du projet dans lequel vous déployez votre service App Engine.

Configurer un service App Engine avec la sortie VPC directe

Pour permettre à un service App Engine nouveau ou existant de se connecter directement à votre réseau VPC, procédez comme suit :

Ajoutez le paramètre vpc_access suivant à votre fichier app.yaml :
```
vpc_access:
  network_interface:
    network: NETWORK
    subnet: SUBNET
    tags:
        - NETWORK_TAGS
  vpc_egress: EGRESS_SETTING
```
Remplacez les éléments suivants :
- NETWORK : nom du réseau existant auquel vos instances d'application se connectent, par exemple default. Spécifiez un réseau VPC, un sous-réseau ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau porte le même nom que le réseau.
- SUBNET : nom du sous-réseau existant auquel vos instances d'application se connectent, par exemple default. Spécifiez un réseau VPC, un sous-réseau ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau porte le même nom que le réseau.
- Facultatif : NETWORK_TAGS : liste de tags réseau à associer aux instances de votre service App Engine pour les utiliser dans les règles de pare-feu et les règles de routage.
- Facultatif : EGRESS_SETTING contrôle la façon dont le trafic sortant est acheminé. Ce champ accepte les paramètres de configuration suivants :
  - all-traffic : toutes les requêtes sortantes sont acheminées via le réseau VPC.
  - private-ranges-only (par défaut) : seul le trafic vers les adresses IP internes est acheminé via le réseau VPC. Le trafic Internet utilise le chemin d'accès App Engine par défaut.
Déployez l'application sur App Engine en exécutant la commande suivante :
```
gcloud beta app deploy
```

Déconnecter un service

Pour déconnecter votre service du réseau VPC :

Supprimez la section vpc_access de votre fichier app.yaml.
Redéployez votre service :
```
gcloud beta app deploy
```

Bonnes pratiques pour la gestion des adresses IP

Il est nécessaire de gérer vos adresses IP, car chaque instance de votre service consomme une adresse IP de votre sous-réseau. Utilisez les stratégies suivantes pour gérer vos adresses IP :

Plage d'adresses IP recommandée : pour une compatibilité optimale, nous vous recommandons de commencer par la plage RFC 6598 (100.64.0.0/10).
Autres plages d'adresses IP : si vous utilisez déjà la plage d'adresses IP recommandée de 100.64.0.0/10, vous pouvez utiliser des plages non-RFC 1918, telles que la classe E (240.0.0.0/4) dans votre sous-réseau.
Dimensionnement du sous-réseau : assurez-vous que la plage d'adresses IPv4 de votre sous-réseau est de /26 ou plus pour fournir suffisamment d'adresses pour le scaling.
Surprovisionner les adresses IP : nous vous recommandons de surprovisionner le nombre d'adresses IP disponibles dans votre sous-réseau pour éviter l'épuisement. Comme pour les services Cloud Run, vous devez généralement utiliser quatre fois plus d'adresses IP (deux fois plus pour l'état stable et deux fois plus pendant le déploiement) que le nombre d'instances en cours d'exécution pour faciliter le scaling et les mises à jour.

Isoler le trafic Internet sortant

Par défaut, lorsque vpc_egress est défini sur private-ranges-only, App Engine envoie le trafic Internet sortant via un pool régional d'adresses IP dynamiques partagées entre les charges de travail sans serveur. N'utilisez pas ce pool partagé par défaut pour les charges de travail qui dépendent de la réputation des adresses IP ou qui génèrent un trafic de vérification important.

Définissez plutôt vpc_egress: all-traffic et acheminez le trafic sortant via Cloud NAT avec des adresses IP sortantes statiques dédiées dans les cas suivants :

Votre service se connecte à des points de terminaison externes sensibles à la réputation, tels que des passerelles de paiement, des bases de données hébergées ou des API partenaires derrière des pare-feu d'application Web (WAF) tiers. Les adresses IP statiques dédiées empêchent le trafic bruyant d'autres locataires du pool partagé de déclencher des blocages WAF externes ou des erreurs HTTP 403.
Votre service exécute une analyse réseau autorisée, une énumération de ports, une empreinte d'hôte, une détection de failles, un scraping Web ou un test de charge. L'exécution de ces charges de travail sur le pool d'adresses IP partagées par défaut dégrade la réputation des adresses IP, peut perturber le service pour d'autres clients en violation du Règlement sur l'utilisation acceptable deGoogle Cloud et peut amener Google à limiter ou suspendre votre charge de travail.

Lorsque vous exécutez des charges de travail d'analyse autorisée ou à connexion élevée via Cloud NAT, allouez suffisamment d'adresses IP statiques et configurez la réservation de ports pour éviter l'épuisement des ports.

Résoudre les problèmes

Cette section décrit les erreurs courantes que vous pouvez rencontrer lors du déploiement de votre service App Engine avec la sortie VPC directe.

Impossible de supprimer le sous-réseau

Pour supprimer un sous-réseau, vous devez d'abord supprimer ou redéployer toutes les ressources qui l'utilisent. Si App Engine utilise un sous-réseau, déconnectez le service App Engine du réseau VPC ou déplacez-le vers un autre sous-réseau avant de supprimer le sous-réseau.

Après avoir supprimé ou déplacé votre service App Engine, attendez une à deux heures que App Engine libère les adresses IP avant de supprimer le sous-réseau.

Échecs de déploiement

Si votre déploiement échoue, la Google Cloud CLI affiche des messages d'erreur indiquant la cause principale. Voici quelques problèmes courants :

Métadonnées VPC incorrectes, telles qu'un nom de réseau ou de sous-réseau mal orthographié dans votre fichier app.yaml. Pour corriger les erreurs potentielles, vérifiez la configuration du VPC dans votre fichier app.yaml.
Autorisations IAM insuffisantes. Assurez-vous d'accorder les autorisations requises sur votre compte de service de déploiement. Si vous rencontrez des erreurs d'autorisation lors du déploiement, assurez-vous d'accorder les rôles supplémentaires suivants au compte de service :
- Compte de service Cloud Build (roles/cloudbuild.builds.builder)
- Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator)

Épuisement des adresses IP

Si votre sous-réseau manque d'adresses IP disponibles, App Engine ne parvient pas à démarrer de nouvelles instances et consigne une erreur. Pour résoudre ce problème, étendez la plage d'adresses IP de votre sous-réseau ou déplacez votre service vers un sous-réseau plus grand.

Fuites d'adresses IP

Les fuites d'adresses IP peuvent entraîner l'épuisement des adresses IP. Les fuites d'adresses IP sont peu probables lors des opérations standards, mais peuvent se produire pour les raisons suivantes :

Votre compte de service de déploiement ne dispose que des autorisations nécessaires pour réserver des adresses (create, createInternal) et ne dispose pas des autorisations nécessaires pour libérer des adresses (delete, deleteInternal).
Votre compte de service a été supprimé alors que d'autres réservations d'adresses Google Cloud étaient actives.
Le compte de facturation Cloud a été supprimé, puis réactivé dans le projet alors que les réservations d'adresses sans serveur étaient actives.
Votre projet Google Cloud a été supprimé, puis restauré alors que les réservations d'adresses sans serveur existaient toujours.

Pour résoudre ce problème, procédez comme suit :

Recherchez les journaux suivants dans l'explorateur de journaux pour identifier les adresses divulguées :
```
protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*"
protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses"
protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*"
severity>=WARNING
```
Si cette requête ne renvoie aucun résultat, cela signifie qu'il n'y a pas de fuite d'adresse IP et qu'aucune autre action n'est requise.
Si votre requête renvoie des résultats, assurez-vous que votre compte de service de déploiement contient le rôle Agent de service App Engine (roles/appengine.serviceAgent). Si vous ne pouvez pas utiliser ce rôle, assurez-vous d'accorder d'autres rôles et autorisations requis sur votre compte de service de déploiement.
Supprimez manuellement les adresses IP divulguées à l'aide de la console Google Cloud ou de la Google Cloud CLI :
Console
1. Accédez à la page Adresses IP dans la console Google Cloud :
  
  Accéder à la page "Adresses IP"
2. Sélectionnez les adresses IP divulguées que vous avez identifiées à l'étape précédente en exécutant la requête.
3. Cliquez sur Libérer l'adresse statique pour supprimer les adresses divulguées.
gcloud
Exécutez la commande gcloud compute addresses delete :
gcloud compute addresses delete ADDRESS_NAME --region=REGION
Remplacez les éléments suivants :
- ADDRESS_NAME : nom de l'adresse IP divulguée.
- REGION : région de l'adresse IP divulguée.