Questo è il primo di una serie di post sulle modifiche, i miglioramenti e le aggiunte del prossimo aggiornamento Red Hat OpenShift Platform 4.0 che ti aiuteranno a prepararti per la transizione alla nuova versione.
Dal momento in cui la neonata comunità Kubernetes si è riunita per la prima volta presso la sede di Google a Seattle nell'autunno del 2014, è stato chiaro che il progetto Kubernetes era destinato a rivoluzionare il modo in cui il software viene sviluppato e distribuito oggi. Allo stesso tempo, i fornitori di servizi cloud pubblici hanno continuato a investire attivamente nello sviluppo di infrastrutture e servizi, che hanno reso il lavoro con l’IT e la creazione di software molto più semplice e accessibile, e li hanno resi incredibilmente accessibili, cosa che pochi avrebbero potuto immaginare all’inizio del secolo. il decennio.
Naturalmente, l'annuncio di ogni nuovo servizio cloud è stato accompagnato da numerose discussioni tra esperti su Twitter e si sono svolti dibattiti su una varietà di argomenti, tra cui la fine dell'era open source, il declino dell'IT on-premise e l'inevitabilità di un nuovo monopolio del software nel cloud e come il nuovo paradigma X sostituirà tutti gli altri paradigmi.
Inutile dire che tutte queste controversie erano molto stupide
La realtà è che nulla scomparirà e oggi possiamo osservare una crescita esponenziale dei prodotti finali e del modo in cui vengono sviluppati, a causa della costante apparizione di nuovi software nelle nostre vite. E nonostante tutto intorno cambierà, allo stesso tempo, in sostanza, tutto rimarrà invariato. Gli sviluppatori di software continueranno a scrivere codice con errori, gli ingegneri operativi e gli specialisti dell'affidabilità continueranno ad andare in giro con i cercapersone e a ricevere avvisi automatici in Slack, i manager continueranno ad operare in termini di OpEx e CapEx e ogni volta che si verifica un errore, lo sviluppatore senior sospirare tristemente con le parole: “Te l'avevo detto”...
Oh veramente dovrebbe essere discusso, è quali strumenti possiamo avere a nostra disposizione per creare prodotti software migliori e come questi possano migliorare la sicurezza e rendere lo sviluppo più semplice e affidabile. Man mano che i progetti diventano più complessi, emergono nuovi rischi e oggi la vita delle persone dipende così tanto dal software che gli sviluppatori devono semplicemente cercare di svolgere meglio il proprio lavoro.
Kubernetes è uno di questi strumenti. È in corso il lavoro per combinare Red Hat OpenShift con altri strumenti e servizi in un'unica piattaforma che renderebbe il software più affidabile, più facile da gestire e più sicuro per gli utenti.
Detto questo, il team di OpenShift pone una semplice domanda:
Come puoi rendere il lavoro con Kubernetes più semplice e conveniente?
La risposta è sorprendentemente ovvia:
- automatizzare aspetti complessi della distribuzione sul cloud o all'esterno del cloud;
- concentrarsi sull'affidabilità nascondendo la complessità;
- continuare a lavorare continuamente per rilasciare aggiornamenti semplici e sicuri;
- ottenere controllabilità e verificabilità;
- sforzarsi di garantire inizialmente un'elevata sicurezza, ma non a scapito dell'usabilità.
La prossima versione di OpenShift dovrebbe tenere conto sia dell'esperienza dei creatori che dell'esperienza di altri sviluppatori che stanno implementando software su larga scala nelle più grandi aziende del mondo. Inoltre, deve tenere conto di tutta l’esperienza accumulata negli ecosistemi aperti che sono alla base del mondo moderno oggi. Allo stesso tempo, è necessario abbandonare la vecchia mentalità dello sviluppatore dilettante e passare a una nuova filosofia di futuro automatizzato. È necessario colmare il divario tra le vecchie e le nuove modalità di distribuzione del software e sfruttare appieno tutta l'infrastruttura disponibile, indipendentemente dal fatto che sia ospitata dal più grande fornitore di servizi cloud o in esecuzione su piccoli sistemi all'edge.
Come ottenere questo risultato?
In Red Hat è consuetudine svolgere a lungo un lavoro noioso e ingrato al fine di preservare la comunità consolidata ed evitare la chiusura di progetti in cui è coinvolta l'azienda. La comunità open source contiene un numero enorme di sviluppatori di talento che creano le cose più straordinarie: divertenti, educative, che aprono nuove opportunità e semplicemente belle, ma, ovviamente, nessuno si aspetta che tutti si muovano nella stessa direzione o perseguano obiettivi comuni . Sfruttare questa energia e reindirizzarla nella giusta direzione è talvolta necessario per sviluppare aree a vantaggio dei nostri utenti, ma allo stesso tempo dobbiamo monitorare lo sviluppo delle nostre comunità e imparare da loro.
All'inizio del 2018, Red Hat ha acquisito il progetto CoreOS, che aveva una visione simile del futuro: più sicuro e affidabile, creato secondo i principi dell'open source. L'azienda ha lavorato per sviluppare ulteriormente queste idee e implementarle, mettendo in pratica la nostra filosofia, cercando di garantire che tutto il software funzioni in modo sicuro. Tutto questo lavoro si basa su Kubernetes, Linux, cloud pubblici, cloud privati e migliaia di altri progetti che sostengono il nostro moderno ecosistema digitale.
La nuova versione di OpenShift 4 sarà chiara, automatizzata e più naturale
La piattaforma OpenShift funzionerà con i migliori e più affidabili sistemi operativi Linux, con supporto hardware bare metal, pratica virtualizzazione, programmazione automatica dell'infrastruttura e, ovviamente, contenitori (che sono essenzialmente solo immagini Linux).
La piattaforma deve essere sicura fin dall'inizio, ma consentire comunque agli sviluppatori di iterare facilmente, ovvero essere sufficientemente flessibile e sicura pur consentendo agli amministratori di controllarla e gestirla facilmente.
Dovrebbe consentire l’esecuzione del software “come servizio” e non portare a una crescita ingestibile delle infrastrutture per gli operatori.
Permetterà agli sviluppatori di concentrarsi sulla creazione di prodotti reali per utenti e clienti. Non dovrai districarti nella giungla delle impostazioni hardware e software e tutte le complicazioni accidentali saranno un ricordo del passato.
OpenShift 4: piattaforma NoOps che non richiede manutenzione
В ha descritto le attività che hanno contribuito a plasmare la visione dell'azienda per OpenShift 4. L'obiettivo del team è semplificare il più possibile le attività quotidiane di utilizzo e manutenzione del software, per rendere questi processi facili e rilassati, sia per gli specialisti coinvolti nell'implementazione che per gli sviluppatori. Ma come avvicinarsi a questo obiettivo? Come creare una piattaforma per l'esecuzione di software che richieda un intervento minimo? Cosa significa NoOps in questo contesto?
Se provi ad astrarre, per gli sviluppatori i concetti di "serverless" o "NoOps" significano strumenti e servizi che consentono di nascondere la componente "operativa" o di ridurre al minimo questo onere per lo sviluppatore.
- Lavora non con i sistemi, ma con le interfacce applicative (API).
- Non preoccuparti di implementare il software: lascia che sia il fornitore a farlo per te.
- Non lanciarti subito nella creazione di un framework di grandi dimensioni: inizia scrivendo piccoli pezzi che fungeranno da "mattoni", prova a far funzionare questo codice con dati ed eventi e non con dischi e database.
L'obiettivo, come prima, è accelerare le iterazioni nello sviluppo del software, offrire l'opportunità di creare prodotti migliori e fare in modo che lo sviluppatore non debba preoccuparsi dei sistemi su cui viene eseguito il suo software. Uno sviluppatore esperto sa bene che concentrarsi sugli utenti può cambiare rapidamente il quadro, quindi non dovresti impegnarti troppo nella scrittura del software a meno che non sei assolutamente sicuro che sia necessario.
Per i professionisti della manutenzione e delle operazioni, la parola “NoOps” può sembrare un po’ spaventosa. Ma quando si comunica con gli ingegneri sul campo, diventa ovvio che i modelli e le tecniche che utilizzano volti a garantire affidabilità e affidabilità (Site Reliability Engineering, SRE) hanno molte somiglianze con i modelli sopra descritti:
- Non gestire i sistemi: automatizza i loro processi di gestione.
- Non implementare software: crea una pipeline per distribuirlo.
- Evita di raggruppare tutti i tuoi servizi insieme e lasciare che il fallimento di uno provochi il fallimento dell'intero sistema: disperdili nell'intera infrastruttura utilizzando strumenti di automazione e collegali in modi che possano essere monitorati e monitorati.
Gli SRE sanno che qualcosa può andare storto e dovranno rintracciare e risolvere il problema, quindi automatizzano il lavoro di routine e impostano in anticipo i budget di errore in modo da essere pronti a stabilire le priorità e prendere decisioni quando si presenta un problema.
Kubernetes in OpenShift è una piattaforma progettata per risolvere due problemi principali: invece di costringerti a comprendere le macchine virtuali o le API del bilanciatore del carico, funziona con astrazioni di ordine superiore: processi e servizi di distribuzione. Invece di installare agenti software, puoi eseguire contenitori e, invece di scrivere il tuo stack di monitoraggio, utilizzare gli strumenti già disponibili nella piattaforma. Quindi, la salsa segreta di OpenShift 4 non è davvero un segreto: è solo questione di prendere i principi SRE e i concetti serverless e portarli alla loro logica conclusione per aiutare gli sviluppatori e gli ingegneri operativi:
- Automatizza e standardizza l'infrastruttura utilizzata dalle applicazioni
- Collega insieme i processi di distribuzione e sviluppo senza limitare gli sviluppatori stessi
- Garantire che il lancio, il controllo e la protezione del centesimo servizio, funzionalità, applicazione o intero stack non siano più difficili del primo.
Ma qual è la differenza tra la piattaforma OpenShift 4 e i suoi predecessori e rispetto all’approccio “standard” alla risoluzione di tali problemi? Cosa determina la scalabilità per i team operativi e di implementazione? A causa del fatto che il re in questa situazione è il grappolo. COSÌ,
- Ci assicuriamo che lo scopo dei cluster sia chiaro (Caro cloud, ho scelto questo cluster perché potevo)
- Esistono macchine e sistemi operativi per servire il cluster (Vostra Maestà)
- Gestisci lo stato degli host dal cluster, minimizza la loro ricostruzione (deriva).
- Per ogni elemento importante del sistema è necessaria una tata (meccanismo) che monitorerà ed eliminerà i problemi
- Il fallimento di *ogni* aspetto o elemento di un sistema e i meccanismi di recupero associati sono una parte normale della vita
- L'intera infrastruttura deve essere configurata tramite API.
- Utilizza Kubernetes per eseguire Kubernetes. (Sì, sì, non è un errore di battitura)
- Gli aggiornamenti dovrebbero essere facili e facili da installare. Se è necessario più di un clic per installare un aggiornamento, ovviamente stiamo facendo qualcosa di sbagliato.
- Il monitoraggio e il debug di qualsiasi componente non dovrebbero essere un problema, e quindi anche il monitoraggio e il reporting nell'intera infrastruttura dovrebbero essere facili e convenienti.
Vuoi vedere le capacità della piattaforma in azione?
Una versione di anteprima di OpenShift 4 è diventata disponibile per gli sviluppatori. Con un programma di installazione facile da usare, puoi eseguire un cluster su AWS su Red Had CoreOS. Per utilizzare l'anteprima, è necessario solo un account AWS per effettuare il provisioning dell'infrastruttura e un set di account per accedere alle immagini di anteprima.
- Per iniziare, vai a e fare clic su "Inizia".
- Accedi al tuo account Red Hat (o creane uno nuovo) e segui le istruzioni per configurare il tuo primo cluster.
Una volta completata l'installazione, dai un'occhiata ai nostri tutorial per comprendere più a fondo i sistemi e i concetti che rendono la piattaforma OpenShift 4 un modo così semplice e conveniente per eseguire Kubernetes.
Prova la nuova versione di OpenShift e condividi la tua opinione. Ci impegniamo a rendere il lavoro con Kumbernetes il più accessibile e semplice possibile: il futuro di NoOps inizia oggi.
Adesso attenzione!
Alla conferenza Il 20 aprile, uno degli sviluppatori di OpenShift, Vadim Rutkovsky, terrà una master class: romperà dieci cluster e li costringerà a risolverli. La conferenza è a pagamento, ma con il codice promozionale #RedHat ottieni uno sconto del 37%.
Masterclass dalle 17:15 alle 18:15 e lo stand è aperto tutto il giorno. Magliette, cappelli, adesivi: il solito!
Sala n.2
“Qui è necessario cambiare tutto il sistema: ripariamo i cluster k8 rotti insieme a meccanici certificati”.
Fonte: habr.com