Sziasztok! A nevem Pavel Agaletsky. Csapatvezetőként dolgozom a Lamoda kézbesítési rendszert fejlesztő csapatban. 2018-ban a HighLoad++ konferencián beszéltem, ma pedig a beszámolóm átiratát szeretném bemutatni.

A témám a vállalatunknak a rendszerek és szolgáltatások különböző környezetekben történő telepítése terén szerzett tapasztalataival foglalkozik. A történelem előtti időktől kezdve, amikor az összes rendszert közönséges virtuális szerverekbe telepítettük, a Nomadról a Kubernetesben történő telepítésre való fokozatos átállásig. Elmondom, miért csináltuk, és milyen problémák merültek fel a folyamat során.

Alkalmazások telepítése virtuális gépre

Kezdjük azzal, hogy 3 évvel ezelőtt a cég összes rendszere és szolgáltatása normál virtuális szerverekre került. Technikailag úgy volt megszervezve, hogy a rendszereinkhez tartozó összes kód tárolása és összeállítása automatikus összeszerelő eszközökkel, jenkinek segítségével történt. Az Ansible segítségével a verziókezelő rendszerünkből kikerült a virtuális szerverekre. Sőt, minden rendszer, amellyel cégünk rendelkezett, legalább 2 szerverre volt telepítve: az egyik a fejen, a másik a farokon. Ez a két rendszer teljesen azonos volt egymással minden beállításában, teljesítményében, konfigurációjában stb. Az egyetlen különbség köztük az volt, hogy a fej fogadott felhasználói forgalmat, míg a farok soha nem kapott felhasználói forgalmat.

Minek kellett?

Alkalmazásunk új kiadásainak bevezetésekor biztosítani akartuk a zökkenőmentes bevezetést, vagyis a felhasználók számára észrevehető következmények nélkül. Ez annak köszönhető, hogy a következő, Ansible-t használó kiadást a végére gördítették. Ott a telepítésben részt vevő személyek ellenőrizhették és megbizonyosodhattak arról, hogy minden rendben van: minden mérőszám, szakasz és alkalmazás működik; a szükséges szkriptek elindulnak. Csak miután meggyőződtek arról, hogy minden rendben, átkapcsolták a forgalmat. Elkezdett arra a szerverre menni, amelyik korábban farok volt. A korábban fejléc pedig felhasználói forgalom nélkül maradt, miközben még rajta volt az alkalmazásunk korábbi verziója.

Szóval zökkenőmentes volt a felhasználók számára. Mert a kapcsolás azonnali, hiszen egyszerűen a kiegyenlítő kapcsolása. A kiegyensúlyozó visszaállításával nagyon könnyen visszaléphet az előző verzióra. Azt is ellenőrizni tudtuk, hogy az alkalmazás élesre képes volt-e még azelőtt, hogy felhasználói forgalmat kapott volna, ami meglehetősen kényelmes volt.

Milyen előnyöket láttunk ebben az egészben?

1. Először is elég csak működik. Mindenki érti, hogyan működik egy ilyen telepítési séma, mert a legtöbb ember valaha is telepített szokásos virtuális szerverekre.
2. Ez elég megbízhatóan, mivel a telepítési technológia egyszerű, több ezer cég tesztelte. Szerverek millióit telepítik így. Nehéz eltörni valamit.
3. És végre megkaphattuk atomi bevetések. Telepítések, amelyek egyszerre történnek a felhasználók számára, anélkül, hogy a régi és az új verzió közötti váltás észrevehető szakasza lenne.

De mindebben több hiányosságot is láttunk:

1. A termelési környezeten, a fejlesztői környezeten kívül más környezetek is léteznek. Például a qa és az előtermelés. Akkoriban sok szerverünk és körülbelül 60 szolgáltatásunk volt. Emiatt volt erre szükség minden szolgáltatáshoz tartsa karban a legújabb verziót Virtuális gép. Sőt, ha könyvtárakat szeretne frissíteni vagy új függőségeket telepíteni, ezt minden környezetben meg kell tennie. Szinkronizálnia kellett az alkalmazás következő új verziójának üzembe helyezésének időpontját is azzal az időponttal, amikor a devops elvégzi a szükséges környezeti beállításokat. Ilyenkor könnyen kerülhetünk olyan helyzetbe, hogy a környezetünk valamennyi környezetben egyszerre lesz más. Például egy minőségbiztosítási környezetben lesznek a könyvtárak bizonyos verziói, éles környezetben pedig különbözőek, ami problémákhoz vezet.
2. Nehézségek a függőségek frissítése során a te alkalmazásod. Nem rajtad múlik, hanem a másik csapaton. Mégpedig a szervereket karbantartó devops csapattól. Megfelelő feladatot és leírást kell adnia nekik arról, hogy mit szeretne csinálni.
3. Akkoriban a nálunk lévő nagy nagy monolitokat is külön kis szolgáltatásokra szerettük volna felosztani, hiszen megértettük, hogy egyre több lesz. Ekkor már több mint 100 darab volt, minden új szolgáltatáshoz külön új virtuális gépet kellett létrehozni, amit szintén karbantartani és telepíteni kellett. Ráadásul nem egy autó kell, hanem legalább kettő. Mindehhez hozzáadódik a minőségbiztosítási környezet. Ez problémákat okoz, és megnehezíti az új rendszerek felépítését és futtatását. bonyolult, költséges és hosszadalmas folyamat.

Ezért úgy döntöttünk, hogy kényelmesebb lenne a szokásos virtuális gépek telepítéséről áttérni az alkalmazásaink docker-tárolóban történő üzembe helyezésére. Ha rendelkezik dokkolóval, akkor olyan rendszerre van szüksége, amely fürtben tudja futtatni az alkalmazást, mivel nem lehet csak úgy felemelni egy tárolót. Általában azt szeretné nyomon követni, hogy hány konténert emeltek fel, hogy azok automatikusan emelkedjenek. Emiatt egy vezérlőrendszert kellett kiválasztanunk.

Sokáig gondolkodtunk, hogy melyiket vegyük. A tény az, hogy abban az időben ez a telepítési verem a szokásos virtuális szervereken kissé elavult volt, mivel nem rendelkeztek az operációs rendszerek legújabb verziójával. Valamikor még a FreeBSD is megjelent, aminek támogatása nem volt túl kényelmes. Megértettük, hogy a lehető leggyorsabban át kell térnünk a dockerre. Devopjaink megvizsgálták a meglévő tapasztalataikat különböző megoldásokkal, és egy olyan rendszert választottak, mint a Nomad.

Váltson Nomadra

A Nomad a HashiCorp terméke. Más megoldásaikról is ismertek:

"Konzul" a szolgáltatás felfedezésének eszköze.

"Teraform" - a szerverek kezelésére szolgáló rendszer, amely lehetővé teszi azok konfigurálását, az úgynevezett infrastruktúra kódként.

"Csavargó" lehetővé teszi a virtuális gépek helyi vagy felhőben történő üzembe helyezését meghatározott konfigurációs fájlok segítségével.

A Nomad akkoriban meglehetősen egyszerű megoldásnak tűnt, amelyre a teljes infrastruktúra megváltoztatása nélkül gyorsan át lehetett váltani. Ráadásul elég könnyű megtanulni. Ezért választottuk konténerünk szűrőrendszerének.

Mi kell ahhoz, hogy Nomadra telepítse a rendszerét?

1. Először is szüksége van docker kép a te alkalmazásod. Meg kell építeni, és el kell helyezni a docker képtárba. Esetünkben ez egy műalkotás - egy olyan rendszer, amely lehetővé teszi, hogy különböző típusú tárgyakat toljon bele. Tárolhat archívumokat, docker-képeket, szerzői PHP-csomagokat, NPM-csomagokat stb.
2. Szintén szükséges konfigurációs fájl, amely megmondja a Nomadnak, hogy mit, hol és milyen mennyiségben szeretne telepíteni.

Amikor a Nomadról beszélünk, a HCL nyelvet használja információs fájlformátumként, ami a következőt jelenti HashiCorp konfigurációs nyelv. Ez a Yaml szuperkészlete, amely lehetővé teszi szolgáltatásának nomád kifejezésekkel történő leírását.

Lehetővé teszi, hogy megmondja, hány tárolót szeretne telepíteni, és mely képekről kell átadni nekik a különféle paramétereket a telepítés során. Így ezt a fájlt betáplálod a Nomad-nak, és ennek megfelelően elindítja a konténereket a termelésbe.

Esetünkben rájöttünk, hogy pusztán teljesen azonos HCL fájlokat írni az egyes szolgáltatásokhoz nem lenne túl kényelmes, mert nagyon sok szolgáltatás létezik, és néha frissíteni szeretné őket. Előfordul, hogy egy szolgáltatást nem egy példányban telepítenek, hanem több különböző példányban. Például az egyik éles rendszerünk több mint 100 példányt tartalmaz. Ugyanabból a képből futnak, de konfigurációs beállításokban és konfigurációs fájlokban különböznek.

Ezért úgy döntöttünk, hogy kényelmesebb lenne, ha az összes konfigurációs fájlunkat egyetlen közös tárolóban tárolnánk a telepítéshez. Így láthatóak voltak: könnyen karbantarthatók, és láthattuk, milyen rendszereink vannak. Ha szükséges, akkor is könnyen frissíthető vagy módosítható valami. Új rendszer hozzáadása szintén nem nehéz - csak létre kell hoznia egy konfigurációs fájlt az új könyvtárban. Belül a következő fájlok találhatók: service.hcl, amely a szolgáltatásunk leírását tartalmazza, és néhány env fájl, amelyek lehetővé teszik ennek a szolgáltatásnak a konfigurálását az éles környezetben.

Egyes rendszereinket azonban nem egy példányban, hanem egyszerre többben is üzembe helyezzük. Ezért úgy döntöttünk, hogy az lenne a kényelmes, ha nem tiszta formában tárolnánk a konfigurációkat, hanem sablonos formában. És mi választottunk dzsindzsa 2. Ebben a formátumban magának a szolgáltatásnak a konfigurációit és a hozzá szükséges env fájlokat is tároljuk.

Ezenkívül a repositoryban elhelyeztünk egy minden projektben közös telepítési szkriptet, amely lehetővé teszi a szolgáltatás elindítását és üzembe helyezését éles környezetben, a kívánt környezetben, a kívánt célpontban. Abban az esetben, ha a HCL konfigurációnkat sablonná alakítottuk, akkor a HCL fájl, amely korábban egy normál Nomad konfiguráció volt, ebben az esetben kicsit másképp nézett ki.

Vagyis néhány konfigurációs helyváltozót lecseréltünk beszúrt változókra, amelyek env fájlokból vagy más forrásokból származnak. Emellett lehetőséget kaptunk a HCL fájlok dinamikus gyűjtésére, vagyis nem csak hétköznapi változó beillesztéseket használhatunk. Mivel a Jinja támogatja a ciklusokat és feltételeket, ott konfigurációs fájlokat is létrehozhat, amelyek attól függően változnak, hogy pontosan hol helyezi üzembe az alkalmazásokat.

Például szeretné telepíteni a szolgáltatást az előgyártásra és a termelésre. Tegyük fel, hogy az előgyártásban nem akarsz cron szkripteket futtatni, hanem csak egy külön tartományban szeretnéd látni a szolgáltatást, hogy megbizonyosodj arról, hogy működik. Mindenki számára, aki telepíti a szolgáltatást, a folyamat nagyon egyszerűnek és átláthatónak tűnik. Mindössze annyit kell tennie, hogy futtassa a deploy.sh fájlt, adja meg, melyik szolgáltatást és melyik célpontra kívánja telepíteni. Például egy bizonyos rendszert szeretne telepíteni Oroszországba, Fehéroroszországba vagy Kazahsztánba. Ehhez egyszerűen módosítsa az egyik paramétert, és megkapja a megfelelő konfigurációs fájlt.

