Distribuire un'applicazione line-of-business con app Azure Ambiente del servizio v3

Servizio app di Azure
DNS di Azure
Monitoraggio di Azure
Azure Log Analytics
Insieme di credenziali chiave di Azure

Per i clienti in segmenti strettamente regolamentati e limitati dalla conformità, è importante avere un ambiente isolato e dedicato, soprattutto per le applicazioni line-of-business. Anche se la sicurezza è anteriore e centrale, queste applicazioni critiche richiedono anche la possibilità di ridimensionare ed eseguire in scenari di utilizzo elevato della memoria o richieste elevate al secondo. Questa soluzione fornisce un esempio di come ospitare applicazioni line-of-business. È possibile usare ambiente del servizio app per assicurarsi che sia la sicurezza che le prestazioni possano essere risolte contemporaneamente. Quando si distribuisce questa soluzione, si avrà la flessibilità necessaria per usare le risorse esistenti nella zona di destinazione di Azure, che rappresenta le risorse nella rete virtuale dell'hub. In alternativa, è possibile distribuire questa soluzione come carico di lavoro autonomo.

Nota

Questo articolo fornisce un'architettura distribuibile allineata alle linee guida di Cloud Adoption Framework per servizio app nelle zone di destinazione di Azure.

Architettura

Diagramma che mostra l'architettura della distribuzione ambiente del servizio app v3.

L'intera immagine è nell'ambito di una sottoscrizione e di una zona DNS privata. Viene indicato da un'icona della sottoscrizione e da un'icona di zona DNS privato di Azure nell'angolo superiore sinistro. Sotto queste icone, due blocchi sono affiancati. Rappresentano due reti virtuali, con peering reti virtuali tra di esse. Il blocco a sinistra rappresenta la rete virtuale dell'hub e il blocco a destra rappresenta la rete virtuale spoke. All'interno della casella sinistra ci sono tre scatole più piccole. Ogni casella indica una subnet diversa e il gruppo di sicurezza di rete associato. A partire dall'alto a sinistra è un'istanza di Azure Bastion all'interno della subnet azure Bastion e in alto a destra è la macchina virtuale jumpbox, che risiede nella subnet jumpbox. In basso a destra è la terza e l'ultima casella nella rete virtuale dell'hub, che contiene il server agente CI/CD che risiede nella subnet CI/CD. La casella a destra, che rappresenta la rete virtuale spoke, contiene solo una casella più piccola, la subnet ambiente del servizio app con l'istanza ambiente del servizio app v3 al suo interno. Una casella più piccola rappresenta il ambiente del servizio app. L'icona servizio app si trova all'interno di tale casella. Nel centro inferiore dell'immagine sono risorse condivise distribuite anche come parte del processo. A partire da sinistra a destra, le risorse condivise includono Azure Key Vault, area di lavoro Analisi dei log di Azure e Azure Application Insights.

Scaricare un file di Visio di questa architettura.

Workflow

Esistono tre flussi con callout in questa architettura: Operazioni (arancione), Distribuzione (verde) e Utente (viola).

Operazioni

  1. Gli operatori o gli amministratori desiderano eseguire attività di amministrazione nel server di integrazione continua/distribuzione continua (CI/CD) o nell'endpoint Kudu per l'ambiente del servizio app. Prima di tutto, dovranno connettersi all'host Azure Bastion.
  2. Usando l'host Azure Bastion, l'operatore o l'amministratore possono quindi usare Remote Desk Protocol (RDP) per accedere al server jumpbox.
  3. Dal server jumpbox, l'operatore o l'amministratore può eseguire RDP nel server CI/CD ed eseguire le attività necessarie, ad esempio gli aggiornamenti dell'agente, gli aggiornamenti del sistema operativo e così via. L'operatore o l'amministratore può anche connettersi dal server jumpbox all'endpoint Kudu dell'istanza di ambiente del servizio app, per eseguire attività amministrative o per eseguire la risoluzione dei problemi avanzata.

Distribuzione

  1. La distribuzione della soluzione viene eseguita tramite il server agente CI/CD. L'agente DevOps in questo server si connetterà ad Azure Pipelines quando viene eseguita una nuova distribuzione.
  2. Gli artefatti verranno quindi distribuiti nel servizio app connettendosi al ambiente del servizio app tramite il peering reti virtuali.

Utente

  1. Gli utenti possono connettersi al servizio app distribuito tramite la rete aziendale. Se necessario, possono usare Azure ExpressRoute o una VPN e/o su qualsiasi peering di rete virtuale di Azure applicabile.

Componenti

