Dit is de earste yn in searje berjochten oer de wizigingen, ferbetteringen en tafoegingen yn 'e kommende Red Hat OpenShift-platfoarm 4.0-fernijing dy't jo sil helpe tariede op de oergong nei de nije ferzje.
Fanôf it momint dat de jonge Kubernetes-mienskip yn 'e hjerst fan 2014 foar it earst by Google's Seattle-kantoar sammele, wie it dúdlik dat it Kubernetes-projekt ornearre wie om de manier te revolúsjonearjen fan 'e manier wêrop software hjoed wurdt ûntwikkele en ynset. Tagelyk bleaune oanbieders fan iepenbiere wolktsjinsten aktyf te ynvestearjen yn 'e ûntwikkeling fan ynfrastruktuer en tsjinsten, wat it wurkjen mei IT en it meitsjen fan software folle makliker en tagonkliker makken, en se ongelooflijk tagonklik makken, wat in pear koe har foarstelle oan it begjin fan it desennium.
Fansels waard de oankundiging fan elke nije wolktsjinst begelaat troch tal fan diskusjes ûnder saakkundigen op Twitter, en debatten waarden fierd oer in ferskaat oan ûnderwerpen - ynklusyf it ein fan it iepen boarne tiidrek, de delgong fan IT op it terrein, en de ûnûntkomberens fan in nij softwaremonopoalje. yn 'e wolk, en hoe't it nije paradigma X alle oare paradigma's sil ferfange.
It is ûnmooglik om te sizzen dat al dizze konflikten tige dom wiene
De realiteit is dat neat fuort giet, en hjoed kinne wy in eksponinsjele groei sjen yn einprodukten en de manier wêrop se wurde ûntwikkele, troch it konstante ûntstean fan nije software yn ús libben. En nettsjinsteande it feit dat alles sil feroarje, tagelyk, yn essinsje, alles sil bliuwe ûnferoare. Software-ûntwikkelders sille noch koade skriuwe mei flaters, operaasje-yngenieurs en betrouberensspesjalisten sille noch mei pagers omrinne en automatyske warskôgings ûntfange yn Slack, managers sille noch operearje yn termen fan OpEx en CapEx, en elke kear as in mislearring optreedt, sil de senior de ûntwikkelder suchtet fertrietlik mei de wurden: "Ik haw it dy sein"...
Oh echt besprutsen wurde moatte, is hokker ark wy kinne hawwe om bettere software produkten te meitsjen, en hoe't se kinne ferbetterje feiligens en meitsje ûntwikkeling makliker en betrouber. As projekten komplekser wurde, ûntsteane nije risiko's, en hjoed is it libben fan minsken sa ôfhinklik fan software dat ûntwikkelders gewoan moatte besykje har wurk better te dwaan.
Kubernetes is ien sa'n ark. Der wurdt wurke oan it kombinearjen fan Red Hat OpenShift mei oare ark en tsjinsten yn ien platfoarm dat de software betrouberer, makliker te behearjen en feiliger soe meitsje foar brûkers.
Mei dat sein, stelt it OpenShift-team ien ienfâldige fraach:
Hoe kinne jo wurkje mei Kubernetes makliker en handiger meitsje?
It antwurd is ferrassend dúdlik:
- automatisearje komplekse aspekten fan ynset op 'e wolk of bûten de wolk;
- fokusje op betrouberens by it ferbergjen fan kompleksiteit;
- trochgean troch te wurkjen om ienfâldige en feilige updates frij te litten;
- berikke kontrolearberens en auditability;
- stribje om yn earste ynstânsje hege feiligens te garandearjen, mar net ten koste fan brûkberens.
De folgjende release fan OpenShift moat rekken hâlde mei sawol de ûnderfining fan 'e makkers as de ûnderfining fan oare ûntwikkelders dy't software op grutte skaal ymplementearje yn' e grutste bedriuwen yn 'e wrâld. Derneist moat it rekken hâlde mei alle opboude ûnderfining fan iepen ekosystemen dy't de moderne wrâld hjoeddedei ûnderlizze. Tagelyk is it needsaaklik om de âlde mentaliteit fan 'e amateurûntwikkelder te ferlitten en nei in nije filosofy fan in automatisearre takomst te gean. It moat de kleau oerbrêgje tusken âlde en nije manieren om software yn te setten, en folslein foardiel te nimmen fan alle beskikbere ynfrastruktuer - of it no wurdt host troch de grutste wolkprovider of rint op lytse systemen oan 'e râne.
Hoe te berikken dit resultaat?
By Red Hat is it wenst om lang saai en tankber wurk te dwaan om de oprjochte mienskip te behâlden en it sluten fan projekten dêr't it bedriuw by belutsen is, foar te kommen. De iepenboarnemienskip befettet in enoarm oantal talintfolle ûntwikkelders dy't de meast bûtengewoane dingen meitsje - fermaaklik, edukatyf, nije kânsen iepenje en gewoan moai, mar fansels ferwachtet gjinien dat elkenien yn deselde rjochting sil bewegen of mienskiplike doelen stribjen . It benutten fan dizze enerzjy en it omlieden yn 'e goede rjochting is soms nedich om gebieten te ûntwikkeljen dy't ús brûkers profitearje, mar tagelyk moatte wy de ûntwikkeling fan ús mienskippen kontrolearje en fan har leare.
Oan it begjin fan 2018 kocht Red Hat it CoreOS-projekt, dat ferlykbere opfettings hie oer de takomst - feiliger en betrouberer, makke op iepen boarne prinsipes. It bedriuw hat wurke om dizze ideeën fierder te ûntwikkeljen en te ymplementearjen, ús filosofy yn 'e praktyk te bringen - besykje te soargjen dat alle software feilich rint. Al dit wurk is boud op Kubernetes, Linux, iepenbiere wolken, privee wolken en tûzenen oare projekten dy't ús moderne digitale ekosysteem stypje.
De nije release fan OpenShift 4 sil dúdlik, automatisearre en natuerliker wêze
It OpenShift-platfoarm sil wurkje mei de bêste en meast betroubere Linux-bestjoeringssystemen, mei bleate metalen hardware-stipe, handige virtualisaasje, automatyske ynfrastruktuerprogrammearring en, fansels, konteners (dy't yn essinsje gewoan Linux-ôfbyldings binne).
It platfoarm moat fan it begjin ôf feilich wêze, mar dochs ûntwikkelders tastean om maklik te iterearjen - dat wol sizze, fleksibel en feilich genôch wêze, wylst behearders it noch maklik kontrolearje en beheare kinne.
It soe tastean software te rinnen "as in tsjinst" en net liede ta ûnbehearbere ynfrastruktuer groei foar operators.
It sil ûntwikkelders tastean om te fokusjen op it meitsjen fan echte produkten foar brûkers en klanten. Jo hoege net te waad troch de jungle fan hardware- en softwareynstellingen, en alle tafallige komplikaasjes sille in ding fan it ferline wêze.
OpenShift 4: NoOps-platfoarm dat gjin ûnderhâld fereasket
В beskreau dy taken dy't holpen foarmje de fisy fan it bedriuw foar OpenShift 4. It doel fan it team is om de deistige taken fan it operearjen en ûnderhâlden fan software safolle mooglik te ferienfâldigjen, om dizze prosessen maklik en ûntspannen te meitsjen - sawol foar spesjalisten belutsen by ymplemintaasje as foar ûntwikkelders. Mar hoe kinne jo tichter by dit doel komme? Hoe kinne jo in platfoarm meitsje foar it útfieren fan software dy't minimale yntervinsje fereasket? Wat betsjuttet NoOps sels yn dizze kontekst?
As jo besykje te abstraheren, dan foar ûntwikkelders betsjutte de begripen "serverless" of "NoOps" ark en tsjinsten dy't jo de "operasjonele" komponint kinne ferbergje of dizze lêst foar de ûntwikkelder minimalisearje.
- Wurkje net mei systemen, mar mei applikaasje-ynterfaces (API's).
- Doch gjin muoite mei it ymplementearjen fan software - lit de provider it foar jo dwaan.
- Jo moatte net direkt springe yn it meitsjen fan in grut ramt - begjin mei it skriuwen fan lytse stikken dy't sille fungearje as "boublokken", besykje dizze koade te wurkjen mei gegevens en eveneminten, en net mei skiven en databases.
It doel, lykas earder, is om iteraasjes yn softwareûntwikkeling te rapperjen, de kâns te jaan om bettere produkten te meitsjen, en sadat de ûntwikkelder gjin soargen hoecht te meitsjen oer de systemen wêrop syn software rint. In betûfte ûntwikkelder is der goed fan bewust dat it rjochtsjen op brûkers de foto fluch feroarje kin, dus jo moatte net tefolle muoite dwaan om software te skriuwen, útsein as jo absolút wis binne dat it nedich is.
Foar professionals yn ûnderhâld en operaasje kin it wurd "NoOps" in bytsje eng klinke. Mar as jo kommunisearje mei fjildingenieurs, wurdt it dúdlik dat de patroanen en techniken dy't se brûke rjochte op it garandearjen fan betrouberens en betrouberens (Site Reliability Engineering, SRE) in protte oerienkomsten hawwe mei de hjirboppe beskreaune patroanen:
- Beheare systemen net - automatisearje har behearprosessen.
- Implementearje gjin software - meitsje in pipeline om it yn te setten.
- Foarkom it bondeljen fan al jo tsjinsten byinoar en lit it mislearjen fan ien it heule systeem mislearje - ferspried se oer jo heule ynfrastruktuer mei automatisearringsark, en ferbine se op manieren dy't kinne wurde kontroleare en kontroleare.
SRE's witte dat der wat mis kin gean en se sille it probleem moatte opspoare en reparearje - sadat se routinewurk automatisearje en flaterbudzjetten foarôf ynstelle, sadat se ree binne om prioriteiten te stellen en besluten te nimmen as in probleem opkomt. .
Kubernetes yn OpenShift is in platfoarm ûntworpen om twa haadproblemen op te lossen: ynstee fan jo te twingen om firtuele masines of loadbalancer API's te begripen, wurket it mei abstraksjes fan hegere oarder - ynsetprosessen en tsjinsten. Ynstee fan software-aginten te ynstallearjen, kinne jo konteners útfiere, en ynstee fan jo eigen kontrôlestap te skriuwen, brûk de ark dy't al beskikber binne yn it platfoarm. Dat, de geheime saus fan OpenShift 4 is wirklik gjin geheim - it is gewoan in kwestje fan SRE-prinsipes en serverless-konsepten te nimmen en se nei har logyske konklúzje te nimmen om ûntwikkelders en operaasje-yngenieurs te helpen:
- Automatisearje en standardisearje de ynfrastruktuer dy't applikaasjes brûke
- Keppelje ynset- en ûntwikkelingsprosessen tegearre sûnder ûntwikkelders sels te beheinen
- Fersekerje dat it lansearjen, kontrolearjen en befeiligjen fan 'e XNUMXe tsjinst, funksje, applikaasje of heule stapel net dreger is as de earste.
Mar wat is it ferskil tusken it OpenShift 4-platfoarm en syn foargongers en fan 'e "standert" oanpak foar it oplossen fan sokke problemen? Wat driuwt skaal foar ymplemintaasje- en operaasjeteams? Fanwege it feit dat de kening yn dizze situaasje is it kluster. Sa,
- Wy soargje derfoar dat it doel fan 'e klusters dúdlik is (Dear wolk, ik haw dizze kluster ophelle om't ik koe)
- Masines en bestjoeringssystemen besteane om it kluster te tsjinjen (Jo Majesteit)
- Behear de steat fan hosts út it kluster, minimalisearje har weropbou (drift).
- Foar elk wichtich elemint fan it systeem is in nanny (meganisme) nedich dy't problemen kontrolearje en eliminearje
- Mislearjen fan * elk * aspekt of elemint fan in systeem en byhearrende herstelmeganismen binne in normaal diel fan it libben
- De hiele ynfrastruktuer moat wurde konfigureare fia API.
- Brûk Kubernetes om Kubernetes út te fieren. (Ja, ja, dat is gjin typflater)
- Updates moatte maklik en probleemfrij wêze om te ynstallearjen. As it mear dan ien klik duorret om in update te ynstallearjen, dan dogge wy fansels wat ferkeard.
- It kontrolearjen en debuggen fan elke komponint soe gjin probleem wêze moatte, en dêrom moatte folgjen en rapportearje oer de heule ynfrastruktuer ek maklik en handich wêze.
Wolle jo de mooglikheden fan it platfoarm yn aksje sjen?
In foarbyldferzje fan OpenShift 4 is beskikber wurden foar ûntwikkelders. Mei in maklik te brûken ynstallearder kinne jo in kluster útfiere op AWS boppe op Red Had CoreOS. Om it foarbyld te brûken, hawwe jo allinich in AWS-akkount nedich om de ynfrastruktuer te leverjen en in set akkounts om tagong te krijen ta de foarbyldôfbyldings.
- Om te begjinnen, gean nei en klikje op "Begin".
- Meld jo oan by jo Red Hat-akkount (of meitsje in nij) en folgje de ynstruksjes om jo earste kluster yn te stellen.
Nei suksesfolle ynstallaasje, besjoch ús tutorials om in djipper begryp te krijen fan 'e systemen en begripen dy't it OpenShift 4-platfoarm sa'n maklike en handige manier meitsje om Kubernetes út te fieren.
Besykje de nije OpenShift-release en diel jo miening. Wy sette ús yn om it wurkjen mei Kumbernetes sa tagonklik en maklik mooglik te meitsjen - de takomst fan NoOps begjint hjoed.
En no oandacht!
Op 'e konferinsje Op 20 april sil ien fan 'e OpenShift-ûntwikkelders, Vadim Rutkovsky, in masterklasse hâlde - hy sil tsien klusters brekke en twinge om se te reparearjen. De konferinsje wurdt betelle, mar mei de promoasjekoade #RedHat krije jo 37% koarting
Masterclass om 17:15 - 18:15 oere, en de stân is de hiele dei iepen. T-shirts, hoeden, stickers - de gewoane!
Hall #2
"Hjir moat it hiele systeem feroare wurde: wy reparearje brutsen k8s-klusters tegearre mei sertifisearre monteurs."
Boarne: www.habr.com