Présentation du routage basé sur le chemin d’accès de l’URL
Le routage basé sur le chemin de l’URL vous permet d’acheminer le trafic vers des pools de serveurs back-end en fonction des chemins de l’URL de la demande.
L’un des scénarios consiste à acheminer les demandes pour différents types de contenu vers des pools de serveurs principaux différents.
Dans l’exemple suivant, Application Gateway route le trafic pour contoso.com à partir de trois pools de back-ends, par exemple : VideoServerPool, ImageServerPool et DefaultServerPool.
Les requêtes adressées à http://contoso.com/video/* sont acheminées vers VideoServerPool et les requêtes adressées à http://contoso.com/images/* sont acheminées vers ImageServerPool. DefaultServerPool est sélectionné si aucun des modèles de chemin d’accès ne correspond.
Remarque
Lorsque vous routez la requête, le chemin d’accès d’URL complet est envoyé au pool back-end. Si les ressources demandées se trouvent sur un autre chemin d’accès (par exemple si une requête à http://contoso.com/video/* nécessite la fourniture de vidéos à partir de la racine du site derrière le VideoServerPool), vous devez alors configurer une Règle de réécriture d’URL ou remplacer le chemin d’accès de back-end dans les paramètres de votre back-end.
Important
Pour les références (SKU) v1 et v2, les règles sont traitées dans l’ordre où elles sont répertoriées dans le portail. Lorsque vous créez des règles de chemin d’accès, il est recommandé de placer le chemin d’accès le moins spécifique (celui avec des caractères génériques) à la fin. Si les caractères génériques apparaissent en haut, ils ont la priorité, même s’il existe une correspondance plus spécifique dans les règles de chemin d’accès suivantes.
Si un écouteur de base est indiqué en premier et correspond à une demande entrante, elle est traitée par cet écouteur. Il est cependant vivement recommandé de configurer des écouteurs multisites avant de configurer un écouteur de base. Vous avez ainsi l’assurance que le trafic est acheminé vers le serveur principal approprié.
Élément de configuration UrlPathMap
L’élément urlPathMap est utilisé pour spécifier les modèles de chemins dans les mappages de pools de back-ends. L’exemple de code suivant est un extrait de l’élément urlPathMap issu du fichier de modèle.
"urlPathMaps": [{
"name": "{urlpathMapName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",
"properties": {
"defaultBackendAddressPool": {
"id": "/subscriptions/ {subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"
},
"defaultBackendHttpSettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsCollection/{settingname1}"
},
"pathRules": [{
"name": "{pathRuleName}",
"properties": {
"paths": [
"{pathPattern}"
],
"backendAddressPool": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"
},
"backendHttpsettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsCollection/{settingName2}"
}
}
}]
}
}]
PathPattern
PathPattern est une liste de modèles de chemin à utiliser pour la correspondance. Chaque chemin doit commencer par / et peut utiliser * comme caractère générique. La chaîne transmise à l’outil de correspondance de chemin d’accès n’inclut pas de texte après le premier signe ?
ou #
. De plus, ces caractères ne sont pas autorisés ici. Sinon, tous les caractères autorisés dans une URL sont autorisés dans PathPattern.
Les règles de chemin ne respectent pas la casse.
Modèle de chemin d’accès | Prise en charge ? |
---|---|
/images/* |
Oui |
/images* |
oui |
/images/*.jpg |
non |
/*.jpg |
non |
/Repos/*/Comments/* |
non |
/CurrentUser/Comments/* |
Oui |
Les règles de chemin d’accès sont traitées dans l’ordre, en fonction de la façon dont elles sont répertoriées dans le portail. Le chemin d’accès le moins spécifique (avec des caractères génériques) doit être à la fin de la liste, afin qu’il soit traité en dernier. Si les règles génériques sont présentes en haut de la liste, elles sont prioritaires et sont traitées en premier. Consultez les exemples de scénarios suivants.
Exemples
Traitement des règles basé sur le chemin lorsque le caractère générique (*) est utilisé :
Exemple 1 :
/master-dev* to contoso.com
/master-dev/api-core/ to fabrikam.com
/master-dev/* to microsoft.com
Comme le chemin d’accès avec caractère générique /master-dev*
est présent au-dessus de chemins plus granulaires, toutes les demandes des clients contenant /master-dev
sont acheminées vers contoso.com, y compris le /master-dev/api-core/
spécifique. Pour vous assurer que les requêtes des clients sont acheminées vers les chemins d’accès appropriés, il est essentiel d’avoir les chemins d’accès granulaires au-dessus de ceux à caractère générique.
Exemple 2 :
/ (default) to contoso.com
/master-dev/api-core/ to fabrikam.com
/master-dev/api to bing.com
/master-dev/* to microsoft.com
Toutes les demandes de client avec le modèle de chemin d’accès /master-dev/*
sont traitées dans l’ordre indiqué. S’il n’existe aucune correspondance dans les règles de chemin d’accès, la demande est routée vers la cible par défaut.
Pour plus d’informations, consultez Modèle Resource Manager utilisant le routage basé sur URL .
Règle PathBasedRouting
La règle RequestRoutingRule de type PathBasedRouting est utilisée pour lier un écouteur à un élément urlPathMap. Toutes les demandes qui sont reçues par cet écouteur sont acheminées en fonction de la stratégie spécifiée dans l’élément urlPathMap. Exemple de la règle PathBasedRouting :
"requestRoutingRules": [
{
"name": "{ruleName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/requestRoutingRules/{ruleName}",
"properties": {
"ruleType": "PathBasedRouting",
"httpListener": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/httpListeners/<listenerName>"
},
"urlPathMap": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}"
}
}
}
]
Étapes suivantes
Après vous être familiarisé avec le routage de contenu basé sur URL, accédez à la section Créer une passerelle d’application à l’aide du routage basé sur URL pour créer une passerelle d’application avec les règles de routage URL.