Modifica

Esecuzione di un'applicazione Web di base in Azure

Servizio app di Azure
Insieme di credenziali chiave di Azure
Monitoraggio di Azure
database SQL di Azure

Questa architettura illustra i componenti fondamentali di un'applicazione Web di base. È possibile usare l'architettura per compilare un'applicazione Web e quindi personalizzare l'applicazione in base alle proprie esigenze.

Architettura

Diagramma che mostra l'architettura di riferimento per un'applicazione Web di base in Azure.

Scaricare un file di Visio di questa architettura.

Componenti

  • Servizio app di Azure è una piattaforma completamente gestita per la creazione e la distribuzione di applicazioni cloud. Consente di definire un set di risorse di calcolo per l'esecuzione di un'app Web, la distribuzione di app Web e la configurazione degli slot di distribuzione.
  • Gli slot di distribuzione consentono di preparare una distribuzione e quindi di scambiarla con la distribuzione di produzione. In questo modo è possibile evitare di eseguire la distribuzione direttamente nell'ambiente di produzione. Per indicazioni specifiche, vedere la sezione relativa alla progettazione e alla distribuzione del rilascio di seguito.
  • Indirizzo IP: l'app servizio app ha un indirizzo IP pubblico e un nome di dominio. Il nome di dominio è un sottodominio di azurewebsites.net, ad esempio contoso.azurewebsites.net.
  • DNS di Azure è un servizio di hosting per i domini DNS, che fornisce la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. Ospitando i domini in Azure, è possibile gestire i record DNS usando le stesse credenziali, API, strumenti e fatturazione come per gli altri servizi Azure. Per usare un nome di dominio personalizzato ( ad esempio contoso.com), creare record DNS che eseguono il mapping del nome di dominio personalizzato all'indirizzo IP. Per ulteriori informazioni, vedere Configurare un nome di dominio personalizzato nel servizio app di Azure.
  • database SQL di Azure è un database relazionale come servizio nel cloud. Il database SQL condivide la base di codice con il motore di database di Microsoft SQL Server. A seconda dei requisiti dell'applicazione, è anche possibile usare Database di Azure per MySQL o Database di Azure per PostgreSQL. Queste alternative sono servizi di database completamente gestiti basati sui motori di database MySQL Server e Postgres open source.
  • Microsoft Entra ID è un servizio di gestione delle identità e degli accessi basato sul cloud che consente ai dipendenti di accedere alle app cloud sviluppate per l'organizzazione.
  • Monitoraggio di Azure è una soluzione per la raccolta, l'analisi e l'uso di log e metriche in tutti gli ambienti.
  • Azure Key Vault supporta la gestione dei segreti, la gestione delle chiavi e la gestione dei certificati. Può archiviare segreti dell'applicazione come i stringa di connessione di database.

Consigli

I requisiti potrebbero essere diversi dall'architettura descritta e specificata nel codice. Il codice viene distribuito con configurazioni di produzione. Usare i consigli per personalizzare la distribuzione in base alle proprie esigenze.

Piano di servizio app

Il piano servizio app ha piani tariffari diversi. Ogni piano tariffario supporta diverse dimensioni di istanza che differiscono per il numero di core e memoria. È possibile modificare il piano tariffario dopo la distribuzione selezionando "Aumentare le prestazioni (piano servizio app)" nel riquadro di spostamento a sinistra. Ecco alcuni consigli servizio app:

  • Eseguire il carico di lavoro di produzione nei piani tariffari Basic, Standard e Premium . In questi tre livelli, l'app viene eseguita in istanze di macchina virtuale dedicate e ha allocato risorse che possono aumentare il numero di istanze.
  • Usare i livelli Standard e Premier se sono necessari la scalabilità automatica e TLS/SSL.
  • Creare un piano di servizio app diverso per il test e lo sviluppo. Usare i livelli Gratuito e Condiviso (anteprima) per il test e lo sviluppo per un'efficienza dei costi. Ma non usare i livelli Gratuito e Condiviso per i carichi di lavoro di produzione. Le risorse condivise non possono aumentare il numero di istanze.
  • Assicurarsi di eliminare i piani che non si usano, ad esempio i test delle distribuzioni. I piani di servizio app vengono fatturati al secondo. Vengono addebitati i costi per le istanze nel piano di servizio app anche se l'app viene arrestata. Per altre informazioni sui piani e la fatturazione di servizio app, vedere:

