Questa è la prima pubblicazione di una serie di materiali dedicati ai cambiamenti, miglioramenti e aggiunte nel prossimo aggiornamento della piattaforma Red Hat OpenShift fino alla versione 4.0, che aiuteranno a prepararsi al passaggio alla nuova versione.
Sin dal momento in cui i rappresentanti di una comunità di Kubernetes in fase di formazione si sono riuniti nell'autunno del 2014 presso l'ufficio di Google a Seattle, si è potuto intuire che il progetto Kubernetes avrebbe radicalmente cambiato i moderni approcci allo sviluppo e all'implementazione del software. Allo stesso tempo, i fornitori di servizi cloud pubblici continuavano a investire attivamente nello sviluppo di infrastrutture e servizi, il che ha notevolmente semplificato e reso più accessibile il lavoro con la tecnologia IT e la creazione di software, rendendoli incredibilmente fruibili, qualcosa che pochi avrebbero potuto immaginare all'inizio del decennio.
Certo, l'annuncio di ogni nuovo servizio cloud è stato accompagnato da numerosi dibattiti tra esperti su Twitter, affrontando i più svariati argomenti: dalla fine dell'era del codice sorgente aperto, al declino dell'IT on-premises, all'inevitabilità di un nuovo monopolio software nel cloud, e come la nuova parodia X sostituirà tutte le altre.
Non è necessario dire che tutte queste discussioni erano piuttosto stupide.
La realtà è che nulla scomparirà e oggi possiamo osservare una crescita esponenziale dei prodotti finali e dei modi per svilupparli, dovuta alla continua comparsa di nuovi software nella nostra vita. E nonostante tutto intorno a noi cambierà, il fondamento rimarrà invariato. Gli sviluppatori continueranno a scrivere codice con errori, gli ingegneri delle operazioni e gli specialisti della affidabilità continueranno a portare i pager e a ricevere notifiche automatiche su Slack, i manager continueranno a operare con i concetti di OpEx e CapEx, e ogni volta che si verifica un guasto, il senior developer sospirerà tristemente dicendo: "Te l'avevo detto"...
Cosa dovremmo realmente discutere, quindi questi sono gli strumenti che possiamo avere a nostra disposizione per creare prodotti software di qualità superiore e come questi consentano di aumentare la sicurezza e rendere lo sviluppo più semplice e affidabile. Con l'aumento della complessità dei progetti emergono nuovi rischi e oggi le vite delle persone dipendono così tanto dal software che gli sviluppatori sono obbligati a cercare di fare il loro lavoro meglio.
Kubernetes è uno di questi strumenti. Si sta lavorando per integrarlo con altri strumenti e servizi all'interno di Red Hat OpenShift in una piattaforma unica, che consentirebbe di rendere il software più affidabile, facile da gestire e sicuro per gli utenti.
Detto ciò, il team di OpenShift si pone una semplice domanda:
Come possiamo rendere l'utilizzo di Kubernetes più semplice e conveniente?
La risposta è sorprendentemente ovvia:
- automatizzare i momenti complessi nel deployment su cloud o on-premise;
- concentrarsi sull'affidabilità, nascondendo al contempo la complessità;
- continuare a rilasciare aggiornamenti semplici e sicuri in modo costante;
- raggiungere il controllo e la possibilità di audit;
- puntare a garantire fin dall'inizio un'elevata sicurezza, senza compromettere l'usabilità.
La prossima versione di OpenShift deve considerare sia l'esperienza degli sviluppatori che quella di altri sviluppatori che implementano software su larga scala nelle più grandi aziende del mondo. Inoltre, deve tenere conto di tutta l'esperienza accumulata delle ecosistemi open source che oggi sono alla base del mondo moderno. È fondamentale abbandonare il vecchio modo di pensare del programmatore dilettante e adottarne uno nuovo, orientato verso un futuro automatizzato. Questo deve costituire un 'ponte' tra i vecchi e i nuovi metodi di distribuzione del software, sfruttando appieno tutta l'infrastruttura disponibile, indipendentemente dal fatto che sia gestita dal più grande fornitore di servizi cloud o eseguita su piccole unità periferiche.
Come si possono ottenere questi risultati?
In Red Hat, it is customary to engage in tedious and thankless work for extended periods to maintain the established community and prevent the closure of projects in which the company is involved. The open-source community is filled with countless talented developers who create extraordinary things—entertaining, educational, groundbreaking, and simply beautiful—but, of course, no one expects all participants to move in the same direction or pursue common goals. Harnessing this energy and redirecting it as needed is sometimes essential for developing areas that would benefit our users, while we must also monitor the evolution of our communities and learn from them.
All'inizio del 2018, Red Hat ha acquisito il progetto CoreOS, che condivideva visioni simili per il futuro: un ambiente più sicuro e affidabile, costruito sui principi dell'open-source. L'azienda ha lavorato per sviluppare ulteriormente queste idee e realizzarle, incarnando la nostra filosofia di mirare a un funzionamento sicuro di tutto il software. Tutto questo si basa su Kubernetes, Linux, cloud pubblici, cloud privati e migliaia di altri progetti che formano la nostra moderna ecosistema digitale.
La nuova versione di OpenShift 4 sarà intuitiva, automatizzata 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, container (che sono fondamentalmente semplici immagini Linux).
La piattaforma deve essere sicura fin dall'inizio, ma deve anche garantire la possibilità di iterazioni semplici per gli sviluppatori, ovvero deve possedere una sufficiente flessibilità e affidabilità, consentendo comunque agli amministratori di effettuare audit e garantire una gestione agevole.
Deve consentire l'esecuzione del 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 sarà necessario districarsi tra le complessità delle impostazioni hardware e software, e tutte le complicazioni casuali appartengono al passato.
OpenShift 4: una piattaforma NoOps, che non richiede manutenzione.
In Si descrive come le sfide affrontate hanno aiutato a plasmare la visione dell'azienda riguardo a OpenShift 4. Il team ha l'obiettivo di semplificare al massimo le operazioni quotidiane di gestione e supporto del software, rendendo questi processi facili e informali sia per gli specialisti dell'implementazione che per gli sviluppatori. Ma come si può avvicinarsi a questo obiettivo? Come creare una piattaforma per eseguire software che richieda un intervento minimo? Cosa significa realmente NoOps in questo contesto?
Se si cerca di astrarsi, per gli sviluppatori i concetti di «serverless» o «NoOps» significano strumenti e servizi che consentono di nascondere la componente operativa o di minimizzare questo onere per lo sviluppatore.
- Lavorate non con i sistemi, ma con le interfacce applicative (API).
- Non occuperetevi dell'implementazione del software - lasciate che sia il provider a farlo.
- Non dovresti lanciarti subito nella creazione di un grande framework: inizia scrivendo piccoli frammenti che fungono da "elementi costitutivi". Cerca di far sì che questo codice lavori con dati ed eventi, e non con dischi e basi di dati.
Il compito, come sempre, è quello di accelerare le iterazioni nello sviluppo software, garantendo la possibilità di creare prodotti di qualità superiore, mentre il sviluppatore non deve preoccuparsi dei sistemi su cui il suo software verrà eseguito. Un sviluppatore esperto sa benissimo che, se ci si concentra sugli utenti, la situazione può cambiare rapidamente. Pertanto, non dovresti investire troppe energie nella scrittura di software se non sei assolutamente certo della sua necessità.
Per i professionisti impegnati nel supporto e nell'operatività, la parola "NoOps" può suonare un po' spaventosa. Tuttavia, durante le conversazioni con gli ingegneri operativi diventa evidente che i modelli e le tecniche che utilizzano per garantire la robustezza del sistema (Site Reliability Engineering, SRE) riflettono in gran parte i modelli descritti sopra:
- Non gestire i sistemi: automatizza i processi di gestione.
- Non occuparti dell'implementazione software: crea un pipeline per il suo deployment.
- Cerca di non unire tutti i tuoi servizi insieme e non lasciare che il guasto di uno di essi porti al fallimento dell'intero sistema: distribuiscili attraverso l'infrastruttura, utilizzando strumenti di automazione, e collegali prevedendo la possibilità di monitoraggio e controllo.
Gli esperti di SRE sanno che qualcosa potrebbe andare storto e dovranno monitorare e risolvere il problema: per questo automatiscono il lavoro di routine e definiscono in anticipo le tolleranze accettabili (error budgets) per essere pronti a stabilire priorità e prendere decisioni quando si presenta un problema.
Kubernetes su OpenShift è una piattaforma progettata per affrontare due compiti principali: invece di costringerti a gestire macchine virtuali o API dei bilanciatori di carico, si lavora con astrazioni di ordine superiore – processi di distribuzione e servizi. Invece di installare agenti software, è possibile eseguire contenitori, e invece di scrivere un proprio stack di monitoraggio, si utilizzano gli strumenti già disponibili nella piattaforma. Infatti, l'ingrediente segreto di OpenShift 4 non è affatto un mistero – basta basarsi sui principi SRE e sui concetti serverless e portarli a compimento, a beneficio di sviluppatori e ingegneri di operazioni.
- Automatizzare e standardizzare l'infrastruttura utilizzata dalle applicazioni
- Collegare i processi di deployment e sviluppo senza limitare gli sviluppatori stessi
- Assicurarsi che avviare, auditare e garantire la sicurezza del centesimo servizio, funzione, applicazione o intero stack sia altrettanto semplice quanto per il primo.
Ma qual è la differenza tra la piattaforma OpenShift 4 e le sue predecessori, così come con l'approccio "standard" per risolvere tali problemi? Come si raggiunge la scalabilità per i team che si occupano dell'implementazione e della gestione? La risposta è che il re in questa situazione è il cluster. Quindi,
- Facciamo in modo che lo scopo dei cluster sia chiaro (Cloud costoso, ho creato questo cluster perché ho potuto)
- Le macchine e i sistemi operativi esistono per servire il cluster (Vostra Maestà)
- Gestite lo stato degli host dal cluster, minimizzate le loro derivazioni (drift).
- Per ogni elemento importante del sistema è necessaria una 'babysitter' (meccanismo) che monitori e risolva i problemi
- Il fallimento *di ogni* aspetto o elemento del sistema e i meccanismi di ripristino corrispondenti sono parte normale della vita
- L'intera 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 sono necessari più di un clic del mouse, evidentemente stiamo facendo qualcosa di sbagliato.
- Il monitoraggio e il debug di qualsiasi componente non dovrebbero mai essere un problema, e di conseguenza, anche il monitoraggio e la reportistica di tutta l'infrastruttura devono essere semplici e pratici.
Vuoi vedere le potenzialità della piattaforma in azione?
La versione preliminare di OpenShift 4 è ora disponibile per gli sviluppatori. Con un installatore facile da usare, puoi avviare un cluster su AWS sopra Red Hat CoreOS. Per utilizzare la versione preliminare è necessario solo un account AWS per fornire l'infrastruttura e un insieme di account per accedere alle immagini della versione preliminare.
- Per iniziare, visita e fai clic su “Get Started”.
- Accedi al tuo account Red Hat (o creane uno nuovo) e segui le istruzioni per impostare il tuo primo cluster.
Dopo un'installazione riuscita, dai un'occhiata ai nostri materiali di formazione , per avere una comprensione più approfondita dei sistemi e dei concetti che rendono 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ù semplice possibile – il futuro del NoOps inizia oggi.
E ora attenzione!
Alla conferenza Il 20 aprile, uno degli sviluppatori di OpenShift, Vadim Rutkovskiy, terrà un masterclass – romperà dieci cluster e ci farà riparare. La conferenza è a pagamento, ma con il codice promozionale #RedHat si ha uno sconto del 37%.
Il masterclass si terrà dalle 17:15 alle 18:15, mentre lo stand sarà aperto tutto il giorno. Magliette, cappelli, adesivi – come al solito!
Sala #2
«Dobbiamo cambiare completamente il sistema: ripareremo cluster k8s rotti insieme a fabbri certificati».
Fonte: habr.com
