Šis ir pirmais raksts materiālu sērijā, kas veltīta izmaiņām, uzlabojumiem un papildinājumiem gaidāmajā Red Hat OpenShift 4.0 platformas atjauninājumā, kas palīdzēs sagatavoties pārejai uz jauno versiju.
No brīža, kad 2014. gada rudenī Google birojā Sietlā pirmo reizi sanāca tikai vēl veidojošās Kubernetes kopienas pārstāvji, jau varēja teikt, ka projektam Kubernetes ir lemts pamatīgi mainīt mūsdienu pieejas programmatūras izstrādē un ieviešanā. Tajā pašā laikā publiskie mākoņu pakalpojumu sniedzēji turpināja aktīvi ieguldīt infrastruktūras un pakalpojumu attīstībā, kas ievērojami atviegloja un vienkāršoja darbu ar IT un programmatūras izstrādi, kā arī padarīja to neticami pieejamu, ko maz kurš spēja iedomāties tā gadsimta sākumā.
Protams, katra jaunā mākoņu pakalpojuma paziņošanu pavadīja daudzas ekspertu diskusijas Twitter, un strīdos tika apspriesti visdažādākie temati – tostarp par atvērtā koda ēras beigām, par IT beigas vietējo risinājumu pusē (on-premises IT), par jaunas programmatūras monopola neizbēgamību mākoņos un par to, kā jauna paradigma X nomainīs visus pārējos paradigmas.
Vai vajag teikt, ka visas šīs strīdi bija visai muļķīgas?
Realitāte ir tāda, ka nekas nekur nepazudīs, un šodien var redzēt eksponenciālu beigu produktu un to izstrādes veidu pieaugumu, kas saistīts ar jaunu programmatūru parādīšanos mūsu dzīvē. Un, neskatoties uz to, ka viss ap mums mainīsies, apstākļi savā būtībā paliks nemainīgi. Programmatūras izstrādātāji turpinās rakstīt kodu ar kļūdām, operāciju inženieri un uzticamības speciālisti turpinās staigāt ar pageriem un saņemt automātiskus paziņojumus Slack, vadītāji joprojām strādās ar OpEx un CapEx jēdzieniem, un katru reizi, kad notiks traucējumi, vecākais izstrādātājs skumji ievilks elpu, sakot: "Es taču teicu…".
Kas tiešām būtu jāpārrunā, tā ir, kādi rīki mums ir pieejami, lai radītu kvalitatīvākus programmatūras produktus, un kā tie ļauj uzlabot drošību un padarīt izstrādi vienkāršāku un uzticamāku. Pieaugot projektu sarežģītībai, parādās jauni riski, un šodien cilvēku dzīvība ir tik atkarīga no programmatūras, ka izstrādātājiem vienkārši jācenšas darīt savu darbu labāk.
Kubernetes ir viens no tādiem rīkiem. Tiek veikts darbs pie tā, lai Red Hat OpenShift ietvaros apvienotu to ar citiem rīkiem un pakalpojumiem vienotā platformā, kas padarītu programmatūru uzticamāku, viegli pārvaldāmu un drošu lietotājiem.
Ņemot vērā teikto, OpenShift komanda uzdod vienkāršu jautājumu:
Kā var padarīt darbu ar Kubernetes vienkāršāku un ērtāku?
Atbilde, par brīnumu, ir acīmredzama:
- automatizēt sarežģītos momentus mākoņa vai ārpus mākoņa izvietošanā;
- koncentrēties uz uzticamību, slēpjot sarežģītību;
- turpināt pastāvīgu darbu pie vienkāršu un drošu atjauninājumu izdošanas;
- iegūt kontrolējamību un audita iespējas;
- censties sākotnēji nodrošināt augstu drošību, bet ne uz lietojamības rēķina.
Nākamajam OpenShift laidienam jāņem vērā gan radītāju pieredze, gan citu izstrādātāju pieredze, kuri ievieš programmatūru lielos mērogos vislielākajās pasaules uzņēmumos. Turklāt tajā jāņem vērā visa uzkrātā pieredze atvērtajās ekosistēmās, kas šodien veido mūsdienu pasaules pamatu. Tajā pašā laikā ir jāpārtrauc iepriekšējā izstrādātāju hobiju mentalitāte un jāpāriet uz jaunu automatizētu nākotnes filozofiju. Tas jābūt „tiltam” starp iepriekšējiem un jauniem programmatūras ievietošanas veidiem un pilnībā jāizmanto visa pieejamā infrastruktūra – nav svarīgi, vai to apkalpo lielākais mākoņu pakalpojumu sniedzējs vai tā darbojas mazās perifērijas sistēmās.
Kā sasniegt šādu rezultātu?
Red Hat ir pieņemts veikt garlaicīgu un nepatīkamu darbu, lai saglabātu izveidojušos kopienu un nepieļautu projektu, kuros uzņēmums piedalās, slēgšanu. Atvērtā koda kopienā ir milzīgs daudzums talantīgu izstrādātāju, kuri rada visneparastākās lietas – izklaidējošas, izglītojošas, atklāj jaunas iespējas un vienkārši skaistas, bet protams, neviens negaida, ka visi dalībnieki virzīsies vienā virzienā vai sekos kopīgiem mērķiem. Šīs enerģijas izmantošana, tās novirzīšana pareizajā virzienā dažkārt ir nepieciešama, lai attīstītu virzienus, kas varētu būt noderīgi mūsu lietotājiem, bet tajā pašā laikā mums jāseko mūsu kopienu attīstībai un jāmācās no tām.
2018. gada sākumā Red Hat iegādājās CoreOS projektu, kuram bija līdzīgi uzskati par nākotni – drošāku un uzticamāku, kas veidota uz atvērtā koda principiem. Uzņēmums strādāja pie šo ideju tālākas attīstības un to īstenošanas, īstenojot mūsu filozofiju – tiecoties nodrošināt drošu visu programmatūras darbību. Visa šī darba pamatā ir Kubernetes, Linux, publiskie mākoņi, privātie mākoņi un tūkstošiem citu projektu, kas veido mūsu mūsdienu digitālo ekosistēmu.
Jaunais OpenShift 4 laidens būs saprotams, automatizēts un dabisks.
OpenShift platforma darbosies ar labākajām un uzticamākajām Linux operētājsistēmām, bare-metal aparatūras atbalstu, ērtu virtualizāciju, automātisku infrastruktūras programmēšanu un, protams, konteineriem (kuri pamatā ir tikai Linux attēli).
Platformai jābūt drošai jau kopš sākuma, bet tai tajā pašā laikā jānodrošina izstrādātājiem ērtas iterācijas – tas ir, tai jābūt pietiekami elastīgai un uzticamai, turklāt joprojām jāļauj administratoriem veikt auditu un nodrošināt ērtu pārvaldību.
Tā jāļauj palaist programmatūru 'kā pakalpojumu', un nedrīkst izraisīt nepārvaldītu infrastruktūras pieaugumu operatoriem.
Tas ļaus izstrādātājiem koncentrēties uz reālu produktu radīšanu lietotājiem un klientiem. Nebūs jākļūst sajauktam ar aparatūras un programmatūras iestatījumu mežonību, un visas nejaušās komplikācijas paliks pagātnē.
OpenShift 4: NoOps platforma, kurai nav nepieciešama apkalpošana
No tika aprakstītas tās problēmas, kas palīdzēja veidot uzņēmuma redzējumu attiecībā uz OpenShift 4. Komandas uzdevums ir maksimāli vienkāršot ikdienas uzdevumus programmatūras izmantošanā un apkalpošanā, padarīt šos procesus vieglus un nepiespiestus – gan implementācijas speciālistiem, gan izstrādātājiem. Bet kā var tuvoties šim mērķim? Kā izveidot platformu programmatūras palaišanai, kas prasa minimālu iejaukšanos? Ko vispār nozīmē NoOps šajā kontekstā?
Ja mēģina abstrahēties, tad izstrādātājiem jēdzieni „serverless” vai „NoOps” nozīmē rīkus un pakalpojumus, kas ļauj noslēpt “izpildes” komponenti vai minimizēt šo nastu izstrādātājam.
- Strādājiet nevis ar sistēmām, bet gan ar lietojumprogrammu interfeisiem (API).
- Nesāciet programmatūras ieviešanu – ļaujiet to darīt pakalpojumu sniedzējam.
- Nepieņemiet uzreiz veidot lielu ietvaru – sāciet ar mazu fragmentu rakstīšanu, kas kalpos par „būvniecības blokiem”, cenšoties, lai šis kods darbotos ar datiem un notikumiem, nevis ar diskiem un datu bāzēm.
Uzdevums, kā agrāk, ir paātrināt iterācijas programmatūras izstrādē, nodrošināt iespēju radīt kvalitatīvākus produktus, un lai izstrādātājs varētu neuztraukties par sistēmām, uz kurām tiek palaista viņa programmatūra. Pieredzējis izstrādātājs lieliski saprot, ka, koncentrējoties uz lietotājiem, aina var ātri mainīties, tāpēc nevajadzētu ieguldīt pārāk daudz pūļu programmatūras rakstīšanā, ja nav absolūtas pārliecības par tās nepieciešamību.
Speciālistiem, kuri nodarbojas ar uzturēšanu un ekspluatāciju, vārds «NoOps» var šķist nedaudz biedējošs. Taču sarunājoties ar inženieriem, kas atbild par ekspluatāciju, kļūst acīmredzams, ka viņu izmantotie paraugi un metodes, kuru mērķis ir nodrošināt uzticamību (Site Reliability Engineering, SRE), lielā mērā sakrīt ar iepriekš minētajiem paraugiem:
- Nepārvaldiet sistēmas – automatizējiet to pārvaldīšanas procesus.
- Nedariet programmatūras ieviešanu – izveidojiet pipelines tās izvietošanai.
- Centieties nesalikt visus savus pakalpojumus kopā un nepieļaut, lai viena no tām atteikšanās radītu visas sistēmas atteikšanos – izklīstiet tos pa visu infrastruktūru, izmantojot automatizācijas rīkus, un savienojiet tos, paredzot iespēju kontrolēt un novērot.
SRE speciālisti apzinās, ka kaut kas var noiet greizi, un viņiem būs jāuzrauga un jānovērš problēma – tāpēc viņi automatizē rutīnas darbu un iepriekš nosaka pieļaujamās novirzes (error budgets), lai būtu gatavi prioritāšu noteikšanai un lēmumu pieņemšanai problēmu gadījumā.
Kubernetes OpenShift ietvaros ir platforma, kas risina divus galvenos uzdevumus: vietā, lai liktu jums iedziļināties virtuālajās mašīnās vai balansa rīku API, tiek strādāts ar augstāka līmeņa abstrakcijām – izplatīšanas procesiem un pakalpojumiem. Vietā, lai instalētu programmatūras aģentus, varat palaist konteinerus, bet vietā, lai rakstītu savu monitoringa steku, izmantot jau pieejamos rīkus platformā. Tādējādi OpenShift 4 slepenais ingridients patiesībā nav nekāda noslēpums – vienkārši jāņem vērā SRE principi un serverless koncepcijas un jāattīsta tās līdz loģiskam noslēgumam, lai atbalstītu izstrādātājus un ekspluatācijas inženierus:
- Automatizēt un standartizēt infrastruktūru, kas tiek izmantota lietotnēs.
- Savienot kopā izvietošanas un izstrādes procesus, nepārkāpjot pašus izstrādātājus.
- Panākt, lai simtā pakalpojuma, funkcijas, lietotnes vai visa steka palaišana, audits un drošības nodrošināšana būtiski neatšķirtos no pirmā.
Bet par kā OpenShift 4 atšķiras no savām iepriekšējām versijām un no "standarta" pieejas šo problēmu risināšanai? Kā tiek panākta komandu, kas nodarbojas ar ieviešanu un ekspluatāciju, mērogošana? Tas viss ir atkarīgs no tā, ka ķēde šajā situācijā ir klasteris. Tātad,
- Darām tā, lai klasteru mērķis būtu skaidrs (Dārgi mākoni, šo klasteri es izveidoju, jo varēju)
- Mašīnas un operētājsistēmas pastāv, lai apkalpotu klasteri (Jūsu Augstība)
- Pārvaldiet hostu stāvokli no klastera, minimizējiet to atkārtošanās (drift).
- Katram svarīgajam sistēmas elementam ir nepieciešams uzraugs (mehānisms), kas sekos un novērsīs problēmas
- Katra aspekta vai elementa sistēmā atteice ir saistīta ar atbilstošajiem atjaunošanas mehānismiem — tā ir ierasta lieta.
- Visai infrastruktūrai jābūt konfigurējamai caur API.
- Izmantojiet Kubernetes, lai palaistu Kubernetes. (Jā, jā, tas nav drukas kļūda)
- Atjauninājumiem jābūt instalējamiem viegli un nemanāmi. Ja atjauninājuma instalēšanai nepieciešami vairāk par vienu peles klikšķi, skaidrs, ka mēs kaut ko nedarām pareizi.
- Uzraudzībai un jebkura komponenta atkļūdošanai nevajadzētu sagādāt problēmas, attiecīgi arī visu infrastruktūru uzraudzīt un ziņot par tās stāvokli vajadzētu būt vienkārši un ērti.
Vēlaties redzēt platformas iespējas darbībā?
OpenShift 4 priekšskatījuma versija ir pieejama izstrādātājiem. Izmantojot vienkāršu uzstādīšanas rīku, varat palaist klasteri uz AWS virs Red Hat CoreOS. Lai izmantotu priekšskatījuma versiju, nepieciešama tikai AWS konts infrastruktūras nodrošināšanai un komplekts kontu piekļuvei priekšskatījuma attēliem.
- Lai uzsāktu darbu, dodieties uz un noklikšķiniet uz "Get Started".
- Ierakstieties savā Red Hat kontā (vai izveidojiet jaunu) un sekojiet norādījumiem, lai iestatītu savu pirmo klasteri.
Pēc veiksmīgas instalēšanas iepazīstieties ar mūsu apmācību materiāliem , lai iegūtu detalizētāku pārsatu par sistēmām un konceptiem, kas padara OpenShift 4 par tik vienkāršu un ērtu rīku Kubernetes palaišanai.
Izmēģiniet jauno OpenShift versiju un dalieties savās domās. Mēs cenšamies padarīt darbu ar Kubernetes pēc iespējas pieejamāku un bez piepūles – NoOps nākotne sākas jau šodien.
Pievērsiet uzmanību!
Konferencē 20. aprīlī viens no OpenShift izstrādātājiem, Vadims Rutkovskis, vadīs meistarklasi – salauzīs desmit klasterus un liks tos salabot. Konference ir maksas, bet ar promo kodu #RedHat atlaide 37%
Meistarklase no 17:15 līdz 18:15, bet stends strādā visu dienu. T-krekli, cepures, uzlīmes – kā parasti!
Zāle #2
„Šeit ir jāmaina visa sistēma: labojam salauztos k8s klasterus kopā ar sertificētiem meistariem.”
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
Finnish
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish