Configurer un équilibreur de charge d'application externe global avec Cloud Run, App Engine ou Cloud Functions

Cette page explique comment créer un équilibreur de charge d'application externe afin d'acheminer les requêtes vers des backends sans serveur. Ici, le terme "sans serveur" fait référence aux produits d'informatique sans serveur suivants :

  • App Engine
  • Cloud Functions
  • Cloud Run

L'intégration des équilibreurs de charge d'application externes à API Gateway permet à vos backends sans serveur de profiter de toutes les fonctionnalités fournies par Cloud Load Balancing. Pour configurer un équilibreur de charge d'application externe afin d'acheminer le trafic vers API Gateway, consultez la page Premiers pas avec un équilibreur de charge d'application externe pour API Gateway. La compatibilité d'API Gateway avec l'équilibreur de charge d'application externe est disponible en version bêta.

Les NEG sans serveur vous permettent d'utiliser des applications sans serveur Google Cloud avec des équilibreurs de charge d'applications externes. Une fois que vous avez configuré un équilibreur de charge avec le backend du NEG sans serveur, les requêtes envoyées à l'équilibreur de charge sont acheminées vers le backend d'application sans serveur.

Pour en savoir plus sur les NEG sans serveur, consultez la présentation des NEG sans serveur.

Si vous êtes déjà un utilisateur de l'équilibreur de charge d'application classique, assurez-vous de consulter la section Planifier votre migration vers l'équilibreur de charge d'application externe global lorsque vous planifiez un nouveau déploiement avec l'équilibreur de charge d'application externe global.

Avant de commencer

  1. Déployez un service App Engine, Cloud Functions ou Cloud Run.
  2. Si vous ne l'avez pas déjà fait, installez Google Cloud CLI.
  3. Configurez les autorisations.
  4. Ajoutez une ressource de certificat SSL.

Déployer un service App Engine, Cloud Functions ou Cloud Run

Pour les instructions fournies sur cette page, nous partons du principe que vous disposez déjà d'un service Cloud Run, Cloud Functions ou App Engine en cours d'exécution.

Dans l'exemple de cette page, nous utilisons le guide de démarrage rapide de Cloud Run pour Python afin de déployer un service Cloud Run dans la région us-central1. Enfin, le reste de la page vous explique comment configurer un équilibreur de charge d'application externe qui utilise un backend de NEG sans serveur pour acheminer les requêtes vers ce service.

Si vous n'avez pas encore déployé d'application sans serveur ou si vous souhaitez essayer un NEG sans serveur avec un exemple d'application, reportez-vous à l'un des guides de démarrage rapide mentionnés ci-après. Vous pouvez créer une application sans serveur dans n'importe quelle région, mais vous devrez utiliser la même région ultérieurement pour créer le NEG et l'équilibreur de charge sans serveur.

Cloud Run

Pour générer une application simple de type "Hello World", intégrez l'application dans une image de conteneur, puis déployez l'image sur Cloud Run. Consultez la page Démarrage rapide : Construire et déployer.

Si vous avez déjà importé un exemple de conteneur dans Container Registry, consultez la page Démarrage rapide : Déployer un exemple de conteneur prédéfini.

Cloud Functions

Consultez la page Cloud Functions : Démarrage rapide pour Python.

App Engine

Consultez les guides de démarrage rapide d'App Engine pour Python 3 suivants :

Installer Google Cloud CLI

Installez Google Cloud CLI. Pour obtenir plus d'informations conceptuelles sur l'outil gcloud ainsi que des instructions d'installation, consultez la Présentation de gcloud.

Si vous n'avez pas encore utilisé gcloud CLI, commencez par exécuter la commande gcloud init pour initialiser votre répertoire gcloud.

Configurer les autorisations

Pour suivre ce guide, vous devez créer un NEG sans serveur et créer un équilibreur de charge HTTP(S) externe dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer des rôles IAM Compute Engine suivants :

Tâche Rôle requis
Créer des composants d'équilibrage de charge et de mise en réseau Administrateur réseau
Créer et modifier des NEG Administrateur d'instances Compute
Créer et modifier des certificats SSL Administrateur de sécurité

Réserver une adresse IP externe

Maintenant que vos services sont opérationnels, configurez une adresse IP externe statique globale que vos clients utiliseront pour accéder à votre équilibreur de charge.

Console

  1. Dans Google Cloud Console, accédez à la page Adresses IP externes.

    Accéder à la page "Adresses IP externes"

  2. Cliquez sur Réserver une adresse IP externe statique.

  3. Dans le champ Nom, saisissez example-ip.

  4. Dans le champ Niveau de service réseau, sélectionnez Premium.

  5. Pour Version IP, sélectionnez IPv4.

  6. Pour le champ Type, sélectionnez Global.

  7. Cliquez sur Réserver.

gcloud 

gcloud compute addresses create example-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

Notez l'adresse IPv4 réservée :

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

Créer une ressource de certificat SSL

Pour créer un équilibreur de charge HTTPS, vous devez ajouter une ressource de certificat SSL au frontal de l'équilibreur de charge. Créez une ressource de certificat SSL à l'aide d'un certificat SSL géré par Google ou d'un certificat SSL autogéré.

  • Certificats gérés par Google. L'utilisation de certificats gérés par Google est recommandée, car Google Cloud obtient, gère et renouvelle automatiquement ces certificats pour vous. Pour créer un certificat géré par Google, vous devez disposer d'un domaine et d'enregistrements DNS pour ce domaine afin que le certificat soit provisionné. Si vous ne possédez pas encore de domaine, vous pouvez en obtenir un auprès de Google Domains. Pour en savoir plus, consultez la section Premiers pas avec Google Domains. De plus, vous devez mettre à jour l'enregistrement DNS A du domaine pour qu'il pointe vers l'adresse IP de l'équilibreur de charge créée à l'étape précédente (example-ip). Pour obtenir des instructions détaillées, consultez la page Utiliser des certificats SSL gérés par Google.

  • Certificats autosignés. Si vous ne souhaitez pas configurer un domaine à ce stade, vous pouvez utiliser un certificat SSL autosigné pour les tests.

Pour cet exemple, nous partons du principe que vous avez déjà créé une ressource de certificat SSL.

