Le applicazioni "cloud native" o semplicemente "cloud" sono progettate specificamente per funzionare nelle infrastrutture cloud. Di solito, esse sono costruite come un insieme di microservizi debolmente accoppiati, impacchettati in container, che a loro volta sono gestiti da una piattaforma cloud. Queste applicazioni, per definizione, sono pronte a fronteggiare guasti, il che significa che funzionano in modo affidabile e scalano anche in caso di gravi malfunzionamenti a livello infrastrutturale. Tuttavia, ci sono anche set di vincoli (contratti) che la piattaforma cloud impone sulle applicazioni containerizzate per poterle gestire in modo automatico.
Pur comprendere l'importanza del passaggio alle applicazioni cloud, molte organizzazioni non sanno ancora da dove iniziare. In questo post, esamineremo una serie di principi che, se seguiti nello sviluppo di applicazioni containerizzate, consentiranno di sfruttare il potenziale delle piattaforme cloud e garantire un funzionamento e una scalabilità affidabili delle applicazioni, anche in caso di gravi guasti nell'infrastruttura IT. L'obiettivo finale di questi principi è imparare a creare applicazioni che possano essere gestite automaticamente da piattaforme cloud come Kubernetes.
Principi di progettazione del software
Nel mondo della programmazione, i principi si riferiscono a regole abbastanza generali che devono essere seguite nello sviluppo di software. Possono essere applicati con qualsiasi linguaggio di programmazione. Ogni principio ha i propri obiettivi, i cui strumenti vengono solitamente realizzati tramite modelli e pratiche. Esistono anche alcuni principi fondamentali per la creazione di software di alta qualità, da cui derivano tutti gli altri. Ecco alcuni esempi di principi fondamentali:
- (Keep it simple, stupid) – non complicare le cose;
- (Don’t repeat yourself) – non ripeterti;
- (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 concrete, ma appartengono alla categoria di considerazioni di buon senso basate sull'esperienza pratica, condivise da molti sviluppatori e a cui essi fanno riferimento regolarmente.
Inoltre, esiste – un insieme dei primi cinque principi di programmazione e progettazione orientata agli oggetti, formulati da Robert Martin. SOLID include principi generali e aperti a interpretazioni complementari, che - se applicati in modo congiunto - aiutano a creare sistemi software di maggiore qualità e a mantenerli meglio nel lungo periodo.
I principi SOLID si applicano all'ambito della programmazione orientata agli oggetti e si formulano in termini di concetti come classi, interfacce e ereditarietà. Allo stesso modo, per le applicazioni cloud è possibile definire principi di sviluppo, dove l'elemento fondamentale non è una classe, ma un contenitore. Seguendo questi principi, è possibile creare applicazioni containerizzate che rispondono meglio agli obiettivi e alle esigenze delle piattaforme cloud come Kubernetes.
Container orientati al cloud: l'approccio di Red Hat
Oggi è relativamente semplice imballare praticamente qualsiasi applicazione in un contenitore. Tuttavia, affinché le applicazioni possano essere automatizzate e orchestrate in modo efficace all'interno di una piattaforma cloud come Kubernetes, è necessario fare uno sforzo aggiuntivo.
La base delle idee qui riportate è stata fornita dalla metodologia e molti 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, costruite su microservizi e destinate a piattaforme cloud come Kubernetes. L'elemento di base nelle nostre considerazioni è l'immagine del container, e per ambiente di esecuzione dei container si intende la piattaforma di orchestrazione dei container. L'obiettivo dei principi proposti è di creare container per i quali sulla maggior parte delle piattaforme di orchestrazione possono essere automatizzati compiti di scheduling (scelta dell'host per l'esecuzione di un'istanza del container), scalabilità e monitoraggio. I principi sono esposti in ordine arbitrario.
Principio della singola preoccupazione (Single Concern Principle, SCP)
Questo principio è molto simile al principio di 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 del SRP è che ogni responsabilità è una causa di cambiamento, e la classe deve avere una e una sola causa di cambiamento.
Nel SCP, invece della parola «responsabilità» (responsibility), utilizziamo la parola «compito» (concern) per indicare un livello di astrazione più elevato e un uso più ampio del contenitore rispetto alla classe OOP. E se l'obiettivo del SRP è avere solo una causa di cambiamenti, SCP si basa sul desiderio di ampliare le capacità di riutilizzo e sostituzione dei contenitori. Seguendo il SRP e creando un contenitore che affronta un'unica, specifica questione e lo fa in modo funzionale e completo, aumenti le possibilità di riutilizzo di quel contenitore in vari contesti applicativi.
Il principio SCP afferma che ogni contenitore deve svolgere un'unica funzione e farlo bene. Inoltre, nel mondo dei contenitori, l'SCP è più facile da raggiungere rispetto all'SRP nel mondo OOP, poiché i contenitori generalmente eseguono un solo processo, e per gran parte del tempo quel processo risolve un'unica attività.
Se un microservizio contenitore deve affrontare più compiti contemporaneamente, può essere suddiviso in contenitori monofunzionali e combinato all'interno di un'unica pod (unità di distribuzione della piattaforma dei contenitori) utilizzando modelli sidecar e init-container. Inoltre, l'SCP facilita la sostituzione di un contenitore obsoleto (ad esempio, un server web o un broker di messaggi) con uno nuovo che svolge la stessa funzione, ma offre funzionalità migliorate o una scalabilità superiore.
Il principio dell'alta osservabilità (High Observability Principle, HOP)
Quando si utilizzano i container come metodo unificato per imballare e avviare applicazioni, queste ultime sono considerate come una "scatola nera". Tuttavia, se si tratta di container cloud, devono fornire API specifiche all'ambiente di esecuzione per controllare la salute dei container e adottare le misure necessarie. Senza questo, non sarà possibile unificare l'automazione dell'aggiornamento dei container e gestire il loro ciclo di vita, il che a sua volta comprometterà la resilienza e l'usabilità del sistema software.
Nella pratica, un'applicazione containerizzata deve, almeno, avere API per diversi tipi di controlli della salute: test di attività (liveness) e test di prontezza (readiness). Se l'applicazione mira a di più, deve fornire anche altri mezzi di controllo del proprio stato. Ad esempio, la registrazione di eventi importanti tramite STDERR e STDOUT per l'aggregazione dei log con strumenti come Fluentd, Logstash e altri strumenti simili. E anche l'integrazione con librerie di tracciamento e raccolta di metriche, come OpenTracing, Prometheus, ecc.
In generale, l'applicazione può comunque essere considerata come un «black box», ma deve essere dotata di tutte le API necessarie alla piattaforma per monitorarla e gestirla nel modo migliore.
Principio di Conformità al Ciclo di Vita (Life-cycle Conformance Principle, LCP)
LCP è l'antitesi dell'HOP. Se l'HOP afferma che il contenitore deve fornire API alla piattaforma per la lettura, l'LCP richiede all'applicazione di ricevere informazioni dalla piattaforma. Inoltre, il contenitore non deve solo ricevere eventi, ma anche adattarsi, in altre parole, reagire a essi. Da qui il nome del principio, che può essere visto come un requisito di fornire API di scrittura alla piattaforma.
Le piattaforme hanno diversi tipi di eventi che aiutano a gestire il ciclo di vita del contenitore. Tuttavia, spetta all'applicazione decidere quali eventi percepire e come reagire.
È chiaro che alcuni eventi sono più importanti di altri. Ad esempio, se un'applicazione gestisce male il termine anomalo, deve accettare i messaggi signal: terminate (SIGTERM) e avviare il proprio processo di terminazione il più velocemente possibile, per poterlo fare prima che venga ricevuto il signal: kill (SIGKILL), che arriva dopo il SIGTERM.
Inoltre, eventi come PostStart e PreStop possono essere cruciali per il ciclo di vita di un'applicazione. Ad esempio, dopo l'avvio, l'applicazione potrebbe avere bisogno di un certo tempo per il 'riscaldamento' prima di poter rispondere alle richieste. Oppure l'applicazione deve liberare risorse in un modo particolare durante la sua chiusura.
Il principio di immutabilità dell'immagine del container (Image Immutability Principle, IIP)
È comune ritenere che le applicazioni containerizzate debbano rimanere immutabili dopo la build, anche quando vengono eseguite in ambienti diversi. Da questo deriva la necessità di esternalizzare lo storage dei dati durante l'esecuzione (in altre parole, utilizzare strumenti esterni per questo) e di affidarsi a configurazioni esterne, specifiche per l'ambiente di esecuzione, invece di modificare o creare container unici per ogni ambiente. Dopo qualsiasi modifica all'applicazione, l'immagine del container deve essere ricostruita e distribuita in tutti gli ambienti utilizzati. A proposito, nella gestione dei sistemi IT viene utilizzato un principio simile, noto come principio dell'immutabilità dei server e dell'infrastruttura.
L'obiettivo dell'IIP è quello di evitare di creare immagini di container separate per diversi ambienti di esecuzione e utilizzare lo stesso image ovunque con la configurazione appropriata per l'ambiente specifico. Seguire questo principio consente di implementare pratiche fondamentali per l'automazione dei sistemi cloud, come il rollback e il roll-forward degli aggiornamenti dell'applicazione.
Il principio della transitorietà dei processi (Process Disposability Principle, PDP)
Una delle caratteristiche fondamentali di un container è la sua efemerità: un'istanza di container può essere facilmente creata e distrutta, rendendola sostituibile in qualsiasi momento. Ci sono molte ragioni per cui questa sostituzione può avvenire: un fallimento nel test di integrità, il ridimensionamento dell'applicazione, il trasferimento su un altro host, l'esaurimento delle risorse della piattaforma o altre situazioni.
Di conseguenza, le applicazioni containerizzate devono mantenere il proprio stato utilizzando strumenti esterni, oppure adottare schemi distribuiti interni con ridondanza. Inoltre, l'applicazione deve avviarsi rapidamente e terminare altrettanto velocemente, e deve essere pronta a subire un'improvvisa e fatale avaria dell'hardware.
Una delle pratiche che aiutano a realizzare questo principio è quella di creare container di dimensioni contenute. Gli ambienti cloud possono automaticamente selezionare un host per avviare un'istanza di container, quindi più piccola è la dimensione del container, più velocemente verrà avviata: si copierà semplicemente più rapidamente sull'host di destinazione tramite rete.
Principio di auto-sufficienza (Self-containment Principle, S-CP)
Secondo questo principio, durante la fase di assemblaggio tutti i componenti necessari vengono inclusi nel contenitore. Il contenitore deve essere progettato tenendo conto che nel sistema c'è solo un nucleo Linux pulito, quindi tutte le librerie necessarie devono essere collocate all'interno dello stesso contenitore. Qui devono essere presenti anche elementi come l'ambiente di esecuzione per il linguaggio di programmazione pertinente, la piattaforma applicativa (se necessario) e altre dipendenze richieste durante l'esecuzione dell'applicazione contenitore.
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 database all'interno di un'applicazione web containerizzata. Secondo il principio S-CP, questi contenitori non devono essere uniti in uno solo, ma devono essere progettati in modo tale che il contenitore del database contenga tutto il necessario per il funzionamento del database, mentre il contenitore dell'applicazione web contenga tutto il necessario per l'esecuzione dell'applicazione web, incluso il server web. Di conseguenza, durante l'esecuzione, il contenitore dell'applicazione web dipenderà dal contenitore del database e si connetterà ad esso secondo necessità.
Principio di restrizione in tempo di esecuzione (Runtime Confinement Principle, RCP)
Il principio S-CP definisce come deve essere assemblato un contenitore e cosa deve contenere il file binario dell'immagine. Ma un contenitore non è solo un "black box" con una sola caratteristica - la dimensione del file. Durante l'esecuzione, un contenitore acquisisce altre dimensioni: la quantità di memoria utilizzata, il tempo di CPU e altre risorse di sistema.
E qui entra in gioco il principio RCP, secondo cui un container deve decapitare le proprie richieste di risorse di sistema e trasmetterle alla piattaforma. Avendo i profili delle risorse di ogni container (quante risorse CPU, memoria, rete e storage necessitano), la piattaforma può gestire in modo ottimale il dispatching e l'auto-scalabilità, gestire le capacità IT e mantenere i livelli SLA per i container.
Oltre a soddisfare le richieste di risorse del container, è fondamentale che l'applicazione non superi i limiti stabiliti dallo stesso. Altrimenti, in caso di carenza di risorse, la piattaforma avrà maggiore probabilità di includerla nell'elenco delle applicazioni da interrompere o migrare.
Parlando di cloud-oriented, intendiamo principalmente il modo di operare.
Abbiamo delineato sopra una serie di principi generali che stabiliscono le basi metodologiche per costruire applicazioni container di qualità per ambienti cloud.
È importante notare che, oltre a questi principi generali, avrete bisogno di metodi e tecniche avanzate specifiche per lavorare con i contenitori. Inoltre, abbiamo alcune raccomandazioni brevi, più specifiche, che devono essere applicate (o meno) a seconda della situazione:
- Cercate di ridurre la dimensione delle immagini: eliminate i file temporanei e non installate pacchetti non necessari. Minore è la dimensione del contenitore, più rapido sarà il suo assemblaggio e la sua copia sulla destinazione attraverso la rete.
- Utilizzate identificatori utente arbitrari: evitate di usare il comando sudo o identificatori utente privilegiati per eseguire i vostri contenitori.
- Etichettate le porte importanti: i numeri delle porte possono essere definiti anche durante l'esecuzione, ma è meglio specificarli usando il comando EXPOSE – sarà più facile per altri utenti e programmi utilizzare le vostre immagini.
- Conservate i dati permanenti sui volumi: i dati che devono rimanere dopo la rimozione del contenitore devono essere registrati sui volumi.
- Annotate i metadati dell'immagine: tag, etichette e annotazioni facilitano l'uso delle immagini – altri sviluppatori vi saranno grati.
- Sincronizza host e immagini: alcune applicazioni container richiedono la sincronizzazione del contenitore con l'host in base ad attributi specifici, come l'ora o l'identificativo della macchina.
- In conclusione, condividiamo modelli e best practice 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
