Ez az első bejegyzés a Red Hat OpenShift platform 4.0 közelgő frissítésének változásairól, fejlesztéseiről és kiegészítéseiről, amelyek segítenek felkészülni az új verzióra való átállásra.
Attól a pillanattól kezdve, hogy a cseperedő Kubernetes-közösség 2014 őszén először összegyűlt a Google seattle-i irodájában, egyértelmű volt, hogy a Kubernetes-projekt célja, hogy forradalmasítsa a mai szoftverfejlesztési és telepítési módot. Ugyanakkor a nyilvános felhőszolgáltatók továbbra is aktívan fektettek be az infrastruktúra és a szolgáltatások fejlesztésébe, ami jelentősen megkönnyítette és elérhetőbbé tette az IT-vel való munkát és a szoftverek létrehozását, és hihetetlenül hozzáférhetővé tette azokat, amit az év elején kevesen gondolhattak volna. az évtized.
Természetesen az egyes új felhőszolgáltatások bejelentését számos szakértői megbeszélés kísérte a Twitteren, és számos témában folytak viták – többek között a nyílt forráskódú korszak végéről, a helyszíni IT hanyatlásáról és az elkerülhetetlenségről. egy új szoftvermonopóliumról a felhőben, és hogyan váltja fel az új X paradigma az összes többi paradigmát.
Mondanom sem kell, hogy ezek a viták nagyon ostobák voltak
A valóság az, hogy soha semmi nem megy kárba, és ma már a végtermékek és fejlesztési módok exponenciális növekedését láthatjuk, az új szoftverek folyamatos megjelenése miatt. És annak ellenére, hogy körülötte minden megváltozik, ugyanakkor lényegében minden változatlan marad. A szoftverfejlesztők továbbra is hibás kódokat írnak majd, az üzemeltetési mérnökök és a megbízhatósági szakemberek továbbra is a személyhívókkal járnak majd, és automatikus figyelmeztetéseket kapnak a Slackban, a menedzserek továbbra is az OpEx és a CapEx koncepciójában fognak működni, és minden hiba esetén a vezető a fejlesztő szomorúan felsóhajt a következő szavakkal: "Megmondtam"...
ó, valóban meg kell vitatni, milyen eszközök állnak rendelkezésünkre a jobb szoftvertermékek létrehozásához, és hogyan javíthatják a biztonságot, és hogyan tehetik könnyebbé és megbízhatóbbá a fejlesztést. A projektek összetettebbé válásával új kockázatok merülnek fel, és ma az emberek élete annyira függ a szoftverektől, hogy a fejlesztőknek egyszerűen meg kell próbálniuk jobban végezni a munkájukat.
A Kubernetes egy ilyen eszköz. Folyamatban van a Red Hat OpenShift más eszközökkel és szolgáltatásokkal való egyesítése egyetlen platformmá, amely megbízhatóbbá, könnyebben kezelhetővé és a felhasználók számára biztonságosabbá tenné a szoftvert.
Ezzel együtt az OpenShift csapata egy egyszerű kérdést tesz fel:
Hogyan teheti könnyebbé és kényelmesebbé a Kubernetes-szel való munkát?
A válasz meglepően egyértelmű:
- automatizálja a felhőben vagy a felhőn kívüli telepítés összetett szempontjait;
- összpontosítson a megbízhatóságra, miközben elrejti a bonyolultságot;
- folytassa az egyszerű és biztonságos frissítések kiadását;
- ellenőrizhetőség és auditálhatóság elérése;
- kezdetben törekedni kell a magas szintű biztonság biztosítására, de nem a használhatóság rovására.
Az OpenShift következő kiadásának figyelembe kell vennie mind az alkotók tapasztalatait, mind a többi fejlesztő tapasztalatát, akik nagy léptékben implementálnak szoftvereket a világ legnagyobb vállalataiban. Ezenkívül figyelembe kell vennie a nyitott ökoszisztémák összes felhalmozott tapasztalatát, amelyek a mai modern világ hátterében állnak. Ugyanakkor fel kell hagyni az amatőr fejlesztő régi mentalitásával, és át kell térni az automatizált jövő új filozófiájára. Át kell hidalnia a szakadékot a régi és az új szoftvertelepítési módok között, és teljes mértékben ki kell használnia az összes rendelkezésre álló infrastruktúra előnyeit – akár a legnagyobb felhőszolgáltató üzemelteti, akár a szélén lévő apró rendszereken fut.
Hogyan lehet elérni ezt az eredményt?
A Red Hatnél bevett szokás, hogy hosszú ideig unalmas és hálátlan munkát végeznek a kialakult közösség megőrzése és a céget érintő projektek bezárásának megakadályozása érdekében. A nyílt forráskódú közösségben rengeteg tehetséges fejlesztő található, akik a legkülönlegesebb dolgokat hoznak létre - szórakoztató, oktató, új lehetőségeket nyitó és egyszerűen szépeket, de természetesen senki sem várja el, hogy mindenki ugyanabba az irányba haladjon, vagy közös célokra törekedjen. . Ennek az energiának a kiaknázása és a helyes irányba terelése olykor szükséges ahhoz, hogy olyan területeket fejlesszünk ki, amelyek a felhasználóink javát szolgálják, ugyanakkor figyelemmel kell kísérnünk közösségeink fejlődését, és tanulnunk kell belőlük.
2018 elején a Red Hat felvásárolta a CoreOS projektet, amely hasonló nézeteket vallott a jövőről – biztonságosabb és megbízhatóbb, nyílt forráskódú elven készült. A vállalat ezen ötletek továbbfejlesztésén és megvalósításán dolgozott, filozófiánkat a gyakorlatba ültetve – igyekezett biztosítani, hogy minden szoftver biztonságosan fusson. Mindezek a munkák Kubernetesre, Linuxra, nyilvános felhőkre, privát felhőkre és több ezer egyéb projektre épülnek, amelyek modern digitális ökoszisztémánkat támasztják alá.
Az OpenShift 4 új kiadása áttekinthető, automatizált és természetesebb lesz
Az OpenShift platform a legjobb és legmegbízhatóbb Linux operációs rendszerekkel fog működni, csupasz hardver támogatással, kényelmes virtualizációval, automatikus infrastruktúra programozással és természetesen konténerekkel (amelyek lényegében csak Linux képek).
A platformnak kezdettől fogva biztonságosnak kell lennie, de lehetővé kell tennie a fejlesztők számára az egyszerű iterációt – vagyis kellően rugalmasnak és biztonságosnak kell lennie, miközben lehetővé teszi a rendszergazdák számára, hogy könnyen ellenőrizzék és kezeljék.
Lehetővé kell tennie a szoftverek „szolgáltatásként” futtatását, és nem vezethet az infrastruktúra kezelhetetlen növekedéséhez az üzemeltetők számára.
Lehetővé teszi a fejlesztők számára, hogy valódi termékek létrehozására összpontosítsanak a felhasználók és ügyfelek számára. Nem kell átgázolnia a hardver- és szoftverbeállítások dzsungelében, és minden véletlen bonyodalma a múlté lesz.
OpenShift 4: NoOps platform, amely nem igényel karbantartást
В ismertette azokat a feladatokat, amelyek hozzájárultak a vállalat OpenShift 4-re vonatkozó víziójának kialakításához. A csapat célja, hogy a szoftver üzemeltetésével és karbantartásával kapcsolatos napi feladatokat a lehető legnagyobb mértékben leegyszerűsítsék, ezek a folyamatok könnyedebbé és könnyedebbé váljanak - mind a megvalósításban résztvevő szakemberek, mind a fejlesztők számára. De hogyan lehet közelebb kerülni ehhez a célhoz? Hogyan készítsünk minimális beavatkozást igénylő szoftver futtatására szolgáló platformot? Mit jelent ebben az összefüggésben a NoOps?
Ha megpróbálja elvonatkoztatni, akkor a fejlesztők számára a „szerver nélküli” vagy „NoOps” fogalmak olyan eszközöket és szolgáltatásokat jelentenek, amelyek lehetővé teszik az „működési” komponens elrejtését vagy a fejlesztő terhének minimalizálását.
- Ne rendszerekkel dolgozzon, hanem alkalmazási felületekkel (API-kkal).
- Ne fáradjon a szoftver bevezetésével – hagyja, hogy a szolgáltató végezze el helyette.
- Ne vágjon bele azonnal egy nagy keretrendszer létrehozásába – kezdje kis darabok írásával, amelyek „építőelemként” működnek, próbálja meg elérni, hogy ez a kód adatokkal és eseményekkel működjön, ne lemezekkel és adatbázisokkal.
A cél az eddigiekhez hasonlóan az iterációk felgyorsítása a szoftverfejlesztésben, lehetőséget adva jobb termékek létrehozására, és hogy a fejlesztőnek ne kelljen aggódnia azon rendszerek miatt, amelyeken a szoftvere fut. Egy tapasztalt fejlesztő tisztában van vele, hogy a felhasználókra való összpontosítás gyorsan megváltoztathatja a képet, ezért ne fektessen túl sok erőfeszítést a szoftver írásába, hacsak nem vagy teljesen biztos benne, hogy szükség van rá.
A karbantartási és üzemeltetési szakemberek számára a „NoOps” szó kissé ijesztően hangozhat. A terepi mérnökökkel való kommunikáció során azonban nyilvánvalóvá válik, hogy az általuk használt, a megbízhatóság és megbízhatóság biztosítását célzó minták és technikák (Site Reliability Engineering, SRE) sok hasonlóságot mutatnak a fent leírt mintákkal:
- Ne kezelje a rendszereket – automatizálja a kezelési folyamataikat.
- Ne implementáljon szoftvert – hozzon létre egy folyamatot a telepítéshez.
- Kerülje el az összes szolgáltatás egybecsomagolását, és ne hagyja, hogy az egyik meghibásodása a teljes rendszer meghibásodását okozza – automatizálási eszközök segítségével oszlassa szét őket a teljes infrastruktúrában, és kösse össze őket olyan módon, amely figyelhető és felügyelhető.
Az SRE-k tudják, hogy valami elromolhat, és fel kell találniuk és meg kell oldaniuk a problémát – ezért automatizálják a rutinmunkát, és előre beállítják a hibaköltségvetéseket, így készen állnak a prioritások felállítására és a döntések meghozatalára, ha probléma merül fel.
A Kubernetes az OpenShiftben két fő probléma megoldására készült: ahelyett, hogy a virtuális gépek vagy a terheléselosztó API-k megértését kényszerítené, magasabb rendű absztrakciókkal – telepítési folyamatokkal és szolgáltatásokkal – működik. A szoftverügynökök telepítése helyett konténereket futtathat, és ahelyett, hogy saját felügyeleti veremet írna, használja a platformon már elérhető eszközöket. Tehát az OpenShift 4 titkos szósza valójában nem titok – csupán az SRE alapelvek és a szerver nélküli koncepciók átvétele és azok logikus végkövetkeztetése a fejlesztők és az üzemeltetési mérnökök segítsége:
- Automatizálja és szabványosítsa az alkalmazások által használt infrastruktúrát
- Kapcsolja össze a telepítési és fejlesztési folyamatokat anélkül, hogy korlátozná magukat a fejlesztőket
- Annak biztosítása, hogy a XNUMX. szolgáltatás, funkció, alkalmazás vagy a teljes verem elindítása, auditálása és biztonságossá tétele ne legyen nehezebb, mint az elsőnél.
De mi a különbség az OpenShift 4 platform és elődei, valamint az ilyen problémák megoldásának „standard” megközelítése között? Mi hajtja a méretarányt a megvalósítási és üzemeltetési csapatoknál? Annak a ténynek köszönhetően, hogy a király ebben a helyzetben a fürt. Így,
- Gondoskodunk arról, hogy a klaszterek célja egyértelmű legyen (Kedves felhő, azért vettem fel ezt a klasztert, mert tudtam)
- Gépek és operációs rendszerek léteznek a klaszter kiszolgálására (Fenség)
- Kezelje a fürtből származó gazdagépek állapotát, minimalizálja újjáépítésüket (sodródásukat).
- A rendszer minden fontos eleméhez szükség van egy dajkára (mechanizmusra), amely felügyeli és kiküszöböli a problémákat
- A rendszer *minden* aspektusának vagy elemének meghibásodása és a kapcsolódó helyreállítási mechanizmusok az élet normális részét képezik
- A teljes infrastruktúrát API-n keresztül kell konfigurálni.
- Használja a Kuberneteset a Kubernetes futtatásához. (Igen, igen, ez nem elírás)
- A frissítések telepítésének egyszerűnek és problémamentesnek kell lennie. Ha egy frissítés telepítéséhez több kattintás szükséges, akkor nyilvánvalóan valamit rosszul csinálunk.
- A komponensek megfigyelése és hibakeresése nem jelenthet problémát, ezért a teljes infrastruktúra nyomon követésének és jelentésének is egyszerűnek és kényelmesnek kell lennie.
Szeretné látni a platform képességeit működés közben?
A fejlesztők számára elérhetővé vált az OpenShift 4 előzetes verziója. Egy könnyen használható telepítővel fürtöt futtathat AWS-en a Red Had CoreOS tetején. Az előnézet használatához csak egy AWS-fiókra van szüksége az infrastruktúra biztosításához, valamint egy fiókkészletre az előnézeti képek eléréséhez.
- A kezdéshez lépjen a következőre: és kattintson a „Kezdés” gombra.
- Jelentkezzen be Red Hat fiókjába (vagy hozzon létre egy újat), és kövesse az utasításokat az első fürt beállításához.
A sikeres telepítés után tekintse meg oktatóanyagainkat hogy mélyebben megértsük azokat a rendszereket és koncepciókat, amelyek az OpenShift 4 platformot a Kubernetes futtatásának egyszerű és kényelmes módjává teszik.
Próbálja ki az új OpenShift kiadást, és ossza meg véleményét. Elkötelezettek vagyunk amellett, hogy a Kumbernetes-szel való együttműködést a lehető legkönnyebben elérhetővé és legkönnyebbé tegyük – a NoOps jövője ma kezdődik.
És most figyelem!
A konferencián Április 20-án az OpenShift egyik fejlesztője, Vadim Rutkovsky mesterkurzust tart – tíz klasztert bont le, és kényszeríti őket a javításukra. A konferencia fizetős, de a #RedHat promóciós kóddal 37% kedvezményt kapsz
Mesterkurzus 17:15-18:15, a stand pedig egész nap nyitva tart. Pólók, sapkák, matricák – a szokásos!
2. terem
„Itt a teljes rendszert meg kell változtatni: a törött k8s-klasztereket minősített szerelőkkel együtt javítjuk.”
Forrás: will.com