To je prva objava v seriji gradiv, posvečenih spremembam, izboljšavam in dopolnili v prihajajoči različici platforme Red Hat OpenShift 4.0, ki bodo pomagale pri prehodu na novo različico.
Že od trenutka, ko so se predstavniki šele nastajajoče skupnosti Kubernetes prvič zbrali jeseni 2014 v pisarni Googla v Seattlu, je bilo mogoče reči, da je projektu Kubernetes usojeno, da temeljito spremeni sodobne pristope k razvoju in uvajanju programske opreme. Hkrati so javni ponudniki oblačnih storitev še naprej aktivno vlagali v razvoj infrastrukture in storitev, kar je znatno olajšalo in poenostavilo delo na IT-ju in ustvarjanje programske opreme ter jih naredilo izjemno dostopne, kar si je na začetku desetletja težko predstavljati.
Seveda je vsak nov oblačni servis spremljala množica razprav strokovnjakov na Twitterju, pri čemer so se razprave dotikale najrazličnejših tem – vključno s koncem dobe odprtokodnega programja, zatonu IT na strani strank (on-premises IT), neizbežnostjo nove programske monopole v oblaku in tem, kako nova paradigma X nadomesti vse druge paradigme.
Ni treba posebej poudarjati, da so bile vse te razprave precej neumne.
Resničnost pa je takšna, da nič ne izgine, in danes lahko opazimo eksponentno rast končnih produktov in načinov njihovega razvoja, kar je povezano s stalnim pojavljanjem nove programske opreme v naših življenjih. In čeprav se bo vse okoli nas spreminjalo, bo v svoji bistvi vse ostalo nespremenjeno. Razvijalci programske opreme bodo še naprej pisali kodo z napakami, operativni inženirji ter strokovnjaki za zanesljivost bodo še naprej nosili pagerje in prejemali samodejna obvestila v Slacku, managerji bodo še naprej uporabljali pojme OpEx in CapEx, in vsakič, ko bo prišlo do okvare, bo starejši razvijalec s težkim srcem vzdihnil z besedami: 'Rekel sem!'…
Tisto, kar bi resnično morali razpravljati., to so, what tools can we have at our disposal to create higher quality software products, and how do they enhance security and make development easier and more reliable. With the increasing complexity of projects, new risks arise, and today people's lives are so dependent on software that developers must strive to do their jobs better.
Kubernetes is one of those tools. Work is underway to integrate it with other tools and services within Red Hat OpenShift into a single platform that would make software more reliable, easier to manage, and safer for users.
With that said, the OpenShift team is asking one simple question:
How can working with Kubernetes be made simpler and more convenient?
The answer is surprisingly obvious:
- automate complex moments in deploying in the cloud or on-premises;
- focus on reliability while hiding complexity;
- continue the constant work of releasing simple and secure updates;
- achieve controllability and auditability;
- aim to ensure high security from the start, but not at the expense of usability.
The next release of OpenShift must take into account both the experiences of creators and the experiences of other developers who are implementing software on a large scale in the world's largest companies. Additionally, it should consider the accumulated experience of open ecosystems that are foundational to the modern world today. At the same time, it is necessary to abandon the old mentality of the amateur developer and move towards a new philosophy of automated future. It must be a 'bridge' between past and new deployment methods and fully utilize all available infrastructure - no matter whether it is served by a major cloud provider or launched on tiny edge systems.
How to achieve such a result?
V Red Hatu je običaj da se dugotrajno obavljaju dosadni i nezahvalni poslovi kako bi se očuvala uspostavljena zajednica i sprečilo zatvaranje projekata u kojima kompanija učestvuje. U open-source zajednici postoji ogroman broj talentovanih programera koji kreiraju najneobičnije stvari – zabavne, edukativne, otvarajući nove mogućnosti i jednostavno prelepe, ali, naravno, niko ne očekuje da će svi učesnici ići u istom pravcu ili da će imati zajedničke ciljeve. Korišćenje te energije, preusmeravanje iste u pravom smeru, ponekad je neophodno za razvoj pravaca koji bi bili korisni našim korisnicima, ali istovremeno moramo pratiti razvoj naših zajednica i učiti od njih.
Početkom 2018. godine, Red Hat je kupio projekat CoreOS, koji je imao slične poglede na budućnost – bezbedniju i pouzdaniju, zasnovanu na principima open-source. Kompanija je radila na daljem razvoju ovih ideja i njihovoj realizaciji, primenjujući našu filosofiju – nastojeći da postigne bezbedan rad svega softverskog rešenja. Sav ovaj rad se oslanja na Kubernetes, Linux, javne oblake, privatne oblake i hiljade drugih projekata koji čine osnovu naše savremene digitalne ekosisteme.
Nova verzija OpenShift 4 biće jasna, automatizovana i prirodnija.
Platforma OpenShift će raditi sa najboljim i najpouzdanijim operativnim sistemima Linux, sa bare-metal hardverskom podrškom, praktičnom virtualizacijom, automatskim programiranjem infrastrukture i, naravno, kontejnerima (koji su u suštini samo Linux slike).
Platforma treba da bude bezbedna od samog početka, ali istovremeno omogućiti jednostavne iteracije za programere – to jest, imati dovoljnu fleksibilnost i pouzdanost, a da istovremeno omogući administratorima da vrše audite i obezbede lako upravljanje.
Ona treba da omogućava pokretanje softvera „kao usluga“, a da ne dovodi do nekontrolisane ekspanzije infrastrukture za operatore.
Tož bo razvijalcem omogočila, da se osredotočijo na ustvarjanje pravih produktov za uporabnike in stranke. Ni vam treba prebijati skozi goščavo nastavitev strojne in programske opreme, vse naključne zaplete pa bodo ostali v preteklosti.
OpenShift 4: NoOps platforma, ki ne zahteva vzdrževanja
V Opisane so naloge, ki so pripomogle k oblikovanju vizije podjetja glede OpenShift 4. Ekipa si prizadeva poenostaviti vsakodnevne naloge vzdrževanja in podpore programske opreme ter narediti te procese lahke in brezskrbne – tako za strokovnjake, ki se ukvarjajo z implementacijo, kot tudi za razvijalce. Kako pa je mogoče doseči ta cilj? Kako ustvariti platformo za zagon programske opreme, ki zahteva minimalno posredovanje? Kaj v tem kontekstu sploh pomeni NoOps?
Če se poskušate abstrahirati, pojma "serverless" ali "NoOps" za razvijalce pomenita orodja in storitve, ki omogočajo skrivanje "operativne" komponente ali minimaliziranje bremena za razvijalca.
- Delujte z aplikativnimi vmesniki (API) in ne s sistemi.
- Ne ukvarjajte se z implementacijo programske opreme – naj to namesto vas stori ponudnik.
- Ne smete se takoj lotiti ustvarjanja velikega okvirja – začnite z nekaterimi manjšimi deli, ki bodo služila kot "gradniki", in poskrbite, da bo ta koda delovala z podatki in dogodki, ne pa z diski in podatkovnimi bazami.
Cilj, kot vedno, je pospešiti iteracije pri razvoju programske opreme, omogočiti ustvarjanje kakovostnejših produktov in poskrbeti, da se razvijalec ne bo moral obremenjevati s sistemi, na katerih teče njegova programska oprema. Izkušen razvijalec zelo dobro razume, da se lahko slika hitro spremeni, če se osredotočite na uporabnike, zato ni smiselno vlagati preveč truda v programsko opremo, če nimate absolutne prepričanosti o njeni nujnosti.
Za strokovnjake, ki se ukvarjajo z vzdrževanjem in obratovanjem, se lahko izraz „NoOps“ sliši nekoliko zastrašujoče. A med pogovorom z inženirji za obratovanje postane očitno, da se vzorci in metodologije, ki jih uporabljajo za zagotavljanje zanesljivosti (Site Reliability Engineering, SRE), v veliki meri prekrivajo z zgoraj opisanimi vzorci:
- Ne upravljajte s sistemi – avtomatizirajte procese njihovega upravljanja.
- Ne ukvarjajte se z uvedbo programske opreme – raje ustvarite pipeline za njeno uvajanje.
- Trudite se, da ne združite vseh svojih storitev skupaj in ne dopustite, da neuspeh ene izmed njih pripelje do neuspeha celotnega sistema – razpršite jih po celotni infrastrukturi, uporabite avtomatizacijska orodja in jih povežite z možnostjo nadzora in spremljanja.
Strokovnjaki za SRE vedo, da lahko kaj gre narobe, zato morajo spremljati in odpravljati težave – zato avtomatizirajo rutinsko delo in se vnaprej dogovorijo o sprejemljivih odstopanjih (error budgets), da bodo lahko prioritizirali in sprejemali odločitve, kadar se pojavijo težave.
Kubernetes v OpenShiftu je platforma, namenjena reševanju dveh glavnih nalog: namesto da vas prisili, da se ukvarjate z virtualnimi stroji ali API-ji uravnoteževalnikov obremenitev, se obravnavajo višji nivoji abstrakcije – procesi uvajanja in storitve. Namesto nameščanja programske opreme lahko zaženete kontejnerje, namesto da bi pisali svoj sistem za nadzor, uporabite že obstoječa orodja na platformi. Tako skrivni sestavina OpenShift 4 v resnici ni nobena skrivnost – preprosto je treba uporabiti načela SRE in brezstrežna koncepta ter jih izpeljati do logičnega zaključka, da bi pomagala razvijalcem in inženirjem za obratovanje:
- Avtomatizirati in standardizirati infrastrukturo, ki jo uporabljajo aplikacije.
- Povezati procese uvajanja in razvoja, ne da bi pri tem omejili same razvijalce.
- Zagotoviti, da je zagon, revizija in zagotavljanje varnosti stotega servisa, funkcije, aplikacije ali celotnega sklada prav tako enostavno kot prvega.
Kako se OpenShift 4 razlikuje od svojih prethodnika i od „standardnog“ pristupa rešavanju sličnih problema? Kako se postiže skaliranje za timove koji se bave implementacijom i eksploatacijom? Na osnovu toga što je kralj u ovoj situaciji — klaster. dakle,
- Učinite da svrha klastera bude jasna (Skupo oblak, ovaj klaster sam podigao jer sam mogao)
- Mašine i operativni sistemi postoje da bi opslužili klaster (Vaša Visost)
- Upravljajte stanjem hostova sa klastera, minimizirajte njihova premeštanja (drift).
- Za svaki važan element sistema potrebna je beba-sitter (mehanizam) koja će pratiti i rešavati probleme
- Kvar *svakog* aspekta ili elementa sistema odgovarajući mehanizmi oporavka — deo su svakodnevnog života
- Cela infrastruktura mora biti konfigurisana putem API-a.
- Koristite Kubernetes za pokretanje Kubernetesa. (Da, da, ovo nije greška)
- Ažuriranja treba da se instaliraju lako i prirodno. Ako za instalaciju ažuriranja treba više od jednog klika miša, očigledno je da radimo nešto pogrešno.
- Praćenje i debagovanje bilo kojeg komponenta ne bi trebala da bude problem, a samim tim i praćenje i izveštavanje o celoj infrastrukturi takođe treba da bude jednostavno i zgodno.
Želite li videti mogućnosti platforme u akciji?
Beta verzija OpenShift 4 postala je dostupna programerima. Sa jednostavnim instalaterom možete pokrenuti klaster na AWS-u iznad Red Hat CoreOS. Za korišćenje beta verzije potrebna je samo AWS nalog za obezbeđivanje infrastrukture i set naloga za pristup beta slikama.
- Za početak, idite na i kliknite na “Get Started”.
- Prijavite se u svoj Red Hat nalog (ili kreirajte novi) i pratite uputstva da biste postavili svoj prvi klaster.
Nakon uspešne instalacije, upoznajte se sa našim obrazovnim materijalima , da biste dobili detaljniji uvid u sisteme i koncepte koji čine platformu OpenShift 4 tako jednostavnim i korisnim alatom za pokretanje Kubernetesa.
Preizkusite novo izdajo OpenShift in delite svoje mnenje. Prizadevamo si, da bi delo s Kubernetesom bilo čim bolj dostopno in brez napora – prihodnost NoOps se začne že danes.
In zdaj pozor!
Na konferenci 20. aprila bo eden od razvijalcev OpenShift, Vadim Rutkovski, izvedel mojstrski tečaj – razbil bo deset grozdov in nas naučil, kako jih popraviti. Konferenca je plačljiva, toda s promocijsko kodo #RedHat popust 37%.
Mojstrski tečaj bo od 17:15 do 18:15, stojnica pa deluje čez dan. T-majice, kape, nalepke – kot običajno!
Dvorana #2
„Tukaj je treba spremeniti celoten sistem: popravljamo pokvarjene k8s grozde skupaj s certificiranimi mojstri.“
Izvor: habr.com