Si vous souhaitez tester ce processus sans créer de ressource de certificat SSL (ou de domaine comme requis par les certificats gérés par Google), vous pouvez toujours utiliser les instructions de cette page pour configurer un équilibreur de charge HTTP.

Créer l'équilibreur de charge

Dans le schéma suivant, l'équilibreur de charge utilise un backend de NEG sans serveur pour envoyer les requêtes vers un service Cloud Run sans serveur. Dans cet exemple, nous avons utilisé le guide de démarrage rapide de Cloud Run pour Python afin de déployer un service Cloud Run.

Architecture de l'équilibreur de charge d'application externe pour une application Cloud Run
Architecture de l'équilibreur de charge d'application externe pour une application Cloud Run (cliquez pour agrandir)

Étant donné que les vérifications d'état ne sont pas disponibles pour les services de backend avec des backends de NEG sans serveur, vous n'avez pas besoin de créer de règle de pare-feu autorisant les vérifications d'état si l'équilibreur de charge ne dispose que de backends de NEG sans serveur.

Console

Démarrer la configuration

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur Créer un équilibreur de charge.
  3. Dans le champ Type d'équilibreur de charge, sélectionnez Équilibreur de charge d'application (HTTP/HTTPS), puis cliquez sur Suivant.
  4. Pour Public ou interne, sélectionnez Public (externe), puis cliquez sur Suivant.
  5. Pour Déploiement mondial ou dans une seule région, sélectionnez Recommandé pour les charges de travail à l'échelle mondiale, puis cliquez sur Suivant.
  6. Pour Génération de l'équilibreur de charge, sélectionnez Équilibreur de charge d'application externe global, puis cliquez sur Suivant.
  7. Cliquez sur Configurer.

Configuration de base

  1. Pour le nom de l'équilibreur de charge, saisissez serverless-lb.
  2. Laissez la fenêtre ouverte pour continuer.

Configuration de l'interface

  1. Cliquez sur Configuration de l'interface.
  2. Dans le champ Nom, saisissez un nom.
  3. Pour créer un équilibreur de charge HTTPS, vous devez disposer d'un certificat SSL (gcloud compute ssl-certificates list).

    Nous vous recommandons d'utiliser un certificat géré par Google, comme décrit précédemment.

    4. Pour configurer un équilibreur de charge d'application externe, renseignez les champs comme suit.

    Vérifiez que les options suivantes sont configurées avec les valeurs suivantes :

    Propriété Valeur (saisissez une valeur ou sélectionnez une option spécifiée)
    Protocole HTTPS
    Niveau de service réseau Premium
    Version IP IPv4
    Adresse IP example-ip
    Port 443
    Facultatif: délai d'expiration du message keepalive HTTP Saisissez une valeur de délai avant expiration comprise entre 5 et 1 200 secondes. La valeur par défaut est de 610 secondes.
    Certificat Sélectionnez un certificat SSL existant ou créez-en un.

    Pour créer un équilibreur de charge HTTPS, vous devez disposer d'une ressource de certificat SSL à utiliser dans le proxy HTTPS. Vous pouvez créer une ressource de certificat SSL à l'aide d'un certificat SSL géré par Google ou d'un certificat SSL autogéré.
    Pour créer un certificat géré par Google, vous devez disposer d'un domaine. L'enregistrement A du domaine doit correspondre à l'adresse IP de l'équilibreur de charge (dans cet exemple, example-ip). Il est recommandé d'utiliser des certificats gérés par Google, car Google Cloud obtient, gère et renouvelle automatiquement ces certificats. Si vous ne détenez pas de domaine, vous pouvez utiliser un certificat SSL autosigné pour les tests.
    Facultatif : Activer la redirection HTTP vers HTTPS Cochez cette case pour activer les redirections HTTP vers HTTPS.

    Cochez cette case pour créer un équilibreur de charge HTTP partiel supplémentaire qui utilise la même adresse IP que votre équilibreur de charge HTTPS et redirige les requêtes HTTP vers l'interface HTTPS de votre équilibreur de charge.

    Cette case ne peut être cochée que lorsque le protocole HTTPS est sélectionné et qu'une adresse IP réservée est utilisée.

    Si vous souhaitez tester ce processus sans configurer une ressource de certificat SSL (ou un domaine comme requis par les certificats gérés par Google), vous pouvez configurer un équilibreur de charge HTTP.

    Pour créer un équilibreur de charge HTTP, vérifiez que les options suivantes sont configurées avec ces valeurs :

    Propriété Valeur (saisissez une valeur ou sélectionnez une option spécifiée)
    Protocole HTTP
    Niveau de service réseau Premium
    Version IP IPv4
    Adresse IP example-ip
    Port 80
    Facultatif: délai d'expiration du message keepalive HTTP Saisissez une valeur de délai avant expiration comprise entre 5 et 1 200 secondes. La valeur par défaut est de 610 secondes.
  4. Cliquez sur OK.

Configuration du backend

  1. Cliquez sur Configuration du backend.
  2. Dans la liste Services de backend et buckets backend, cliquez sur Créer un service de backend.
  3. Dans le champ Nom, saisissez un nom.
  4. Dans le champ Type de backend, sélectionnez Groupe de points de terminaison du réseau sans serveur.
  5. Laissez le paramètre Protocole inchangé. Ce paramètre est ignoré.
  6. Dans la section Backends, dans le champ Nouveau backend, sélectionnez Créer un groupe de points de terminaison du réseau sans serveur.
  7. Dans le champ Nom, saisissez un nom.
  8. Dans le champ Région, sélectionnez us-central1, puis Cloud Run.
  9. Cliquez sur Sélectionner un nom de service.
  10. Dans la liste Service, sélectionnez le service Cloud Run pour lequel vous souhaitez créer un équilibreur de charge.
  11. Cliquez sur Créer.
  12. Dans la section Nouveau backend, cliquez sur Terminé.
  13. Cliquez sur Créer.

Règles de routage

Les règles de routage déterminent la manière dont le trafic est dirigé. Pour configurer le routage, vous devez configurer des règles d'hôte et des outils de mise en correspondance des chemins, qui sont des composants de configuration d'un mappage d'URL de l'équilibreur de charge d'application externe.

  1. Cliquez sur Règles de routage.

  2. Conservez les hôtes et les chemins d'accès par défaut. Pour cet exemple, toutes les requêtes sont transmises au service de backend créé à l'étape précédente.

