Ahojte všetci! Volám sa Pavel Agaletsky. Pracujem ako vedúci tímu v tíme, ktorý vyvíja doručovací systém Lamoda. V roku 2018 som vystúpil na konferencii HighLoad++ a dnes by som rád predstavil prepis mojej správy.

Moja téma je venovaná skúsenostiam našej spoločnosti s nasadzovaním systémov a služieb do rôznych prostredí. Počnúc našim pravekom, keď sme všetky systémy nasadzovali do bežných virtuálnych serverov, končiac postupným prechodom od Nomad k nasadeniu v Kubernetes. Poviem vám, prečo sme to urobili a aké problémy sme pri tom mali.

Nasadenie aplikácií do VM

Začnime tým, že pred 3 rokmi boli všetky systémy a služby spoločnosti nasadené na bežné virtuálne servery. Technicky to bolo zorganizované tak, že všetok kód pre naše systémy bol uložený a zostavený pomocou automatických montážnych nástrojov, pomocou jenkinov. Pomocou Ansible bol rozšírený z nášho systému správy verzií na virtuálne servery. Navyše každý systém, ktorý naša spoločnosť mala, bol nasadený minimálne na 2 servery: jeden na čele, druhý na chvoste. Tieto dva systémy boli navzájom absolútne identické vo všetkých nastaveniach, výkone, konfigurácii atď. Jediný rozdiel medzi nimi bol, že head prijímal užívateľskú návštevnosť, zatiaľ čo tail nikdy užívateľskú návštevnosť.

Prečo sa to urobilo?

Keď sme nasadzovali nové vydania našej aplikácie, chceli sme zabezpečiť bezproblémové zavádzanie, teda bez viditeľných následkov pre používateľov. Dosiahlo sa to vďaka skutočnosti, že ďalšie skompilované vydanie s použitím Ansible bolo spustené až na koniec. Tam mohli ľudia, ktorí sa podieľali na nasadení, skontrolovať a uistiť sa, že je všetko v poriadku: všetky metriky, sekcie a aplikácie fungujú; spustia sa potrebné skripty. Až potom, čo sa presvedčili, že je všetko v poriadku, premávka bola zmenená. Začalo to ísť na server, ktorý bol predtým chvostom. A ten, ktorý bol predtým hlavou, zostal bez návštevnosti používateľov, pričom na ňom bola stále predchádzajúca verzia našej aplikácie.

Takže to bolo pre používateľov bezproblémové. Pretože spínanie je okamžité, keďže ide len o spínanie balancéra. K predchádzajúcej verzii sa môžete veľmi jednoducho vrátiť jednoduchým prepnutím balancéra späť. Mohli sme si tiež overiť, že aplikácia bola schopná produkcie ešte predtým, ako dostala užívateľskú návštevnosť, čo bolo celkom pohodlné.

Aké výhody sme v tom všetkom videli?

1. V prvom rade stačí proste to funguje. Každý chápe, ako takáto schéma nasadenia funguje, pretože väčšina ľudí ju niekedy nasadila na bežné virtuálne servery.
2. To stačí spoľahlivo, keďže technológia nasadenia je jednoduchá, testovaná tisíckami spoločností. Takto sú nasadené milióny serverov. Je ťažké niečo rozbiť.
3. A konečne sme sa mohli dostať atómové nasadenie. Nasadenia, ktoré sa pre používateľov vyskytujú súčasne, bez znateľného štádia prepínania medzi starou verziou a novou verziou.

V tom všetkom sme však videli aj niekoľko nedostatkov:

1. Okrem produkčného prostredia, vývojového prostredia, existujú aj iné prostredia. Napríklad qa a predprodukcia. V tom čase sme mali veľa serverov a asi 60 služieb. Z tohto dôvodu to bolo nevyhnutné pre každú službu udržiavajte jej najnovšiu verziu virtuálny prístroj. Navyše, ak chcete aktualizovať knižnice alebo nainštalovať nové závislosti, musíte to urobiť vo všetkých prostrediach. Potrebovali ste tiež synchronizovať čas, kedy sa chystáte nasadiť ďalšiu novú verziu vašej aplikácie, s časom, keď devops vykoná potrebné nastavenia prostredia. V tomto prípade je ľahké dostať sa do situácie, kedy naše prostredie bude vo všetkých prostrediach naraz v niečom iné. Napríklad v prostredí QA budú existovať niektoré verzie knižníc a v produkčnom prostredí budú iné, čo povedie k problémom.
2. Ťažkosti s aktualizáciou závislostí vašej žiadosti. Závisí to nie od vás, ale od druhého tímu. Konkrétne od tímu devops, ktorý spravuje servery. Musíte im dať vhodnú úlohu a popis toho, čo chcete robiť.
3. Vtedy sme aj veľké veľké monolity, ktoré sme mali, chceli rozdeliť na samostatné malé služby, keďže sme chápali, že ich bude stále viac. V tom čase sme ich mali už viac ako 100. Pre každú novú službu bolo potrebné vytvoriť samostatný nový virtuálny stroj, ktorý bolo potrebné aj udržiavať a nasadzovať. Navyše nepotrebujete jedno auto, ale aspoň dve. K tomu všetkému sa pridáva prostredie QA. To spôsobuje problémy a sťažuje vám vytváranie a spúšťanie nových systémov. zložitý, drahý a zdĺhavý proces.

Preto sme sa rozhodli, že bude pohodlnejšie prejsť od nasadzovania bežných virtuálnych strojov k nasadzovaniu našich aplikácií v docker kontajneri. Ak máte docker, potrebujete systém, ktorý dokáže spustiť aplikáciu v klastri, pretože nemôžete len vyvolať kontajner. Zvyčajne chcete mať prehľad o tom, koľko kontajnerov sa zdvihne, aby sa zdvihli automaticky. Z tohto dôvodu sme potrebovali zvoliť riadiaci systém.

Dlho sme rozmýšľali, ktorý by sme si mohli vziať. Faktom je, že v tom čase bol tento zásobník nasadenia na bežných virtuálnych serveroch trochu zastaraný, pretože nemali najnovšie verzie operačných systémov. V určitom okamihu dokonca existovalo FreeBSD, ktorého podpora nebola príliš vhodná. Pochopili sme, že musíme čo najrýchlejšie migrovať na docker. Naši vývojári sa pozreli na svoje existujúce skúsenosti s rôznymi riešeniami a vybrali si systém ako Nomad.

Prepnúť na Nomad

Nomad je produktom spoločnosti HashiCorp. Sú tiež známe svojimi ďalšími riešeniami:

"konzul" je nástroj na vyhľadávanie služieb.

"Teraform" - systém na správu serverov, ktorý vám umožňuje konfigurovať ich prostredníctvom konfigurácie, takzvanej infraštruktúry ako kódu.

"tulák" umožňuje nasadiť virtuálne stroje lokálne alebo v cloude prostredníctvom špecifických konfiguračných súborov.

Nomad sa v tom čase javil ako celkom jednoduché riešenie, na ktoré sa dalo rýchlo prejsť bez zmeny celej infraštruktúry. Navyše sa dá celkom ľahko naučiť. Preto sme ho zvolili ako filtračný systém pre našu nádobu.

Čo potrebujete na nasadenie vášho systému na Nomad?

1. V prvom rade potrebujete obrázok dockeru vašej žiadosti. Musíte ho postaviť a umiestniť do úložiska obrázkov docker. V našom prípade ide o artifactory – systém, ktorý vám umožňuje natlačiť do nej rôzne artefakty rôzneho typu. Môže ukladať archívy, obrázky dockerov, skladateľské balíky PHP, balíky NPM atď.
2. Tiež sa vyžaduje konfiguračný súbor, ktorý Nomadovi povie, čo, kde a v akom množstve chcete nasadiť.

Keď hovoríme o Nomad, používa jazyk HCL ako formát informačného súboru, čo znamená Konfiguračný jazyk HashiCorp. Toto je nadmnožina Yaml, ktorá vám umožňuje opísať vašu službu v podmienkach Nomad.

Umožňuje vám povedať, koľko kontajnerov chcete nasadiť, z ktorých obrázkov im počas nasadenia odovzdať rôzne parametre. Tento súbor teda podáte Nomadovi a ten podľa neho spustí kontajnery do výroby.

V našom prípade sme si uvedomili, že jednoduché písanie absolútne identických súborov HCL pre každú službu by nebolo veľmi pohodlné, pretože služieb je veľa a niekedy ich chcete aktualizovať. Stáva sa, že jedna služba nie je nasadená v jednej inštancii, ale v mnohých rôznych. Napríklad jeden zo systémov, ktoré máme vo výrobe, má vo výrobe viac ako 100 inštancií. Spúšťajú sa z rovnakých obrazov, líšia sa však konfiguračnými nastaveniami a konfiguračnými súbormi.

