Ky është i pari në një seri postimesh në lidhje me ndryshimet, përmirësimet dhe shtesat në përditësimin e ardhshëm të platformës Red Hat OpenShift 4.0 që do t'ju ndihmojë të përgatiteni për kalimin në versionin e ri.
Që nga momenti kur komuniteti i ri Kubernetes u mblodh për herë të parë në zyrën e Google në Seattle në vjeshtën e vitit 2014, projekti Kubernetes ishte i destinuar të revolucionarizonte mënyrën se si zhvillohet dhe vendoset softueri sot. Në të njëjtën kohë, ofruesit e shërbimeve publike cloud vazhduan të investojnë në mënyrë aktive në zhvillimin e infrastrukturës dhe shërbimeve, gjë që e bëri punën me IT dhe krijimin e softuerit shumë më të lehtë dhe më të aksesueshëm, dhe i bëri ato tepër të përballueshme, gjë që pakkush mund ta imagjinonte në fillim të dekadën.
Natyrisht, shpallja e çdo shërbimi të ri cloud u shoqërua me diskutime të shumta midis ekspertëve në Twitter dhe u zhvilluan debate për një sërë temash - duke përfshirë fundin e epokës me burim të hapur, rënien e IT-së në mjedise dhe pashmangshmërinë. të një monopoli të ri softuerësh në cloud, dhe si paradigma e re X do të zëvendësojë të gjitha paradigmat e tjera.
Eshtë e panevojshme të thuhet, të gjitha këto mosmarrëveshje ishin shumë marrëzi
Realiteti është se asgjë nuk do të largohet, dhe sot ne mund të shohim një rritje eksponenciale në produktet përfundimtare dhe mënyrën e zhvillimit të tyre, për shkak të shfaqjes së vazhdueshme të softuerëve të rinj në jetën tonë. Dhe përkundër faktit se gjithçka përreth do të ndryshojë, në të njëjtën kohë, në thelb, gjithçka do të mbetet e pandryshuar. Zhvilluesit e softuerit do të vazhdojnë të shkruajnë kode me gabime, inxhinierët e operacioneve dhe specialistët e besueshmërisë do të vazhdojnë të ecin me pager dhe të marrin sinjalizime automatike në Slack, menaxherët do të vazhdojnë të operojnë në termat e OpEx dhe CapEx dhe sa herë që ndodh një dështim, zhvilluesi i vjetër do të psherëtijë e trishtuar me fjalët: “Të thashë”...
Oh me te vërtetë duhet diskutuar, janë mjetet që mund të kemi në dispozicionin tonë për të krijuar produkte softuerike më të mira dhe se si ato mund të përmirësojnë sigurinë dhe ta bëjnë zhvillimin më të lehtë dhe më të besueshëm. Ndërsa projektet bëhen më komplekse, lindin rreziqe të reja dhe sot jeta e njerëzve është aq e varur nga programet kompjuterike saqë zhvilluesit thjesht duhet të përpiqen të bëjnë punën e tyre më mirë.
Kubernetes është një mjet i tillë. Po punohet për të kombinuar Red Hat OpenShift me mjete dhe shërbime të tjera në një platformë të vetme që do ta bënte softuerin më të besueshëm, më të lehtë për t'u menaxhuar dhe më të sigurt për përdoruesit.
Me këtë thënë, ekipi i OpenShift bën një pyetje të thjeshtë:
Si mund ta bëni më të lehtë dhe më të përshtatshëm punën me Kubernetes?
Përgjigja është çuditërisht e qartë:
- automatizoni aspektet komplekse të vendosjes në re ose jashtë saj;
- përqendrohuni në besueshmërinë duke fshehur kompleksitetin;
- vazhdoni të punoni vazhdimisht për lëshimin e përditësimeve të thjeshta dhe të sigurta;
- të arrihet kontrollueshmëria dhe auditueshmëria;
- përpiquni të siguroni fillimisht siguri të lartë, por jo në kurriz të përdorshmërisë.
Publikimi i ardhshëm i OpenShift duhet të marrë parasysh përvojën e krijuesve dhe përvojën e zhvilluesve të tjerë që po zbatojnë softuer në një shkallë të gjerë në kompanitë më të mëdha në botë. Për më tepër, ai duhet të marrë parasysh të gjithë përvojën e akumuluar të ekosistemeve të hapura që qëndrojnë në themel të botës moderne sot. Në të njëjtën kohë, është e nevojshme të braktisim mentalitetin e vjetër të zhvilluesit amator dhe të kalojmë në një filozofi të re të një të ardhmeje të automatizuar. Duhet të kapërcejë hendekun midis mënyrave të vjetra dhe të reja të vendosjes së softuerit dhe të përfitojë plotësisht nga e gjithë infrastruktura e disponueshme—qoftë ajo e organizuar nga ofruesi më i madh i reve kompjuterike ose funksionon në sisteme të vogla në skaj.
Si të arrihet ky rezultat?
Në Red Hat, është zakon të bëni punë të mërzitshme dhe mosmirënjohëse për një kohë të gjatë për të ruajtur komunitetin e krijuar dhe për të parandaluar mbylljen e projekteve në të cilat kompania është e përfshirë. Komuniteti me burim të hapur përmban një numër të madh zhvilluesish të talentuar që krijojnë gjërat më të jashtëzakonshme - argëtuese, arsimore, hapëse të mundësive të reja dhe thjesht të bukura, por, natyrisht, askush nuk pret që të gjithë pjesëmarrësit të lëvizin në të njëjtin drejtim ose të ndjekin të përbashkët qëllimet. Përdorimi i kësaj energjie dhe ridrejtimi i saj në drejtimin e duhur ndonjëherë është i nevojshëm për të zhvilluar fusha nga të cilat do të përfitonin përdoruesit tanë, por në të njëjtën kohë ne duhet të monitorojmë zhvillimin e komuniteteve tona dhe të mësojmë prej tyre.
Në fillim të vitit 2018, Red Hat bleu projektin CoreOS, i cili kishte pikëpamje të ngjashme për të ardhmen - më të sigurt dhe të besueshëm, të krijuar në parime me burim të hapur. Kompania ka punuar për të zhvilluar më tej këto ide dhe për t'i zbatuar ato, duke e vënë në praktikë filozofinë tonë - duke u përpjekur të sigurojë që i gjithë softueri të funksionojë në mënyrë të sigurt. E gjithë kjo punë është ndërtuar në Kubernetes, Linux, retë publike, retë private dhe mijëra projekte të tjera që mbështesin ekosistemin tonë modern dixhital.
Publikimi i ri i OpenShift 4 do të jetë i qartë, i automatizuar dhe më i natyrshëm
Platforma OpenShift do të punojë me sistemet operative më të mira dhe më të besueshme Linux, me mbështetje harduerike metalike të zhveshur, virtualizim të përshtatshëm, programim automatik të infrastrukturës dhe, natyrisht, kontejnerë (që në thelb janë vetëm imazhe Linux).
Platforma duhet të jetë e sigurt që nga fillimi, por gjithsesi t'i lejojë zhvilluesit të përsërisin lehtësisht—d.m.th., të jenë mjaft fleksibël dhe të sigurt, duke i lejuar ende administratorët ta auditojnë dhe ta menaxhojnë atë me lehtësi.
Ai duhet të lejojë që softueri të përdoret "si shërbim" dhe të mos çojë në rritje të pamenaxhueshme të infrastrukturës për operatorët.
Ai do t'i lejojë zhvilluesit të fokusohen në krijimin e produkteve reale për përdoruesit dhe klientët. Nuk do t'ju duhet të kaloni nëpër xhunglën e cilësimeve të harduerit dhe softuerit dhe të gjitha ndërlikimet aksidentale do t'i përkasin së shkuarës.
OpenShift 4: Platforma NoOps që nuk kërkon mirëmbajtje
В përshkroi ato detyra që ndihmuan në formësimin e vizionit të kompanisë për OpenShift 4. Qëllimi i ekipit është të thjeshtojë sa më shumë që të jetë e mundur detyrat e përditshme të funksionimit dhe mirëmbajtjes së softuerit, për t'i bërë këto procese të lehta dhe të relaksuara - si për specialistët e përfshirë në zbatim ashtu edhe për zhvilluesit. Por si mund t'i afroheni këtij qëllimi? Si të krijoni një platformë për ekzekutimin e softuerit që kërkon ndërhyrje minimale? Çfarë do të thotë edhe NoOps në këtë kontekst?
Nëse përpiqeni të abstraktoni, atëherë për zhvilluesit konceptet "pa server" ose "NoOps" nënkuptojnë mjete dhe shërbime që ju lejojnë të fshehni komponentin "operativ" ose të minimizoni këtë barrë për zhvilluesin.
- Punoni jo me sisteme, por me ndërfaqe aplikacionesh (API).
- Mos u shqetësoni për zbatimin e softuerit - lëreni ofruesin ta bëjë atë për ju.
- Mos u hidhni në krijimin e një kornize të madhe menjëherë - filloni duke shkruar pjesë të vogla që do të veprojnë si "blloqe ndërtimi", përpiquni ta bëni këtë kod të funksionojë me të dhëna dhe ngjarje, dhe jo me disqe dhe baza të të dhënave.
Qëllimi, si më parë, është të përshpejtojë përsëritjet në zhvillimin e softuerit, të ofrojë mundësinë për të krijuar produkte më të mira dhe në mënyrë që zhvilluesi të mos ketë nevojë të shqetësohet për sistemet në të cilat funksionon softueri i tij. Një zhvillues me përvojë është i vetëdijshëm se përqendrimi te përdoruesit mund të ndryshojë shpejt figurën, kështu që nuk duhet të bëni shumë përpjekje për të shkruar softuer nëse nuk jeni absolutisht i sigurt se është i nevojshëm.
Për profesionistët e mirëmbajtjes dhe operacioneve, fjala "NoOps" mund të tingëllojë paksa e frikshme. Por kur komunikoni me inxhinierët në terren, bëhet e qartë se modelet dhe teknikat që ata përdorin për të siguruar besueshmërinë dhe besueshmërinë (Site Reliability Engineering, SRE) kanë shumë ngjashmëri me modelet e përshkruara më sipër:
- Mos menaxhoni sistemet - automatizoni proceset e tyre të menaxhimit.
- Mos zbatoni softuer - krijoni një tubacion për ta vendosur atë.
- Shmangni bashkimin e të gjitha shërbimeve tuaja së bashku dhe lënien që dështimi i njërit të shkaktojë dështimin e të gjithë sistemit—shpërndajini ato në të gjithë infrastrukturën tuaj duke përdorur mjete automatizimi dhe lidhini ato në mënyra që mund të monitorohen dhe monitorohen.
SRE-të e dinë se diçka mund të shkojë keq dhe ata do të duhet të gjurmojnë dhe rregullojnë problemin—kështu që ata automatizojnë punën rutinë dhe vendosin buxhetet e gabimeve paraprakisht, në mënyrë që të jenë gati të japin përparësi dhe të marrin vendime kur lind një problem.
Kubernetes në OpenShift është një platformë e krijuar për të zgjidhur dy probleme kryesore: në vend që t'ju detyrojë të kuptoni makinat virtuale ose API-të e balancuesit të ngarkesës, ai funksionon me abstraksione të rendit më të lartë - proceset dhe shërbimet e vendosjes. Në vend që të instaloni agjentë softuerësh, mund të përdorni kontejnerë dhe në vend që të shkruani grupin tuaj të monitorimit, përdorni mjetet tashmë të disponueshme në platformë. Pra, salca sekrete e OpenShift 4 nuk është me të vërtetë sekret - është thjesht një çështje e marrjes së parimeve SRE dhe koncepteve pa server dhe për t'i çuar ato në përfundimin e tyre logjik për të ndihmuar zhvilluesit dhe inxhinierët e operacioneve:
- Automatizoni dhe standardizoni infrastrukturën që përdorin aplikacionet
- Lidhni së bashku proceset e vendosjes dhe zhvillimit pa kufizuar vetë zhvilluesit
- Sigurimi që lançimi, auditimi dhe sigurimi i shërbimit, veçorisë, aplikacionit ose të gjithë grupit të XNUMX-të nuk është më i vështirë se i pari.
Por cili është ndryshimi midis platformës OpenShift 4 dhe paraardhësve të saj dhe nga qasja "standarde" për zgjidhjen e problemeve të tilla? Çfarë e shtyn shkallën për ekipet e zbatimit dhe operacioneve? Për faktin se mbreti në këtë situatë është grupi. Kështu që,
- Sigurohemi që qëllimi i grupimeve të jetë i qartë (E dashur re, e mora këtë grup sepse munda)
- Makinat dhe sistemet operative ekzistojnë për t'i shërbyer grupit (Madhëria juaj)
- Menaxhoni gjendjen e hosteve nga grupi, minimizoni rindërtimin e tyre (drift).
- Për çdo element të rëndësishëm të sistemit nevojitet një dado (mekanizëm) që do të monitorojë dhe eliminojë problemet
- Dështimi i *çdo* aspekt ose elementi i një sistemi dhe mekanizmat e lidhur me rikuperimin janë një pjesë normale e jetës
- E gjithë infrastruktura duhet të konfigurohet nëpërmjet API.
- Përdor Kubernetes për të ekzekutuar Kubernetes. (Po, po, nuk është një gabim shtypi)
- Përditësimet duhet të jenë të lehta dhe pa probleme për t'u instaluar. Nëse duhen më shumë se një klik për të instaluar një përditësim, atëherë padyshim që po bëjmë diçka të gabuar.
- Monitorimi dhe korrigjimi i ndonjë komponenti nuk duhet të jetë problem, dhe për këtë arsye gjurmimi dhe raportimi në të gjithë infrastrukturën duhet të jetë gjithashtu i lehtë dhe i përshtatshëm.
Dëshironi të shihni aftësitë e platformës në veprim?
Një version paraprak i OpenShift 4 është bërë i disponueshëm për zhvilluesit. Me një instalues të lehtë për t'u përdorur, mund të ekzekutoni një grup në AWS në krye të Red Had CoreOS. Për të përdorur pamjen paraprake, ju nevojitet vetëm një llogari AWS për të siguruar infrastrukturën dhe një grup llogarish për të hyrë në imazhet e pamjes paraprake.
- Për të filluar, shkoni te dhe klikoni "Filloni".
- Hyni në llogarinë tuaj Red Hat (ose krijoni një të re) dhe ndiqni udhëzimet për të konfiguruar grupin tuaj të parë.
Pas instalimit të suksesshëm, shikoni mësimet tona për të kuptuar më thellë sistemet dhe konceptet që e bëjnë platformën OpenShift 4 një mënyrë kaq të lehtë dhe të përshtatshme për të drejtuar Kubernetes.
Provoni versionin e ri të OpenShift dhe ndani mendimin tuaj. Ne jemi të përkushtuar ta bëjmë punën me Kumbernetes sa më të aksesueshme dhe pa mundim - e ardhmja e NoOps fillon sot.
Tani vëmendje!
Në konferencë Më 20 prill, një nga zhvilluesit e OpenShift, Vadim Rutkovsky, do të mbajë një klasë master - ai do të thyejë dhjetë grupime dhe do t'i detyrojë ata t'i rregullojnë ato. Konferenca paguhet, por me kodin promocional #RedHat përfitoni 37% ulje
Klasa master në orën 17:15 - 18:15, dhe stendat janë të hapura gjatë gjithë ditës. Bluza, kapele, ngjitëse - e zakonshme!
Salla #2
"Këtu i gjithë sistemi duhet të ndryshohet: ne riparojmë grupimet e prishura të k8s së bashku me mekanikë të certifikuar."
Burimi: www.habr.com