Il modello di Resource Manager seguente viene distribuito nel piano tariffario Standard.

Database SQL

  • Usare database SQL di Azure per ridurre il sovraccarico di gestione. database SQL di Azure crea un costrutto logico che funge da punto amministrativo centrale per una raccolta di database. Questo costrutto logico riduce il sovraccarico di gestione. Ogni database all'interno del gruppo viene distribuito con un livello di servizio specifico. All'interno di ogni gruppo, i database non possono condividere le risorse. Non sono previsti costi di calcolo per il server, ma è necessario specificare il livello per ogni database. Di conseguenza, le prestazioni potrebbero essere migliori a causa delle risorse dedicate, ma il costo può essere superiore.
  • Eseguire la pianificazione delle capacità e scegliere un livello di prestazioni che soddisfi i propri requisiti. Il database SQL supporta i livelli di servizio Basic, Standard e Premium con più livelli di prestazioni all'interno di ciascuno di essi, misurati in DTU (Database Transaction Unit).

Paese

  • Creare il piano di servizio app e il database SQL nella stessa area per ridurre al minimo la latenza di rete. In genere, è consigliabile selezionare l'area più vicina agli utenti.
  • Anche il gruppo di risorse è associato a un'area Specifica dove vengono archiviati i metadati di distribuzione. Inserire il gruppo di risorse e le relative risorse nella stessa area per migliorare la disponibilità durante la distribuzione.
  • Usare il calcolatore prezzi per stimare i costi.
  • Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework. I pilastri sono una serie di set di principi guida che migliorano la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Efficienza prestazionale

Uno dei vantaggi principali del servizio app di Azure è la possibilità di scalare l'applicazione in base al carico. Ecco alcune considerazioni da tenere presenti quando si pianifica la scalabilità dell'applicazione.

Scalabilità dell'app del servizio app

Esistono due modi per scalare un'app del servizio app:

  • Aumentare le prestazioni significa modificare le dimensioni dell'istanza. La dimensione dell'istanza determina la memoria, il numero di core e l'archiviazione in ogni istanza della macchina virtuale. È possibile scalare verticalmente in modo manuale modificando la dimensione dell'istanza o il livello di piano.
  • Aumentare il numero di istanze significa aggiungere istanze per gestire un carico maggiore. Ogni livello tariffario prevede un numero massimo di istanze. È possibile aumentare il numero di istanze modificando manualmente il numero di istanze o configurando la scalabilità automatica in modo che Azure aggiunga o rimuovono automaticamente istanze in base a una pianificazione e/o a metriche delle prestazioni. Ogni operazione di scalabilità avviene rapidamente, in genere entro pochi secondi.

Per abilitare la scalabilità automatica, creare un profilo di scalabilità automatica che definisce il numero minimo e massimo di istanze. È possibile configurare profili basati su pianificazione per attivare eventi di scalabilità. Ad esempio, è possibile creare profili separati per i giorni feriali e i fine settimana. Un profilo può contenere regole per quando aggiungere o rimuovere istanze. Ad esempio, l'aggiunta di due istanze se l'utilizzo della CPU è superiore al 70% per 5 minuti.