Preto sme sa rozhodli, že bude pre nás výhodné uložiť všetky naše konfiguračné súbory na nasadenie do jedného spoločného úložiska. Takto boli viditeľné: ľahko sa udržiavali a videli sme, aké systémy máme. V prípade potreby je tiež jednoduché niečo aktualizovať alebo zmeniť. Pridanie nového systému tiež nie je ťažké - stačí vytvoriť konfiguračný súbor v novom adresári. Vo vnútri sú nasledujúce súbory: service.hcl, ktorý obsahuje popis našej služby a niektoré env súbory, ktoré umožňujú konfiguráciu práve tejto služby, ktorá je nasadená v produkcii.

Niektoré naše systémy sú však vo výrobe nasadené nie v jednej kópii, ale vo viacerých naraz. Preto sme sa rozhodli, že pre nás bude vhodné neukladať konfigurácie v ich čistej forme, ale ich šablónovú formu. A vybrali sme si jinja 2. V tomto formáte ukladáme ako konfigurácie samotnej služby, tak aj env súbory potrebné pre ňu.

Okrem toho sme do úložiska umiestnili skript nasadenia spoločný pre všetky projekty, ktorý umožňuje spustiť a nasadiť vašu službu do produkcie, do požadovaného prostredia, do požadovaného cieľa. V prípade, keď sme zmenili našu konfiguráciu HCL na šablónu, potom súbor HCL, ktorý bol predtým bežným konfiguráciou Nomad, v tomto prípade začal vyzerať trochu inak.

To znamená, že sme nahradili niektoré premenné umiestnenia konfigurácie vloženými premennými, ktoré sú prevzaté zo súborov env alebo iných zdrojov. Okrem toho sme dostali možnosť dynamicky zbierať HCL súbory, to znamená, že môžeme použiť nielen bežné vkladanie premenných. Keďže jinja podporuje slučky a podmienky, môžete tam vytvárať aj konfiguračné súbory, ktoré sa menia v závislosti od toho, kde presne nasadíte svoje aplikácie.

Napríklad chcete nasadiť svoju službu do predprodukcie a produkcie. Povedzme, že v predprodukcii nechcete spúšťať cron skripty, ale len chcete vidieť službu na samostatnej doméne, aby ste sa uistili, že funguje. Pre každého, kto službu nasadí, vyzerá proces veľmi jednoducho a transparentne. Všetko, čo musíte urobiť, je spustiť súbor deploy.sh, zadať službu, ktorú chcete nasadiť a na ktorý cieľ. Napríklad chcete nasadiť určitý systém do Ruska, Bieloruska alebo Kazachstanu. Ak to chcete urobiť, jednoducho zmeňte jeden z parametrov a budete mať správny konfiguračný súbor.

Keď je služba Nomad už nasadená do vášho klastra, vyzerá to takto.

Najprv potrebujete nejaký balancér vonku, ktorý bude prijímať všetku návštevnosť používateľov. Bude spolupracovať s Consulom a zistí od neho, kde, na akom uzle, na akej IP adrese sa nachádza konkrétna služba, ktorá zodpovedá konkrétnemu názvu domény. Služby v Consul pochádzajú od samotného Nomada. Keďže ide o produkty od tej istej firmy, dosť spolu súvisia. Dá sa povedať, že Nomad po vybalení môže zaregistrovať všetky služby, ktoré sú v ňom spustené vo vnútri Consul.

Keď váš front-end nástroj na vyvažovanie zaťaženia vie, na ktorú službu má posielať návštevnosť, prepošle ju do príslušného kontajnera alebo viacerých kontajnerov, ktoré zodpovedajú vašej aplikácii. Prirodzene, treba myslieť aj na bezpečnosť. Aj keď všetky služby bežia na rovnakých virtuálnych počítačoch v kontajneroch, zvyčajne to vyžaduje zamedzenie voľného prístupu z akejkoľvek služby k inej. Dosiahli sme to segmentáciou. Každá služba bola spustená vo vlastnej virtuálnej sieti, na ktorej boli predpísané pravidlá smerovania a pravidlá pre povolenie/zakázanie prístupu k iným systémom a službám. Mohli by sa nachádzať vo vnútri tohto zhluku aj mimo neho. Ak chcete napríklad zabrániť pripojeniu služby ku konkrétnej databáze, môžete to urobiť segmentáciou na úrovni siete. To znamená, že ani omylom sa nemôžete náhodne pripojiť z testovacieho prostredia k vašej produkčnej databáze.

