App Spring di Azure integrate con le zone di destinazione

Questa architettura di riferimento distribuisce l'architettura di base di Azure Spring Apps nelle zone di destinazione di Azure.

In questo scenario, l'organizzazione prevede che il carico di lavoro usi risorse federate gestite da team centrali (piattaforma) Esempi di gestione centralizzata includono la rete per la connettività locale, la gestione degli accessi alle identità e i criteri. Queste linee guida presuppongono che l'organizzazione abbia adottato zone di destinazione di Azure per applicare una governance coerente e risparmiare sui costi in più carichi di lavoro.

Le scelte di progettazione effettuate in questa architettura sono descritte nelle principali aree tecniche di progettazione. Per altre informazioni, vedere Zona di destinazione di Azure Spring Apps in Cloud Adoption Framework.

Architettura

Il diagramma seguente illustra l'architettura per questo approccio:

Tra gli usi tipici di questa architettura sono inclusi:

• Applicazioni private: applicazioni interne distribuite in ambienti cloud ibridi.
• Applicazioni pubbliche: applicazioni con connessione esterna.

Questi casi d'uso sono simili ad eccezione della configurazione delle regole di sicurezza e del traffico di rete.

Componenti

Le sezioni seguenti descrivono i componenti di questa architettura. I componenti sono divisi in base alle responsabilità di proprietà per identificare cosa condividere con i team della piattaforma dell'organizzazione. Per la documentazione del prodotto sui servizi di Azure, vedere la sezione Risorse correlate .

Risorse di proprietà del team dell'applicazione

Il team è responsabile della creazione e della gestione delle risorse seguenti.

• Azure Spring Apps Standard ospita le applicazioni Java Spring Boot in Azure.

• app Azure lication Gateway Standard_v2 è il proxy inverso che instrada il traffico Web in ingresso ad Azure Spring Apps. Questo SKU ha integrato Web application firewall di Azure che controlla il traffico per individuare le vulnerabilità OWASP (Open Web Application Security Project).

• Azure Macchine virtuali funge da jump box per le operazioni di gestione.

• Database di Azure per MySQL archivia i dati dell'applicazione.

• Azure Key Vault archivia segreti e configurazione, ad esempio un stringa di connessione al database.

• Log Analytics è una funzionalità di Monitoraggio di Azure nota anche come log di Monitoraggio di Azure. Log Analytics è il sink di monitoraggio che archivia i log e le metriche dall'applicazione e dai servizi di Azure.

• app Azure lication Insights viene usato come strumento APM (Application Performance Management) per raccogliere tutti i dati di monitoraggio delle applicazioni e archiviarli direttamente all'interno di Log Analytics.

Risorse di proprietà del team della piattaforma

Questa architettura presuppone che le risorse seguenti esistano già. I team centrali dell'organizzazione possiedono e mantengono queste risorse. L'applicazione dipende da questi servizi per ridurre il sovraccarico operativo e ottimizzare i costi.

• Firewall di Azure controlla e limita il traffico in uscita.

• Azure Bastion offre accesso sicuro al jump box di gestione.

• Azure ExpressRoute offre connettività privata dall'infrastruttura locale all'infrastruttura di Azure.

• DNS di Azure offre la risoluzione dei nomi cross-premise.

• Azure Gateway VPN connette l'applicazione con i team remoti nella rete locale.

Considerazioni sull'applicazione

L'implementazione di riferimento include un'applicazione di esempio che illustra un'applicazione di microservizi tipica ospitata in un'istanza di Azure Spring Apps. Le sezioni seguenti forniscono informazioni dettagliate sull'applicazione ospitata. Per altre informazioni, vedere PetClinic store sample (Esempio di archivio PetClinic).

Individuazione dei servizi

In un modello di microservizi, la funzionalità del Registro di sistema del servizio deve essere supportata per il routing delle richieste utente e della comunicazione da servizio a servizio.

I servizi devono essere in grado di comunicare con altri servizi. Quando vengono generate nuove istanze, vengono aggiunte al Registro di sistema in modo che possano essere individuate in modo dinamico. In questa architettura, il Registro del servizio Spring Cloud gestito è abilitato per Azure Spring Apps. Questo servizio gestisce un registro di istanze di app attive, consente il bilanciamento del carico sul lato client e separa i provider di servizi dai client senza basarsi su un servizio DNS (Domain Name Service).

L'istanza di Azure Spring Apps implementa il modello di routing del gateway, che fornisce un singolo punto di ingresso per il traffico esterno. Il gateway instrada le richieste in ingresso alle istanze del servizio attive presenti nel Registro di sistema. In questa progettazione, il modello viene implementato con un'implementazione open source di Spring Cloud Gateway. Offre un set di funzionalità che include autenticazione e autorizzazione, funzionalità di resilienza e limitazione della frequenza.

