Configurer un équilibreur de charge d'application interne interrégional avec des buckets Cloud Storage

Ce document explique comment créer un équilibreur de charge d'application interne interrégional afin d'acheminer les requêtes de contenu statique vers des buckets Cloud Storage.

Avant de commencer

Assurez-vous que votre configuration remplit les conditions préalables suivantes.

Installer Google Cloud CLI

Certaines instructions de ce guide ne peuvent être exécutées qu'à l'aide de Google Cloud CLI. Pour l'installer, consultez le document Installer gcloud CLI.

Vous trouverez des commandes liées à l'équilibrage de charge dans la documentation de référence de l'API et de gcloud CLI.

Autorisations

Pour suivre ce guide, vous devez créer des buckets Cloud Storage et des ressources réseau dans votre 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 réseaux, des sous-réseaux et des composants de l'équilibreur de charge Rôle d'administrateur de réseaux Compute (roles/compute.networkAdmin)
Ajouter et supprimer des règles de pare-feu Rôle d'administrateur de sécurité de Compute (roles/compute.securityAdmin)
Créer des buckets Cloud Storage Rôle Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin)

Pour en savoir plus, consultez les guides suivants :

Configurer une ressource de certificat SSL

Pour un équilibreur de charge d'application interne interrégional qui utilise HTTPS comme protocole de requête et de réponse, créez une ressource de certificat SSL à l'aide de Certificate Manager, comme décrit dans l'un des documents suivants :

Après avoir créé le certificat, vous pouvez l'associer au proxy cible HTTPS.

Nous vous recommandons d'utiliser un certificat géré par Google.

Limites

Les limites suivantes s'appliquent aux buckets Cloud Storage lorsqu'ils servent de backends à un équilibreur de charge d'application interne interrégional :

  • L'accès aux buckets privés n'est pas pris en charge. Le bucket backend doit donc être accessible publiquement sur Internet.

  • Les URL signées ne sont pas acceptées.

  • L'intégration de Cloud CDN n'est pas disponible lorsque vous créez des buckets backend pour un équilibreur de charge d'application interne interrégional.

  • Lorsque vous utilisez un équilibreur de charge d'application interne interrégional pour accéder aux buckets backend, seule la méthode HTTP GET est acceptée. Vous pouvez télécharger du contenu depuis le bucket, mais vous ne pouvez pas en importer via l'équilibreur de charge d'application interne interrégional.

Vue d'ensemble de la configuration

Vous pouvez configurer un équilibreur de charge d'application interne interrégional dans plusieurs régions, comme illustré dans le schéma suivant :

Un équilibreur de charge d'application interne interrégional envoie du trafic vers un backend Cloud Storage.
Distribuer le trafic vers Cloud Storage (cliquez pour agrandir)

Comme le montre le schéma d'architecture, cet exemple crée un équilibreur de charge d'application interne interrégional dans un réseau de cloud privé virtuel (VPC) avec deux buckets de backend, où chaque bucket backend fait référence à un bucket Cloud Storage. Les buckets Cloud Storage se trouvent dans les régions us-east1 et asia-east1.

Cette architecture de déploiement offre une haute disponibilité. Si l'équilibreur de charge d'application interne interrégional d'une région échoue, les règles de routage DNS acheminent le trafic vers un équilibreur de charge d'application interne interrégional d'une autre région.

Configurer le réseau et les sous-réseaux

Au sein du réseau VPC, configurez un sous-réseau dans chaque région où la règle de transfert de vos équilibreurs de charge doit être configurée. En outre, configurez un proxy-only-subnet dans chaque région où vous souhaitez configurer l'équilibreur de charge.

