Dette er det første i en serie med innlegg om endringene, forbedringene og tilleggene i den kommende Red Hat OpenShift-plattformen 4.0-oppdateringen som vil hjelpe deg med å forberede overgangen til den nye versjonen.
Fra det øyeblikket det nye Kubernetes-fellesskapet først samlet seg på Googles kontor i Seattle høsten 2014, var Kubernetes-prosjektet bestemt til å revolusjonere måten programvare utvikles og distribueres på i dag. Samtidig fortsatte offentlige skytjenesteleverandører å investere aktivt i utvikling av infrastruktur og tjenester, noe som gjorde arbeidet med IT og å lage programvare mye enklere og mer tilgjengelig, og gjorde dem utrolig rimelige, noe få kunne ha forestilt seg i begynnelsen av tiåret.
Selvfølgelig ble kunngjøringen av hver nye skytjeneste ledsaget av en rekke diskusjoner blant eksperter på Twitter, og debatter ble gjennomført om en rekke emner – inkludert slutten av åpen kildekode-æraen, nedgangen av lokal IT og uunngåelig av et nytt programvaremonopol i skyen, og hvordan det nye paradigmet X vil erstatte alle andre paradigmer.
Det burde være unødvendig å si at alle disse tvistene var veldig dumme
Realiteten er at ingenting kommer til å forsvinne, og i dag kan vi se en eksponentiell vekst i sluttprodukter og måten de utvikles på, på grunn av den konstante fremveksten av ny programvare i livene våre. Og til tross for at alt rundt vil endre seg, vil på samme tid, i hovedsak, alt forbli uendret. Programvareutviklere vil fortsatt skrive kode med feil, driftsingeniører og pålitelighetsspesialister vil fortsatt gå rundt med personsøkere og motta automatiske varsler i Slack, ledere vil fortsatt operere i form av OpEx og CapEx, og hver gang en feil oppstår, vil senior utvikleren sukk trist med ordene: "Jeg sa det til deg"...
Åh, virkelig bør diskuteres, er hvilke verktøy vi kan ha til rådighet for å lage bedre programvareprodukter, og hvordan de kan forbedre sikkerheten og gjøre utviklingen enklere og mer pålitelig. Etter hvert som prosjekter blir mer komplekse, oppstår nye risikoer, og i dag er folks liv så avhengig av programvare at utviklere rett og slett må prøve å gjøre jobben sin bedre.
Kubernetes er et slikt verktøy. Det arbeides med å kombinere Red Hat OpenShift med andre verktøy og tjenester til én enkelt plattform som vil gjøre programvaren mer pålitelig, enklere å administrere og tryggere for brukerne.
Når det er sagt, stiller OpenShift-teamet ett enkelt spørsmål:
Hvordan kan du gjøre arbeidet med Kubernetes enklere og mer praktisk?
Svaret er overraskende åpenbart:
- automatisere komplekse aspekter ved distribusjon på skyen eller utenfor skyen;
- fokus på pålitelighet mens du skjuler kompleksitet;
- fortsette å jobbe kontinuerlig med å gi ut enkle og sikre oppdateringer;
- oppnå kontrollerbarhet og reviderbarhet;
- bestrebe seg på å i utgangspunktet sikre høy sikkerhet, men ikke på bekostning av brukervennligheten.
Den neste utgivelsen av OpenShift bør ta hensyn til både erfaringen til skaperne og erfaringen til andre utviklere som implementerer programvare i stor skala i de største selskapene i verden. I tillegg må den ta hensyn til all den akkumulerte erfaringen fra åpne økosystemer som ligger til grunn for den moderne verden i dag. Samtidig er det nødvendig å forlate den gamle mentaliteten til amatørutvikleren og flytte til en ny filosofi om en automatisert fremtid. Den må bygge bro mellom gamle og nye måter å distribuere programvare på, og dra full nytte av all tilgjengelig infrastruktur – enten den drives av den største skyleverandøren eller kjører på små systemer i kanten.
Hvordan oppnå dette resultatet?
Hos Red Hat er det vanlig å gjøre kjedelig og utakknemlig arbeid over lang tid for å bevare det etablerte fellesskapet og hindre nedleggelse av prosjekter som selskapet er involvert i. Åpen kildekode-fellesskapet inneholder et stort antall talentfulle utviklere som skaper de mest ekstraordinære tingene - underholdende, pedagogiske, åpne opp for nye muligheter og rett og slett vakre, men selvfølgelig forventer ingen at alle skal bevege seg i samme retning eller forfølge felles mål . Å utnytte denne energien og omdirigere den i riktig retning er noen ganger nødvendig for å utvikle områder som vil være til nytte for brukerne våre, men samtidig må vi overvåke utviklingen i lokalsamfunnene våre og lære av dem.
I begynnelsen av 2018 kjøpte Red Hat CoreOS-prosjektet, som hadde lignende syn på fremtiden – sikrere og pålitelige, skapt etter åpen kildekode-prinsipper. Selskapet har jobbet med å videreutvikle disse ideene og implementere dem, og satt filosofien vår ut i livet – forsøker å sikre at all programvare kjører trygt. Alt dette arbeidet er bygget på Kubernetes, Linux, offentlige skyer, private skyer og tusenvis av andre prosjekter som underbygger vårt moderne digitale økosystem.
Den nye utgivelsen av OpenShift 4 vil være tydelig, automatisert og mer naturlig
OpenShift-plattformen vil fungere med de beste og mest pålitelige Linux-operativsystemene, med bar-metall maskinvarestøtte, praktisk virtualisering, automatisk infrastrukturprogrammering og, selvfølgelig, containere (som i hovedsak bare er Linux-bilder).
Plattformen må være sikker fra starten av, men fortsatt la utviklere enkelt iterere – det vil si være fleksibel og sikker nok samtidig som administratorer kan revidere og administrere den enkelt.
Det skal tillate programvare å kjøre "som en tjeneste" og ikke føre til uhåndterlig infrastrukturvekst for operatører.
Det vil tillate utviklere å fokusere på å lage ekte produkter for brukere og kunder. Du trenger ikke å vasse gjennom jungelen av maskinvare- og programvareinnstillinger, og alle utilsiktede komplikasjoner vil være en saga blott.
OpenShift 4: NoOps-plattform som ikke krever vedlikehold
В beskrev de oppgavene som bidro til å forme selskapets visjon for OpenShift 4. Teamets mål er å forenkle de daglige oppgavene med drift og vedlikehold av programvare så mye som mulig, for å gjøre disse prosessene enkle og avslappede – både for spesialister involvert i implementering og for utviklere. Men hvordan kan du komme nærmere dette målet? Hvordan lage en plattform for å kjøre programvare som krever minimal intervensjon? Hva betyr NoOps i denne sammenhengen?
Hvis du prøver å abstrahere, betyr begrepene "serverløs" eller "NoOps" for utviklere verktøy og tjenester som lar deg skjule den "operative" komponenten eller minimere denne byrden for utvikleren.
- Arbeid ikke med systemer, men med applikasjonsgrensesnitt (API).
- Ikke bry deg med å implementere programvare – la leverandøren gjøre det for deg.
- Ikke hopp ut i å lage et stort rammeverk med en gang – start med å skrive små biter som vil fungere som «byggeklosser», prøv å få denne koden til å fungere med data og hendelser, og ikke med disker og databaser.
Målet er som før å få fart på iterasjoner i programvareutvikling, gi mulighet til å lage bedre produkter, og slik at utvikleren slipper å bekymre seg for systemene programvaren hans kjører på. En erfaren utvikler er godt klar over at fokus på brukere raskt kan endre bildet, så du bør ikke legge for mye arbeid i å skrive programvare med mindre du er helt sikker på at det er nødvendig.
For fagfolk i vedlikehold og drift kan ordet "NoOps" høres litt skummelt ut. Men når man kommuniserer med feltingeniører, blir det åpenbart at mønstrene og teknikkene de bruker for å sikre pålitelighet og pålitelighet (Site Reliability Engineering, SRE) har mange likheter med mønstrene beskrevet ovenfor:
- Ikke administrer systemer – automatiser administrasjonsprosessene deres.
- Ikke implementer programvare – lag en pipeline for å distribuere den.
- Unngå å samle alle tjenestene dine sammen og la feilen i en få hele systemet til å svikte – spre dem over hele infrastrukturen ved hjelp av automatiseringsverktøy, og koble dem til på måter som kan overvåkes og overvåkes.
SRE-er vet at noe kan gå galt og de må spore opp og fikse problemet – så de automatiserer rutinearbeid og setter feilbudsjetter på forhånd slik at de er klare til å prioritere og ta avgjørelser når et problem oppstår.
Kubernetes i OpenShift er en plattform designet for å løse to hovedproblemer: i stedet for å tvinge deg til å forstå virtuelle maskiner eller lastbalanserings-APIer, fungerer den med høyere ordens abstraksjoner – distribusjonsprosesser og tjenester. I stedet for å installere programvareagenter, kan du kjøre containere, og i stedet for å skrive din egen overvåkingsstack, kan du bruke verktøyene som allerede er tilgjengelige på plattformen. Så, den hemmelige sausen til OpenShift 4 er egentlig ingen hemmelighet - det er bare et spørsmål om å ta SRE-prinsipper og serverløse konsepter og ta dem til sin logiske konklusjon for å hjelpe utviklere og driftsingeniører:
- Automatiser og standardiser infrastrukturen som applikasjoner bruker
- Koble sammen distribusjons- og utviklingsprosesser uten å begrense utviklerne selv
- Å sikre at lansering, revisjon og sikring av den XNUMX. tjenesten, funksjonen, applikasjonen eller hele stabelen ikke er vanskeligere enn den første.
Men hva er forskjellen mellom OpenShift 4-plattformen og dens forgjengere og fra "standard" tilnærmingen til å løse slike problemer? Hva driver skala for implementerings- og driftsteam? På grunn av det faktum at kongen i denne situasjonen er klyngen. Så,
- Vi sørger for at formålet med klyngene er klart (Kjære sky, jeg plukket opp denne klyngen fordi jeg kunne)
- Maskiner og operativsystemer finnes for å betjene klyngen (Deres Majestet)
- Administrer tilstanden til verter fra klyngen, minimer deres gjenoppbygging (drift).
- For hvert viktig element i systemet trengs en barnepike (mekanisme) som vil overvåke og eliminere problemer
- Svikt i *hvert* aspekt eller element i et system og tilhørende gjenopprettingsmekanismer er en normal del av livet
- Hele infrastrukturen må konfigureres via API.
- Bruk Kubernetes til å kjøre Kubernetes. (Ja, ja, det er ikke en skrivefeil)
- Oppdateringer skal være enkle og problemfrie å installere. Hvis det tar mer enn ett klikk for å installere en oppdatering, gjør vi åpenbart noe galt.
- Overvåking og feilsøking av enhver komponent bør ikke være et problem, og derfor bør sporing og rapportering på tvers av hele infrastrukturen også være enkelt og praktisk.
Vil du se plattformens evner i aksjon?
En forhåndsversjon av OpenShift 4 har blitt tilgjengelig for utviklere. Med et brukervennlig installasjonsprogram kan du kjøre en klynge på AWS på toppen av Red Had CoreOS. For å bruke forhåndsvisningen trenger du bare en AWS-konto for å klargjøre infrastrukturen og et sett med kontoer for å få tilgang til forhåndsvisningsbildene.
- For å komme i gang, gå til og klikk "Kom i gang".
- Logg på Red Hat-kontoen din (eller opprett en ny) og følg instruksjonene for å sette opp din første klynge.
Etter vellykket installasjon, sjekk veiledningene våre for å få en dypere forståelse av systemene og konseptene som gjør OpenShift 4-plattformen til en så enkel og praktisk måte å kjøre Kubernetes på.
Prøv den nye OpenShift-utgivelsen og del din mening. Vi er forpliktet til å gjøre arbeidet med Kumbernetes så tilgjengelig og uanstrengt som mulig – fremtiden til NoOps starter i dag.
Og nå oppmerksomhet!
På konferansen 20. april vil en av OpenShift-utviklerne, Vadim Rutkovsky, holde en mesterklasse – han vil bryte ti klynger og tvinge dem til å fikse dem. Konferansen er betalt, men med kampanjekoden #RedHat får du 37 % rabatt
Master class kl 17:15 - 18:15, og standen er åpen hele dagen. T-skjorter, hatter, klistremerker - det vanlige!
Hall #2
"Her må hele systemet endres: vi reparerer ødelagte k8s-klynger sammen med sertifiserte mekanikere."
Kilde: www.habr.com