La soluzione usa i servizi di Azure seguenti:

  • ambiente del servizio app Azure v3 (ASEv3) è una funzionalità del servizio app Azure ed è un servizio a tenant singolo per i clienti che richiedono scalabilità elevata, isolamento della rete, sicurezza e/o utilizzo elevato della memoria. Le app sono ospitate in piani di servizio app creati in ambiente del servizio app v3, con opzioni per l'uso di livelli diversi all'interno di un piano di servizio Isolato V2. Rispetto a una versione precedente di ambiente del servizio app, sono stati apportati numerosi miglioramenti, tra cui, a titolo esemplificativo, dipendenza di rete, tempo di scala e rimozione della tariffa stamp. Questa soluzione usa un ambiente del servizio app v3 configurato per l'accesso interno.

  • DNS privato di Azure consente di gestire e risolvere i nomi di dominio in una rete virtuale senza dover aggiungere una soluzione DNS personalizzata. Una zona DNS privato di Azure può essere collegata a una o più reti virtuali tramite collegamenti di rete virtuale. A causa della natura interna della ambiente del servizio app v3 usata da questa architettura di riferimento, è necessaria una zona DNS privata per risolvere i nomi di dominio delle applicazioni ospitate nel ambiente del servizio app.

  • Azure Application Insights è una funzionalità di Monitoraggio di Azure che consente agli sviluppatori di rilevare anomalie, diagnosticare i problemi e comprendere i modelli di utilizzo. Application Insights offre la gestione e il monitoraggio delle prestazioni applicative per le app Web live. Sono supportate diverse piattaforme, tra cui .NET, Node.js, Java e Python. Supporta le app ospitate in Azure, in locale, in un ambiente ibrido o in altri cloud pubblici. Application Insights è incluso nell'ambito di questa architettura di riferimento per monitorare i comportamenti dell'applicazione distribuita.

  • Azure Log Analytics è una funzionalità di Monitoraggio di Azure che consente di modificare ed eseguire query di log con dati nei log di Monitoraggio di Azure, facoltativamente dall'interno del portale di Azure. Gli sviluppatori possono eseguire query semplici per un set di record o usare Analisi dei log per eseguire un'analisi avanzata. Possono quindi visualizzare i risultati. Analisi dei log è configurato come parte di questa architettura di riferimento per aggregare tutti i log di monitoraggio per l'analisi e la creazione di report.

  • Macchine virtuali di Azure è una risorsa di calcolo scalabile su richiesta che può essere usata per ospitare diversi carichi di lavoro. In questa architettura di riferimento, le macchine virtuali vengono usate per fornire un server jumpbox di gestione e per fornire un host per l'agente DevOps o gitHub runner.

  • Azure Key Vault è un servizio cloud che archivia e accede in modo sicuro ai segreti, che vanno dalle chiavi API e password ai certificati e alle chiavi crittografiche. Un insieme di credenziali delle chiavi di Azure viene distribuito come parte dell'infrastruttura di questa architettura, per facilitare la gestione dei segreti per le distribuzioni di codice future.

  • Azure Bastion è un servizio distribuita come piattaforma di cui viene effettuato il provisioning all'interno della rete virtuale dello sviluppatore. Offre connettività RDP/SSH sicura e ininterrotta alle macchine virtuali dello sviluppatore dal portale di Azure, tramite TLS. Con Azure Bastion, le macchine virtuali non richiedono più un indirizzo IP pubblico per connettersi tramite RDP/SSH. Questa architettura di riferimento usa Azure Bastion per accedere all'agente DevOps o al server di esecuzione GitHub o al server jumpbox di gestione.

Alternative

È consigliabile aggiungere un Gateway applicazione di Azure prima dell'istanza di servizio app, per fornire funzionalità web application firewall (WAF) per proteggere le applicazioni Web da exploit e vulnerabilità comuni.