Ha a Nomad szolgáltatás már telepítve van a fürtben, ez így néz ki.

Először is kell valamiféle kiegyensúlyozó kívül, ami fogadja az összes felhasználói forgalmat. Együtt fog működni a Consullal, és kideríti belőle, hogy hol, milyen csomóponton, milyen IP-címen található egy adott szolgáltatás, amely egy adott domain névnek felel meg. A Consul szolgáltatásai magától a Nomadtól származnak. Mivel ezek ugyanannak a cégnek a termékei, meglehetősen rokonságban állnak egymással. Elmondhatjuk, hogy a Nomad out of the box minden benne elindított szolgáltatást regisztrálhat a Consulon belül.

Miután a front-end terheléselosztó tudja, hogy melyik szolgáltatáshoz kell forgalmat küldenie, továbbítja azt az alkalmazásának megfelelő tárolóba vagy több tárolóba. Természetesen a biztonságra is gondolni kell. Annak ellenére, hogy minden szolgáltatás ugyanazon a virtuális gépen fut konténerekben, ehhez általában meg kell akadályozni, hogy bármely szolgáltatás szabadon hozzáférjen bármely másikhoz. Ezt szegmentálással értük el. Mindegyik szolgáltatás a saját virtuális hálózatában indult, amelyen útválasztási szabályokat, valamint más rendszerekhez és szolgáltatásokhoz való hozzáférés engedélyezésére/megtiltására vonatkozó szabályokat írtak elő. Elhelyezkedhetnek ezen a klaszteren belül és azon kívül is. Például, ha meg szeretné akadályozni, hogy egy szolgáltatás kapcsolódjon egy adott adatbázishoz, ezt hálózati szintű szegmentálással megteheti. Ez azt jelenti, hogy még véletlenül sem tud véletlenül csatlakozni a tesztkörnyezetből az éles adatbázishoz.

Mennyibe került nekünk az átállás emberi erőforrás tekintetében?

A teljes cég átállása a Nomadra körülbelül 5-6 hónapot vett igénybe. Szolgáltatásonként haladtunk, de elég gyors ütemben. Minden csapatnak saját konténereket kellett létrehoznia a szolgáltatásokhoz.

Olyan megközelítést alkalmaztunk, hogy minden csapat önállóan felelős a rendszereik docker-képeiért. A DevOps biztosítja a telepítéshez szükséges általános infrastruktúrát, azaz magának a fürtnek a támogatását, a CI-rendszer támogatását stb. És akkoriban több mint 60 rendszert költöztettek át a Nomadba, ami körülbelül 2 ezer konténert jelentett.

A Devops felelős minden, a telepítéssel és a szerverekkel kapcsolatos általános infrastruktúráért. Minden fejlesztőcsapat pedig felelős a saját rendszeréhez tartozó konténerek megvalósításáért, mivel ez a csapat tudja, hogy általában mire van szüksége egy adott konténerben.

A Nomad elhagyásának okai

Milyen előnyökhöz jutottunk többek között a Nomad és a docker használatával történő telepítésre váltással?