Koľko nás stál prechod z hľadiska ľudských zdrojov?

Prechod celej spoločnosti na Nomad trval približne 5-6 mesiacov. Postupovali sme podľa jednotlivých služieb, ale pomerne rýchlym tempom. Každý tím si musel vytvoriť vlastné kontajnery pre služby.

Prijali sme taký prístup, že každý tím je zodpovedný za obrázky dokovacích systémov svojich systémov nezávisle. DevOps poskytuje všeobecnú infraštruktúru potrebnú na nasadenie, teda podporu pre samotný klaster, podporu pre CI systém atď. A v tom čase sme mali do Nomadu presunutých viac ako 60 systémov, čo predstavovalo približne 2 tisíc kontajnerov.

Devops je zodpovedný za všeobecnú infraštruktúru všetkého, čo súvisí s nasadením a servermi. A každý vývojový tím je zase zodpovedný za implementáciu kontajnerov pre svoj špecifický systém, pretože je to tím, ktorý vie, čo vo všeobecnosti potrebuje v konkrétnom kontajneri.

Dôvody opustenia Nomada

Aké výhody sme získali prechodom na nasadenie okrem iného pomocou Nomad a docker?

1. My za rovnakých podmienok pre všetky prostredia. Vo vývoji, QA prostredí, predprodukcii, produkcii sa používajú rovnaké obrázky kontajnerov, s rovnakými závislosťami. V súlade s tým nemáte prakticky žiadnu šancu, že to, čo skončí vo výrobe, nie je to, čo ste predtým testovali lokálne alebo vo svojom testovacom prostredí.
2. Tiež sme zistili, že to stačí jednoduché pridanie novej služby. Z hľadiska nasadenia sa akékoľvek nové systémy spúšťajú veľmi jednoducho. Stačí prejsť do úložiska, v ktorom sú uložené konfigurácie, pridať tam ďalšiu konfiguráciu pre váš systém a všetko je pripravené. Svoj systém môžete nasadiť do produkcie bez akéhokoľvek ďalšieho úsilia zo strany vývojárov.
3. všetko konfiguračné súbory v jednom spoločnom úložisku sa ukázalo byť predmetom kontroly. V čase, keď sme naše systémy nasadzovali pomocou virtuálnych serverov, používali sme Ansible, v ktorom boli konfigurácie v rovnakom úložisku. Pre väčšinu vývojárov to však bolo o niečo náročnejšie. Tu sa objem konfigurácií a kódu, ktoré musíte pridať na nasadenie služby, výrazne zmenšil. Navyše je pre vývojárov veľmi jednoduché to opraviť alebo zmeniť. V prípade prechodu, napríklad na novú verziu Nomadu, môžu prevziať a hromadne aktualizovať všetky operačné súbory umiestnené na rovnakom mieste.

Ale narazili sme aj na niekoľko nevýhod:

Ukázalo sa, že my nepodarilo dosiahnuť bezproblémové nasadenie v prípade Nomáda. Pri vykladaní kontajnerov za rôznych podmienok sa mohlo ukázať, že je spustený a Nomad to vnímal ako kontajner pripravený na príjem dopravy. Stalo sa to ešte predtým, ako sa aplikácia v ňom vôbec mohla spustiť. Z tohto dôvodu začal systém na krátky čas produkovať 500 chýb, pretože návštevnosť začala smerovať do kontajnera, ktorý ešte nebol pripravený ju prijať.

S niektorými sme sa stretli pri močiaroch. Najvýznamnejšou chybou je, že Nomad nezvláda veľmi dobre veľký klaster, ak máte veľa systémov a kontajnerov. Keď chcete odstrániť jeden zo serverov, ktoré sú súčasťou klastra Nomad, na údržbu, je dosť vysoká pravdepodobnosť, že klaster sa nebude cítiť dobre a rozpadne sa. Niektoré kontajnery môžu napríklad spadnúť a nie stúpať – to vás bude neskôr stáť veľmi veľa, ak sú všetky vaše produkčné systémy umiestnené v klastri spravovanom Nomadom.

