Questo scenario di esempio mostra un esempio di un carico di lavoro esistente originariamente progettato per l'esecuzione in Kubernetes invece in App Contenitore di Azure. App Contenitore di Azure è ideale per i carichi di lavoro brownfield in cui i team cercano di semplificare l'orchestrazione complessa dell'infrastruttura e dei contenitori. Il carico di lavoro di esempio esegue un'applicazione di microservizi in contenitori.
L'esempio accetta il carico di lavoro usato nell'architettura dei microservizi in servizio Azure Kubernetes e lo ospita nuovamente in App Contenitore di Azure come piattaforma applicativa.
Suggerimento
L'architettura è supportata da un'implementazione di esempio che illustra alcune scelte di progettazione descritte in questo articolo.
Architettura
Scaricare un file di Visio di questa architettura.
In questo scenario, le immagini del contenitore vengono generate da Registro Azure Container e distribuite in un ambiente app contenitore.
I servizi che condividono lo stesso ambiente traggono vantaggio da:
- Ingresso interno e individuazione dei servizi
- Una singola area di lavoro Log Analytics per la registrazione di runtime
- Gestione sicura di segreti e certificati
L'app contenitore del servizio flusso di lavoro è in esecuzione in modalità revisione singola. Un'app contenitore in esecuzione in modalità di revisione singola avrà una singola revisione supportata da repliche zero-many. Una replica è costituita dal contenitore dell'applicazione ed eventuali contenitori sidecar necessari. Questo esempio non usa contenitori sidecar, pertanto ogni replica dell'app contenitore rappresenta un singolo contenitore. Poiché questo esempio non usa il ridimensionamento, per ogni app contenitore sarà in esecuzione una sola replica.
Il flusso di lavoro usa un approccio ibrido per la gestione dei segreti. Le identità gestite vengono usate nei servizi in cui tale implementazione non richiede modifiche al codice. I servizi di pianificazione e recapito drone usano identità gestite assegnate dall'utente per eseguire l'autenticazione con Azure Key Vault per accedere ai segreti archiviati in questa posizione. I servizi rimanenti archiviano i segreti tramite il servizio App contenitore a livello di applicazione.
Questo diagramma illustra l'architettura di runtime per la soluzione.
Scaricare un file di Visio di questa architettura.
Flusso di dati
- Servizio di inserimento: riceve le richieste client, li memorizza nel buffer e li invia tramite bus di servizio di Azure al servizio flusso di lavoro.
- Servizio flusso di lavoro: utilizza i messaggi di bus di servizio di Azure e li invia ai servizi sottostanti.
- Servizio pacchetti: gestisce i pacchetti.
- Servizio di pianificazione droni: pianifica droni e monitora droni in volo.
- Servizio di recapito: gestisce le consegne pianificate o in transito.
Componenti
Il servizio di consegna tramite drone usa una serie di servizi di Azure insieme tra loro.
App contenitore di Azure
App Azure Container è il componente principale.
Molte delle complessità dell'architettura precedente del servizio Azure Kubernetes vengono sostituite da queste funzionalità:
- Individuazione dei servizi predefinita
- Endpoint HTTP e HTTP/2 completamente gestiti
- Bilanciamento del carico integrato
- Registrazione e monitoraggio
- Scalabilità automatica basata su traffico HTTP o eventi basati su KEDA
- Aggiornamenti e controllo delle versioni delle applicazioni
Archiviazione esterna e altri componenti
Servizio Azure Key Vault per l'archiviazione e l'accesso sicuro ai segreti, ad esempio chiavi API, password e certificati.
Registro Azure Container archivia immagini di contenitori private. È anche possibile usare altri registri contenitori, ad esempio Docker Hub.
Azure Cosmos DB archivia i dati usando Azure Cosmos DB open source per MongoDB. I microservizi sono in genere senza stato e scrivono il proprio stato in archivi dati esterni. Azure Cosmos DB è un database NoSQL con API open source per MongoDB e Cassandra.
bus di servizio di Azure offre una messaggistica cloud affidabile come servizio e una semplice integrazione ibrida. bus di servizio supporta modelli di messaggistica asincroni comuni alle applicazioni di microservizi.
cache di Azure per Redis aggiunge un livello di memorizzazione nella cache all'architettura dell'applicazione per migliorare la velocità e le prestazioni per carichi di traffico pesanti.
Monitoraggio di Azure raccoglie e archivia metriche e log dall'applicazione. Usare questi dati per monitorare l'applicazione, configurare avvisi e dashboard ed eseguire l'analisi della causa radice degli errori. Questo scenario usa un'area di lavoro Log Analytics per il monitoraggio completo dell'infrastruttura e dell'applicazione.
Application Insights offre la gestione estendibile delle prestazioni delle applicazioni (APM) e il monitoraggio per i servizi. Ogni servizio viene instrumentato con Application Insights SDK per monitorare l'app e indirizzare i dati a Monitoraggio di Azure.
Modelli Bicep per configurare e distribuire le applicazioni.
Alternative
Uno scenario alternativo di questo esempio è l'applicazione Fabrikam Drone Delivery usando Kubernetes, disponibile in GitHub nel repository di recapito tramite drone di servizio Azure Kubernetes (AKS) Fabrikam.
Dettagli dello scenario
L'azienda può semplificare la distribuzione e la gestione dei contenitori di microservizi usando App Azure Container. App contenitore offre un ambiente serverless completamente gestito per la compilazione e la distribuzione di applicazioni moderne.
Fabrikam, Inc. (una società fittizia) ha implementato un'applicazione di consegna tramite drone in cui gli utenti possono richiedere un drone per ritirare le merci per la consegna. Quando un cliente pianifica un prelievo, un sistema back-end assegna un drone e invia all'utente una notifica con un tempo di recapito stimato.
L'applicazione di microservizi è stata distribuita in un cluster servizio Azure Kubernetes (servizio Azure Kubernetes). Tuttavia, il team di Fabrikam non sfruttava le funzionalità avanzate o specifiche della piattaforma del servizio Azure Kubernetes. Alla fine è stata eseguita la migrazione dell'applicazione ad App Contenitore di Azure senza sovraccarichi. Con la conversione della soluzione in App Azure Container, Fabrikam è stato in grado di:
- Eseguire la migrazione dell'applicazione quasi così com'è: sono state necessarie modifiche al codice molto minime durante lo spostamento dell'applicazione dal servizio Azure Kubernetes ad App Contenitore di Azure.
- Distribuire sia l'infrastruttura che il carico di lavoro con i modelli Bicep: non sono stati necessari manifesti YAML kubernetes per distribuire i contenitori dell'applicazione.
- Esporre l'applicazione tramite ingresso gestito: supporto predefinito per l'ingresso esterno basato su HTTPS per esporre il servizio di inserimento ha rimosso la necessità di configurare il proprio ingresso.
- Eseguire il pull delle immagini del contenitore da Registro Azure Container: Le app di Azure Container non richiedono un'immagine o un registro di base specifici.
- Gestire il ciclo di vita dell'applicazione: la funzionalità di revisione supporta l'esecuzione di più revisioni di una particolare app contenitore e la suddivisione del traffico tra di esse per scenari di test A/B o di distribuzione Blu/Verde.
- Usare l'identità gestita: il team di Fabrikam è stato in grado di usare un'identità gestita per l'autenticazione con Azure Key Vault e Registro Azure Container.
Potenziali casi d'uso
- Distribuire un'applicazione basata su microservizi brownfield in un'offerta PaaS (Platform as a Service) per evitare la complessità operativa della gestione di un agente di orchestrazione dei contenitori.
- Ottimizzare le operazioni e la gestione eseguendo la migrazione di servizi in contenitori a una piattaforma che supporta la scalabilità nativa a zero.
- Eseguire un processo in background a esecuzione prolungata, ad esempio il servizio flusso di lavoro in modalità revisione singola.
Altri usi comuni delle app contenitore includono:
- Esecuzione di carichi di lavoro in contenitori in una piattaforma serverless basata sul consumo.
- Scalabilità automatica delle applicazioni in base al traffico HTTP/HTTPS e/o ai trigger basati su eventi supportati da KEDA
- Riduzione del sovraccarico di manutenzione per le applicazioni in contenitori
- Distribuzione di endpoint dell'API
- Hosting di applicazioni di elaborazione in background
- Gestione dell'elaborazione guidata dagli eventi
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
Disponibilità
App contenitore consente di distribuire, gestire, gestire e monitorare più facilmente le applicazioni. La disponibilità può essere garantita da queste funzionalità chiave:
- Le revisioni consentono di distribuire gli aggiornamenti delle applicazioni senza tempi di inattività. È possibile usare le revisioni per gestire la distribuzione degli aggiornamenti delle applicazioni e dividere il traffico tra le revisioni per supportare distribuzioni blu/verde e test A/B (attualmente non usati in questo carico di lavoro di esempio).
- Con le funzionalità di osservabilità end-to-end di App contenitore, è disponibile una visualizzazione olistica delle applicazioni in esecuzione. App contenitore è integrato con Monitoraggio di Azure e Log Analytics, che consente di tenere traccia dell'esecuzione dell'app contenitore e impostare avvisi in base a metriche ed eventi.
- Quando un'app termina in modo imprevisto, il servizio App contenitore la riavvia automaticamente.
- È possibile abilitare le regole di scalabilità automatica per soddisfare la domanda man mano che aumenta il traffico e i carichi di lavoro.
- Le prestazioni sono ottimizzate dalle funzionalità di bilanciamento del carico dinamico di App contenitore (attualmente non usate in questo carico di lavoro di esempio).
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.
Per ottenere l'eccellenza operativa, il servizio App contenitore offre queste funzionalità:
- Integrazione di GitHub Actions per la configurazione di distribuzioni CI/CD automatizzate.
- Modalità di revisione multipla con suddivisione del traffico per il test delle modifiche al codice dell'applicazione e regole di scalabilità.
- Integrazione con Monitoraggio di Azure e Log Analytics per fornire informazioni dettagliate sull'applicazione in contenitori.
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 altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.
Considerazioni sulle prestazioni in questa soluzione:
- Il carico di lavoro viene distribuito tra più applicazioni di microservizi.
- Ogni microservizio è indipendente e non condivide nulla con gli altri microservizi, in modo che possano essere ridimensionati in modo indipendente.
- La scalabilità automatica può essere abilitata man mano che aumenta il carico di lavoro.
- Le richieste vengono bilanciate in modo dinamico.
- Le metriche, tra cui l'utilizzo della CPU e della memoria, le informazioni sulla larghezza di banda e l'utilizzo dell'archiviazione, sono disponibili tramite Monitoraggio di Azure.
- Log Analytics offre l'aggregazione dei log per raccogliere informazioni in ogni ambiente di App contenitore.
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à.
App contenitore tenterà di riavviare i contenitori con errori e astrae l'hardware dagli utenti. Gli errori temporanei e la disponibilità elevata delle risorse di calcolo di backup vengono gestiti da Microsoft.
Il monitoraggio delle prestazioni tramite Log Analytics e Monitoraggio di Azure consente di valutare l'applicazione sotto carico. Le metriche e le informazioni di registrazione forniscono i dati necessari per riconoscere le tendenze per prevenire gli errori ed eseguire l'analisi della causa radice degli errori quando si verificano.
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.
Segreti
- L'app contenitore può archiviare e recuperare i valori sensibili come segreti. Dopo aver definito un segreto per l'app contenitore, è disponibile per l'uso da parte dell'applicazione e delle regole di scalabilità associate. Se si esegue in modalità multi-revisione, tutte le revisioni condivideranno gli stessi segreti. Poiché i segreti vengono considerati una modifica dell'ambito applicazione, se si modifica il valore di un segreto, non viene creata una nuova revisione. Tuttavia, per eventuali revisioni in esecuzione per caricare il nuovo valore del segreto, sarà necessario riavviarli. In questo scenario vengono usati i valori delle variabili di applicazione e ambiente.
- Variabili di ambiente: i valori sensibili possono essere archiviati in modo sicuro a livello di applicazione. Quando le variabili di ambiente vengono modificate, l'app contenitore genera una nuova revisione.
Sicurezza di rete
- Ingresso: per limitare l'accesso esterno, solo il servizio di inserimento è configurato per l'ingresso esterno. I servizi back-end sono accessibili solo tramite la rete virtuale interna nell'ambiente App contenitore. Espone solo i servizi a Internet, se necessario. Poiché questa architettura usa la funzionalità di ingresso esterna predefinita, questa soluzione non offre la possibilità di posizionare completamente il punto di ingresso dietro un web application firewall (WAF) o di includerlo nei piani di protezione DDoS. Tutti i carichi di lavoro con connessione Web devono essere front-end con un web application firewall.
- Rete virtuale: quando si crea un ambiente, è possibile fornire una rete virtuale personalizzata; in caso contrario, una rete virtuale viene generata e gestita automaticamente da Microsoft. Non è possibile modificare questa rete virtuale gestita da Microsoft, ad esempio aggiungendo gruppi di sicurezza di rete (NSG) o forzando il tunneling del traffico a un firewall in uscita. In questo esempio viene usata una rete virtuale generata automaticamente.
Per altre opzioni di topologia di rete, vedere Architettura di rete in App Azure Container.
Identità dei carichi di lavoro
- App contenitore supporta le identità gestite di Microsoft Entra che consentono all'app di eseguire l'autenticazione in altre risorse protette da Microsoft Entra ID, ad esempio Azure Key Vault, senza gestire le credenziali nell'app contenitore. Un'app contenitore può usare i tipi assegnati dal sistema, assegnati dall'utente o entrambi i tipi di identità gestite. Per i servizi che non supportano l'autenticazione di Active Directory, è necessario archiviare i segreti in Azure Key Vault e usare un'identità gestita per accedere ai segreti.
- Usare le identità gestite per l'accesso Registro Azure Container. App Contenitore di Azure supporta l'uso di un'identità gestita diversa per il carico di lavoro rispetto all'accesso al registro contenitori, consigliato quando si vuole ottenere controlli di accesso granulari sulle identità gestite.
Ottimizzazione dei costi
- La sezione Costo in Microsoft Azure Well-Architected Framework descrive le considerazioni sui costi. Usare il calcolatore prezzi di Azure per stimare i costi per lo scenario specifico.
- App Azure Container ha un modello tariffario basato sul consumo.
- App Azure Container supporta la scalabilità a zero. Quando un'app contenitore viene ridimensionata su zero, non è previsto alcun addebito.
- In questo scenario, Azure Cosmos DB e cache di Azure per Redis sono i principali driver di costo.
Distribuire lo scenario
Per distribuire questo scenario, seguire la procedura descritta nella README.md nel repository di scenari di esempio di App contenitore di Azure.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Catherine Bundy | Writer tecnico
Passaggi successivi
- Documentazione di App Azure Container
- repository GitHub per la distribuzione di droni servizio Azure Kubernetes (AKS)