1. Mi egyenlő feltételeket biztosított minden környezethez. A fejlesztésben, minőségbiztosítási környezetben, előgyártásban, gyártásban ugyanazokat a konténerképeket használják, azonos függőségekkel. Ennek megfelelően gyakorlatilag nincs esélye arra, hogy az élesben ne az legyen, amit korábban helyileg vagy a tesztkörnyezetében tesztelt.
2. Azt is tapasztaltuk, hogy elég könnyű új szolgáltatást hozzáadni. Telepítési szempontból minden új rendszert nagyon egyszerűen indítanak el. Csak lépjen a konfigurációkat tároló tárolóba, adjon hozzá egy másik konfigurációt a rendszeréhez, és már kész is. A fejlesztők további erőfeszítése nélkül üzembe helyezheti rendszerét éles környezetben.
3. minden konfigurációs fájlok egy közös adattárban kiderült, hogy felülvizsgálat alatt áll. Amikor rendszereinket virtuális szerverekkel telepítettük, az Ansible-t használtuk, amelyben a konfigurációk ugyanabban a tárolóban voltak. A legtöbb fejlesztő számára azonban ez egy kicsit nehezebb volt. Itt a szolgáltatás üzembe helyezéséhez hozzáadandó konfigurációk és kódok mennyisége sokkal kisebb lett. Ráadásul a devops nagyon könnyen megjavíthatja vagy megváltoztathatja. Például a Nomad új verziójára való áttérés esetén tömegesen frissíthetik az ugyanazon a helyen található összes működő fájlt.

De több hátránnyal is találkoztunk:

Kiderült, hogy mi nem tudtak zökkenőmentes telepítést elérni Nomád esetében. A konténerek különböző körülmények között történő kigörgetésekor kiderülhet, hogy fut, és a Nomad úgy fogta fel, mint egy konténer, amely készen áll a forgalom fogadására. Ez még azelőtt történt, hogy a benne lévő alkalmazásnak esélye lett volna elindulni. Emiatt a rendszer rövid időre 500 hibát kezdett produkálni, mert a forgalom egy olyan konténer felé kezdett haladni, amely még nem volt kész a fogadására.

Találkoztunk néhány a lápok mellett. A legjelentősebb hiba az, hogy a Nomad nem kezeli túl jól a nagy klasztereket, ha sok rendszerrel és konténerrel rendelkezik. Ha a Nomad fürtben lévő egyik kiszolgálót ki akarja venni karbantartás céljából, meglehetősen nagy a valószínűsége annak, hogy a fürt nem érzi jól magát, és szétesik. Egyes konténerek például leeshetnek, és nem emelkedhetnek fel – ez később nagyon sokba fog kerülni, ha minden termelési rendszere a Nomad által kezelt klaszterben található.

Ezért úgy döntöttünk, hogy átgondoljuk, merre induljunk tovább. Ekkor már sokkal jobban tudatában voltunk annak, hogy mit is szeretnénk elérni. Mégpedig: megbízhatóságot akarunk, kicsit több funkciót, mint amennyit a Nomad biztosít, és egy kiforrottabb, stabilabb rendszert.

E tekintetben a Kubernetesre esett a választásunk, mint a klaszterek indításának legnépszerűbb platformjára. Főleg, hogy a konténereink mérete és száma elég nagy volt. Ilyen célokra a Kubernetes tűnt a legalkalmasabb rendszernek, amelyet megvizsgálhatunk.

Áttérés a Kubernetesre

Mesélek egy kicsit a Kubernetes alapfogalmairól és arról, hogy miben különböznek a Nomadtól.

Először is, a Kubernetes legalapvetőbb fogalma a pod fogalma. Hüvely egy vagy több konténerből álló csoport, amelyek mindig együtt futnak. És mindig úgy működnek, mintha szigorúan egy virtuális gépen lennének. Különböző portokon IP 127.0.0.1-en keresztül érhetők el egymás számára.

Tegyük fel, hogy van egy PHP-alkalmazása, amely nginx-ből és php-fpm-ből áll – a klasszikus séma. Valószínűleg az nginx és a php-fpm konténereket mindig együtt kell tartani. A Kubernetes ezt úgy érheti el, hogy egyetlen közös podként írja le őket. Pontosan ez az, amit a Nomaddal nem tudtunk elérni.

A második koncepció az bevetés. A helyzet az, hogy maga a hüvely egy mulandó dolog, elindul és eltűnik. Először az összes korábbi konténeredet szeretnéd megölni, majd egyszerre elindítani az új verziókat, vagy fokozatosan szeretnéd kivezetni őket?Ez az a folyamat, amiért a telepítés koncepciója felelős. Leírja, hogyan telepítheti a podokat, milyen mennyiségben és hogyan frissítheti őket.

