Esecuzione di un'applicazione Web di base in Azure

Servizio app di Azure
Monitoraggio di Azure
Database SQL di Microsoft Azure

Questo articolo fornisce un'architettura di base per informazioni sull'esecuzione di applicazioni Web in Servizio app di Azure in una singola area.

Importante

Questa architettura non è destinata alle applicazioni di produzione. Funziona come configurazione introduttiva per scopi di apprendimento e prova di concetto (POC). Per progettare un'applicazione App Service di produzione, vedere Applicazione Web a disponibilità elevata e ridondanza tra zone di riferimento.

Architettura

Diagramma che mostra un'architettura servizio app di base.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

Il flusso di lavoro seguente corrisponde al diagramma precedente.

  1. Un utente invia una richiesta HTTPS al dominio predefinito del servizio app in azurewebsites.net. Questo dominio punta automaticamente all'indirizzo IP pubblico integrato dell'applicazione App Service. La connessione TLS (Transport Layer Security) viene stabilita dal client direttamente al servizio app. Azure gestisce completamente il certificato.

  2. Easy Auth, una funzionalità del servizio app, garantisce che l'utente che accede al sito venga autenticato usando Microsoft Entra ID.

  3. Il codice dell'applicazione distribuito nel Servizio app gestisce la richiesta. Ad esempio, il codice potrebbe connettersi a un'istanza di database SQL di Azure usando un stringa di connessione configurato nel servizio app come impostazione dell'app.

  4. Le informazioni sulla richiesta originale al servizio app e la chiamata al database SQL vengono registrate in Application Insights.

Componenti

  • Microsoft Entra ID è un servizio di gestione delle identità e degli accessi basato sul cloud che fornisce funzionalità di autenticazione e autorizzazione. In questa architettura si integra con il servizio app tramite Easy Auth per garantire l'autenticazione per gli utenti che accedono all'applicazione Web. Semplifica anche il processo di autenticazione senza richiedere modifiche significative al codice.

  • Il servizio app è una piattaforma gestita per la compilazione, la distribuzione e il ridimensionamento di applicazioni Web. In questa architettura ospita il codice dell'applicazione Web, gestisce le richieste HTTPS nel dominio predefinito azurewebsites.net e si connette al database SQL tramite stringhe di connessione configurate.

  • Monitoraggio di Azure è un servizio di monitoraggio che raccoglie, analizza e agisce sui dati di telemetria provenienti da ambienti cloud e locali. In questa architettura acquisisce e archivia le informazioni sulle richieste al servizio app e le chiamate al database SQL tramite l'integrazione di Application Insights.

  • Il database SQL è un servizio di database relazionale gestito che offre funzionalità di SQL Server nel cloud. In questa architettura funge da livello di archiviazione dati, che consente all'applicazione del servizio app di connettersi tramite stringhe di connessione definite nelle impostazioni dell'app.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

I componenti elencati in questa architettura sono collegati alle guide ai servizi 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 considerazioni e le raccomandazioni chiave diWell-Architected Framework applicabili a questa architettura.

Questa architettura di base è progettata solo per scopi di valutazione e apprendimento. Assegna priorità alla semplicità e all'efficienza dei costi rispetto alle funzionalità di livello di produzione. Le sezioni seguenti illustrano le limitazioni principali di questa architettura e forniscono raccomandazioni e considerazioni utili per pianificare distribuzioni più affidabili.

Affidabilità

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

Questa architettura non è progettata per le distribuzioni di produzione. In questa architettura vengono omesse le funzionalità di affidabilità critiche seguenti:

  • Il piano di servizio app è configurato per il livello Standard, che non include il supporto per Azure zone di disponibilità. Il servizio app non è più disponibile se si verifica un problema con l'istanza, il rack o il data center che ospita l'istanza.

  • Il database SQL è configurato per il livello Basic, che non supporta la ridondanza della zona. Di conseguenza, i dati non vengono replicati tra le zone di disponibilità di Azure, mettendo a rischio la perdita di dati confermati se si verifica un'interruzione del servizio.

  • Le distribuzioni in questa architettura possono comportare tempi di inattività per le distribuzioni di applicazioni 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 tempo di inattività della distribuzione viene risolto nell'architettura di base tramite 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. Utilizzare questo POC per progettare e convalidare il vostro approccio alla distribuzione di produzione basato su slot.

  • La scalabilità automatica non è abilitata in questa architettura di base. Per evitare problemi di affidabilità causati da risorse di calcolo insufficienti, è necessario effettuare il overprovisioning per garantire una capacità sufficiente per gestire la domanda simultanea massima.

Per altre informazioni su come risolvere questi problemi di affidabilità, vedere Applicazione Web di base con zona a ridondanza e alta disponibilità - Affidabilità.

