Containerizzazione di applicazioni monolitiche

Suggerimento

Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET containerizzati, disponibile in documentazione .NET o come PDF scaricabile gratuitamente leggibile offline.

Scaricare il PDF

È possibile creare una singola applicazione Web o un servizio distribuito monoliticamente e distribuirlo come contenitore. L'applicazione stessa potrebbe non essere internamente monolitica, ma strutturata come diverse librerie, componenti o persino livelli (livello applicazione, livello di dominio, livello di accesso ai dati e così via). Esternamente, tuttavia, si tratta di un singolo contenitore, ovvero un singolo processo, una singola applicazione Web o un singolo servizio.

Per gestire questo modello, distribuire un singolo contenitore per rappresentare l'applicazione. Per aumentare la capacità, è possibile scalare orizzontalmente, ovvero aggiungere altre copie con un bilanciamento del carico davanti. La semplicità deriva dalla gestione di una singola distribuzione in un singolo contenitore o macchina virtuale.

Figura 4-1. Esempio di architettura di un'applicazione monolitica in contenitori

È possibile includere più componenti, librerie o livelli interni in ogni contenitore, come illustrato nella figura 4-1. Un'applicazione containerizzata monolitica ha la maggior parte delle sue funzionalità all'interno di un singolo contenitore, con livelli o librerie interne, e si espande clonando il contenitore su più server o macchine virtuali. Tuttavia, questo modello monolitico potrebbe essere in conflitto con il principio del contenitore "un contenitore esegue un'unica operazione e lo esegue in un unico processo", ma potrebbe essere ok per alcuni casi.

Lo svantaggio di questo approccio diventa evidente se l'applicazione cresce, richiedendo la scalabilità. Se l'intera applicazione può essere ridimensionata, non è un problema. Nella maggior parte dei casi, tuttavia, solo alcune parti dell'applicazione sono i punti di soffocamento che richiedono il ridimensionamento, mentre altri componenti vengono usati meno.

Ad esempio, in una tipica applicazione di e-commerce, è probabile che sia necessario ridimensionare il sottosistema delle informazioni sul prodotto, perché molti più clienti esplorano i prodotti rispetto all'acquisto. Più clienti usano il carrello rispetto a quanti utilizzano il sistema di pagamento. Meno clienti aggiungono commenti o visualizzano la cronologia degli acquisti. E potresti avere solo pochi dipendenti che devono gestire i contenuti e le campagne di marketing. Se si ridimensiona la progettazione monolitica, tutto il codice per queste diverse attività viene distribuito più volte e ridimensionato allo stesso livello.

Esistono diversi modi per ridimensionare una duplicazione orizzontale dell'applicazione, suddividere aree diverse dell'applicazione e partizionare concetti o dati aziendali simili. Tuttavia, oltre al problema del ridimensionamento di tutti i componenti, le modifiche apportate a un singolo componente richiedono la ripetizione completa dell'intera applicazione e una ridistribuzione completa di tutte le istanze.

Tuttavia, l'approccio monolitico è comune, perché lo sviluppo dell'applicazione è inizialmente più semplice rispetto agli approcci ai microservizi. Di conseguenza, molte organizzazioni sviluppano usando questo approccio architetturale. Anche se alcune organizzazioni hanno avuto risultati sufficienti, altri stanno raggiungendo i limiti. Molte organizzazioni hanno progettato le proprie applicazioni usando questo modello perché gli strumenti e l'infrastruttura hanno reso troppo difficile creare architetture orientate ai servizi (SOA) anni fa e non hanno visto la necessità fino a quando l'applicazione è cresciuta.

Dal punto di vista dell'infrastruttura, ogni server può eseguire molte applicazioni all'interno dello stesso host e avere un rapporto accettabile di efficienza nell'utilizzo delle risorse, come illustrato nella figura 4-2.

Figura 4-2. Approccio monolitico: esecuzione di più applicazioni, ciascuna eseguita come un container

Le applicazioni monolitiche in Microsoft Azure possono essere distribuite usando macchine virtuali dedicate per ogni istanza. Inoltre, usando i set di scalabilità di macchine virtuali di Azure, è possibile ridimensionare facilmente le macchine virtuali. Il servizio app di Azure può anche eseguire applicazioni monolitiche e ridimensionare facilmente le istanze senza richiedere la gestione delle macchine virtuali. Dal 2016 Servizi app di Azure può eseguire anche singole istanze di contenitori Docker, semplificando la distribuzione.