Vérifier la configuration

  1. Cliquez sur Vérifier et finaliser.
  2. Vérifiez tous les paramètres.
  3. Facultatif : cliquez sur Code équivalent pour afficher la requête API REST qui sera utilisée pour créer l'équilibreur de charge.
  4. Cliquez sur Créer.
  5. Attendez jusqu'à ce que l'équilibreur de charge soit créé.
  6. Cliquez sur le nom de l'équilibreur de charge (serverless-lb).
  7. Notez l'adresse IP de l'équilibreur de charge pour la prochaine tâche. Elle est désignée par l'élément IP_ADDRESS.

gcloud

  1. Créez un NEG sans serveur pour votre application sans serveur.

    Pour créer un NEG sans serveur avec un service Cloud Run, procédez comme suit : 

       gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
       --region=us-central1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=CLOUD_RUN_SERVICE_NAME
    Pour plus d'options, consultez le guide de référence gcloud sur gcloud compute network-endpoint-groups create.
  2. Créez un service de backend. 
       gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --global
  3. Ajoutez le NEG sans serveur en tant que backend au service de backend : 
       gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --global \
       --network-endpoint-group=SERVERLESS_NEG_NAME \
       --network-endpoint-group-region=us-central1
  4. Créez un mappage d'URL pour acheminer les requêtes entrantes vers le service de backend. 
       gcloud compute url-maps create URL_MAP_NAME \
       --default-service BACKEND_SERVICE_NAME

    Cet exemple de mappage d'URL ne cible qu'un service de backend représentant une seule application sans serveur. Vous n'avez donc pas besoin de configurer de règles d'hôte ni de mises en correspondance des chemins d'accès. Si vous disposez de plusieurs services de backend, vous pouvez utiliser des règles d'hôte pour acheminer les requêtes vers différents services en fonction du nom d'hôte. Vous pouvez également configurer un outil de mise en correspondance des chemins d'accès pour diriger les requêtes vers différents services en fonction du chemin d'accès des requêtes.

  5. Pour créer un équilibreur de charge HTTPS, vous devez disposer d'une ressource de certificat SSL à utiliser dans le proxy HTTPS cible. Vous pouvez créer une ressource de certificat SSL à l'aide d'un certificat SSL géré par Google ou d'un certificat SSL autogéré. L'utilisation de certificats gérés par Google est recommandée, car Google Cloud obtient, gère et renouvelle automatiquement ces certificats.

    Pour créer un certificat géré par Google, vous devez disposer d'un domaine. Si ce n'est pas le cas, vous pouvez utiliser un certificat SSL auto-signé pour les tests.

    Pour créer une ressource de certificat SSL géré par Google, procédez comme suit : 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --domains DOMAIN
    Pour créer une ressource de certificat SSL autogéré, procédez comme suit : 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --certificate CRT_FILE_PATH \
       --private-key KEY_FILE_PATH

  6. Créez un proxy HTTP(S) cible, qui va rediriger les requêtes vers votre mappage d'URL.

    Pour un équilibreur de charge HTTP, créez un proxy HTTP cible :

       gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
      --url-map=URL_MAP_NAME

    Pour un équilibreur de charge HTTPS, créez un proxy cible HTTPS. Le proxy est la partie de l'équilibreur de charge qui contient le certificat SSL pour l'équilibrage de charge HTTPS. Vous chargez donc également votre certificat à cette étape.

       gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
       --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
       --ssl-certificates=SSL_CERTIFICATE_NAME \
       --url-map=URL_MAP_NAME

    Remplacez les éléments suivants :

    • TARGET_HTTP_PROXY_NAME: nom du proxy HTTP cible.
    • TARGET_HTTPS_PROXY_NAME : nom du proxy HTTPS cible.
    • HTTP_KEEP_ALIVE_TIMEOUT_SEC: champ facultatif utilisé pour spécifier le délai d'expiration du message keepalive HTTP du client. La valeur de ce délai doit être comprise entre 5 et 1 200 secondes. La valeur par défaut est de 610 secondes.
    • SSL_CERTIFICATE_NAME : nom du certificat SSL.
    • URL_MAP_NAME : nom du mappage d'URL.
  7. Créez une règle de transfert pour acheminer les requêtes entrantes vers le proxy.

    Pour un équilibreur de charge HTTP, utilisez ce qui suit :

       gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --address=example-ip \
   --target-http-proxy=TARGET_HTTP_PROXY_NAME \
   --global \
   --ports=80

    Pour un équilibreur de charge HTTPS, utilisez ce qui suit :

       gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --network-tier=PREMIUM \
       --address=example-ip \
       --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
       --global \
       --ports=443

Connecter un domaine à votre équilibreur de charge

Une fois l'équilibreur de charge créé, notez l'adresse IP associée à celui-ci (par exemple, 30.90.80.100). Pour faire pointer votre domaine vers votre équilibreur de charge, créez un enregistrement A à l'aide de votre service d'enregistrement de domaine. Si vous avez ajouté plusieurs domaines à votre certificat SSL, vous devez ajouter un enregistrement A à chacun d'eux, tous pointant vers l'adresse IP de l'équilibreur de charge. Par exemple, pour créer des enregistrements A pour www.example.com et example.com, utilisez le code suivant :

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Si vous utilisez Cloud DNS comme fournisseur DNS, consultez la section Ajouter, modifier et supprimer des enregistrements.

Tester l'équilibreur de charge

