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 les frais opérationnels liés à 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.

  • Compatibilité avec Cloud NAT : vous pouvez configurer une passerelle Cloud NAT sur votre sous-réseau pour fournir des services NAT, tels que Public NAT ou Private NAT, pour le trafic sortant 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 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 : par défaut, vous ne pouvez configurer que 100 instances maximum par version d'App Engine pour utiliser la sortie VPC directe. Vous pouvez demander une augmentation de quota pour cette limite si votre charge de travail nécessite davantage d'instances.

  • 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.

  • Disponibilité régionale : la sortie VPC directe n'est disponible que sur invitation dans certaines régions. Pour demander l'accès dans ces régions, contactez l'assistance.

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 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 accélérer le scaling à la hausse lors d'une surcharge du trafic, App Engine réserve les 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

  1. 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, suivez les instructions pour en créer un dans Créer un réseau VPC.

  2. Activez l'API Compute Engine et l'API Cloud Build :

    Activer les API

  3. 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 à l'agent de service App Engine :

  • 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) à l'agent de service App Engine. Les sous-réseaux avec IPv6 externe 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 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

Vous pouvez configurer la sortie VPC directe pour un service App Engine à l'aide de YAML ou de Terraform. Pour activer ou déconnecter la sortie VPC directe, déployez une nouvelle version et migrez le trafic vers celle-ci. Vous pouvez également supprimer la version déployée avant d'écraser un ID de version existant.

YAML

  1. 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 utilise 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 utilise le même nom que le réseau.

    • Facultatif : NETWORK_TAGS répertorie les 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.

  2. Déployez l'application sur App Engine en exécutant la commande suivante :

    gcloud app deploy

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

  1. Ajoutez le bloc vpc_access suivant à une ressource google_app_engine_standard_app_version dans votre configuration Terraform :

    vpc_access {
vpc_egress = "EGRESS_SETTING"
network_interfaces {
 network    = "NETWORK"
 subnetwork = "SUBNET"
 tags       = ["TAG_1", "TAG_2"]
}
}

    Remplacez les éléments suivants :

    • NETWORK : nom du réseau VPC 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. Vous pouvez également référencer un nom de ressource google_compute_network (par exemple, google_compute_network.custom.name).
    • 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 utilise le même nom que le réseau. Vous pouvez également référencer un nom de ressource google_compute_subnetwork (par exemple, google_compute_subnetwork.custom.name).
    • Facultatif : TAG_1, TAG_2 répertorie les 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_IP_RANGES (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.

  2. Si la version est déjà déployée sans sortie VPC directe, remplacez la valeur du champ version_id par une nouvelle valeur. Vous ne pouvez pas activer la sortie VPC directe sur une version existante.

  3. Appliquez la configuration :

    terraform apply

Déconnecter un service

Pour déconnecter votre service du réseau VPC, utilisez YAML ou Terraform :

YAML

  1. Supprimez la section vpc_access de votre fichier app.yaml.

  2. Redéployez votre service :

    gcloud app deploy

Terraform

  1. Supprimez le bloc vpc_access de la ressource google_app_engine_standard_app_version dans votre configuration Terraform.

  2. Remplacez le champ version_id par une nouvelle valeur. Vous ne pouvez pas désactiver la sortie VPC directe sur une version existante.

  3. Appliquez la configuration :

    terraform apply

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 sondage 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 à l'agent de service App Engine. Si vous rencontrez des erreurs d'autorisation lors du déploiement, assurez-vous d'accorder les rôles supplémentaires suivants à votre compte de service de déploiement :

Épuisement des adresses IP

Si votre sous-réseau n'a 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 :

  • L'agent de service App Engine n'est autorisé qu'à réserver des adresses (create, createInternal) et ne dispose pas des autorisations nécessaires pour libérer des adresses (delete, deleteInternal).
  • L'agent de service App Engine 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 toujours.

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

  1. 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.

  2. Si votre requête renvoie des résultats, assurez-vous que l'agent de service App Engine dispose du rôle Agent de service App Engine (roles/appengine.serviceAgent). Si vous ne pouvez pas utiliser ce rôle, assurez-vous d'accorder les autres rôles et autorisations requis à l'agent de service App Engine.

  3. 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.