Configurer la vérification d'état active pour le basculement régional avec PSC

Cette page s'applique à Apigee, mais pas à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

Ce document explique comment configurer Apigee pour la vérification de l'état active dans les cas où vous souhaitez utiliser Private Service Connect (PSC) pour le routage réseau Northbound (trafic des clients vers Apigee). La vérification de l'état active permet d'éviter la perte de trafic réseau en cas de défaillance régionale.

Présentation

Si vous prévoyez d'utiliser PSC pour le routage réseau Northbound Apigee, suivez les instructions de ce document pour configurer la vérification d'état active. Pour le moment, la surveillance active des vérifications de l'état n'est pas compatible avec PSC. Pour contourner cette limitation de PSC, vous pouvez modifier la configuration d'installation d'Apigee afin d'utiliser un groupe d'instances géré (MIG), qui offre une fonctionnalité de vérification de l'état active.

Vous pouvez utiliser la détection des anomalies pour surveiller l'état. Toutefois, en cas de défaillances régionales, vous risquez de perdre régulièrement une partie du trafic, car la détection des anomalies utilise le trafic en temps réel comme indicateur. La détection des anomalies redirige régulièrement une partie du trafic en direct pour vérifier l'état de la région défaillante.

La figure 1 illustre l'architecture proposée. Un point de terminaison de service se connecte au rattachement de service dans l'instance Apigee, et un MIG fait office de proxy pour le trafic vers le point de terminaison de service. Vous activez la surveillance des vérifications de l'état sur le MIG.

Figure 1. Architecture Apigee pour la vérification active de l'état sans appairage de VPC.

Approche de la vérification de l'état basée sur les MIG

Prérequis

Vous pouvez appliquer la technique décrite dans ce document aux installations Apigee qui utilisent ou non l'appairage de VPC. Toutefois, dans le cas d'une installation VPC appairée, la technique active de vérification de l'état décrite ici ne s'applique que si vous utilisez PSC pour votre configuration de routage.

Avant d'effectuer les étapes de cette section, procédez comme suit :

• Pour les installations non VPC :
  1. Suivez les étapes de provisionnement Apigee 1 à 6 pour les installations basées sur un abonnement ou le paiement à l'usage. Pour le moment, la seule option consiste à effectuer ces étapes à l'aide de l'interface de ligne de commande.
  2. Ignorez l'étape 7 : Configurez le routage et suivez plutôt les étapes ci-dessous.
• Pour les installations d'appairage de VPC qui utilisent PSC pour le routage :
  1. Suivez les étapes de provisionnement Apigee 1 à 7 pour les installations basées sur un abonnement ou le paiement à l'usage. Pour le moment, la seule option consiste à effectuer ces étapes à l'aide de l'interface de ligne de commande.
  2. Ignorez l'étape 8 : Configurez le routage et suivez plutôt les étapes ci-dessous.

1. Configurer un point de terminaison de service PSC pour le rattachement de service Apigee

Au cours de cette étape, vous allez créer un point de terminaison de service PSC qui pointe vers le rattachement de service dans l'instance Apigee :

1. Récupérez le rattachement de service à partir de l'instance Apigee que vous avez créée précédemment :

   curl -i -X GET -H "Authorization: Bearer $AUTH" \
     "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   Dans l'exemple de résultat suivant, la valeur serviceAttachment est indiquée en gras :

   {
     "instances": [
       {
         "name": "us-west1",
         "location": "us-west1",
         "host": "10.82.192.2",
         "port": "443",
         "createdAt": "1645731488019",
         "lastModifiedAt": "1646504754219",
         "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
         "state": "ACTIVE",
         "peeringCidrRange": "SLASH_22",
         "runtimeVersion": "1-7-0-20220228-190814",
         "ipRange": "10.82.192.0/22,10.82.196.0/28",
         "consumerAcceptList": [
           "875609189304"
         ],
         "serviceAttachment": "projects/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1"
       }
     ]
   }

   Remarque : L'ID du projet que vous avez utilisé pour créer votre organisation Apigee apparaît toujours dans la liste consumerAcceptList. Dans l'exemple de résultat présenté ci-dessus, il s'agit du seul projet de la liste.
2. Créez un point de terminaison de service PSC qui pointe vers le rattachement de service obtenu à partir du corps de réponse de l'instance à l'étape précédente, comme expliqué dans la section Créer un point de terminaison Private Service Connect.

2. Configurer un MIG qui pointe vers le point de terminaison du service

Au cours de cette étape, vous allez créer un MIG qui fait office de proxy pour le trafic vers le point de terminaison du service. Vous pouvez ensuite activer la vérification active de l'état sur le MIG.

Autorisations requises pour cette tâche

Vous pouvez attribuer à l'approvisionneur Apigee un rôle prédéfini qui inclut les autorisations nécessaires pour effectuer cette tâche, ou définir des autorisations plus précises selon le principe du moindre privilège. Consultez les sections Rôles prédéfinis et Autorisations de routage des accès.

Remarque : Les groupes d'instances gérés ne sont pas globaux, mais régionaux. Par conséquent, pour l'emplacement multirégional, vous devez créer un groupe d'instances géré pour chaque région et l'ajouter au service de backend de l'équilibreur de charge global.

2A. Activez l'accès privé à Google pour un sous-réseau de votre réseau VPC.

Pour activer l'accès privé à Google pour un sous-réseau de votre réseau VPC, suivez la procédure décrite dans la section Activer l'accès privé à Google.

Remarque : Si vous effectuez une configuration multirégionale, vous devez effectuer cette étape une fois pour chaque région.

2B. Définir des variables d'environnement

Multirégional : une configuration multirégionale nécessite un MIG distinct pour chaque région.

Les instructions de cette section utilisent des variables d'environnement pour faire référence à des chaînes utilisées de manière répétée. Nous vous recommandons de les définir avant de continuer :

MIG_NAME=YOUR_MIG_NAME  # A name you provide for the MIG
VPC_NAME=default       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=default     # Private Google Access must be enabled for this subnet
REGION=RUNTIME_REGION        # The same region as your Apigee runtime instance
SERVICE_ENDPOINT_IP=YOUR_SERVICE_ENDPOINT_IP.  ## The endpoint IP of the service endpoint you just created

Vous utiliserez ces variables plusieurs fois au cours des processus restants. Si vous souhaitez configurer plusieurs régions, créez des variables avec des valeurs spécifiques à chaque région.

2C. Créer un groupe d'instances géré

Multirégional : une configuration multirégionale nécessite un MIG distinct pour chaque région. Si vous configurez plusieurs régions, répétez les étapes 2b et 2c pour chaque région, en remplaçant les variables appropriées pour chaque région.

Au cours de cette étape, vous allez créer et configurer un groupe d'instances géré.

1. Créez un modèle d'instance en exécutant la commande suivante.

   gcloud compute instance-templates create $MIG_NAME \
   --project $PROJECT_ID \
   --region $REGION \
   --network $VPC_NAME \
   --subnet $VPC_SUBNET \
   --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
   --machine-type e2-medium --image-family debian-12 \
   --image-project debian-cloud --boot-disk-size 20GB \
   --no-address \
   --metadata ENDPOINT=$SERVICE_ENDPOINT_IP,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

   Comme vous pouvez le voir avec cette commande, les machines sont de type e2-medium. Elle exécute Debian 12 et dispose de 20 Go d'espace disque. Le script startup-script.sh configure le groupe d'instances géré pour acheminer le trafic entrant de l'équilibreur de charge vers l'instance Apigee.

2. Créez un groupe d'instances géré en exécutant la commande suivante :

   gcloud compute instance-groups managed create $MIG_NAME \
   --project $PROJECT_ID --base-instance-name apigee-mig \
   --size 2 --template $MIG_NAME --region $REGION

