Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Sortie VPC directe

La sortie VPC directe fournit une solution réseau performante pour que votre service App Engine puisse envoyer du trafic vers un réseau de cloud privé virtuel (VPC). La sortie VPC directe permet aux charges de travail d'accéder de manière fluide 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 les frais opérationnels liés à la gestion des instances de connecteurs, 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 aucun frais supplémentaire. Vous n'avez pas non plus à payer de frais mensuels fixes pour les VM de connecteur.
Performances et fiabilité améliorées : en éliminant la nécessité d'utiliser un connecteur, la sortie VPC directe offre une connexion plus rapide et plus fiable à vos ressources de 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 lors de la maintenance.
Sécurité précise : vous pouvez appliquer des tags réseau directement à vos versions de service App Engine, ce qui permet de définir des règles de pare-feu et des stratégies réseau précises et spécifiques à un service.

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. Votre capacité de scaling est limitée par le nombre d'adresses IP disponibles dans le sous-réseau choisi.
Événements de maintenance : votre service peut rencontrer de brèves interruptions de connexion lors d'événements de maintenance de l'infrastructure 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 par version App Engine pour utiliser la sortie VPC direct.

Allocation d'adresses IP

Pour placer votre service App Engine sur un réseau VPC, spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise 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 une mise à l'échelle plus rapide en cas de pic de trafic, App Engine réserve les adresses IP par blocs de 16 (masque de sous-réseau 28) à la fois. Pour vous assurer de disposer d'un nombre suffisant d'adresses IPv4 à utiliser dans App Engine, la plage d'adresses IPv4 de votre sous-réseau doit être /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 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. Au cours de cet intervalle de 20 minutes, vous devez réserver au moins 400 adresses IP ((100 + 100) * 2).

Plages IPv4 acceptées

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 encore d'un VPC, 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 dernière version de Google Cloud CLI :
```
gcloud components update
```

Rôles requis

Assurez-vous qu'App Engine a accès au réseau VPC en accordant 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 ni les autorisations personnalisées, attribuez le rôle d'utilisateur de réseau Compute (roles/compute.networkUser) au compte de service de l'agent de service App Engine. Les sous-réseaux avec des adresses IPv6 externes nécessitent également le rôle d'administrateur d'adresse IP publique Compute (roles/compute.publicIpAdmin).

Par exemple, pour accorder le rôle d'utilisateur du réseau Compute, exécutez la commande suivante :
```
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service.iam.gserviceaccount.com" \
--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 se connectent les instances de votre application, par exemple default. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise le même nom que le réseau.
- SUBNET : nom du sous-réseau existant auquel se connectent les instances de votre application, par exemple default. Spécifiez un réseau VPC ou un sous-réseau, ou les deux. Si vous ne spécifiez qu'un réseau, le sous-réseau utilise 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 manière dont le trafic sortant est routé. 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. Voici quelques stratégies 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).
Plages d'adresses IP alternatives : si vous utilisez déjà la plage d'adresses IP recommandée 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.
Taille du sous-réseau : assurez-vous que la plage d'adresses IPv4 de votre sous-réseau est /26 ou plus grande pour fournir suffisamment d'adresses pour la mise à l'échelle.
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 la mise à l'échelle et les mises à jour.

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 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 qu'App Engine libère les adresses IP avant de supprimer le sous-réseau.

Échecs de déploiement

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

Métadonnées VPC incorrectes, par exemple 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 à 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 ne dispose plus 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 n'est autorisé qu'à réserver des adresses (create, createInternal) et non à les libérer (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 des réservations d'adresses sans serveur existaient encore.

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

Interrogez 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'attribuer les autres rôles et autorisations requis à votre compte de service de déploiement.
Supprimez manuellement les adresses IP divulguées à l'aide de la console Google Cloud ou de Google Cloud CLI :
Console
1. Accédez à la page Adresses IP de 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.