Esecuzione di un'applicazione Web di base in Azure

Questo articolo fornisce un'architettura di base destinata all'apprendimento dell'esecuzione di applicazioni Web in app Azure Servizio in una singola area.

Architettura

Figura 1: Architettura di base del servizio app Azure

Scaricare un file di Visio di questa architettura.

Workflow

1. Un utente invia una richiesta HTTPS al dominio predefinito del servizio app in azurewebsites.net. Questo dominio punta automaticamente all'indirizzo IP pubblico predefinito del servizio app. La connessione TLS viene stabilita dal client direttamente al servizio app. Il certificato viene gestito completamente da Azure.
2. Easy Auth, una funzionalità del servizio app Azure, garantisce che l'utente che accede al sito sia autenticato con Microsoft Entra ID.
3. Il codice dell'applicazione distribuito in servizio app gestisce la richiesta. Ad esempio, tale codice potrebbe connettersi a un'istanza di database SQL di Azure, usando un stringa di connessione configurato nella servizio app configurata come impostazione dell'app.
4. Le informazioni sulla richiesta originale per servizio app e la chiamata a database SQL di Azure vengono registrate in Application Insights.

Componenti

• Microsoft Entra ID è un servizio per la gestione delle identità e degli accessi basato sul cloud. Fornisce un singolo piano di controllo delle identità per gestire autorizzazioni e ruoli per gli utenti che accedono all'applicazione Web. Si integra con servizio app e semplifica l'autenticazione e l'autorizzazione per le app Web.
• Servizio app è una piattaforma completamente gestita per la creazione, la distribuzione e il ridimensionamento di applicazioni Web.
• Monitoraggio di Azure è un servizio di monitoraggio che raccoglie, analizza e agisce sui dati di telemetria nella distribuzione.
• Database di Azure SQL è un servizio di database relazionale completamente gestito per i dati relazionali.

Raccomandazioni e considerazioni

I componenti elencati in questa architettura sono collegati alle guide al servizio Azure Well-Architected. Le guide al servizio illustrano in dettaglio le raccomandazioni e le considerazioni per servizi specifici. Questa sezione estende le linee guida evidenziando le raccomandazioni e le considerazioni chiave di Azure Well-Architected Framework applicabili a questa architettura. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Questa architettura di base non è destinata alle distribuzioni di produzione. L'architettura favorisce la semplicità e l'efficienza dei costi rispetto alle funzionalità per consentire di valutare e apprendere app Azure Servizio. Le sezioni seguenti illustrano alcune carenze di questa architettura di base, insieme a raccomandazioni e considerazioni.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Poiché questa architettura non è progettata per le distribuzioni di produzione, di seguito sono descritte alcune delle funzionalità di affidabilità critiche omesse in questa architettura:

• Il piano di servizio app è configurato per il Standard livello, che non supporta la zona di disponibilità di Azure. Il servizio app diventa non disponibile in caso di problemi con l'istanza, il rack o il data center che ospita l'istanza.
• Il database SQL di Azure è configurato per il Basic livello, che non supporta la ridondanza della zona. Ciò significa che i dati non vengono replicati tra zone di disponibilità di Azure, rischiando la perdita di dati di cui è stato eseguito il commit in caso di interruzione.
• Le distribuzioni in questa architettura possono comportare tempi di inattività con le distribuzioni dell'applicazione, perché la maggior parte delle tecniche di distribuzione richiede il riavvio di tutte le istanze in esecuzione. Gli utenti potrebbero riscontrare errori 503 durante questo processo. Questo problema viene risolto nell'architettura di base tramite gli slot di distribuzione. Per supportare la distribuzione simultanea degli slot, è necessario un'attenta progettazione dell'applicazione, gestione dello schema e gestione della configurazione dell'applicazione. Usare questo modello di verifica per progettare e convalidare l'approccio alla distribuzione di produzione basato su slot.
• La scalabilità automatica non è abilitata in questa architettura di base. Per evitare problemi di affidabilità a causa della mancanza di risorse di calcolo disponibili, è necessario effettuare l'overprovisioning per eseguire sempre con risorse di calcolo sufficienti per gestire la capacità massima simultanea.

