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 pour 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

Pour Preview, certaines des instructions de ce guide ne peuvent être exécutées qu'à l'aide de la 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 d'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 du Gestionnaire de certificats, 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 accepté. Par conséquent, le bucket backend doit ê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 prise en charge. Vous pouvez télécharger du contenu depuis le bucket, mais l'importation de contenu dans le bucket via l'équilibreur de charge d'application interne interrégional n'est pas disponible.

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.
Distribution du 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 cloud privé virtuel (VPC) avec deux buckets de backend, où chaque bucket de 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 Google 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 le sous-réseau proxy réservé

Un sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google Cloud 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.

Console

  1. Dans la console Google 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 :

    • Nom : proxy-only-subnet-us
    • Région : us-east1
    • Plage d'adresses IP : 10.129.0.0/23
  5. Cliquez sur Ajouter.

  6. Créez un autre sous-réseau pour la règle de transfert de l'équilibreur de charge dans une autre région. Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.

  7. Saisissez les informations suivantes :

    • Nom : proxy-only-subnet-asia
    • Région : asia-east1
    • Plage d'adresses IP : 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 Google Cloud, accédez à la page Règles d'administration.

    Accéder à la page "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,Google 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 de vos 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 Google 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 Google Cloud, accédez à la page Buckets 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 buckets Cloud Storage.

Copier des fichiers graphiques dans 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 buckets par les noms de vos buckets 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 Google Cloud, accédez à la page Buckets 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 beta compute backend-buckets create. Les buckets de backend ont un schéma d'équilibrage de charge de INTERNAL_MANAGED.

    gcloud beta compute backend-buckets create backend-bucket-cats \
        --gcs-bucket-name=BUCKET1_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED
    
    gcloud beta 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 de 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 qui y existent. 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 la section Réserver une nouvelle adresse IPv4 ou IPv6 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 cible HTTP:

    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 à partir d'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 dispose d'adresses IP virtuelles (VIP) 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érifier 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 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
    

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

Étape suivante