Maintenant que vous avez configuré votre équilibreur de charge, vous pouvez commencer à envoyer du trafic vers son adresse IP. Si vous avez configuré un domaine, vous pouvez également envoyer du trafic vers le nom de domaine. Toutefois, la propagation DNS peut prendre un certain temps. Vous pouvez donc commencer à utiliser l'adresse IP à des fins de test.

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur l'équilibreur de charge que vous venez de créer.

  3. Notez l'adresse IP de l'équilibreur de charge.

  4. S'il s'agit d'un équilibreur de charge HTTP, vous pouvez le tester à l'aide d'un navigateur Web en accédant à http://IP_ADDRESS. Remplacez IP_ADDRESS par l'adresse IP de l'équilibreur de charge. Vous devriez être redirigé vers la page d'accueil du service helloworld.

  5. S'il s'agit d'un équilibreur de charge HTTPS, vous pouvez le tester à l'aide d'un navigateur Web en accédant à https://IP_ADDRESS. Remplacez IP_ADDRESS par l'adresse IP de l'équilibreur de charge. Vous devriez être redirigé vers la page d'accueil du service helloworld.
    Si cela ne fonctionne pas et que vous utilisez un certificat géré par Google, vérifiez que l'état de votre ressource de certificat est ACTIF. Pour en savoir plus, consultez la section Vérifier l'état du certificat SSL géré par Google.
    Si vous avez utilisé un certificat autosigné pour les tests, votre navigateur affiche un avertissement. Vous devez explicitement lui indiquer d'accepter un certificat autosigné. Cliquez sur l'avertissement pour afficher la page.

Options de configuration supplémentaires

Cette section développe l'exemple de configuration et propose d'autres options de configuration. Toutes les tâches décrites ici sont facultatives. Vous pouvez les exécuter dans n'importe quel ordre.

Configurer l'équilibrage de charge multirégional

Dans l'exemple décrit précédemment sur cette page, un seul service Cloud Run sert de backend dans la région us-central1. Étant donné que le NEG sans serveur ne peut pointer que vers un seul point de terminaison à la fois, l'équilibrage de charge n'est pas effectué sur plusieurs régions. L'équilibreur de charge d'application externe sert uniquement d'interface pour transmettre le trafic par proxy au point de terminaison de l'application helloworld spécifié. Toutefois, vous pouvez diffuser votre application Cloud Run à partir de plusieurs régions afin d'améliorer la latence pour l'utilisateur final.

Si un service de backend est associé à plusieurs NEG sans serveur, l'équilibreur de charge équilibre le trafic en transférant les requêtes au NEG sans serveur situé dans la région disponible la plus proche. Toutefois, les services de backend ne peuvent contenir qu'un seul NEG sans serveur par région. Pour que votre service Cloud Run soit disponible dans plusieurs régions, vous devez configurer le routage interrégional. Vous devez pouvoir utiliser un schéma d'URL unique qui fonctionne partout dans le monde, tout en répondant aux requêtes des utilisateurs depuis la région la plus proche d'eux.

Pour configurer la diffusion multirégionale, vous devez utiliser le niveau réseau Premium pour vous assurer que tous les déploiements Cloud Run régionaux sont compatibles et prêts à diffuser le trafic en provenance de n'importe quelle région.

Pour configurer un équilibreur de charge multirégional, procédez comme suit :

  1. Configurez deux services Cloud Run dans différentes régions. Supposons que vous avez déployé deux services Cloud Run : un pour une région aux États-Unis et un autre pour une région en Europe.
  2. Créez un équilibreur de charge d'application externe avec la configuration suivante :
    1. Configurez un service de backend global avec deux NEG sans serveur :
      1. Créez le premier NEG dans la même région que le service Cloud Run déployé aux États-Unis.
      2. Créez le second NEG dans la même région que le service Cloud Run déployé en Europe.
    2. Définissez la configuration de votre interface avec le niveau de service réseau Premium.

La configuration obtenue est illustrée dans le schéma suivant.

Routage multirégional pour les applications sans serveur.
Routage multirégional pour les applications sans serveur

Cette section s'appuie sur la configuration d'équilibreur de charge décrite précédemment sur cette page, dans laquelle vous avez créé un NEG sans serveur dans la région us-central1 qui pointe vers un service Cloud Run dans la même région. Nous supposons également que vous avez créé un deuxième service Cloud Run dans la région europe-west1. Le deuxième NEG sans serveur que vous créez pointe vers ce service Cloud Run dans la région europe-west1.

Dans cet exemple, vous allez effectuer les étapes suivantes :

  1. Créer un second NEG sans serveur dans la région europe-west1.
  2. Associer le deuxième NEG sans serveur au service de backend.

Pour ajouter un second NEG sans serveur à un service de backend existant, procédez comme suit :

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur le nom de l'équilibreur de charge dont vous souhaitez modifier le service de backend.

  3. Sur la page Détails de l'équilibreur de charge, cliquez sur Modifier.

  4. Sur la page Modifier l'équilibreur de charge d'application externe global, cliquez sur Configuration du backend.

  5. Sur la page Configuration du backend, cliquez sur le bouton Modifier correspondant au service de backend que vous souhaitez modifier.

  6. Dans la section Backends, cliquez sur Ajouter un backend.

  7. Dans la liste Groupes de points de terminaison du réseau sans serveur, sélectionnez Créer un groupe de points de terminaison du réseau sans serveur.

  8. Saisissez un nom pour le NEG sans serveur.

  9. Pour Région, sélectionnez europe-west1.

  10. Pour Type de groupe de points de terminaison du réseau sans serveur, sélectionnez Cloud Run, puis procédez comme suit :

    1. Choisissez l'option Sélectionner un service.
    2. Dans la liste Service, sélectionnez le service Cloud Run pour lequel vous souhaitez créer un équilibreur de charge.

  11. Cliquez sur Créer.

  12. Sur la page Nouveau backend, cliquez sur Terminé.

  13. Cliquez sur Enregistrer.

  14. Pour mettre à jour le service de backend, cliquez sur Mettre à jour.

  15. Pour mettre à jour l'équilibreur de charge, sur la page Modifier l'équilibreur de charge d'application externe global, cliquez sur Mettre à jour.

gcloud

  1. Créez un second NEG sans serveur dans la même région que celle dans laquelle le service Cloud Run est déployé.

    gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
  --region=europe-west1 \
  --network-endpoint-type=SERVERLESS \
  --cloud-run-service=CLOUD_RUN_SERVICE_2

    Remplacez les éléments suivants :

    • SERVERLESS_NEG_NAME_2 : nom du deuxième NEG sans serveur.
    • CLOUD_RUN_SERVICE_2 : nom du service Cloud Run.

  2. Ajoutez le second NEG sans serveur en tant que backend au service de backend :

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
  --network-endpoint-group-region=europe-west1

    Remplacez les éléments suivants :

    • BACKEND_SERVICE_NAME : nom du service de backend.
    • SERVERLESS_NEG_NAME_2 : nom du deuxième NEG sans serveur.

