Reindirizzamento URL per il Gateway applicativo per contenitori di Azure - API in ingresso

Il Gateway applicativo per contenitori consente di restituire una risposta di reindirizzamento al client in base a tre aspetti di un URL: protocollo, nome host e percorso. Per ogni reindirizzamento, un codice di stato HTTP definito può essere restituito al client per definire la natura del reindirizzamento.

Usage details (Dettagli di utilizzo)

I reindirizzamenti URL sfruttano il filtro della regola RequestRedirect come definito dall'API del gateway Kubernetes.

Reindirizzamento

Un reindirizzamento imposta il codice di stato della risposta restituito ai client per comprendere lo scopo del reindirizzamento. Sono supportati i tipi di reindirizzamento seguenti:

  • 301 (spostato in modo permanente): indica che alla risorsa di destinazione viene assegnato un nuovo URI permanente. Eventuali riferimenti futuri a questa risorsa usano uno degli URI racchiusi. Usare il codice di stato 301 per il reindirizzamento da HTTP a HTTPS.
  • 302 (Trovato): indica che la risorsa di destinazione è temporaneamente in un URI diverso. Poiché il reindirizzamento può cambiare in alcuni casi, il client deve continuare a usare l'URI della richiesta effettivo per le richieste future.

Funzionalità di reindirizzamento

  • Il reindirizzamento del protocollo viene comunemente usato per indicare al client di passare da uno schema di traffico non crittografato al traffico, ad esempio il reindirizzamento da HTTP a HTTPS.

  • Il reindirizzamento del nome host corrisponde al nome di dominio completo (FQDN) della richiesta. Questo è comunemente osservato nel reindirizzamento di un nome di dominio precedente a un nuovo nome di dominio, come contoso.com a fabrikam.com.

  • Il reindirizzamento del percorso ha due varianti diverse: prefix e full.

    • Il tipo di reindirizzamento Prefix reindirizzerà tutte le richieste a partire da un valore definito. Ad esempio, un prefisso di /shop corrisponde a /shop ed a qualsiasi testo che segue. Ad esempio, /shop, /shop/completamento della transazione e /shop/item-a reindirizza tutti a /shop.
    • Il tipo di reindirizzamento Full corrisponde a un valore esatto. Ad esempio, /shop reindirizza a /store, ma /shop/completamento della transazione non reindirizza a /store.

Nella figura seguente viene illustrato un esempio di richiesta destinata a contoso.com/summer-promotion reindirizzata a contoso.com/shop/category/5. Inoltre, una seconda richiesta avviata per contoso.com tramite protocollo HTTP restituisce un reindirizzamento per avviare una nuova connessione alla relativa variante https.

Diagramma che mostra il Gateway applicativo per contenitori che restituisce un URL di reindirizzamento a un client.

Prerequisiti

  1. Se si segue la strategia di distribuzione BYO, assicurarsi di configurare l'Application Gateway per le risorse dei contenitori e il controller ALB (componente aggiuntivo o Helm).

  2. Se si segue la strategia di distribuzione gestita di ALB, assicurarsi di eseguire il provisioning del controller ALB (componente aggiuntivo o Helm) e di eseguire il provisioning delle risorse del gateway applicazione per contenitori tramite la risorsa personalizzata ApplicationLoadBalancer.

  3. Distribuire un'applicazione HTTP di esempio:

    Applicare il file deployment.yaml seguente nel cluster per distribuire un certificato TLS di esempio per illustrare le funzionalità di reindirizzamento.

    kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/https-scenario/ssl-termination/deployment.yaml

    Questo comando crea gli elementi seguenti nel cluster:

    • uno spazio dei nomi denominato test-infra
    • un servizio denominato echo nello spazio dei nomi test-infra
    • una distribuzione denominata echo nello spazio dei nomi test-infra
    • un segreto denominato listener-tls-secret nello spazio dei nomi test-infra

Distribuire le risorse necessarie di IngressExtension

  1. Creare una risorsa IngressExtension per gestire il reindirizzamento da HTTP a HTTPS per contoso.com

    kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
  name: http-to-https
  namespace: test-infra
spec:
  rules:
    - host: contoso.com
      requestRedirect:
        statusCode: 301
        scheme: https
EOF

  2. Creare una risorsa IngressExtension per gestire il reindirizzamento basato sul percorso da contoso.com/summer-promotion a contoso.com/shop/category/5.

    kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
  name: summer-promotion-redirect
  namespace: test-infra
