Partager via

Réécriture d’URL pour Azure Application Gateway pour conteneurs : API d’entrée

  • Article

Application Gateway pour conteneurs vous permet de réécrire l’URL d’une requête cliente, y compris le nom d’hôte et/ou le chemin d’accès des requêtes. Lorsque Passerelle d'application pour conteneurs lance la requête vers la cible back-end, la requête contient l’URL nouvellement réécrite pour lancer la requête.

Usage details

Les réécritures d’URL tirent parti de la ressource personnalisée IngressExtension d’Application Gateway pour conteneurs.

Background

La réécriture d’URL vous permet de traduire une requête entrante en une autre URL lorsqu’elle est lancée vers une cible back-end.

L’illustration suivante illustre une requête destinée à contoso.com/shop réécrit en contoso.com/ecommerce lorsque la requête est lancée sur la cible principale par Application Gateway pour conteneurs :

Diagramme montrant la réécriture d’une URL vers le back-end par Passerelle d’application pour conteneurs.

Prérequis

  1. Si vous suivez la stratégie de déploiement BYO, veillez à configurer vos ressources de Passerelle d’application pour conteneurs et le contrôleur ALB.
  2. Si vous suivez la stratégie de déploiement managé ALB, veillez à approvisionner votre contrôleur ALB et les ressources de Passerelle d’application pour conteneurs via la ressource personnalisée ApplicationLoadBalancer.
  3. Déployez un exemple d’application HTTP :
    Appliquez le fichier deployment.yaml suivant sur votre cluster pour créer un exemple d’application web afin de montrer le routage basé sur un chemin d’accès, une requête et un en-tête.
kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

Cette commande crée les éléments suivants sur votre cluster :

  • Un espace de noms nommé test-infra
  • Deux services nommés backend-v1 et backend-v2 dans l’espace de noms test-infra
  • Deux déploiements nommés backend-v1 et backend-v2 dans l’espace de noms test-infra

Déployer les ressources d’API d’entrée requises

  1. Créer une entrée qui intercepte tout le trafic et tous les itinéraires vers backend-v2
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-name: alb-test
    alb.networking.azure.io/alb-namespace: alb-test-infra
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v2
                port:
                  number: 8080
EOF
  1. Créer une entrée qui correspond au préfixe /shop qui achemine vers backend-v1
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-02
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-name: alb-test
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-ingress-extension: url-rewrite
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /shop
            pathType: Prefix
            backend:
              service:
                name: backend-v1
                port:
                  number: 8080
EOF

Remarque

Lorsque le contrôleur ALB crée les ressources Passerelle d’application pour conteneurs dans ARM, il utilise la convention de dénomination suivante pour une ressource front-end : fe-<8 caractères générés aléatoirement>

Si vous souhaitez modifier le nom du front-end créé dans Azure, il peut être préférable de suivre la stratégie de déploiement BYO.

Lorsque chaque ressource d’entrée est créée, vérifiez que l’état est valide, que l’écouteur est programméet qu’une adresse est affectée à la passerelle.

kubectl get ingress ingress-01 -n test-infra -o yaml
kubectl get ingress ingress-02 -n test-infra -o yaml

Exemple de sortie de l’une des ressources d’entrée.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.networking.azure.io/alb-frontend: FRONTEND_NAME
    alb.networking.azure.io/alb-id: /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz"},"name"
:"ingress-01","namespace":"test-infra"},"spec":{"ingressClassName":"azure-alb-external","rules":[{"host":"contoso.com","http":{"paths":[{"backend":{"service":{"name":"backend-v2","port":{"number":8080}}},"path":"/","pathType":"Prefix"}]}}]}}
  creationTimestamp: "2023-07-22T18:02:13Z"
  generation: 2
  name: ingress-01
  namespace: test-infra
  resourceVersion: "278238"
  uid: 17c34774-1d92-413e-85ec-c5a8da45989d
spec:
  ingressClassName: azure-alb-external
  rules:
  - host: contoso.com
    http:
      paths:
      - backend:
          service:
            name: backend-v2
            port:
              number: 8080
        path: /
        pathType: Prefix
status:
  loadBalancer:
    ingress:
    - hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.fzyy.alb.azure.com
      ports:
      - port: 80
        protocol: TCP

Lorsque l’entrée est créée, créez une ressource IngressExtension pour contoso.com. Cet exemple garantit que le trafic envoyé à contoso.com/shop est lancé en tant que contoso.com/ecommerce à la cible back-end.

kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
  name: url-rewrite
  namespace: test-infra
spec:
  rules:
    - host: contoso.com
      rewrites:
      - type: URLRewrite
        urlRewrite:
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /ecommerce
EOF

Lorsque la ressource IngressExtension est créée, vérifiez que la ressource IngressExtension affiche accepté et que la ressource Application Gateway pour conteneurs est Programmé.

kubectl get IngressExtension url-rewrite -n test-infra -o yaml

Vérifiez que la ressource Application Gateway pour conteneurs est correctement mise à jour pour l’entrée Extension.

Tester l’accès à l’application

Nous sommes maintenant prêts à envoyer du trafic à notre exemple d’application, via le nom de domaine complet affecté au front-end. Utilisez la commande suivante pour obtenir le nom de domaine complet.

fqdn=$(kubectl get ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Si vous spécifiez l’indicateur de nom de serveur contoso.com/shop à l’aide de la commande curl, une réponse du service backend-v1 est retournée avec le chemin d’accès demandé à la cible back-end affichant contoso.com/ecommerce.

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com/shop

Par le biais de la réponse, nous devrions voir :

{
 "path": "/ecommerce",
 "host": "contoso.com",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/7.81.0"
  ],
  "X-Forwarded-For": [
   "xxx.xxx.xxx.xxx"
  ],
  "X-Forwarded-Proto": [
   "http"
  ],
  "X-Request-Id": [
   "dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v1-5b8fd96959-f59mm"
}

Si vous spécifiez l’indicateur de nom de serveur contoso.com à l’aide de la commande curl, une réponse est retournée par le service backend-v2, comme indiqué.

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com

La réponse suivante doit être affichée :

{
 "path": "/",
 "host": "contoso.com",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/7.81.0"
  ],
  "X-Forwarded-For": [
   "xxx.xxx.xxx.xxx"
  ],
  "X-Forwarded-Proto": [
   "http"
  ],
  "X-Request-Id": [
   "adae8cc1-8030-4d95-9e05-237dd4e3941b"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v2-594bd59865-ppv9w"
}

Félicitations, vous avez installé le contrôleur ALB, déployé une application back-end et utilisé l’ingress Extension pour réécrire l’URL demandée par le client, avant que le trafic soit défini sur la cible sur Application Gateway pour conteneurs.