Aceasta este prima dintr-o serie de postări despre modificările, îmbunătățirile și completările din viitoarea actualizare a platformei Red Hat OpenShift 4.0, care vă va ajuta să vă pregătiți pentru tranziția la noua versiune.
Din momentul în care noua comunitate Kubernetes s-a adunat pentru prima dată la biroul Google din Seattle în toamna lui 2014, a fost clar că proiectul Kubernetes era destinat să revoluționeze modul în care software-ul este dezvoltat și implementat astăzi. În același timp, furnizorii publici de servicii cloud au continuat să investească activ în dezvoltarea infrastructurii și a serviciilor, ceea ce a făcut ca lucrul cu IT și crearea de software să fie mult mai ușor și mai accesibil, și le-a făcut incredibil de accesibile, ceea ce puțini și-ar fi putut imagina la începutul deceniul.
Bineînțeles, anunțul fiecărui nou serviciu cloud a fost însoțit de numeroase discuții între experți pe Twitter și au avut loc dezbateri pe o varietate de subiecte - inclusiv sfârșitul erei open source, declinul IT-ului on-premise și inevitabilitatea a unui nou monopol de software în cloud și modul în care noua paradigmă X va înlocui toate celelalte paradigme.
Inutil să spun că toate aceste dispute au fost foarte stupide
Realitatea este că nimic nu va dispărea, iar astăzi putem observa o creștere exponențială a produselor finale și a modului în care sunt dezvoltate, datorită apariției constante a noilor software în viața noastră. Și în ciuda faptului că totul în jur se va schimba, în același timp, în esență, totul va rămâne neschimbat. Dezvoltatorii de software vor scrie în continuare cod cu erori, inginerii operaționali și specialiștii în fiabilitate se vor plimba în continuare cu pagere și vor primi alerte automate în Slack, managerii vor opera în continuare în termeni de OpEx și CapEx, iar de fiecare dată când apare un eșec, seniorul dezvoltator va suspină trist cu cuvintele: „Ți-am spus așa”...
Oh, chiar aşa ar trebui discutat, este ce instrumente putem avea la dispoziție pentru a crea produse software mai bune și cum pot îmbunătăți securitatea și face dezvoltarea mai ușoară și mai fiabilă. Pe măsură ce proiectele devin mai complexe, apar noi riscuri, iar astăzi viața oamenilor este atât de dependentă de software, încât dezvoltatorii trebuie pur și simplu să încerce să-și facă treaba mai bine.
Kubernetes este un astfel de instrument. Se lucrează pentru a combina Red Hat OpenShift cu alte instrumente și servicii într-o singură platformă care ar face software-ul mai fiabil, mai ușor de gestionat și mai sigur pentru utilizatori.
Acestea fiind spuse, echipa OpenShift pune o întrebare simplă:
Cum puteți face lucrul cu Kubernetes mai ușor și mai convenabil?
Răspunsul este surprinzător de evident:
- automatizează aspecte complexe ale implementării în cloud sau în afara cloudului;
- concentrați-vă pe fiabilitate, ascunzând în același timp complexitatea;
- continuați să lucrați continuu pentru a lansa actualizări simple și sigure;
- atinge controlabilitatea și auditabilitatea;
- depuneți eforturi pentru a asigura inițial securitate ridicată, dar nu în detrimentul utilizabilității.
Următoarea versiune a OpenShift ar trebui să țină cont atât de experiența creatorilor, cât și de experiența altor dezvoltatori care implementează software pe scară largă în cele mai mari companii din lume. În plus, trebuie să țină cont de toată experiența acumulată a ecosistemelor deschise care stau la baza lumii moderne de astăzi. În același timp, este necesar să renunțăm la vechea mentalitate a dezvoltatorului amator și să trecem la o nouă filozofie a unui viitor automatizat. Trebuie să reducă diferența dintre modurile vechi și noi de implementare a software-ului și să profite din plin de întreaga infrastructură disponibilă, indiferent dacă este găzduită de cel mai mare furnizor de cloud sau rulează pe sisteme minuscule de la periferie.
Cum să obții acest rezultat?
La Red Hat, se obișnuiește să se facă o muncă plictisitoare și ingrată timp îndelungat pentru a păstra comunitatea consacrată și pentru a preveni închiderea proiectelor în care este implicată compania. Comunitatea open-source conține un număr mare de dezvoltatori talentați care creează cele mai extraordinare lucruri - distractive, educaționale, care deschid noi oportunități și pur și simplu frumoase, dar, desigur, nimeni nu se așteaptă ca toată lumea să se miște în aceeași direcție sau să urmărească obiective comune. . Valorificarea acestei energii și redirecționarea ei în direcția corectă este uneori necesară pentru a dezvolta zone de care ar beneficia utilizatorii noștri, dar în același timp trebuie să monitorizăm dezvoltarea comunităților noastre și să învățăm din ele.
La începutul lui 2018, Red Hat a achiziționat proiectul CoreOS, care avea opinii similare asupra viitorului - mai sigur și mai fiabil, creat pe principii open-source. Compania a lucrat pentru a dezvolta în continuare aceste idei și a le implementa, punând în practică filosofia noastră - încercând să ne asigurăm că toate programele funcționează în siguranță. Toate aceste lucrări sunt construite pe Kubernetes, Linux, nori publici, nori private și mii de alte proiecte care stau la baza ecosistemului nostru digital modern.
Noua versiune a OpenShift 4 va fi clară, automatizată și mai naturală
Platforma OpenShift va funcționa cu cele mai bune și mai fiabile sisteme de operare Linux, cu suport hardware bare-metal, virtualizare convenabilă, programare automată a infrastructurii și, desigur, containere (care sunt în esență doar imagini Linux).
Platforma trebuie să fie sigură de la început, dar totuși să permită dezvoltatorilor să repete cu ușurință, adică să fie suficient de flexibilă și sigură, permițând totuși administratorilor să o auditeze și să o gestioneze cu ușurință.
Ar trebui să permită rularea software-ului „ca serviciu” și să nu conducă la creșterea infrastructurii de negestionat pentru operatori.
Acesta va permite dezvoltatorilor să se concentreze pe crearea de produse reale pentru utilizatori și clienți. Nu va trebui să treci prin jungla setărilor hardware și software, iar toate complicațiile accidentale vor fi de domeniul trecutului.
OpenShift 4: platformă NoOps care nu necesită întreținere
В a descris acele sarcini care au contribuit la modelarea viziunii companiei pentru OpenShift 4. Scopul echipei este să simplifice cât mai mult posibil sarcinile zilnice de operare și întreținere a software-ului, pentru a face aceste procese ușoare și relaxate - atât pentru specialiștii implicați în implementare, cât și pentru dezvoltatori. Dar cum te poți apropia de acest obiectiv? Cum se creează o platformă pentru rularea software-ului care necesită intervenție minimă? Ce înseamnă chiar NoOps în acest context?
Dacă încercați să abstrageți, atunci pentru dezvoltatori conceptele de „fără server” sau „NoOps” înseamnă instrumente și servicii care vă permit să ascundeți componenta „operațională” sau să minimizați această povară pentru dezvoltator.
- Nu lucrați cu sisteme, ci cu interfețe de aplicație (API).
- Nu vă deranjați să implementați software - lăsați furnizorul să o facă pentru dvs.
- Nu ar trebui să treceți imediat la crearea unui cadru mare - începeți prin a scrie bucăți mici care vor acționa ca „blocuri de construcție”, încercați să faceți acest cod să funcționeze cu date și evenimente, și nu cu discuri și baze de date.
Scopul, ca și până acum, este să accelereze iterațiile în dezvoltarea de software, să ofere posibilitatea de a crea produse mai bune și astfel încât dezvoltatorul să nu fie nevoit să-și facă griji cu privire la sistemele pe care rulează software-ul său. Un dezvoltator cu experiență este foarte conștient de faptul că concentrarea asupra utilizatorilor poate schimba rapid imaginea, așa că nu ar trebui să depuneți prea mult efort în scrierea de software decât dacă sunteți absolut sigur că este necesar.
Pentru profesioniștii în întreținere și operațiuni, cuvântul „NoOps” poate suna puțin înfricoșător. Dar atunci când comunicați cu inginerii de teren, devine evident că modelele și tehnicile pe care le folosesc pentru a asigura fiabilitatea și fiabilitatea (Site Reliability Engineering, SRE) au multe asemănări cu modelele descrise mai sus:
- Nu gestionați sistemele - automatizați-le procesele de gestionare.
- Nu implementați software - creați o conductă pentru a-l implementa.
- Evitați să vă grupați toate serviciile și să lăsați ca defecțiunea unuia să cauzeze defectarea întregului sistem – dispersați-le în întreaga infrastructură folosind instrumente de automatizare și conectați-le în moduri care pot fi monitorizate și monitorizate.
SRE știu că ceva poate merge prost și vor trebui să urmărească și să remedieze problema, astfel încât să automatizeze munca de rutină și să stabilească bugete pentru erori în avans, astfel încât să fie gata să prioritizeze și să ia decizii atunci când apare o problemă. .
Kubernetes în OpenShift este o platformă concepută pentru a rezolva două probleme principale: în loc să vă oblige să înțelegeți mașinile virtuale sau API-urile de echilibrare a încărcăturii, funcționează cu abstracții de ordin superior - procese și servicii de implementare. În loc să instalați agenți software, puteți rula containere și, în loc să vă scrieți propria stivă de monitorizare, folosiți instrumentele deja disponibile în platformă. Deci, sosul secret al OpenShift 4 nu este cu adevărat un secret - este doar o chestiune de a lua principiile SRE și conceptele fără server și de a le duce la concluzia lor logică pentru a ajuta dezvoltatorii și inginerii operaționali:
- Automatizați și standardizați infrastructura pe care o folosesc aplicațiile
- Conectați procesele de implementare și dezvoltare, fără a restricționa dezvoltatorii înșiși
- Asigurarea că lansarea, auditarea și securizarea celui de-al XNUMX-lea serviciu, caracteristică, aplicație sau întreg stiva nu este mai dificilă decât primul.
Dar care este diferența dintre platforma OpenShift 4 și predecesorii săi și față de abordarea „standard” pentru rezolvarea unor astfel de probleme? Ce determină scalarea pentru echipele de implementare și operațiuni? Datorită faptului că regele în această situație este clusterul. Asa de,
- Ne asigurăm că scopul clusterelor este clar (Dragă nor, am luat acest cluster pentru că am putut)
- Există mașini și sisteme de operare pentru a servi clusterul (Maestatea Voastră)
- Gestionați starea gazdelor din cluster, minimizați reconstrucția (deriva) a acestora.
- Pentru fiecare element important al sistemului este nevoie de o bonă (mecanism) care va monitoriza și elimina problemele
- Eșecul *fiecărui* aspect sau element al unui sistem și mecanismele de recuperare asociate sunt o parte normală a vieții
- Întreaga infrastructură trebuie configurată prin API.
- Utilizați Kubernetes pentru a rula Kubernetes. (Da, da, nu este o greșeală de scriere)
- Actualizările ar trebui să fie ușor și fără probleme de instalat. Dacă este nevoie de mai mult de un clic pentru a instala o actualizare, atunci evident că facem ceva greșit.
- Monitorizarea și depanarea oricărei componente nu ar trebui să fie o problemă și, prin urmare, urmărirea și raportarea în întreaga infrastructură ar trebui să fie, de asemenea, ușoare și convenabile.
Doriți să vedeți capabilitățile platformei în acțiune?
O versiune de previzualizare a OpenShift 4 a devenit disponibilă pentru dezvoltatori. Cu un program de instalare ușor de utilizat, puteți rula un cluster pe AWS pe Red Had CoreOS. Pentru a utiliza previzualizarea, aveți nevoie doar de un cont AWS pentru a furniza infrastructura și de un set de conturi pentru a accesa imaginile de previzualizare.
- Pentru a începe, accesați și faceți clic pe „Începeți”.
- Conectați-vă la contul dvs. Red Hat (sau creați unul nou) și urmați instrucțiunile pentru a configura primul dvs. cluster.
După instalarea cu succes, consultați tutorialele noastre pentru a obține o înțelegere mai profundă a sistemelor și conceptelor care fac din platforma OpenShift 4 o modalitate atât de ușoară și convenabilă de a rula Kubernetes.
Încercați noua versiune OpenShift și împărtășiți-vă părerea. Ne angajăm să facem lucrul cu Kumbernetes cât mai accesibil și fără efort posibil – viitorul NoOps începe astăzi.
Și acum atenție!
La conferință Pe 20 aprilie, unul dintre dezvoltatorii OpenShift, Vadim Rutkovsky, va susține o clasă de master - el va sparge zece clustere și îi va forța să le repare. Conferința este plătită, dar cu codul promoțional #RedHat primești o reducere de 37%.
Master class la 17:15 - 18:15, iar standul este deschis toată ziua. Tricouri, pălării, autocolante - cele obișnuite!
Sala #2
„Aici, întregul sistem trebuie schimbat: reparăm grupurile k8s defecte împreună cu mecanici autorizați.”
Sursa: www.habr.com