• Cloud, Guide
• 20 Giugno 2019

Azure Front Door è un bilanciatore di carico globale che permette di avere funzionalità di protezione DDoS, caching e web application firewall (WAF). Si tratta di una piattaforma altamente disponibile e scalabile pensata per le applicazioni web, per i cloud services e per le macchine virtuali.

Il servizio Front Door di Azure consente di definire, gestire e monitorare il routing globale del traffico Web, ottimizzando le prestazioni e permettendo sempre la connessione alle applicazioni grazie al failover globale. Azure Front Door funziona al livello 7 del Modello OSI e usa il protocollo anycast con split TCP. Usando il protocollo anycast basato su split TCP, Front Door garantisce che gli utenti finali possano connettersi immediatamente al Frontdoor POP (Point of Presence) più vicino.

Il compito di questo servizio è quello di instradare le richieste del client nel back-end dell’applicazione che in quel momento risulta essere più veloce e maggiormente disponibile. Il backend di un’applicazione può essere qualsiasi servizio internet ospitato all’interno o all’esterno di Azure. Frontdoor offre diversi metodi di routing del traffico e opzioni di monitoraggio dell’integrità del back-end per soddisfare diverse esigenze delle applicazioni e i modelli di failover automatico.

Azure Front Door assicura disponibilità elevata per le applicazioni critiche usando i probe di integrità intelligenti, monitorando sia la latenza che la disponibilità dei back-end e offrendo un failover automatico istantaneo quando si verifica l’indisponibilità di un back-end.

In questa guida voglio farvi vedere come creare un profilo di Azure Front Door che fornisce disponibilità e prestazioni elevate per un’applicazione web globale.

Lo scenario descritto in questa guida include due istanze di un’applicazione web in esecuzione in aree di Azure diverse (una in Europa ed un’altra negli Stati Uniti). Verrà creata una configurazione di Front Door basata su back-end ponderati e con la stessa priorità, che consente di instradare il traffico utente al set più vicino di back-end. Front Door monitora continuamente l’applicazione web e si occuperà del failover automatico nel successivo back-end disponibile quando il sito primario non è disponibile.

Funzionamento di Azure Front Door

Creazione delle Web App

Ho distribuito due istanze di un’applicazione web in esecuzione in aree di Azure diverse (una in Europa ed un’altra negli Stati Uniti) ed entrambe possono ricevere traffico direttamente.

Per creare una web app è sufficiente loggarsi al portale di Azure e selezionare Crea una risorsa à Web à App Web à Crea. Nelle figure sotto sono mostrati i parametri che ho scelto per questa guida. Sono state create due applicazioni web che rispondono rispettivamente gli indirizzi https://ictpower-eu.azurewebsites.net (in Europa) e https://ictpower-us.azurewebsites.net (negli Stati Uniti).

Figura 1: Creazione della Web App negli Stati Uniti

Figura 2: Creazione della Web App in Europa

Successivamente ho provveduto a popolare le due Web App con alcuni contenuti, per testarne il funzionamento.

Creazione del profilo di Front Door

Dal portale di Azure cercate nel MarketPlace la risorsa Front Door e create un nuovo profilo da Crea una risorsa à Rete à Front Door à Crea

Figura 3: Creazione di un nuovo profilo Front Door dal Marketplace

Inserite le informazioni di base immettendo la sottoscrizione in cui configurare la front door ed il resource group che la ospiterà.

Figura 4: Inserimento delle configurazioni di base di Azure Front Door

Una volta compilate le informazioni di base, il primo passaggio consiste nel definire l’host front-end per la configurazione. Il nome da utilizzare deve essere un nome di dominio valido e deve essere univoco. Io ho scelto ictpower-fd.azurefd.net

È anche possibile configurare i parametri di Session Affinity ed eventualmente abilitare il Web Application Firewall, progettato e gestito per difendere i servizi web da vulnerabilità comuni e per mantenere una disponibilità elevata del servizio per gli utenti, oltre che per aiutare a soddisfare i requisiti di conformità.

Figura 5: Scelta dell’host front-end per la configurazione di Front Door

Successivamente è necessario configurare uno o più back-end dell’applicazione in un pool back-end, per indicare a Front Door dove si trova l’applicazione. Fate clic sull’icona ‘+’ per aggiungere un pool back-end e quindi specificate un nome per il pool back-end. Io ho scelto ITCPower-backends.

Il Pool di backend è un raggruppamento logico delle istanze delle app distribuite in tutto il mondo che devono ricevere lo stesso tipo di traffico.

Figura 6: Creazione del pool di backend

Fate clic su Add a backend per aggiungere i siti web creati in precedenza. È possibile aggiungere diversi tipi di backend: App Service, Cloud Service, Storage, Storage (classic) e Custom host. Per maggiori informazioni consultate la guida Backends and backend pools in Azure Front Door Service

Figura 7: Tipi di backend host che è possibile aggiungere ad Azure Front Door

Selezionate App Service come backend host type, selezionate la sottoscrizione in cui è stato creato il primo sito web e quindi scegliete il primo sito web dal menu a tendina Backend host header. Ripetete il passaggio per aggiungere anche il secondo sito web da aggiungere al backend.

Figura 8: Aggiunta del primo sito web al backend

Figura 9: Aggiunta del secondo sito web al backend

Al termine delle due operazioni i due siti di backend saranno visibili nel blade.

Figura 10: I due siti web sono stati aggiunti al backend

Prima di fare click su Add per aggiungere il backend pool ricordatevi di controllare Health probes, che serviranno a determinare la prossimità (misurando la latenza di connessione) e l’integrità di ogni back-end (controllando di ricevere un 200 OK status code) per caricare e per bilanciare le richieste degli utenti finali. Io ho lasciato un intervallo di 30 secondi, ma ovviamente può essere ridotto per essere ancora più veloci in caso di failure di uno degli endpoint.

Infine, fate clic sull’icona ‘+’ in Routing Rules per configurare una regola di routing. Questo è necessario per eseguire il mapping dell’host front-end con il pool back-end, che in sostanza consiste nel configurare che, quando ictpower-fd.azurefd.net riceve una richiesta, deve inoltrarla al pool back-end ICTpower-backends.

Figura 11: Aggiunta della regola di routing per eseguire il mapping dell’host front-end con il pool back-end

Per maggiori informazioni sull’architettura di routing di Azure Front Door vi rimando alla lettura dell’articolo Panoramica dell’architettura di routing

Figura 12: Configurazione di Azure Front Door completata

Figura 13: la risorsa Azure Front Door è stata creata

È possibile modificare in qualsiasi momento le configurazioni effettuate semplicemente selezionando la risorsa Azure Front Door e cliccando sul nodo Front Door Designer, come mostrato in figura:

Figura 14: È possibile apportare modifiche alla configurazione tramite il Front Door Designer

Verifica del funzionamento