Vedere come risolvere questi problemi di affidabilità nella sezione Affidabilità nell'applicazione Web con ridondanza della zona a disponibilità elevata baseline .

Se questo carico di lavoro richiederà un'architettura attiva-attiva o passiva in più aree, vedere le risorse seguenti:

• Approcci alle app servizio app in più aree per il ripristino di emergenza per indicazioni sulla distribuzione del carico di lavoro servizio app ospitato in più aree.
• Applicazione Web multi-area a disponibilità elevata per un'architettura di riferimento che segue un approccio attivo-passivo.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Poiché questa architettura non è progettata per le distribuzioni di produzione, di seguito vengono descritte alcune delle funzionalità di sicurezza critiche omesse in questa architettura, insieme ad altre raccomandazioni e considerazioni sull'affidabilità:

• Questa architettura di base non implementa la privacy della rete. I piani di dati e gestione per le risorse, ad esempio il servizio app Azure e Azure SQL Server, sono raggiungibili tramite la rete Internet pubblica. L'omissione di una rete privata aumenta significativamente la superficie di attacco dell'architettura. Per informazioni su come implementare la rete privata garantisce le funzionalità di sicurezza seguenti, consultare la sezione relativa alla rete dell'applicazione Web con ridondanza della zona a disponibilità elevata baseline:

  • Un singolo punto di ingresso sicuro per il traffico client
  • Il traffico di rete viene filtrato sia a livello di pacchetto che a livello DDoS.
  • L'esfiltrazione dei dati viene ridotta al minimo mantenendo il traffico in Azure usando collegamento privato
  • Le risorse di rete sono raggruppate e isolate logicamente l'una dall'altra tramite la segmentazione di rete.

• Questa architettura di base non include una distribuzione di Web application firewall di Azure. L'applicazione Web non è protetta da exploit e vulnerabilità comuni. Vedere l'implementazione di base per scoprire come è possibile implementare Web Application Firewall con il gateway application di Azure in un'architettura di Servizi app di Azure.

• Questa architettura di base archivia segreti come il stringa di connessione di SQL Server di Azure in Impostazioni app. Mentre le impostazioni dell'app vengono crittografate, quando si passa alla produzione, è consigliabile archiviare i segreti in Azure Key Vault per una maggiore governance. Una soluzione ancora migliore consiste nell'usare l'identità gestita per l'autenticazione e non avere segreti archiviati nella stringa di connessione.

• Lasciare abilitati il debug remoto e gli endpoint Kudu durante lo sviluppo o la fase di verifica è corretto. Quando si passa all'ambiente di produzione, è consigliabile disabilitare il piano di controllo, la distribuzione o l'accesso remoto non necessari.

• Lasciare abilitati i metodi di autenticazione locale per le distribuzioni di siti FTP e SCM durante la fase di sviluppo o modello di verifica. Quando si passa all'ambiente di produzione, è consigliabile disabilitare l'autenticazione locale a tali endpoint.

• Non è necessario abilitare Microsoft Defender per servizio app nella fase di verifica. Quando si passa all'ambiente di produzione, è necessario abilitare Defender per servizio app per generare raccomandazioni sulla sicurezza da implementare per aumentare il comportamento di sicurezza e per rilevare più minacce al servizio app.

• Servizio app di Azure include un endpoint SSL di un sottodominio di azurewebsites.net senza alcun costo aggiuntivo. Le richieste HTTP vengono reindirizzate all'endpoint HTTPS per impostazione predefinita. Per le distribuzioni di produzione, in genere si userà un dominio personalizzato associato al gateway applicazione o alla gestione API davanti alla distribuzione servizio app.

• Usare il meccanismo di autenticazione integrata per servizio app ("EasyAuth"). EasyAuth semplifica il processo di integrazione dei provider di identità nell'app Web. Gestisce l'autenticazione all'esterno dell'app Web, quindi non è necessario apportare modifiche significative al codice.

• Usare l'identità gestita per le identità del carico di lavoro. Identità gestita elimina la necessità che gli sviluppatori gestiscano le credenziali di autenticazione. L'architettura di base esegue l'autenticazione a SQL Server tramite password in un stringa di connessione. Prendere in considerazione l'uso dell'identità gestita per l'autenticazione in SQL Server di Azure.

Per ulteriori considerazioni aggiuntive sulla sicurezza, consultare la sezione Garantire la sicurezza di un'app in Servizio app di Azure.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Le sezioni seguenti forniscono indicazioni sulla configurazione, il monitoraggio e la distribuzione dell'applicazione servizio app.

Configurazioni app

Poiché l'architettura di base non è destinata all'ambiente di produzione, usa Configurazione Servizio app per archiviare i valori di configurazione e i segreti. L'archiviazione dei segreti nella configurazione servizio app è corretta per la fase poC. Non si usano segreti reali e non è necessaria la governance dei segreti necessaria per i carichi di lavoro di produzione.

Di seguito sono riportati i consigli e le considerazioni sulla configurazione:

• Per iniziare, usare servizio app configurazione per archiviare i valori di configurazione e i stringa di connessione nelle distribuzioni di modelli di verifica. Le impostazioni dell'app e le stringhe di connessione vengono crittografate e decrittografate appena prima di essere inserite nell'app all'avvio.
• Quando si passa alla fase di produzione, archiviare i segreti in Azure Key Vault. L'uso di Azure Key Vault migliora la governance dei segreti in due modi:
  • L'esternalizzazione dell'archiviazione dei segreti in Azure Key Vault consente di centralizzare l'archiviazione dei segreti. È disponibile un'unica posizione per gestire i segreti.
  • Usando Azure Key Vault, è possibile registrare ogni interazione con i segreti, inclusa ogni volta che si accede a un segreto.
• Quando si passa all'ambiente di produzione, è possibile gestire l'uso di Azure Key Vault e servizio app configurazione usando i riferimenti a Key Vault.

Diagnostica e monitoraggio

Durante la fase di verifica, è importante comprendere quali log e metriche sono disponibili per l'acquisizione. Di seguito sono riportati i consigli e le considerazioni per il monitoraggio nella fase di verifica:

• Abilitare la registrazione diagnostica per tutte le origini di log degli elementi. La configurazione dell'uso di tutte le impostazioni di diagnostica consente di comprendere quali log e metriche vengono forniti per impostazione predefinita e eventuali lacune che è necessario chiudere usando un framework di registrazione nel codice dell'applicazione. Quando si passa all'ambiente di produzione, è necessario eliminare le origini di log che non aggiungono valore e aggiungono rumore e costi al sink di log del carico di lavoro.
• Configurare la registrazione per l'uso di Analisi dei log di Azure. Analisi dei log di Azure offre una piattaforma scalabile per centralizzare la registrazione facile da eseguire.
• Usare Application Insights o un altro strumento APM (Application Performance Management) per generare dati di telemetria e log per monitorare le prestazioni dell'applicazione.

Distribuzione

Di seguito sono elencate le indicazioni per la distribuzione dell'applicazione servizio app.

• Seguire le indicazioni in CI/CD per Azure App Web con Azure Pipelines per automatizzare la distribuzione dell'applicazione. Iniziare a compilare la logica di distribuzione nella fase poC. L'implementazione di CI/CD nelle prime fasi del processo di sviluppo consente di eseguire rapidamente e in modo sicuro l'iterazione dell'applicazione durante lo spostamento verso la produzione.
• Usare i modelli ARM per distribuire le risorse di Azure e le relative dipendenze. È importante avviare questo processo nella fase di verifica. Man mano che si passa all'ambiente di produzione, si vuole poter distribuire automaticamente l'infrastruttura.
• Usare modelli arm diversi e integrarli con i servizi Azure DevOps. Questa configurazione consente di creare ambienti diversi. Ad esempio, è possibile replicare scenari simili alla produzione o ambienti di test di carico solo quando necessario e risparmiare sui costi.

Per maggiori informazioni, consultare la sezione su DevOps in Azure Well-Architected Framework.

Contenitori

L'architettura di base può essere usata per distribuire il codice supportato direttamente nelle istanze di Windows o Linux. In alternativa, servizio app è anche una piattaforma di hosting di contenitori per eseguire l'applicazione Web in contenitori. servizio app offre vari contenitori predefiniti. Se si usano app personalizzate o multi-contenitore per ottimizzare ulteriormente l'ambiente di runtime o per supportare un linguaggio di codice non supportato in modo nativo, è necessario introdurre un registro contenitori.

Piano di controllo

Durante la fase di verifica, acquisire familiarità con app Azure piano di controllo del servizio come esposto tramite il servizio Kudu. Questo servizio espone API di distribuzione comuni, ad esempio distribuzioni ZIP, espone log non elaborati e variabili di ambiente.

Se si usano contenitori, assicurarsi di comprendere la capacità di Kudu di aprire una sessione SSH in un contenitore per supportare funzionalità di debug avanzate.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Poiché questa architettura non è progettata per le distribuzioni di produzione, di seguito vengono descritte alcune delle funzionalità critiche di efficienza delle prestazioni omesse in questa architettura, insieme ad altre raccomandazioni e considerazioni sull'affidabilità:

Un risultato del modello di verifica deve essere la selezione dello SKU che si stima è adatto per il carico di lavoro. Il carico di lavoro deve essere progettato per soddisfare in modo efficiente la domanda tramite il ridimensionamento orizzontale modificando il numero di istanze di calcolo distribuite nel piano di servizio app. Non progettare il sistema in modo da dipendere dalla modifica dello SKU di calcolo per allinearlo alla domanda.

• Il servizio app in questa architettura di base non ha implementato il ridimensionamento automatico. Il servizio non aumenta in modo dinamico la scalabilità orizzontale o in per mantenere in modo efficiente l'allineamento con la domanda.
  • Il livello standard supporta le impostazioni di scalabilità automatica per consentire di configurare la scalabilità automatica basata su regole. Una parte del processo di verifica deve essere quella di arrivare a impostazioni di scalabilità automatica efficienti in base alle esigenze delle risorse del codice dell'applicazione e alle caratteristiche di utilizzo previste.
  • Per le distribuzioni di produzione, prendere in considerazione i livelli Premium che supportano la scalabilità automatica in cui la piattaforma gestisce automaticamente le decisioni di ridimensionamento.
• Seguire le linee guida per scalare verticalmente i database individuali senza tempi di inattività dell'applicazione se è necessario un livello di servizio o di prestazioni superiore per il database SQL.

Distribuire lo scenario

Le linee guida sono supportate da un'implementazione di esempio che illustra questa implementazione di base servizio app in Azure.

Passaggi successivi

Risorse correlate

• Applicazione Web con ridondanza della zona di base
• Applicazione Web a disponibilità elevata in più aree geografiche
• Approcci alle app servizio app in più aree per il ripristino di emergenza

Documentazione sui prodotti:

• Panoramica del Servizio app
• Panoramica di Monitoraggio di Azure
• Panoramica del piano di servizio app di Azure
• Panoramica di Log Analytics in Monitoraggio di Azure
• Cos'è Microsoft Entra ID?
• Informazioni sul database SQL di Azure

Moduli di Microsoft Learn:

• Configura e gestisci Monitoraggio di Azure
• Configura l'ID Microsoft Entra
• Configurare Monitoraggio di Azure
• Distribuire e configurare server, istanze e database per Azure SQL
• Esplorare Servizio app di Azure
• Ospitare un'applicazione Web con il servizio app di Azure
• Ospitare il dominio in DNS di Azure
• Implementare Azure Key Vault
• Gestire utenti e gruppi in Microsoft Entra ID