Rozhodli sme sa teda porozmýšľať, kam by sme sa mali vydať ďalej. V tom momente sme si oveľa viac uvedomili, čo chceme dosiahnuť. Totiž: chceme spoľahlivosť, o niečo viac funkcií, než poskytuje Nomad, a vyspelejší a stabilnejší systém.

V tomto smere naša voľba padla na Kubernetes ako najobľúbenejšiu platformu na spúšťanie klastrov. Najmä vzhľadom na to, že veľkosť a počet našich kontajnerov bol dostatočne veľký. Na takéto účely sa Kubernetes javil ako najvhodnejší systém, na ktorý sme sa mohli pozrieť.

Prechod na Kubernetes

Poviem vám niečo o základných konceptoch Kubernetes a ako sa líšia od Nomad.

Po prvé, najzákladnejším konceptom v Kubernetes je koncept pod. Struk je skupina jedného alebo viacerých kontajnerov, ktoré vždy bežia spolu. A vždy fungujú ako striktne na jednom virtuálnom stroji. Sú navzájom prístupné cez IP 127.0.0.1 na rôznych portoch.

Predpokladajme, že máte PHP aplikáciu, ktorá pozostáva z nginx a php-fpm – klasická schéma. S najväčšou pravdepodobnosťou budete chcieť mať kontajnery nginx aj php-fpm vždy spolu. Kubernetes vám to umožňuje dosiahnuť tým, že ich opíšete ako jeden spoločný modul. To je presne to, čo sme s Nomad nemohli získať.

Druhý koncept je rozvinutie. Faktom je, že samotný lusk je efemérna vec; začína a mizne. Chcete najprv zabiť všetky svoje predchádzajúce kontajnery a potom spustiť nové verzie naraz, alebo ich chcete zavádzať postupne? Toto je proces, za ktorý je zodpovedný koncept nasadenia. Popisuje, ako nasadíte svoje moduly, v akom množstve a ako ich aktualizovať.

Tretí koncept je služba. Vaša služba je vlastne váš systém, ktorý prijíma určitú návštevnosť a potom ju preposiela jednému alebo viacerým modulom zodpovedajúcim vašej službe. To znamená, že vám umožňuje povedať, že všetka prichádzajúca návštevnosť tej a takej služby s takým a takým názvom sa musí posielať do týchto špecifických modulov. A zároveň vám poskytuje vyváženie dopravy. To znamená, že môžete spustiť dva moduly vašej aplikácie a všetka prichádzajúca návštevnosť bude rovnomerne vyvážená medzi modulmi súvisiacimi s touto službou.

A štvrtý základný koncept je Ingress. Toto je služba, ktorá beží na klastri Kubernetes. Funguje ako externý load balancer, ktorý preberá všetky požiadavky. Pomocou rozhrania Kubernetes API môže Ingress určiť, kam sa majú tieto požiadavky odoslať. Navyše to robí veľmi flexibilne. Môžete povedať, že všetky požiadavky na tohto hostiteľa a také a také URL sa posielajú tejto službe. A tieto požiadavky prichádzajúce na tento hostiteľ a na inú adresu URL sa odosielajú do inej služby.

Najúžasnejšia vec z pohľadu niekoho, kto vyvíja aplikáciu, je, že si to všetko dokážete spravovať sami. Nastavením konfigurácie Ingress môžete všetku návštevnosť prichádzajúcu do toho a takého API posielať do samostatných kontajnerov napísaných napríklad v Go. Ale táto návštevnosť, prichádzajúca na rovnakú doménu, ale na inú URL, by mala byť odoslaná do kontajnerov napísaných v PHP, kde je veľa logiky, ale nie sú príliš rýchle.

Ak porovnáme všetky tieto koncepty s Nomad, môžeme povedať, že prvé tri koncepty sú spolu Service. A posledný koncept absentuje v samotnom Nomade. Použili sme externý balancer: mohlo by to byť haproxy, nginx, nginx+ atď. V prípade kocky tento dodatočný pojem netreba zvlášť predstavovať. Ak sa však pozriete na Ingress interne, je to buď nginx, haproxy alebo traefik, ale akosi zabudovaný do Kubernetes.