Dopo aver creato una Front Door, occorreranno alcuni minuti perché la configurazione venga distribuita ovunque a livello globale. Al termine della distribuzione, accedete all’host front-end creato (nel mio caso è https://ictpower-fd.azurefd.net)

La richiesta verrà automaticamente instradata al back-end più vicino tra quelli specificati nel pool back-end (nel mio caso il sito web europeo).

NOTA: Ho volutamente configurato in maniera diversa i due siti (quello europeo e quello statunitense) in modo tale da poter verificare che il reindirizzamento avvenga in maniera corretta.

Figura 15: Azure Front Door mi reindirizza al sito web europeo, quello più vicino

Se volete testare il failover di Front Door, potete arrestare una delle Web App create. In base all’impostazione dell’health probe per il pool back-end, verrà eseguito immediatamente il failover del traffico verso l’altra distribuzione del sito Web. Ho quindi stoppato l’applicazione web che gira in Europa e dopo pochi secondi (io avevo configurato un probe per 30 secondi) mi ha risposto l’applicazione web che gira negli Stati Uniti.

Figura 16: Azure Front Door ha eseguito il failover verso il sito web ospitato negli Stati Uniti

Aggiunta di un dominio personalizzato ad Azure Front Door

Quando si usa il servizio Front Door di Azure per la distribuzione di un’applicazione web, un dominio personalizzato è necessario se si vuole che il nome di dominio sia visibile nella richiesta dell’utente finale. Per aggiungere il vostro dominio personalizzato sarà prima necessario creare un record CNAME nel proprio pannello DNS che punti al nome del frontend host (nel mio caso ictpower-fd.azurefd.net)

Ho deciso di aggiungere un nome personalizzato chiamato test.ictpower.it e nel momento in cui tento di aggiungerlo ai FrontEnd host il portale di Azure mi avvisa che non riesce a trovare il record CNAME nella zona DNS di ICTPower.it; l’errore è riportato nella figura sotto:

Figura 17: Aggiunta di un dominio personalizzato ad Azure Front Door

Dopo aver aggiunto in maniera corretta il record CNAME alla zona DNS, il nome host viene verificato e viene aggiunto il dominio personalizzato. Ricordatevi anche modificare le Routing Rules in modo tale che tra i Frontend hosts ci sia anche il nuovo nome di dominio. Un messaggio di avviso vi inviterà a modificare la Routing Rule prima del salvataggio.

Figura 18: Configurazione delle regole di routing di Front Door per l’utilizzo di un dominio personalizzato

Figura 19: Il servizio di Azure Front Door è raggiungibile attraverso un dominio personalizzato

Configurare HTTPS per un dominio personalizzato di Front Door

È possibile abilitare il protocollo HTTPS per il dominio personalizzato associato al profilo di Azure Front Door. Per farlo vio basterà selezionare il Frontend host da modificare e cliccare su Enabled nella sezione CUSTOM DOMAIN HTTPS. È possibile scegliere di usare un certificato gestito dal servizio Front Door di Azure oppure utilizzare un certificato personale. Per utilizzare certificati personali fate riferimento alla guida https://docs.microsoft.com/it-it/azure/frontdoor/front-door-custom-domain-https

Figura 20: Abilitazione del supporto HTTPS al dominio personalizzato in Azure Front Door

Dopo aver cliccato sul pulsante Update sarà necessario attendere qualche minuto per la generazione del certificato. Cliccando nuovamente sul nome di dominio personalizzato sarà possibile seguire lo stato di avanzamento delle operazioni, come mostrato nella figura sotto:

Figura 21: Stato di avanzamento della generazione del certificato per il dominio personalizzato di Azure Front Door

NOTA: Se si utilizza un record di autorizzazione dell’autorità di certificazione (CAA, Certificate Authority Authorization) con il provider DNS, il record deve includere DigiCert come CA valida. Un record CAA consente ai proprietari di domini di indicare ai propri provider DNS le CA autorizzate a emettere certificati per i loro domini. Se una CA riceve l’ordine di un certificato per un dominio dotato di record CAA ma la CA non è citata come autorità emittente autorizzata in tale record, non deve emettere il certificato per il dominio o il sottodominio.

Figura 22: Configurazione del record CAA corretto nella zona DNS

Dopo la convalida del nome di dominio, per l’attivazione della funzionalità HTTPS per il dominio personalizzato possono essere necessarie 6-8 ore. Nel mio caso il processo di generazione del certificato è durato un paio d’ore.

Al termine del processo, lo stato HTTPS personalizzato nel portale di Azure viene impostato su Abilitato e i quattro passaggi nella finestra di dialogo del dominio personalizzato sono contrassegnati come completati. Il dominio personalizzato è ora pronto per l’uso di HTTPS.

Al termine della creazione del certificato il nome di dominio personalizzato aggiunto ad Azure Front Door non darà più errori, come mostrato in figura:

Figura 23: Azure Front Door presenta il certificato corretto

Conclusioni

Azure Front Door permette di rendere altamente disponibili applicazioni web, servizi cloud e macchine virtuali. Il bilanciatore di carico globale garantisce prestazioni elevate perché gli utenti possono connettersi al Front Door POP (Point of Presence) più vicino. Usando gli health probe intelligenti e monitorando sia la latenza che la disponibilità dei back-end è possibile avere un failover automatico istantaneo quando si verifica un problema con un back-end. In più, il routing basato su percorso URL consente di instradare il traffico verso pool di back-end in base ai percorsi URL della richiesta. Uno degli scenari è l’instradamento delle richieste di tipi di contenuto diversi a pool di back-end diversi.