3. Configurez l'autoscaling pour le groupe en exécutant la commande suivante :
   Remarque : Un MIG régional avec des instances e2-medium peut accepter un maximum de 6 Gbit/s. Si cela ne suffit pas à vos besoins en débit, envisagez de redimensionner la VM et/ou d'augmenter le nombre d'instances dupliquées.

   gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
   --project $PROJECT_ID --region $REGION --max-num-replicas 3 \
   --target-cpu-utilization 0.75 --cool-down-period 90

4. Pour définir un port nommé, exécutez la commande suivante :

   gcloud compute instance-groups managed set-named-ports $MIG_NAME \
   --project $PROJECT_ID --region $REGION --named-ports https:443

3. Configurer l'équilibreur de charge avec la surveillance des vérifications de l'état

Dans les étapes suivantes, vous allez configurer un équilibreur de charge avec la surveillance des vérifications de l'état.

3A. Créer un certificat SSL et une clé pour l'équilibreur de charge

Vous ne devez créer les identifiants qu'une seule fois, que vous procédiez à l'installation dans une ou plusieurs régions. Lors d'une prochaine étape, vous associerez ces identifiants au proxy HTTPS cible de l'équilibreur de charge.

Vous pouvez créer les identifiants avec :

• Votre propre certificat émis par une autorité de certification
• Un certificat SSL géré par Google
• Un certificat autosigné (non recommandé en production)

Pour en savoir plus sur la création et l'utilisation de certificats SSL pour l'équilibreur de charge Google Cloud, consultez les pages Certificats SSL et Présentation des certificats SSL.

Dans l'exemple suivant, nous créons un certificat SSL géré par Google :

1. Créez les variables d'environnement suivantes :

   CERTIFICATE_NAME=YOUR_CERT_NAME
   DOMAIN_HOSTNAME=YOUR_DOMAIN_HOSTNAME 

   Définissez DOMAIN_HOSTNAME sur un nom d'hôte de domaine valide que vous avez enregistré. Lors d'une prochaine étape, vous obtiendrez l'adresse IP de l'équilibreur de charge et mettrez à jour l'enregistrement A du domaine afin qu'il pointe vers cette adresse. Par exemple, un nom d'hôte de domaine pourrait ressembler à ceci : foo.example.com.

2. Exécutez la commande gcloud compute ssl-certificates create :

   gcloud compute ssl-certificates create $CERTIFICATE_NAME \
   --domains=$DOMAIN_HOSTNAME \
   --project $PROJECT_ID \
   --global

   Le provisionnement du certificat peut prendre jusqu'à une heure. Pour vérifier l'état du provisionnement, exécutez la commande suivante :

   gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
   --global \
   --format="get(name,managed.status, managed.Status)"

   Remarque : Vous pouvez créer plusieurs enregistrements DNS A pour les noms d'hôte de votre groupe d'environnements, pointant tous vers la même adresse IP d'équilibreur de charge.

3B. Créer une vérification d'état

1. Créez une vérification d'état :

   gcloud compute health-checks create https HEALTH_CHECK_NAME \
   --project $PROJECT_ID --port 443 --global \
   --request-path /healthz/ingress

   Cette vérification d'état vous permettra de vous assurer que le service de backend est en cours d'exécution. Pour configurer des vérifications d'état plus avancées sur un proxy spécifique, consultez la page Effectuer des vérifications d'état.

   Remarque : Si vous rencontrez l'erreur suivante lors de la tentative de création d'une vérification d'état :

   ERROR: unrecognized arguments: --global,

   Essayez de mettre à jour gcloud à l'aide de la commande gcloud components update.

