Red Hat OpenShift plataformaren 4.0 eguneratzearen inguruko aldaketa, hobekuntza eta gehiketei buruzko argitalpenen lehenengoa da, bertsio berrirako trantsizioa prestatzen lagunduko dizutena.
Kubernetes komunitate hasiberria 2014ko udazkenean Google-ren Seattleko bulegoan lehen aldiz bildu zen unetik, argi zegoen Kubernetes proiektua gaur egun softwarea garatzeko eta zabaltzeko modua iraultzera zuzenduta zegoela. Aldi berean, hodeiko zerbitzu-hornitzaileek aktiboki inbertitzen jarraitu zuten azpiegituren eta zerbitzuen garapenean, eta horrek IT-arekin lan egitea eta softwarea sortzea askoz errazagoa eta eskuragarriago bihurtu zuen, eta izugarri irisgarri bihurtu ziren, gutxik imajina zezakeen hasieran. hamarkadan.
Jakina, hodeiko zerbitzu berri bakoitzaren iragarpenarekin Twitter-eko adituen arteko eztabaida ugarirekin batera, eta eztabaidak egin ziren hainbat gairen inguruan, besteak beste, kode irekiko aroaren amaiera, IT lokalaren gainbehera eta ezinbestekotasuna. software monopolio berri baten hodeian, eta X paradigma berriak beste paradigma guztiak nola ordezkatuko dituen.
Esan beharrik ez dago auzi hauek guztiak oso ergelak zirela
Errealitatea da ezer ez dela desagertuko, eta gaur egun amaierako produktuen eta garatzeko moduaren hazkunde esponentziala ikus dezakegu, gure bizitzan software berrien etengabeko agerpenaren ondorioz. Eta inguruan dena aldatuko den arren, aldi berean, funtsean, dena aldatu gabe geratuko da. Software garatzaileek akatsekin kodea idatziko dute oraindik, operazio-ingeniariek eta fidagarritasun-espezialistek orriekin ibiliko dira eta alerta automatikoak jasoko dituzte Slack-en, kudeatzaileek OpEx eta CapEx kontzeptuetan funtzionatuko dute, eta hutsegite bat gertatzen den bakoitzean, garatzailea seniorrak. hasperen egingo du triste hitzekin: "Esan dizut"...
benetan eztabaidatu beharko litzateke, zer tresna izan ditzakegun software produktu hobeak sortzeko, eta nola hobetu dezaketen segurtasuna eta garapena errazagoa eta fidagarriagoa izan dadin. Proiektuaren konplexutasuna handitzen doan heinean, arrisku berriak ere handitzen dira, eta gaur egun pertsonen bizitza softwarearen menpe dago, non garatzaileek lan hobea egiten saiatu behar dute.
Kubernetes da horrelako tresna bat. Red Hat OpenShift beste tresna eta zerbitzu batzuekin konbinatzeko lanak egiten ari dira plataforma bakar batean, softwarea fidagarriagoa, kudeatzeko errazagoa eta erabiltzaileentzat seguruagoa izango litzatekeena.
Hori esanda, OpenShift taldeak galdera sinple bat egiten du:
Nola egin dezakezu Kubernetesekin lan egitea errazagoa eta erosoagoa?
Erantzuna harrigarriro agerikoa da:
- Hodeian edo hodeitik kanpo hedapenaren alderdi konplexuak automatizatzea;
- fidagarritasunari arreta jarri konplexutasuna ezkutatuz;
- jarraitu etengabe eguneratze errazak eta seguruak askatzeko lanean;
- kontrolagarritasuna eta ikuskargarritasuna lortzea;
- ahalegindu hasiera batean segurtasun handia bermatzen, baina ez erabilgarritasunaren kaltetan.
OpenShift-en hurrengo bertsioak sortzaileen esperientzia eta munduko enpresa handienetan softwarea eskala handian ezartzen ari diren beste garatzaile batzuen esperientzia hartu beharko luke kontuan. Horrez gain, gaur egungo mundu modernoaren oinarrian dauden ekosistema irekietan pilatutako esperientzia guztia kontuan hartu behar du. Aldi berean, garatzaile amateurren aurreko mentalitatea alde batera utzi eta etorkizun automatizatu baten filosofia berri batera pasa behar da. Softwarea zabaltzeko modu zaharren eta berrien arteko aldea gainditu behar du, eta erabilgarri dauden azpiegitura guztiak aprobetxatu behar ditu, hodeiko hornitzaile handienak ostatatuta edo ertzean dauden sistema txikietan exekutatzen den.
Nola lortu emaitza hori?
Red Hat-en ohikoa da denbora luzez lan aspergarriak eta eskergabeak egitea, ezarritako komunitatea gordetzeko eta enpresak parte hartzen duen proiektuak ixtea saihesteko. Kode irekiko komunitateak gauza apartekoenak sortzen dituzten talentu handiko garatzaile ugari ditu: entretenigarriak, hezigarriak, aukera berriak irekitzen dituztenak eta, besterik gabe, ederrak, baina, noski, inork ez du espero parte-hartzaile guztiak norabide berean mugitzea edo komunetara jotzea. helburuak. Energia hori aprobetxatzea eta norabide egokian birbideratzea beharrezkoa da batzuetan gure erabiltzaileei mesede egingo liekeen eremuak garatzeko, baina, aldi berean, gure komunitateen garapena kontrolatu eta haietatik ikasi behar dugu.
2018 hasieran, Red Hat-ek CoreOS proiektua eskuratu zuen, etorkizunari buruzko antzeko ikuspegiak zituena - seguruagoa eta fidagarriagoa, kode irekiko printzipioetan sortua. Konpainiak ideia hauek gehiago garatzen eta inplementatzen lan egin du, gure filosofia praktikan jarriz, software guztiak segurtasunez exekutatzen direla ziurtatzen saiatuz. Lan hau guztia Kubernetes, Linux, hodei publikoak, hodei pribatuak eta gure ekosistema digital modernoa eusten duten beste milaka proiektutan eraikita dago.
OpenShift 4-ren bertsio berria argia, automatizatua eta naturalagoa izango da
OpenShift plataformak Linux sistema eragile onenekin eta fidagarrienekin funtzionatuko du, hardware hutsezko euskarria, birtualizazio erosoa, azpiegituren programazio automatikoa eta, jakina, edukiontziekin (funtsean Linux irudiak besterik ez direnak).
Plataformak segurua izan behar du hasiera-hasieratik, baina hala ere garatzaileei erraz errepikatzeko aukera ematen die, hau da, nahikoa malgua eta segurua izan behar du administratzaileek erraz ikuskatu eta kudeatzeko aukera ematen dieten bitartean.
Softwarea "zerbitzu gisa" exekutatzeko aukera eman beharko luke eta ez operadoreentzako azpiegitura kudeatu ezineko hazkunderik ekarri.
Garatzaileek erabiltzaile eta bezeroentzako benetako produktuak sortzera bideratu ahal izango dituzte. Ez duzu hardware eta software ezarpenen oihanean barrena ibili beharko, eta ustekabeko konplikazio guztiak iraganeko gauza izango dira.
OpenShift 4: mantentze-lanak behar ez dituen NoOps plataforma
Π enpresak OpenShift 4rako duen ikuspegia moldatzen lagundu zuten zeregin horiek deskribatu zituen. Taldearen helburua softwarea ustiatzeko eta mantentzeko eguneroko zereginak ahalik eta gehien erraztea da, prozesu horiek errazak eta lasaiak izan daitezen, bai inplementazioan parte hartzen duten espezialistentzat, bai garatzaileentzat. Baina nola hurbil zaitezke helburu horretara? Nola sortu esku-hartze minimoa behar duen softwarea exekutatzeko plataforma bat? Zer esan nahi du NoOps-ek testuinguru honetan?
Abstrakzioa egiten saiatzen bazara, garatzaileentzat "zerbitzaririk gabeko" edo "NoOps" kontzeptuek osagai "operatiboa" ezkutatzeko edo garatzailearentzat zama hori gutxitzeko aukera ematen duten tresnak eta zerbitzuak esan nahi dute.
- Ez lan egin sistemekin, baizik eta aplikazioen interfazeekin (API).
- Ez kezkatu softwarea inplementatzen - utzi hornitzaileak zure ordez egiten.
- Ez zenuke berehala marko handi bat sortzera salto egin behar; hasi "eraikuntza-bloke" gisa funtzionatuko duten pieza txikiak idazten, saiatu kode honek datu eta gertaerekin funtziona dezan, eta ez disko eta datu-baseekin.
Helburua, lehen bezala, softwarearen garapenean errepikapenak bizkortzea da, produktu hobeak sortzeko aukera eskaintzea eta garatzaileak bere softwareak exekutatzen dituen sistemez kezkatu beharrik izan ez dezan. Esperientziadun garatzaile batek ondo daki erabiltzaileengan arreta jartzeak argazkia azkar alda dezakeela, beraz, ez zenuke ahalegin handiegirik egin behar softwarea idazteko beharrezkoa dela guztiz ziur ez bazaude.
Mantentze- eta operazio-profesionalentzat, "NoOps" hitzak beldur samarra izan dezake. Baina eremuko ingeniariekin komunikatzean, bistakoa da fidagarritasuna eta fidagarritasuna bermatzera bideratutako erabiltzen dituzten eredu eta teknikek (Site Reliability Engineering, SRE) antzekotasun asko dituztela goian deskribatutako ereduekin:
- Ez kudeatu sistemak - automatizatu haien kudeaketa-prozesuak.
- Ez inplementatu softwarea - sortu kanalizazio bat zabaltzeko.
- Saihestu zure zerbitzu guztiak batera biltzea eta baten hutsegiteak sistema osoa huts egiten uztea; sakabanatu zure azpiegitura osoan automatizazio-tresnak erabiliz, eta konektatu monitorizatu eta kontrolatu daitezkeen moduetan.
SREek badakite zerbait oker egon daitekeela eta arazoa bilatu eta konpondu beharko dutela; beraz, ohiko lana automatizatzen dute eta errore-aurrekontuak ezartzen dituzte aldez aurretik, arazoren bat sortzen denean lehentasunak emateko eta erabakiak hartzeko prest egon daitezen.
OpenShift-en Kubernetes bi arazo nagusi konpontzeko diseinatutako plataforma bat da: makina birtualak edo karga-orekatzaileen APIak ulertzera behartu beharrean, goi mailako abstrakzioekin lan egiten du - inplementazio-prozesuak eta zerbitzuak. Software-agenteak instalatu beharrean, edukiontziak exekutatu ditzakezu eta zure monitorizazio-pila idatzi beharrean, plataforman dagoeneko eskuragarri dauden tresnak erabili. Beraz, OpenShift 4-ren saltsa sekretua ez da sekretua - SRE printzipioak eta zerbitzaririk gabeko kontzeptuak hartu eta ondorio logikora eramatea besterik ez da garatzaileei eta operazio-ingeniariei laguntzeko:
- Aplikazioek erabiltzen duten azpiegitura automatizatu eta estandarizatu
- Lotu hedapen- eta garapen-prozesuak elkarrekin garatzaileak beraiek mugatu gabe
- XNUMX. zerbitzua, eginbidea, aplikazioa edo pila osoa abian jartzea, ikuskatzea eta ziurtatzea lehena baino zailagoa ez dela ziurtatzea.
Baina zer desberdintasun dago OpenShift 4 plataformaren eta bere aurrekoen eta horrelako arazoak konpontzeko ikuspegi "estandarra"ren artean? Zerk bultzatzen du eskala inplementazio eta eragiketa taldeetarako? Egoera horretan dagoen erregea klusterra delako. Beraz,
- Ziurtatzen dugu klusterren helburua argi dagoela (Hodei maitea, kluster hau jaso nuen ahal nuelako)
- Makinak eta sistema eragileak daude clusterra zerbitzatzeko (Zure Maiestatea)
- Kudeatu ostalarien egoera clusterretik, gutxitu haien berreraikuntza (derrift).
- Sistemaren elementu garrantzitsu bakoitzerako, umezain bat (mekanismoa) behar da, arazoak kontrolatu eta ezabatuko dituena
- Sistema baten *alderdi edo elementu guztien* eta lotutako berreskuratze-mekanismoen porrota bizitzaren zati normala da
- Azpiegitura osoa API bidez konfiguratu behar da.
- Erabili Kubernetes Kubernetes exekutatzeko. (Bai, bai, hori ez da akatsa)
- Eguneraketak erraz eta arazorik gabe instalatu behar dira. Eguneratze bat instalatzeko klik bat baino gehiago behar bada, jakina, zerbait gaizki egiten ari gara.
- Edozein osagairen jarraipena eta arazketa ez da arazorik izan behar, eta, beraz, azpiegitura osoan jarraipena eta txostenak egitea ere erraza eta erosoa izan behar da.
Plataformaren gaitasunak martxan ikusi nahi dituzu?
OpenShift 4-ren aurrebista bertsio bat garatzaileentzat eskuragarri egon da. Erabiltzeko erraza den instalatzaile batekin, AWS-n kluster bat exekutatu dezakezu Red Had CoreOS-en gainean. Aurrebista erabiltzeko, AWS kontu bat baino ez duzu behar azpiegitura hornitzeko eta kontu multzo bat aurrebista irudietara sartzeko.
- Hasteko, joan hona eta egin klik "Hasi".
- Hasi saioa Red Hat-eko kontuan (edo sortu berri bat) eta jarraitu argibideei zure lehen clusterra konfiguratzeko.
Instalatu ondoren, begiratu gure tutorialak OpenShift 4 plataforma Kubernetes exekutatzeko modu erraz eta erosoa bihurtzen duten sistemak eta kontzeptuak sakonago ezagutzeko.
Probatu OpenShift bertsio berria eta partekatu zure iritzia. Kumbernetesekin lan egitea ahalik eta eskuragarrien eta esfortzurik gabe egiteko konpromisoa hartu dugu β NoOps-en etorkizuna gaur hasten da.
Eta orain arreta!
Jardunaldian Apirilaren 20an, OpenShift-eko garatzaileetako batek, Vadim Rutkovskyk, klase magistral bat egingo du - hamar kluster hautsi eta horiek konpontzera behartuko ditu. Jardunaldia ordainpekoa da, baina #RedHat promozio-kodearekin %37ko deskontua lortzen duzu
Master class 17:15 - 18:15, eta standa egun osoan dago zabalik. Kamisetak, txapelak, pegatinak - ohikoa!
Aretoa #2
"Hemen sistema osoa aldatu behar da: hautsitako k8s klusterrak konpontzen ditugu ziurtatutako mekanikariekin".
Iturria: www.habr.com