{"id":33654,"date":"2019-10-31T21:53:58","date_gmt":"2019-10-31T18:53:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/deploj-prilozhenij-v-vm-nomad-i-kubernetes\/"},"modified":"2019-10-31T21:53:58","modified_gmt":"2019-10-31T18:53:58","slug":"deploj-prilozhenij-v-vm-nomad-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"Nasadenie aplik\u00e1ci\u00ed vo VM, Nomad a Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ahojte v\u0161etci! Vol\u00e1m sa Pavel Agaletck\u00fd. Pracujem ako t\u00edmov\u00fd l\u00edder v t\u00edme, ktor\u00fd vyv\u00edja doru\u010dovaciu syst\u00e9m Lamoda. V roku 2018 som vyst\u00fapil na konferencii HighLoad++, a dnes chcem predstavi\u0165 prepis svojej prezent\u00e1cie.<\/p>\n

Moja t\u00e9ma sa venuje sk\u00fasenostiam na\u0161ej spolo\u010dnosti pri nasaden\u00ed syst\u00e9mov a slu\u017eieb do r\u00f4znych prostred\u00ed. Za\u010dneme od na\u0161ich pravek\u00fdch \u010dias, ke\u010f sme nasadzovali v\u0161etky syst\u00e9my na oby\u010dajn\u00e9 virtu\u00e1lne servery, kon\u010diac postupn\u00fdm prechodom od Nomad po nasadenie do Kubernetes. Povieme si, pre\u010do sme to urobili a ak\u00e9 probl\u00e9my sme mali v procese.<\/p>\n

\r\n \"Prehrajte\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

Nasadenie aplik\u00e1ci\u00ed na VM<\/h1>\n

\nZa\u010dneme t\u00fdm, \u017ee pred 3 rokmi v\u0161etky syst\u00e9my a slu\u017eby spolo\u010dnosti boli nasadzovan\u00e9 na oby\u010dajn\u00e9 virtu\u00e1lne servery. Technicky to bolo usporiadan\u00e9 tak, \u017ee cel\u00fd k\u00f3d na\u0161ich syst\u00e9mov le\u017eal a bol zostavovan\u00fd pomocou automatizovanej zostavy, s pomocou jenkins. Pomocou Ansible sa rozkladali z n\u00e1\u0161ho syst\u00e9mu kontroly verzi\u00ed na virtu\u00e1lne servery. Pri tom ka\u017ed\u00e1 syst\u00e9m, ktor\u00fd sme mali v na\u0161ej spolo\u010dnosti, bol nasaden\u00fd minim\u00e1lne na 2 serveroch: jeden z nich bol head, druh\u00fd bol tail. Tieto dva syst\u00e9my boli vo v\u0161etk\u00fdch svojich nastaveniach, v\u00fdkonnosti, konfigur\u00e1cii a in\u00fdch parametroch \u00faplne identick\u00e9. Rozdiel medzi nimi bol len v tom, \u017ee head prij\u00edmal pou\u017e\u00edvate\u013esk\u00fd traffic, zatia\u013e \u010do tail nikdy neprij\u00edmal traffic pou\u017e\u00edvate\u013eov. <\/p>\n

Na \u010do to bolo uroben\u00e9? <\/p>\n

Ke\u010f sme nasadzovali nov\u00e9 verzie na\u0161ej aplik\u00e1cie, chceli sme zabezpe\u010di\u0165 mo\u017enos\u0165 bezprobl\u00e9mov\u00e9ho nasadenia, teda bez vidite\u013en\u00fdch n\u00e1sledkov pre pou\u017e\u00edvate\u013eov. Dosahovalo sa to t\u00fdm, \u017ee \u010fal\u0161ia zostaven\u00e1 verzia sa pomocou Ansible nasadzovala na tail. Tam mohli \u013eudia, ktor\u00ed sa zaoberali nasaden\u00edm, skontrolova\u0165 a uisti\u0165 sa, \u017ee v\u0161etko je v poriadku: v\u0161etky metriky, sekcie a aplik\u00e1cie funguj\u00fa; sp\u00fa\u0161\u0165aj\u00fa sa potrebn\u00e9 skripty. A\u017e potom, \u010do sa uistili, \u017ee v\u0161etko je v poriadku, sa traffic prepol. Ten za\u010dal prich\u00e1dza\u0165 na server, ktor\u00fd do tej doby bol tail. A ten, ktor\u00fd do tej doby bol head, zostal bez pou\u017e\u00edvate\u013esk\u00e9ho trafficu, pri\u010dom mal predch\u00e1dzaj\u00facu verziu na\u0161ej aplik\u00e1cie.<\/p>\n

Pre u\u017e\u00edvate\u013eov to bolo bezprobl\u00e9mov\u00e9. Preto\u017ee preklik je okam\u017eit\u00fd, ke\u010f\u017ee ide iba o prehodnotenie vyva\u017eova\u010da. Je ve\u013emi jednoduch\u00e9 vr\u00e1ti\u0165 sa na predch\u00e1dzaj\u00facu verziu jednoducho prehodnoten\u00edm vyva\u017eova\u010da sp\u00e4\u0165. Taktie\u017e sme sa mohli uisti\u0165 o schopnosti aplik\u00e1cie na produkcii e\u0161te predt\u00fdm, ako na \u0148u p\u00f4jde u\u017e\u00edvate\u013esk\u00fd traffic, \u010do bolo dos\u0165 pohodln\u00e9. <\/p>\n