Consigli per la scalabilità di un'app Web:

  • Limitare il più possibile l'aumento e la riduzione delle prestazioni. Può attivare un riavvio dell'applicazione. Aumentare invece il numero di istanze. Selezionare un livello e le dimensioni che soddisfano i requisiti di prestazioni in base al carico tipico e quindi aumentare le istanze per gestire le modifiche nel volume di traffico.
  • Abilitare la scalabilità automatica. Se l'applicazione presenta un carico di lavoro regolare e prevedibile, creare profili per pianificare i conteggi delle istanze anticipatamente. Se il carico di lavoro non è prevedibile, usare la scalabilità automatica basata su regole per reagire alle modifiche del carico man mano che si verificano. È possibile combinare entrambi gli approcci.
  • Usare l'utilizzo della CPU per le regole di scalabilità automatica. L'uso della CPU è in genere una buona metrica per le regole di scalabilità automatica. È tuttavia necessario testare il carico dell'applicazione, identificare potenziali colli di bottiglia e basare le regole di scalabilità automatica su tali dati.
  • Impostare un periodo di raffreddamento più breve per l'aggiunta di istanze e un periodo di raffreddamento più lungo per la rimozione delle istanze. Le regole di scalabilità automatica includono un periodo di raffreddamento . Il periodo di raffreddamento è l'intervallo di attesa dopo il completamento di un'azione di ridimensionamento prima di avviare una nuova azione di ridimensionamento. Il periodo di raffreddamento consente di stabilizzare il sistema prima di una nuova azione di ridimensionamento. Impostare, ad esempio, 5 minuti per aggiungere un'istanza e 60 minuti per rimuoverla. È preferibile aggiungere rapidamente nuove istanze con un carico elevato per gestire il traffico aggiuntivo e quindi ridurre gradualmente il numero di istanze.

Ridimensionamento dei database SQL

Aumentare le prestazioni dei singoli database senza tempi di inattività dell'applicazione se è necessario un livello di servizio o un livello di prestazioni superiore per database SQL.

Per altre informazioni, vedere Ridimensionare le risorse di database singoli nel database SQL di Azure.

Affidabilità

Al momento della scrittura, il contratto di servizio (SLA) per servizio app è del 99,95%. Il contratto di servizio del servizio app si applica a una o più istanze. Il contratto di servizio per database SQL è del 99,99% per i livelli Basic, Standard e Premium.

Backup

database SQL fornisce il ripristino temporizzato e il ripristino geografico per ripristinare la perdita di dati. Tali funzionalità sono disponibili in tutti i livelli e vengono abilitate automaticamente. Non è necessario pianificare o gestire i backup.

Eccellenza operativa

Creare gruppi di risorse separati per gli ambienti di produzione, sviluppo e test. La separazione degli ambienti semplifica la gestione delle distribuzioni, l'eliminazione delle distribuzioni di test e l'assegnazione dei diritti di accesso.

Quando si assegnano risorse ai gruppi di risorse, prendere in considerazione le funzionalità seguenti:

  • Ciclo di vita. In generale, includere le risorse con un ciclo di vita identico nello stesso gruppo di risorse.
  • Accesso. È possibile usare il controllo degli accessi in base al ruolo di Azure per applicare i criteri di accesso alle risorse in un gruppo.
  • Fatturazione. È possibile visualizzare il riepilogo dei costi per il gruppo di risorse.

Per altre informazioni, vedere Panoramica di Azure Resource Manager.

Configurazioni delle app

  • Archiviare le impostazioni di configurazione come impostazioni app. Definire le impostazioni dell'app nei modelli di Resource Manager o tramite PowerShell. In fase di runtime, le impostazioni dell'app sono disponibili come variabili di ambiente.
  • Non archiviare mai le password, le chiavi di accesso o le stringhe di connessione nel controllo del codice sorgente, Passare invece segreti come parametri a uno script di distribuzione che archivia questi valori come impostazioni dell'app.
  • Durante lo scambio di uno slot di distribuzione, le impostazioni dell'app vengono scambiate per impostazione predefinita. Se sono necessarie impostazioni di produzione e gestione temporanea diverse, è possibile creare impostazioni dell'app che si attaccano a uno slot e non vengono scambiate.

Diagnostica e monitoraggio