Cet exemple utilise le réseau VPC, la région et les sous-réseaux suivants :

  • Réseau : le réseau est un réseau VPC en mode personnalisé nommé lb-network.

  • Sous-réseaux pour l'équilibreur de charge. Un sous-réseau nommé subnet-us dans la région us-east1 utilise 10.1.2.0/24 pour sa plage d'adresses IP principale. Un sous-réseau nommé subnet-asia dans la région asia-east1 utilise 10.1.3.0/24 pour sa plage d'adresses IP principale.

  • Sous-réseau pour les proxys Envoy. Un sous-réseau nommé proxy-only-subnet-us-east1 dans la région us-east1 utilise 10.129.0.0/23 pour sa plage d'adresses IP principale. Un sous-réseau nommé proxy-only-subnet-asia-east1 dans la région asia-east1 utilise 10.130.0.0/23 pour sa plage d'adresses IP principale.

Les équilibreurs de charge d'application internes interrégionaux sont accessibles depuis n'importe quelle région du VPC. Ainsi, les clients de n'importe quelle région peuvent accéder aux backends de votre équilibreur de charge à l'échelle mondiale.

Configurer les sous-réseaux pour la règle de transfert de l'équilibreur de charge

Console

  1. Dans la console Trusted Cloud , accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur Créer un réseau VPC.

  3. Dans le champ Nom, saisissez lb-network.

  4. Dans la section Sous-réseaux, définissez le Mode de création du sous-réseau sur Personnalisé.

  5. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

    • Nom : subnet-us
    • Sélectionnez une région : us-east1.
    • Plage d'adresses IP : 10.1.2.0/24

  6. Cliquez sur OK.

  7. Cliquez sur Ajouter un sous-réseau.

  8. Créez un autre sous-réseau pour la règle de transfert de l'équilibreur de charge dans une autre région. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

    • Nom : subnet-asia
    • Région : asia-east1
    • Plage d'adresses IP : 10.1.3.0/24

  9. Cliquez sur OK.

  10. Cliquez sur Créer.

gcloud

  1. Créez un réseau VPC personnalisé nommé lb-network à l'aide de la commande gcloud compute networks create.

    gcloud compute networks create lb-network --subnet-mode=custom

  2. Créez un sous-réseau dans le réseau VPC lb-network de la région us-east1 à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create subnet-us \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-east1

  3. Créez un sous-réseau dans le réseau VPC lb-network de la région asia-east1 à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create subnet-asia \
    --network=lb-network \
    --range=10.1.3.0/24 \
    --region=asia-east1

Configurer les sous-réseaux proxy réservés

Un sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Trusted Cloud by S3NS pour exécuter des proxys Envoy en votre nom. Les proxys interrompent les connexions du client et créent de nouvelles connexions vers les backends.

Ce sous-réseau proxy réservé est utilisé par tous les équilibreurs de charge régionaux basés sur Envoy dans la même région que le réseau VPC. Il ne peut y avoir qu'un seul sous-réseau proxy réservé actif pour une utilisation donnée, par région et par réseau. Dans cet exemple, nous créons deux sous-réseaux proxy réservés : l'un dans la région us-east1 et l'autre dans la région asia-east1.

Console

  1. Dans la console Trusted Cloud , accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur le nom du réseau VPC que vous avez créé.

  3. Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.

  4. Saisissez les informations suivantes :

    • Dans le champ Nom, saisissez proxy-only-subnet-us.
    • Pour Région, saisissez us-east1.
    • Pour Objectif, sélectionnez Proxy géré interrégional.
    • Dans Plage d'adresses IP, saisissez 10.129.0.0/23.

  5. Cliquez sur Ajouter.

  6. Créez un autre sous-réseau proxy réservé dans la région asia-east1. Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.

  7. Saisissez les informations suivantes :

    • Dans le champ Nom, saisissez proxy-only-subnet-asia.
    • Pour Région, saisissez asia-east1.
    • Pour Objectif, sélectionnez Proxy géré interrégional.
    • Dans Plage d'adresses IP, saisissez 10.130.0.0/23.

  8. Cliquez sur Ajouter.

gcloud

  1. Créez un sous-réseau proxy réservé dans la région us-east1 à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create proxy-only-subnet-us \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-east1 \
    --network=lb-network \
    --range=10.129.0.0/23

  2. Créez un sous-réseau proxy réservé dans la région asia-east1 à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create proxy-only-subnet-asia \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=asia-east1 \
    --network=lb-network \
    --range=10.130.0.0/23

