Présentation des mappages d'URL

Les équilibreurs de charge HTTP(S) et Traffic Director de Google Cloud utilisent une ressource de configuration Google Cloud appelée mappage d'URL pour acheminer les requêtes vers des services de backend ou des buckets backend.

Par exemple, avec un équilibreur de charge HTTP(S) externe, vous pouvez utiliser un seul mappage d'URL pour acheminer les requêtes vers différentes destinations en fonction des règles configurées dans le mappage d'URL :

  • Les requêtes pour https://example.com/video sont dirigées vers un service de backend.
  • Les requêtes pour https://example.com/audio sont dirigées vers un autre service de backend.
  • Les requêtes pour https://example.com/images sont dirigées vers un bucket backend Cloud Storage.
  • Les requêtes pour toute autre combinaison d'hôte et de chemin d'accès sont dirigées vers un service de backend par défaut.

Les mappages d'URL sont utilisés avec les produits Google Cloud suivants :

Deux types de ressources de mappage d'URL sont disponibles : global et régional. Le type de ressource que vous utilisez dépend du schéma d'équilibrage de charge du produit.

Produit Schéma d'équilibrage de charge Type de ressource de mappage d'URL Destinations compatibles
Équilibreur de charge HTTP(S) externe EXTERNAL Global, externe Services de backend, buckets backend
Équilibreur de charge HTTP(S) interne INTERNAL_MANAGED Régional, interne Services de backend
Traffic Director INTERNAL_SELF_MANAGED Global, interne Services de backend

Certaines fonctionnalités de mappage d'URL ne sont pas disponibles pour tous les produits. Les mappages d'URL utilisés avec l'équilibrage de charge HTTP(S) interne et Traffic Director sont également compatibles avec plusieurs fonctionnalités avancées de gestion du trafic. Pour en savoir plus sur ces différences, consultez la section Gestion avancée du trafic.

Fonctionnement des mappages d'URL

Lorsqu'une requête arrive au niveau de l'équilibreur de charge, celui-ci l'achemine vers un service de backend ou un bucket backend particulier, en fonction des règles définies dans le mappage d'URL.

Un service de backend représente une collection de backends, qui sont des instances d'une application ou d'un microservice. Un bucket backend est un bucket Google Cloud Storage, qui est couramment utilisé pour héberger du contenu statique, tel que des images.

Pour les équilibreurs de charge HTTP(S) externes, les équilibreurs de charge HTTP(S) internes et Traffic Director, les destinations possibles sont les suivantes :

De plus, un équilibreur de charge HTTP(S) externe accepte les éléments suivants :

  • Bucket backend par défaut
  • Bucket backend autre que celui par défaut

Par exemple, partons de la configuration suivante :

  • Une adresse IP :
    • Toutes les requêtes adressées à votre organisation sont envoyées vers la même adresse IP et le même équilibreur de charge.
    • Le trafic est dirigé vers différents services de backend en fonction de l'URL de la requête.
  • Deux domaines :
    • example.net héberge des vidéos de formation.
    • example.org héberge le site Web de votre entreprise.
  • Quatre ensembles de serveurs :
    • Un ensemble qui héberge le site Web de votre entreprise (service de backend : org-site)
    • Un ensemble qui héberge le site Web contenant l'intégralité des vidéos de formation (service de backend : video-site)
    • Un ensemble qui héberge des vidéos de formation en haute définition (HD) (service de backend : video-hd)
    • Un ensemble qui héberge des vidéos de formation en définition standard (SD) (service de backend : video-sd)

