Le applicazioni “cloud native” o semplicemente “cloud” sono create appositamente per funzionare nelle infrastrutture cloud. Sono generalmente realizzati come un insieme di microservizi liberamente accoppiati racchiusi in contenitori, che a loro volta sono gestiti da una piattaforma cloud. Tali applicazioni sono predisposte ai guasti per impostazione predefinita, il che significa che funzionano in modo affidabile e scalano anche in caso di gravi guasti a livello di infrastruttura. L’altra faccia della medaglia sono gli insiemi di vincoli (contratti) che la piattaforma cloud impone alle applicazioni container per poterle gestire in modo automatico.
Pur essendo pienamente consapevoli della necessità e dell'importanza del passaggio ad applicazioni basate su cloud, molte organizzazioni non sanno ancora da dove cominciare. In questo post esamineremo una serie di principi che, se seguiti durante lo sviluppo di applicazioni containerizzate, consentiranno di realizzare il potenziale delle piattaforme cloud e ottenere un funzionamento affidabile e un dimensionamento delle applicazioni anche in caso di gravi guasti all'infrastruttura IT. livello. L'obiettivo finale dei principi qui delineati è imparare come 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 durante lo sviluppo del software. Possono essere utilizzati quando si lavora con qualsiasi linguaggio di programmazione. Ogni principio ha i propri obiettivi, gli strumenti per raggiungerli sono solitamente modelli e pratiche. Esistono inoltre una serie di principi fondamentali per la creazione di software di alta qualità, da cui derivano tutti gli altri. Ecco alcuni esempi di principi fondamentali:
- (Mantienilo semplice, stupido) – non complicarlo;
- (Non ripeterti) - non ripeterti;
- (Non ne avrai bisogno) - non creare qualcosa che non sia immediatamente necessario;
- Separazione delle preoccupazioni – condivisione delle responsabilità.
Come potete vedere, questi principi non fissano regole specifiche, ma appartengono alla categoria delle cosiddette considerazioni di buon senso basate sull'esperienza pratica, che sono condivise da molti sviluppatori e alle quali fanno regolarmente riferimento.
Inoltre, c'è – Un insieme dei primi cinque principi della programmazione e della progettazione orientata agli oggetti, formulati da Robert Martin. SOLID include principi ampi, aperti e complementari che, se applicati insieme, aiutano a creare sistemi software migliori e a mantenerli meglio a lungo termine.
I principi SOLID appartengono al campo dell'OOP e sono formulati nel linguaggio di concetti e concetti come classi, interfacce ed ereditarietà. Per analogia, i principi di sviluppo possono essere formulati anche per le applicazioni cloud, solo che qui l'elemento base non sarà una classe, ma un contenitore. Seguendo questi principi, puoi creare applicazioni containerizzate che soddisfano meglio gli scopi e gli obiettivi delle piattaforme cloud come Kubernetes.
Contenitori cloud-native: l'approccio Red Hat
Oggi quasi tutte le applicazioni possono essere inserite in contenitori con relativa facilità. Ma affinché le applicazioni siano automatizzate e orchestrate in modo efficace all’interno di una piattaforma cloud come Kubernetes, è necessario uno sforzo aggiuntivo.
La base per le idee delineate di seguito è stata la 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 solo allo sviluppo di applicazioni containerizzate basate su microservizi e progettate per piattaforme cloud come Kubernetes. L'elemento di base nella nostra discussione è l'immagine del contenitore e il runtime del contenitore di destinazione è la piattaforma di orchestrazione del contenitore. L'obiettivo dei principi proposti è creare contenitori per i quali le attività di pianificazione, ridimensionamento e monitoraggio possano essere automatizzate sulla maggior parte delle piattaforme di orchestrazione. I principi sono presentati senza un ordine particolare.
Principio di singola preoccupazione (SCP)
Questo principio è per molti versi simile al principio di responsabilità unica. ), che fa parte del set SOLID e afferma che ogni oggetto deve avere una responsabilità e che la responsabilità deve essere completamente incapsulata in una classe. Il punto dell’SRP è che ogni responsabilità è motivo di cambiamento e una classe deve avere una e una sola ragione per cambiare.
In SCP usiamo la parola “preoccupazione” invece della parola “responsabilità” per indicare il livello più elevato di astrazione e lo scopo più ampio di un contenitore rispetto a una classe OOP. E se l’obiettivo dell’SRP è avere una sola ragione per il cambiamento, allora dietro l’SCP c’è il desiderio di espandere la capacità di riutilizzare e sostituire i contenitori. Seguendo l'SRP e creando un contenitore che risolva un singolo problema e lo faccia in modo funzionalmente completo, si aumentano le possibilità di riutilizzare quell'immagine del contenitore in diversi contesti applicativi.
Il principio SCP afferma che ogni contenitore dovrebbe risolvere un singolo problema e farlo bene. Inoltre, l’SCP nel mondo dei container è più facile da ottenere rispetto all’SRP nel mondo dell’OOP, poiché i container solitamente eseguono un singolo processo e nella maggior parte dei casi questo processo risolve un singolo compito.
Se un microservizio contenitore deve risolvere più problemi contemporaneamente, può essere suddiviso in contenitori con attività singola e combinato all'interno di un pod (un'unità di distribuzione della piattaforma contenitore) utilizzando modelli di contenitore sidecar e init. Inoltre, SCP semplifica la sostituzione di un vecchio contenitore (come un server Web o un broker di messaggi) con uno nuovo che risolve lo stesso problema ma ha funzionalità estese o scalabilità migliori.
Principio di alta osservabilità (HOP)
Quando i contenitori vengono utilizzati come modo unificato per creare pacchetti ed eseguire applicazioni, le applicazioni stesse vengono trattate come una scatola nera. Tuttavia, se si tratta di contenitori cloud, allora devono fornire API speciali al runtime per monitorare lo stato dei contenitori e, se necessario, intraprendere le azioni appropriate. Senza questo, non sarà possibile unificare l'automazione dell'aggiornamento dei contenitori e della gestione del loro ciclo di vita, il che, a sua volta, peggiorerà la stabilità e l'usabilità del sistema software.
In pratica, un'applicazione containerizzata dovrebbe, come minimo, avere un'API per vari tipi di controlli di integrità: test di attività e test di disponibilità. Se un'applicazione pretende di fare di più, deve fornire altri mezzi per monitorare il suo stato. Ad esempio, registrazione di eventi importanti tramite STDERR e STDOUT per l'aggregazione dei log utilizzando Fluentd, Logstash e altri strumenti simili. Oltre all'integrazione con librerie di raccolta di tracciamenti e metriche, come OpenTracing, Prometheus, ecc.
In generale l’applicazione può comunque essere trattata come una scatola nera, ma deve essere dotata di tutte le API di cui la piattaforma ha bisogno per poterla monitorare e gestire al meglio.
Principio di conformità del ciclo di vita (LCP)
LCP è l'antitesi di HOP. Mentre HOP afferma che il contenitore deve esporre le API di lettura alla piattaforma, LCP richiede che l'applicazione sia in grado di accettare informazioni dalla piattaforma. Inoltre il contenitore non deve solo recepire gli eventi, ma anche adattarsi, cioè reagire ad essi. Da qui il nome del principio, che può essere considerato come un requisito per dotare la piattaforma di API di scrittura.
Le piattaforme hanno diversi tipi di eventi per aiutare a gestire il ciclo di vita di un contenitore. Ma spetta all'applicazione stessa decidere quali percepire e come reagire.
È chiaro che alcuni eventi sono più importanti di altri. Ad esempio, se un'applicazione non tollera bene i crash, deve accettare i messaggi signal: terminate (SIGTERM) e avviare la routine di terminazione il più rapidamente possibile per catturare il signal: kill (SIGKILL) che viene dopo SIGTERM.
Inoltre, eventi come PostStart e PreStop possono essere importanti per il ciclo di vita di un'applicazione. Ad esempio, dopo aver avviato un'applicazione, potrebbe essere necessario un po' di tempo di riscaldamento prima di poter rispondere alle richieste. Oppure l'applicazione deve rilasciare risorse in qualche modo speciale durante la chiusura.
Il principio di immutabilità dell’immagine (IIP)
È generalmente accettato che le applicazioni containerizzate rimangano invariate dopo essere state create, anche se vengono eseguite in ambienti diversi. Ciò implica la necessità di esternalizzare l'archiviazione dei dati in fase di runtime (in altre parole, di utilizzare strumenti esterni per questo) e di fare affidamento su configurazioni esterne specifiche del runtime, piuttosto che modificare o creare contenitori unici per ciascun ambiente. Dopo qualsiasi modifica all'applicazione, l'immagine del contenitore deve essere ricostruita e distribuita in tutti gli ambienti utilizzati. A proposito, quando si gestiscono i sistemi IT viene utilizzato un principio simile, noto come principio di immutabilità dei server e dell'infrastruttura.
L'obiettivo di IIP è impedire la creazione di immagini di contenitori separate per ambienti di runtime diversi e utilizzare la stessa immagine ovunque insieme alla configurazione specifica dell'ambiente appropriata. Seguire questo principio consente di implementare pratiche importanti dal punto di vista dell'automazione dei sistemi cloud come il rollback e il rollforward degli aggiornamenti delle applicazioni.
Principio di eliminabilità del processo (PDP)
Una delle caratteristiche più importanti di un contenitore è la sua effimerità: un'istanza di un contenitore è facile da creare e facile da distruggere, quindi può essere facilmente sostituita con un'altra istanza in qualsiasi momento. Possono esserci molte ragioni per tale sostituzione: fallimento di un test di funzionalità, ridimensionamento dell'applicazione, trasferimento su un altro host, esaurimento delle risorse della piattaforma o altre situazioni.
Di conseguenza, le applicazioni containerizzate devono mantenere il loro stato utilizzando alcuni mezzi esterni o utilizzare schemi distribuiti interni con ridondanza per questo. Inoltre, l'applicazione deve avviarsi e arrestarsi rapidamente ed essere preparata a guasti hardware improvvisi e fatali.
Una pratica che aiuta a implementare questo principio è mantenere i contenitori piccoli. Gli ambienti cloud possono selezionare automaticamente un host su cui avviare un'istanza di contenitore, quindi più piccolo è il contenitore, più velocemente verrà avviato: verrà semplicemente copiato sull'host di destinazione sulla rete più velocemente.
Principio di autocontenimento (S-CP)
Secondo questo principio, in fase di assemblaggio, tutti i componenti necessari sono inclusi nel contenitore. Il contenitore dovrebbe essere costruito partendo dal presupposto che il sistema abbia solo un kernel Linux puro, quindi tutte le librerie aggiuntive necessarie dovrebbero essere inserite nel contenitore stesso. Dovrebbe contenere anche elementi come il runtime per il linguaggio di programmazione corrispondente, la piattaforma dell'applicazione (se necessario) e altre dipendenze che saranno necessarie durante l'esecuzione dell'applicazione contenitore.
Sono previste eccezioni per le configurazioni che variano da ambiente a ambiente e devono essere fornite in fase di runtime, ad esempio tramite Kubernetes ConfigMap.
Un'applicazione può includere diversi componenti containerizzati, ad esempio un contenitore DBMS separato all'interno di un'applicazione web containerizzata. Secondo il principio S-CP, questi contenitori non dovrebbero essere combinati in uno solo, ma dovrebbero essere realizzati in modo tale che il contenitore DBMS contenga tutto il necessario per il funzionamento del database e il contenitore dell'applicazione web contenga tutto il necessario per il funzionamento del web. applicazione, lo stesso server web. Di conseguenza, in fase di esecuzione il contenitore dell'applicazione Web dipenderà dal contenitore DBMS e vi accederà secondo necessità.
Principio di confinamento del runtime (RCP)
Il principio S-CP definisce come dovrebbe essere costruito il contenitore e cosa dovrebbe contenere l'immagine binaria. Ma un contenitore non è solo una “scatola nera” che ha una sola caratteristica: la dimensione del file. Durante l'esecuzione, il contenitore assume altre dimensioni: la quantità di memoria utilizzata, il tempo della CPU e altre risorse di sistema.
E qui torna utile il principio RCP, secondo il quale il container deve decapitare i suoi fabbisogni di risorse di sistema e trasferirli sulla piattaforma. Con i profili delle risorse di ciascun container (quantità di CPU, memoria, rete e risorse disco necessarie), la piattaforma può eseguire in modo ottimale la pianificazione e la scalabilità automatica, gestire la capacità IT e mantenere i livelli di SLA per i container.
Oltre a soddisfare i requisiti di risorse del contenitore, è anche importante che l'applicazione non vada oltre i propri confini. Altrimenti, quando si verifica una carenza di risorse, è più probabile che la piattaforma la includa nell'elenco delle applicazioni che devono essere terminate o migrate.
Quando parliamo di cloud first, ci riferiamo al modo in cui lavoriamo.
In precedenza, abbiamo formulato una serie di principi generali che stabiliscono le basi metodologiche per la creazione di applicazioni container di alta qualità per ambienti cloud.
Tieni presente che oltre a questi principi generali, avrai bisogno anche di metodi e tecniche avanzati aggiuntivi per lavorare con i contenitori. Inoltre, abbiamo alcune brevi raccomandazioni più specifiche che dovrebbero essere applicate (o non applicate) a seconda della situazione:
- Prova a ridurre la dimensione delle immagini: elimina i file temporanei e non installare pacchetti non necessari: minore è la dimensione del contenitore, più velocemente verrà assemblato e copiato sull'host di destinazione sulla rete.
- Concentrati su ID utente arbitrari: non utilizzare il comando sudo o qualsiasi ID utente speciale per avviare i tuoi contenitori.
- Contrassegna le porte importanti: puoi impostare i numeri di porta in fase di runtime, ma è meglio specificarli utilizzando il comando ESPOSIZIONE: renderà più semplice per altre persone e programmi utilizzare le tue immagini.
- Archiviare dati persistenti sui volumi: i dati che dovrebbero rimanere dopo la distruzione del contenitore dovrebbero essere scritti sui volumi.
- Scrivi metadati delle immagini: tag, etichette e annotazioni rendono le immagini più facili da usare: altri sviluppatori ti ringrazieranno.
- Sincronizza host e immagini: alcune applicazioni containerizzate richiedono che il contenitore si sincronizzi con l'host su determinati attributi, come l'ora o l'ID macchina.
- In conclusione, condividiamo modelli e migliori pratiche che ti aiuteranno a implementare in modo più efficace i principi sopra elencati:
11 giugno alle 11.00
Cosa imparerai:
- Red Hat Enterprise Linux CoreOS immutabile
- Rete di servizi OpenShift
- Quadro degli operatori
- Quadro Knativo
Fonte: habr.com