Présentation des mappages d'URL

Les équilibreurs de charge d'application Google Cloud et 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 backend ou 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 bêta.

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

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

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.

Exemple de configuration d'un service de backend. — Exemple de configuration du service (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 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 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. — 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.

Remarque: Les buckets backend ne sont pas compatibles avec les équilibreurs de charge d'application internes et Traffic Director.
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 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ôte news.example.net et finance.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 sur example.net:8080. Dans le cas de l'équilibreur de charge d'application classique, seul le nom d'hôte de l'URL est pris en compte lors de la mise en correspondance d'une règle d'hôte. Par exemple, les requêtes example.net pour les ports 8080 et 80 correspondent à la règle d'hôte example.net.
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

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/abc@xyz.com/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 PathMatcher cart-matcher. La variable {username=*} correspond à abc@xyz.com 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 le pathTemplateMatch dans notre pathTemplateRewrite.
La requête réécrite est envoyée à cart-backend avec le chemin d'URL réécrit : /abc@xyz.com-FL0001090004/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 PathMatcher user-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 et x-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 les noms d'hôte et les règles d'hôte. — Relation entre les noms d'hôte et les règles d'hôte (cliquez pour agrandir)

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 les règles d'hôte et les outils de mise en correspondance des chemins d'accès. — Relation entre les règles d'hôte et les outils de mise en correspondance des chemins d'accès (cliquez pour agrandir)

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égions comme 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 backend sur 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 backend lors 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.

Mappage d'URL, sans règle, comportant seulement un service par défaut. — 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 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
```
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. — 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 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.