Všetky koncepty, ktoré som opísal, sú v skutočnosti zdroje, ktoré existujú v rámci klastra Kubernetes. Na ich opis v kocke sa používa formát yaml, ktorý je v prípade Nomad čitateľnejší a známejší ako súbory HCL. Ale štruktúrne opisujú to isté napríklad v prípade pod. Hovoria – chcem tam nasadiť také a také pody, s takými a takými obrázkami, v takých a takých množstvách.

Okrem toho sme si uvedomili, že nechceme vytvárať každý jednotlivý zdroj ručne: nasadenie, služby, Ingress atď. Namiesto toho sme chceli opísať každý z našich systémov z hľadiska Kubernetes počas nasadenia, aby sme nemuseli manuálne znovu vytvárať všetky potrebné závislosti zdrojov v správnom poradí. Helm bol vybraný ako systém, ktorý nám to umožnil.

Základné pojmy v Helme

Helm je správca balíkov pre Kubernetes. Je to veľmi podobné tomu, ako fungujú správcovia balíkov v programovacích jazykoch. Umožňujú vám uložiť službu pozostávajúcu napríklad z nasadenia nginx, nasadenia php-fpm, konfigurácie pre Ingress, configmaps (to je entita, ktorá vám umožňuje nastaviť env a ďalšie parametre pre váš systém) vo forme tzv. nazývané grafy. Zároveň Helm beží na vrchole Kubernetes. To znamená, že toto nie je nejaký druh systému stojaceho bokom, ale len ďalšia služba spustená vo vnútri kocky. Interagujete s ním cez jeho API cez príkaz konzoly. Jeho pohodlnosťou a krásou je, že aj keď sa kormidlo zlomí alebo ho odstránite z klastra, vaše služby nezmiznú, keďže kormidlo v podstate slúži len na spustenie systému. Za výkon a stav služieb je potom zodpovedný samotný Kubernetes.

Uvedomili sme si to aj my štandardizácia, ktorý sme boli predtým nútení urobiť sami zavedením jinja do našich konfigurácií, je jednou z hlavných funkcií kormidla. Všetky konfigurácie, ktoré vytvoríte pre svoje systémy, sú uložené v kormidle vo forme šablón, trochu podobných jinja, ale v skutočnosti používajú šablóny jazyka Go, v ktorom je kormidlo napísané, napríklad Kubernetes.

Helm pre nás pridáva niekoľko ďalších konceptov.

graf - toto je popis vašej služby. V iných správcoch balíkov by sa to nazývalo balík, zväzok alebo podobne. Tu sa to nazýva graf.

hodnoty sú premenné, ktoré chcete použiť na zostavenie konfigurácií zo šablón.

Verzia. Zakaždým, keď služba, ktorá je nasadená pomocou kormidla, dostane prírastkovú verziu vydania. Helm si pamätá, aká bola konfigurácia služby v predchádzajúcom vydaní, vydaní pred tým atď. Preto, ak potrebujete vrátiť späť, stačí spustiť príkaz helm callback a nasmerovať ho na predchádzajúcu verziu. Aj keď zodpovedajúca konfigurácia vo vašom archíve nie je v čase návratu k dispozícii, Helm si bude stále pamätať, čo to bolo, a vráti váš systém do stavu, v akom bol v predchádzajúcom vydaní.

V prípade, že používame kormidlo, bežné konfigurácie pre Kubernetes sa premenia aj na šablóny, v ktorých je možné používať premenné, funkcie a aplikovať podmienené príkazy. Týmto spôsobom môžete zhromaždiť konfiguráciu služby v závislosti od prostredia.

V praxi sme sa rozhodli robiť veci trochu inak ako s Nomadom. Ak v Nomade boli konfigurácie nasadenia aj n-premenné, ktoré boli potrebné na nasadenie našej služby, uložené v jednom úložisku, tu sme sa rozhodli rozdeliť ich do dvoch samostatných úložisk. Úložisko „nasadenie“ ukladá iba n-premenných potrebných na nasadenie a úložisko „helm“ ukladá konfigurácie alebo grafy.

Čo nám to dalo?

Napriek tomu, že v samotných konfiguračných súboroch neukladáme žiadne naozaj citlivé údaje. Napríklad heslá do databáz. V Kubernetes sú uložené ako tajomstvá, no napriek tomu tam stále existujú určité veci, ku ktorým nechceme poskytnúť prístup každému. Preto je prístup k úložisku „nasadenia“ obmedzenejší a úložisko „helm“ jednoducho obsahuje popis služby. Z tohto dôvodu k nemu môže bezpečne pristupovať širší okruh ľudí.

