Det hÀr Àr den första publikation i en serie material som handlar om förÀndringar, förbÀttringar och tillÀgg i den kommande uppdateringen av plattformen Red Hat OpenShift till version 4.0, som hjÀlper till att förbereda övergÄngen till den nya versionen.
Redan frÄn det ögonblick dÄ representanter för det nybildade Kubernetes-gemenskapen samlades pÄ hösten 2014 i Googles kontor i Seattle, stod det klart att projektet Kubernetes var Àmnat att förÀndra de moderna metoderna för programvaruutveckling och implementering. Samtidigt fortsatte offentliga molnleverantörer att investera aktivt i utvecklingen av infrastruktur och tjÀnster, vilket vÀsentligt underlÀttade IT-arbetet och skapandet av programvara, vilket gjorde dem otroligt tillgÀngliga, nÄgot som fÄ kunde förestÀlla sig i början av decenniet.
SjĂ€lvklart Ă„tföljdes varje nytt molntjĂ€nstlansering av omfattande diskussioner bland experter pĂ„ Twitter, dĂ€r debatten spĂ€nde över mĂ„nga Ă€mnen â inklusive slutet pĂ„ den öppna kĂ€llkodseran, nedgĂ„ngen för lokala IT-lösningar (on-premises IT), den oundvikliga uppkomsten av ett nytt programvarumonopol i molnet och hur den nya X-paradigmen kommer att ersĂ€tta alla andra paradigmer.
Det Àr vÀrt att nÀmna att alla dessa diskussioner var ganska dumma.
Verkligheten Ă€r att inget försvinner, och i dag kan vi se en exponentiell tillvĂ€xt av slutprodukter och sĂ€tt att utveckla dem, vilket hĂ€nger samman med stĂ€ndigt nya programvaror som dyker upp i vĂ„ra liv. Trots att allt runt omkring förĂ€ndras, kommer grunderna förbli oförĂ€ndrade. Programvaruutvecklare kommer fortfarande att skriva kod med buggar, drifttekniker och specialister pĂ„ tillförlitlighet kommer fortsĂ€tta att bĂ€ra pagers och fĂ„ automatiska meddelanden i Slack, chefer kommer fortsĂ€tta att hantera begreppen OpEx och CapEx, och varje gĂ„ng det uppstĂ„r ett fel kommer den seniora utvecklaren att sucka djupt och sĂ€ga: "Jag sa ju det"âŠ
Vad som verkligen borde diskuterasSÄ, vilka verktyg kan vi fÄ tillgÄng till för att skapa mer kvalitativa mjukvaruprodukter och hur gör de det möjligt att öka sÀkerheten och förenkla och förbÀttra utvecklingen? NÀr komplexiteten i projekten ökar, uppstÄr ocksÄ nya risker, och idag Àr mÀnniskors liv sÄ beroende av programvara att utvecklare Àr tvungna att strÀva efter att göra sitt arbete bÀttre.
Kubernetes Àr ett av dessa verktyg. Det pÄgÄr arbete för att integrera det med andra verktyg och tjÀnster inom ramen för Red Hat OpenShift, för att skapa en enhetlig plattform som gör programvara mer pÄlitlig, hanterbar och sÀker för anvÀndarna.
Med detta sagt stÀller OpenShift-teamet sig en enkel frÄga:
Hur kan vi göra arbetet med Kubernetes enklare och mer anvÀndarvÀnligt?
Svaret Àr förvÄnansvÀrt uppenbart:
- att automatisera komplexa moment i distribuerandet bÄde i molnet och pÄ andra platser;
- att fokusera pÄ tillförlitlighet medan komplexiteten döljs;
- att fortsÀtta det stÀndiga arbetet med att slÀppa enkla och sÀkra uppdateringar;
- att uppnÄ kontrollerbarhet och möjlighet till revision;
- att strÀva efter att sÀkerstÀlla hög sÀkerhet frÄn början, utan att tumma pÄ anvÀndarvÀnligheten.
Den nÀsta versionen av OpenShift bör ta hÀnsyn till bÄde utvecklarnas erfarenhet och erfarenheterna frÄn andra utvecklare som pÄ stor skala implementerar programvara i vÀrldens största företag. Dessutom mÄste den beakta all den kunskap som samlats inom öppna ekosystem, som Àr grundlÀggande för den moderna vÀrlden idag. Samtidigt mÄste man överge det tidigare mentaliteten hos hobbymedarbetare och anta en ny filosofi av ett automatiserat framtid. Detta ska vara en "bro" mellan tidigare och nya metoder för programvarudistribution och utnyttja all tillgÀnglig infrastruktur - oavsett om den förvaltas av en stor molnleverantör eller körs pÄ smÄ system vid kanten.
Hur kan vi uppnÄ ett sÄdant resultat?
PĂ„ Red Hat Ă€r det vanligt att man Ă€gnar sig Ă„t lĂ„ngtrĂ„kigt och otacksamt arbete för att bevara det gemenskap som har vuxit fram och för att förhindra att projekt dĂ€r företaget deltar lĂ€ggs ner. Det finns ett stort antal begĂ„vade utvecklare i open-source-gemenskapen som skapar de mest extraordinĂ€ra saker â underhĂ„llande, lĂ€rorika, som öppnar nya möjligheter och helt enkelt vackra, men sjĂ€lvklart förvĂ€ntas ingen att alla deltagare ska röra sig i samma riktning eller ha gemensamma mĂ„l. Att anvĂ€nda denna energi och omdirigera den pĂ„ rĂ€tt sĂ€tt Ă€r ibland nödvĂ€ndigt för att utveckla riktningar som skulle vara till nytta för vĂ„ra anvĂ€ndare, men samtidigt mĂ„ste vi hĂ„lla ett öga pĂ„ vĂ„ra gemenskaper och lĂ€ra av dem.
I början av 2018 förvĂ€rvade Red Hat projektet CoreOS, som hade liknande visioner för framtiden â en sĂ€krare och mer pĂ„litlig plattform som byggs pĂ„ open-source-principer. Företaget arbetade med att vidareutveckla dessa idĂ©er och implementera dem, i linje med vĂ„r filosofi â att strĂ€va efter sĂ€ker drift för all mjukvara. Allt detta arbete bygger pĂ„ Kubernetes, Linux, offentliga moln, privata moln och tusentals andra projekt som ligger till grund för vĂ„rt moderna digitala ekosystem.
Den nya versionen av OpenShift 4 kommer att vara tydlig, automatiserad och mer naturlig.
OpenShift-plattformen kommer att fungera med de bÀsta och mest pÄlitliga Linux-operativsystemen, med bare-metal hÄrdvarustöd, anvÀndarvÀnlig virtualisering, automatisk programmering av infrastrukturen och naturligtvis containrar (som i grund och botten bara Àr Linux-avbilder).
Plattformen mĂ„ste vara sĂ€ker frĂ„n början, men Ă€ndĂ„ ge möjlighet till smidiga iterationer för utvecklarna â det vill sĂ€ga ha tillrĂ€cklig flexibilitet och tillförlitlighet, samtidigt som den fortfarande tillĂ„ter administratörer att genomföra revisioner och sĂ€kerstĂ€lla anvĂ€ndarvĂ€nlig hantering.
Den mÄste möjliggöra körning av mjukvara "som en tjÀnst", utan att leda till en okontrollerad tillvÀxt av infrastrukturen för operatörer.
Det kommer att göra det möjligt för utvecklare att fokusera pÄ att skapa verkliga produkter för anvÀndare och kunder. De behöver inte lÀngre brottas med komplexiteten i hÄrdvaru- och mjukvaruinstÀllningar, och alla eventuella komplikationer kommer att vara ett minne blott.
OpenShift 4: En NoOps-plattform som inte krÀver underhÄll
I De uppgifter som beskrivs har hjÀlpt till att forma företagets vision angÄende OpenShift 4. Teamet har som mÄl att sÄ mycket som möjligt förenkla de dagliga uppgifterna relaterade till drift och underhÄll av programvara, vilket gör dessa processer lÀtta och avslappnade - bÄde för implementeringsspecialister och för utvecklare. Men hur kan man nÀrma sig detta mÄl? Hur skapar man en plattform för att köra programvara som krÀver minimal inblandning? Vad innebÀr NoOps överhuvudtaget i detta sammanhang?
Om vi försöker abstrahera sÄ betyder begreppen "serverless" eller "NoOps" för utvecklare verktyg och tjÀnster som döljer den "driftsmÀssiga" komponenten eller minimerar den bördan för utvecklaren.
- Arbeta inte med system, utan med applikationsgrÀnssnitt (API).
- Ăgna dig inte Ă„t programvaruimplementering â lĂ„t leverantören göra det Ă„t dig.
- Ta inte pĂ„ dig att skapa ett stort ramverk pĂ„ en gĂ„ng â börja med att skriva smĂ„ fragment som fungerar som "byggstenar", och se till att denna kod arbetar med data och hĂ€ndelser snarare Ă€n med diskar och databaser.
MÄlet, som tidigare, Àr att pÄskynda iterationerna vid programvaruutveckling, att möjliggöra skapandet av kvalitetsprodukter, och att utvecklaren kan vara lugn angÄende de system dÀr hans mjukvara körs. En erfaren utvecklare förstÄr att om man fokuserar pÄ anvÀndarna, kan bilden snabbt förÀndras, sÄ det Àr inte vÀrt att lÀgga för mycket tid pÄ att skriva mjukvara om man inte Àr absolut sÀker pÄ dess nödvÀndighet.
För specialister som arbetar med drift och underhĂ„ll kan termen âNoOpsâ lĂ„ta skrĂ€mmande. Men vid samtal med driftsingenjörer blir det uppenbart att de mönster och metoder de anvĂ€nder för att sĂ€kerstĂ€lla tillförlitlighet (Site Reliability Engineering, SRE) i stor utstrĂ€ckning överensstĂ€mmer med de ovan beskrivna mönstren:
- Hantera inte system â automatisera processerna för att styra dem.
- Syssla inte med att implementera programvara â skapa en pipeline för att distribuera den.
- Försök att inte sammanföra alla dina tjĂ€nster och undvik att ett fel i en av dem leder till att hela systemet fallerar â sprid ut dem över hela infrastrukturen med hjĂ€lp av automatiseringsverktyg och koppla ihop dem med möjlighet till övervakning och kontroll.
SRE-specialister vet att nĂ„got kan gĂ„ fel, och de mĂ„ste spĂ„ra och Ă„tgĂ€rda problemet â dĂ€rför automatiserar de sitt rutinarbete och faststĂ€ller pĂ„ förhand tillĂ„tna avvikelser (error budgets) för att vara förberedda pĂ„ prioritering och beslutsfattande nĂ€r problem uppstĂ„r.
Kubernetes i OpenShift Ă€r en plattform som syftar till att lösa tvĂ„ huvudproblem: istĂ€llet för att tvinga dig att hantera virtuella maskiner eller API:er frĂ„n lastbalanserare, arbetar man med högre ordningens abstraktioner â med distributionsprocesser och tjĂ€nster. IstĂ€llet för att installera mjukvaruagenter kan man köra containrar, och istĂ€llet för att skriva en egen övervakningsstack kan man anvĂ€nda de verktyg som redan finns tillgĂ€ngliga pĂ„ plattformen. SĂ„ hemligheten bakom OpenShift 4 Ă€r faktiskt ingen hemlighet â det handlar helt enkelt om att bygga pĂ„ principerna för SRE och serverlösa koncept, och föra dem till sin logiska slutsats till hjĂ€lp för utvecklare och drifttekniker:
- Automatisera och standardisera infrastrukturen som anvÀnds av applikationerna
- Koppla samman distributions- och utvecklingsprocesserna utan att begrÀnsa utvecklarna sjÀlva
- Se till att start, granskning och sÀkerstÀllande av sÀkerheten för den hundrade tjÀnsten, funktionen, applikationen eller hela stacken Àr precis lika enkelt som för den första.
Men vad Àr skillnaden mellan OpenShift 4-plattformen och dess föregÄngare samt den "standard" metodik som anvÀnds för att lösa liknande problem? Hur uppnÄs skalning för team som arbetar med implementering och drift? Genom att kungen i denna situation Àr klustret. SÄ,
- LÄt oss göra syftet med klustren tydligt (Dyra molnet, jag satte upp detta kluster för att jag kunde)
- Maskiner och operativsystem finns för att betjÀna klustret (Ers MajestÀt)
- Hantera tillstÄndet av noder i klustret, minimera deras avvikelser (drift).
- För varje viktigt systemelement behövs en barnvakt (mekanism) som övervakar och löser problem.
- Ett misslyckande av *varje* aspekt eller element i systemet innebÀr att motsvarande ÄterstÀllningsmekanismer Àr en vanlig del av livet.
- Hela infrastrukturen mÄste konfigureras via API.
- AnvÀnd Kubernetes för att köra Kubernetes. (Ja, det Àr inte ett skrivfel)
- Uppdateringar ska installeras enkelt och obehindrat. Om det krÀvs mer Àn ett musklick för att installera en uppdatering, gör vi uppenbarligen nÄgot fel.
- Ăvervakning och felsökning av vilken komponent som helst bör inte vara ett problem, och dĂ€rmed bör Ă€ven spĂ„rning och rapportering av hela infrastrukturen vara enkelt och bekvĂ€mt.
Vill du se plattformens kapacitet i praktiken?
Förhandsversionen av OpenShift 4 har blivit tillgÀnglig för utvecklare. Med hjÀlp av en lÀttanvÀnd installerare kan du sÀtta upp ett kluster pÄ AWS ovanpÄ Red Hat CoreOS. För att anvÀnda förhandsversionen behövs bara ett AWS-konto för att tillhandahÄlla infrastrukturen och ett set av konton för att fÄ tillgÄng till förhandsversionens bilder.
- För att komma igĂ„ng, gĂ„ till och klicka pĂ„ âKom igĂ„ngâ.
- Logga in pÄ ditt Red Hat-konto (eller skapa ett nytt) och följ instruktionerna för att konfigurera ditt första kluster.
Efter en lyckad installation, ta del av vÄra utbildningsmaterial , för att fÄ en mer detaljerad förstÄelse för system och koncept som gör OpenShift 4-plattformen till ett sÄ enkelt och anvÀndarvÀnligt verktyg för att köra Kubernetes.
Prova den nya versionen av OpenShift och dela din Ă„sikt. Vi strĂ€var efter att göra arbetet med Kubernetes sĂ„ tillgĂ€ngligt och enkelt som möjligt â framtiden för NoOps börjar redan idag.
Och nu, uppmÀrksamhet!
Vid konferensen Den 20 april kommer en av utvecklarna av OpenShift, Vadim Rutkovsky, att hĂ„lla en masterklass â han kommer att bryta tio kluster och fĂ„ dem att reparera. Konferensen kostar, men med rabattkoden #RedHat fĂ„r du 37% rabatt.
Masterklassen Ă€r mellan 17:15 och 18:15, och montern Ă€r öppen hela dagen. Tröjor, hattar, klistermĂ€rken â som vanligt!
Sal #2
"HÀr mÄste hela systemet bytas ut: vi lagar trasiga k8s-kluster tillsammans med certifierade tekniker."
KĂ€lla: habr.com