Se il carico di lavoro richiede un'architettura attiva-attiva o attiva-passiva in più aree, vedere Approcci all'app del servizio app in più aree per il ripristino di emergenza.

Sicurezza

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

Questa architettura non è progettata per le distribuzioni di produzione. In questa architettura sono state omesse le funzionalità di sicurezza critiche seguenti, insieme ad altre raccomandazioni e considerazioni sull'affidabilità:

  • Questa architettura di base non implementa la privacy della rete. I piani dati e di gestione per le risorse, ad esempio il servizio app 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 ulteriori informazioni su come l'implementazione di una rete privata garantisce le seguenti funzionalità di sicurezza, vedere Applicazione Web con zona ridondante ad alta disponibilità – Rete. L'implementazione della rete privata consente di ridurre questi rischi fornendo le funzionalità di sicurezza seguenti:

    • Un singolo punto di ingresso sicuro per il traffico client.

    • Il traffico di rete viene filtrato sia a livello di pacchetto che a livello di DDoS (Distributed Denial of Service).

    • L'esfiltrazione dei dati è ridotta mantenendo il traffico all'interno di Azure utilizzando collegamento privato di Azure.

    • 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. Per informazioni su come implementare Web application firewall di Azure con gateway applicazione di Azure in un'architettura di App Services, vedere l'implementazione di base .

  • Questa architettura di base archivia segreti come il SQL Server stringa di connessione in Impostazioni app. Le impostazioni dell'app vengono crittografate per impostazione predefinita. Tuttavia, quando si passa all'ambiente di produzione, è consigliabile archiviare i segreti in Azure Key Vault per una maggiore governance. Per una maggiore sicurezza e riduzione del sovraccarico di gestione dei segreti, è consigliabile usare l'identità gestita per l'autenticazione anziché incorporare segreti nelle stringhe di connessione.

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

  • I metodi di autenticazione locale per le implementazioni del sito FTP (File Transfer Protocol) e SCM (Source Control Management) possono rimanere abilitati durante la fase di sviluppo o POC. Quando si passa all'ambiente di produzione, è consigliabile disabilitare l'autenticazione locale a tali endpoint.

  • Non è necessario abilitare Microsoft Defender per App Service nella fase POC. Quando si passa all'ambiente di produzione, è necessario abilitare Defender per il servizio app per generare raccomandazioni sulla sicurezza. È consigliabile implementare queste raccomandazioni per aumentare il comportamento di sicurezza e rilevare più minacce per la distribuzione del servizio app.

  • Il servizio app include un endpoint SSL (Secure Sockets Layer) in un sottodominio di azurewebsites.net senza costi aggiuntivi. Le richieste HTTP vengono reindirizzate all'endpoint HTTPS per impostazione predefinita. Per le distribuzioni di produzione, un dominio personalizzato viene in genere utilizzato con Application Gateway o la gestione API davanti alla distribuzione del Servizio App.

  • Usare il meccanismo di autenticazione integrata per il servizio app. Easy Auth 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.

  • Uso delle identità gestite per i carichi di lavoro. Identità gestita elimina la necessità che gli sviluppatori gestiscano le credenziali di autenticazione. L'architettura di base esegue l'autenticazione per SQL Server usando una password in un stringa di connessione. È consigliabile usare managed identity per autenticarsi a SQL Server.

Per altre informazioni, vedere Proteggere un'app nel servizio app.

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Questa architettura ottimizza i costi grazie ai numerosi compromessi rispetto agli altri pilastri del framework Well-Architected. Questi compromessi sono specifici per allinearsi agli obiettivi di apprendimento e verifica di questa architettura. I risparmi sui costi rispetto a un'architettura più avanzata per la produzione, come ad esempio l'applicazione Web basata su una zona ridondante a elevata disponibilità, derivano principalmente dalle seguenti scelte:

  • Una singola istanza del servizio app, senza scalabilità automatica abilitata

  • Piano tariffario Standard per il servizio app

  • Nessun certificato TLS personalizzato o indirizzo IP statico

  • Nessun web application firewall (WAF)

  • Nessun account di archiviazione dedicato per la distribuzione dell'applicazione

  • Piano tariffario basic per il database SQL, senza criteri di conservazione dei backup

  • Nessun componente di Microsoft Defender per il cloud

  • Nessun controllo in uscita del traffico di rete tramite un firewall

  • Nessun endpoint privato

  • Log minimi e periodo di conservazione dei log nei log Monitoraggio di Azure

Per visualizzare il costo stimato di questa architettura, vedere la stima del calcolatore dei prezzi che usa i componenti di questa architettura. Il costo di questa architettura può in genere essere ulteriormente ridotto usando una sottoscrizione Azure Dev/Test, che sarebbe un tipo ideale di sottoscrizione per PoC come questo.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo 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 del 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. È possibile memorizzare i segreti nella configurazione di App Service durante la fase POC. Non si usano segreti reali e non è necessaria la governance dei segreti necessaria per i carichi di lavoro di produzione.