2. Créez un service de backend :

   gcloud compute backend-services create PROXY_BACKEND_NAME \
   --project $PROJECT_ID \
   --protocol HTTPS \
   --health-checks HEALTH_CHECK_NAME \
   --port-name https \
   --timeout 302s \
   --connection-draining-timeout 300s \
   --global

   Remarque : Comme indiqué dans la documentation de référence sur les propriétés des points de terminaison Apigee, l'entrée d'Apigee (équilibreur de charge interne) a un délai avant expiration de 300 secondes par défaut. Le fait de définir le délai avant expiration des services de backend de l'équilibreur de charge sur 302 secondes permet à la commande des services de backend de se terminer entièrement dans Apigee en cas de transactions de longue durée. Si vous définissez cette valeur sur une valeur inférieure, par exemple 60 secondes, le délai d'expiration risque d'être dépassé par l'équilibreur de charge avant la fin de la requête, ce qui génère 502 réponses.
3. Ajoutez le MIG à votre service de backend à l'aide de la commande suivante :
   Multirégional : pour une configuration multirégionale, vous devez créer un MIG distinct pour chaque région. Ensuite, répétez cette étape pour ajouter chaque MIG au service de backend. Veillez à spécifier les variables REGION et MIG_NAME appropriées pour chacune des régions.

   gcloud compute backend-services add-backend PROXY_BACKEND_NAME \
   --project $PROJECT_ID --instance-group $MIG_NAME \
   --instance-group-region $REGION \
   --balancing-mode UTILIZATION --max-utilization 0.8 --global

4. Créez un mappage d'URL d'équilibrage de charge à l'aide de la commande suivante :

   gcloud compute url-maps create MIG_PROXY_MAP_NAME \
   --project $PROJECT_ID --default-service PROXY_BACKEND_NAME

5. Créez un proxy HTTPS cible d'équilibrage de charge à l'aide de la commande suivante :

   gcloud compute target-https-proxies create MIG_HTTPS_PROXY_NAME \
   --project $PROJECT_ID --url-map MIG_PROXY_MAP_NAME \
   --ssl-certificates $CERTIFICATE_NAME

3C. Obtenir une adresse IP réservée et créer des règles de pare-feu

Vous devez attribuer une adresse IP à l'équilibreur de charge, puis créer des règles permettant à l'équilibreur de charge d'accéder au groupe d'instances géré. Vous ne devez effectuer cette étape qu'une seule fois, que vous procédiez à l'installation dans une ou plusieurs régions.

1. Réservez une adresse IP pour l'équilibreur de charge :

   gcloud compute addresses create ADDRESSES_NAME \
   --project $PROJECT_ID \
   --ip-version=IPV4 \
   --global

2. Créez une règle de transfert globale à l'aide de la commande suivante :

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
   --project $PROJECT_ID --address ADDRESSES_NAME --global \
   --target-https-proxy MIG_HTTPS_PROXY_NAME --ports 443

3. Obtenez une adresse IP réservée en exécutant la commande suivante :

   gcloud compute addresses describe ADDRESSES_NAME \
   --project $PROJECT_ID --format="get(address)" --global

4. Étape importante : Accédez au site, à l'hôte DNS ou au FAI sur lequel vos enregistrements DNS sont gérés, et assurez-vous que l'enregistrement DNS de votre domaine renvoie l'adresse IP de l'équilibreur de charge Google Cloud. Cette adresse est la valeur de l'adresse IP renvoyée à la dernière étape. Pour en savoir plus, consultez la section Mettre à jour les enregistrements DNS A et AAAA pour qu'ils pointent vers l'adresse IP de l'équilibreur de charge.
5. Créez une règle de pare-feu qui permet à l'équilibreur de charge d'accéder au groupe d'instances géré à l'aide de la commande suivante :

   gcloud compute firewall-rules create FIREWALL_RULE_NAME \
   --description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
   --project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
   --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

   Notez que les plages d'adresses IP 130.211.0.0/22 et 35.191.0.0/16 sont les plages d'adresses IP sources pour Google Load Balancing. Cette règle de pare-feu permet à Google Cloud Load Balancing de passer des requêtes de vérification d'état au groupe d'instances géré.

Le provisionnement d'Apigee est terminé. Accédez à la page Déployer un exemple de proxy.