Les équilibreurs de charge d'application Google Cloudet Traffic Director utilisent une ressource de configuration Google Cloud appelée mappage d'URL pour acheminer les requêtes HTTP(S) vers des services de backendou des buckets backend.
Par exemple, avec un équilibreur de charge d'application 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 :
- Équilibreur de charge d'application externe (modes mondial, régional et classique)
- Équilibreur de charge d'application interne (modes interrégionaux et régionaux)
- Traffic Director, lorsque Traffic Director est déployé avec les API d'équilibrage de charge
Deux types de ressources de mappage d'URL sont disponibles : globale et régionale. 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 d'application externe mondial | EXTERNAL_MANAGED |
Mondial, externe | Services de backend, buckets backend |
Équilibreur de charge d'application classique | EXTERNAL |
Mondial, externe | Services de backend, buckets backend |
Équilibreur de charge d'application externe régional | EXTERNAL_MANAGED |
Régional, externe | Services de backend |
Équilibreur de charge d'application interne interrégional | INTERNAL_MANAGED |
Mondial, interne | Services de backend |
Équilibreur de charge d'application interne régional | INTERNAL_MANAGED |
Régional, interne | Services de backend |
Traffic Director | INTERNAL_SELF_MANAGED |
Mondial, interne | Services de backend |
Les fonctionnalités de mappage d'URL ne sont pas toutes disponibles pour l'ensemble des produits. Les mappages d'URL utilisés avec les équilibreurs de charge d'application externes mondiaux, les équilibreurs de charge d'application externes régionaux, les équilibreurs de charge d'application internes 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 page Comparaison des fonctionnalités de l'équilibreur de charge : routage et gestion du trafic. En outre, les mappages d'URL régionaux peuvent être des ressources désignées comme des services dans App Hub, qui est en version preview.
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 backendou 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 Cloud Storage, qui est couramment utilisé pour héberger du contenu statique, tel que des images.
Pour les équilibreurs de charge d'application externes régionaux, les équilibreurs de charge d'application internes et Traffic Director, les destinations possibles sont les suivantes:
- Service de backend par défaut
- Service de backend autre que celui par défaut
De plus, les équilibreurs de charge d'application externes mondiaux sont compatibles avec 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
)
- 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
Une valeur --path-rule
pour /video/*
correspond à des URI tels que /video/test1
et /video/test2
. Toutefois, cette règle de chemin ne correspond pas au chemin /video
.
Si l'équilibreur de charge reçoit une requête avec /../
dans l'URL, il transforme l'URL en supprimant le segment de chemin avant ..
et répond avec l'URL transformée. Par exemple, lorsqu'une requête est envoyée pour http://example.net/video/../abc
, l'équilibreur de charge répond par une redirection 302 vers http://example.net/abc
. La plupart des clients réagissent ensuite en envoyant une requête à l'URL renvoyée par l'équilibreur de charge (dans le cas présent, http://example.net/abc
). Cette redirection 302 n'est pas journalisée dans Cloud Logging.
Le mappage d'URL vous permet de configurer ce type d'acheminement basé sur un hôte et un chemin d'accès.
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 dans la console Google Cloud. Si vous utilisez Google Cloud CLI 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 backendou 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 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 backendou 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ô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 en spécifiant le caractère générique*
. Par exemple, une règle d'hôte*.example.net
est mise en correspondance avec les noms d'hôtenews.example.net
etfinance.example.net
.- Numéro du port. Différents équilibreurs de charge d'application gèrent les numéros de port différemment. Dans le cas de l'équilibreur de charge d'application interne, vous pouvez 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
. Dans le cas de l'équilibreur de charge d'application classique, seul le nom d'hôte dans l'URL est pris en compte lors de la mise en correspondance d'une règle d'hôte. Par exemple, les requêtesexample.net
pour les ports 8080 et 80 correspondent à la règle d'hôteexample.net
.
- Numéro du port. Différents équilibreurs de charge d'application gèrent les numéros de port différemment. Dans le cas de l'équilibreur de charge d'application interne, vous pouvez 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 (
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 backendpar 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 backendou le bucket backendapproprié, 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 backendou le bucket backendpar 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 backendpar 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
Des contraintes s'appliquent aux noms d'hôte, aux outils de mise en correspondance des chemins d'accès et aux règles de chemin d'accès.
Caractères génériques, expressions régulières et URL dynamiques dans les règles de chemin d'accès
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'expressions régulières ou de sous-chaîne. PathTemplateMatch peut utiliser des opérateurs de mise en correspondance de chemins d'accès simplifiés. 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 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.
Caractères génériques et opérateurs de mise en correspondance de formats dans les modèles de chemin d'accès pour les règles de routage
Les opérateurs de mise en correspondance de formats flexibles vous permettent de faire correspondre plusieurs parties d'un chemin d'URL, y compris des URL partielles et des suffixes (extensions de fichier), à l'aide d'une syntaxe de caractère générique. Ces opérateurs peuvent être utiles lorsque vous devez acheminer le trafic et exécuter des réécritures en fonction de chemins d'URL complexes. Vous pouvez également associer un ou plusieurs composants de chemin d'accès à des variables nommées, puis faire référence à ces variables lors de la réécriture de l'URL. Avec les variables nommées, vous pouvez réorganiser et supprimer les composants d'URL avant que la requête ne soit envoyée à votre origine.
La correspondance de modèle avec des caractères génériques n'est acceptée que pour les produits suivants :
- Équilibreur de charge d'application externe global
- Équilibreur de charge d'application externe régional
- Équilibreur de charge d'application interne régional
- Équilibreur de charge d'application interne interrégional
- Traffic Director
L'exemple suivant achemine le trafic pour une application e-commerce qui dispose de services distincts pour les informations sur le panier et les informations utilisateur.
Vous pouvez configurer routeRules
avec des opérateurs de correspondance de formats flexibles et des variables nommées pour envoyer l'ID unique de l'utilisateur à une page de détails du compte utilisateur et les informations sur le panier de l'utilisateur à un service de traitement du panier après réécriture de l'URL.
pathMatchers:
- name: cart-matcher
routeRules:
- description: CartService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
service: cart-backend
priority: 1
routeAction:
urlRewrite:
pathTemplateRewrite: '/{username}-{cartid}/'
- name: user-matcher
routeRules:
- description: UserService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
service: user-backend
priority: 1
Voici ce qu'il se passe lorsqu'un client demande /xyzwebservices/v2/xyz/users/[email protected]/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
, qui contient à la fois des informations sur l'utilisateur et des informations sur le panier :
- Le chemin de requête correspond à
pathTemplateMatch
dans l'outil PathMatchercart-matcher
. La variable{username=*}
correspond à[email protected]
et la variable{cartid=**}
correspond àFL0001090004/entries/SJFI38u3401nms
. - Les paramètres de requête sont séparés du chemin d'accès, le chemin d'accès est réécrit en fonction de
pathTemplateRewrite
, et les paramètres de requête sont ajoutés au chemin réécrit. Il est nécessaire d'utiliser les mêmes variables que celles utilisées pour définir lepathTemplateMatch
dans notrepathTemplateRewrite
. - La requête réécrite est envoyée à
cart-backend
avec le chemin d'URL réécrit :/[email protected]/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
.
Ce qui suit se produit lorsqu'un client demande /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234
à la place, qui ne contient que des informations sur l'utilisateur et le compte :
- Le chemin de requête correspond à
pathTemplateMatch
dans l'outil PathMatcheruser-matcher
. Le premier*
correspond àabc%40xyz.com
et le second*
correspond àabc-1234
. - La requête est envoyée à
user-backend
.
Le tableau suivant décrit la syntaxe des formats de modèles d'accès.
Opérateur | Correspondance établie |
---|---|
* |
Un segment de chemin d'accès unique, sans les caractères de séparation de chemin d'accès / qui l'entourent. |
** |
Correspond à zéro ou plusieurs caractères, y compris les caractères de séparateur de chemin d'accès / entre plusieurs segments de chemin d'accès. Si d'autres opérateurs sont inclus, l'opérateur ** doit être le dernier. |
{name} ou {name=*} |
Une variable nommée correspondant à un segment de chemin d'accès. Correspond à un seul segment de chemin d'accès, sans inclure les caractères de séparateur de chemin d'accès / qui l'entourent. |
{name=news/*} |
Une variable nommée correspondant explicitement à deux segments de chemin d'accès : news et un segment à caractère générique * . |
{name=*/news/*} |
Une variable nommée correspondant à trois segments de chemin d'accès. |
{name=**} |
Une variable nommée correspondant à zéro ou plusieurs caractères. Si elle est présente, il doit s'agir du dernier opérateur. |
Lorsque vous utilisez ces opérateurs pour mettre en correspondance des formats flexibles, gardez à l'esprit les points suivants :
- Plusieurs opérateurs peuvent être combinés dans un seul format.
- Les paramètres de requête sont séparés du chemin d'accès, le chemin d'accès est réécrit en fonction de
pathTemplateRewrite
, et les paramètres de requête sont ajoutés au chemin réécrit. - Les requêtes ne sont pas normalisées en encodage-pourcent. Par exemple, une URL avec une barre oblique en encodage-pourcent (%2F) n'est pas décodée dans sa forme non encodée.
- Chaque nom de variable, tel que
{segment}
ou{region}
, ne peut apparaître qu'une seule fois dans le même format. Plusieurs variables portant le même nom ne sont pas valides et sont refusées. - Les noms de variables sont sensibles à la casse et doivent être des identifiants valides. Pour vérifier si un nom de variable est valide, assurez-vous qu'il correspond à l'expression régulière
^[a-zA-Z][a-zA-Z0-9_]*$
.{API}
,{api}
et{api_v1}
sont tous des identifiants valides. Ils identifient trois variables distinctes.{1}
,{_api}
et{10alpha}
ne sont pas des identifiants valides.
- Le nombre d'opérateurs par format de modèle est limité à cinq.
Pour exécuter une réécriture d'URL facultative avant l'envoi de la requête à l'origine, vous pouvez utiliser les mêmes variables que celles définies pour capturer un chemin d'accès.
Par exemple, vous pouvez référencer, réorganiser ou omettre les variables dans le champ pathTemplateRewrite
lors de la définition de urlRewrite
.
Lorsque vous utilisez des variables et des opérateurs pour mettre en correspondance des formats flexibles pour les réécritures d'URL, gardez à l'esprit les points suivants :
- Lorsque vous réécrivez une URL, vous pouvez omettre des variables si elles ne sont pas requises en tant que partie de l'URL réécrite.
- Avant toute réécriture, vous pouvez identifier l'URL envoyée par le client à votre origine en inspectant les en-têtes de réponse. L'URL du client d'origine est renseignée avec les en-têtes
x-client-request-url
etx-envoy-original-path
.
Relation entre le nom d'hôte et la règle d'hôte
Un nom d'hôte ne peut faire référence qu'à une seule règle d'hôte.
Une seule règle d'hôte peut traiter plusieurs noms d'hôte.
Relation entre la règle d'hôte et l'outil de mise en correspondance des chemins d'accès
Plusieurs règles d'hôte peuvent référencer un même outil de mise en correspondance des chemins d'accès.
Une règle d'hôte ne peut référencer qu'un seul outil de mise en correspondance des chemins d'accès.
Le schéma suivant illustre ces points.
Relation entre l'URL et le backend
Chaque URL unique est dirigée vers un seul service de backend ou un seul bucket de backend. Par conséquent :
Google Cloud utilise la partie nom d'hôte d'une URL pour sélectionner une règle d'hôte unique et l'outil de mise en correspondance des chemins d'accès qu'elle référence.
Lorsque vous utilisez des règles de chemin d'accès dans un outil de mise en correspondance des chemins d'accès, vous ne pouvez créer qu'une seule règle de chemin d'accès par chemin. Par exemple, les requêtes destinées à
/videos/hd
ne peuvent pas être dirigées vers plusieurs services de backend ou plusieurs buckets de 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égionscomme backends, et que vous pouvez créer des buckets de backend utilisant des classes de stockage multirégionales.Pour diriger le trafic d'une URL unique vers plusieurs services, vous pouvez utiliser des règles de routage plutôt que des règles de chemin d'accès. Si vous configurez l'outil de mise en correspondance des chemins d'accès avec des règles de routage pour les correspondances d'en-tête ou de paramètre, une URL unique peut être dirigée vers plusieurs services ou buckets de backendsur la base du contenu des en-têtes ou des paramètres de requête de l'URL.
De même, pour les équilibreurs de charge d'application externes régionaux et Traffic Director, les services de backend pondérés peuvent diriger une même URL vers plusieurs services ou buckets de backendlors d'une action de routage en se basant sur les pondérations définies sur le service de backend pondéré.
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.
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 workflow de mappage d'URL avec un équilibreur de charge d'application externe
L'exemple suivant illustre l'ordre de priorité des opérations pour un mappage d'URL. Cet exemple configure uniquement le mappage d'URL pour un équilibreur de charge d'application classique existant. 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, consultez la page Créer un équilibreur de charge d'application classique.
Pour en savoir plus sur la création et la configuration de mappages d'URL avec des outils de mise en correspondance des chemins d'accès et des règles d'hôte, consultez la documentation sur gcloud compute url-maps create
.
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
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 :
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 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 . |
Redirections d'URL
Une redirection d'URL redirige les visiteurs de votre domaine d'une URL vers une autre.
Une redirection d'URL par défaut n'est pas conditionnée par la correspondance d'un modèle 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'intégralité du chemin d'accès de la requête est remplacée par le chemin que vous spécifiez.
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 fournit des 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'extrait partiel suivant illustre l'annotation de chaque ressource API :
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 ? ...
Étapes suivantes
Consultez la page Utiliser des mappages d'URL pour savoir comment ajouter, valider, tester, lister ou supprimer un mappage d'URL.
Pour en savoir plus sur les mappages des règles de routage avec Traffic Director, consultez la page Présentation des mappages des règles de routage Traffic Director.