Configurer une règle de pare-feu

Cet exemple utilise la règle de pare-feu suivante :

  • Règle d'entrée autorisant l'accès SSH sur le port 22 à la VM cliente. Dans cet exemple, cette règle de pare-feu est nommée fw-allow-ssh.

Console

  1. Dans la console Trusted Cloud , accédez à la page Règles de pare-feu.

    Accéder aux stratégies de pare-feu

  2. Cliquez sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes sur la VM cliente :

    • Nom : fw-allow-ssh
    • Réseau : lb-network
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : Tags cibles spécifiés
    • Tags cibles : allow-ssh
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 0.0.0.0/0
    • Protocoles et ports :
      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case TCP, puis saisissez 22 pour le numéro de port.

  3. Cliquez sur Créer.

gcloud

  1. Créez la règle de pare-feu fw-allow-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez --source-ranges,Trusted Cloud interprète la règle comme désignant n'importe quelle source.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Configurer vos buckets Cloud Storage

Le processus de configuration des buckets Cloud Storage est le suivant :

  • Créez les buckets.
  • Copiez le contenu dans les buckets.

Créer des buckets Cloud Storage

Dans cet exemple, vous allez créer deux buckets Cloud Storage, l'un dans la région us-east1 et l'autre dans la région asia-east1. Pour les déploiements de production, nous vous recommandons de choisir un bucket multirégional, qui réplique automatiquement les objets sur plusieurs régions Trusted Cloud . Cela peut améliorer la disponibilité de votre contenu et augmenter la tolérance aux pannes au sein de votre application.

Console

  1. Dans la console Trusted Cloud , accédez à la page Buckets de Cloud Storage.

    Accéder à la page "Buckets"

  2. Cliquez sur  Créer.

  3. Dans le champ Nommer votre bucket, saisissez un nom unique qui respecte les consignes de dénomination.

  4. Cliquez sur Choisir où stocker vos données.

  5. Définissez le Type d'emplacement sur Région.

  6. Dans la liste des régions, sélectionnez us-east1.

  7. Cliquez sur Créer.

  8. Cliquez sur Buckets pour revenir à la page des buckets Cloud Storage. Suivez ces instructions pour créer un second bucket, mais définissez le champ Emplacement sur asia-east1.

gcloud

  1. Créez le premier bucket dans la région us-east1 à l'aide de la commande gcloud storage buckets create.

    gcloud storage buckets create gs://BUCKET1_NAME \
    --default-storage-class=standard \
    --location=us-east1 \
    --uniform-bucket-level-access

  2. Créez le deuxième bucket dans la région asia-east1 à l'aide de la commande gcloud storage buckets create.

    gcloud storage buckets create gs://BUCKET2_NAME \
    --default-storage-class=standard \
    --location=asia-east1 \
    --uniform-bucket-level-access

Remplacez les variables BUCKET1_NAME et BUCKET2_NAME par les noms de vos bucket Cloud Storage.

Copier des fichiers graphiques vers vos buckets Cloud Storage

Pour pouvoir tester la configuration, vous allez copier un fichier graphique depuis un bucket Cloud Storage public vers vos propres buckets Cloud Storage.

Exécutez les commandes suivantes dans Cloud Shell en remplaçant les variables de nom de bucket par vos noms de bucket Cloud Storage uniques :

gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/never-fetch/

gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

Rendre vos buckets Cloud Storage lisibles publiquement

Pour rendre tous les objets d'un bucket lisibles par tous sur l'Internet public, attribuez au compte principal allUsers le rôle Lecteur des objets Storage (roles/storage.objectViewer).

Console

