Kliimahalduse korraldamine kollektiivis

See on esimene väljaanne sarjast materjale, mis käsitleb Red Hat OpenShifti 4.0 platvormi tulevaste uuenduste, parenduste ja lisaelementide muutusi, mis aitavad valmis olla üleminekuks uuele versioonile.

Alates hetkest, mil Kubernetes'e alles kujuneva kogukonna esindajad esmakordselt 2014. aasta sügisel Google'i kontoris Seattle'is kokku said, oli juba selge, et Kubernetes on määratud muutma kaasaegseid lähenemisviise tarkvara arendamisele ja rakendamisele. Samal ajal jätkasid avalikud pilveteenuste pakkujad aktiivset investeerimist infrastruktuuri ja teenuste arendamisse, mis sageli lihtsustas ja hõlbustas IT-d ja tarkvara loomist, muutes need uskumatult kergesti kättesaadavaks, mille üle ei osanud keegi unistadagi veel kümnendi alguses.

Muidugi, iga uue pilveteenuse kuulutamisega kaasnes mitmeid arutelusid spetsialistide seas Twitteris, kus vaidlused käidi erinevatel teemadel - sealhulgas avatud lähtekoodide ajastu lõpp, klientide (on-premises IT) IT-d lõpp, uue tarkvaramonopoli vältimatuse üle pilves ning kuidas uus X paradiigma asendab kõik teised paradiigmad.

Pole vaja öelda, et kõik need vaidlused olid üsna rumalad.

Reaalsus on see, et miski ei kao kuhugi ja täna on võimalik jälgida lõppproduktide ja nende arendamise viiside eksponentsiaalset kasvu, mis on seotud pidevalt meie ellu tuleva uue tarkvaraga. Ja vaatamata sellele, et kõik ümberringi muutub, jääb kõik oma olemuselt muutumatuks. Tarkvaraarendajad kirjutavad ikka veel vigadega koodi, opsiekspedeerijad ja usaldusspetsialistid käivad endiselt pageritega ning saavad automaatseid teateid Slackis, juhid opereerivad endiselt mõistetega OpEx ja CapEx, ja iga kord, kui ilmneb rike, ohkab vanem arendaja kurvalt sõnadega: „Ma ju ütlesin...“

Mis on tõeliselt arutleda, nii et need on tööriistad, mida meil on võimalik kasutada, et luua kvaliteetsemaid tarkvaratooteid, ja kuidas need aitavad parandada turvalisust ning muuta arenduse lihtsamaks ja usaldusväärsemaks. Projektide keerukuse suurenemisega kaasnevad uued riskid ning tänapäeval sõltuvad inimeste elud nii palju tarkvarast, et arendajad peavad lihtsalt püüdma oma tööd paremini teha.

Kubernetes on üks selline tööriist. Red Hat OpenShift'i raames tehakse tööd selle integreerimise nimel teiste tööriistade ja teenustega, et luua ühtne platvorm, mis muudaks tarkvara usaldusväärsemaks, haldamise lihtsamaks ja kasutajate jaoks turvalisemaks.

Nagu öeldud, küsib OpenShift'i meeskond endalt lihtsat küsimust:

Kuidas saaks Kubernetes'e kasutamist lihtsustada ja mugavamaks muuta?

Üllataval kombel on vastus ilmne:

• automatiseerida keerulisi hetki pilves või väljaspool seda;
• fookustada usaldusväärsusele, varjates samal ajal keerukust;
• jätkata pidevat tööd lihtsate ja turvaliste uuenduste väljalaskmisel;
• saama kontrollitavust ja auditeeritavust;
• püüdma algusest peale pakkuda kõrge turvalisuse taset, kuid mitte kasutatavuse arvelt.

Järgmine OpenShift'i versioon peab arvestama nii arendajate kui ka teiste tarkvaraarendajate kogemustega, kes rakendavad tarkvara suurel skaalal maailma suurimates ettevõtetes. Samuti peab see arvestama kogu avatud ökosüsteemide kogutud kogemustega, mis tänapäeva maailmas aluseks on. Peame loobuma varasest harjumusest, mis on seotud hobiarendajaga, ja minema üle uuele automatiseeritud tuleviku filosoofiale. See peaks olema "sild" vanade ja uute tarkvarade kasutamise viiside vahel ning täielikult ära kasutama kogu olemasolevat infrastruktuuri – olenemata sellest, kas seda teenindab suurima pilveteenuse pakkuja või see on üles seadistatud väikestes servasüsteemides.

Kuidas selleni jõuda?