Utiliser un abonnement push Pub/Sub authentifié avec un déploiement multirégional Cloud Run

Pour les requêtes push authentifiées, Cloud Run attend par défaut un champ d'audience spécifique à la région. Dans le cas d'un déploiement Cloud Run multirégional, si la requête push est acheminée vers un service Cloud Run dans une région différente, la validation du jeton JWT échoue en raison d'une erreur de correspondance de l'audience.

Pour contourner cette restriction spécifique à la région, procédez comme suit :

  1. Configurez une audience personnalisée identique pour les déploiements de services dans différentes régions.
  2. Configurez les messages push Pub/Sub pour utiliser l'audience personnalisée en tant qu'audience dans le jeton JWT.

Configurer le routage régional

Les applications sont souvent diffusées à partir de plusieurs régions pour répondre aux exigences de localisation des données. Par exemple, vous pouvez vous assurer que les requêtes effectuées par des utilisateurs européens sont toujours traitées à partir d'une région située en Europe. Pour ce faire, vous devez disposer d'un schéma d'URL avec des URL distinctes pour les utilisateurs de l'UE et des autres pays, et diriger vos utilisateurs européens vers les URL de l'UE.

Dans un tel scénario, vous utilisez le mappage d'URL pour acheminer les requêtes provenant d'URL spécifiques vers les régions correspondantes. Avec une telle configuration, les requêtes destinées à une région ne sont jamais diffusées à une autre région. Cela permet d'isoler les régions. En revanche, lorsqu'une région est indisponible, les requêtes ne sont pas acheminées vers une autre région. Cette configuration n'augmente donc pas la disponibilité de votre service.

Pour configurer le routage régional, vous devez utiliser le niveau réseau Premium afin de pouvoir combiner différentes régions au sein d'une seule règle de transfert.

Pour configurer un équilibreur de charge avec un routage régional :

  1. Configurez deux services Cloud Run dans différentes régions. Supposons que vous avez déployé deux services Cloud Run : hello-world-eu dans une région d'Europe et hello-world-us dans une région aux États-Unis.
  2. Créez un équilibreur de charge d'application externe avec la configuration suivante :
    1. Configurez un service de backend avec un NEG sans serveur en Europe. Le NEG sans serveur doit être créé dans la même région que le service Cloud Run déployé en Europe.
    2. Configurez un second service de backend avec un autre NEG sans serveur aux États-Unis. Vous devez créer ce NEG sans serveur dans la même région que le service Cloud Run déployé aux États-Unis.
    3. Configurez votre mappage d'URL avec les règles d'hôte et de chemin d'accès appropriées afin que les requêtes provenant d'un ensemble d'URL spécifique soient acheminées vers le service de backend européen, tandis que toutes les autres requêtes sont acheminées vers le service de backend américain.
    4. Définissez la configuration de votre interface avec le niveau réseau Premium.

Le reste de la configuration peut être identique à celle décrite précédemment. Votre configuration doit se présenter comme suit :

Routage régional pour les applications sans serveur sans basculement
Routage régional pour les applications sans serveur sans basculement

Utiliser un masque d'URL

Lorsque vous créez un NEG sans serveur, au lieu de sélectionner un service Cloud Run spécifique, vous pouvez utiliser un masque d'URL qui pointe vers plusieurs services diffusés sur le même domaine. Un masque d'URL est un modèle de votre schéma d'URL. Le NEG sans serveur utilisera ce modèle pour extraire le nom du service de l'URL de la requête entrante et mapper la requête au service approprié.

Les masques d'URL sont utiles si votre service est mappé sur un domaine personnalisé plutôt que sur l'adresse par défaut que Google Cloud fournit au service déployé. Un masque d'URL vous permet de cibler plusieurs services et versions avec une seule règle, même lorsque votre application utilise un format d'URL personnalisé.

Si vous ne l'avez pas déjà fait, consultez la section Masques d'URL de la présentation des NEG sans serveur.

Créer un masque d'URL

Pour créer un masque d'URL pour votre équilibreur de charge, commencez par l'URL de votre service. Pour cet exemple, nous allons utiliser un exemple d'application sans serveur s'exécutant sur https://example.com/login. Il s'agit de l'URL où le service login de l'application sera diffusé.

  1. Supprimez http ou https de l'URL pour ne garder que example.com/login.
  2. Remplacez le nom du service par un espace réservé pour le masque d'URL.
    1. Cloud Run : remplacez le nom du service Cloud Run par l'espace réservé <service>. Si le service Cloud Run est associé à un tag, remplacez celui-ci par l'espace réservé <tag>. Dans cet exemple, le masque d'URL final est example.com/<service>.
    2. Cloud Functions : remplacez le nom de la fonction par l'espace réservé <function>. Dans cet exemple, le masque d'URL final est example.com/<function>.
    3. App Engine : remplacez le nom du service par l'espace réservé <service>. Si une version du service est associée, remplacez la version par l'espace réservé <version>. Dans cet exemple, le masque d'URL final est example.com/<service>.
    4. API Gateway : remplacez le nom de passerelle par l'espace réservé <gateway>. Dans cet exemple, le masque d'URL final est example.com/<gateway>.

  3. (Facultatif) Si le nom du service (ou la fonction, la version, ou le tag) peut être extrait de la partie du chemin d'accès de l'URL, le domaine peut être omis. La partie du chemin d'accès du masque d'URL se distingue par le premier caractère /. Si le caractère / est absent du masque d'URL, le masque est considéré comme représentant uniquement l'hôte. Par conséquent, dans cet exemple, le masque d'URL peut être réduit à /<service>, /<gateway> ou /<function>.

    De même, si le nom du service peut être extrait de la partie hôte de l'URL, vous pouvez omettre complètement le chemin d'accès du masque d'URL.

    Vous pouvez également omettre les composants d'hôte ou de sous-domaine qui précèdent le premier espace réservé, ainsi que les composants de chemin d'accès qui suivent le dernier espace réservé. Dans ce cas, l'espace réservé capture les informations requises pour le composant.