A harmadik fogalom az szolgáltatás. Az Ön szolgáltatása valójában az Ön rendszere, amely fogad némi forgalmat, majd továbbítja azt a szolgáltatásának megfelelő egy vagy több podba. Vagyis lehetővé teszi, hogy azt mondjuk, hogy az ilyen és ehhez hasonló szolgáltatásokhoz ilyen és ilyen névvel érkező összes bejövő forgalmat ezekre a konkrét podokra kell küldeni. Ugyanakkor biztosítja a forgalom kiegyensúlyozását. Ez azt jelenti, hogy elindíthatja az alkalmazás két podját, és az összes bejövő forgalom egyenletesen lesz kiegyensúlyozva a szolgáltatáshoz kapcsolódó podok között.

A negyedik alapkoncepció pedig az Bemenetel. Ez egy Kubernetes-fürtön futó szolgáltatás. Külső terheléselosztóként működik, amely átveszi az összes kérést. A Kubernetes API segítségével az Ingress meghatározhatja, hogy hová kell küldeni ezeket a kéréseket. Ráadásul ezt nagyon rugalmasan teszi. Elmondhatja, hogy az ehhez a gazdagéphez intézett összes kérés és az ilyen és ehhez hasonló URL-címek erre a szolgáltatásra kerülnek. És ezek a kérések, amelyek ehhez a gazdagéphez és egy másik URL-hez érkeznek, egy másik szolgáltatáshoz kerülnek elküldésre.

A legmenőbb dolog abból a szempontból, hogy valaki, aki alkalmazást fejleszt, az az, hogy mindezt maga tudja kezelni. Az Ingress config beállításával az ilyen és ehhez hasonló API-ra érkező összes forgalmat külön konténerekbe küldheti, például Go-ban írva. De ezt a forgalmat, amely ugyanarra a domainre érkezik, de más URL-re, PHP-ben írt konténerekbe kell küldeni, ahol sok a logika, de nem túl gyorsak.

Ha ezeket a fogalmakat a Nomaddal összehasonlítjuk, akkor azt mondhatjuk, hogy az első három fogalom együtt szolgáltatás. Az utolsó fogalom pedig magában a Nomadban hiányzik. Külső egyensúlyozót használtunk: lehet haproxy, nginx, nginx+ stb. Kocka esetén ezt a kiegészítő fogalmat nem kell külön bemutatni. Ha azonban belülről nézzük az Ingress-t, akkor az vagy nginx, haproxy vagy traefik, de valahogy a Kubernetesbe van beépítve.

Az általam leírt összes fogalom valójában egy Kubernetes-fürtön belüli erőforrás. Ezek leírására a kockában egy yaml formátumot használnak, amely a Nomad esetében jobban olvasható és ismerősebb, mint a HCL fájlok. De szerkezetileg ugyanazt írják le például a hüvely esetében. Azt mondják - ilyen-olyan hüvelyeket szeretnék ott telepíteni, ilyen-olyan képekkel, ilyen-olyan mennyiségben.

Ezen kívül rájöttünk, hogy nem akarunk minden egyes erőforrást kézzel létrehozni: telepítés, szolgáltatások, Ingress stb. Ehelyett minden rendszerünket Kubernetes-rendszerrel szerettük volna leírni a telepítés során, hogy ne kelljen manuálisan újra létrehoznunk az összes szükséges erőforrás-függőséget a megfelelő sorrendben. A Helmet választották rendszerként, amely lehetővé tette számunkra ezt.

Alapfogalmak Helmben

Helm az csomagkezelő Kubernetes számára. Nagyon hasonlít a programozási nyelvek csomagkezelőinek működéséhez. Lehetővé teszik például a telepítési nginx, telepítési php-fpm, Config for Ingress, configmaps (ez egy entitás, amely lehetővé teszi az env és egyéb paraméterek beállítását a rendszer számára) tárolását ilyen formában. diagramoknak nevezzük. Ugyanakkor Helm a Kubernetes tetején fut. Vagyis ez nem valamiféle félreállt rendszer, hanem csak egy újabb, a kocka belsejében elindított szolgáltatás. Az API-ján keresztül egy konzolparancs segítségével léphet kapcsolatba vele. Kényelme és szépsége abban rejlik, hogy hiába törik el a kormányrudat, vagy eltávolítod a klaszterből, szolgáltatásaid nem tűnnek el, hiszen a sisak lényegében csak a rendszer indítását szolgálja. Ezután maga a Kubernetes felelős a szolgáltatások teljesítményéért és állapotáért.

Arra is rájöttünk sablonozás, amit korábban magunk is kénytelenek voltunk megtenni a konfigjainkba dzsindzsa bevezetésével, a helm egyik fő jellemzője. A rendszerekhez létrehozott összes konfigurációt a helmben tárolja sablonok formájában, kissé hasonló a jinja-hoz, de valójában a Go nyelv sablonjait használja, amelyen a helm van írva, mint például a Kubernetes.

Helm még néhány fogalmat ad nekünk.

Táblázatos - ez a szolgáltatás leírása. Más csomagkezelőkben ezt csomagnak, kötegnek vagy valami hasonlónak nevezik. Itt diagramnak hívják.

Értékek ezek azok a változók, amelyeket a konfigurációk sablonokból való összeállításához használni szeretne.

Engedje. Minden alkalommal, amikor egy helm segítségével telepített szolgáltatás megkapja a kiadás növekményes verzióját. Helm emlékszik, hogy mi volt a szolgáltatás konfigurációja az előző kiadásban, az azt megelőző kiadásban stb. Ezért, ha vissza kell állítania, futtassa a helm callback parancsot, és az előző kiadási verzióra irányítja. Még ha a megfelelő konfiguráció a lerakatban nem is elérhető a visszaállítás időpontjában, a helm akkor is emlékezni fog, hogy mi volt, és visszaállítja a rendszert az előző kiadás állapotába.

Helm használata esetén a Kubernetes szokásos konfigurációi is sablonokká alakulnak, amelyekben lehetőség van változók, függvények használatára és feltételes utasítások alkalmazására. Így a környezettől függően összegyűjtheti a szolgáltatás konfigurációját.

A gyakorlatban úgy döntöttünk, hogy egy kicsit másképp csináljuk a dolgokat, mint a Nomaddal. Ha a Nomadban mind az üzembe helyezési konfigurációk, mind a szolgáltatásunk üzembe helyezéséhez szükséges n-változók egy lerakatban voltak tárolva, akkor itt úgy döntöttünk, hogy két külön tárolóra osztjuk őket. A „telepítési” lerakat csak a telepítéshez szükséges n-változókat tárolja, a „helm” lerakat pedig konfigurációkat vagy diagramokat tárol.

Mit adott ez nekünk?

Annak ellenére, hogy magukban a konfigurációs fájlokban nem tárolunk igazán érzékeny adatokat. Például jelszavak adatbázisokhoz. A Kubernetes titokként tárolja őket, de ennek ellenére vannak még ott bizonyos dolgok, amelyekhez nem szeretnénk mindenkinek hozzáférést adni. Ezért a „telepítési” tárhoz való hozzáférés korlátozottabb, és a „helm” tároló egyszerűen tartalmazza a szolgáltatás leírását. Emiatt az emberek szélesebb köre biztonságosan megközelíthető.

Mivel nem csak termelési, hanem más környezetekkel is rendelkezünk, ennek az elválasztásnak köszönhetően újra felhasználhatjuk vezérlődiagramjainkat, hogy a szolgáltatásokat nem csak a termelésben, hanem például a minőségbiztosítási környezetben is telepítsük. Még arra is, hogy helyileg telepítse őket Minikube - ez a Kubernetes helyi futtatásához szükséges.

