Dit is die eerste in 'n reeks plasings oor die veranderinge, verbeterings en toevoegings in die komende Red Hat OpenShift-platform 4.0-opdatering wat jou sal help om voor te berei vir die oorgang na die nuwe weergawe.
Vanaf die oomblik dat die jong Kubernetes-gemeenskap die eerste keer in die herfs van 2014 by Google se kantoor in Seattle bymekaargekom het, was dit duidelik dat die Kubernetes-projek bestem was om 'n rewolusie teweeg te bring in die manier waarop sagteware vandag ontwikkel en ontplooi word. Terselfdertyd het openbare wolkdiensverskaffers voortgegaan om aktief te belê in die ontwikkeling van infrastruktuur en dienste, wat die werk met IT en die skep van sagteware baie makliker en meer toeganklik gemaak het, en dit ongelooflik toeganklik gemaak het, wat min kon dink aan die begin van die dekade.
Natuurlik het die aankondiging van elke nuwe wolkdiens gepaard gegaan met talle besprekings onder kundiges op Twitter, en debatte is gevoer oor 'n verskeidenheid onderwerpe - insluitend die einde van die oopbron-era, die agteruitgang van IT op die perseel en die onvermydelikheid van 'n nuwe sagteware-monopolie in die wolk, en hoe die nuwe paradigma X alle ander paradigmas sal vervang.
Nodeloos om te sê, al hierdie geskille was baie dom
Die realiteit is dat niks gaan weggaan nie, en vandag kan ons 'n eksponensiële groei in eindprodukte en die manier waarop dit ontwikkel word sien, as gevolg van die voortdurende opkoms van nuwe sagteware in ons lewens. En ten spyte van die feit dat alles rondom sal verander, sal alles terselfdertyd in wese onveranderd bly. Sagteware-ontwikkelaars sal steeds kode met foute skryf, bedryfsingenieurs en betroubaarheidspesialiste sal steeds met pagers rondloop en outomatiese waarskuwings in Slack ontvang, bestuurders sal steeds in terme van OpEx en CapEx werk, en elke keer as 'n mislukking plaasvind, sal die senior die ontwikkelaar sug hartseer met die woorde: “Ek het jou so gesê”...
o regtig bespreek moet word, is watter gereedskap ons tot ons beskikking kan hê om beter sagtewareprodukte te skep, en hoe dit sekuriteit kan verbeter en ontwikkeling makliker en betroubaarder kan maak. Soos projekte meer kompleks word, ontstaan nuwe risiko's, en vandag is mense se lewens so afhanklik van sagteware dat ontwikkelaars eenvoudig moet probeer om hul werk beter te doen.
Kubernetes is een so 'n instrument. Werk is aan die gang om Red Hat OpenShift met ander gereedskap en dienste te kombineer in 'n enkele platform wat die sagteware meer betroubaar, makliker om te bestuur en veiliger vir gebruikers sal maak.
Met dit gesê, vra die OpenShift-span een eenvoudige vraag:
Hoe kan jy dit makliker en geriefliker maak om met Kubernetes te werk?
Die antwoord is verbasend duidelik:
- outomatiseer komplekse aspekte van ontplooiing op die wolk of buite die wolk;
- fokus op betroubaarheid terwyl kompleksiteit weggesteek word;
- voortgaan om voortdurend te werk om eenvoudige en veilige opdaterings vry te stel;
- beheerbaarheid en ouditeerbaarheid te bereik;
- streef daarna om aanvanklik hoë sekuriteit te verseker, maar nie ten koste van bruikbaarheid nie.
Die volgende weergawe van OpenShift moet beide die ervaring van die skeppers en die ervaring van ander ontwikkelaars wat sagteware op groot skaal in die grootste maatskappye ter wêreld implementeer in ag neem. Daarbenewens moet dit al die opgehoopte ervaring van oop ekosisteme wat die moderne wêreld vandag onderlê, in ag neem. Terselfdertyd is dit nodig om die ou mentaliteit van die amateur-ontwikkelaar te laat vaar en na 'n nuwe filosofie van 'n outomatiese toekoms te beweeg. Dit moet die gaping tussen ou en nuwe maniere om sagteware te ontplooi oorbrug en alle beskikbare infrastruktuur ten volle te benut—of dit nou deur die grootste wolkverskaffer gehuisves word of op klein stelsels aan die rand loop.
Hoe om hierdie resultaat te bereik?
By Red Hat is dit gebruiklik om lank vervelige en ondankbare werk te doen om die gevestigde gemeenskap te bewaar en die sluiting van projekte waarby die maatskappy betrokke is te voorkom. Die oopbrongemeenskap bevat 'n groot aantal talentvolle ontwikkelaars wat die mees buitengewone dinge skep - vermaaklik, opvoedkundig, nuwe geleenthede oopmaak en eenvoudig pragtig, maar natuurlik verwag niemand dat almal in dieselfde rigting moet beweeg of gemeenskaplike doelwitte moet nastreef nie. . Om hierdie energie te benut en dit in die regte rigting te herlei, is soms nodig om gebiede te ontwikkel wat tot voordeel van ons gebruikers sal wees, maar terselfdertyd moet ons die ontwikkeling van ons gemeenskappe monitor en daaruit leer.
Aan die begin van 2018 het Red Hat die CoreOS-projek bekom, wat soortgelyke sienings oor die toekoms gehad het - veiliger en betroubaarder, geskep op oopbronbeginsels. Die maatskappy het gewerk om hierdie idees verder te ontwikkel en te implementeer, om ons filosofie in die praktyk te bring – om te probeer verseker dat alle sagteware veilig werk. Al hierdie werk is gebou op Kubernetes, Linux, publieke wolke, private wolke en duisende ander projekte wat ons moderne digitale ekosisteem ondersteun.
Die nuwe weergawe van OpenShift 4 sal duidelik, outomaties en natuurliker wees
Die OpenShift-platform sal met die beste en mees betroubare Linux-bedryfstelsels werk, met kaalmetaal-hardeware-ondersteuning, gerieflike virtualisering, outomatiese infrastruktuurprogrammering en natuurlik houers (wat in wese net Linux-beelde is).
Die platform moet van die begin af veilig wees, maar steeds ontwikkelaars toelaat om maklik te herhaal—dit wil sê, buigsaam en veilig genoeg wees terwyl dit steeds administrateurs toelaat om dit maklik te oudit en te bestuur.
Dit moet toelaat dat sagteware "as 'n diens" bedryf word en nie lei tot onhanteerbare infrastruktuurgroei vir operateurs nie.
Dit sal ontwikkelaars in staat stel om te fokus op die skep van regte produkte vir gebruikers en kliënte. Jy hoef nie deur die oerwoud van hardeware- en sagteware-instellings te gaan nie, en alle toevallige komplikasies sal iets van die verlede wees.
OpenShift 4: NoOps-platform wat nie onderhoud benodig nie
В beskryf daardie take wat gehelp het om die maatskappy se visie vir OpenShift 4 te vorm. Die span se doelwit is om die daaglikse take van die bedryf en instandhouding van sagteware soveel as moontlik te vereenvoudig, om hierdie prosesse maklik en ontspanne te maak – beide vir spesialiste betrokke by implementering en vir ontwikkelaars. Maar hoe kan jy nader aan hierdie doelwit kom? Hoe om 'n platform te skep vir die bestuur van sagteware wat minimale ingryping vereis? Wat beteken NoOps selfs in hierdie konteks?
As u probeer abstraheer, beteken die konsepte van "bedienerloos" of "NoOps" vir ontwikkelaars gereedskap en dienste wat u toelaat om die "operasionele" komponent te verberg of hierdie las vir die ontwikkelaar te verminder.
- Werk nie met stelsels nie, maar met toepassingskoppelvlakke (API's).
- Moenie die moeite doen om sagteware te implementeer nie – laat die verskaffer dit vir jou doen.
- Moenie dadelik inspring om 'n groot raamwerk te skep nie - begin deur klein stukkies te skryf wat as "boublokke" sal dien, probeer om hierdie kode met data en gebeurtenisse te laat werk, en nie met skywe en databasisse nie.
Die doel, soos voorheen, is om herhalings in sagteware-ontwikkeling te bespoedig, die geleentheid te bied om beter produkte te skep, en sodat die ontwikkelaar nie hoef te bekommer oor die stelsels waarop sy sagteware loop nie. 'n Ervare ontwikkelaar is deeglik bewus daarvan dat die fokus op gebruikers vinnig die prentjie kan verander, so jy moet nie te veel moeite doen om sagteware te skryf nie, tensy jy heeltemal seker is dat dit nodig is.
Vir instandhoudings- en bedryfspersoneel kan die woord "NoOps" 'n bietjie skrikwekkend klink. Maar wanneer daar met veldingenieurs gekommunikeer word, word dit duidelik dat die patrone en tegnieke wat hulle gebruik om betroubaarheid en betroubaarheid te verseker (Site Reliability Engineering, SRE) baie ooreenkomste het met die patrone wat hierbo beskryf word:
- Moenie stelsels bestuur nie – outomatiseer hul bestuursprosesse.
- Moenie sagteware implementeer nie – skep 'n pyplyn om dit te ontplooi.
- Vermy om al jou dienste saam te bundel en dat die mislukking van een die hele stelsel laat misluk – versprei hulle oor jou hele infrastruktuur deur outomatiseringsnutsmiddels te gebruik, en verbind hulle op maniere wat gemonitor en gemonitor kan word.
SRE's weet dat iets verkeerd kan gaan en hulle sal die probleem moet opspoor en regmaak—so hulle outomatiseer roetinewerk en stel foutbegrotings vooraf op sodat hulle gereed is om te prioritiseer en besluite te neem wanneer 'n probleem opduik. .
Kubernetes in OpenShift is 'n platform wat ontwerp is om twee hoofprobleme op te los: in plaas daarvan om jou te dwing om virtuele masjiene of lasbalanseerder-API's te verstaan, werk dit met hoërorde-abstraksies - ontplooiingsprosesse en -dienste. In plaas daarvan om sagteware-agente te installeer, kan jy houers laat loop, en in plaas daarvan om jou eie moniteringsstapel te skryf, gebruik die gereedskap wat reeds op die platform beskikbaar is. Dus, die geheime sous van OpenShift 4 is regtig geen geheim nie - dit is net 'n kwessie daarvan om SRE-beginsels en bedienerlose konsepte te neem en hulle tot hul logiese gevolgtrekking te neem om ontwikkelaars en bedryfsingenieurs te help:
- Outomatiseer en standaardiseer die infrastruktuur wat toepassings gebruik
- Koppel ontplooiings- en ontwikkelingsprosesse aan mekaar sonder om ontwikkelaars self te beperk
- Om te verseker dat die bekendstelling, ouditering en beveiliging van die XNUMXste diens, kenmerk, toepassing of hele stapel nie moeiliker is as die eerste nie.
Maar wat is die verskil tussen die OpenShift 4-platform en sy voorgangers en van die "standaard"-benadering om sulke probleme op te los? Wat dryf skaal vir implementering en bedryfspanne? As gevolg van die feit dat die koning in hierdie situasie die groep is. Dus,
- Ons maak seker dat die doel van die clusters duidelik is (Liewe wolk, ek het hierdie cluster opgetel omdat ek kon)
- Masjiene en bedryfstelsels bestaan om die groep te bedien (U Majesteit)
- Bestuur die toestand van leërskare uit die groep, verminder hul herbou (dryf).
- Vir elke belangrike element van die stelsel is 'n kinderoppasser (meganisme) nodig wat probleme sal monitor en uitskakel
- Mislukking van *elke* aspek of element van 'n sisteem en gepaardgaande herstelmeganismes is 'n normale deel van die lewe
- Die hele infrastruktuur moet via API gekonfigureer word.
- Gebruik Kubernetes om Kubernetes te laat loop. (Ja, ja, dit is nie 'n tikfout nie)
- Opdaterings moet maklik en moeitevry wees om te installeer. As dit meer as een klik neem om 'n opdatering te installeer, dan doen ons natuurlik iets verkeerd.
- Monitering en ontfouting van enige komponent behoort nie 'n probleem te wees nie, en daarom behoort nasporing en verslagdoening oor die hele infrastruktuur ook maklik en gerieflik te wees.
Wil jy die platform se vermoëns in aksie sien?
'n Voorskouweergawe van OpenShift 4 het vir ontwikkelaars beskikbaar geword. Met 'n maklik-om-te gebruik installeerder, kan jy 'n groepering op AWS laat loop bo-op Red Had CoreOS. Om die voorskou te gebruik, benodig jy net 'n AWS-rekening om die infrastruktuur te voorsien en 'n stel rekeninge om toegang tot die voorskoubeelde te kry.
- Om te begin, gaan na en klik "Begin".
- Meld aan by jou Red Hat-rekening (of skep 'n nuwe een) en volg die instruksies om jou eerste groepering op te stel.
Na suksesvolle installasie, kyk na ons tutoriale om 'n dieper begrip te kry van die stelsels en konsepte wat die OpenShift 4-platform so 'n maklike en gerieflike manier maak om Kubernetes te laat loop.
Probeer die nuwe OpenShift-weergawe en deel jou mening. Ons is daartoe verbind om die werk met Kumbernetes so toeganklik en moeiteloos moontlik te maak—die toekoms van NoOps begin vandag.
Nou aandag!
Op die konferensie Op 20 April sal een van die OpenShift-ontwikkelaars, Vadim Rutkovsky, 'n meesterklas hou - hy sal tien groepe breek en hulle dwing om dit reg te maak. Die konferensie is betaal, maar met die promosiekode #RedHat kry jy 37% afslag
Meestersklas om 17:15 - 18:15, en die staanplek is heeldag oop. T-hemde, hoede, plakkers - die gewone!
Saal #2
“Hier moet die hele stelsel verander word: ons herstel stukkende k8s-klusters saam met gesertifiseerde werktuigkundiges.”
Bron: will.com