DevOps

  • Usare i modelli di Resource Manager per distribuire le risorse di Azure e le relative dipendenze. Il modello arm a cui si accompagna distribuisce una singola applicazione Web. Tutte le risorse sono isolate nello stesso carico di lavoro di base. Questo isolamento semplifica l'associazione delle risorse specifiche del carico di lavoro a un team. Il team può quindi gestire in modo indipendente tutti gli aspetti di tali risorse. Questo isolamento consente al team DevOps di eseguire l'integrazione continua e il recapito continuo (CI/CD).
  • Usare modelli arm diversi e integrarli con i servizi Azure DevOps. Questa configurazione consente di creare ambienti diversi in pochi minuti. Ad esempio, è possibile replicare scenari simili alla produzione o ambienti di test di carico solo quando necessario e risparmiare sui costi.
  • Effettuare il provisioning di più istanze dell'applicazione Web. Non si vuole che l'app Web dipenda da una singola istanza e crei potenzialmente un singolo punto di errore. Più istanze migliorano la resilienza e la scalabilità.

Per altre informazioni, vedere la sezione DevOps in Azure Well-Architected Framework.

Progettazione e distribuzione del rilascio

  • Usare i modelli di Azure Resource Manager per effettuare il provisioning delle risorse di Azure. I modelli semplificano l'automazione delle distribuzioni tramite PowerShell o l'interfaccia della riga di comando di Azure.
  • Distribuire l'applicazione (codice, file binari e file di contenuto). Sono disponibili diverse opzioni, tra cui la distribuzione da un archivio Git locale, tramite Visual Studio, o la distribuzione continua dal controllo del codice sorgente basato su cloud. Vedere l'articolo relativo alla distribuzione dell'app nel servizio app di Azure.

Un'app servizio app ha sempre uno slot di distribuzione denominato production. Lo slot di produzione rappresenta il sito di produzione live. È consigliabile creare uno slot di gestione temporanea per la distribuzione degli aggiornamenti. I vantaggi dell'utilizzo di uno slot di gestione temporanea includono:

  • È possibile verificare che la distribuzione sia riuscita prima di scambiarla nell'ambiente di produzione.
  • La distribuzione in uno slot di gestione temporanea consente di eseguire il riscaldamento di tutte le istanze prima che vengano scambiate nell'ambiente di produzione. Molte applicazioni presentano tempi di riscaldamento e di avvio a freddo piuttosto lunghi.
  • Creare un terzo slot per contenere l'ultima distribuzione valida nota. Dopo lo scambio tra gestione temporanea e produzione, spostare la distribuzione della produzione precedente (ora in gestione temporanea) nell'ultimo slot valido. In questo modo, in caso di problemi successivi, sarà possibile ripristinare l'ultima versione valida.

Swapping slots for production and staging deployments (Scambio di slot per le distribuzioni di produzione e gestione temporanea)

  • Se si ripristina una versione precedente, assicurarsi che le modifiche allo schema del database siano compatibili con le versioni precedenti.
  • Non usare gli slot nella distribuzione della produzione per il test, perché tutte le applicazioni include nello stesso piano del servizio app condividono le stesse istanze della macchina virtuale. I test di carico, ad esempio, possono ridurre le prestazioni del sito di produzione attivo. Creare invece piani del servizio app separati per gli ambienti di produzione e di test. Se si inseriscono le distribuzioni di test in un piano separato, le si isola dalla versione di produzione.

Sicurezza

Questa sezione contiene alcune considerazioni sulla sicurezza specifiche dei servizi di Azure descritti in questo articolo. Non è un elenco completo delle procedure di sicurezza consigliate. Per altre considerazioni sulla sicurezza, vedere Proteggere un'app nel servizio app Azure.

Controllo del database SQL

Il controllo consente di agevolare la conformità alle normative e ottenere informazioni su eventuali discrepanze e anomalie che potrebbero indicare problemi aziendali o sospette violazioni della sicurezza. Vedere Introduzione al controllo del database SQL.

Slot di distribuzione

Ogni slot di distribuzione è associato un indirizzo IP pubblico. Proteggere gli slot non di produzione usando l'account di accesso di Microsoft Entra in modo che solo i membri dei team di sviluppo e DevOps possano raggiungere tali endpoint.

