See on esimene postituste seeriast, mis käsitleb eelseisva Red Hat OpenShift platvormi 4.0 värskenduse muudatusi, täiustusi ja täiendusi, mis aitavad teil valmistuda uuele versioonile üleminekuks.
Alates hetkest, kui Kubernetese kogukond 2014. aasta sügisel esimest korda Google'i Seattle'i kontorisse kogunes, oli selge, et Kubernetese projekti eesmärk on muuta tänapäeval tarkvara arendamise ja juurutamise viisi. Samal ajal jätkasid avalike pilveteenuste pakkujad suuri investeeringuid taristu ja teenuste arendamisse, mis muutis IT-ga töötamise ja tarkvara loomise palju lihtsamaks ja kättesaadavamaks ning muutis need uskumatult ligipääsetavaks, mida vähesed oleksid osanud aasta alguses ette kujutada. aastakümnel.
Loomulikult kaasnesid iga uue pilveteenuse väljakuulutamisega Twitteris arvukad arutelud ekspertide vahel ning debatte peeti erinevatel teemadel – sealhulgas avatud lähtekoodiga ajastu lõpp, kohapealse IT allakäik ja paratamatus. uuest tarkvaramonopolist. pilves ja kuidas uus paradigma X asendab kõik teised paradigmad.
Ütlematagi selge, et kõik need vaidlused olid väga rumalad
Reaalsus on see, et miski ei kao kuhugi ja täna näeme lõpptoodete ja nende arendusviiside hüppelist kasvu, kuna meie ellu tuleb pidevalt uus tarkvara. Ja hoolimata sellest, et kõik ümberringi muutub, jääb sisuliselt kõik samal ajal muutumatuks. Tarkvaraarendajad kirjutavad endiselt vigadega koodi, operatsiooniinsenerid ja töökindlusspetsialistid kõnnivad piiparitega ringi ja saavad Slackis automaatseid hoiatusi, juhid töötavad endiselt OpExi ja CapExi osas ning iga kord, kui ilmneb rike, teeb arendaja vanem. ohkake kurvalt sõnadega: "Ma ütlesin sulle nii"...
Kas tõesti tuleks arutada, millised tööriistad saavad meie käsutuses olla paremate tarkvaratoodete loomiseks ja kuidas need võivad parandada turvalisust ning muuta arendus lihtsamaks ja usaldusväärsemaks. Projektide keerukuse kasvades kasvavad ka uued riskid ning tänapäeval on inimeste elu niivõrd tarkvarast sõltuv, et arendajad peavad lihtsalt proovima oma tööd paremini teha.
Kubernetes on üks selline tööriist. Käimas on töö Red Hat OpenShifti ühendamiseks teiste tööriistade ja teenustega üheks platvormiks, mis muudaks tarkvara töökindlamaks, lihtsamini hallatavaks ja kasutajate jaoks turvalisemaks.
Seda öeldes küsib OpenShifti meeskond ühe lihtsa küsimuse:
Kuidas muuta Kubernetesega töötamine lihtsamaks ja mugavamaks?
Vastus on üllatavalt ilmne:
- automatiseerida pilves või väljaspool pilve juurutamise keerulisi aspekte;
- keskenduda usaldusväärsusele, varjates samas keerukust;
- jätkake pidevat tööd lihtsate ja turvaliste värskenduste avaldamise nimel;
- saavutada kontrollitavus ja auditeeritavus;
- püüdma esialgu tagada kõrge turvalisuse, kuid mitte kasutatavuse arvelt.
OpenShifti järgmine väljalase peaks arvestama nii loojate kui ka teiste arendajate kogemustega, kes juurutavad tarkvara suures mahus maailma suurimates ettevõtetes. Lisaks peab see võtma arvesse kõiki avatud ökosüsteemide kogunenud kogemusi, mis on tänapäeva kaasaegse maailma aluseks. Samal ajal on vaja loobuda vanast amatöörarendaja mentaliteedist ja minna üle uuele automatiseeritud tuleviku filosoofiale. See peab ületama lõhe vanade ja uute tarkvara juurutamise viiside vahel ning kasutama täielikult ära kogu saadaoleva infrastruktuuri – olgu seda siis hostinud suurim pilveteenuse pakkuja või see töötab väikestes äärealadel asuvates süsteemides.
Kuidas seda tulemust saavutada?
Red Hatis on tavaks teha pikka aega igavat ja tänamatut tööd, et säilitada väljakujunenud kogukonda ja vältida projektide sulgemist, millega ettevõte on seotud. Avatud lähtekoodiga kogukond sisaldab tohutul hulgal andekaid arendajaid, kes loovad kõige erakordsemaid asju - meelelahutuslikku, harivat, uusi võimalusi avavat ja lihtsalt ilusat, kuid loomulikult ei oota keegi, et kõik osalejad liiguksid samas suunas või taotleksid ühist. eesmärgid. Selle energia ärakasutamine ja õiges suunas ümbersuunamine on mõnikord vajalik, et arendada valdkondi, millest oleks kasu meie kasutajatele, kuid samas peame jälgima oma kogukondade arengut ja neilt õppima.
2018. aasta alguses omandas Red Hat CoreOS projekti, millel olid sarnased tulevikuvaateid – turvalisem ja töökindlam, loodud avatud lähtekoodiga põhimõtetel. Ettevõte on töötanud nende ideede edasiarendamise ja elluviimise nimel, rakendades meie filosoofiat praktikas – püüdes tagada, et kogu tarkvara töötaks ohutult. Kogu see töö on üles ehitatud Kubernetesele, Linuxile, avalikele pilvedele, privaatpilvedele ja tuhandetele teistele projektidele, mis on meie kaasaegse digitaalse ökosüsteemi aluseks.
OpenShift 4 uus väljalase on selge, automatiseeritud ja loomulikum
OpenShifti platvorm hakkab töötama parimate ja töökindlamate Linuxi operatsioonisüsteemidega, millel on paljasmetallist riistvara tugi, mugav virtualiseerimine, automaatne infrastruktuuri programmeerimine ja loomulikult konteinerid (mis on sisuliselt ainult Linuxi pildid).
Platvorm peab olema algusest peale turvaline, kuid võimaldama arendajatel hõlpsasti itereerida, st olema piisavalt paindlik ja turvaline, võimaldades administraatoritel seda hõlpsalt auditeerida ja hallata.
See peaks võimaldama tarkvara käitada "teenusena" ega tohi kaasa tuua operaatorite jaoks juhitamatut infrastruktuuri kasvu.
See võimaldab arendajatel keskenduda kasutajatele ja klientidele reaalsete toodete loomisele. Te ei pea läbi riist- ja tarkvaraseadete džungli kahlata ning kõik juhuslikud komplikatsioonid jäävad minevikku.
OpenShift 4: NoOps platvorm, mis ei vaja hooldust
В kirjeldas neid ülesandeid, mis aitasid kujundada ettevõtte visiooni OpenShift 4-st. Meeskonna eesmärk on võimalikult palju lihtsustada igapäevaseid tarkvara haldamise ja hooldamise ülesandeid, muuta need protsessid lihtsaks ja pingevabaks - nii juurutamisega seotud spetsialistide kui ka arendajate jaoks. Aga kuidas sellele eesmärgile lähemale jõuda? Kuidas luua minimaalset sekkumist vajava tarkvara käitamiseks platvormi? Mida NoOps selles kontekstis üldse tähendab?
Kui proovite abstraktset võtta, siis arendajate jaoks tähendavad mõisted "serverita" või "NoOps" tööriistu ja teenuseid, mis võimaldavad peita "töötava" komponendi või minimeerida seda arendaja koormust.
- Töötage mitte süsteemide, vaid rakendusliidestega (API-dega).
- Ärge vaevake tarkvara juurutamisega – laske teenusepakkujal seda teie eest teha.
- Ärge hüppage kohe suure raamistiku loomisega – alustage väikeste tükkide kirjutamisega, mis toimivad "ehitusplokkidena", proovige panna see kood töötama andmete ja sündmustega, mitte ketaste ja andmebaasidega.
Eesmärk, nagu varemgi, on kiirendada tarkvaraarenduse iteratsioone, anda võimalus luua paremaid tooteid ning et arendaja ei peaks muretsema süsteemide pärast, millel tema tarkvara töötab. Kogenud arendaja teab hästi, et kasutajatele keskendumine võib pilti kiiresti muuta, seega ei tasu tarkvara kirjutamisega liigselt pingutada, kui pole täiesti kindel, et see on vajalik.
Hooldus- ja käitamisprofessionaalide jaoks võib sõna "NoOps" tunduda pisut hirmutav. Kuid väliinseneridega suheldes ilmneb, et nende töökindluse ja töökindluse tagamiseks kasutatavatel mustritel ja tehnikatel (Site Reliability Engineering, SRE) on palju sarnasusi ülalkirjeldatud mustritega:
- Ärge haldage süsteeme – automatiseerige nende juhtimisprotsesse.
- Ärge juurutage tarkvara – looge selle juurutamiseks torujuhe.
- Vältige kõigi oma teenuste koondamist ja laskmist ühe rikke tõttu kogu süsteemil ebaõnnestuda – hajutage need automatiseerimistööriistade abil kogu oma infrastruktuurile ja ühendage need jälgitavatel ja jälgitavatel viisidel.
SRE-d teavad, et midagi võib valesti minna ja nad peavad probleemile jälile jõudma ja parandama – nii automatiseerivad nad rutiinset tööd ja määravad eelnevalt vigade eelarved, et nad oleksid valmis probleemi ilmnemisel prioriteete seadma ja otsuseid langetama.
OpenShifti Kubernetes on platvorm, mis on loodud kahe peamise probleemi lahendamiseks: selle asemel, et sundida teid virtuaalmasinaid või koormuse tasakaalustaja API-sid mõistma, töötab see kõrgema järgu abstraktsioonidega - juurutusprotsesside ja teenustega. Tarkvaraagentide installimise asemel saate käitada konteinereid ja oma jälgimispinu kirjutamise asemel kasutada platvormil juba olemasolevaid tööriistu. Niisiis, OpenShift 4 salajane kaste pole tegelikult mingi saladus – tuleb lihtsalt võtta SRE põhimõtted ja serverita kontseptsioonid ning viia need nende loogilise järelduseni, et aidata arendajaid ja operatsiooniinsenere:
- Automatiseerige ja standardiseerige rakenduste kasutatavat infrastruktuuri
- Ühendage juurutamis- ja arendusprotsesse ilma arendajaid endid piiramata
- Selle tagamine, et XNUMX. teenuse, funktsiooni, rakenduse või kogu virna käivitamine, auditeerimine ja turvamine pole keerulisem kui esimene.
Kuid mis vahe on OpenShift 4 platvormil ja selle eelkäijatel ning "standardsest" lähenemisviisist selliste probleemide lahendamisel? Mis juhib rakendus- ja tegevusmeeskondade mastaapi? Tulenevalt sellest, et kuningas selles olukorras on kobar. Niisiis,
- Veendume, et klastrite eesmärk oleks selge (Kallis pilv, ma võtsin selle klastri üles, sest sain)
- Klastrit teenindavad masinad ja operatsioonisüsteemid (Teie Majesteet)
- Hallake klastri hostide olekut, minimeerige nende ümberehitamist (triivimist).
- Süsteemi iga olulise elemendi jaoks on vaja lapsehoidjat (mehhanismi), mis jälgib ja kõrvaldab probleemid
- Süsteemi *iga* aspekti või elemendi ja sellega seotud taastamismehhanismide ebaõnnestumine on elu normaalne osa
- Kogu infrastruktuur tuleb konfigureerida API kaudu.
- Kasutage Kubernetese käitamiseks Kubernetest. (Jah, jah, see pole kirjaviga)
- Värskendusi peaks olema lihtne ja probleemideta installida. Kui värskenduse installimiseks kulub rohkem kui üks klõps, teeme ilmselt midagi valesti.
- Mis tahes komponendi jälgimine ja silumine ei tohiks olla probleem ning seetõttu peaks jälgimine ja aruandlus kogu infrastruktuuri ulatuses olema samuti lihtne ja mugav.
Kas soovite näha platvormi võimalusi töös?
OpenShift 4 eelvaateversioon on muutunud arendajatele kättesaadavaks. Lihtsalt kasutatava installeri abil saate Red Had CoreOS-i peal AWS-is käitada klastri. Eelvaate kasutamiseks vajate infrastruktuuri loomiseks ainult AWS-i kontot ja eelvaatepiltidele juurdepääsuks kontode komplekti.
- Alustamiseks minge aadressile ja klõpsake nuppu "Alusta".
- Logige sisse oma Red Hati kontole (või looge uus) ja järgige oma esimese klastri seadistamiseks juhiseid.
Pärast edukat installimist vaadake meie õpetusi et saada sügavam arusaam süsteemidest ja kontseptsioonidest, mis muudavad OpenShift 4 platvormi nii lihtsaks ja mugavaks Kubernetese käitamiseks.
Proovige uut OpenShifti väljalaset ja jagage oma arvamust. Oleme pühendunud sellele, et Kumbernetesega töötamine oleks võimalikult juurdepääsetav ja vaevatu – NoOpsi tulevik algab juba täna.
Ja nüüd tähelepanu!
Konverentsil 20. aprillil peab üks OpenShifti arendajatest Vadim Rutkovsky meistriklassi – ta lõhub kümme klastrit ja sunnib neid parandama. Konverents on tasuline, kuid sooduskoodiga #RedHat saad 37% allahindlust
Meistriklass kell 17:15 - 18:15 ja stend on avatud terve päeva. T-särgid, mütsid, kleebised – tavaline!
saal nr 2
"Siin tuleb muuta kogu süsteem: parandame koos sertifitseeritud mehaanikutega katkisi k8-klastreid."
Allikas: www.habr.com