Vous souhaitez organiser l'acheminement du trafic comme suit :

  • Diriger les requêtes adressées à example.org (ou à tout autre domaine que example.net) vers le service de backend org-site
  • Diriger les requêtes adressées à example.net qui ne correspondent pas à des chemins d'accès plus spécifiques vers le service de backend video-site
  • Diriger les requêtes adressées à example.net/video/hd/* vers le service de backend video-hd
  • Diriger les requêtes adressées à example.net/video/sd/* vers le service de backend video-sd.

Le mappage d'URL vous permet de configurer ce type d'acheminement basé sur un hôte et un chemin d'accès.

Exemple de configuration du service (cliquez pour agrandir)
Exemple de configuration d'un service de backend (cliquez pour agrandir)

Dénomination

Chaque mappage d'URL possède un nom. Lorsque vous créez un équilibreur de charge basé sur HTTP(S) à l'aide de Google Cloud Console, un nom est attribué au mappage d'URL. Ce nom est identique à celui de l'équilibreur de charge. Si vous utilisez l'outil de ligne de commande gcloud ou l'API, vous pouvez définir un nom personnalisé pour le mappage d'URL.

Composants de mappage d'URL

Un mappage d'URL est un ensemble de ressources de configuration Google Cloud qui dirigent les requêtes pour des URL vers des services de backend ou des buckets backend. Pour ce faire, le mappage d'URL prend en compte les parties nom d'hôte et chemin d'accès de chaque URL qu'il traite :

  • Un nom d'hôte correspond à la partie nom de domaine d'une URL. Par exemple, dans l'URL http://example.net/video/hd, le nom d'hôte est example.net.
  • Un chemin d'accès est la partie d'une URL qui suit le nom d'hôte et le numéro de port facultatif. Par exemple, dans l'URL http://example.net/video/hd, le chemin d'accès est /video/hd.
Configuration de l'équilibreur de charge avec un mappage d'URL de base (cliquez pour agrandir)
Configuration de l'équilibreur de charge avec un mappage d'URL de base (cliquez pour agrandir)

Ce schéma illustre la structure des objets de configuration d'équilibrage de charge les uns par rapport aux autres.

Vous pouvez spécifier quels services de backend ou buckets backend doivent recevoir les requêtes entrantes à l'aide des paramètres de configuration de mappage d'URL suivants :

  • Service de backend par défaut ou bucket backend par défaut. Lorsque vous créez un mappage d'URL, vous devez spécifier un service de backend par défaut ou un bucket backend par défaut, mais pas les deux. Il s'agit du service de backend ou du bucket backend vers lequel Google Cloud dirigera les requêtes pour les URL contenant n'importe quel nom d'hôte, sauf si une règle d'hôte s'applique.

  • Règle d'hôte (hostRules). Une règle d'hôte dirige les requêtes envoyées à un ou plusieurs noms d'hôte associés vers un seul outil de mise en correspondance des chemins d'accès (pathMatchers). La partie nom d'hôte d'une URL correspond exactement à l'ensemble des noms d'hôte configurés de la règle d'hôte. Dans une règle d'hôte et de chemin d'accès d'un mappage d'URL, si vous omettez l'hôte, la règle correspond à tout hôte demandé. Pour diriger les requêtes destinées à http://example.net/video/hd vers un outil de mise en correspondance des chemins d'accès, vous devez disposer d'une seule règle d'hôte incluant au moins le nom d'hôte example.net. Cette même règle d'hôte peut également traiter les requêtes pour d'autres noms d'hôte, mais elle les dirigera vers le même outil de mise en correspondance des chemins d'accès.

    Si vous avez besoin de diriger les requêtes vers d'autres outils, vous devez utiliser des règles d'hôte différentes. Deux règles d'hôte définies dans un mappage d'URL ne peuvent pas inclure le même nom d'hôte.

    Il est possible de mettre en correspondance tous les noms d'hôte en spécifiant le caractère générique * dans la règle d'hôte. Par exemple, pour les URL http://example.org, http://example.net/video/hd et http://example.com/audio, les trois noms d'hôte example.org, example.net et example.com peuvent être mis en correspondance en spécifiant * dans la règle d'hôte. Il est également possible de mettre en correspondance un nom d'hôte partiel à l'aide du caractère générique *. Par exemple, une règle d'hôte *.example.net est mise en correspondance avec les noms d'hôte foo.example.net et bar.example.net.

    • Numéro du port. Vous pouvez également utiliser le paramètre Règle d'hôte pour spécifier un numéro de port. Par exemple, pour diriger les requêtes example.net vers le port 8080, définissez la règle d'hôte sur example.net:8080.
  • Outil de mise en correspondance des chemins d'accès (pathMatchers). Il s'agit du paramètre de configuration référencé par une règle d'hôte. Il définit la relation entre la partie chemin d'accès d'une URL et le service de backend ou le bucket backend qui doit diffuser la requête. Un outil de mise en correspondance des chemins d'accès se compose de deux éléments :

    • Service de backend par défaut de l'outil de mise en correspondance des chemins d'accès ou bucket backend par défaut de l'outil de mise en correspondance des chemins d'accès. Pour chaque outil, vous devez spécifier au moins un service de backend ou un bucket backend par défaut, mais pas les deux. Il s'agit du service de backend ou du bucket backend vers lequel Google Cloud dirigera les requêtes pour les URL dont les noms d'hôte correspondent à une règle d'hôte associée à l'outil de mise en correspondance des chemins d'accès et dont les chemins d'URL ne correspondent à aucune règle de chemin d'accès dans l'outil.

    • Règles de chemin d'accès Pour chaque outil, vous pouvez spécifier une ou plusieurs règles de chemin d'accès, qui sont des paires clé/valeur mappant un chemin d'URL avec un seul service de backend ou bucket backend. La section suivante contient des informations supplémentaires sur le fonctionnement de ces règles.

Ordre de priorité des opérations

Pour un nom d'hôte et un chemin d'accès donnés spécifiés dans une URL demandée, Google Cloud suit la procédure suivante pour diriger la requête vers le service de backend ou le bucket backend approprié, conformément à la configuration définie dans le mappage d'URL :

  • Si le mappage d'URL ne contient pas de règle d'hôte pour le nom d'hôte de l'URL, Google Cloud dirige les requêtes vers le service de backend ou le bucket backend par défaut du mappage d'URL, selon ce que vous avez défini.

  • Si le mappage d'URL contient une règle d'hôte qui inclut le nom d'hôte de l'URL, l'outil de mise en correspondance des chemins d'accès référencé par cette règle d'hôte est consulté :

    • Si l'outil de mise en correspondance des chemins d'accès contient une règle de chemin d'accès qui correspond exactement au chemin de l'URL, Google Cloud dirige les requêtes vers le service de backend ou le bucket backend défini pour cette règle de chemin d'accès.

    • Si l'outil de mise en correspondance des chemins d'accès ne contient pas de règle de chemin d'accès correspondant exactement au chemin de l'URL, mais qu'il contient une règle de chemin d'accès se terminant par /* et dont le préfixe correspond à la plus longue partie du chemin de l'URL, Google Cloud dirige les requêtes vers le service de backend ou le bucket backend défini pour cette règle de chemin d'accès. Par exemple, pour le mappage d'URL comportant deux règles de mise en correspondance des chemins d'accès /video/hd/movie1 et /video/hd/*, si l'URL contient le chemin exact /video/hd/movie1, elle est mise en correspondance avec cette règle de chemin d'accès.

    • Si aucune des conditions précédentes n'est vraie, Google Cloud dirige les requêtes vers le service de backend ou le bucket backend par défaut de l'outil de mise en correspondance des chemins d'accès, selon ce que vous avez défini.

Contraintes liées à l'outil de mise en correspondance des chemins d'accès

Les outils de mise en correspondance des chemins d'accès et les règles de chemin d'accès imposent les contraintes suivantes :

  • Une règle de chemin d'accès ne peut inclure qu'un caractère générique (*) après une barre oblique (/). Par exemple, /videos/* et /videos/hd/* sont des règles de chemin d'accès valides, mais pas /videos* et /videos/hd*.

  • Les règles de chemin d'accès n'utilisent pas la mise en correspondance d'expression régulière ou de sous-chaîne. Par exemple, les règles de chemin d'accès pour /videos/hd ou /videos/hd/* ne s'appliquent pas à une URL dont le chemin est /video/hd-abcd. En revanche, une règle de chemin d'accès pour /video/* s'applique à ce chemin.

  • Les outils de mise en correspondance des chemins d'accès (et les mappages d'URL en général) n'offrent pas de fonctionnalités semblables aux directives Apache LocationMatch. Si votre application génère des chemins d'URL dynamiques ayant un préfixe commun, comme /videos/hd-abcd et /videos/hd-pqrs, et que vous devez envoyer les requêtes adressées à ces chemins vers différents services de backend, vous ne pourrez peut-être pas le faire à l'aide d'un mappage d'URL. Pour les cas simples ne comportant que quelques URL dynamiques possibles, vous pourrez peut-être créer un outil de mise en correspondance des chemins d'accès avec cet ensemble limité de règles de chemin d'accès. Pour les cas plus complexes, vous devrez effectuer une mise en correspondance d'expression régulière basée sur le chemin d'accès sur les backends.

Un nom d'hôte ne peut référencer qu'une seule règle d'hôte, laquelle ne peut référencer qu'un seul outil de mise en correspondance des chemins d'accès. Cependant, une même règle d'hôte peut traiter plusieurs noms d'hôte, et un même outil de mise en correspondance des chemins d'accès peut être référencé par plusieurs règles d'hôte. Par conséquent, chaque URL unique est dirigée vers un seul service de backend ou un seul bucket backend :

  • Google Cloud utilise la partie nom d'hôte d'une URL pour sélectionner une seule règle d'hôte et l'outil de mise en correspondance des chemins d'accès qu'elle référence.

  • Dans l'outil de mise en correspondance des chemins d'accès, vous ne pouvez pas créer plus d'une règle de chemin d'accès pour le même chemin. Par exemple, les requêtes destinées à /videos/hd ne peuvent pas être dirigées vers plusieurs services de backend ou plusieurs buckets backend. Les services de backend peuvent utiliser des groupes d'instances ou des groupes de points de terminaison du réseau (NEG) de différentes zones et régions comme backends, et que vous pouvez créer des buckets backend utilisant des classes de stockage multirégionales.

Mappages d'URL et protocoles

Vous pouvez traiter les requêtes HTTP et HTTPS envoyées par les clients à l'aide du même mappage d'URL, des mêmes règles d'hôte et des mêmes outils de mise en correspondance des chemins d'accès, à condition que le mappage d'URL soit référencé à la fois par un proxy HTTP cible et par un proxy HTTPS cible.

Vous pouvez utiliser un mappage d'URL pour configurer la redirection, comme indiqué dans les guides suivants :

Mappage d'URL le plus simple

La forme la plus simple de mappage d'URL ne comporte qu'un service de backend par défaut ou qu'un bucket backend par défaut. Elle ne contient aucune règle d'hôte ni aucun outil de mise en correspondance des chemins d'accès. Le service de backend par défaut ou le bucket backend par défaut (selon ce que vous avez défini) gère toutes les URL demandées.

Si vous définissez un service de backend par défaut, Google Cloud dirige les requêtes vers ses groupes d'instances backend ou ses NEG de backend en fonction de la configuration du service de backend.

Mappage d'URL, sans règle, comportant seulement un service par défaut (cliquez pour agrandir)
Mappage d'URL, sans règle, comportant seulement un service par défaut (cliquez pour agrandir)

Exemple de workflow de mappage d'URL avec un équilibreur de charge HTTP(S) externe

L'exemple suivant illustre l'ordre de priorité des opérations pour un mappage d'URL. Cet exemple illustre la configuration du mappage d'URL pour un équilibreur de charge HTTP(S) externe. Pour des raisons de simplicité conceptuelle, cet exemple n'utilise que des services de backend. Vous pouvez toutefois les remplacer par des buckets backend. Pour apprendre à créer les autres composants de l'équilibreur de charge HTTP(S) externe, consultez la page Créer un équilibreur de charge HTTP(S).

Pour obtenir un exemple de création d'un mappage d'URL d'un équilibreur de charge HTTP(S) interne et d'autres composants, consultez la page Préparer la configuration de l'équilibrage de charge HTTP(S) interne.

Chaque service de backend décrit dans l'exemple suivant possède un schéma de type "externe" et utilise le protocole HTTP, HTTPS ou HTTP/2.

  1. Créez un mappage d'URL pour l'équilibreur de charge et spécifiez un service de backend par défaut. Cet exemple crée un mappage d'URL nommé video-org-url-map qui référence un service de backend existant nommé org-site.

    gcloud compute url-maps create video-org-url-map \
        --default-service=org-site
    
  2. Créez un outil de mise en correspondance des chemins d'accès nommé video-matcher et doté des caractéristiques suivantes :

    • Le service de backend par défaut est video-site. Il s'agit d'un service de backend existant.
    • Ajoutez des règles de chemin d'accès qui dirigent les requêtes pour le chemin d'URL exact /video/hd ou pour le préfixe de chemin d'URL /video/hd/* vers un service de backend existant nommé video-hd.
    • Ajoutez des règles de chemin d'accès qui dirigent les requêtes pour le chemin d'URL exact /video/sd ou pour le préfixe de chemin d'URL /video/sd/* vers un service de backend existant nommé video-sd.
    gcloud compute url-maps add-path-matcher video-org-url-map \
        --path-matcher-name=video-matcher \
        --default-service=video-site \
        --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
    
  3. Créez une règle d'hôte qui référence l'outil de mise en correspondance des chemins d'accès example.net pour le nom d'hôte video-matcher.

    gcloud compute url-maps add-host-rule video-org-url-map \
        --hosts=example.net \
        --path-matcher-name=video-matcher
    

Le mappage d'URL video-org-url-map doit se présenter comme suit :

gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

Le mappage d'URL video-org-url-map dirige les URL demandées vers les backends de la manière suivante :

Mappage d'URL avec une règle de chemin d'accès, des outils de mise en correspondance des chemins d'accès et une règle d'hôte (cliquez pour agrandir)
Mappage d'URL avec une règle de chemin d'accès, des outils de mise en correspondance des chemins d'accès et une règle d'hôte (cliquez pour agrandir)

Le tableau suivant décrit le traitement des demandes indiqué dans le schéma précédent.

Nom d'hôte Chemins d'URL Service de backend sélectionné Motif de la sélection
Nom d'hôte :
example.org et tous les autres noms d'hôte différents de
example.net
tous les chemins org-site Le nom d'hôte ne figure dans aucune règle d'hôte du mappage d'URL. Par conséquent, la requête est dirigée vers le service de backend par défaut du mappage d'URL.
Nom d'hôte :
example.net
/video
/video/examples
video-site La requête est dirigée vers le service de backend par défaut, car il n'existe aucune règle de chemin d'accès pour /video/ ou /video/*. La règle d'hôte pour example.net référence un outil de mise en correspondance des chemins d'accès, mais celui-ci ne comporte aucune règle de chemin d'accès pouvant s'appliquer à ces chemins.
Nom d'hôte :
example.net
/video/hd
/video/hd/movie1
/video/hd/movies/movie2
Autres URL qui commencent par /video/hd/*
video-hd Une règle d'hôte pour example.net référence un outil de mise en correspondance des chemins d'accès dont les règles de chemin d'accès dirigent les requêtes destinées aux chemins d'URL correspondant exactement à /video/hd ou commençant par /video/hd/* vers le service de backend video-hd.
Nom d'hôte :
example.net
/video/sd
/video/sd/show1
/video/sd/shows/show2
Autres URL qui commencent par /video/sd/*
video-sd Une règle d'hôte pour example.net référence un outil de mise en correspondance des chemins d'accès dont les règles de chemin d'accès dirigent les requêtes destinées aux chemins d'URL correspondant exactement à /video/sd ou commençant par /video/sd/* vers le service de backend video-sd.

Redirections d'URL

Une redirection d'URL redirige les visiteurs de votre domaine d'une URL à une autre.

Une redirection d'URL par défaut n'est pas prévue pour correspondre à un format particulier dans la requête entrante. Par exemple, vous pouvez utiliser une redirection d'URL par défaut pour rediriger tout nom d'hôte vers le nom d'hôte de votre choix.

Il existe plusieurs façons de créer une redirection d'URL, comme indiqué dans le tableau suivant.

Méthode Configuration
Redirection d'URL par défaut du mappage d'URL defaultUrlRedirect de premier niveau
Redirection d'URL par défaut d'un outil de mise en correspondance des chemins d'accès pathMatchers[].defaultUrlRedirect[]
Redirection d'URL de la règle de chemin d'accès d'un outil de mise en correspondance des chemins d'accès pathMatchers[].pathRules[].urlRedirect
Redirection d'URL de la règle de routage d'un outil de mise en correspondance des chemins d'accès pathMatchers[].routeRules[].urlRedirect

Au sein de defaultUrlRedirect ou de urlRedirect, pathRedirect fonctionne toujours comme suit :

  • L'ensemble du chemin de la requête est remplacé par le chemin que vous avez spécifié.

Au sein de defaultUrlRedirect ou de urlRedirect, le fonctionnement de prefixRedirect dépend de l'utilisation que vous en faites :

  • Si vous utilisez un paramètre defaultUrlRedirect, prefixRedirect a pour effet d'ajouter un préfixe, car le chemin correspondant est toujours /.
  • Si vous utilisez un paramètre urlRedirect dans une règle de routage ou de chemin d'accès d'un outil de mise en correspondance des chemins d'accès, prefixRedirect a pour effet de remplacer le préfixe en fonction de la correspondance du chemin demandé, comme défini dans la règle de chemin d'accès ou la règle de routage.

Exemples de redirection

Le tableau suivant présente quelques exemples de configurations de redirection. La colonne de droite affiche la configuration de l'API pour une redirection d'URL par défaut.

Ce que vous souhaitez Réalisée à l'aide d'une redirection d'URL par défaut
Redirection HTTP vers HTTPS

Rediriger
http://host.name/path
vers
https://host.name/path

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           
Redirection HTTP vers HTTPS + Redirection de l'hôte

Rediriger
http://any-host-name/path
vers
https://www.example.com/path

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          
Redirection HTTP vers HTTPS + Redirection de l'hôte + Redirection du chemin d'accès complet

Rediriger
http://any-host-name/path
vers
https://www.example.com/newPath

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           
Redirection HTTP vers HTTPS + Redirection de l'hôte + Redirection du préfixe

Rediriger
http://any-host-name/originalPath
vers
https://www.example.com/newPrefix/originalPath

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              prefixRedirect: "/newPrefix"
            

L'exemple suivant illustre l'annotation de chaque ressource API.

kind: compute#urlMap
name: web-map-http
defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
  },
  "defaultUrlRedirect": {
    "redirectResponseCode": enum,
  }

Pour obtenir des exemples complets, consultez les pages suivantes :

Gestion avancée du trafic

Certaines fonctionnalités de mappage d'URL ne sont pas disponibles pour tous les produits. Les mappages d'URL sont utilisés avec l'équilibrage de charge HTTP(S) interne et Traffic Director pour permettre d'utiliser plusieurs fonctionnalités avancées de gestion du trafic, qui ne sont pas toutes compatibles avec l'équilibrage de charge HTTP(S) externe.

Consultez le tableau suivant pour connaître les fonctionnalités de mappage d'URL disponibles pour chaque produit. Chaque produit comporte des sujets dédiés qui expliquent comment fonctionne la gestion du trafic et inclut des exemples de mappages d'URL pour chaque cas d'utilisation.

Produit Fonctionnalités de mappage d'URL et guides sur la gestion du trafic
Équilibrage de charge HTTP(S) externe Fonctionnalités de l'équilibreur de charge : routage et gestion du trafic

Présentation de la gestion du trafic pour les équilibreurs de charge HTTP(S) externes

Configurer la gestion du trafic pour les équilibreurs de charge HTTP(S) externes

Équilibrage de charge HTTP(S) interne Fonctionnalités de l'équilibreur de charge : routage et gestion du trafic

Présentation de la gestion du trafic pour les équilibreurs de charge HTTP(S) internes

Configurer la gestion du trafic pour les équilibreurs de charge HTTP(S) internes

Traffic Director Traffic Director features: Routing and traffic management

Présentation de la gestion avancée du trafic

Configurer la gestion avancée du trafic

Documentation de référence sur l'API et sur le SDK Cloud

En plus de Cloud Console, vous pouvez utiliser l'API et le SDK Cloud pour créer des mappages d'URL.

API

Pour une description des propriétés et des méthodes disponibles lorsque vous utilisez des mappages d'URL via l'API REST, consultez les pages suivantes :

Produit Documentation sur l'API
Équilibrage de charge HTTP(S) externe urlMaps
Équilibrage de charge HTTP(S) interne regionUrlMaps
Traffic Director urlMaps

SDK Cloud

Pour l'outil de ligne de commande gcloud du SDK Cloud, consultez les pages suivantes :

Pour la gestion avancée du trafic, utilisez des fichiers YAML et importez-les avec la commande gcloud compute url-maps import.

Étape suivante