Voici quelques exemples supplémentaires illustrant ces règles :

Cloud Run

Ce tableau part du principe que vous disposez d'un domaine personnalisé appelé example.com et que tous vos services Cloud Run sont mappés sur ce domaine à l'aide d'un équilibreur de charge d'application externe.

Service, nom du tag URL du domaine personnalisé Masque d'URL
service : login https://login-home.example.com/web <service>-home.example.com
service : login https://example.com/login/web example.com/<service> ou /<service>
service : login, tag : test https://test.login.example.com/web <tag>.<service>.example.com
service : login, tag : test https://example.com/home/login/test example.com/home/<service>/<tag> ou /home/<service>/<tag>
service : login, tag : test https://test.example.com/home/login/web <tag>.example.com/home/<service>

Cloud Functions

Ce tableau part du principe que vous disposez d'un domaine personnalisé appelé example.com et que tous vos services Cloud Functions sont mappés sur ce domaine.

Nom de la fonction URL du domaine personnalisé Masque d'URL
login https://example.com/login /<function>
login https://example.com/home/login /home/<function>
login https://login.example.com <function>.example.com
login https://login.home.example.com <function>.home.example.com

App Engine

Ce tableau part du principe que vous disposez d'un domaine personnalisé appelé example.com et que tous vos services App Engine sont mappés sur ce domaine.

Nom du service, version URL du domaine personnalisé Masque d'URL
service : login https://login.example.com/web <service>.example.com
service : login https://example.com/home/login/web example.com/home/<service> ou /home/<service>
service : login, version : test https://test.example.com/login/web <version>.example.com/<service>
service : login, version : test https://example.com/login/test example.com/<service>/<version>

API Gateway

Ce tableau part du principe que vous disposez d'un domaine personnalisé appelé example.com et que tous vos services API Gateway sont mappés sur ce domaine.

Nom de la passerelle URL de domaine personnalisé API Gateway (bêta) Masque d'URL
connexion https://example.com/login /<gateway>
connexion https://example.com/home/login /home/<gateway>
connexion https://login.example.com <gateway>.example.com
connexion https://login.home.example.com <gateway>.home.example.com

Créer un NEG sans serveur avec un masque d'URL

Console

Pour un nouvel équilibreur de charge, vous pouvez utiliser le même processus de bout en bout que celui décrit précédemment dans cet article. Au lieu de sélectionner un service spécifique lors de la configuration du service de backend, saisissez un masque d'URL.

Si vous disposez déjà d'un équilibreur de charge, vous pouvez modifier la configuration du backend et faire en sorte que le NEG sans serveur pointe vers un masque d'URL au lieu d'un service spécifique.

Pour ajouter un NEG sans serveur basé sur un masque d'URL à un service de backend existant, procédez comme suit :

  1. Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
    Accéder à la page Équilibrage de charge
  2. Cliquez sur le nom de l'équilibreur de charge dont vous souhaitez modifier le service de backend.
  3. Sur la page Détails de l'équilibreur de charge, cliquez sur Modifier .
  4. Sur la page Modifier l'équilibreur de charge d'application externe global, cliquez sur Configuration du backend.
  5. Sur la page Configuration du backend, cliquez sur le bouton Modifier correspondant au service de backend que vous souhaitez modifier.
  6. Cliquez sur Ajouter le backend.
  7. Sélectionnez Créer un groupe de points de terminaison du réseau sans serveur.
    1. Dans le champ Nom, saisissez helloworld-serverless-neg.
    2. Sous Région, sélectionnez us-central1.
    3. Sous Type de groupe de points de terminaison du réseau sans serveur, sélectionnez la plate-forme sur laquelle vos applications sans serveur (ou services ou fonctions) ont été créées.
      1. Sélectionnez Utiliser un masque d'URL.
      2. Saisissez un masque d'URL. Pour obtenir des instructions sur la création d'un masque d'URL, consultez la section sur la création de masque d'URL.
      3. Cliquez sur Créer.
  8. Dans la section Nouveau backend, cliquez sur Terminé.
  9. Cliquez sur Update (Mettre à jour).

gcloud : Cloud Run

Pour créer un NEG sans serveur avec un exemple de masque d'URL example.com/<service>, exécutez la commande suivante :

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

gcloud : Cloud Functions

Pour créer un NEG sans serveur avec un exemple de masque d'URL example.com/<service>, exécutez la commande suivante :

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud : App Engine

Pour créer un NEG sans serveur avec un exemple de masque d'URL example.com/<service>, exécutez la commande suivante :

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud : API Gateway

Pour créer un NEG sans serveur avec un exemple de masque d'URL example.com/<gateway>, exécutez la commande suivante :

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

Pour savoir comment l'équilibreur de charge gère les problèmes d'incohérences des masques d'URL, consultez la section Résoudre les problèmes liés aux NEG sans serveur.

Déplacer votre domaine personnalisé à diffuser via l'équilibreur de charge d'application externe

Si vos applications d'informatique sans serveur sont mappées à des domaines personnalisés, vous pouvez mettre à jour vos enregistrements DNS afin que le trafic envoyé aux URL de domaines personnalisés Cloud Run, Cloud Functions, API Gateway ou App Engine soit acheminé via l'équilibreur de charge.

Par exemple, si vous disposez d'un domaine personnalisé appelé example.com et que tous vos services Cloud Run sont mappés sur ce domaine, vous devez mettre à jour l'enregistrement DNS afin que example.com pointe vers l'adresse IP de l'équilibreur de charge.

Avant de mettre à jour les enregistrements DNS, vous pouvez tester votre configuration localement en forçant la résolution DNS locale du domaine personnalisé sur l'adresse IP de l'équilibreur de charge. Pour effectuer un test en local, modifiez le fichier /etc/hosts/ sur votre ordinateur local de sorte que example.com pointe vers l'adresse IP de l'équilibreur de charge, ou utilisez l'option curl --resolve afin de forcer curl à utiliser l'adresse IP de l'équilibreur de charge pour la requête.