Ak\u00e9 sme videli v celom tomto v\u00fdhody?<\/p>\n

    \n
  1. Predov\u0161etk\u00fdm, je to dos\u0165 jednoduch\u00e9 fungovanie.<\/b> V\u0161etk\u00fdm je jasn\u00e9, ako funguje tak\u00e1to sch\u00e9ma nasadenia, preto\u017ee v\u00e4\u010d\u0161ina \u013eud\u00ed niekedy nasadila na be\u017en\u00e9 virtu\u00e1lne servery.<\/li>\n
  2. Je to dos\u0165 spo\u013eahliv\u00e9<\/b>, preto\u017ee technol\u00f3gia nasadenia je jednoduch\u00e1, overen\u00e1 tis\u00edckami spolo\u010dnost\u00ed. Mili\u00f3ny serverov sa nasadzuj\u00fa pr\u00e1ve takto. Je \u0165a\u017ek\u00e9 nie\u010do pokazi\u0165. <\/li>\n
  3. A nakoniec, mohli sme z\u00edska\u0165 atom\u00e1rne nasadenia<\/b>. Nasadenia, ktor\u00e9 sa pre u\u017e\u00edvate\u013eov uskuto\u010d\u0148uj\u00fa okam\u017eite, bez vidite\u013enej f\u00e1zy prechodu medzi starou a novou verziou. <\/li>\n<\/ol>\n

    \nAle v tom v\u0161etkom sme tie\u017e videli nieko\u013eko nev\u00fdhod: <\/p>\n

      \n
    1. Okrem produk\u010dn\u00e9ho prostredia, v\u00fdvojov\u00e9ho prostredia, existuj\u00fa aj \u010fal\u0161ie prostredia. Napr\u00edklad, qa a preprodukcia. V tom \u010dase sme mali ve\u013ea serverov a pribli\u017ene 60 slu\u017eieb. Z tohto d\u00f4vodu sme museli pre ka\u017ed\u00fa slu\u017ebu udr\u017eiava\u0165 aktu\u00e1lnu verziu <\/b>virtu\u00e1lneho stroja. A ak chcete aktualizova\u0165 kni\u017enice alebo nain\u0161talova\u0165 nov\u00e9 z\u00e1vislosti, mus\u00edte to urobi\u0165 vo v\u0161etk\u00fdch prostrediach. Tie\u017e bolo potrebn\u00e9 synchronizova\u0165 \u010das, kedy pl\u00e1nujete nasadi\u0165 nov\u00fa verziu va\u0161ej aplik\u00e1cie, s \u010dasom, kedy devops vykon\u00e1 potrebn\u00e9 nastavenia prostredia. V takom pr\u00edpade je \u013eahk\u00e9 sa dosta\u0165 do situ\u00e1cie, kedy sa na\u0161e prostredie bude mierne l\u00ed\u0161i\u0165 vo v\u0161etk\u00fdch prostrediach po sebe. Napr\u00edklad, v QA prostred\u00ed bud\u00fa in\u00e9 verzie kni\u017en\u00edc ako v produkcii, \u010do povedie k probl\u00e9mom. <\/li>\n
    2. Zlo\u017eitos\u0165 pri aktualiz\u00e1cii z\u00e1vislost\u00ed<\/b> va\u0161ej aplik\u00e1cie. To nez\u00e1vis\u00ed od v\u00e1s, ale od in\u00e9ho t\u00edmu. A konkr\u00e9tne, od t\u00edmu devops, ktor\u00fd spravuje servery. Mus\u00edte im nastavi\u0165 pr\u00edslu\u0161n\u00fa \u00falohu a poskytn\u00fa\u0165 popis toho, \u010do chcete urobi\u0165.<\/li>\n
    3. V tom \u010dase sme sa tie\u017e chceli zbavi\u0165 na\u0161ich ve\u013ek\u00fdch monolitov a rozdeli\u0165 ich na men\u0161ie slu\u017eby, preto\u017ee sme vedeli, \u017ee ich bude st\u00e1le viac a viac. V tom \u010dase sme u\u017e mali viac ako 100 tak\u00fdchto slu\u017eieb. Pre ka\u017ed\u00fa nov\u00fa slu\u017ebu bolo potrebn\u00e9 vytvori\u0165 samostatn\u00fa virtu\u00e1lnu ma\u0161inu, ktor\u00fa bolo tie\u017e nutn\u00e9 spravova\u0165 a nasadzova\u0165. Okrem toho potrebujeme nie jednu, ale aspo\u0148 dve ma\u0161iny. K tomu v\u0161etk\u00e9mu potrebujeme aj testovaciu (QA) prostredie. To sp\u00f4sobuje probl\u00e9my a rob\u00ed vytv\u00e1ranie a spustenie nov\u00fdch syst\u00e9mov pre v\u00e1s ove\u013ea komplexnej\u0161\u00edm, n\u00e1kladnej\u0161\u00edm a zd\u013ahavej\u0161\u00edm procesom.<\/b><\/li>\n<\/ol>\n

      \nPreto sme sa rozhodli, \u017ee bude pohodlnej\u0161ie prejs\u0165 od nasadzovania be\u017en\u00fdch virtu\u00e1lnych strojov k nasadenie na\u0161ich aplik\u00e1ci\u00ed v kontajneri Docker. Pri pou\u017e\u00edvan\u00ed Docker potrebujeme syst\u00e9m, ktor\u00fd dok\u00e1\u017ee spusti\u0165 aplik\u00e1ciu v klastri, preto\u017ee jednoducho nezvl\u00e1dnete len tak spusti\u0165 kontajner. Zvy\u010dajne chcete sledova\u0165 po\u010det spusten\u00fdch kontajnerov, aby sa automaticky sp\u00fa\u0161\u0165ali. Z tohto d\u00f4vodu sme potrebovali vybra\u0165 syst\u00e9m na spr\u00e1vu. <\/p>\n

      Dlho sme uva\u017eovali, ktor\u00fa z nich si zobra\u0165. Probl\u00e9m bol v tom, \u017ee v tom \u010dase bol n\u00e1\u0161 nasadzovac\u00ed stack na be\u017en\u00e9 virtu\u00e1lne servery zastaran\u00fd, preto\u017ee sme tam mali nie najnov\u0161ie verzie opera\u010dn\u00fdch syst\u00e9mov. V ur\u010ditom momente sme tam mali dokonca FreeBSD, \u010do bolo \u0165a\u017ek\u00e9 podporova\u0165. Uvedomovali sme si, \u017ee mus\u00edme \u010do najsk\u00f4r migrova\u0165 na Docker. Na\u0161i DevOps si prezreli svoju existuj\u00facu prax s r\u00f4znymi rie\u0161eniami a vybrali syst\u00e9m ako Nomad. <\/p>\n

      Prechod na Nomad<\/h1>\n

      \nNomad je produkt spolo\u010dnosti \u201eHashiCorp\u201c. Taktie\u017e s\u00fa zn\u00e1mi svojimi \u010fal\u0161\u00edmi rie\u0161eniami:<\/p>\n

      \"Nasadenie
      \n
      \n\u201eConsul\u201c<\/b> \u2014 je n\u00e1stroj na objavovanie slu\u017eieb.<\/p>\n

      \u201eTerraform\u201c<\/b> \u2014 syst\u00e9m na spr\u00e1vu serverov, ktor\u00fd v\u00e1m umo\u017e\u0148uje nastavi\u0165 ich prostredn\u00edctvom konfigur\u00e1cie, zn\u00e1mej ako infrastructure-as-a-code.<\/p>\n

      \u201eVagrant\u201c<\/b> umo\u017e\u0148uje v\u00e1m nasadzova\u0165 virtu\u00e1lne stroje lok\u00e1lne alebo v cloude pomocou definovan\u00fdch konfigura\u010dn\u00fdch s\u00faborov. <\/p>\n

      Nomad v tom \u010dase vyzeral ako dostato\u010dne jednoduch\u00e9 rie\u0161enie, na ktor\u00e9 je mo\u017en\u00e9 r\u00fdchlo prejs\u0165 bez zmeny celej infra\u0161trukt\u00fary. Okrem toho je aj dos\u0165 \u013eahko ovl\u00e1date\u013en\u00fd. Preto sme ho vybrali ako syst\u00e9m na spr\u00e1vu na\u0161ich kontajnerov. <\/p>\n

      \u010co potrebujete na to, aby ste v\u00f4bec mohli nasadi\u0165 v\u00e1\u0161 syst\u00e9m do Nomad? <\/p>\n

        \n
      1. Predov\u0161etk\u00fdm potrebujete docker image<\/b> va\u0161ej aplik\u00e1cie. Je potrebn\u00e9 ju zostavi\u0165 a umiestni\u0165 do \u00falo\u017eiska obrazov docker. V na\u0161om pr\u00edpade je to artifactory \u2014 syst\u00e9m, ktor\u00fd umo\u017e\u0148uje uklada\u0165 r\u00f4zne artefakty r\u00f4zneho typu. Uklad\u00e1 arch\u00edvy, docker obrazy, RHP bal\u00edky, NPM bal\u00edky a tak \u010falej. <\/li>\n
      2. Tie\u017e je potrebn\u00e9 konfigura\u010dn\u00fd s\u00fabor<\/b>, ktor\u00fd povie Nomadovi, \u010do, kam a v akom mno\u017estve chcete nasadi\u0165. <\/li>\n<\/ol>\n

        \nKe\u010f hovor\u00edme o Nomade, ako form\u00e1t informa\u010dn\u00e9ho s\u00faboru pou\u017e\u00edva jazyk HCL, \u010do je skratka pre HashiCorp Configuration Language<\/i>. Je to nadmno\u017eina jazyka YAML, ktor\u00e1 v\u00e1m umo\u017e\u0148uje pop\u00edsa\u0165 va\u0161u slu\u017ebu pojmami Nomadu. <\/p>\n

        \"Nasadenie
        \n
        \nUmo\u017e\u0148uje v\u00e1m poveda\u0165, ko\u013eko kontajnerov chcete nasadi\u0165, z ktor\u00fdch obr\u00e1zkov im posla\u0165 r\u00f4zne parametre pri nasaden\u00ed. Takto pod\u00e1vate tento s\u00fabor Nomadu, ktor\u00fd sp\u00fa\u0161\u0165a kontajnery v produkcii pod\u013ea neho. <\/p>\n

        V na\u0161om pr\u00edpade sme si uvedomili, \u017ee p\u00edsanie absol\u00fatne identick\u00fdch HCL s\u00faborov pre ka\u017ed\u00fa slu\u017ebu by nebolo ve\u013emi pohodln\u00e9, preto\u017ee slu\u017eieb je ve\u013ea a ob\u010das ich chcete aktualizova\u0165. M\u00f4\u017ee sa sta\u0165, \u017ee jedna slu\u017eba nie je nasaden\u00e1 v jednom exempl\u00e1ri, ale v r\u00f4znych. Napr\u00edklad jeden z na\u0161ich syst\u00e9mov v produkcii m\u00e1 viac ako 100 in\u0161tanci\u00ed v prev\u00e1dzke. Sp\u00fa\u0161\u0165aj\u00fa sa z t\u00fdch ist\u00fdch obrazov, ale l\u00ed\u0161ia sa konfigur\u00e1ciou a konfigura\u010dn\u00fdmi s\u00fabormi. <\/p>\n

        Preto sme sa rozhodli, \u017ee bude pohodln\u00e9 uchov\u00e1va\u0165 v\u0161etky na\u0161e konfigura\u010dn\u00e9 s\u00fabory pre nasadenie v jednom spolo\u010dnom repozit\u00e1ri. Takto sa stali preh\u013eadn\u00fdmi: bolo ich \u013eahk\u00e9 udr\u017eiava\u0165 a mohli sme vidie\u0165, ak\u00e9 syst\u00e9my m\u00e1me. V pr\u00edpade potreby nie je tie\u017e \u0165a\u017ek\u00e9 nie\u010do aktualizova\u0165 alebo zmeni\u0165. Prida\u0165 nov\u00fd syst\u00e9m tie\u017e nebude probl\u00e9m \u2014 sta\u010d\u00ed jednoducho vytvori\u0165 konfigura\u010dn\u00fd s\u00fabor v novej prie\u010dinke. Vn\u00fatri nej s\u00fa s\u00fabory: service.hcl, ktor\u00fd obsahuje popis na\u0161ej slu\u017eby, a niektor\u00e9 env s\u00fabory, ktor\u00e9 umo\u017e\u0148uj\u00fa t\u00fato slu\u017ebu, ke\u010f je nasaden\u00e1 do produkcie, nakonfigurova\u0165. <\/p>\n

        \"Nasadenie
        \n
        \nAv\u0161ak niektor\u00e9 na\u0161e syst\u00e9my s\u00fa nasaden\u00e9 v produkcii nie v jednom exempl\u00e1ri, ale v nieko\u013ek\u00fdch naraz. Preto sme sa rozhodli, \u017ee bude pre n\u00e1s pohodln\u00e9 uchov\u00e1va\u0165 nie\u010die konfigur\u00e1cie v \u010distej forme, ale ich \u0161abl\u00f3nov\u00fa podobu. A ako jazyk \u0161abloniz\u00e1cie sme vybrali jinja 2<\/i>. V takom form\u00e1te uchov\u00e1vame nielen konfigur\u00e1cie samotnej slu\u017eby, ale aj env-s\u00fabory, ktor\u00e9 s\u00fa pre \u0148u potrebn\u00e9. <\/p>\n

        Okrem toho sme do repozit\u00e1ra umiestnili spolo\u010dn\u00fd skript pre v\u0161etky projekty, ktor\u00fd umo\u017e\u0148uje spusti\u0165 a nasadi\u0165 va\u0161u slu\u017ebu do produkcie, do po\u017eadovan\u00e9ho prostredia a ciela. V pr\u00edpade, \u017ee sme n\u00e1\u0161 HCL-konfig premenili na \u0161abl\u00f3nu, tak ten HCL-s\u00fabor, ktor\u00fd predt\u00fdm bol oby\u010dajn\u00fdm konfigom Nomad, v tomto pr\u00edpade vyzer\u00e1 trochu inak.<\/p>\n

        \"Nasadenie
        \n
        \nTo znamen\u00e1, \u017ee sme nahradili niektor\u00e9 premenn\u00e9 miesta konfigu vlo\u017een\u00edm premenn\u00fdch, ktor\u00e9 sa ber\u00fa z env-s\u00faborov alebo z in\u00fdch zdrojov. Okrem toho sme z\u00edskali mo\u017enos\u0165 dynamicky generova\u0165 HCL-s\u00fabory, to znamen\u00e1, \u017ee m\u00f4\u017eeme aplikova\u0165 nielen oby\u010dajn\u00e9 vkladanie premenn\u00fdch. Ke\u010f\u017ee jinja podporuje cykly a podmienky, m\u00f4\u017eeme bra\u0165 do \u00favahy aj konfigura\u010dn\u00e9 s\u00fabory, ktor\u00e9 sa menia v z\u00e1vislosti od toho, kam presne nasadzujete svoje aplik\u00e1cie. <\/p>\n

        Napr\u00edklad, ak chcete nasadi\u0165 svoju slu\u017ebu do preprodukcie a do produkcie. Predpokladajme, \u017ee v preprodukcii nechcete sp\u00fa\u0161\u0165a\u0165 cron-skripty, ale jednoducho chcete vidie\u0165 slu\u017ebu na samostatnej dom\u00e9ne, aby ste sa uistili, \u017ee funguje. Pre ka\u017ed\u00e9ho, kto nas\u00e1dza slu\u017ebu, je proces ve\u013emi jednoduch\u00fd a transparentn\u00fd. Sta\u010d\u00ed spusti\u0165 s\u00fabor deploy.sh, uvies\u0165, ktor\u00fa slu\u017ebu chcete nasadi\u0165 a do ktor\u00e9ho cie\u013ea. Napr\u00edklad, ak chcete nasadi\u0165 nejak\u00fd syst\u00e9m do Ruska, Bieloruska alebo Kazachstanu. Na to sta\u010d\u00ed jednoducho zmeni\u0165 jeden z parametrov a spr\u00e1vny konfigura\u010dn\u00fd s\u00fabor sa zostav\u00ed. <\/p>\n

        Ke\u010f je slu\u017eba Nomad u\u017e nasaden\u00e1 vo va\u0161om klastri, vyzer\u00e1 to nasledovne.<\/p>\n

        \"Nasadenie
        \n
        \nNa za\u010diatok potrebujete nejak\u00fd vyva\u017eova\u010d zvonka, ktor\u00fd bude prij\u00edma\u0165 cel\u00fd pou\u017e\u00edvate\u013esk\u00fd prenos. Bude pracova\u0165 spolu s Consul a zis\u0165ova\u0165 od neho, kde, na ktorej node, pod\u013ea ak\u00e9ho IP adresu<\/a> sa nach\u00e1dza konkr\u00e9tna slu\u017eba, ktor\u00e1 zodpoved\u00e1 dan\u00e9mu dom\u00e9nov\u00e9mu menu. Slu\u017eby v Consul sa objavuj\u00fa priamo z Nomad. Ke\u010f\u017ee ide o produkty tej istej spolo\u010dnosti, s\u00fa medzi sebou dobre prepojen\u00e9. Dalo by sa poveda\u0165, \u017ee Nomad m\u00e1 z boxu schopnos\u0165 registrova\u0165 v\u0161etky spusten\u00e9 slu\u017eby v \u0148om priamo v Consul. <\/p>\n

        Ke\u010f v\u00e1\u0161 extern\u00fd vyva\u017eova\u010d za\u0165a\u017eenia zist\u00ed, do ktorej slu\u017eby m\u00e1 posla\u0165 prev\u00e1dzku, prepo\u0161le ju do pr\u00edslu\u0161n\u00e9ho kontajnera alebo nieko\u013ek\u00fdch kontajnerov, ktor\u00e9 zodpovedaj\u00fa va\u0161ej aplik\u00e1cii. Samozrejme, pri tom treba myslie\u0165 aj na bezpe\u010dnos\u0165. Aj ke\u010f sa v\u0161etky slu\u017eby sp\u00fa\u0161\u0165aj\u00fa na t\u00fdch ist\u00fdch virtu\u00e1lnych strojoch v kontajneroch, zvy\u010dajne treba zak\u00e1za\u0165 vo\u013en\u00fd pr\u00edstup z ktorejko\u013evek slu\u017eby k akejko\u013evek inej. To sme dosiahli pomocou segment\u00e1cie. Ka\u017ed\u00e1 slu\u017eba bola spusten\u00e1 vo svojej virtu\u00e1lnej sieti, na ktorej boli nastaven\u00e9 pravidl\u00e1 smerovania a pravidl\u00e1 povo\u013eovania\/zakazovania pr\u00edstupov\u00fdch pr\u00e1v k in\u00fdm syst\u00e9mom a slu\u017eb\u00e1m. Tieto slu\u017eby mohli by\u0165 bu\u010f v r\u00e1mci tohto klastera, alebo mimo neho. Napr\u00edklad, ak chcete zak\u00e1za\u0165 slu\u017ebe pripoji\u0165 sa k ur\u010ditej datab\u00e1ze, m\u00f4\u017eete to urobi\u0165 prostredn\u00edctvom segment\u00e1cie na \u00farovni siete. To znamen\u00e1, \u017ee ani chybne sa nem\u00f4\u017eete n\u00e1hodou pripoji\u0165 z testovacieho prostredia k va\u0161ej produk\u010dnej datab\u00e1ze.<\/p>\n

        Ko\u013eko n\u00e1s st\u00e1lo prechod z h\u013eadiska \u013eudsk\u00fdch zdrojov? <\/p>\n

        Prechod celej spolo\u010dnosti na Nomad trval pribli\u017ene 5-6 mesiacov. Prech\u00e1dzali sme po slu\u017eb\u00e1ch, ale v dos\u0165 r\u00fdchlom tempe. Ka\u017ed\u00fd t\u00edm musel vytvori\u0165 svoje vlastn\u00e9 kontajnerov\u00e9 slu\u017eby. <\/p>\n

        Prijali sme tak\u00fd pr\u00edstup, \u017ee ka\u017ed\u00fd t\u00edm zodpoved\u00e1 za docker imid\u017ee svojich syst\u00e9mov samostatne. DevOps poskytuj\u00fa spolo\u010dn\u00fa infra\u0161trukt\u00faru potrebn\u00fa na nasadenie, teda podporu samotn\u00e9ho klastera, podporu CI syst\u00e9mu a tak \u010falej. V tom \u010dase u n\u00e1s viac ako 60 syst\u00e9mov pre\u0161lo na Nomad, \u010do vytvorilo okolo 2000 kontajnerov. <\/p>\n

        DevOps zodpoved\u00e1 za spolo\u010dn\u00fa infra\u0161trukt\u00faru v\u0161etk\u00e9ho, \u010do s\u00favis\u00ed s nasaden\u00edm a servermi. A ka\u017ed\u00fd t\u00edm v\u00fdvoja zase zodpoved\u00e1 za realiz\u00e1ciu kontajnerov pod svoj konkr\u00e9tny syst\u00e9m, preto\u017ee len t\u00edm vie, \u010do vlastne potrebuje v tom \u010di onom kontajneri.<\/p>\n

        D\u00f4vody odmietnutia Nomad<\/h1>\n

        \nAk\u00e9 v\u00fdhody sme z\u00edskali prechodom na nasadenie pomocou Nomad a docker?<\/p>\n

          \n
        1. Integrujeme Grafanu s Omnibus poskytli sme rovnak\u00e9 podmienky<\/b> pre v\u0161etky prostredia. Vo v\u00fdvoji, QA prostred\u00ed, predproduk\u010dnom a produk\u010dnom prostred\u00ed sa pou\u017e\u00edvaj\u00fa tieto ist\u00e9 obrazy kontajnerov so v\u0161etk\u00fdmi rovnak\u00fdmi z\u00e1vislos\u0165ami. T\u00fdm p\u00e1dom m\u00e1te takmer nulov\u00fa \u0161ancu, \u017ee do produkcie sa dostane nie\u010do, \u010do ste predt\u00fdm netestovali lok\u00e1lne alebo v testovacom prostred\u00ed. <\/li>\n
        2. Tie\u017e sme zistili, \u017ee je dostato\u010dne \u013eahk\u00e9 prida\u0165 nov\u00fa slu\u017ebu<\/b>. Ak\u00e9ko\u013evek nov\u00e9 syst\u00e9my z poh\u013eadu nasadenia sa sp\u00fa\u0161\u0165aj\u00fa ve\u013emi jednoducho. Sta\u010d\u00ed \u00eds\u0165 do repozit\u00e1ra, kde sa uchov\u00e1vaj\u00fa konfigur\u00e1cie, prida\u0165 tam \u010fal\u0161iu konfigur\u00e1ciu pre v\u00e1\u0161 syst\u00e9m a m\u00e1te v\u0161etko pripraven\u00e9. M\u00f4\u017eete nasadi\u0165 v\u00e1\u0161 syst\u00e9m do produkcie bez dodato\u010dn\u00fdch sn\u00e1h od devops. <\/li>\n
        3. V\u0161echna konfigura\u010dn\u00e9 s\u00fabory<\/b> v jednom spolo\u010dnom repozit\u00e1ri sa uk\u00e1zali ako preh\u013eadn\u00e9<\/b>. V tom momente, ke\u010f sme nasadzovali na\u0161e syst\u00e9my pomocou virtu\u00e1lne servery.<\/a>, sme pou\u017e\u00edvali Ansible, v ktorom boli konfigur\u00e1cie ulo\u017een\u00e9 v rovnakom repozit\u00e1ri. Av\u0161ak pre v\u00e4\u010d\u0161inu v\u00fdvoj\u00e1rov bolo s t\u00fdmto trochu zlo\u017eitej\u0161ie pracova\u0165. Tu sa objem konfigur\u00e1ci\u00ed a k\u00f3du, ktor\u00fd mus\u00edte prida\u0165, aby ste nasadili slu\u017ebu, v\u00fdrazne zn\u00ed\u017eil. Navy\u0161e je pre devops ve\u013emi jednoduch\u00e9 ho opravi\u0165 alebo zmeni\u0165. V pr\u00edpade prechodov, napr\u00edklad na novej verzii Nomad, m\u00f4\u017eu hromadne aktualizova\u0165 v\u0161etky opera\u010dn\u00e9 s\u00fabory, ktor\u00e9 s\u00fa ulo\u017een\u00e9 na rovnakom mieste.<\/li>\n<\/ol>\n

          \nAle stretli sme sa aj s nieko\u013ek\u00fdmi nev\u00fdhodami: <\/p>\n

          Uk\u00e1zalo sa, \u017ee sme nedok\u00e1zali dosiahnu\u0165 bezprobl\u00e9movos\u0165 nasaden\u00ed <\/b>v pr\u00edpade Nomad. Pri nasadzovan\u00ed kontajnerov z r\u00f4znych podmienok mohlo nasta\u0165, \u017ee bol spusten\u00fd a Nomad ho pova\u017eoval za pripraven\u00fd na prijatie prev\u00e1dzky. To sa stalo e\u0161te predt\u00fdm, ako sa aplik\u00e1cia vn\u00fatri stihla spusti\u0165. Z tohto d\u00f4vodu syst\u00e9m na kr\u00e1tky \u010das za\u010d\u00ednal generova\u0165 chyby 500, preto\u017ee prev\u00e1dzka za\u010dala prich\u00e1dza\u0165 na kontajner, ktor\u00fd e\u0161te nebol pripraven\u00fd ju prija\u0165. <\/p>\n

          Stretli sme sa s niektor\u00fdmi chybami<\/b>. Najv\u00fdraznej\u0161ou chybou je, \u017ee Nomad nie je ve\u013emi dobre prisp\u00f4soben\u00fd pre ve\u013ek\u00e9 klastre, ak m\u00e1te mnoho syst\u00e9mov a kontajnerov. Ke\u010f sa rozhodnete uvies\u0165 do \u00fadr\u017eby jeden zo serverov, ktor\u00fd je s\u00fa\u010das\u0165ou klastru Nomad, existuje pomerne ve\u013ek\u00e1 pravdepodobnos\u0165, \u017ee sa klaster nebude c\u00edti\u0165 dobre a rozpadne sa. Niektor\u00e9 kontajnery m\u00f4\u017eu napr\u00edklad spadn\u00fa\u0165 a neznovu sa spusti\u0165 \u2014 to v\u00e1s n\u00e1sledne ve\u013emi draho vyjde, ak s\u00fa v\u0161etky va\u0161e syst\u00e9my v produkcii pr\u00e1ve v klastre spravovanom Nomadom. <\/p>\n

          Preto sme sa rozhodli zv\u00e1\u017ei\u0165, kam sa pohn\u00fa\u0165 \u010falej. V tom \u010dase sme omnoho lep\u0161ie ch\u00e1pali, \u010do chceme dosiahnu\u0165. A to konkr\u00e9tne: chceme spo\u013eahlivos\u0165, o nie\u010do viac funkci\u00ed, ne\u017e pon\u00faka Nomad, a vyzretej\u0161\u00ed, stabilnej\u0161\u00ed syst\u00e9m. <\/p>\n

          V tomto smere sme sa rozhodli pre Kubernetes ako pre najpopul\u00e1rnej\u0161iu platformu na sp\u00fa\u0161\u0165anie klastrov. Najm\u00e4 vzh\u013eadom na to, \u017ee ve\u013ekos\u0165 a po\u010det na\u0161ich kontajnerov bol dos\u0165 ve\u013ek\u00fd. Pre tieto \u00fa\u010dely sa Kubernetes uk\u00e1zal ako najvhodnej\u0161\u00ed syst\u00e9m zo v\u0161etk\u00fdch, ktor\u00e9 sme mohli presk\u00fama\u0165. <\/p>\n

          Prechod na Kubernetes<\/h1>\n

          \nTrochu poviem o tom, ak\u00e9 s\u00fa z\u00e1kladn\u00e9 pojmy Kubernetes a \u010d\u00edm sa l\u00ed\u0161ia od Nomadu. <\/p>\n

          \"Nasadenie
          \n
          \nNa prvom mieste je najz\u00e1kladnej\u0161\u00edm pojmom v Kubernetes pojem pod. Pod<\/b> \u2014 je to skupina jedn\u00e9ho alebo viacer\u00fdch kontajnerov, ktor\u00e9 sa v\u017edy sp\u00fa\u0161\u0165aj\u00fa spolu. A funguj\u00fa akoby v\u017edy priamo na jednom virtu\u00e1lnom stroji. S\u00fa dostupn\u00e9 navz\u00e1jom na IP adrese 127.0.0.1 na r\u00f4znych portoch. <\/p>\n

          Predpokladajme, \u017ee m\u00e1te PHP aplik\u00e1ciu, ktor\u00e1 sa sklad\u00e1 z nginx a php-fpm \u2013 klasick\u00fd schematick\u00fd model. Sk\u00f4r \u010di nesk\u00f4r budete chcie\u0165, aby kontajnery nginx aj php-fpm boli v\u017edy spolu. Kubernetes to umo\u017e\u0148uje dosiahnu\u0165 t\u00fdm, \u017ee ich pop\u00ed\u0161ete ako jeden spolo\u010dn\u00fd pod. Pr\u00e1ve to sme nedok\u00e1zali dosiahnu\u0165 pomocou Nomadu.<\/p>\n

          Druh\u00fdm pojmom je deployment<\/b>. Pod je toti\u017e efem\u00e9rna z\u00e1le\u017eitos\u0165, sp\u00fa\u0161\u0165a sa a zmizne. \u010ci u\u017e chcete najprv zastavi\u0165 v\u0161etky va\u0161e predch\u00e1dzaj\u00face kontajnery a potom spusti\u0165 nov\u00e9 verzie, alebo ich chcete uv\u00e1dza\u0165 postupne \u2013 pr\u00e1ve za tento proces je zodpovedn\u00fd pojem deployment. Ten popisuje, ako nasadzujete svoje pod-y, v akom mno\u017estve a ako ich aktualizova\u0165. <\/p>\n

          Tret\u00edm pojmom je service<\/b>. V\u00e1\u0161 service je fakticky v\u00e1\u0161 syst\u00e9m, ktor\u00fd prij\u00edma ur\u010dit\u00fd traffic a potom ho smeruje na jeden alebo viac podov, ktor\u00e9 zodpovedaj\u00fa v\u00e1\u0161mu service. T\u00fdm p\u00e1dom umo\u017e\u0148uje ur\u010di\u0165, \u017ee v\u0161etok prich\u00e1dzaj\u00faci traffic pre tak\u00fdto service s tak\u00fdmto menom by mal by\u0165 poslan\u00fd na konkr\u00e9tne tieto pod. A z\u00e1rove\u0148 zabezpe\u010duje vyrovn\u00e1vanie trafficu. To znamen\u00e1, \u017ee m\u00f4\u017eete spusti\u0165 dva pody v\u00e1\u0161ho aplik\u00e1cie a cel\u00fd prich\u00e1dzaj\u00faci traffic sa bude rovnomerne vyrovn\u00e1va\u0165 medzi podmi patriacimi k tomuto service.<\/p>\n

          A \u0161tvrt\u00fd hlavn\u00fd koncept \u2014 Ingress<\/b>. Je to service, ktor\u00fd sa sp\u00fa\u0161\u0165a v klastri Kubernetes. Vykon\u00e1va funkciu extern\u00e9ho vyrovn\u00e1va\u010da z\u00e1\u0165a\u017ee, ktor\u00fd preber\u00e1 v\u0161etky po\u017eiadavky. V\u010faka API Kubernetes Ingress m\u00f4\u017ee ur\u010di\u0165, kam by sa mali tieto po\u017eiadavky posla\u0165. A rob\u00ed to ve\u013emi flexibilne. M\u00f4\u017eete poveda\u0165, \u017ee v\u0161etky po\u017eiadavky na tento host a tak\u00fdto URL posielame na tento service. A tieto po\u017eiadavky, ktor\u00e9 prich\u00e1dzaj\u00fa na tento host a na in\u00fd URL, posielame na in\u00fd service. <\/p>\n

          Najcool za\u010do, kto vyv\u00edja aplik\u00e1ciu \u2014 je to, \u017ee m\u00f4\u017eete v\u0161etko spravova\u0165 samostatne. Nastaven\u00edm konfigur\u00e1cie Ingress m\u00f4\u017eete v\u0161etok traffic prich\u00e1dzaj\u00faci na tak\u00fdto API posiela\u0165 na samostatn\u00e9 kontajnery, nap\u00edsan\u00e9 napr\u00edklad na Go. A tento traffic, prich\u00e1dzaj\u00faci na ten ist\u00fd dom\u00e9nov\u00fd n\u00e1zov, ale na in\u00fd URL, posiela\u0165 na kontajnery, nap\u00edsan\u00e9 v PHP, kde je ve\u013ea logiky, ale nie s\u00fa a\u017e tak r\u00fdchle.<\/p>\n

          Ak porovn\u00e1me v\u0161etky tieto pojmy s Nomad, m\u00f4\u017eeme poveda\u0165, \u017ee prv\u00e9 tri pojmy \u2014 to v\u0161etko spolu tvor\u00ed Service. A posledn\u00fd pojem v Nomade ch\u00fdba. Ako jeho ekvivalent sme pou\u017e\u00edvali extern\u00fd vyrovn\u00e1va\u010d: m\u00f4\u017ee to by\u0165 haproxy, nginx, nginx+ a tak \u010falej. V pr\u00edpade kubu nemus\u00edte zav\u00e1dza\u0165 toto dodato\u010dn\u00e9 pojem osobitne. Av\u0161ak, ak sa pozrieme na Ingress vo vn\u00fatri, tak to je bu\u010f nginx, alebo haproxy, alebo traefik, ale akoby zabudovan\u00e9 v Kubernetes. <\/p>\n

          V\u0161etky mnou pop\u00edsan\u00e9 pojmy s\u00fa v podstate zdroje, ktor\u00e9 existuj\u00fa vn\u00fatri klastra Kubernetes. Na ich popis v kube sa pou\u017e\u00edva yaml form\u00e1t, ktor\u00fd je \u010ditate\u013enej\u0161\u00ed a zn\u00e1mys\u00ed ako HCL s\u00fabory v pr\u00edpade Nomad. Ale \u0161truktur\u00e1lne popisuj\u00fa v pr\u00edpade, napr\u00edklad, podu to ist\u00e9. Hovoria \u2014 chcem nasadi\u0165 tak\u00e9to pody tamto, s tak\u00fdmi imagami, v takomto mno\u017estve. <\/p>\n

          \"Nasadenie
          \n
          \nOkrem toho sme si uvedomili, \u017ee nechceme ru\u010dne vytv\u00e1ra\u0165 ka\u017ed\u00fa jednotliv\u00fa zlo\u017eku: deployment, slu\u017eby, Ingress a podobne. Namiesto toho sme chceli pri nasaden\u00ed pop\u00edsa\u0165 ka\u017ed\u00fd syst\u00e9m, ktor\u00fd m\u00e1me, v pojmoch Kubernetes, aby sme nemuseli ru\u010dne znova vytv\u00e1ra\u0165 v\u0161etky potrebn\u00e9 z\u00e1vislosti v spr\u00e1vnom porad\u00ed. Ako tak\u00fd syst\u00e9m, ktor\u00fd n\u00e1m to umo\u017enil, bol vybran\u00fd Helm. <\/p>\n

          Z\u00e1kladn\u00e9 pojmy v Helme<\/h1>\n

          \nHelm je spr\u00e1vca bal\u00edkov<\/b> pre Kubernetes. Je ve\u013emi podobn\u00fd tomu, ako funguj\u00fa spr\u00e1vcovia bal\u00edkov v programovac\u00edch jazykoch. Umo\u017e\u0148uj\u00fa v\u00e1m uchov\u00e1va\u0165 slu\u017ebu, ktor\u00e1 sa sklad\u00e1 napr\u00edklad z deployment nginx, deployment php-fpm, konfigur\u00e1cie pre Ingress, configmaps (to je entita, ktor\u00e1 v\u00e1m umo\u017e\u0148uje nastavi\u0165 env a \u010fal\u0161ie parametre pre v\u00e1\u0161 syst\u00e9m) vo forme tzv. chartov. Helm funguje nad Kubernetes<\/b>. To znamen\u00e1, \u017ee to nie je nejak\u00fd syst\u00e9m, ktor\u00fd stoj\u00ed bokom, ale jednoducho e\u0161te jedna slu\u017eba spusten\u00e1 vo vn\u00fatri klastru. Interagujete s n\u00edm cez jeho API pomocou pr\u00edkazov\u00e9ho rozhrania. Jeho pohodlie a kr\u00e1sa spo\u010d\u00edva v tom, \u017ee aj ke\u010f helm prestane fungova\u0165 alebo ho odstr\u00e1nite z klastru, va\u0161e slu\u017eby nezmizn\u00fa, preto\u017ee helm v podstate sl\u00fa\u017ei len na spustenie syst\u00e9mu. Za funk\u010dnos\u0165 a stav slu\u017eieb n\u00e1sledne zodpoved\u00e1 samotn\u00fd Kubernetes. <\/p>\n

          Tie\u017e sme si uvedomili, \u017ee \u0161abloniz\u00e1cia<\/b>, ktor\u00fa sme predt\u00fdm museli robi\u0165 sami prostredn\u00edctvom implement\u00e1cie jinja do na\u0161ich konfigur\u00e1ci\u00ed, je jednou z hlavn\u00fdch mo\u017enost\u00ed helmu. V\u0161etky konfigur\u00e1cie, ktor\u00e9 vytv\u00e1rate pre svoje syst\u00e9my, s\u00fa ulo\u017een\u00e9 v helme vo forme \u0161abl\u00f3n, ktor\u00e9 s\u00fa trochu podobn\u00e9 jinja, ale v skuto\u010dnosti pou\u017e\u00edvaj\u00fa \u0161abloniz\u00e1ciu programovacieho jazyka Go, v ktorom je helm nap\u00edsan\u00fd, rovnako ako Kubernetes. <\/p>\n

          Helm n\u00e1m prid\u00e1va e\u0161te nieko\u013eko \u010fal\u0161\u00edch pojmov. <\/p>\n

          Chart<\/b> je popis va\u0161ej slu\u017eby. V in\u00fdch spr\u00e1vcovsk\u00fdch bal\u00edkoch by sa nazval bal\u00edk, bundle alebo nie\u010do podobn\u00e9. Tu sa to naz\u00fdva chart. <\/p>\n

          Values <\/b>s\u00fa premenn\u00e9, ktor\u00e9 chcete pou\u017ei\u0165 na zostavenie svojich konfigur\u00e1ci\u00ed zo \u0161abl\u00f3n. <\/p>\n

          Verzia<\/b>. Ka\u017ed\u00fd raz, ke\u010f sa slu\u017eba nasadzuje pomocou helm, z\u00edska inkrement\u00e1lnu verziu uvo\u013enenia. Helm si pam\u00e4t\u00e1, ak\u00e1 bola konfigur\u00e1cia slu\u017eby pri predch\u00e1dzaj\u00facom, predpredch\u00e1dzaj\u00facom uvo\u013enen\u00ed a tak \u010falej. Preto, ak je potrebn\u00e9 sa vr\u00e1ti\u0165 sp\u00e4\u0165, sta\u010d\u00ed vykona\u0165 pr\u00edkaz helm callback s uveden\u00edm predch\u00e1dzaj\u00facej verzie uvo\u013enenia. Aj ke\u010f v okamihu n\u00e1vratu nemus\u00ed by\u0165 pr\u00edslu\u0161n\u00e1 konfigur\u00e1cia vo va\u0161om repozit\u00e1ri dostupn\u00e1, helm si aj tak pam\u00e4t\u00e1, ak\u00e1 bola, a vr\u00e1ti v\u00e1\u0161 syst\u00e9m do stavu, v akom bol pri predch\u00e1dzaj\u00facom uvo\u013enen\u00ed. <\/p>\n

          V pr\u00edpade, \u017ee pou\u017e\u00edvame helm, sa be\u017en\u00e9 konfigur\u00e1cie pre Kubernetes tie\u017e menia na \u0161abl\u00f3ny, v ktor\u00fdch je mo\u017en\u00e9 pou\u017e\u00edva\u0165 premenn\u00e9, funkcie a aplikova\u0165 podmiene\u010dn\u00e9 oper\u00e1tory. Takto m\u00f4\u017eete zostavi\u0165 konfigur\u00e1ciu va\u0161ej slu\u017eby v z\u00e1vislosti od prostredia.<\/p>\n

          \"Nasadenie
          \n
          \nV praxi sme sa rozhodli postupova\u0165 trochu inak, ne\u017e sme robili pri Nomad. Ak v Nomad v jednom repozit\u00e1ri boli ulo\u017een\u00e9 aj konfigur\u00e1cie pre nasadenie, aj n-premenn\u00e9 potrebn\u00e9 na nasadenie na\u0161ej slu\u017eby, tu sme sa rozhodli ich rozdeli\u0165 na dva samostatn\u00e9 repozit\u00e1re. V repozit\u00e1ri \u201edeploy\u201c sa ukladaj\u00fa iba n-premenn\u00e9 potrebn\u00e9 na nasadenie, zatia\u013e \u010do v repozit\u00e1ri \u201ehelm\u201c sa uchov\u00e1vaj\u00fa konfigur\u00e1cie alebo grafy.<\/p>\n

          \"Nasadenie
          \n
          \n\u010co n\u00e1m to dalo? <\/p>\n

          Napriek tomu, \u017ee v samotn\u00fdch konfigura\u010dn\u00fdch s\u00faboroch neuchov\u00e1vame skuto\u010dne citliv\u00e9 \u00fadaje. Napr\u00edklad, hesl\u00e1 k datab\u00e1zam. Tieto s\u00fa uchov\u00e1van\u00e9 vo forme secrets v Kubernetes, ale predsa len existuj\u00fa jednotliv\u00e9 veci, k ktor\u00fdm nechceme poskytova\u0165 pr\u00edstup v\u0161etk\u00fdm. Preto je pr\u00edstup k repozit\u00e1ru \u201edeploy\u201c obmedzenej\u0161\u00ed, zatia\u013e \u010do repozit\u00e1r \u201ehelm\u201c obsahuje iba popis slu\u017eby. Z tohto d\u00f4vodu je mo\u017en\u00e9 mu bezpe\u010dne poskytova\u0165 pr\u00edstup \u0161ir\u0161iemu okruhu os\u00f4b. <\/p>\n

          Ke\u010f\u017ee m\u00e1me nielen produkciu, ale aj in\u00e9 prostredia, v\u010faka tak\u00e9muto rozdeleniu m\u00f4\u017eeme znovu pou\u017e\u00edva\u0165 na\u0161e helm-grafy na nasadenie slu\u017eieb nielen do produkcie, ale aj napr\u00edklad do prostredia QA. Dokonca aj na to, aby sme ich nasadili lok\u00e1lne, pou\u017e\u00edvaj\u00fac Minikube<\/i> \u2014 to je vec na lok\u00e1lne spustenie Kubernetes. <\/p>\n

          V ka\u017edom repozit\u00e1ri sme ponechali rozdelenie na samostatn\u00e9 adres\u00e1re pre ka\u017ed\u00fa slu\u017ebu. To znamen\u00e1, \u017ee v ka\u017edom adres\u00e1ri sa nach\u00e1dzaj\u00fa \u0161abl\u00f3ny, ktor\u00e9 sa t\u00fdkaj\u00fa pr\u00edslu\u0161n\u00e9ho chartu a popisuj\u00fa zdroje, ktor\u00e9 je potrebn\u00e9 nasadi\u0165 na spustenie n\u00e1\u0161ho syst\u00e9mu. V repozit\u00e1ri \u201edeploy\u201c sme ponechali len envy. V tomto pr\u00edpade sme nepou\u017eili \u0161abloniz\u00e1ciu pomocou jinja, preto\u017ee helm s\u00e1m poskytuje \u0161abloniz\u00e1ciu priamo \u2013 to je jedna z jeho z\u00e1kladn\u00fdch funkci\u00ed. <\/p>\n

          Ponechali sme skript na nasadenie \u2013 deploy.sh, ktor\u00fd u\u013eah\u010duje a \u0161tandardizuje spustenie nasadenia pomocou helmu. Tak\u017ee pre ka\u017ed\u00e9ho, kto chce nasadi\u0165, vyzer\u00e1 rozhranie nasadenia presne tak, ako to bolo pri nasaden\u00ed cez Nomad. Ten ist\u00fd deploy.sh, n\u00e1zov va\u0161ej slu\u017eby a miesto, kam chcete, aby bola nasaden\u00e1. To vedie k tomu, \u017ee sa spust\u00ed helm. Ten n\u00e1sledne zhroma\u017e\u010fuje konfigur\u00e1cie zo \u0161abl\u00f3n, vklad\u00e1 do nich potrebn\u00e9 values-s\u00fabory, a potom nasad\u00ed, posielaj\u00fac ich do Kubernetes. <\/p>\n

          Zhrnutie<\/h1>\n

          \nSlu\u017eba Kubernetes vyzer\u00e1 zlo\u017eitej\u0161ie ako Nomad. <\/p>\n

          \"Nasadenie
          \n
          \nTu prich\u00e1dza odch\u00e1dzaj\u00faci trafik do Ingressu. To je frontov\u00fd kontrol\u00e9r, ktor\u00fd prij\u00edma v\u0161etky po\u017eiadavky a n\u00e1sledne ich posiela do pr\u00edslu\u0161n\u00fdch slu\u017eieb na z\u00e1klade danej po\u017eiadavky. Ur\u010duje ich na z\u00e1klade konfigur\u00e1ci\u00ed, ktor\u00e9 s\u00fa s\u00fa\u010das\u0165ou popisu va\u0161ej aplik\u00e1cie v helme a ktor\u00e9 si v\u00fdvoj\u00e1ri nastavuj\u00fa sami. Slu\u017eba potom posiela po\u017eiadavky na svoje pod, teda konkr\u00e9tne kontejnery, vyva\u017euj\u00fac prich\u00e1dzaj\u00faci trafik medzi v\u0161etk\u00fdmi kontajnermi, ktor\u00e9 sa t\u00fdkaj\u00fa danej slu\u017eby. A samozrejme, nemali by sme zab\u00fada\u0165 na to, \u017ee na \u00farovni siete, by sme nemali nikam odch\u00e1dza\u0165 od bezpe\u010dnosti. Preto v klastre Kubernetes funguje segment\u00e1cia, ktor\u00e1 je zalo\u017een\u00e1 na ozna\u010dovan\u00ed. V\u0161etky slu\u017eby maj\u00fa ur\u010dit\u00e9 ozna\u010denia, ku ktor\u00fdm s\u00fa viazan\u00e9 pr\u00e1va pr\u00edstupu slu\u017eieb k t\u00fdm alebo on\u00fdm extern\u00fdm\/vn\u00fatorn\u00fdm zdrojom vo vn\u00fatri alebo mimo klastra. <\/p>\n

          Pri prechode sme zistili, \u017ee Kubernetes m\u00e1 v\u0161etky funkcie, ktor\u00e9 mal Nomad, ktor\u00fd sme predt\u00fdm pou\u017e\u00edvali, a prid\u00e1va mnoho nov\u00e9ho. M\u00f4\u017ee sa roz\u0161irova\u0165 cez pluginy a v skuto\u010dnosti aj prostredn\u00edctvom vlastn\u00fdch typov zdrojov. To znamen\u00e1, \u017ee m\u00e1te mo\u017enos\u0165 nielen pou\u017e\u00edva\u0165 nie\u010do, \u010do je v Kubernetes zabudovan\u00e9, ale aj vytvori\u0165 vlastn\u00fd zdroj a slu\u017ebu, ktor\u00e1 bude tento zdroj \u010d\u00edta\u0165. To poskytuje dodato\u010dn\u00e9 mo\u017enosti roz\u0161\u00edrenia va\u0161ej syst\u00e9mu bez potreby prein\u0161talovania Kubernetes a bez nutnosti zmien. <\/p>\n

          Pr\u00edkladom tak\u00e9ho vyu\u017eitia je Prometheus, ktor\u00fd be\u017e\u00ed u n\u00e1s v klasttri Kubernetes. Aby za\u010dal zbiera\u0165 metriky z r\u00f4znej slu\u017eby, mus\u00edme prida\u0165 do popisu slu\u017eby \u010fal\u0161\u00ed typ zdroja, takzvan\u00fd service-monitor. V\u010faka tomu, \u017ee Prometheus dok\u00e1\u017ee \u010d\u00edta\u0165 vlastn\u00e9 typy zdrojov, ke\u010f be\u017e\u00ed v Kubernetes, automaticky za\u010d\u00edna zbiera\u0165 metriky z nov\u00e9ho syst\u00e9mu. Je to ve\u013emi praktick\u00e9. <\/p>\n

          Prv\u00e9 nasadenie, ktor\u00e9 sme urobili v Kubernetes, bolo v marci 2018. A od tej doby sme s n\u00edm nikdy nemali \u017eiadne probl\u00e9my. Funguje celkom stabilne bez podstatn\u00fdch ch\u00fdb. Okrem toho ho m\u00f4\u017eeme \u010falej roz\u0161irova\u0165. V s\u00fa\u010dasnosti n\u00e1m sta\u010dia mo\u017enosti, ktor\u00e9 obsahuje, a ve\u013emi sa n\u00e1m p\u00e1\u010dia tempo rozvoja Kubernetes. Moment\u00e1lne je v Kubernetes viac ako 3000 kontajnerov. Klaster sa sklad\u00e1 z nieko\u013ek\u00fdch uzlov. Je pritom spravovan\u00fd, stabiln\u00fd a ve\u013emi kontrolovate\u013en\u00fd.
          \n
          Zdroj:           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nasadenie aplik\u00e1ci\u00ed vo VM, Nomad a Kubernetes | ProHoster","description":"Ahojte! Vol\u00e1m sa Pavel Agaletky. Pracujem ako t\u00edmov\u00fd l\u00edder v t\u00edme, ktor\u00fd vyv\u00edja doru\u010dovaciu syst\u00e9m Lamoda.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u043f\u043b\u043e\u0439 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 VM, Nomad \u0438 Kubernetes | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:53:58+00:00","article:modified_time":"2019-10-31T18:53:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33654","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:38:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:36:34","updated":"2026-02-08 20:38:40","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}