Ky është publikimi i parë në një seri materialesh që lidhen me ndryshimet, përmirësimet dhe shtesat në versionin e ardhshëm të platformës Red Hat OpenShift deri në 4.0, që do të ndihmojnë në përgatitjen për kalimin në versionin e ri.
Që nga momenti kur përfaqësuesit e komunitetit të sapoformuar të Kubernetes u mblodhën për herë të parë në vjeshtën e vitit 2014 në zyrën e Google në Seattle, mund të thuhej se projekti Kubernetes ishte i destinuar të transformonte qasjet moderne në zhvillimin dhe implementimin e softuerit. Në të njëjtën kohë, ofruesit publikë të shërbimeve në cloud vazhduan të investonin në zhvillimin e infrastrukturës dhe shërbimeve, duke e bërë punën me IT dhe krijimin e softuerit të jashtëzakonshëm të lehtë dhe të aksesueshëm, gjë që pak kush mund ta imagjinonte në fillim të dekadës.
Natyrisht, shpallja e çdo shërbimi të ri në cloud u shoqërua me diskutime të shumta nga ekspertët në Twitter, duke përfshirë debate mbi fundin e epokës së kodit të hapur, rënien e IT-së në vendin e klientëve (IT on-premises), pashmangshmërinë e një monopoli të ri të softuerit në cloud, dhe si paradigma e re X do të zëvendësonte të gjitha paradimat e tjera.
A është e nevojshme të thuash se të gjitha këto debate ishin mjaft të këqija?
Realiteti është se asgjë nuk do të zhduket, dhe sot mund të vërehet një rritje eksponenciale e produkteve përfundimtare dhe mënyrave të të zhvilluarit të tyre, që lidhet me shfaqjen e vazhdueshme të softuerit të ri në jetën tonë. Dhe ndonëse çdo gjë do të ndryshojë, në thelb gjithçka do të mbetet e pandryshuar. Zhvilluesit e softuerit do të vazhdojnë të shkruajnë kod me gabime, inxhinierët e operacionit dhe specialistët për qëndrueshmëri do të vazhdojnë të mbajnë pajisje ndihmëse dhe të marrin njoftime automatike në Slack, menaxherët do të operojnë gjithashtu me konceptet e OpEx dhe CapEx, dhe çdo herë që ndodh një dështim, zhvilluesi kryesor do të thotë me keqardhje: 'Të thashë unë'...
Çfarë vërtet duhet të diskutohet, është se cilat mjete mund të kemi në dispozicion për të krijuar produkte softueri më cilësore dhe si ato mund të rrisin sigurinë dhe ta bëjnë zhvillimin më të lehtë dhe më të sigurt. Me rritjen e kompleksitetit të projekteve, shfaqen gjithashtu rreziqe të reja, dhe sot jeta e njerëzve është kaq e lidhur me softuerin saqë zhvilluesit thjesht duhet të përpiqen të bëjnë punën e tyre më mirë.
Kubernetes është një nga këto mjete. Po punohet për të bashkuar atë me mjete dhe shërbime të tjera brenda Red Hat OpenShift në një platformë të vetme që do t'u mundësonte të bënin softuerin më të besueshëm, më të lehtë për t'u menaxhuar dhe më të sigurt për përdoruesit.
Duke marrë parasysh këto, ekipi i OpenShift bëhet me një pyetje të thjeshtë:
Si mund ta bëjmë punën me Kubernetes më të lehtë dhe më të qartë?
Përgjigjja është befas e qartë:
- të automatizojmë momentet e komplikuara në shpërndarjen në cloud ose jashtë cloud;
- të përqendrohemi në qëndrueshmëri, duke fshehur kompleksitetin;
- të vazhdojmë punën e vazhdueshme për të nxjerrë versione të thjeshta dhe të sigurta;
- të arrijmë kontrollueshmërinë dhe mundësinë e auditimit;
- të synojmë që nga fillimi të ofrojmë siguri të lartë, por jo me kosto të përdorshmërisë.
Lëshimi i ardhshëm i OpenShift duhet të marrë parasysh si përvojën e krijuesve ashtu edhe përvojën e zhvilluesve të tjerë, të cilët zbatojnë softuerin në skalë të gjerë në kompanitë më të mëdha në botë. për më tepër, duhet të merret parasysh e gjithë përvoja e grupeve të hapura, të cilat sot qëndrojnë në thelb të botës moderne. Në të njëjtën kohë, duhet të largohemi nga mentaliteti i vjetër i zhvilluesit amator dhe të kalojmë në një filozofi të re të së ardhmes automatizuese. Kjo duhet të jetë një 'urë' midis mënyrave të vjetra dhe atyre të reja të shpërndarjes së softuerit dhe të shfrytëzojë plotësisht të gjithë infrastrukturën e disponueshme - nuk ka rëndësi nëse shërbehet nga ofruesi kryesor i cloud-it ose ekzekutohet në sisteme të vogla në periferi.
Si të arrijmë një rezultat të tillë?
Në Red Hat është e zakonshme të kryhen punë të mërzitshme dhe të padëshiruara për një kohë të gjatë, në mënyrë që të ruhet komuniteti i krijuar dhe të mos lejohet mbyllja e projekteve në të cilat kompania është e angazhuar. Në komunitetin open-source ka një numër të madh zhvilluesish talentuar, të cilët krijojnë gjëra të jashtëzakonshme – argëtuese, edukative, që hapin mundësi të reja dhe thjesht të bukura, por, sigurisht, askush nuk pret që të gjithë pjesëmarrësit të lëvizin në një drejtim të vetëm ose të ndajnë qëllime të përbashkëta. Përdorimi i kësaj energjie, drejtimi i saj në rrugë të duhur, është shpesh i nevojshëm për zhvillimin e drejtimeve të cilat do të ishin të dobishme për përdoruesit tanë, por njëkohësisht ne duhet të ndjekim 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 më të besueshëm, duke u ndërtuar mbi parimet e open-source. Kompania punoi për zhvillimin e mëtejshëm të këtyre ideve dhe realizimin e tyre, duke zbatuar filozofinë tonë – duke u përpjekur për të siguruar funksionimin e sigurt të gjithë software-it. I gjithë ky punë bazohet në Kubernetes, Linux, në cloud publik, cloud privat dhe në mijëra projekte të tjera që qëndrojnë në themel të ekosistemit tonë digjital modern.
Versioni i ri i OpenShift 4 do të jetë i qartë, automatizuar dhe më natyror
Platforma OpenShift do të funksionojë me sistemet operative Linux më të mira dhe më të besueshme, me mbështetje bare-metal, virtualizim të lehtë, programim automatizimi të infrastrukturës dhe, sigurisht, konteinerë (të cilët në thelb janë thjesht imazhe Linux).
Platforma duhet të jetë e sigurt nga fillimi, por gjithashtu të ofrojë mundësi për iteracione të lehta për zhvilluesit – pra, të ketë mjaft fleksibilitet dhe besueshmëri, duke i lejuar akoma administratorët të kryejnë auditime dhe të sigurojnë lehtësinë e menaxhimit.
Ajo duhet të lejojë ekzekutimin e software-it "si shërbim", dhe të mos çojë në një zgjerim të pakontrolluar të infrastrukturës për operatorët.
Ajo do t'u mundësojë zhvilluesve që të përqendrohen në krijimin e produkteve reale për përdoruesit dhe klientët. Nuk do të ketë nevojë të kaloni nëpër tundimet e konfigurimeve të harduerit dhe software-it, dhe të gjitha komplikimet e rastit do të mbeten në të kaluarën.
OpenShift 4: Platformë NoOps, e cila nuk kërkon mbështetje
Në u përshkruan ato detyra që ndihmuan në formimin e vizionit të kompanisë për OpenShift 4. Ekipi ka për qëllim të thjeshtësojë sa më shumë që të jetë e mundur detyrat e përditshme për eksploatimin dhe mbështetje të softuerit, duke i bërë këto procese të lehta dhe të qeta – si për specialistët e implementimit, ashtu edhe për zhvilluesit. Por si mund të arrijmë këtë qëllim? Si të krijojmë një platformë për ekzekutimin e softuerit që kërkon ndërhyrje minimale? Çfarë do të thotë në të vërtetë NoOps në këtë kontekst?
Nëse përpiqemi të abstenojmë, për zhvilluesit konceptet "serverless" ose "NoOps" përfaqësojnë mjete dhe shërbime që lejojnë fshehjen e përbërësit "operativ" ose minimizimin e këtij barrimi për zhvilluesin.
- Punoni jo me sisteme, por me ndërfaqet e aplikacioneve (API).
- Mos u merrni me implementimin e softuerit – lejojeni që këtë ta bëjë ofruesi.
- Mos u merrni menjëherë me krijimin e një framework-u të madh – filloni me shkresat e vogla që do të shërbejnë si "blloqe ndërtimi", përpiquni që ky kod të punojë me të dhënat dhe ngjarjet, jo me disqet dhe bazat e të dhënave.
Detyra, siç ka qenë gjithnjë, është të përshpejtojë iteracionet gjatë zhvillimit të softuerit, të ofrojë mundësi për krijimin e produkteve më cilësore, dhe që zhvilluesi të mos ketë shqetësim për sistemet në të cilat ekzekutohet softueri i tij. Një zhvillues me përvojë e kupton mirë se nëse përqendrohemi te përdoruesit, situata mund të ndryshojë shpejt, prandaj nuk duhet të investoni shumë përpjekje në shkruarjen e softuerit, nëse nuk keni besim absolut në nevojshmërinë e tij.
Për specialistët që merren me mbështetje dhe operim, fjala "NoOps" mund të tingëllojë paksa frikësuese. Por gjatë komunikimit me inxhinierët e operacioneve, bëhet e qartë se modelet dhe metodologjitë që ata përdorin për të siguruar besueshmërinë e pandërprerë (Site Reliability Engineering, SRE) përputhen në masë të madhe me modelet e përshkruara më sipër:
- Mos menaxhoni sistemet – automatizoni proceset e menaxhimit të tyre.
- Mos u angazhoni në implementimin e software-it – krijoni një pipeline për implementimin e tij.
- Përpiquni të mos bashkoni të gjitha shërbimet tuaja së bashku dhe mos e lejoni që dështimi i njërit prej tyre të shkaktojë dështimin e tërë sistemit – shpërndani ato nëpër infrastrukturë duke përdorur mjete të automatizimit dhe lidhini me një sistem të monitorimit dhe kontrollit.
Specialistët e SRE e dinë që diçka mund të shkojë keq, dhe do t'i duhet të ndjekin dhe të eliminojnë problemin – prandaj automatizojnë punët rutinë dhe përcaktojnë paraprakisht tolerancat për gabime (error budgets) për të qenë të përgatitur për prioritizim dhe marrjen e vendimeve në rast problemi.
Kubernetes në OpenShift është një platformë që synon të zgjidhë dy probleme kryesore: në vend që t'ju detyrojë të merret me makinat virtuale ose API-të e balancuesve të ngarkesës, qasja bëhet përmes abstraksioneve më të larta – me proceset e implementimit dhe shërbimet. Në vend që të instaloni agjentë softuerikë, mund të lançoni kontejnerë, dhe në vend që të shkruani një stack monitorimi tuajin, mund të përdorni mjetet që platforma ofron. Kështu, përbërësi sekret i OpenShift 4 nuk është asgjë më shumë se sa të aplikoni parimet e SRE dhe konceptet serverless, dhe t'i çoni ato deri në përfundim, në ndihmë të zhvilluesve dhe inxhinierëve operacionalë:
- Automatizoni dhe standardizoni infrastrukturën që shërben për aplikacionet.
- Lidhni proceset e implementimit dhe zhvillimit pa limituar zhvilluesit e vet.
- Sigurohuni që fillimi, auditimi dhe sigurimi i sigurisë së shërbimit të njëqindit, funksionit, aplikacionit ose tërë stack-ut të jetë po aq i thjeshtë sa ai i parë.
Por çfarë e ndan platformën OpenShift 4 nga paraardhësit e saj dhe nga qasja 'standard' për zgjidhjen e problemeve të tilla? Si arrin të përmirësojë shkallëzimin për ekipet që merakosen për implementimin dhe operimin? Sepse në këtë situatë, mbreti është klasteri. Pra,
- Bëni që qëllimi i klastereve të jetë i qartë (E shtrenjtë në re, këtë klaster e ngrita sepse mundesha).
- Makinat dhe sistemet operative ekzistojnë për të shërbyer klasterin (Mbreti juaj).
- Menaxhoni gjendjen e hosteve nga klasteri, minimizoni ndryshimet e tyre (drift).
- Për çdo komponent të rëndësishëm të sistemit është e nevojshme një 'nanny' (mekanizëm) që do të përcjellë dhe eliminojë problemet.
- Dështimi i *çdo* aspekti ose elementi të sistemit është një pjesë normale e jetës.
- E gjithë infrastruktura duhet të konfigurohet përmes API-ve.
- Përdorni Kubernetes për të lançuar Kubernetes. (Po, nuk është një gabim shkronjash).
- Përditësimet duhet të instalohen lehtësisht dhe pa ndonjë ndërlikim. Nëse për të instaluar një përditësim kërkohen më shumë se një klik, atëherë duket se po bëjmë diçka gabim.
- Monitorimi dhe debugging i çdo komponente nuk duhet të jetë një problem, për rrjedhojë, ndjekja dhe raportimi për tërë infrastrukturën gjithashtu duhet të jetë e thjeshtë dhe e lehtë.
A doni të shihni mundësitë e platformës në veprim?
Versioni i 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ë ngrini një klaster në AWS mbi Red Hat CoreOS. Për të përfituar nga versioni i paraprak, ju nevojitet vetëm një llogari AWS për të ofruar infrastrukturën dhe një grup llogarish për qasje në imazhet e versionit të paraprak.
- Për të filluar, shkoni te dhe klikoni 'Get Started'.
- Hyni në llogarinë tuaj Red Hat (ose krijoni një të re) dhe ndiqni udhëzimet për të konfiguruar klasterin tuaj të parë.
Pas instalimit të suksesshëm, shikoni materialet tona të trajnimit , për një pasqyrë më të detajuar të sistemeve dhe koncepteve që e bëjnë platformën OpenShift 4 një mjet të thjeshtë dhe të lehtë për të lançuar Kubernetes.
Provo versionin e ri të OpenShift dhe ndaj mendimin tënd. Ne synojmë ta bëjmë përdorimin e Kubernetes sa më të thjeshtë dhe pa mundim – e ardhmja NoOps fillon që sot.
Dhe tani, vëmendje!
Në konferencë Më 20 prill, një nga zhvilluesit e OpenShift, Vadim Rutkovsky do të mbajë një master klasë – do të thyejë dhjetë klasterë dhe do t'i bëjë të riparohen. Konferenca është me pagesë, por me kodin promocional #RedHat, ndihmoheni me 37%.
Master klasa nga 17:15 deri 18:15, dhe stendi do të funksionojë gjatë gjithë ditës. T-shirt, kapele, ngjitëse – si zakonisht!
Salla #2
"Duhet të ndryshojmë të gjithë sistemin: do të riparojmë klasterët k8s të thyer së bashku me mjeshtrat e certifikuar."
Burimi: habr.com