Lorsque l'enregistrement DNS de example.com renvoie à l'adresse IP de l'équilibreur de charge HTTPS, les requêtes envoyées à example.com commencent à être acheminées via l'équilibreur de charge. L'équilibreur de charge les distribue au service de backend approprié en fonction de son mappage d'URL. En outre, si le service de backend est configuré avec un masque d'URL, le NEG sans serveur utilise celui-ci pour acheminer la requête vers le service Cloud Run, Cloud Functions, API Gateway ou App Engine approprié.

Enable Cloud CDN

L'activation de Cloud CDN pour votre service Cloud Run vous permet d'optimiser la diffusion de contenu via la mise en cache du contenu à proximité de vos utilisateurs.

Vous pouvez activer Cloud CDN sur les services de backend utilisés par les équilibreurs de charge d'application externes globaux en utilisant la commande gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

Cloud CDN est disponible pour les services de backend avec Cloud Run, Cloud Functions, API Gateway et App Engine.

Activer IAP sur l'équilibreur de charge d'application externe

Remarque : IAP n'est pas compatible avec Cloud CDN.

Vous pouvez configurer IAP pour l'activer ou le désactiver (par défaut). Si cette option est activée, vous devez fournir des valeurs pour oauth2-client-id et oauth2-client-secret.

Pour activer IAP, mettez à jour le service de backend afin d'inclure l'indicateur --iap=enabled avec oauth2-client-id et oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

Activer Google Cloud Armor

Google Cloud Armor est un produit de sécurité qui fournit une protection contre les attaques par déni de service distribué (DDoS) sur tous les équilibreurs de charge proxy GCLB. Google Cloud Armor fournit également des stratégies de sécurité configurables aux services accessibles via un équilibreur de charge d'application externe. Pour en savoir plus sur les règles de sécurité de Google Cloud Armor pour les équilibreurs de charge d'application externes, consultez la page Présentation des règles de sécurité Google Cloud Armor.

Si vous utilisez Cloud Functions, vous pouvez vous assurer que les requêtes envoyées aux URL par défaut sont bloquées en utilisant le paramètre d'entrée internal-and-gclb.

Si vous utilisez Cloud Run, vous pouvez vous assurer que les requêtes envoyées aux URL par défaut ou à tout autre domaine personnalisé configuré via Cloud Run sont bloquées en limitant les entrées à l'"équilibrage de charge interne et cloud.".

Si vous utilisez App Engine, vous pouvez utiliser les contrôles d'entrée pour que votre application ne reçoive que les requêtes envoyées par l'équilibreur de charge (et le VPC si vous l'utilisez).

Sans les paramètres d'entrée appropriés, les utilisateurs peuvent utiliser l'URL par défaut de votre application sans serveur pour contourner l'équilibreur de charge, les règles de sécurité Google Cloud Armor, les certificats SSL et les clés privées qui sont transmises via l'équilibreur de charge.

Facultatif : Configurez une règle de sécurité de backend par défaut. La stratégie de sécurité par défaut limite le trafic au-delà d'un seuil configuré par l'utilisateur. Pour en savoir plus sur les stratégies de sécurité par défaut, consultez la page Présentation de la limitation du débit.

  1. Pour désactiver la stratégie de sécurité par défaut de Google Cloud Armor, sélectionnez None dans le menu de la liste des stratégies de sécurité backend.
  2. Dans la section Sécurité, sélectionnez Stratégie de sécurité par défaut.
  3. Dans le champ Nom de la règle, acceptez le nom généré automatiquement ou saisissez un nom pour votre stratégie de sécurité.
  4. Dans le champ Nombre de requêtes, acceptez le nombre de requêtes par défaut ou saisissez un nombre entier compris entre 1 et 10,000.
  5. Dans le champ Intervalle, sélectionnez un intervalle.
  6. Dans le champ Appliquer à la clé, choisissez l'une des valeurs suivantes : Tous, Adresse IP ou Adresse IP X-Forwarded-For. Pour en savoir plus sur ces options, consultez la section Identifier les clients pour la limitation du débit.

Activer la journalisation et la surveillance

Vous pouvez activer, désactiver et afficher les journaux d'un service de backend d'équilibreur de charge d'application externe. Lorsque vous utilisez Google Cloud Console, la journalisation est activée par défaut pour les services de backend avec des backends NEG sans serveur. Vous pouvez utiliser gcloud afin de désactiver la journalisation pour chaque service de backend si nécessaire. Pour obtenir des instructions, consultez la page Journalisation.

L'équilibreur de charge exporte également les données de surveillance vers Cloud Monitoring. Les métriques de surveillance peuvent être utilisées pour évaluer la configuration, l'utilisation et les performances d'un équilibreur de charge. Les métriques peuvent également être utilisées pour résoudre les problèmes, et améliorer l'utilisation des ressources et l'expérience utilisateur. Pour obtenir des instructions, consultez la page Surveillance.

Mettre à jour le délai d'expiration du message keepalive HTTP client

L'équilibreur de charge créé lors des étapes précédentes a été configuré avec une valeur par défaut pour le délai d'expiration du message keepalive HTTP du client. Pour mettre à jour le délai d'expiration du message HTTP du client, suivez les instructions ci-dessous.

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accédez à la page "Équilibrage de charge".

  2. Cliquez sur le nom de l'équilibreur de charge que vous souhaitez modifier.
  3. Cliquez sur Modifier ().
  4. Cliquez sur Configuration de l'interface.
  5. Développez la section Fonctionnalités avancées. Dans le champ Délai avant expiration du message keepalive HTTP, saisissez une valeur de délai avant expiration comprise entre 5 et 1 200 secondes.
  6. Cliquez sur Update (Mettre à jour).
  7. Pour vérifier vos modifications, cliquez sur Vérification et finalisation, puis sur Mettre à jour.

gcloud

Pour un équilibreur de charge HTTP, mettez à jour le proxy HTTP cible à l'aide de la commande gcloud compute target-http-proxies update :

    gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Pour un équilibreur de charge HTTPS, mettez à jour le proxy HTTPS cible à l'aide de la commande gcloud compute target-https-proxies update :

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

Remplacez les éléments suivants :

  • TARGET_HTTP_PROXY_NAME: nom du proxy HTTP cible.
  • TARGET_HTTPS_PROXY_NAME : nom du proxy HTTPS cible.
  • HTTP_KEEP_ALIVE_TIMEOUT_SEC: valeur du délai avant expiration du message keepalive HTTP comprise entre 5 et 1 200 secondes.

Activer la détection des anomalies

Vous pouvez activer la détection des anomalies sur les services de backend globaux pour identifier les NEG sans serveur non opérationnels et réduire le nombre de requêtes envoyées aux NEG sans serveur non opérationnels.

La détection des anomalies est activée sur le service de backend à l'aide de l'une des méthodes suivantes :

  • La méthode consecutiveErrors (outlierDetection.consecutiveErrors), dans laquelle un code d'état HTTP de la série 5xx est considéré comme une erreur.
  • La méthode consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), dans laquelle seuls les codes d'état HTTP 502, 503 et 504 sont considérés comme des erreurs.