Server di configurazione

Per i microservizi, i dati di configurazione devono essere separati dal codice. In questa architettura, il server di configurazione di Azure Spring Apps consente la gestione delle risorse tramite un repository collegabile che supporta l'archiviazione locale e i repository Git.

Ridondanza

È possibile usare le zone di disponibilità durante la creazione di un'istanza di Azure Spring Apps.

Con questa funzionalità, Azure Spring Apps distribuisce automaticamente le risorse fondamentali nelle sezioni logiche dell'infrastruttura di Azure sottostante. Questa distribuzione offre un livello di disponibilità superiore e protegge da errori hardware o eventi di manutenzione pianificata.

La ridondanza della zona garantisce che i nodi della macchina virtuale sottostante vengano distribuiti uniformemente in tutte le zone di disponibilità. Tuttavia, la ridondanza della zona non garantisce nemmeno la distribuzione delle istanze dell'app. Se un'istanza dell'app ha esito negativo perché la zona individuata diventa inattiva, Azure Spring Apps crea una nuova istanza dell'app per questa app in un nodo in un'altra zona di disponibilità.

Se si abilita la propria risorsa in Azure Spring Apps, ad esempio l'archiviazione permanente, abilitare la ridondanza della zona per la risorsa. Per altre informazioni, vedere Come abilitare l'archiviazione permanente in Azure Spring Apps.

Le zone di disponibilità non sono supportate in tutte le aree. Per informazioni sulle aree che supportano le zone di disponibilità, vedere Aree di Azure che supportano zone di disponibilità.

Scalabilità

Azure Spring Apps offre funzionalità di scalabilità automatica predefinite che consentono alle app di ridimensionarsi in base alle soglie delle metriche o durante un intervallo di tempo specifico. La scalabilità automatica è consigliata quando le app devono aumentare o aumentare le prestazioni in risposta alla modifica della domanda.

Azure Spring Apps supporta anche il ridimensionamento manuale delle applicazioni modificando CPU, memoria/GB per istanza e numero di istanze dell'app. Questo tipo di ridimensionamento è adatto per un'attività di ridimensionamento monouso che può essere utile per determinate app. Modificare i valori per soddisfare le esigenze di ridimensionamento dell'applicazione e assicurarsi che le impostazioni siano entro i limiti massimi per ogni attributo.

Considerazioni sulla rete

In questa progettazione, il carico di lavoro dipende dalle risorse di proprietà del team della piattaforma per l'accesso alle risorse locali, il controllo del traffico in uscita e così via. Per altre informazioni, vedere Zona di destinazione di Azure Spring Apps: Topologia di rete e connettività.

Topologia di rete

Il team della piattaforma determina la topologia di rete. In questa architettura si presuppone una topologia hub-spoke.

Rete virtuale hub

La sottoscrizione di connettività contiene una rete virtuale hub condivisa dall'intera organizzazione. La rete contiene le risorse di rete di proprietà e gestite dal team della piattaforma. Le risorse del team della piattaforma seguenti rientrano nell'ambito di questa architettura:

• Firewall di Azure controlla il traffico in uscita verso Internet.
• Azure Bastion protegge l'accesso al jump box di gestione.

Rete virtuale spoke

La zona di destinazione dell'applicazione ha almeno una rete virtuale con provisioning preliminare con peering alla rete hub. Le risorse in questa rete, ad esempio il servizio di bilanciamento del carico che instrada e protegge le connessioni HTTP/s in ingresso ad Azure Spring Apps da Internet.

La rete virtuale e i peering con provisioning preliminare devono essere in grado di supportare la crescita prevista del carico di lavoro. Stimare le dimensioni della rete virtuale e valutare regolarmente i requisiti con il team della piattaforma. Per informazioni, vedere Requisiti di rete virtuale.

Inserimento della rete virtuale e subnet

Azure Spring Apps viene distribuito nella rete tramite il processo di inserimento della rete virtuale . Questo processo isola l'applicazione da Internet, dai sistemi in reti private, da altri servizi di Azure e anche dal runtime del servizio. Il traffico in ingresso e in uscita dall'applicazione è consentito o negato in base alle regole di rete.

L'isolamento viene ottenuto tramite subnet. L'utente è responsabile dell'allocazione di subnet nella rete virtuale spoke. Azure Spring Apps richiede due subnet dedicate per il runtime del servizio e per le applicazioni Java Spring Boot.

