Detta är det första i en serie inlägg om ändringar, förbättringar och tillägg i den kommande Red Hat OpenShift-plattformen 4.0-uppdateringen som hjälper dig att förbereda dig för övergången till den nya versionen.
Från det ögonblick som den nystartade Kubernetes-gemenskapen först samlades på Googles kontor i Seattle hösten 2014, stod det klart att Kubernetes-projektet var avsett att revolutionera hur mjukvara utvecklas och distribueras idag. Samtidigt fortsatte leverantörer av offentliga molntjänster att aktivt investera i utvecklingen av infrastruktur och tjänster, vilket gjorde arbetet med IT och skapa mjukvara mycket enklare och mer tillgängligt, och gjorde dem otroligt tillgängliga, vilket få kunde ha föreställt sig i början av årtiondet.
Naturligtvis åtföljdes tillkännagivandet av varje ny molntjänst av många diskussioner bland experter på Twitter, och debatter fördes om en mängd olika ämnen - inklusive slutet av öppen källkodseran, nedgången av lokal IT och oundvikligheten av ett nytt mjukvarumonopol i molnet, och hur det nya paradigmet X kommer att ersätta alla andra paradigm.
Det behöver inte sägas att alla dessa tvister var väldigt dumma
Verkligheten är att ingenting någonsin kommer att gå till spillo, och idag kan vi se en exponentiell tillväxt i slutprodukter och hur de utvecklas, på grund av den ständiga uppkomsten av ny mjukvara i våra liv. Och trots det faktum att allt runt omkring kommer att förändras, samtidigt, i huvudsak, kommer allt att förbli oförändrat. Mjukvaruutvecklare kommer fortfarande att skriva kod med fel, driftingenjörer och tillförlitlighetsspecialister kommer fortfarande att gå runt med personsökare och ta emot automatiska varningar i Slack, chefer kommer fortfarande att verka i koncepten OpEx och CapEx, och varje gång ett fel inträffar är senioren utvecklaren kommer att sucka sorgset med orden: "Jag sa det till dig"...
Jasså bör diskuteras, är vilka verktyg vi kan ha till vårt förfogande för att skapa bättre mjukvaruprodukter, och hur de kan förbättra säkerheten och göra utvecklingen enklare och mer tillförlitlig. När projekten blir mer komplexa uppstår nya risker och idag är människors liv så beroende av mjukvara att utvecklare helt enkelt måste försöka göra sitt jobb bättre.
Kubernetes är ett sådant verktyg. Arbete pågår för att kombinera Red Hat OpenShift med andra verktyg och tjänster till en enda plattform som skulle göra programvaran mer tillförlitlig, lättare att hantera och säkrare för användarna.
Med det sagt ställer OpenShift-teamet en enkel fråga:
Hur kan du göra arbetet med Kubernetes enklare och bekvämare?
Svaret är förvånansvärt uppenbart:
- automatisera komplexa aspekter av distribution i molnet eller utanför molnet;
- fokusera på tillförlitlighet och samtidigt dölja komplexitet;
- fortsätta att kontinuerligt arbeta för att släppa enkla och säkra uppdateringar;
- uppnå kontrollerbarhet och revisionsbarhet;
- sträva efter att initialt säkerställa hög säkerhet, men inte på bekostnad av användbarheten.
Nästa version av OpenShift bör ta hänsyn till både skaparnas erfarenhet och erfarenheten från andra utvecklare som implementerar mjukvara i stor skala i de största företagen i världen. Dessutom måste den ta hänsyn till all ackumulerad erfarenhet av öppna ekosystem som ligger till grund för den moderna världen idag. Samtidigt är det nödvändigt att överge den gamla mentaliteten hos amatörutvecklaren och gå över till en ny filosofi om en automatiserad framtid. Den måste överbrygga klyftan mellan gamla och nya sätt att distribuera programvara och dra full nytta av all tillgänglig infrastruktur – oavsett om den är värd hos den största molnleverantören eller körs på små system i kanten.
Hur uppnår man detta resultat?
På Red Hat är det brukligt att göra tråkigt och otacksamt arbete under lång tid för att bevara det etablerade samhället och förhindra nedläggning av projekt som företaget är inblandat i. Gemenskapen med öppen källkod innehåller ett stort antal talangfulla utvecklare som skapar de mest extraordinära sakerna - underhållande, pedagogiska, öppna upp för nya möjligheter och helt enkelt vackra, men naturligtvis förväntar ingen att alla ska gå i samma riktning eller sträva efter gemensamma mål . Att utnyttja denna energi och styra om den i rätt riktning är ibland nödvändigt för att utveckla områden som skulle gynna våra användare, men samtidigt måste vi övervaka utvecklingen av våra samhällen och lära av dem.
I början av 2018 förvärvade Red Hat CoreOS-projektet, som hade liknande syn på framtiden – säkrare och pålitligare, skapat på principer med öppen källkod. Företaget har arbetat med att vidareutveckla dessa idéer och implementera dem, och omsatt vår filosofi i praktiken – att försöka se till att all mjukvara fungerar säkert. Allt detta arbete är byggt på Kubernetes, Linux, offentliga moln, privata moln och tusentals andra projekt som stödjer 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 hårdvarustöd av barmetall, bekväm virtualisering, automatisk infrastrukturprogrammering och, naturligtvis, containrar (som i huvudsak bara är Linux-bilder).
Plattformen måste vara säker från början, men ändå tillåta utvecklare att enkelt iterera – det vill säga vara tillräckligt flexibel och säker samtidigt som administratörer kan granska och hantera den enkelt.
Det bör tillåta programvara att köras "som en tjänst" och inte leda till ohanterlig infrastrukturtillväxt för operatörer.
Det kommer att tillåta utvecklare att fokusera på att skapa riktiga produkter för användare och kunder. Du behöver inte vada genom djungeln av hårdvaru- och mjukvaruinställningar, och alla oavsiktliga komplikationer kommer att vara ett minne blott.
OpenShift 4: NoOps-plattform som inte kräver underhåll
В beskrev de uppgifter som hjälpte till att forma företagets vision för OpenShift 4. Teamets mål är att förenkla de dagliga uppgifterna att driva och underhålla mjukvara så mycket som möjligt, för att göra dessa processer enkla och avslappnade – både för specialister som är involverade i implementering och för utvecklare. Men hur kan du komma närmare detta mål? Hur skapar man en plattform för att köra programvara som kräver minimalt med ingrepp? Vad betyder NoOps ens i detta sammanhang?
Om du försöker abstrahera, betyder begreppen "serverlös" eller "NoOps" för utvecklare verktyg och tjänster som låter dig dölja den "operativa" komponenten eller minimera denna börda för utvecklaren.
- Arbeta inte med system, utan med applikationsgränssnitt (API).
- Bry dig inte om att implementera programvara – låt leverantören göra det åt dig.
- Hoppa inte in i att skapa ett stort ramverk direkt - börja med att skriva små bitar som kommer att fungera som "byggstenar", försök att få den här koden att fungera med data och händelser, och inte med diskar och databaser.
Målet är liksom tidigare att snabba upp iterationer i mjukvaruutveckling, ge möjlighet att skapa bättre produkter och så att utvecklaren inte behöver oroa sig för de system som hans mjukvara körs på. En erfaren utvecklare är väl medveten om att fokus på användarna snabbt kan förändra bilden, så du bör inte lägga för mycket ansträngning på att skriva programvara om du inte är helt säker på att det behövs.
För proffs inom underhåll och drift kan ordet "NoOps" låta lite skrämmande. Men när man kommunicerar med fältingenjörer blir det uppenbart att de mönster och tekniker de använder för att säkerställa tillförlitlighet och tillförlitlighet (Site Reliability Engineering, SRE) har många likheter med mönstren som beskrivs ovan:
- Hantera inte system – automatisera deras hanteringsprocesser.
- Implementera inte programvara – skapa en pipeline för att distribuera den.
- Undvik att bunta ihop alla dina tjänster och låt ett misslyckande orsaka att hela systemet misslyckas – sprid dem över hela din infrastruktur med hjälp av automationsverktyg och anslut dem på ett sätt som kan övervakas och övervakas.
SRE vet att något kan gå fel och de måste spåra och åtgärda problemet – så de automatiserar rutinarbete och sätter felbudgetar i förväg så att de är redo att prioritera och fatta beslut när ett problem uppstår. .
Kubernetes i OpenShift är en plattform designad för att lösa två huvudproblem: istället för att tvinga dig att förstå virtuella maskiner eller belastningsbalanserings-API:er, fungerar den med abstraktioner av högre ordning - distributionsprocesser och tjänster. Istället för att installera programvaruagenter kan du köra containrar och istället för att skriva din egen övervakningsstack, använda de verktyg som redan finns på plattformen. Så, den hemliga såsen av OpenShift 4 är verkligen ingen hemlighet - det är bara en fråga om att ta SRE-principer och serverlösa koncept och ta dem till sin logiska slutsats för att hjälpa utvecklare och driftingenjörer:
- Automatisera och standardisera infrastrukturen som applikationer använder
- Länka samman distributions- och utvecklingsprocesser utan att begränsa utvecklarna själva
- Att se till att lansering, granskning och säkrande av den XNUMX:e tjänsten, funktionen, applikationen eller hela stacken inte är svårare än den första.
Men vad är skillnaden mellan OpenShift 4-plattformen och dess föregångare och från "standard"-metoden för att lösa sådana problem? Vad driver skalan för implementerings- och driftsteam? På grund av det faktum att kungen i denna situation är klustret. Så,
- Vi ser till att syftet med klustren är tydligt (Kära moln, jag plockade upp det här klustret för att jag kunde)
- Maskiner och operativsystem finns för att tjäna klustret (Ers Majestät)
- Hantera tillståndet för värdar från klustret, minimera deras återuppbyggnad (drift).
- För varje viktigt element i systemet behövs en barnskötare (mekanism) som kommer att övervaka och eliminera problem
- Misslyckande med *varje* aspekt eller del av ett system och tillhörande återhämtningsmekanismer är en normal del av livet
- Hela infrastrukturen måste konfigureras via API.
- Använd Kubernetes för att köra Kubernetes. (Ja, ja, det är inget stavfel)
- Uppdateringar ska vara enkla och problemfria att installera. Om det tar mer än ett klick för att installera en uppdatering så gör vi uppenbarligen något fel.
- Övervakning och felsökning av någon komponent bör inte vara ett problem, och därför bör spårning och rapportering över hela infrastrukturen också vara enkelt och bekvämt.
Vill du se plattformens funktioner i aktion?
En förhandsversion av OpenShift 4 har blivit tillgänglig för utvecklare. Med ett lättanvänt installationsprogram kan du köra ett kluster på AWS ovanpå Red Had CoreOS. För att använda förhandsgranskningen behöver du bara ett AWS-konto för att tillhandahålla infrastrukturen och en uppsättning konton för att komma åt förhandsgranskningsbilderna.
- 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, kolla in våra tutorials för att få en djupare förståelse för de system och koncept som gör OpenShift 4-plattformen till ett så enkelt och bekvämt sätt att köra Kubernetes.
Prova den nya OpenShift-versionen och dela din åsikt. Vi är fast beslutna att göra arbetet med Kumbernetes så tillgängligt och enkelt som möjligt – framtiden för NoOps börjar idag.
Nu uppmärksamhet!
På konferensen Den 20 april kommer en av OpenShift-utvecklarna, Vadim Rutkovsky, att hålla en mästarklass – han kommer att bryta tio kluster och tvinga dem att fixa dem. Konferensen är betald, men med kampanjkoden #RedHat får du 37% rabatt
Masterclass kl 17:15 - 18:15, och montern är öppen hela dagen. T-shirts, hattar, klistermärken - det vanliga!
Hall #2
"Här måste hela systemet ändras: vi reparerar trasiga k8s-kluster tillsammans med certifierade mekaniker."
Källa: will.com