Prendere in considerazione i consigli e le considerazioni di configurazione seguenti:

  • Per iniziare, usare la configurazione del servizio app per archiviare i valori di configurazione e le stringhe di connessione nelle distribuzioni poC. Le impostazioni dell'app e le stringhe di connessione vengono crittografate e decrittografate immediatamente prima di essere inserite nell'app all'avvio.

  • Quando passi all'ambiente di produzione, memorizza i segreti in Key Vault. Il servizio Key Vault migliora la gestione dei segreti in due modi:

    • L'esternalizzazione dei segreti a Key Vault fornisce un'unica posizione centralizzata per la gestione sicura dei segreti.

    • Usando 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 mantenere l'uso della configurazione di Key Vault e del servizio app usando riferimenti Key Vault.

Contenitori

È possibile usare l'architettura di base per distribuire il codice supportato direttamente nelle istanze di Windows o Linux. In alternativa, il servizio app è anche una piattaforma di hosting di contenitori che è possibile usare per eseguire l'applicazione Web in contenitori. Il servizio app offre vari contenitori predefiniti. Le app personalizzate o multiple-container consentono di ottimizzare l'ambiente di runtime o supportare linguaggi di codice non supportati in modo nativo. Questo approccio richiede l'introduzione di un registro contenitori.

Piano di controllo

Durante la fase di PoC, acquisire familiarità con il piano di controllo dell'App Service, accessibile tramite il servizio Kudu. Questo servizio fornisce API di distribuzione comuni, ad esempio distribuzioni ZIP, ed espone log non elaborati e variabili di ambiente.

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

Diagnostica e monitoraggio

Durante la fase di Proof of Concept (POC), è importante comprendere quali log e metriche sono disponibili per l'acquisizione. Considerare le seguenti raccomandazioni e idee per il monitoraggio nella fase POC.

  • Abilitare la registrazione diagnostica per tutte le sorgenti di log degli elementi. La configurazione dell'uso di tutte le impostazioni di diagnostica consente di comprendere quali log e metriche vengono forniti di default e consente di identificare eventuali lacune da chiudere usando un framework di logging nel codice dell'applicazione. Quando si passa all'ambiente di produzione, eliminare le origini di log che non aggiungono valore e invece aggiungono rumore e costi alla destinazione di log del carico di lavoro.

  • Configurare la registrazione per l'uso di Analisi dei log di Azure. Log Analytics di Azure offre una piattaforma scalabile per centralizzare la raccolta di log, facile da interrogare.

  • Usare Application Insights o un altro strumento di gestione delle prestazioni delle applicazioni (APM) per generare dati di telemetria e log per monitorare le prestazioni dell'applicazione.

Distribuzione

I punti seguenti forniscono indicazioni su come distribuire l'applicazione del servizio app:

  • Seguire le indicazioni in CI/CD per Azure App Web con Azure Pipelines per automatizzare la distribuzione dell'applicazione. Inizia a costruire la tua logica di distribuzione nella fase POC. L'implementazione dell'integrazione continua e del recapito continuo (CI/CD) all'inizio del processo di sviluppo consente di eseguire rapidamente e in modo sicuro l'iterazione dell'applicazione durante lo spostamento verso la produzione.

  • Usare Azure Resource Manager modelli (modelli arm) per distribuire risorse Azure e le relative dipendenze. È importante avviare questo processo nella fase POC. Man mano che si passa all'ambiente di produzione, si vuole poter distribuire automaticamente l'infrastruttura.

  • Usare modelli ARM diversi e integrarli con Azure DevOps Services. 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 altre informazioni, vedere i principi di progettazione dell'eccellenza operativa.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli 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, questa sezione descrive alcune delle funzionalità critiche per l'efficienza delle prestazioni omesse in questa architettura, insieme ad altre raccomandazioni e considerazioni.

Un risultato del Proof of Concept dovrebbe essere una selezione di SKU che si stima sia adatta al carico di lavoro. Progettare il carico di lavoro 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.

  • La distribuzione del servizio app in questa architettura di base non ha implementato il ridimensionamento automatico. Il servizio non scala dinamicamente verso l'esterno o verso l'interno per rimanere efficientemente allineato alla domanda.

    • Il livello Standard supporta le impostazioni di scalabilità automatica per consentire di configurare la scalabilità automatica basata su regole. Come parte del processo di verifica, determinare impostazioni di scalabilità automatica efficienti personalizzate in base ai requisiti delle risorse del codice dell'applicazione e ai modelli di utilizzo previsti.

    • 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.

Passaggi successivi

Tutorial sulla distribuzione:

Documentazione sui prodotti:

Moduli di Microsoft Learn: