Kaasaegne platvorm tarkvara arendamiseks ja juurutamiseks

See on esimene artikkel seerias materjale, mis käsitlevad muudatusi, parandusi ja täiendusi, mis on tulemas Red Hat OpenShift platvormi versioonis 4.0, et aidata valmistuda üleminekuks uuele versioonile.

Alates hetkest, kui Kubernetes'e areneva kogukonna esindajad sügisel 2014 Google'i Seattle'i kontoris esmakordselt kohtusid, oli selge, et Kubernetes on määratud muutma kaasaegseid tarkvara arendamise ja juurutamise lähenemisviise. Samal ajal jätkasid avalikud pilveteenuse pakkujad aktiivset investeerimist infrastruktuuri ja teenuste arendamisse, mis on oluliselt lihtsustanud IT töö tegemist ja tarkvara loomist, muutes selle uskumatult kergesti kättesaadavaks, millest enamik ei osanud aasta alguses unistadagi.

Muidugi, iga uue pilveteenuse väljakuulutamisega kaasnesid mitmed arutelud ekspertide seas Twitteris, kus vaieldi väga erinevatel teemadel – sealhulgas avatud lähtekoodide ajastu lõpust, kliendipoolse IT langusest (on-premises IT), pilves uue tarkvara monopoli vältimatust ning sellest, kuidas uus X paradigmad asendab kõik eelnevad.

Tuleb mainida, et kõik need arutelud olid pigem rumalad.

Tõde on see, et miski ei kao kuskile ja täna näeme eksponentsiaalset kasvu lõppproduktides ja nende arendamise viisides, mis seondub pideva uue tarkvara ilmumisega meie ellu. Ja hoolimata sellest, et kõik ümberringi muutub, jääb kõik oma olemuselt samaks. Tarkvara arendajad kirjutavad endiselt vigaseid koode, operatsioonitehnika insenerid ja usaldusväärsuse spetsialistid käivad endiselt pageritega ning saavad automaatseid teateid Slackis, juhid opereerivad endiselt OpEx ja CapEx mõistetega ning iga kord, kui tekib tõrge, ohkab vanem arendaja kurvalt: „Ma ütlesin ju.”

Mis on tõeliselt arutlemise väärt., nii et see on see, milliseid tööriistu saame kasutada kvaliteetsemate tarkvaratoodete loomiseks ning kuidas need aitavad suurendada turvalisust ja muuta arenduse lihtsamaks ja usaldusväärsemaks. Projektide keerukuse suurenedes tekivad uued riskid ja täna on inimeste elu nii sõltuv tarkvarast, et arendajad peavad kindlasti pingutama, et oma tööd paremini teha.

Kubernetes on üks sellistest tööriistadest. Töötatakse selle nimel, et Red Hat OpenShift raames ühendada see teiste tööriistade ja teenustega ühtseks platvormiks, mis võimaldaks tarkvara muuta usaldusväärsemaks, haldamiseks mugavamaks ja kasutajatele turvalisemaks.

Arvesse võttes afoonitud, küsivad OpenShift'i meeskond endalt ühte lihtsat küsimust:

Kuidas muuta Kubernetesega töötamine lihtsamaks ja mugavamaks?

Vastus on üllatavalt ilmne:

• automatiseerida keerukaid hetki pilves või pilveväliselt;
• fookust panna usaldusväärsusele, samal ajal keerukust varjates;
• järgida pidevat tööd lihtsate ja turvaliste uuenduste väljalaskmiseks;
• tagada kontrollitavus ja auditivõimalus;
• püüelda algselt kõrge turvalisuse tagamise poole, kuid mitte kasutusmugavuse arvelt.

Järgmine OpenShift'i väljalase peaks arvesse võtma nii loojate kogemusi kui ka teiste arendajate kogemusi, kes suurtes mahtudes juurutavad tarkvara maailma suurimates ettevõtetes. Samuti peab arvesse võtma kogu teadlikkust avatud ökosüsteemide osas, mis tänapäeval moodustavad kaasaegse maailma aluse. Samal ajal tuleb loobuda varasemast hobiarendaja mentaliteedist ja minna üle uuele automatiseeritud tuleviku filosoofiale. See peaks olema „sild” vana ja uue tarkvara juurutamise vahel ning täielikult kasutama kogu olemasolevat infrastruktuuri – pole tähtis, kas seda haldab suurim pilveteenuse pakkuja või töötab see väikestes periferaalsetes süsteemides.

Kuidas sellise tulemuse saavutamine toimub?

Red Hat'is on tavaks teha pikka aega igavat ja tänamatut tööd, et säilitada juba loodud kogukonda ja vältida projektide sulgemist, milles ettevõte osaleb. Open-source kogukonnas on tohutult andekaid arendajaid, kes loovad kõige ebatavalisemaid asju — meelelahutust, haridust, uusi võimalusi ja lihtsalt ilusaid asju, kuid loomulikult ei oota keegi, et kõik osalised liiguksid samas suunas või järgiksid ühiseid eesmärke. Selle energia kasutamine, selle suunamine õigesse voolu, on mõnikord vajalik suundade arendamiseks, mis oleksid meie kasutajatele kasulikud, kuid samal ajal peame jälgima meie kogukondade arengut ja neilt õppima.

2018. aasta alguses omandas Red Hat projekti CoreOS, millel olid sarnased vaated tulevikule — turvalisem ja usaldusväärsem, loodud open-source'i põhimõtete alusel. Ettevõte töötas edasi nende ideede arendamise ja elluviimise nimel, ellu viies meie filosoofiat — püüdes saavutada kogu tarkvara ohutut toimimist. Kogu see töö põhineb Kubernetesel, Linuxil, avalikel ja privaatsetel pilvedel ning tuhandetel teistel projektidel, mis moodustavad meie kaasaegse digitaalekosüsteemi aluse.

Uus OpenShift 4 versioon saab olema arusaadav, automatiseeritud ja loomulikum.

OpenShift'i platvorm töötab parimate ja usaldusväärsete Linuxi operatsioonisüsteemidega, bare-metal riistvara toega, mugava virtualiseerimisega, infrastruktuuri automaatse programmeerimisega ja loomulikult konteineritega (mis sisuliselt on lihtsalt Linuxi pildid).

Platvorm peab olema algusest peale turvaline, kuid samas võimaldama arendajatele mugavaid iteratsioone — see tähendab, et sellel peab olema piisavalt paindlikkust ja usaldusväärsust, samas lubades administraatoritel teostada auditeid ja tagada haldamise mugavus.

See peaks võimaldama jooksutada tarkvara "teenusena" ja mitte viima infrastruktuuri kontrollimatu laienemiseni operaatoritele.

See võimaldab arendajatel keskenduda reaalseid tooteid kasutajatele ja klientidele loomisele. Ei pea läbi ajama seadmete ja tarkvara seadistuste džunglist, ning kõik juhuslikud komplikatsioonid jäävad möödunud aega.

OpenShift 4: NoOps platvorm, mis ei nõua hooldust

Uues selle väljaande käsitleti ülesandeid, mis aitasid kujundada ettevõtte visiooni OpenShift 4 kohta. Meeskonnal on ülesanne maksimaalselt lihtsustada igapäevase tarkvara hoolduse ja juhtimise ülesandeid, muutes need protsessid lihtsaks ja vaevatuks – nii implementijatele kui ka arendajatele. Kuid kuidas sellele eesmärgile läheneda? Kuidas luua tarkvara käitamiseks platvorm, mis vajab minimaalset sekkumist? Mida tähendab NoOps antud kontekstis?

Kui proovida abstraktiseerida, siis arendajate jaoks tähendab mõisted «serverless» või «NoOps» tööriistu ja teenuseid, mis võimaldavad peita „hooldus“ komponendi või minimeerida seda koormust arendajale.

• Töötage mitte süsteemidega, vaid rakendusliideste (API) kaudu.
• Ärge tegelege tarkvara rakendamisega – las selle eest hoolitseb teenusepakkuja.
• Ärge võtke kohe ette suure raamistiku loomist – alustage väikeste fragmentide kirjutamisest, mis toimivad „ehitusplokkidena“, püüdes, et see kood töötaks andmete ja sündmustega, mitte kettade ja andmebaasidega.

Ülesanne, nagu alati, on kiirendada tarkvara arendamise iteratsioone, luua võimalusi kvaliteetsemate toodete loomiseks ja võimaldada arendajal mitte muretseda süsteemide pärast, millel tema tarkvara töötab. Kogenud arendaja mõistab suurepäraselt, et kui keskenduda kasutajatele, võib pilt kiiresti muutuda, seetõttu ei tohiks liiga palju vaeva näha tarkvara kirjutamisega, kui teil puudub absoluutne veendumus selle vajalikkuses.

Süsteemi hoolduses ja kasutamises tegutsevatele spetsialistidele võib sõna „NoOps” tunduda natuke hirmutav. Kuid suhtlemisel operatsioonitehnikutega muutub selgeks, et nende kasutatavad mustrid ja meetodid, mis on suunatud töökindluse tagamisele (Site Reliability Engineering, SRE), kattuvad paljuski eespool kirjeldatud mustritega.

• Ärge juhtige süsteeme – automatiseerige nende haldamise protsessid.
• Ärge tegelege tarkvara juurutamisega – looge selle rakendamiseks tegevusvõrk.
• Püüdke mitte liita kõiki oma teenuseid ja vältige, et ühe neist talitlushäire tooks kaasa kogu süsteemi rikke – jaotage need kogu infrastruktuuri ulatuses, kasutades automatiseerimise vahendeid, ning ühendage need, arvestades võimalust kontrollimiseks ja jälgimiseks.

SRE spetsialistid teavad, et midagi võib valesti minna ja nad peavad jälgima ja lahendama probleeme – seetõttu automatiseerivad nad rutiinse töö ja määratlevad eelnevalt lubatud kõrvalekalded (error budgets), et olla valmis prioriteetide seadmiseks ja otsuste tegemiseks probleemide ilmnemisel.

Kubernetes OpenShiftis on platvorm, mille eesmärk on lahendada kaks peamist ülesannet: selle asemel, et sundida teid tegelema virtuaalmasinate või koormuse tasakaalustamise API-dega, töötate kõrgema taseme abstraktsioonide – juurutamise protsesside ja teenustega. Selle asemel, et installida tarkvara agente, saate käivitada konteinerid, ja selle asemel, et kirjutada oma jälgimistehnoloogia, kasutada platvormil juba olemasolevaid tööriistu. Nii et OpenShift 4 saladus ei ole tegelikult mingi saladus – peate lihtsalt rakendama SRE põhimõtteid ja serverita kontseptsioone ning viima need loogilisse lõpule, et aidata arendajaid ja operatsioonitehnikuid.

• Automatiseerida ja standardiseerida infrastruktuuri, mida rakendused kasutavad.
• Siduda juurutamis- ja arendusprotsessid, piiranguteta arendajatele.
• Tagada, et saja teenuse, funktsiooni, rakenduse või terve tehnoloogiakihi käivitamine, auditeerimine ja turvamine ei oleks üldse keerulisem kui esimese oma.

Kuid mis on OpenShift 4 platvormi erinevus eelkäijatest ja "tavalistest" lähenemistest sarnaste probleemide lahendamiseks? Kuidas saavutatakse meeskondade skaleerimine, kes tegelevad rakendamise ja haldamisega? Ainus, mis loeb, on klaster. Nii et

• Teeme nii, et klastrite eesmärk oleks selge (Kallis pilv, tõstsin selle klaster üles, sest sain).
• Masinad ja operatsioonisüsteemid eksisteerivad selleks, et teenindada klastrit (Teie Majesteet).
• Hallake hostide olekut klastrist, minimiseerige nende muutumist (drift).
• Iga olulise süsteemielemendi jaoks on vajalik lapsehoidja (mehhanism), mis jälgib ja lahendab probleeme.
• Iga süsteemi aspekti või elemendi rike ning vastavad taastumise mehhanismid on tavaline osa elust.
• Kogu infrastruktuur peab olema konfigureeritud API kaudu.
• Kasutage Kubernetes't Kubernetes'e käitamiseks. (Jah-jah, see pole trükiviga.)
• Uuendused peavad olema hõlpsasti ja vaevatult installitud. Kui uuenduse installimiseks on vajalik rohkem kui üks hiireklõps, siis ilmselgelt teeme midagi valesti.
• Iga komponendi jälgimine ja tõrkeotsing ei tohiks probleeme tekitada ning seega peab kogu infrastruktuuri jälgimine ja aruandlus olema samuti lihtne ja mugav.

Kas soovite näha platvormi võimalusi tegutsemas?

OpenShift 4 eelversioon on arendajatele saadaval. Lihtsa paigaldustööriista abil saab klastrit käivitada AWS-is Red Hat CoreOS'i peal. Eelversiooni kasutamiseks on vajalik vaid AWS-i konto infrastruktuuri pakkumiseks ja hulk kontosid eelversiooni piltide juurde pääsemiseks.

1. Alustamiseks minge aadressile try.openshift.com ja klõpsake “Get Started.”
2. Logige sisse oma Red Hat kontole (või looge uus) ja järgige juhiseid oma esimese klastrite seadistamiseks.

Pärast eduka paigaldamise lõpetamist tutvuge meie koolitusmaterjalidega OpenShift Training, et saada üksikasjalik ülevaade süsteemidest ja kontseptsioonidest, mis muudavad OpenShift 4 platvormi nii lihtsaks ja mugavaks tööriistaks Kubernetes'e käitamiseks.

Proovige uut OpenShift'i väljaannet ja jagage oma arvamust. Meie eesmärk on teha Kubernetesega töötamine võimalikult lihtsaks ja pingutuseta – NoOps tulevik algab juba täna.

Ja nüüd tähelepanu!
Konverentsil DevOpsForum 2019 20. aprillil viib üks OpenShift'i arendajatest, Vadim Rutkovski, läbi meistriklassi — lõhub kümme klastrit ja paneb need remontima. Konverents on tasuline, kuid sooduskoodiga #RedHat on 37% allahindlus.

Meistriklass toimub kell 17:15 – 18:15, ning stend on avatud kogu päeva. T-särgid, mütsid, kleebised – nagu ikka!

Saali #2
„Siin tuleb kogu süsteem muuta: parandame purunenud k8s klastreid koos sertifitseeritud meistritega.“

Allikas: habr.com