Az egyes tárolókon belül minden szolgáltatáshoz külön könyvtárakat hagytunk fel. Ez azt jelenti, hogy minden könyvtárban találhatók a megfelelő diagramhoz kapcsolódó sablonok, amelyek leírják a rendszerünk elindításához telepítendő erőforrásokat. Csak az env-eket hagytuk meg a „telepítési” tárolóban. Ebben az esetben nem használtunk jinja-t használó sablonozást, mert a helm maga biztosítja a sablonozást a dobozból - ez az egyik fő funkciója.

Meghagytunk egy telepítési szkriptet - deploy.sh, amely leegyszerűsíti és szabványosítja az indítást a helm segítségével történő telepítéshez. Tehát bárki számára, aki telepíteni akar, a telepítési felület pontosan ugyanúgy néz ki, mint a Nomadon keresztüli telepítéskor. Ugyanaz a deploy.sh, a szolgáltatás neve és a telepítés helye. Emiatt a kormány belsőleg beindul. Ez viszont összegyűjti a konfigurációkat a sablonokból, beilleszti a szükséges értékfájlokat, majd telepíti őket, és elindítja a Kubernetesbe.

Álláspontja

A Kubernetes szolgáltatás összetettebbnek tűnik, mint a Nomad.

Itt a kimenő forgalom az Ingress felé érkezik. Ez csak az elülső vezérlő, amely átveszi az összes kérést, majd elküldi azokat a kérésadatoknak megfelelő szolgáltatásoknak. Azon konfigurációk alapján határozza meg őket, amelyek az alkalmazás leírásának részét képezik a kormányban, és amelyeket a fejlesztők maguk állítanak be. A szolgáltatás kéréseket küld a pod-jaihoz, azaz meghatározott konténerekhez, kiegyenlítve a bejövő forgalmat a szolgáltatáshoz tartozó összes konténer között. És persze nem szabad megfeledkeznünk arról sem, hogy a hálózati szintű biztonságtól sehova sem szabad mennünk. Ezért a szegmentálás egy Kubernetes-fürtben működik, amely címkézésen alapul. Minden szolgáltatás rendelkezik bizonyos címkékkel, amelyekhez a szolgáltatások hozzáférési jogai vannak társítva bizonyos külső/belső erőforrásokhoz a fürtön belül vagy kívül.

Az átállás során láttuk, hogy a Kubernetes rendelkezik a Nomad összes képességével, amit korábban is használtunk, és sok újdonsággal is bővült. Bővíthető beépülő modulokkal, sőt egyéni erőforrástípusokkal. Vagyis lehetősége van arra, hogy ne csak a Kuberneteshez tartozó dolgokat használja, hanem saját erőforrást és szolgáltatást is létrehozhat, amely olvassa az erőforrást. Ez további lehetőségeket kínál a rendszer bővítésére a Kubernetes újratelepítése és módosítások nélkül.

Az ilyen felhasználásra példa a Prometheus, amely a Kubernetes-fürtünkön belül fut. Ahhoz, hogy egy adott szolgáltatásból mérőszámokat kezdjen gyűjteni, egy további típusú erőforrást, az úgynevezett szolgáltatásfigyelőt kell hozzáadnunk a szolgáltatás leírásához. A Prometheus, mivel képes beolvasni az egyéni erőforrástípusokat a Kubernetesben, automatikusan elkezdi gyűjteni a mérőszámokat az új rendszerből. Elég kényelmes.

Az első üzembe helyezést a Kubernetesben 2018 márciusában hajtottuk végre. És ezalatt soha nem tapasztaltunk vele semmilyen problémát. Meglehetősen stabilan működik, jelentős hibák nélkül. Ráadásul tovább bővíthetjük. Ma már elegünk van a benne rejlő képességekből, és nagyon szeretjük a Kubernetes fejlődési ütemét. Jelenleg több mint 3000 konténer található Kubernetesben. A fürt több csomópontot foglal el. Ugyanakkor szervizelhető, stabil és nagyon jól irányítható.

Forrás: will.com