Keďže máme nielen produkčné, ale aj iné prostredia, vďaka tomuto oddeleniu môžeme znovu využiť naše kormidelnícke grafy na nasadenie služieb nielen do produkcie, ale napríklad aj do QA prostredia. Dokonca ich nasadiť lokálne pomocou Minikube - toto je vec pre lokálne spustenie Kubernetes.

Vo vnútri každého úložiska sme ponechali rozdelenie na samostatné adresáre pre každú službu. To znamená, že vo vnútri každého adresára sú šablóny súvisiace s príslušným diagramom a popisujúce prostriedky, ktoré je potrebné nasadiť na spustenie nášho systému. V „deploy“ úložisku sme ponechali iba env. V tomto prípade sme nepoužili šablónovanie pomocou jinja, pretože samotná kormidlo poskytuje šablónovanie hneď po vybalení – to je jedna z jeho hlavných funkcií.

Ponechali sme skript nasadenia – deploy.sh, ktorý zjednodušuje a štandardizuje spustenie na nasadenie pomocou kormidla. Takže pre každého, kto chce nasadiť, rozhranie nasadenia vyzerá úplne rovnako ako pri nasadzovaní cez Nomad. Rovnaký deploy.sh, názov vašej služby a miesto, kde ju chcete nasadiť. To spôsobí interné spustenie kormidla. Na druhej strane zhromažďuje konfigurácie zo šablón, vkladá do nich potrebné súbory s hodnotami, potom ich nasadzuje a spúšťa do Kubernetes.

Závery

Zdá sa, že služba Kubernetes je zložitejšia ako Nomad.

Tu odchádzajúca prevádzka prichádza do Ingressu. Ide len o predný kontrolór, ktorý preberá všetky požiadavky a následne ich posiela službám zodpovedajúcim údajom požiadavky. Určuje ich na základe konfigurácií, ktoré sú súčasťou popisu vašej aplikácie v kormidle a ktoré vývojári nastavujú sami. Služba posiela požiadavky na svoje moduly, teda konkrétne kontajnery, pričom vyrovnáva prichádzajúcu premávku medzi všetkými kontajnermi, ktoré patria do tejto služby. A samozrejme by sme nemali zabúdať na to, že by sme nemali ísť nikam od bezpečnosti na úrovni siete. Segmentácia teda funguje v klastri Kubernetes, ktorý je založený na značkovaní. Všetky služby majú určité značky, ku ktorým sú priradené prístupové práva služieb k určitým externým/interným zdrojom v rámci alebo mimo klastra.

Počas prechodu sme videli, že Kubernetes má všetky možnosti Nomadu, ktoré sme predtým používali, a tiež pridal veľa nových vecí. Dá sa rozšíriť pomocou doplnkov a v skutočnosti prostredníctvom vlastných typov zdrojov. To znamená, že máte možnosť nielen použiť niečo, čo sa dodáva s Kubernetes hneď po vybalení, ale vytvoriť si vlastný zdroj a službu, ktorá bude čítať váš zdroj. To vám dáva ďalšie možnosti rozšírenia systému bez toho, aby ste museli preinštalovať Kubernetes a bez nutnosti úprav.

Príkladom takéhoto použitia je Prometheus, ktorý beží v našom klastri Kubernetes. Aby mohla začať zbierať metriky z konkrétnej služby, musíme do popisu služby pridať ďalší typ zdroja, takzvaný monitor služby. Prometheus vďaka tomu, že dokáže čítať vlastný typ zdroja pri spustení v Kubernetes, automaticky začne zbierať metriky z nového systému. Je to celkom pohodlné.

Prvé nasadenie, ktoré sme vykonali v Kubernetes, bolo v marci 2018. A počas tejto doby sme s tým nikdy nezaznamenali žiadne problémy. Funguje celkom stabilne bez výraznejších chýb. Navyše ho môžeme ďalej rozširovať. Dnes máme dostatok možností, ktoré má, a tempo vývoja Kubernetes sa nám veľmi páči. V súčasnosti je v Kubernetes viac ako 3000 kontajnerov. Klaster zaberá niekoľko uzlov. Zároveň je prevádzkyschopný, stabilný a veľmi dobre ovládateľný.

Zdroj: hab.com