Registrazione

I log non devono mai registrare le password degli utenti o altre informazioni che potrebbero essere usate per commettere furti di identità. Eseguire lo scrubbing di questi dettagli dai dati prima di archiviarli.

SSL

Un'app servizio app include un endpoint SSL in un sottodominio di azurewebsites.net senza costi aggiuntivi. L'endpoint SSL include un certificato con caratteri jolly per il nome di dominio *.azurewebsites.net. Se si usa un nome di dominio personalizzato, è necessario specificare un certificato corrispondente al dominio personalizzato. L'approccio più semplice consiste nell'acquistare un certificato direttamente tramite il portale di Azure. È inoltre possibile importare i certificati da altre autorità di certificazione. Per altre informazioni, vedere Acquistare e configurare un certificato SSL per il servizio app Azure.

HTTPS non è abilitato per impostazione predefinita nella distribuzione del modello di Resource Manager. Come procedura ottimale di protezione, l'app deve applicare HTTPS mediante il reindirizzamento delle richieste HTTP. È possibile implementare HTTPS all'interno dell'applicazione o usare una regola di riscrittura URL come descritto in Abilitare HTTPS per un'app nel servizio app Azure.

Autenticazione

È consigliabile eseguire l'autenticazione tramite un provider di identità (IDP), ad esempio Microsoft Entra ID, Facebook, Google o Twitter. Usare OAuth 2 o OpenID Connect (OIDC) per il flusso di autenticazione. Microsoft Entra ID offre funzionalità per gestire utenti e gruppi, creare ruoli applicazione, integrare le identità locali e utilizzare servizi back-end come Microsoft 365 e Skype for Business.

Evitare che l'applicazione gestisca direttamente gli account di accesso utente e le credenziali. Crea una potenziale superficie di attacco. Come minimo, è necessario avere una conferma tramite posta elettronica, il recupero delle password e l'autenticazione a più fattori, convalidare la complessità della password e archiviare gli hash delle password in modo sicuro. I provider di identità di grandi dimensioni gestiscono tutti questi aspetti e monitorano e migliorano costantemente le procedure di sicurezza.

È consigliabile usare l'autenticazione servizio app per implementare il flusso di autenticazione OAuth o OIDC. I vantaggi dell'autenticazione del servizio app sono:

  • È facile da configurare.
  • Non è necessario alcun codice per gli scenari di autenticazione semplici.
  • Supporta l'autorizzazione delegata mediante i token di accesso OAuth per l'uso delle risorse per conto dell'utente.
  • Offre una cache dei token incorporata.

Alcune limitazioni di autenticazione del servizio app:

  • Opzioni di personalizzazione limitate.
  • L'autorizzazione delegata è limitata a una sola risorsa di back-end per ogni sessione di accesso.
  • Se si usano più provider di identità, non esiste alcun meccanismo predefinito per l'individuazione dell'area di autenticazione principale.
  • Per gli scenari multi-tenant, l'applicazione deve implementare la logica per convalidare l'autorità emittente di token.

Distribuire lo scenario

Questa architettura include un piano di servizio app Azure e un'applicazione vuota. Usa database SQL di Azure, Azure Key Vault per archiviare il stringa di connessione del database e Monitoraggio di Azure per la registrazione, il monitoraggio e gli avvisi.

Usare il comando seguente per creare un gruppo di risorse per la distribuzione. Selezionare il pulsante Prova per usare una shell incorporata.

az group create --name basic-web-app --location eastus

Eseguire il comando seguente per distribuire l'applicazione Web e l'infrastruttura di supporto. Quando richiesto, immettere un nome utente e una password. Questi valori vengono usati per accedere all'istanza di database SQL di Azure.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Per informazioni dettagliate e altre opzioni di distribuzione, vedere i modelli di Resource Manager usati per distribuire questa soluzione.

Modello arm dell'applicazione Web di base

Passaggi successivi

Suggerimenti per la risoluzione dei problemi dell'applicazione:

Documentazione sui prodotti:

Moduli di Microsoft Learn: