Les équilibreurs de charge HTTP(S) Google Cloud et Traffic Director utilisent un mappage d'URL pour diriger les requêtes vers une destination. Lorsque vous configurez un équilibreur de charge HTTP(S) ou Traffic Director, vous créez un mappage d'URL. Ce mappage d'URL dirige le trafic vers une ou plusieurs des destinations suivantes en fonction des règles que vous définissez :
- Service de backend par défaut
- Service de backend autre que celui par défaut
- Bucket backend par défaut
- Bucket backend autre que celui par défaut
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.
Par exemple, vous pouvez utiliser un seul mappage d'URL pour diriger les requêtes en fonction de l'hôte et du chemin d'accès de la requête :
- 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 :
À propos 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 configurations effectuées dans un mappage d'URL.
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
)
- Un ensemble qui héberge le site Web de votre entreprise (service de backend :
Vous souhaitez organiser l'acheminement du trafic comme suit :
- Diriger les requêtes adressées à
example.org
(ou à tout autre domaine queexample.net
) vers le service de backendorg-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 backendvideo-site
- Diriger les requêtes adressées à
example.net/video/hd/*
vers le service de backendvideo-hd
- Diriger les requêtes adressées à
example.net/video/sd/*
vers le service de backendvideo-sd
.
Le mappage d'URL vous permet de configurer ce type d'acheminement basé sur un hôte et un chemin d'accès.
Gestion avancée du trafic
L'équilibrage de charge HTTP(S) interne et Traffic Director utilisent des mappages d'URL pour le routage basé sur l'hôte et le chemin d'accès (comme décrit dans ce document). Lorsqu'ils sont utilisés avec ces produits, les mappages d'URL sont également compatibles avec les fonctionnalités de gestion avancée du trafic. Pour plus d'informations sur la gestion avancée du trafic, consultez les pages Présentation de la gestion du trafic et Gestion avancée du trafic.
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 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 une ressource de configuration Google Cloud qui dirige les requêtes destinées à des URL spécifiques vers des services de backend ou des buckets backend. Pour ce faire, le mappage 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 estexample.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
.
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. 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. 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. 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ôteexample.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 URLhttp://example.org
,http://example.net/video/hd
ethttp://example.com/audio
, les trois noms d'hôteexample.org
,example.net
etexample.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ôtefoo.example.net
etbar.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 surexample.net:8080
.
- 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
Outil de mise en correspondance des chemins d'accès. 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 :
- Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge HTTP(S) externes
- Configurer la gestion du trafic pour les équilibreurs de charge HTTP(S) internes
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.
Exemple de mappage d'URL
L'exemple suivant illustre l'ordre de priorité des opérations pour un mappage d'URL. Pour des raisons de simplicité conceptuelle, cet exemple n'utilise que des services de backend. Vous pouvez toutefois les remplacer par des buckets backend. Les étapes suivantes permettent de configurer le mappage d'URL pour un équilibreur de charge HTTP(S) externe. Pour obtenir un exemple de création des 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 section 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.
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
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
- Le service de backend par défaut est
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ôtevideo-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
dirige les URL demandées vers les backends de la manière suivante :
Le tableau suivant décrit le traitement des demandes indiqué dans le schéma précédent.
Nom de l'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 deexample.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 . |
Documentation de référence sur l'API et sur gcloud
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 :
- Champ d'application global : urlMaps
- Champ d'application régional : regionUrlMaps
Pour l'outil de ligne de commande gcloud
, consultez la page suivante :
- gcloud compute url-maps
- Champ d'application global :
--global
- Champ d'application régional :
--region=[REGION]
- Champ d'application global :
Étape suivante
- Pour ajouter, tester, répertorier ou supprimer un mappage d'URL, consultez la page Utiliser des mappages d'URL.
- Pour en savoir plus sur les cartes des règles de routage avec Traffic Director, consultez la page Présentation des cartes des règles de routage Cloud Load Balancing.