Procédez comme suit pour activer la détection des anomalies pour un service de backend existant. Sachez que même après l'activation de la détection des anomalies, certaines requêtes peuvent être envoyées au service non opérationnel et renvoyer un code d'état 5xx aux clients. Pour réduire davantage le taux d'erreur, vous pouvez configurer des valeurs plus agressives pour les paramètres de détection des anomalies. Pour en savoir plus, consultez le champ outlierDetection.

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur le nom de l'équilibreur de charge dont vous souhaitez modifier le service de backend.

  3. Sur la page Détails de l'équilibreur de charge, cliquez sur Modifier.

  4. Sur la page Modifier l'équilibreur de charge d'application externe global, cliquez sur Configuration du backend.

  5. Sur la page Configuration du backend, cliquez sur le bouton Modifier correspondant au service de backend que vous souhaitez modifier.

  6. Faites défiler la page vers le bas et développez la section Configurations avancées.

  7. Dans la section Détection des anomalies, cochez la case Activer.

  8. Cliquez sur Modifier pour configurer la détection des anomalies.

    Vérifiez que les options suivantes sont configurées avec ces valeurs :

    Propriété Valeur
    Erreurs consécutives 5
    Intervalle 1000
    Durée d'éjection de base 30000
    Pourcentage maximal d'éjection 50
    Éjection pour erreurs consécutives 100

    Dans cet exemple, l'analyse de détection des anomalies s'exécute toutes les secondes. Si le nombre de codes d'état HTTP 5xx consécutifs reçus par un proxy Envoy est supérieur ou égal à cinq, le point de terminaison de backend est exclu du pool d'équilibrage de charge de ce proxy Envoy pendant 30 secondes. Lorsque le pourcentage d'application est défini sur 100 %, le service de backend exclut les points de terminaison non opérationnels des pools d'équilibrage de charge de ces proxys Envoy spécifiques à chaque exécution de l'analyse de détection des anomalies. Si les conditions d'exclusion sont remplies, jusqu'à 50 % des points de terminaison de backend du pool d'équilibrage de charge peuvent être exclus.

  9. Cliquez sur Enregistrer.

  10. Pour mettre à jour le service de backend, cliquez sur Mettre à jour.

  11. Pour mettre à jour l'équilibreur de charge, sur la page Modifier l'équilibreur de charge d'application externe global, cliquez sur Mettre à jour.

gcloud

  1. Exportez le service de backend dans un fichier YAML.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

    Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

  2. Modifiez la configuration YAML du service de backend pour ajouter les champs de détection des anomalies, comme indiqué dans la configuration YAML suivante.

    Dans cet exemple, l'analyse de détection des anomalies s'exécute toutes les secondes. Si le nombre de codes d'état HTTP 5xx consécutifs reçus par un proxy Envoy est supérieur ou égal à cinq, le point de terminaison de backend est exclu du pool d'équilibrage de charge de ce proxy Envoy pendant 30 secondes. Lorsque le pourcentage d'application est défini sur 100 %, le service de backend exclut les points de terminaison non opérationnels des pools d'équilibrage de charge de ces proxys Envoy spécifiques à chaque exécution de l'analyse de détection des anomalies. Si les conditions d'exclusion sont remplies, jusqu'à 50 % des points de terminaison de backend du pool d'équilibrage de charge peuvent être exclus. 

    name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...

    Remplacez les éléments suivants :

    • BACKEND_SERVICE_NAME : nom du service de backend.
    • PROJECT_ID : ID de votre projet
    • REGION_A et REGION_B : régions dans lesquelles l'équilibreur de charge a été configuré.
    • SERVERLESS_NEG_NAME : nom du premier NEG sans serveur.
    • SERVERLESS_NEG_NAME_2 : nom du deuxième NEG sans serveur.

  3. Mettez à jour le service de backend en important la dernière configuration.

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global

    La détection des anomalies est désormais activée sur le service de backend.

Supprimer un NEG sans serveur

Un groupe de points de terminaison du réseau ne peut pas être supprimé s'il est associé à un service de backend. Avant de supprimer un NEG, assurez-vous qu'il est dissocié du service de backend.

Console

  1. Pour vous assurer que le NEG sans serveur que vous souhaitez supprimer n'est actuellement utilisé par aucun service de backend, accédez à l'onglet Services de backend du menu avancé de l'équilibrage de charge.
    Accéder à l'onglet Services de backend
  2. Si le NEG sans serveur est actuellement utilisé :
    1. Cliquez sur le nom du service de backend utilisant le NEG sans serveur.
    2. Cliquez sur Modifier .
    3. Dans la liste des Backends, cliquez sur pour supprimer le backend NEG sans serveur du service de backend.
    4. Cliquez sur Enregistrer.
  3. Accédez à la page Groupe de points de terminaison du réseau dans la console Google Cloud.
    Accéder à la page Groupes de points de terminaison du réseau
  4. Cochez la case correspondant au NEG sans serveur que vous souhaitez supprimer.
  5. Cliquez sur Supprimer.
  6. Cliquez à nouveau sur Supprimer pour confirmer votre choix.

gcloud

Pour supprimer un NEG sans serveur d'un service de backend, vous devez spécifier la région dans laquelle le NEG a été créé. Vous devez également spécifier l'option --global, car helloworld-backend-service est une ressource globale.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

Pour supprimer le NEG sans serveur, exécutez la commande suivante :

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Étape suivante