Le subnet devono essere dedicate a una singola istanza di Azure Spring Apps. Più istanze non possono condividere le stesse subnet.

La dimensione minima di ogni subnet è /28. Le dimensioni effettive dipendono dal numero di istanze dell'applicazione supportate da Azure Spring Apps. Per altre informazioni, vedere Uso di intervalli di subnet più piccoli.

Controlli di rete

app Azure lication Gateway con Web Application Firewall limita il traffico in ingresso alla rete virtuale spoke da Internet. Le regole web application firewall consentono o negano le connessioni HTTP/s.

Il traffico all'interno della rete viene controllato usando i gruppi di sicurezza di rete (NSG) nelle subnet. I gruppi di sicurezza di rete filtrano il traffico in base agli indirizzi IP e alle porte configurati. In questa progettazione, i gruppi di sicurezza di rete vengono posizionati in tutte le subnet. La subnet di Azure Bastion consente il traffico HTTPS da Internet, servizi gateway, servizi di bilanciamento del carico e rete virtuale. Solo la comunicazione RDP e SSH con le reti virtuali è consentita dalla subnet.

I collegamenti privati vengono usati per controllare la connettività tra Azure Spring Apps e altri servizi di Azure, ad esempio l'accesso all'insieme di credenziali delle chiavi e al database. Gli endpoint privati vengono inseriti in una subnet separata.

I record DNS dell'host dell'applicazione devono essere archiviati in Azure DNS privato per garantire la disponibilità continua durante un errore geografico.

Anche se la sottoscrizione di connettività include zone DNS private, creare zone di azure DNS privato personalizzate per supportare i servizi a cui accedono gli endpoint privati.

Il traffico in uscita dalla rete virtuale deve essere limitato per impedire attacchi di esfiltrazione dei dati. Questo traffico viene instradato attraverso la Firewall di Azure centralizzata (hop successivo) che consente o nega il flusso usando un nome di dominio completo (FQDN).

Gestione delle identità e dell'accesso

L'implementazione dell'identità del carico di lavoro deve essere allineata alle procedure consigliate dell'organizzazione per garantire che l'applicazione non viola i limiti di sicurezza o governance dell'organizzazione. Per altre informazioni, vedere Zona di destinazione di Azure Spring Apps: Gestione delle identità e degli accessi.

Microsoft Entra ID è consigliato per autenticare utenti e servizi che interagiscono con l'istanza di Azure Spring Apps.

L'approccio consigliato consiste nell'abilitare le identità gestite di Microsoft Entra per le risorse di Azure per l'applicazione per consentire all'app di eseguire l'autenticazione automatica ad altri servizi. In questa architettura, le identità gestite assegnate dal sistema vengono usate per semplificare la gestione.

Per l'autorizzazione, usare il Controllo di accesso controllo degli accessi in base al ruolo di Azure applicando il principio dei privilegi minimi quando si concedono le autorizzazioni.

Considerazioni sul monitoraggio

La piattaforma della zona di destinazione di Azure fornisce risorse di osservabilità condivise come parte delle sottoscrizioni di gestione. Tuttavia, è consigliabile effettuare il provisioning delle proprie risorse di monitoraggio per semplificare la gestione complessiva del carico di lavoro. Per altre informazioni, vedere Zona di destinazione di Azure Spring Apps: Monitorare le operazioni.

Questa architettura crea le risorse seguenti:

• app Azure lication Insights è la soluzione Application Monitor prestazioni ing (APM) ed è completamente integrata nel servizio tramite un agente Java. Questo agente offre visibilità su tutte le applicazioni e le dipendenze distribuite senza richiedere codice aggiuntivo.
• L'area di lavoro Azure Log Analytics è il sink unificato per tutti i log e le metriche raccolti dai servizi di Azure e dall'applicazione.

Configurare l'istanza di Azure Spring Apps per inviare i log di diagnostica dall'applicazione all'area di lavoro Log Analytics di cui è stato effettuato il provisioning. Per altre informazioni, vedere Monitorare le applicazioni end-to-end.

Raccogliere log e metriche per altri servizi di Azure. La diagnostica di avvio è abilitata per il jump box, in modo da poter acquisire gli eventi come avvio della macchina virtuale.

Configurare le impostazioni di diagnostica per inviare i log delle risorse per tutte le altre risorse di Azure a un'area di lavoro Log Analytics. I log delle risorse non vengono raccolti finché non vengono indirizzati a una destinazione. Ogni risorsa di Azure richiede una propria impostazione di diagnostica.

Correlazione dei dati da più aree di lavoro

I log e le metriche generati dal carico di lavoro e i relativi componenti dell'infrastruttura vengono salvati nell'area di lavoro Log Analytics del carico di lavoro. Tuttavia, i log e le metriche generati da servizi centralizzati, ad esempio Active Directory e Firewall di Azure, vengono salvati in un'area di lavoro Log Analytics centrale gestita dai team della piattaforma. La correlazione dei dati da sink diversi può causare complessità.

Si consideri uno scenario di un flusso utente in cui il carico di lavoro presenta dipendenze dai servizi centralizzati. Una parte dei dati potrebbe essere raccolta a livello di carico di lavoro ed esportata nell'area di lavoro Log Analytics centrale in cui è correlata ai log della piattaforma.

Tuttavia, altre voci potrebbero esistere solo nell'area di lavoro del carico di lavoro a causa di problemi come volume di dati, interoperabilità del formato o vincoli di sicurezza. Le voci di log non correlate presenti in due o più aree di lavoro per un singolo flusso utente possono rendere più difficile risolvere determinati problemi. Queste complessità aggiunte richiedono ai team di collaborare per risolvere gli eventi imprevisti dell'applicazione.

Per facilitare questo tipo di collaborazione, acquisire familiarità con le procedure configurate dall'organizzazione. Quando si verifica un evento imprevisto di sicurezza, agli amministratori a livello di carico di lavoro potrebbe essere richiesto di esaminare i log dei sistemi per individuare i segni di attività dannose o fornire copie dei log ai gestori eventi imprevisti per ulteriori analisi. Quando gli amministratori del carico di lavoro risodono i problemi dell'applicazione, potrebbero richiedere assistenza agli amministratori della piattaforma per correlare le voci di log dalle reti aziendali, dalla sicurezza o da altri servizi della piattaforma.

Probe di integrità

app Azure lication Gateway usa probe di integrità per garantire che il traffico in ingresso venga instradato alle istanze back-end reattive. Sono consigliati i probe di idoneità, attività e avvio di Azure Spring Apps. In caso di errore, questi probe possono essere utili per la terminazione normale. Per altre informazioni, vedere Come configurare i probe di integrità.

Considerazioni relative alla sicurezza

I team centralizzati forniscono controlli di rete e identità come parte della piattaforma. Tuttavia, il carico di lavoro deve avere inviti di sicurezza per ridurre la superficie di attacco. Per altre informazioni, vedere Zona di destinazione di Azure Spring Apps: Sicurezza.

Dati inattivi

I dati inattivi devono essere crittografati. L'applicazione stessa è senza stato. Tutti i dati vengono salvati in modo permanente in un database esterno, in cui questa architettura usa Database di Azure per MySQL. Questo servizio crittografa i dati, inclusi i backup e i file temporanei creati durante l'esecuzione di query.

Dati in movimento

I dati in transito devono essere crittografati. Il traffico tra il browser dell'utente e app Azure gateway deve essere crittografato per garantire che i dati rimangano invariati durante il transito. In questa architettura, app Azure lication Gateway accetta solo il traffico HTTPS e negozia l'handshake TLS. Questo controllo viene applicato tramite le regole del gruppo di sicurezza di rete nella subnet gateway applicazione. Il certificato TLS viene caricato direttamente durante la distribuzione.

Il traffico da gateway applicazione all'istanza di Azure Spring Apps viene ricrittografato per garantire che solo il traffico sicuro raggiunga l'applicazione. Il runtime del servizio Azure Spring Apps riceve il traffico e funge da punto di terminazione TLS. Da questo punto, la comunicazione tra servizi all'interno dell'applicazione non è crittografata. Tuttavia, la comunicazione con altri servizi PaaS di Azure e il runtime del servizio avviene tramite TLS.

È possibile scegliere di implementare la comunicazione TLS end-to-end tramite Azure Spring Apps. Considerare i compromessi. Potrebbe esserci un effetto negativo sulla latenza e sulle operazioni.

I dati in transito devono essere controllati per individuare le vulnerabilità. Web Application Firewall è integrato con gateway applicazione ed esamina ulteriormente il traffico che blocca le vulnerabilità OWASP. È possibile configurare Web Application Firewall per rilevare, monitorare e registrare gli avvisi sulle minacce. In alternativa, è possibile configurare il servizio per bloccare intrusioni e attacchi rilevati dalle regole.

Protezione DDoS

