Questa è la prima pubblicazione di una serie di materiali dedicati alle modifiche, ai miglioramenti e alle integrazioni nella prossima versione della piattaforma Red Hat OpenShift 4.0, che aiuteranno a prepararsi al passaggio alla nuova versione.
Fin dal momento in cui i rappresentanti della comunità Kubernetes, allora in fase di formazione, si sono riuniti per la prima volta nell'autunno del 2014 nell'ufficio di Google a Seattle, era chiaro che il progetto Kubernetes era destinato a trasformare radicalmente gli approcci moderni allo sviluppo e all'implementazione del software. Nel frattempo, i fornitori di servizi cloud pubblici continuavano a investire attivamente nello sviluppo di infrastrutture e servizi, semplificando notevolmente il lavoro con l'IT e la creazione di software, rendendoli incredibilmente accessibili, cosa che pochi avrebbero potuto immaginare all'inizio del decennio.
È evidente che l'annuncio di ogni nuovo servizio cloud è stato accompagnato da numerosi dibattiti tra esperti su Twitter, con discussioni su una vasta gamma di argomenti – tra cui la fine dell'era del codice sorgente aperto, il declino dell'IT on-premises, l'inevitabilità di un nuovo monopolio del software nel cloud e come la nuova paradigmatica X sostituirà tutte le altre paradigmatiche.
È inutile dire che tutti questi dibattiti erano piuttosto stupidi
La realtà è che nulla scompare davvero, e oggi possiamo osservare una crescita esponenziale dei prodotti finali e dei modi per svilupparli, collegata alla continua comparsa di nuovo software nelle nostre vite. E nonostante tutto ciò che ci circonda stia cambiando, in sostanza tutto rimarrà invariato. I programmatori continueranno a scrivere codice con errori, gli ingegneri delle operazioni e gli esperti di affidabilità continueranno a portare i pager e a ricevere avvisi automatici su Slack, i manager continueranno a parlare di OpEx e CapEx, e ogni volta che si verifica un guasto, il programmatore senior sospirerà tristemente dicendo: 'L'ho detto'...
Ciò che davvero dovrebbe essere discusso, quindi è ciò che possiamo ottenere a nostra disposizione per creare prodotti software di qualità superiore, e come questi strumenti ci consentono di migliorare la sicurezza e rendere lo sviluppo più semplice e affidabile. Con l'aumento della complessità dei progetti emergono anche nuovi rischi, e oggi le vite delle persone dipendono così tanto dal software che i programmatori sono obbligati a cercare di fare meglio il proprio lavoro.
Kubernetes è uno di questi strumenti. Si sta lavorando per integrare questo strumento con altri strumenti e servizi all'interno di Red Hat OpenShift, creando una piattaforma unica in grado di rendere il software più affidabile, facile da gestire e sicuro per gli utenti.
Tenendo conto di quanto detto, il team di OpenShift si pone una domanda semplice:
Come possiamo rendere più semplice e comoda l'interazione con Kubernetes?
La risposta è sorprendentemente ovvia:
- automatizzare i momenti complessi nel deployment in cloud o on-premise;
- concentrarsi sulla resilienza, nascondendo nel contempo la complessità;
- continuare a rilasciare aggiornamenti semplici e sicuri in modo costante;
- garantire controllabilità e possibilità di audit;
- puntare sin dall'inizio a garantire un'elevata sicurezza, senza compromettere l'usabilità.
La prossima versione di OpenShift deve considerare sia l'esperienza dei creatori sia l'esperienza di altri sviluppatori, che implementano il software su larga scala nelle più grandi aziende del mondo. Inoltre, deve tenere conto dell'esperienza accumulata delle ecosistemi aperti, che oggi sono alla base del mondo moderno. È necessario abbandonare la mentalità del programmatore amatoriale e passare a una nuova filosofia di futuro automatizzato. Deve essere un 'ponte' tra i vecchi e i nuovi metodi di deployment del software e sfruttare appieno l'intera infrastruttura disponibile, che sia gestita da un grande fornitore di cloud o eseguita su piccole macchine ai margini.
Come ottenere questo risultato?
In Red Hat è consuetudine eseguire a lungo lavori noiosi e ingrati per mantenere la comunità consolidata e prevenire la chiusura dei progetti a cui l'azienda partecipa. Nella comunità open source si trova un enorme numero di sviluppatori talentuosi che creano le cose più straordinarie: divertenti, educative, che aprono nuove possibilità e semplicemente belle, ma, ovviamente, nessuno si aspetta che tutti i partecipanti si muovano nella stessa direzione o perseguano obiettivi comuni. Utilizzare questa energia, reindirizzarla nella giusta direzione è talvolta necessario per sviluppare aree che sarebbero utili ai nostri utenti, ma allo stesso tempo dobbiamo monitorare l'evoluzione delle nostre comunità e imparare da esse.
All'inizio del 2018, Red Hat ha acquisito il progetto CoreOS, che condivideva visioni simili sul futuro: più sicuro e affidabile, basato sui principi dell'open source. L'azienda ha lavorato per ulteriori sviluppi di queste idee e la loro realizzazione, attuando la nostra filosofia: cercando di garantire il funzionamento sicuro di tutto il software. Tutto questo lavoro si basa su Kubernetes, Linux, cloud pubblici, cloud privati e migliaia di altri progetti che stanno alla base del nostro moderno ecosistema digitale.
Il nuovo rilascio di OpenShift 4 sarà comprensibile, automatizzato e più naturale.
La piattaforma OpenShift funzionerà con i migliori e più affidabili sistemi operativi Linux, con supporto hardware bare-metal, virtualizzazione conveniente, programmazione automatica dell'infrastruttura e, naturalmente, con container (che sono essenzialmente immagini Linux).
La piattaforma deve essere sicura fin dall'inizio, ma deve anche garantire la possibilità di iteration convenienti per gli sviluppatori, cioè possedere sufficiente flessibilità e affidabilità, permettendo comunque agli amministratori di effettuare audit e garantendo facilità nella gestione.
Deve consentire di eseguire software "come servizio" e non portare a un'espansione incontrollata dell'infrastruttura per gli operatori.
Permetterà agli sviluppatori di concentrarsi sulla creazione di prodotti reali per gli utenti e i clienti. Non dovranno districarsi tra le complessità delle configurazioni hardware e software, e tutte le complicazioni casuali rimarranno nel passato.
OpenShift 4: Piattaforma NoOps, che non richiede manutenzione
In sono state descritte quelle sfide che hanno contribuito a formare la visione dell'azienda riguardo a OpenShift 4. Il team ha il compito di semplificare al massimo le operazioni quotidiane di gestione e manutenzione del software, rendendo questi processi facili e senza sforzo – sia per i professionisti che si occupano dell'implementazione, sia per gli sviluppatori. Ma in che modo si può avvicinarsi a questo obiettivo? Come creare una piattaforma per l'esecuzione del software che richieda il minimo intervento? Cosa significa realmente NoOps in questo contesto?
Se si cerca di astrarsi, per gli sviluppatori i concetti di «serverless» o «NoOps» rappresentano strumenti e servizi che consentono di nascondere l'aspetto «operativo» o di minimizzare questo onere per lo sviluppatore.
- Lavorate non con i sistemi, ma con le interfacce applicative (API).
- Non occupatevi dell'implementazione del software – lasciate che sia il provider a farlo.
- Non bisogna iniziare subito a creare un grande framework – iniziate scrivendo piccoli frammenti che fungeranno da «mattoni», cercate di far sì che questo codice lavori con dati ed eventi, e non con dischi e database.
L'obiettivo, come sempre, è quello di accelerare le iterazioni nello sviluppo del software, consentendo la creazione di prodotti di qualità superiore, e affinché lo sviluppatore possa non preoccuparsi dei sistemi su cui viene eseguito il suo software. Un sviluppatore esperto sa bene che se ci si concentra sugli utenti, la situazione può cambiare rapidamente, quindi non è opportuno investire troppe energie nella scrittura del software se non si è certi della sua necessità.
Per i professionisti coinvolti nel supporto e nella gestione, la parola «NoOps» può sembrare piuttosto spaventosa. Ma durante le conversazioni con gli ingegneri operativi diventa chiaro che i modelli e le metodologie che utilizzano per garantire l'affidabilità (Site Reliability Engineering, SRE) sono in molti aspetti in sintonia con i modelli descritti sopra:
- Non gestire i sistemi: automatizza i processi di gestione.
- Non occuparti dell'implementazione del software: crea un pipeline per il suo deployment.
- Cerca di non unire tutti i tuoi servizi insieme e non permettere che il guasto di uno di essi porti al guasto dell'intero sistema: distribuiscili in tutta l'infrastruttura, utilizzando strumenti di automazione, e collegali prevedendo la possibilità di controllo e monitoraggio.
Gli specialisti SRE sanno che qualcosa potrebbe andare storto e che dovranno monitorare e risolvere il problema: per questo automatizzano il lavoro di routine e definiscono in anticipo le tolleranze ammissibili (error budgets), per essere pronti a fare prioritizzazioni e prendere decisioni in caso di problemi.
Kubernetes su OpenShift è una piattaforma progettata per risolvere due principali compiti: invece di costringerti a districarti tra macchine virtuali o API dei bilanciatori di carico, si lavora su astrazioni di ordine superiore – sui processi di deployment e sui servizi. Invece di installare agenti software, puoi avviare contenitori, e invece di scrivere il tuo stack di monitoraggio, utilizzare gli strumenti già disponibili nella piattaforma. Così facendo, l'ingrediente segreto di OpenShift 4 non è poi così misterioso: basta prendere a riferimento i principi SRE e le concettualità serverless, e portarli a compimento, a beneficio di sviluppatori e ingegneri operativi:
- Automatizzare e standardizzare l'infrastruttura utilizzata dalle applicazioni.
- Collegare i processi di deployment e sviluppo, senza limitare i programmatori.
- Assicurarsi che l'avvio, l'audit e la sicurezza del centesimo servizio, funzione, applicazione o intero stack non siano affatto più complessi di quelli del primo.
Ma qual è la differenza tra la piattaforma OpenShift 4 e i suoi predecessori e l'approccio "standard" per risolvere problemi simili? Come si raggiunge la scalabilità per i team che si occupano di implementazione e gestione? Perché il vero protagonista in questa situazione è il cluster. Quindi,
- Facciamo in modo che la funzione dei cluster sia chiara (Cloud costoso, questo cluster l'ho creato perché ho potuto)
- Le macchine e i sistemi operativi esistono per servire il cluster (Vostro Maestà)
- Gestisci lo stato degli host dal cluster, minimizza le loro deviazioni (drift).
- Per ciascun elemento importante del sistema è necessaria una babysitter (meccanismo) che monitora e risolve i problemi.
- Il guasto *di ogni* aspetto o elemento del sistema prevede i meccanismi di ripristino — è una parte normale della vita.
- Tutta l'infrastruttura deve essere configurata tramite API.
- Usa Kubernetes per eseguire Kubernetes. (Sì, non è un errore di battitura)
- Gli aggiornamenti devono essere installati facilmente e senza sforzo. Se per installare un aggiornamento servono più di un clic, evidentemente stiamo facendo qualcosa di sbagliato.
- Il monitoraggio e il debug di qualsiasi componente non devono essere problematici e, di conseguenza, anche il tracciamento e la redazione di report sull'intera infrastruttura devono essere semplici e comodi.
Vuoi vedere le potenzialità della piattaforma in azione?
La versione beta di OpenShift 4 è diventata disponibile per gli sviluppatori. Con un installatore facile da usare, è possibile avviare un cluster su AWS su Red Hat CoreOS. Per usufruire della versione beta è solo necessaria un'account AWS per fornire l'infrastruttura e un insieme di account per accedere alle immagini della beta.
- Per iniziare, visita e fai clic su "Inizia".
- Accedi al tuo account Red Hat (o creane uno nuovo) e segui le istruzioni per configurare il tuo primo cluster.
Dopo un'installazione riuscita, consulta il nostro materiale formativo , per avere una visione più dettagliata dei sistemi e dei concetti che rendono la piattaforma OpenShift 4 uno strumento così semplice e pratico per avviare Kubernetes.
Prova la nuova versione di OpenShift e condividi la tua opinione. Ci impegniamo a rendere l'uso di Kubernetes il più accessibile e senza sforzo possibile: il futuro del NoOps inizia oggi stesso.
E ora attenzione!
Alla conferenza Il 20 aprile, uno degli sviluppatori di OpenShift, Vadim Rutkovsky, terrà un masterclass — distruggerà dieci cluster e li farà riparare. La conferenza è a pagamento, ma con il codice promozionale #RedHat si ottiene uno sconto del 37%.
Il masterclass si svolgerà dalle 17:15 alle 18:15, mentre lo stand sarà aperto tutto il giorno. Magliette, cappelli, adesivi — come al solito!
Sala #2
«Dobbiamo cambiare l'intero sistema: riparare i cluster k8s rotti insieme a tecnici certificati».
Fonte: habr.com
