Aceasta este prima publicație dintr-o serie de materiale dedicate schimbărilor, îmbunătățirilor și completărilor din viitoarea actualizare a platformei Red Hat OpenShift la versiunea 4.0, care vor ajuta la pregătirea pentru trecerea la noua versiune.
Încă de la acel moment în care reprezentanții comunității Kubernetes, abia emergente, s-au reunit pentru prima dată în toamna anului 2014 în biroul Google din Seattle, a fost evident că proiectul Kubernetes va schimba fundamental abordările actuale în dezvoltarea și implementarea software-ului. În același timp, furnizorii publici de servicii cloud continuau să investească activ în dezvoltarea infrastructurii și serviciilor, ceea ce a ușurat și simplificat semnificativ munca cu IT-ul și crearea de software, făcându-le incredibil de accesibile, lucru pe care puțini ar fi putut să-l imagineze la începutul decadelor.
Desigur, anunțul fiecărui nou serviciu cloud a fost însoțit de numeroase discuții ale experților pe Twitter, iar disputele se purtau pe teme variate - inclusiv despre sfârșitul erei codurilor deschise, despre declinul IT-ului pe partea clienților (on-premises IT), despre inevitabilitatea unei noi monopolii software în cloud și despre cum noua paradigmă X va înlocui toate celelalte paradigme.
Nu trebuie să spunem că toate aceste dispute au fost extrem de stupide.
Realitatea este că nimic nu dispare și astăzi putem observa o creștere exponențială a produselor finale și a modalităților lor de dezvoltare, ceea ce este legat de apariția constantă a noului software în viețile noastre. Și, deși totul în jur se va schimba, în esență, totul va rămâne neschimbat. Dezvoltatorii de software vor continua să scrie cod cu erori, inginerii de operațiuni și specialiștii în fiabilitate vor continua să umble cu pagere și să primească alerte automate în Slack, iar managerii vor opera în continuare cu conceptele de OpEx și CapEx, iar de fiecare dată când apare o problemă, dezvoltatorul senior va suspina trist spunând: „Știam eu...”
Ce ar trebui cu adevărat să discutăm, astfel încât să putem avea la dispoziție instrumentele necesare pentru a crea produse software de o calitate superioară și cum acestea ne ajută să îmbunătățim securitatea și să facem dezvoltarea mai simplă și mai fiabilă. Odată cu creșterea complexității proiectelor, apar și noi riscuri, iar astăzi viețile oamenilor depind atât de mult de software, încât dezvoltatorii trebuie să se străduiască să își facă munca mai bine.
Kubernetes este unul dintre aceste instrumente. Se lucrează pentru a integra acest instrument cu alte unelte și servicii în cadrul Red Hat OpenShift într-o platformă unificată, care să facă software-ul mai fiabil, mai ușor de gestionat și mai sigur pentru utilizatori.
Având în vedere cele spuse, echipa OpenShift își pune o întrebare simplă:
Cum putem face lucrul cu Kubernetes mai simplu și mai confortabil?
Răspunsul este, surprinzător, evident:
- să automatizăm momentele complexe din desfășurarea în cloud sau on-premise;
- să ne concentrăm pe fiabilitate, ascunzând în același timp complexitatea;
- să continuăm să lucrăm constant pentru lansarea unor actualizări simple și sigure;
- să ne asigurăm că există un control și posibilitatea de audit;
- să ne străduim să asigurăm încă de la început un nivel ridicat de securitate, fără a compromite utilizabilitatea.
Următoarea versiune OpenShift trebuie să țină cont atât de experiența creatorilor, cât și de experiența altor dezvoltatori, care implementează software la scară largă în cele mai mari companii din lume. De asemenea, aceasta trebuie să integreze întreaga experiență acumulată a ecosistemelor deschise, care stau la baza lumii moderne. Este esențial să abandonăm mentalitatea anterioară a dezvoltatorului amator și să ne orientăm spre o nouă filozofie a viitorului automatizării. Aceasta trebuie să fie un 'pod' între vechile și noile metode de desfășurare a software-ului și să utilizeze pe deplin toată infrastructura disponibilă – indiferent dacă este susținută de un mare furnizor de cloud sau rulată pe sisteme mici la marginea rețelei.
Cum putem atinge acest rezultat?
La Red Hat se angajează să finalizeze munca plictisitoare și nerecunoscătoare pentru a menține comunitatea formată și a evita închiderea proiectelor în care compania este implicată. În comunitatea open-source există o mulțime de dezvoltatori talentați care creează lucruri extraordinare – distractive, educative, care deschid noi oportunități și pur și simplu frumoase, dar, desigur, nimeni nu se așteaptă ca toți participanții să meargă în aceeași direcție sau să urmărească scopuri comune. Folosirea acestei energii, redirecționarea ei în direcția dorită, este uneori necesară pentru dezvoltarea unor direcții care ar fi benefice pentru utilizatorii noștri, dar în același timp trebuie să ne monitorizăm comunitățile și să învățăm de la ele.
La începutul anului 2018, Red Hat a achiziționat proiectul CoreOS, care avea viziuni similare pentru viitor – mai sigur și mai fiabil, creat pe principii open-source. Compania a lucrat la dezvoltarea ulterioară a acestor idei și implementarea lor, punând în practică filosofia noastră – încercând să asigure funcționarea în siguranță a întregului software. Toată această muncă se bazează pe Kubernetes, Linux, cloud-uri publice, cloud-uri private și mii de alte proiecte care stau la baza ecosistemului nostru digital modern.
Noua versiune OpenShift 4 va fi clară, automatizată și mai naturală.
Platforma OpenShift va funcționa cu cele mai bune și fiabile sisteme de operare Linux, cu suport hardware bare-metal, virtualizare convenabilă, programare automată a infrastructurii și, desigur, containere (care sunt de fapt doar imagini Linux).
Platforma trebuie să fie sigură de la bun început, dar în același timp să ofere posibilitatea unor iterații convenabile pentru dezvoltatori – adică să aibă o flexibilitate și fiabilitate suficiente, permițând totodată administratorilor să efectueze audituri și să asigure ușurința gestionării.
Aceasta trebuie să permită rularea software-ului „ca serviciu” și să nu ducă la o expansiune necontrolată a infrastructurii pentru operatori.
Aceasta va permite dezvoltatorilor să se concentreze pe crearea de produse reale pentru utilizatori și clienți. Nu va mai fi nevoie să navigheze prin jungla setărilor hardware și software, iar toate complicațiile accidentale vor rămâne în trecut.
OpenShift 4: O platformă NoOps care nu necesită suport
În Au fost descrise acele sarcini care au ajutat la formarea viziunii companiei cu privire la OpenShift 4. Echipa are sarcina de a simplifica cât mai mult posibil sarcinile de operare și suport software, făcând aceste procese simple și relaxante – atât pentru specialiștii implicați în implementare, cât și pentru dezvoltatori. Dar cum putem apropia de acest obiectiv? Cum să creăm o platformă pentru rularea software-ului, care necesită o intervenție minimă? Ce înseamnă, de fapt, NoOps în acest context?
Dacă încercăm să ne abstragem, atunci pentru dezvoltatori conceptele de „serverless” sau „NoOps” reprezintă instrumente și servicii care permit ascunderea componentei „operaționale” sau minimizarea acestei poveri pentru dezvoltator.
- Lucrează nu cu sisteme, ci cu interfețe de programare a aplicațiilor (API).
- Nu te ocupa cu implementarea software-ului – lasă această sarcină providerului.
- Nu ar trebui să te apuci deodată de crearea unui cadru mare – începe prin a scrie fragmente mici, care vor acționa ca „blocuri de construcție”, asigură-te că acest cod funcționează cu date și evenimente, nu cu discuri și baze de date.
Sarcina, ca și înainte, rămâne să accelereze iterațiile în dezvoltarea software-ului, să ofere posibilitatea de a crea produse de calitate superioară, astfel încât dezvoltatorul să nu fie îngrijorat de sistemele pe care rulează software-ul său. Un dezvoltator experimentat înțelege perfect că, dacă se concentrează pe utilizatori, situația se poate schimba rapid, așa că nu ar trebui să investească prea mult efort în scrierea software-ului, dacă nu are o încredere absolută în necesitatea acestuia.
Pentru specialiștii implicați în suportul și exploatarea sistemelor, termenul „NoOps” poate suna puțin înfricoșător. Dar, în timpul interacțiunii cu inginerii de exploatare, devine evident că modelele și metodele folosite de ei, menite să asigure fiabilitatea (Site Reliability Engineering, SRE), se aliniază în mare parte cu modelele menționate anterior:
- Nu gestionați sistemele – automatizați procesele de gestionare a acestora.
- Nu vă ocupați de implementarea software-ului – creați un pipeline pentru desfășurarea acestuia.
- Încercați să nu combinați toate serviciile dvs. și nu permiteți ca defectarea unuia dintre ele să ducă la eșecul întregului sistem – dispersează-le în întreaga infrastructură folosind instrumente de automatizare și conectați-le, având în vedere posibilitatea de control și monitorizare.
Specialiștii în SRE știu că lucrurile pot merge prost și va trebui să monitorizeze și să rezolve problemele – de aceea, ei automatizează activitățile de rutină și stabilesc din timp limitele acceptabile de erori (error budgets), pentru a fi pregătiți să prioritizeze și să ia decizii în caz de probleme.
Kubernetes în OpenShift este o platformă destinată să rezolve două probleme principale: în loc să te forțeze să te ocupi de mașini virtuale sau API-uri ale încărcătoarelor de echilibrare, lucrezi cu aberații de ordin superior – cu procesele de desfășurare și serviciile. În loc să instalezi agenți software, poți lansa containere, iar în loc să scrii propriul tău stack de monitorizare, folosește instrumentele deja disponibile pe platformă. Astfel, ingredientul secret al OpenShift 4 nu reprezintă de fapt niciun mister – trebuie doar să aplici principiile SRE și conceptele serverless și să le duci la bun sfârșit, în sprijinul dezvoltatorilor și inginerilor de exploatare:
- Automatizați și standardizați infrastructura utilizată de aplicații.
- Conectați procesele de desfășurare și dezvoltare fără a limita dezvoltatorii.
- Asigurați-vă că desfășurarea, auditarea și asigurarea securității celui de-al suta serviciu, funcționalitate, aplicație sau întreaga stivă nu sunt mai dificile decât pentru primul.
Dar care este diferența între platforma OpenShift 4 și predecesoarele sale, precum și între abordarea „standard” de a rezolva probleme similare? Cum se realizează scalarea pentru echipele care se ocupă de implementare și operare? Datorită faptului că regele în această situație este clusterul. Așadar,
- Facem astfel încât scopul clusterelor să fie clar (Cloud costisitor, acest cluster l-am creat pentru că am putut)
- Mașinile și sistemele de operare există pentru a sprijini clusterul (Majestatea Voastră)
- Gestionează starea gazdelor din cluster, minimalizând reconstruirea acestora (drift).
- Pentru fiecare element important al sistemului, este necesar un mecanism (bonă) care să monitorizeze și să rezolve problemele
- Defecțiunea *fiecărui* aspect sau element al sistemului activează mecanismele de recuperare — aceasta este o parte obișnuită a vieții
- Întreaga infrastructură trebuie configurată prin intermediul API-ului.
- Folosește Kubernetes pentru a rula Kubernetes. (Da, da, nu este o greșeală de tipar)
- Actualizările trebuie instalate ușor și fără efort. Dacă pentru instalarea unei actualizări sunt necesare mai mult de un clic al mouse-ului, atunci, evident, facem ceva greșit.
- Monitorizarea și depanarea oricărui component nu ar trebui să reprezinte o problemă, iar, în consecință, urmărirea și raportarea pentru întreaga infrastructură ar trebui să fie la fel de simplă și convenabilă.
Vrei să vezi capacitățile platformei în acțiune?
Versiunea preliminară OpenShift 4 este disponibilă pentru dezvoltatori. Cu ajutorul unui instalator ușor de utilizat, poți să rulezi un cluster pe AWS folosind Red Hat CoreOS. Pentru a beneficia de versiunea preliminară, este necesar doar un cont AWS pentru a furniza infrastructura și un set de conturi pentru a accesa imaginile versiunii preliminare.
- Pentru a începe, accesează și apasă „Get Started”.
- Conectează-te la contul tău Red Hat (sau creează unul nou) și urmează instrucțiunile pentru a configura primul tău cluster.
După instalarea cu succes, consultă materialele noastre de învățare , pentru a obține o imagine mai detaliată a sistemelor și conceptelor care fac din platforma OpenShift 4 un instrument atât de simplu și convenabil pentru a rula Kubernetes.
Încercați noua versiune OpenShift și împărtășiți-vă opinia. Ne străduim să facem utilizarea Kubernetes cât mai accesibilă și fără efort – viitorul NoOps începe chiar astăzi.
Și acum atenție!
La conferință Pe 20 aprilie, unul dintre dezvoltatorii OpenShift, Vadim Rutkovski, va susține un masterclass – va distruge zece clustere și ne va învăța să le reparăm. Conferința este cu plată, dar cu codul promoțional #RedHat aveți o reducere de 37%.
Masterclass-ul va avea loc între 17:15 și 18:15, iar standul va funcționa întreaga zi. Tricouri, pălării, autocolante – ca de obicei!
Sala #2
„Trebuie să schimbăm întreaga sistemă: reparăm clusterele k8s defecte împreună cu mecanicii certificați.”
Sursa: habr.com