Pour autoriser tous les utilisateurs à afficher des objets dans vos buckets, répétez la procédure suivante pour chaque bucket :

  1. Dans la console Trusted Cloud , accédez à la page Buckets de Cloud Storage.

    Accéder à la page "Buckets"

  2. Dans la liste des buckets, cliquez sur le nom de celui que vous souhaitez rendre public.

  3. Sélectionnez l'onglet Autorisations en haut de la page.

  4. Dans la section Autorisations, cliquez sur le bouton Accorder l'accès. La boîte de dialogue Accorder l'accès s'affiche.

  5. Dans le champ Nouveaux comptes principaux, saisissez allUsers.

  6. Dans le champ Sélectionner un rôle, saisissez Storage Object Viewer dans le champ de filtre, puis sélectionnez Lecteur des objets Storage dans les résultats filtrés.

  7. Cliquez sur Enregistrer.

  8. Cliquez sur Autoriser l'accès public.

gcloud

Pour autoriser tous les utilisateurs à afficher les objets de vos buckets, exécutez la commande buckets add-iam-policy-binding.

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME --member=allUsers --role=roles/storage.objectViewer
 
gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME --member=allUsers --role=roles/storage.objectViewer

Remplacez les variables de nom de bucket par les noms uniques de vos buckets Cloud Storage.

Configurer l'équilibreur de charge avec des buckets backend

Cette section vous explique comment créer les ressources suivantes pour un équilibreur de charge d'application interne interrégional :

Dans cet exemple, vous pouvez utiliser HTTP ou HTTPS comme protocole de requête et de réponse entre le client et l'équilibreur de charge. Pour créer un équilibreur de charge HTTPS, vous devez ajouter une ressource de certificat SSL au frontal de l'équilibreur de charge.