Il servizio Distributed Denial of Service (DDoS) può arrestare un sistema sovraccaricandolo con le richieste. La protezione DDoS di base è abilitata a livello di infrastruttura per tutti i servizi di Azure per difendersi da tali attacchi. Prendere in considerazione l'aggiornamento al servizio Protezione DDoS di Azure per sfruttare i vantaggi di funzionalità come il monitoraggio, gli avvisi, la possibilità di impostare soglie per l'applicazione. Per altre informazioni, vedere Domande frequenti sul servizio Protezione DDoS di Azure.

Gestione dei segreti

L'approccio di sicurezza Zero Trust di Microsoft richiede segreti, certificati e credenziali da archiviare in un insieme di credenziali sicuro. Il servizio consigliato è Azure Key Vault.

Esistono modi alternativi per archiviare i segreti a seconda del servizio e della finalità di Azure. Questa architettura implementa l'approccio seguente:

• I certificati vengono caricati durante la distribuzione.
• La connessione a MySQL viene implementata tramite Service Connector.

Strategie di ottimizzazione dei costi

A causa della natura della progettazione del sistema distribuito, lo sprawl dell'infrastruttura è una realtà. Questa realtà comporta costi imprevisti e non controllabili. Azure Spring Apps viene creato usando componenti che consentono di soddisfare la domanda e ottimizzare i costi. La base di questa architettura è la servizio Azure Kubernetes (servizio Azure Kubernetes). Il servizio è progettato per ridurre la complessità e il sovraccarico operativo della gestione di Kubernetes e include efficienza nel costo operativo del cluster.

È possibile distribuire applicazioni e tipi di applicazioni diversi in una singola istanza di Azure Spring Apps. Il servizio supporta la scalabilità automatica delle applicazioni attivate da metriche o pianificazioni che possono migliorare l'utilizzo e l'efficienza dei costi.

È anche possibile usare Application Insights e Monitoraggio di Azure per ridurre i costi operativi. Con la visibilità fornita dalla soluzione di registrazione completa, è possibile implementare l'automazione per ridimensionare i componenti del sistema in tempo reale. È anche possibile analizzare i dati di log per rivelare inefficienze nel codice dell'applicazione che è possibile affrontare per migliorare il costo complessivo e le prestazioni del sistema.

Distribuzione dello scenario

Una distribuzione per questa architettura di riferimento è disponibile nel repository GitHub della zona di destinazione di Azure Spring Apps. La distribuzione usa i modelli Terraform.

Gli artefatti in questo repository forniscono una base che è possibile personalizzare per l'ambiente. L'implementazione crea una rete hub con risorse condivise, ad esempio Firewall di Azure a scopo illustrativo. Questo raggruppamento può essere mappato a sottoscrizioni separate della zona di destinazione per mantenere separate le funzioni del carico di lavoro e della piattaforma.

Per distribuire l'architettura, seguire le istruzioni dettagliate.

Supporto di VMware con il livello Enterprise

Se si vuole il supporto VMware Tanzu® gestito per la distribuzione in tempo reale, è consigliabile eseguire l'aggiornamento al livello Enterprise di Azure Spring Apps. Il Registro dei servizi VMware Tanzu® è integrato per Azure Spring Apps, che consente l'individuazione e la registrazione dei servizi.

Per il routing del gateway, è possibile passare a VMware Spring Cloud Gateway. Offre un set di funzionalità che include autenticazione e autorizzazione, funzionalità di resilienza e limitazione della frequenza.

Nel livello Enterprise, il servizio di configurazione delle applicazioni per Tanzu® consente la gestione delle risorse ConfigMap native di Kubernetes popolate da proprietà definite in uno o più repository Git.

In questo livello sono supportati altri servizi VMware. Per altre informazioni, vedere Livello Enterprise in Azure Marketplace.

L'implementazione di riferimento supporta lo SKU Enterprise di Azure Spring Apps come opzione di distribuzione. In questa opzione sono state apportate alcune modifiche all'architettura. Usa un'istanza di Database di Azure per PostgreSQL server flessibile distribuito con l'integrazione di Azure Rete virtuale e cache di Azure per Redis con endpoint privato. L'applicazione di esempio è l'app Fitness Store.

Passaggi successivi

• Esaminare le aree di progettazione delle linee guida per la zona di destinazione di Azure Spring Apps.

Risorse correlate

Per la documentazione del prodotto sui servizi di Azure usati in questa architettura, vedere gli articoli seguenti:

• Azure Spring Apps Enterprise
• gateway app Azure lication v2
• Database di Azure per MySQL
• Azure Key Vault
• Rete virtuale di Azure
• Tabelle di route

Per altri scenari di implementazione, vedere gli articoli seguenti:

• Distribuire App Azure Spring in più aree
• Esporre Azure Spring Apps tramite un proxy inverso