Come ambiente di controllo di qualità o ambiente di produzione limitato, è possibile distribuire più macchine virtuali host Docker e bilanciarle usando il servizio di bilanciamento di Azure, come illustrato nella figura 4-3. In questo modo è possibile gestire il ridimensionamento con un approccio granulare grossolano, perché l'intera applicazione si trova all'interno di un singolo contenitore.

Figura 4-3. Esempio di più host che aumentano le prestazioni di una singola applicazione contenitore

La distribuzione nei vari host può essere gestita con tecniche di distribuzione tradizionali. Gli host Docker possono essere gestiti con comandi come docker run o docker-compose eseguiti manualmente o tramite automazione, ad esempio pipeline di recapito continuo (CD).

Distribuzione di un'applicazione monolitica in un container

Esistono vantaggi per l'uso dei contenitori per gestire le distribuzioni di applicazioni monolitiche. Il ridimensionamento delle istanze dei contenitori è molto più veloce e semplice rispetto alla distribuzione di macchine virtuali aggiuntive. Anche se si usano set di scalabilità di macchine virtuali, l'avvio delle macchine virtuali richiede tempo. Quando viene distribuita come istanze dell'applicazione tradizionale anziché come contenitori, la configurazione dell'applicazione viene gestita come parte della macchina virtuale, che non è ideale.

La distribuzione degli aggiornamenti sotto forma di immagini Docker è molto più veloce ed efficiente dal punto di vista della rete. Le immagini Docker vengono in genere avviate entro pochi secondi, velocizzando la distribuzione. L'disinstallazione di un'istanza di immagine Docker è semplice come l'esecuzione di un docker stop comando e in genere viene completata in meno di un secondo.

Poiché i contenitori non sono modificabili per impostazione predefinita, non è mai necessario preoccuparsi delle macchine virtuali danneggiate. Al contrario, gli script di aggiornamento per una macchina virtuale potrebbero dimenticare di tenere conto di una configurazione o di un file specifico lasciato su disco.

Anche se le applicazioni monolitiche possono trarre vantaggio da Docker, vengono toccati solo i vantaggi. Altri vantaggi della gestione dei contenitori derivano dalla distribuzione con agenti di orchestrazione dei contenitori, che gestiscono le varie istanze e il ciclo di vita di ogni istanza del contenitore. Suddividere l'applicazione monolitica in sottosistemi che possono essere scalati, sviluppati e distribuiti singolarmente è il punto di ingresso nell'ambito dei microservizi.

Pubblicazione di un'applicazione basata su singolo contenitore nel servizio app di Azure

Se si vuole ottenere la convalida di un contenitore distribuito in Azure o quando un'applicazione è semplicemente un'applicazione a contenitore singolo, il servizio app di Azure offre un ottimo modo per fornire servizi scalabili basati su contenitore singolo. L'uso del servizio app di Azure è semplice. Offre un'ottima integrazione con Git per semplificare l'uso del codice, compilarlo in Visual Studio e distribuirlo direttamente in Azure.

Figura 4-4. Pubblicazione di un'applicazione con contenitore singolo in Servizio App di Azure da Visual Studio 2022

Senza Docker, se sono necessarie altre funzionalità, framework o dipendenze non supportate nel servizio app di Azure, è necessario attendere che il team di Azure ha aggiornato tali dipendenze nel servizio app. In alternativa, è stato necessario passare ad altri servizi, ad esempio Servizi cloud di Azure o macchine virtuali, in cui è stato possibile controllare ulteriormente e installare un componente o un framework necessari per l'applicazione.

Il supporto dei contenitori in Visual Studio 2017 e versioni successive offre la possibilità di includere qualsiasi elemento desiderato nell'ambiente dell'applicazione, come illustrato nella figura 4-4. Poiché è in esecuzione in un contenitore, se si aggiunge una dipendenza all'applicazione, è possibile includere la dipendenza nell'immagine Dockerfile o Docker.

Come illustrato anche nella figura 4-4, il flusso di pubblicazione esegue il push di un'immagine tramite un registro contenitori. Può trattarsi del Registro Azure Container (un registro vicino alle distribuzioni in Azure e protetto da gruppi e account di Azure Active Directory) o qualsiasi altro registro Docker, ad esempio l'hub Docker o un registro locale.

PrecedenteAvanti