Pour créer les composants d'équilibrage de charge mentionnés ci-dessus à l'aide de la gcloud CLI, procédez comme suit :

  1. Créez deux buckets de backend, un dans la région us-east1 et l'autre dans la région asia-east1, à l'aide de la commande gcloud compute backend-buckets create. Les buckets backend ont un schéma d'équilibrage de charge INTERNAL_MANAGED.

    gcloud compute backend-buckets create backend-bucket-cats \
    --gcs-bucket-name=BUCKET1_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED

    gcloud compute backend-buckets create backend-bucket-dogs \
    --gcs-bucket-name=BUCKET2_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED

  2. Créez un mappage d'URL pour acheminer les requêtes entrantes vers le bucket backend à l'aide de la commande gcloud compute url-maps create.

    gcloud compute url-maps create lb-map \
    --default-backend-bucket=backend-bucket-cats \
    --global

  3. Configurez les règles d'hôte et de chemin d'accès du mappage d'URL à l'aide de la commande gcloud compute url-maps add-path-matcher.

    Dans cet exemple, le bucket backend par défaut est backend-bucket-cats, qui gère tous les chemins d'accès qu'il contient. Toutefois, toute requête ciblant http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg utilise le backend backend-bucket-dogs. Par exemple, si le dossier /love-to-fetch/ existe également dans votre backend par défaut (backend-bucket-cats), l'équilibreur de charge donne la priorité au backend backend-bucket-dogs, car il existe une règle de chemin d'accès spécifique pour /love-to-fetch/*.

    gcloud compute url-maps add-path-matcher lb-map \
    --path-matcher-name=path-matcher-pets \
    --new-hosts=* \
    --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \
    --default-backend-bucket=backend-bucket-cats

  4. Créez un proxy cible à l'aide de la commande gcloud compute target-http-proxies create.

    Pour le trafic HTTP, créez un proxy HTTP cible qui va acheminer les requêtes vers le mappage d'URL :

    gcloud compute target-http-proxies create http-proxy \
    --url-map=lb-map \
    --global

    Pour le trafic HTTPS, créez un proxy HTTPS cible pour acheminer les requêtes vers le mappage d'URL. Le proxy est la partie de l'équilibreur de charge qui contient le certificat SSL pour un équilibreur de charge HTTPS. Après avoir créé le certificat, vous pouvez l'associer au proxy cible HTTPS.

    gcloud compute target-https-proxies create https-proxy \
    --url-map=lb-map \
    --certificate-manager-certificates=CERTIFICATE_NAME \
    --global

    Remplacez CERTIFICATE_NAME par le nom du certificat SSL que vous avez créé à l'aide du gestionnaire de certificats.

  5. Créez deux règles de transfert globales, l'une avec une adresse IP dans la région us-east1 et l'autre avec une adresse IP dans la région asia-east1 à l'aide de la commande gcloud compute forwarding-rules create.

    Si vous souhaitez réserver une adresse IP interne statique pour la règle de transfert de votre équilibreur de charge, consultez Réserver une adresse IP interne statique. La réservation d'une adresse IP est facultative pour une règle de transfert HTTP. Toutefois, vous devez réserver une adresse IP pour une règle de transfert HTTPS.

    Dans cet exemple, une adresse IP éphémère est associée à la règle de transfert HTTP de votre équilibreur de charge. Une adresse IP éphémère reste constante tant que la règle de transfert existe. Si vous devez supprimer la règle de transfert et la recréer, celle-ci peut alors recevoir une nouvelle adresse IP.

    Pour le trafic HTTP, créez les règles de transfert globales pour acheminer les requêtes entrantes vers le proxy HTTP cible :

    gcloud compute forwarding-rules create http-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=subnet-us \
    --subnet-region=us-east1 \
    --ports=80 \
    --target-http-proxy=http-proxy \
    --global-target-http-proxy \
    --global

    gcloud compute forwarding-rules create http-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=subnet-asia \
    --subnet-region=asia-east1 \
    --ports=80 \
    --target-http-proxy=http-proxy \
    --global-target-http-proxy \
    --global

    Pour le trafic HTTPS, créez les règles de transfert globales pour acheminer les requêtes entrantes vers le proxy cible HTTPS :

    gcloud compute forwarding-rules create https-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global

    gcloud compute forwarding-rules create https-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global

Envoyer une requête HTTP à l'équilibreur de charge

Envoyez une requête depuis une VM cliente interne à la règle de transfert de l'équilibreur de charge.

Obtenir l'adresse IP de la règle de transfert de l'équilibreur de charge

  1. Obtenez l'adresse IP de la règle de transfert de l'équilibreur de charge (http-fw-rule-1), qui se trouve dans la région us-east1.

    gcloud compute forwarding-rules describe http-fw-rule-1 \
    --global

  2. Obtenez l'adresse IP de la règle de transfert de l'équilibreur de charge (http-fw-rule-2), qui se trouve dans la région asia-east1.

    gcloud compute forwarding-rules describe http-fw-rule-2 \
    --global

Créer une VM cliente pour tester la connectivité

  1. Créez une VM cliente dans la région us-east1.

    gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh

  2. Établissez une connexion SSH avec la VM cliente.

    gcloud compute ssh client-a --zone=us-east1-c

  3. Dans cet exemple, l'équilibreur de charge d'application interne interrégional possède des adresses IP virtuelles d'interface dans les régions us-east1 et asia-east1 du réseau VPC. Envoyez une requête HTTP au VIP dans l'une des régions à l'aide de curl.

    curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg

    curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg

Tester la haute disponibilité

  1. Supprimez la règle de transfert (http-fw-rule-1) dans la région us-east1 pour simuler une panne régionale et vérifiez si le client de la région us-east peut toujours accéder aux données du bucket backend.

    gcloud compute forwarding-rules delete http-fw-rule-1 \
    --global

  2. Envoyez une requête HTTP à l'adresse IP virtuelle de la règle de transfert dans l'une ou l'autre région à l'aide de curl.

    curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg

    curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg

    Si vous envoyez une requête HTTP à l'adresse IP virtuelle dans la région us-east1, les règles de routage DNS détectent que cette adresse IP virtuelle ne répond pas et renvoient l'adresse IP virtuelle optimale suivante au client (dans cet exemple, asia-east1). Ce comportement permet de s'assurer que votre application reste opérationnelle même en cas de panne régionale.

Étapes suivantes