Tai pirmasis iš eilės įrašų apie būsimojo Red Hat OpenShift platformos 4.0 atnaujinimo pakeitimus, patobulinimus ir papildymus, kurie padės pasiruošti perėjimui prie naujos versijos.
Nuo to momento, kai 2014 m. rudenį jaunoji „Kubernetes“ bendruomenė pirmą kartą susibūrė „Google“ biure Sietle, buvo aišku, kad „Kubernetes“ projektui buvo lemta pakeisti šiandienos programinės įrangos kūrimo ir diegimo būdą. Tuo pat metu viešųjų debesijos paslaugų teikėjai ir toliau aktyviai investavo į infrastruktūros ir paslaugų plėtrą, todėl darbas su IT ir programinės įrangos kūrimas tapo daug lengvesnis ir prieinamesnis bei neįtikėtinai įperkamas, ką retas galėjo įsivaizduoti dešimtmetį.
Žinoma, paskelbus apie kiekvieną naują debesies paslaugą, Twitter tinkle vyko daugybė ekspertų diskusijų, vyko diskusijos įvairiomis temomis, įskaitant atvirojo kodo eros pabaigą, vietinių IT nuosmukį ir neišvengiamumą. naujos programinės įrangos monopolijos debesyje ir kaip naujoji paradigma X pakeis visas kitas paradigmas.
Nereikia nė sakyti, kad visi šie ginčai buvo labai kvaili
Realybė yra tokia, kad niekas nedings, o šiandien galime pastebėti, kad galutinių produktų ir jų kūrimo būdo augimas sparčiai auga, nes mūsų gyvenime nuolat atsiranda naujos programinės įrangos. Ir nepaisant to, kad viskas aplink pasikeis, tuo pačiu iš esmės viskas išliks nepakitusi. Programinės įrangos kūrėjai vis tiek rašys kodą su klaidomis, operacijų inžinieriai ir patikimumo specialistai vis tiek vaikščios su pranešimų gavikliais ir gaus automatinius įspėjimus sistemoje „Slack“, vadybininkai vis tiek veiks pagal „OpEx“ ir „CapEx“, o kiekvieną kartą, kai įvyks gedimas, vyresnysis kūrėjas liūdnai atsidūsti su žodžiais: „Aš tau taip sakiau“...
Oi tikrai reikėtų aptarti, nurodo, kokius įrankius galime turėti kurdami geresnius programinės įrangos produktus ir kaip jie gali pagerinti saugumą ir padaryti kūrimą lengvesnį bei patikimesnį. Kadangi projektai tampa sudėtingesni, kyla naujų pavojų, o šiandien žmonių gyvenimas taip priklauso nuo programinės įrangos, kad kūrėjai tiesiog turi stengtis geriau atlikti savo darbą.
„Kubernetes“ yra viena iš tokių priemonių. Vykdomi darbai, siekiant sujungti Red Hat OpenShift su kitais įrankiais ir paslaugomis į vieną platformą, kuri padarytų programinę įrangą patikimesnę, lengviau valdomą ir saugesnę vartotojams.
Tai pasakius, „OpenShift“ komanda užduoda vieną paprastą klausimą:
Kaip galite padaryti darbą su Kubernetes lengviau ir patogiau?
Atsakymas stebėtinai akivaizdus:
- automatizuoti sudėtingus diegimo debesyje arba už jos ribų aspektus;
- sutelkti dėmesį į patikimumą, slepiant sudėtingumą;
- ir toliau nuolat dirbti, kad būtų išleisti paprasti ir saugūs naujinimai;
- pasiekti kontrolę ir auditą;
- iš pradžių stengtis užtikrinti aukštą saugumą, bet ne naudojimo patogumo sąskaita.
Kitoje „OpenShift“ laidoje turėtų būti atsižvelgta tiek į kūrėjų, tiek į kitų kūrėjų, kurie stambaus masto programinę įrangą diegia didžiausiose pasaulio įmonėse, patirtį. Be to, ji turi atsižvelgti į visą sukauptą atvirų ekosistemų patirtį, kuri yra šiuolaikinio pasaulio pagrindas. Kartu būtina atsisakyti senojo kūrėjo mėgėjo mentaliteto ir pereiti prie naujos automatizuotos ateities filosofijos. Ji turi užpildyti atotrūkį tarp senų ir naujų programinės įrangos diegimo būdų ir visapusiškai išnaudoti visos turimos infrastruktūros privalumus – nesvarbu, ar ją priglobia didžiausias debesijos paslaugų teikėjas, ar veikia mažose sistemose.
Kaip pasiekti šį rezultatą?
„Red Hat“ įprasta ilgą laiką dirbti nuobodų ir nedėkingą darbą, siekiant išsaugoti susiformavusią bendruomenę ir užkirsti kelią projektų, kuriuose dalyvauja įmonė, uždarymas. Atvirojo kodo bendruomenėje yra daugybė talentingų kūrėjų, kurie kuria pačius nepaprastiausius dalykus – pramoginius, edukacinius, atveriančius naujas galimybes ir tiesiog gražius, bet, žinoma, niekas nesitiki, kad visi judės ta pačia kryptimi ar sieks bendrų tikslų. . Panaudoti šią energiją ir nukreipti ją tinkama linkme kartais būtina plėtoti sritis, kurios būtų naudingos mūsų vartotojams, tačiau tuo pat metu turime stebėti savo bendruomenių vystymąsi ir iš jų mokytis.
2018 metų pradžioje Red Hat įsigijo CoreOS projektą, kurio požiūris į ateitį buvo panašus – saugesnis ir patikimesnis, sukurtas atvirojo kodo principais. Bendrovė stengėsi toliau plėtoti šias idėjas ir jas įgyvendinti, taikydama savo filosofiją praktikoje – stengdamasi užtikrinti, kad visa programinė įranga veiktų saugiai. Visas šis darbas sukurtas naudojant „Kubernetes“, „Linux“, viešuosius debesis, privačius debesis ir tūkstančius kitų projektų, kuriais grindžiama mūsų moderni skaitmeninė ekosistema.
Naujasis „OpenShift 4“ leidimas bus aiškus, automatizuotas ir natūralesnis
„OpenShift“ platforma veiks su geriausiomis ir patikimiausiomis „Linux“ operacinėmis sistemomis, su „be metalo“ techninės įrangos palaikymu, patogia virtualizacija, automatiniu infrastruktūros programavimu ir, žinoma, konteineriais (kurie iš esmės yra tik „Linux“ vaizdai).
Platforma turi būti saugi nuo pat pradžių, bet vis tiek leisti kūrėjams lengvai kartotis, ty būti pakankamai lanksti ir saugi, o administratoriai gali lengvai ją tikrinti ir valdyti.
Tai turėtų leisti programinę įrangą paleisti „kaip paslaugą“ ir nesukelti operatorių nevaldomo infrastruktūros augimo.
Tai leis kūrėjams sutelkti dėmesį į tikrų produktų kūrimą vartotojams ir klientams. Jums nereikės bristi per aparatinės ir programinės įrangos nustatymų džiungles, o visos atsitiktinės komplikacijos liks praeitimi.
OpenShift 4: NoOps platforma, kuriai nereikia priežiūros
В aprašė tas užduotis, kurios padėjo suformuoti įmonės „OpenShift 4“ viziją. Komandos tikslas – kiek įmanoma supaprastinti kasdienes programinės įrangos valdymo ir priežiūros užduotis, kad šie procesai būtų lengvi ir atpalaiduoti – tiek diegiant dalyvaujantiems specialistams, tiek kūrėjams. Bet kaip priartėti prie šio tikslo? Kaip sukurti platformą programinei įrangai, kuriai reikia minimalaus įsikišimo, paleisti? Ką šiame kontekste reiškia „NoOps“?
Jei bandote abstrahuoti, kūrėjams sąvokos „be serverio“ arba „NoOps“ reiškia įrankius ir paslaugas, leidžiančias paslėpti „operacinį“ komponentą arba sumažinti šią kūrėjo naštą.
- Dirbkite ne su sistemomis, o su taikomųjų programų sąsajomis (API).
- Nesivaržykite diegdami programinę įrangą – leiskite paslaugų teikėjui tai padaryti už jus.
- Nepradėkite kurti didelio pagrindo iš karto – pradėkite rašydami mažas dalis, kurios veiks kaip „statybiniai blokai“, stenkitės, kad šis kodas veiktų su duomenimis ir įvykiais, o ne su diskais ir duomenų bazėmis.
Tikslas, kaip ir anksčiau, yra paspartinti programinės įrangos kūrimo iteracijas, suteikti galimybę kurti geresnius produktus ir kad kūrėjui nereikėtų rūpintis sistemomis, kuriose veikia jo programinė įranga. Patyręs kūrėjas puikiai žino, kad sutelkus dėmesį į vartotojus vaizdas gali greitai pasikeisti, todėl nereikėtų dėti per daug pastangų kurdami programinę įrangą, nebent esate visiškai tikri, kad jos reikia.
Priežiūros ir eksploatavimo specialistams žodis „NoOps“ gali atrodyti šiek tiek bauginantis. Tačiau bendraujant su lauko inžinieriais tampa akivaizdu, kad jų naudojami modeliai ir metodai, kuriais siekiama užtikrinti patikimumą ir patikimumą (Site Reliability Engineering, SRE) turi daug panašumų su aukščiau aprašytais modeliais:
- Nevaldykite sistemų – automatizuokite jų valdymo procesus.
- Nediekite programinės įrangos – sukurkite konvejerį jai įdiegti.
- Venkite sujungti visas savo paslaugas ir neleisti, kad dėl vienos gedimo sugestų visa sistema – paskirstykite jas visoje infrastruktūroje naudodami automatizavimo įrankius ir prijunkite jas stebimais ir stebimais būdais.
SRE žino, kad kažkas gali nutikti ne taip, todėl jie turės atsekti ir išspręsti problemą – todėl jie automatizuoja įprastą darbą ir iš anksto nustato klaidų biudžetus, kad būtų pasirengę nustatyti prioritetus ir priimti sprendimus iškilus problemai.
„Kubernetes“ sistemoje „OpenShift“ yra platforma, skirta išspręsti dvi pagrindines problemas: užuot verčiau suprasti virtualias mašinas ar apkrovos balansavimo API, ji veikia su aukštesnės eilės abstrakcijomis – diegimo procesais ir paslaugomis. Užuot įdiegę programinės įrangos agentus, galite paleisti konteinerius ir užuot rašę savo stebėjimo krūvą, naudokite platformoje jau esančius įrankius. Taigi, slaptas „OpenShift 4“ padažas tikrai nėra paslaptis – tereikia perimti SRE principus ir be serverio koncepcijas ir padaryti juos logiška išvada, kad padėtų kūrėjams ir operacijų inžinieriams:
- Automatizuokite ir standartizuokite infrastruktūrą, kurią naudoja programos
- Susiekite diegimo ir kūrimo procesus, neapribodami pačių kūrėjų
- Užtikrinti, kad paleisti, tikrinti ir apsaugoti XNUMX-ąją paslaugą, funkciją, programą ar visą paketą nėra sunkiau nei pirmąjį.
Tačiau kuo „OpenShift 4“ platforma skiriasi nuo jos pirmtakų ir nuo „standartinio“ požiūrio į tokių problemų sprendimą? Kas lemia diegimo ir operacijų komandų mastą? Dėl to, kad šioje situacijoje karalius yra klasteris. Taigi,
- Įsitikiname, kad klasterių paskirtis yra aiški (gerbiamas debesėlis, aš pasirinkau šią grupę, nes galėjau)
- Yra mašinos ir operacinės sistemos, skirtos klasteriui aptarnauti (Jūsų Didenybė)
- Tvarkykite pagrindinio kompiuterio būseną iš klasterio, sumažinkite jų atstatymą (dreifą).
- Kiekvienam svarbiam sistemos elementui reikalinga auklė (mechanizmas), kuri stebės ir pašalins problemas
- *Kiekvieno* sistemos aspekto ar elemento ir susijusių atkūrimo mechanizmų gedimas yra įprasta gyvenimo dalis
- Visa infrastruktūra turi būti sukonfigūruota per API.
- Naudokite Kubernetes, kad paleistumėte Kubernetes. (Taip, taip, tai nėra rašybos klaida)
- Atnaujinimai turi būti lengvai ir be vargo įdiegti. Jei naujinimui įdiegti reikia daugiau nei vieno paspaudimo, akivaizdu, kad kažką darome ne taip.
- Bet kurio komponento stebėjimas ir derinimas neturėtų būti problema, todėl sekimas ir ataskaitų teikimas visoje infrastruktūroje taip pat turėtų būti lengvas ir patogus.
Norite pamatyti platformos galimybes?
Kūrėjams tapo prieinama „OpenShift 4“ peržiūros versija. Naudodami lengvai naudojamą diegimo programą galite paleisti grupę AWS ant Red Had CoreOS. Kad galėtumėte naudoti peržiūrą, jums reikia tik AWS paskyros, kad būtų sukurta infrastruktūra, ir paskyrų rinkinio, kad galėtumėte pasiekti peržiūros vaizdus.
- Norėdami pradėti, eikite į ir spustelėkite „Pradėti“.
- Prisijunkite prie savo „Red Hat“ paskyros (arba sukurkite naują) ir vadovaukitės instrukcijomis, kad nustatytumėte pirmąją grupę.
Sėkmingai įdiegę peržiūrėkite mūsų vadovėlius Norėdami geriau suprasti sistemas ir koncepcijas, dėl kurių „OpenShift 4“ platforma yra toks paprastas ir patogus būdas paleisti „Kubernetes“.
Išbandykite naują „OpenShift“ leidimą ir pasidalykite savo nuomone. Esame įsipareigoję dirbti su „Kumbernetes“ kuo lengviau ir lengviau – „NoOps“ ateitis prasideda šiandien.
O dabar dėmesio!
Konferencijoje Balandžio 20 dieną vienas iš „OpenShift“ kūrėjų Vadimas Rutkovskis surengs meistriškumo klasę – sulaužys dešimt klasterių ir privers juos taisyti. Konferencija mokama, tačiau su akcijos kodu #RedHat gaunate 37% nuolaidą
Meistriškumo klasė 17:15 - 18:15, o stendas dirba visą dieną. Marškinėliai, kepurės, lipdukai – įprasta!
2 salė
„Čia reikia keisti visą sistemą: sugedusius k8s klasterius remontuojame kartu su sertifikuotais mechanikais.
Šaltinis: www.habr.com