Red Hat'is on traditsioon kaua aega raisata igavaid ja tänamatuid ülesandeid, et säilitada väljakujunenud kogukond ja vältida projektide sulgemist, milles ettevõte osaleb. Avatud lähtekoodiga kogukonnas on suur hulk andekaid arendajaid, kes loovad erakordseid asju – meelelahutuslikke, harivaid, uusi võimalusi avavaid ja lihtsalt ilusaid. Kuid loomulikult ei oota keegi, et kõik osalejad liiguvad ühes suunas või järgivad ühiseid eesmärke. Selle energia kasutamine, suunamine õigesse kohta on mõnikord vajalik suundumuste arendamiseks, mis oleksid meie kasutajatele kasulikud, kuid samal ajal peame jälgima oma kogukondade arengut ja neist õppima.

2018. aasta alguses omandas Red Hat CoreOS projekti, millel olid sarnased vaated tulevikule – turvalisem ja usaldusväärsem, põhinev avatud lähtekoodiga printsiipidel. Ettevõte töötas nende ideede edasise arendamise ja rakendamise nimel, järgides meie filosoofiat – saavutada kogu tarkvara ohutu töö. Kõik see töö põhineb Kubernetesel, Linuxil, avalikel ja privaatsetel pilvedel ning tuhandetel teistel projektidel, mis on meie kaasaegse digitaalökosüsteemi aluseks.

Uus OpenShift 4 väljaanne on arusaadav, automatiseeritud ja loomulik.

OpenShift platvorm töötab parimate ja usaldusväärsete Linuxi operatsioonisüsteemidega, bare-metal riistvaratoega, mugava virtualiseerimisega, infrastruktuuri automaatse programmeerimisega ja loomulikult konteineritega (mis on põhimõtteliselt lihtsalt Linuxi pildid).

Platvorm peab olema algusest peale turvaline, kuid samas võimaldama arendajatele mugavaid iteratsioone – see tähendab, et tal peab olema piisavalt paindlikkust ja usaldusväärsust, võimaldades samas administraatoritel auditit läbi viia ja haldamist hõlbustada.

See peab võimaldama tarkvara käivitamist „teenusena“ ning mitte viima operaatorite jaoks juhtimatu infrastruktuuri laienemiseni.

See võimaldab arendajatel keskenduda tõeliste toodete loomisele kasutajatele ja klientidele. Ei pea enam läbi illustreeritud seadistuste ja tarkvara džungli läbima, kõik juhuslikud keerukused jäävad minevikku.

OpenShift 4: NoOps platvorm, mis ei vaja hooldust.

V selles publikatsioonis kirjeldatud ülesanded aitasid kujundada ettevõtte nägemust OpenShift 4 osas. Meeskonnal on ülesanne maksimaalselt lihtsustada igapäevaste tarkvara haldamise ja hooldamise ülesannete täitmist, et need protsessid oleksid sujuvad ja muretud – nii rakendajatele kui ka arendajatele. Kuid kuidas selle eesmärgiga läheneda? Kuidas luua tarkvara käivitamise platvorm, mis vajab minimaalset sekkumist? Mida tähendab NoOps selle konteksti jaoks?

Kui püüda abstraktse mõtlemise suunas liikuda, siis arendajate jaoks tähendavad mõisted „serverless” või „NoOps” tööriistu ja teenuseid, mis võimaldavad varjata „haldamise” aspekti või minimeerida selle koormust arendajale.

• Töötage mitte süsteemidega, vaid rakendusliideste (API) kaudu.
• Ärge tegelege tarkvara rakendamisega – laske selle eest hoolitseda teenusepakkujatel.
• Ära proovige kohe luua suurt raamistikku – alustage väikeste fragmentide kirjutamisega, mis toimivad "ehitusplokkidena". Püüdke, et see kood töötaks andmete ja sündmustega, mitte ketaste ja andmebaasidega.

Nagu varemgi, on eesmärk kiirendada tarkvara arendamise iteratsioone, pakkuda võimalust kvaliteetsemate toodete loomiseks ning et arendaja ei peaks muretsema selle üle, millistel süsteemidel tema tarkvara käivitub. Kogenud arendaja mõistab suurepäraselt, et kui keskenduda kasutajatele, võib olukord kiiresti muutuda. Seetõttu ei tasu pühendada liiga palju aega tarkvara kirjutamisele, kui teil pole selle vajalikkuses täiesti kindlat veendumust.

Operatsioonigruppide töötajatele võib termin "NoOps" kõlada hirmutavalt. Kuid diskussioonides operatsioonitehnika inseneridega on selge, et nende kasutatavad mustrid ja tehnikad, mis on suunatud usaldusväärsuse tagamisele (Site Reliability Engineering, SRE), kattuvad suurel määral ülaltoodud mustritega:

• Ärge haldage süsteeme – automatiseerige nende haldusprotsessid.
• Ärge tegelege tarkvara juurutamisega – looge selle ülesseadmise töövoog.
• Ärge pange kõiki oma teenuseid kokku ja vältige olukordi, kus ühe teenuse tõrge põhjustab kogu süsteemi pealejõudmise – hajutage need oma infrastruktuuri ja kasutage automatiseerimise vahendeid, et neid siduda ning tagada kontroll ja jälgimine.

SRE spetsialistid teavad, et midagi võib valesti minna, ja nad peavad jälgima ja lahendama probleeme – seetõttu nad automatiseerivad rutiinset tööd ja määravad ette lubatud kõrvalekalded (error budgets), et valmistuda prioriteetide seadmiseks ja otsustamiseks probleemide korral.

Kubernetes OpenShiftis on platvorm, mis on loodud kahe peamise ülesande täitmiseks: selle asemel, et sundida teid tegelema virtuaalmasinate või koormuse jaotamise API-dega, töötate kõrgema taseme abstraktsioonidega – rakenduste juurutamise ja teenustega. Tarkvaraliidese paigaldamise asemel saate käivitada konteinerid ja oma jälgimisstacki loomise asemel kasutada juba platvormil olemasolevaid tööriistu. Seega, OpenShift 4 saladus ei ole tegelikult saladus – peate lihtsalt lähtuma SRE põhimõtetest ja serverivabast kontseptsioonist ning viima need loogiliselt lõpule, et aidata arendajaid ja operatiivinseneride tööd:

• Automatiseerida ja standardiseerida infrastruktuuri, mida rakendused kasutavad
• Siduda kokku juurutamise ja arendamise protsessid, piirates samas arendajate tegevust
• Tagada, et sadade teenuste, funktsioonide, rakenduste või tervikstaki käivitamine, auditeerimine ja turvamine ei oleks keerulisem kui esimest.

Kuidas erineb OpenShift 4 platvorm oma eelkäijatest ja "standardsetest" lähenemistest sarnaste probleemide lahendamiseks? Kuidas saavutatakse meeskondade jaoks, kes tegelevad juurutamise ja haldamisega, skaleerimine? Selle saavutab klaster, kes on siin peamine tegija. Nii et

• Teeme nii, et klastrite eesmärk oleks selge (Kallis pilv, tõstsime selle klastriga, sest oskasin seda teha)
• Masinad ja operatsioonisüsteemid eksisteerivad selleks, et teenida klastrit (Teie Kuninglikkus)
• Halda hostide olekut klastrist, minimeeri nende ümberkasutamine (drift).
• Iga süsteemi olulise elemendi jaoks on vajalik beebivalve (mehhanism), mis jälgib ja lahendab probleeme.
• Häire *iga* süsteemi aspektis või elemendis on taastumise mehhanismid — see on tavaline elu osa.
• Kogu infrastruktuur peab olema konfigureeritav API kaudu.
• Kasutage Kuberneteset Kubernetes käivitamiseks. (Jah, see pole trükiviga)
• Uuendused peavad olema lihtsad ja vaevatuks. Kui uuenduse installimiseks on vajalik rohkem kui üks hiireklõps, siis ilmselgelt teeme me midagi valesti.
• Komponentide jälgimine ja tõrkeotsing ei tohiks olla probleem, seega peaks kogu infrastruktuuri jälgimine ja arvestamine olema samuti lihtne ja mugav.

Kas soovite näha platvormi võimalusi praktikas?

OpenShift 4 eelversioon on arendajatele nüüd saadaval. Lihtsa installeri abil saab AWS-is Red Hat CoreOS-i peal klastrit käivitada. Eelversiooni kasutamiseks on vajalik ainult AWS konto, et pakkuda infrastruktuuri ja komplekt konto jaoks, et pääseda eelversioonide piltidele.

1. Alustamiseks minge sellele lehele try.openshift.com ja klikkige "Get Started."
2. Logige sisse oma Red Hat kontole (või looge uus) ja järgige juhiseid, et seadistada oma esimene klaster.

Pärast edukat installimist tutvuge meie õpikute materjalidega OpenShift Training, et saada põhjalik ülevaade süsteemidest ja kontseptsioonidest, mis teevad OpenShift 4 platvormi nii lihtsaks ja mugavaks tööriistaks Kubernetes'i käivitamiseks.

Proovige uut OpenShifti versiooni ja jagage oma arvamust. Meie eesmärk on muuta Kubernetesiga toimetamine võimalikult lihtsaks ja vaevatuks – NoOps tulevik algab juba täna.

Ja nüüd tähelepanu!
Konverentsil DevOpsFoorum 2019 20. aprillil viib OpenShifti arendaja Vadim Rutkovski läbi töötoa — purustab kümme klastrit ja paneb need parandama. Üritus on tasuline, kuid sooduskoodiga #RedHat on 37% allahindlus.

Töötuba kell 17:15 – 18:15, samas kui stend töötab kogu päeva. T-särgid, mütsid, kleebised – nagu tavaliselt!

Saal #2
«Siin tuleb kogu süsteem muuta: parandame katki läinud k8s klastrid koos sertifitseeritud mehaanikutega.»

Allikas: habr.com