Le applicazioni «cloud native» o semplicemente «cloud» sono progettate specificamente per operare nelle infrastrutture cloud. Di solito, sono costruite come un insieme di microservizi debolmente accoppiati, confezionati in contenitori, che a loro volta sono gestiti da una piattaforma cloud. Queste applicazioni sono pronte per le interruzioni per impostazione predefinita, il che significa che funzionano in modo affidabile e si scalano anche in caso di fallimenti significativi dell'infrastruttura. D'altro canto, ci sono set di vincoli (contratti) che la piattaforma cloud impone sulle applicazioni containerizzate per poterle gestire automaticamente.
Consapevoli della necessità e dell'importanza del passaggio alle applicazioni cloud, molte organizzazioni non sanno ancora da dove cominciare. In questo post, esamineremo una serie di principi la cui osservanza nella progettazione di applicazioni containerizzate consentirà di realizzare il potenziale delle piattaforme cloud e garantire un funzionamento e una scalabilità affidabili delle applicazioni anche di fronte a seri guasti dell'infrastruttura IT. L'obiettivo finale dei principi qui esposti è imparare a creare applicazioni che possono essere gestite automaticamente dalle piattaforme cloud, come Kubernetes.
Principi di progettazione del software
Nel mondo della programmazione, i principi si riferiscono a regole piuttosto generali che devono essere rispettate durante lo sviluppo del software. Possono essere applicati con qualsiasi linguaggio di programmazione. Ogni principio ha i propri obiettivi, il cui strumento di attuazione sono solitamente modelli e pratiche. Esiste anche un insieme di principi fondamentali per la creazione di software di qualità, da cui derivano tutti gli altri. Ecco alcuni esempi di principi fondamentali:
- (Keep it simple, stupid) – non complicare;
- (Don’t repeat yourself) – non ripetersi;
- (You aren’t gonna need it) – non creare ciò di cui non hai bisogno immediato;
- (Separation of concerns) – separare le responsabilità.
Come si può vedere, questi principi non stabiliscono regole specifiche, ma appartengono al cosiddetto ambito del buon senso basato sull'esperienza pratica, condiviso da molti sviluppatori e a cui essi fanno riferimento regolarmente.
Inoltre, esiste – un insieme dei primi cinque principi della programmazione e progettazione orientata agli oggetti, formulati da Robert Martin. SOLID include principi generali e aperti a interpretazione, che – se applicati insieme – aiutano a creare sistemi software di qualità superiore e a mantenerli meglio nel lungo periodo.
I principi SOLID appartengono alla sfera della programmazione orientata agli oggetti e sono formulati in termini di concetti e nozioni come classi, interfacce e ereditarietà. Analogamente, anche per le applicazioni cloud è possibile formulare principi di sviluppo, dove l’elemento base non è la classe, ma il contenitore. Seguendo questi principi, è possibile creare applicazioni containerizzate che rispondono meglio agli obiettivi delle piattaforme cloud come Kubernetes.
Contenitori orientati al cloud: l'approccio Red Hat
Oggi è relativamente facile impacchettare praticamente qualsiasi applicazione in contenitori. Ma affinché le applicazioni siano automatizzate e orchestrate in modo efficace su piattaforme cloud tipo Kubernetes, è necessario fare ulteriori sforzi.
La base delle idee sottostanti è stata la metodologia e numerosi altri lavori su vari aspetti della creazione di applicazioni web, dalla gestione del codice sorgente ai modelli di scalabilità. I principi descritti si applicano esclusivamente allo sviluppo di applicazioni containerizzate basate su microservizi e destinate a piattaforme cloud come Kubernetes. L'elemento fondamentale nel nostro ragionamento è l'immagine del contenitore, e con l'ambiente di esecuzione dei contenitori intendiamo la piattaforma di orchestrazione dei contenitori. L'obiettivo dei principi proposti è creare contenitori per i quali la maggior parte delle piattaforme di orchestrazione possa automatizzare attività di scheduling, scaling e monitoring. I principi sono esposti in ordine arbitrario.
Principio della singola responsabilità (Single Concern Principle, SCP)
Questo principio è in gran parte simile al principio della singola responsabilità (Single Responsibility Principle, ), che fa parte del set SOLID e afferma che ogni oggetto deve avere una sola responsabilità, e questa responsabilità deve essere completamente incapsulata nella classe. L'essenza dell'SRP è che ogni responsabilità rappresenta una causa di cambiamento, e la classe deve avere una e una sola causa per cambiare.
Nell'SCP, invece della parola "responsabilità" (responsibility) usiamo la parola "compito" (concern), per indicare un livello di astrazione superiore e un uso più ampio del contenitore rispetto a una classe OOP. E se l'obiettivo dell'SRP è avere solo una causa di cambiamento, l'SCP si basa sul desiderio di ampliare le possibilità di riutilizzo e sostituzione dei contenitori. Seguendo l'SRP e creando un contenitore che risolve un solo compito e lo fa in modo funzionale e completo, aumentate le possibilità di riutilizzare l'oggetto di quel contenitore in diversi contesti applicativi.
Il principio SCP afferma che ogni contenitore deve risolvere un unico compito e farlo bene. Inoltre, l'SCP nel mondo dei contenitori è più facile da raggiungere rispetto all'SRP nel mondo OOP, poiché i contenitori di solito eseguono un solo processo, e la maggior parte del tempo quel processo risolve un solo compito.
Se un certo microservizio del contenitore deve risolvere più compiti, può essere suddiviso in contenitori a singolo compito e aggregato all'interno di un singolo pod (unità di distribuzione della piattaforma dei contenitori) utilizzando i modelli sidecar e init-containers. Inoltre, l'SCP facilita la sostituzione di un vecchio contenitore (ad esempio, un server web o un broker di messaggi) con uno nuovo che risolve lo stesso compito, ma offre funzionalità ampliate o si scala meglio.
Principio di alta osservabilità (High Observability Principle, HOP)
Nell'utilizzo di contenitori come metodo unificato per il packaging e l'avvio delle applicazioni, le stesse applicazioni sono considerate come una "scatola nera". Tuttavia, se si tratta di contenitori cloud, essi devono fornire all'ambiente di esecuzione API speciali per controllare l'integrità dei contenitori e intraprendere le azioni necessarie. Senza questo, non sarà possibile unificare l'automazione dell'aggiornamento dei contenitori e la gestione del loro ciclo di vita, il che, a sua volta, comprometterà la robustezza e la facilità d'uso del sistema software.
In pratica, un'applicazione container deve almeno disporre di un'API per vari tipi di controlli di integrità: test di attività (liveness) e test di prontezza (readiness). Se l'applicazione pretende di più, deve fornire anche altri strumenti di monitoraggio del proprio stato. Ad esempio, la registrazione di eventi importanti tramite STDERR e STDOUT per l'aggregazione dei log usando Fluentd, Logstash e strumenti simili. E anche integrazioni con librerie di tracciamento e raccolta metriche, come OpenTracing, Prometheus e così via.
In generale, un'applicazione può ancora essere vista come una "scatola nera", ma deve essere dotata di tutte le API necessarie affinché la piattaforma possa monitorarla e gestirla in modo ottimale.
Principio di conformità al ciclo di vita (Life-cycle Conformance Principle, LCP)
LCP è un'antitesi del HOP. Se HOP afferma che il contenitore deve fornire alla piattaforma API per la lettura, LCP richiede all'applicazione la capacità di ricevere informazioni dalla piattaforma. Inoltre, il contenitore deve non solo ricevere eventi, ma anche adattarsi, ovvero reagire a essi. Da qui il nome del principio, che può essere visto come il requisito di fornire alla piattaforma API per la scrittura.
Le piattaforme hanno diversi tipi di eventi che aiutano a gestire il ciclo di vita del contenitore. Ma spetta all'applicazione decidere quali di essi ricevere e come reagire.
È chiaro che alcuni eventi sono più importanti di altri. Ad esempio, se un'applicazione gestisce male il termine improvviso, deve accettare i messaggi signal: terminate (SIGTERM) e avviare la propria procedura di terminazione il prima possibile, per riuscire prima della ricezione di signal: kill (SIGKILL), che arriva dopo SIGTERM.
Inoltre, eventi come PostStart e PreStop possono essere importanti per il ciclo di vita dell'applicazione. Ad esempio, dopo il lancio, potrebbe essere necessario un certo tempo per il "riscaldamento" dell'applicazione prima che possa rispondere alle richieste. Oppure l'applicazione deve liberare risorse in modo particolare al termine.
Principio di immutabilità dell'immagine del contenitore (Image Immutability Principle, IIP)
È comunemente accettato che le applicazioni containerizzate debbano rimanere immutabili dopo la compilazione, anche quando vengono eseguite in ambienti diversi. Da qui deriva la necessità di esternalizzare la memorizzazione dei dati a runtime (in altre parole, utilizzare strumenti esterni per questo), così come dipendere da configurazioni esterne, configurate per l'ambiente di esecuzione specifico, invece di modificare o creare contenitori unici per ogni ambiente. Dopo qualsiasi modifica all'applicazione, l'immagine del contenitore deve essere ricompilata e distribuita in tutti gli ambienti utilizzati. A proposito, nella gestione dei sistemi IT viene utilizzato un principio simile, noto come principio di immutabilità dei server e dell'infrastruttura.
L'obiettivo dell'IIP è prevenire la creazione di immagini del contenitore separate per diversi ambienti di esecuzione e utilizzare lo stesso contenitore ovunque insieme alla configurazione appropriata per l'ambiente specifico. Seguire questo principio consente di implementare pratiche fondamentali per l'automazione dei sistemi cloud, come il roll-back e il roll-forward degli aggiornamenti dell'applicazione.
Principio di disposabilità dei processi (Process Disposability Principle, PDP)
Una delle caratteristiche più importanti di un contenitore è la sua ephemerità: un'istanza di contenitore è facilmente creata e facilmente distrutta, quindi può essere facilmente sostituita da un'altra istanza in qualsiasi momento. Le ragioni per tale sostituzione possono essere molte: fallimento del test di integrità, scalabilità dell'applicazione, migrazione su un altro host, esaurimento delle risorse della piattaforma o altre situazioni.
Di conseguenza, le applicazioni containerizzate devono mantenere il proprio stato utilizzando strumenti esterni o impiegando schemi distribuiti interni con ridondanza. Inoltre, l'applicazione deve avviarsi rapidamente e terminare l'esecuzione in tempi brevi, oltre a essere pronta per un'improvvisa e fatale avaria dell'hardware.
Una delle pratiche che aiuta a realizzare questo principio consiste nel creare contenitori di dimensioni ridotte. Gli ambienti cloud possono selezionare automaticamente l'host per avviare un'istanza del contenitore, quindi più piccola è la dimensione del contenitore, più veloce sarà l'avvio: verrà semplicemente copiato più velocemente sull'host di destinazione attraverso la rete.
Principio di autosufficienza (Self-containment Principle, S-CP)
Secondo questo principio, durante la fase di costruzione, nel contenitore vengono inclusi tutti i componenti necessari. Il contenitore deve essere progettato considerando che nel sistema esiste solo un kernel Linux pulito, quindi tutte le librerie aggiuntive necessarie devono essere posizionate all'interno del contenitore stesso. Qui dovrebbero trovarsi anche elementi come l'ambiente di runtime per il linguaggio di programmazione pertinente, la piattaforma applicativa (se necessario) e altre dipendenze necessarie durante l'esecuzione dell'applicazione containerizzata.
Le eccezioni vengono fatte solo per le configurazioni che variano da ambiente a ambiente, e devono essere fornite durante l'esecuzione, ad esempio, tramite Kubernetes ConfigMap.
L'applicazione può includere diversi componenti containerizzati, ad esempio, un contenitore separato per il DBMS all'interno di un'applicazione web containerizzata. Secondo il principio S-CP, questi contenitori non devono essere uniti in uno solo, ma è opportuno fare in modo che il contenitore DBMS contenga tutto il necessario per il funzionamento del database, mentre il contenitore dell'applicazione web deve includere tutto il necessario per il funzionamento dell'applicazione web, incluso il server web. Di conseguenza, durante l'esecuzione, il contenitore dell'applicazione web dipenderà dal contenitore DBMS e vi si riferirà quando necessario.
Principio di confine in fase di esecuzione (Runtime Confinement Principle, RCP)
Il principio S-CP definisce come deve essere assemblato il container e cosa deve contenere il file binario dell'immagine. Ma il container non è solo una "scatola nera" che ha una sola caratteristica: la dimensione del file. Durante l'esecuzione, il container acquisisce altre dimensioni: quantità di memoria utilizzata, tempo di CPU e altre risorse di sistema.
Ed è qui che entra in gioco il principio RCP, secondo il quale il container deve decapitare le sue esigenze di risorse di sistema e trasferirle alla piattaforma. Avere profili di risorse per ogni container (quante risorse di CPU, memoria, rete e disco gli servono) consente alla piattaforma di gestire la pianificazione e l'autoscaling in modo ottimale, oltre a gestire le capacità IT e mantenere i livelli SLA per i container.
Oltre a soddisfare le esigenze di risorse del container, è anche importante che l'applicazione non superi i limiti che ha definito. In caso contrario, se si verifica una carenza di risorse, è più probabile che la piattaforma la includa nell'elenco delle applicazioni da interrompere o migrare.
Parlando di cloud-first, intendiamo principalmente il modo di lavorare.
In precedenza, abbiamo formulato una serie di principi generali che stabiliscono le basi metodologiche per la creazione di applicazioni container di qualità per ambienti cloud.
Si noti che oltre a questi principi generali, avrete bisogno di ulteriori metodi e tecniche avanzate per lavorare con i container. Inoltre, abbiamo alcune brevi raccomandazioni che sono più specifiche e devono essere applicate (o meno) a seconda della situazione:
- Cercate di ridurre le dimensioni delle immagini: eliminate i file temporanei e non installate pacchetti non necessari; più piccola è la dimensione del container, più velocemente viene assemblato e copiato sulla destinazione attraverso la rete.
- Fate riferimento a User-ID arbitri: non utilizzate il comando sudo o particolari userid per avviare i vostri container.
- Contrassegnate le porte importanti: i numeri delle porte possono essere specificati anche durante l'esecuzione, ma è meglio indicarli tramite il comando EXPOSE – sarà più semplice per altre persone e programmi utilizzare le vostre immagini.
- Conserva i dati permanenti sui volumi: i dati che devono rimanere dopo la distruzione del container devono essere scritti sui volumi.
- Definisci i metadati dell'immagine: i tag, le etichette e le annotazioni facilitano l'uso delle immagini – altri sviluppatori ti saranno grati.
- Sincronizza host e immagini: alcune applicazioni containerizzate richiedono la sincronizzazione del container con l'host in base a determinati attributi, come l'ora o l'identificativo della macchina.
- In conclusione, condividiamo modelli e migliori pratiche che aiuteranno a implementare in modo più efficace i principi sopra elencati:
11 giugno alle 11.00
Cosa imparerai:
- Immutable Red Hat Enterprise Linux CoreOS
- OpenShift service mesh
- Operator framework
- Knative framework
Fonte: habr.com