spec:
  rules:
    - host: contoso.com
      requestRedirect:
        statusCode: 302
        path:
          type: ReplaceFullPath
          replaceFullPath: /shop/category/5
EOF

Distribuire le risorse Ingress richieste

  1. Creare la prima risorsa In ingresso per l'ascolto delle richieste HTTPS.

    kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-https
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
    alb.networking.azure.io/alb-frontend: ingress-fe
spec:
  ingressClassName: azure-alb-external
  tls:
    - hosts:
        - contoso.com
      secretName: listener-tls-secret
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echo
                port:
                  number: 80
EOF

  2. Creare la seconda risorsa In ingresso per l'ascolto sulla porta 80 e il reindirizzamento a HTTPS.

    kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-http
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
    alb.networking.azure.io/alb-frontend: ingress-fe
    alb.networking.azure.io/alb-ingress-extension: http-to-https
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echo
                port:
                  number: 80
EOF

  3. Creare una terza risorsa In ingresso per l'ascolto sulla porta 80 e 443 per contoso.com/summer-promotion e il reindirizzamento a contoso.com/shop/category/5.

    kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-summer-promotion-redirect
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
    alb.networking.azure.io/alb-frontend: ingress-fe
    alb.networking.azure.io/alb-ingress-extension: summer-promotion-redirect
spec:
  ingressClassName: azure-alb-external
  tls:
    - hosts:
        - contoso.com
      secretName: listener-tls-secret
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /summer-promotion
            pathType: Prefix
            backend:
              service:
                name: ignored-for-redirect
                port:
                  number: 80
EOF

Nota

Quando il controller ALB crea l'Application Gateway per le risorse dei contenitori in Azure Resource Manager, usa la convenzione di denominazione seguente per una risorsa frontend: fe-<eight randomly generated characters>.

Per modificare il nome della risorsa front-end creata in Azure, valutare la possibilità di seguire la strategia di distribuzione BYO.

Per ciascuna risorsa In ingresso, verificare che lo stato sia valido, che il listener sia Programmato e che venga assegnato un indirizzo alla risorsa in ingresso. Per tutte e tre le risorse In ingresso, in questo esempio dovrebbe essere visualizzato lo stesso nome host.

kubectl get ingress ingress-https -n test-infra -o yaml

Output di esempio della creazione corretta della risorsa In ingresso.

status:
  loadBalancer:
    ingress:
    - hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.fzyy.alb.azure.com
      ports:
      - port: 443
        protocol: TCP

Testare l'accesso all'applicazione

A questo punto, è possibile inviare traffico all'applicazione di esempio tramite l’FQDN assegnato al front-end. Usare il comando seguente per ottenere il nome di dominio completo (FQDN).

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

Quando si specifica l'indicatore del nome del server usando il comando curl, http://contoso.com deve restituire una risposta del Gateway applicativo per contenitori con un'intestazione location che definisce un reindirizzamento 301 a https://contoso.com.

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

Attraverso la risposta, dovremmo vedere quanto segue:

* Added contoso.com:80:xxx.xxx.xxx.xxx to DNS cache
* Hostname contoso.com was found in DNS cache
*   Trying xxx.xxx.xxx.xxx:80...
* Connected to contoso.com (xxx.xxx.xxx.xxx) port 80 (#0)
> GET / HTTP/1.1
> Host: contoso.com
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< location: https://contoso.com/
< date: Mon, 26 Feb 2024 22:56:23 GMT
< server: Microsoft-Azure-Application-LB/AGC
< content-length: 0
<
* Connection #0 to host contoso.com left intact

Quando si specifica l'indicatore del nome del server usando il comando curl, il Gateway applicativo per contenitori https://contoso.com/summer-promotion deve restituire un reindirizzamento 302 a https://contoso.com/shop/category/5.

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:443:$fqdnIp https://contoso.com/summer-promotion -v

Attraverso la risposta, dovremmo vedere quanto segue:

> GET /summer-promotion HTTP/2
> Host: contoso.com
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 302
< location: https://contoso.com/shop/category/5
< date: Mon, 26 Feb 2024 22:58:43 GMT
< server: Microsoft-Azure-Application-LB/AGC
<
* Connection #0 to host contoso.com left intact

Congratulazioni, è stato installato il controller ALB, è stata distribuita un'applicazione back-end e è stata usata l'API Ingress per configurare sia un reindirizzamento HTTP a HTTPS che il reindirizzamento basato sul percorso a richieste client specifiche.

  • Last updated on