È possibile usare uno strumento di esecuzione GitHub self-hosted al posto dell'agente self-hosted di Azure DevOps.

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 Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

  • Considerare i requisiti per la ridondanza della zona in questa implementazione di riferimento, nonché le funzionalità di ridondanza della zona di qualsiasi altro servizio di Azure nella soluzione. Ambiente del servizio app v3 supporta la ridondanza della zona distribuendo le istanze in tutte e tre le zone nell'area di destinazione. Questa configurazione può essere impostata solo al momento della creazione del ambiente del servizio app e potrebbe non essere disponibile in tutte le aree. Per maggiori informazioni, consultare la sezione Supporto zona di disponibilità per l'ambiente del servizio app. Questa implementazione di riferimento implementa la ridondanza della zona, ma è possibile modificarla clonando questo repository e impostando la zoneRedundant proprietà su false.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

  • Usare l'uso appropriato delle restrizioni di accesso, in modo che il servizio app sia raggiungibile solo da posizioni valide. Ad esempio, se il servizio app ospita le API e viene anteriore da APIM, è possibile configurare una restrizione di accesso in modo che il servizio app sia accessibile solo da APIM.
  • Poiché questa implementazione di riferimento distribuisce un ambiente del servizio app in una rete virtuale (definita ambiente del servizio app interna), tutte le applicazioni distribuite nel ambiente del servizio app sono intrinsecamente isolate dalla rete, nell'ambito della rete virtuale.
  • Archiviare i segreti dell'applicazione (credenziali del database, token API e chiavi private) in Azure Key Vault. Configurare l'app servizio app per accedervi in modo sicuro con un'identità gestita. Determinare quando usare Azure Key Vault e Configurazione app di Azure.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

  • Anche se non è prevista alcuna tariffa stamp per un'istanza di ambiente del servizio app v3, è previsto un addebito quando non sono configurati piani di servizio app all'interno dell'istanza di ambiente del servizio app v3. Questo addebito viene addebitato alla stessa tariffa di un'istanza di Windows I1v2 per l'area in cui viene distribuita l'istanza di ambiente del servizio app v3.
  • Se configurata per essere ridondante della zona, il modello di ricarica viene modificato in modo da tenere conto dell'infrastruttura sottostante distribuita in questa configurazione. Potrebbe essere responsabile di istanze aggiuntive, in base ai prezzi di ASEv3.
  • Per ambiente del servizio app piani di servizio app v3 (noti come piani di servizio app Isolated V2), usare prenotazioni di Azure e piano di risparmio di Azure per il calcolo con un contratto di un anno o tre anni e ottenere risparmi significativi sui prezzi con pagamento in base al consumo. Per maggiori informazioni, consultare la sezione In che modo gli sconti per le prenotazioni si applicano alle istanze Isolated v2.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

  • Usare Application Insights o un'altra soluzione di gestione delle prestazioni delle applicazioni per monitorare e apprendere il comportamento dell'applicazione in ambienti diversi.
    • Esistono due modi per abilitare Application Insights. Per ambienti diversi, raccogliere dati di telemetria in istanze di Application Insights diverse.
    • Se l'applicazione include più componenti separati in servizi diversi, è possibile esaminarne il comportamento insieme. Raccogliere i dati di telemetria nella stessa istanza di Application Insights, ma etichettarli con nomi di ruolo cloud diversi.
    • Esportare i dati di Application Insights in un'area di lavoro di Analisi dei log di Azure. È consigliabile usare una singola area di lavoro per l'organizzazione.
    • Includere dashboard operative nella progettazione di applicazioni e funzionalità per garantire che la soluzione possa essere supportata nell'ambiente di produzione.
    • Implementare i controlli di integrità per gli endpoint e quindi usarli per probe di integrità, controlli delle dipendenze e test di disponibilità.
  • Valutare la possibilità di usare prefissi e suffissi con convenzioni ben definite per identificare in modo univoco ogni risorsa distribuita. Queste convenzioni di denominazione evitano conflitti nella distribuzione di soluzioni una accanto all'altra e migliorano la velocità effettiva e l'agilità complessiva del team.
  • A seconda della configurazione di rete, servizio app potrebbe non essere raggiungibile da Internet pubblico e l'uso di agenti ospitati pubblici non funzionerà per le distribuzioni. Usare agenti self-hosted in questo scenario.

Distribuire lo scenario

Per iniziare e comprendere meglio le specifiche di questa implementazione, vedere le risorse di implementazione di riferimento, nella Guida dell'utente per la distribuzione dell'implementazione di riferimento.

  • È consigliabile clonare questo repository e modificare le risorse di implementazione di riferimento in base ai requisiti e alle linee guida specifiche dell'area di destinazione dell'organizzazione.
  • Prima di eseguire la distribuzione, assicurarsi che l'entità servizio usata per distribuire la soluzione disponga delle autorizzazioni necessarie per creare i tipi di risorse elencati in precedenza.
  • Prendere in considerazione il servizio CI/CD che verrà usato per distribuire l'implementazione di riferimento. Poiché questa implementazione di riferimento è un ambiente del servizio app interno, è necessario un agente self-hosted per eseguire le pipeline di distribuzione. È possibile scegliere di usare un agente DevOps o uno strumento di esecuzione di GitHub. Fare riferimento alla guida dell'utente sui valori di configurazione specifici necessari.
  • Si considerino le aree in cui si intende distribuire questa implementazione di riferimento. Per assicurarsi che le aree selezionate siano abilitate per la distribuzione, vedere l'elenco aree ASEv3.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Maggiori informazioni su questi servizi chiave: