{"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\/sl\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"Dejstvo aplikacij v VM, Nomad in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozdravljeni vsi! Ime mi je Pavel Agaletki. Delam kot vodja ekipe, ki razvija sistem dostave Lamoda. Leta 2018 sem nastopil na konferenci HighLoad++, danes pa \u017eelim predstaviti transkripcijo svojega predavanja.<\/p>\n

Moja tema se osredoto\u010da na izku\u0161nje na\u0161e podjetja pri uvajanju sistemov in storitev v razli\u010dna okolja. Za\u010deli smo v na\u0161ih zgodovinskih \u010dasih, ko smo vse sisteme uvajali na navadne virtualne stre\u017enike, in kon\u010dali s postopnim prehodom od Nomada do uvajanja v Kubernetes. Povedal bom, zakaj smo to storili in s kak\u0161nimi te\u017eavami smo se sre\u010dali v postopku.<\/p>\n

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

Uvajanje aplikacij na VM<\/h1>\n

\nZa\u010dnimo s tem, da so pred 3 leti vsi sistemi in storitve podjetja uvajali na navadne virtualne stre\u017enike. Tehni\u010dno je bilo organizirano tako, da je bil celoten kodo na\u0161ih sistemov shranjen in sestavljen s pomo\u010djo avtomatiziranega zbiranja preko Jenkins. S pomo\u010djo Ansible se je ta koda iz na\u0161ega sistema za nadzor razli\u010dic prenesla na virtualne stre\u017enike. Vsak sistem v na\u0161em podjetju se je uvajal na vsaj 2 stre\u017enika: eden je bil head, drugi pa tail. Ta dva sistema sta bila med seboj povsem enaka po vseh nastavitvah, zmogljivosti, konfiguraciji in drugem. Razlika med njima je bila le ta, da je head prejemal uporabni\u0161ki promet, medtem ko tail nikoli ni prejemal prometa uporabnikov. <\/p>\n

Zakaj je bilo to narejeno? <\/p>\n

Ko smo uvajali nove razli\u010dice na\u0161e aplikacije, smo \u017eeleli zagotoviti mo\u017enost brez\u0161ivnega uvajanja, torej brez opaznih posledic za uporabnike. To smo dosegli tako, da se je nova zgrajena razli\u010dica s pomo\u010djo Ansible prenesla na tail. Tam so ljudje, ki so se ukvarjali z uvajanjem, lahko preverili in se prepri\u010dali, da je vse v redu: vse metrike, razdelki in aplikacije delujejo; zagnani so potrebni skripti. \u0160ele potem, ko so se prepri\u010dali, da je vse v redu, se je promet preusmeril. Za\u010del se je usmerjati na tisti stre\u017enik, ki je bil prej tail. Tisti, ki je bil prej head, pa je ostal brez uporabni\u0161kega prometa, vendar z obstoje\u010do prej\u0161njo razli\u010dico na\u0161e aplikacije.<\/p>\n

Tako so uporabnikom omogo\u010dili neprekinjeno izku\u0161njo. Preklop se zgodi takoj, saj gre preprosto za preklop balancerja. Zelo enostavno se lahko vrnete na prej\u0161njo razli\u010dico, tako da preklopite balancer nazaj. Prav tako smo lahko preverili zmogljivost aplikacije v produkciji \u0161e pred prihodom uporabni\u0161kega prometa, kar je bilo zelo priro\u010dno. <\/p>\n

Kak\u0161ne prednosti smo videli v vsem tem?<\/p>\n

    \n
  1. Predvsem to je zadostno enostavno deluje.<\/b> Vsem je jasno, kako deluje taka shema uvajanja, ker je ve\u010dina ljudi kdaj koli izvajala uvajanje na obi\u010dajne virtualne stre\u017enike.<\/li>\n
  2. To je zadostno zanesljivo<\/b>, saj je tehnologija uvajanja preprosta in jo je preizkusilo na tiso\u010de podjetij. Milijoni stre\u017enikov se uvajajo na ta na\u010din. Te\u017eko je kaj pokvariti. <\/li>\n
  3. In kon\u010dno, lahko smo dobili atomska uvajanja<\/b>. Uvajanja, ki se za uporabnike zgodijo takoj, brez opaznega preklapljanja med staro in novo razli\u010dico. <\/li>\n<\/ol>\n

    \nToda v vsem tem smo prav tako opazili nekaj slabosti: <\/p>\n

      \n
    1. Poleg produkcijskega okolja in okolja za razvoj obstajajo tudi druga okolja. Na primer, qa in predprodukcija. Takrat smo imeli veliko stre\u017enikov in pribli\u017eno 60 storitev. Zaradi tega smo morali za vsako storitev ohranjati ustrezno razli\u010dico <\/b>virtualnega stroja. \u010ce \u017eelite posodobiti knji\u017enice ali namestiti nove odvisnosti, to morate narediti v vseh okoljih. Prav tako je treba sinhronizirati \u010das, ko nameravate uvajati novo razli\u010dico va\u0161e aplikacije, s \u010dasom, ko devops izvede potrebne nastavitve okolja. V tem primeru je zlahka priti v situacijo, kjer se okolje nekoliko razlikuje v vseh okoljih zaporedoma. Na primer, v okolju QA bodo razli\u010dne razli\u010dice knji\u017enic, v produkciji pa druge, kar lahko povzro\u010di te\u017eave. <\/li>\n
    2. Zapletenost pri posodabljanju odvisnosti<\/b> va\u0161e aplikacije. To ne gre od vas, temve\u010d od druge ekipe. Natan\u010dneje, ekipe devops, ki vzdr\u017euje stre\u017enike. Morate jim postaviti ustrezno nalogo in dati opis, kaj \u017eelite storiti.<\/li>\n
    3. Takrat smo tudi \u017eeleli razdeliti velike monolite, ki smo jih imeli, na posamezne majhne storitve, saj smo razumeli, da jih bo vedno ve\u010d. Takrat smo jih imeli \u017ee ve\u010d kot 100. Za vsako novo storitev je bilo potrebno ustvariti novo virtualno napravo, ki jo je bilo treba vzdr\u017eevati in implementirati. Poleg tega potrebujemo ve\u010d kot eno napravo, vsaj dve. Vse skupaj se \u0161e dodaja QA okolje. To povzro\u010da te\u017eave in ote\u017euje ustvarjanje in zagon novih sistemov. To je zapleten, drag in dolgotrajen postopek.<\/b><\/li>\n<\/ol>\n

      \nZato smo se odlo\u010dili, da bo bolj priro\u010dno preiti z uvajanja obi\u010dajnih virtualnih naprav na uvajanje na\u0161ih aplikacij v Docker vsebniku. Pri uporabi Dockera potrebujemo sistem, ki lahko za\u017eene aplikacijo v grozdu, saj le tako ne morete preprosto zagnati vsebnika. Obi\u010dajno \u017eelimo spremljati, koliko vsebnikov je aktiviranih, da se lahko samodejno za\u017eenejo. Iz tega razloga smo potrebovali sistem za upravljanje. <\/p>\n

      Dolgo smo razmi\u0161ljali, katero izmed njih izbrati. V tistem trenutku je bil na\u0161 sistem uvajanja na obi\u010dajne virtualne stre\u017enike nekoliko zastaran, saj so tam bile starej\u0161e razli\u010dice operacijskih sistemov. V nekem trenutku je bila celo FreeBSD, ki je bila te\u017eko vzdr\u017eevati. Zavedali smo se, da moramo \u010dim prej migrirati v Docker. Na\u0161i DevOps strokovnjaki so prou\u010dili svoje izku\u0161nje z razli\u010dnimi re\u0161itvami in izbrali sistem Nomad. <\/p>\n

      Prehod na Nomad<\/h1>\n

      \nNomad je izdelek podjetja HashiCorp. Znani so tudi po svojih drugih re\u0161itvah:<\/p>\n

      \"Dejstvo
      \n
      \n\u201eConsul\u201c<\/b> \u2014 to je orodje za odkrivanje storitev.<\/p>\n

      \u201eTerraform\u201c<\/b> \u2014 sistem za upravljanje stre\u017enikov, ki vam omogo\u010da, da jih konfigurirate prek infrastrukture kot kode.<\/p>\n

      \u201eVagrant\u201c<\/b> omogo\u010da pritrditev virtualnih naprav lokalno ali v oblaku s pomo\u010djo dolo\u010denih konfiguracijskih datotek. <\/p>\n

      Nomad se je tisti trenutek zdel dovolj preprost sistem, na katerega bi se lahko hitro preusmerili brez spremembe celotne infrastrukture. Prav tako je precej enostaven za obvladovanje. Zato smo ga izbrali kot sistem za filtriranje na\u0161ega vsebnika. <\/p>\n

      Kaj potrebujete za uvajanje va\u0161ega sistema v Nomad? <\/p>\n

        \n
      1. Najprej potrebujete docker sliko<\/b> va\u0161ega aplikacije. Potrebno jo je zbrati in shraniti v shranjevanje slik Docker. V na\u0161em primeru je to artifactory \u2014 tak\u0161na sistem, ki omogo\u010da nalaganje razli\u010dnih artefaktov razli\u010dnih tipov. Shranjuje lahko arhive, slike Docker, pakete Composer PHP, NPM pakete itd. <\/li>\n
      2. Poleg tega je potrebno konfiguracijska datoteka<\/b>, ki bo povedala Nomadu, kaj, kam in v kak\u0161ni koli\u010dini \u017eelite implementirati. <\/li>\n<\/ol>\n

        \nKo govorimo o Nomadu, kot format informacijskega dokumenta uporablja jezik HCL, kar pomeni HashiCorp Configuration Language<\/i>. To je nadmno\u017eica YAML, ki vam omogo\u010da, da opi\u0161ete svojo storitev v izrazih Nomada. <\/p>\n

        \"Dejstvo
        \n
        \nOmogo\u010da vam, da dolo\u010dite, koliko vsebnikov \u017eelite implementirati, iz katerih slik jih \u017eelite prenesti ter razli\u010dne parametre pri implementaciji. Tako posredujete to datoteko Nomadu, on pa spro\u017ei vsebnike v produkciji v skladu z njo. <\/p>\n

        V na\u0161em primeru smo ugotovili, da bi bilo neprakti\u010dno pisati enake identi\u010dne HCL datoteke za vsako storitev, saj imamo veliko storitev in jih ob\u010dasno \u017eelimo posodobiti. Zgodi se, da ena storitev ni implementirana v eni kopiji, temve\u010d v razli\u010dnih. Na primer, enega od sistemov, ki ga imamo v produkciji, upravlja ve\u010d kot 100 instanc v produkciji. Ti se zagnajo iz istih slik, vendar se razlikujejo po konfiguracijskih nastavitvah in konfiguracijskih datotekah. <\/p>\n

        Zato smo se odlo\u010dili, da bo priro\u010dno shraniti vse na\u0161e konfiguracijske datoteke za implementacijo v enem skupnem repozitoriju. Tako so postale pregledne: lahko jih je bilo enostavno vzdr\u017eevati in videli smo, kateri sistemi imamo. V primeru potrebe je tudi enostavno kar koli posodobiti ali spremeniti. Dodati nov sistem tudi ne bo te\u017eko \u2014 dovolj je le ustvariti konfiguracijsko datoteko znotraj nove mape. Znotraj nje se nahajajo datoteke: service.hcl, ki vsebuje opis na\u0161e storitve, in nekatere env-datoteke, ki omogo\u010dajo, da to storitev ob implementaciji v produkcijo ustrezno nastavite. <\/p>\n

        \"Dejstvo
        \n
        \nVendar so nekatere na\u0161e storitve implementirane v produkciji ne v eni kopiji, temve\u010d hkrati v ve\u010d. Zato smo se odlo\u010dili, da bo prakti\u010dno shraniti ne konfiguracije v \u010disti obliki, ampak njihov \u0161abloniziran videz. Kot jezik za \u0161ablonizacijo smo izbrali jinja 2<\/i>. V tem formatu imamo shranjene tako konfiguracije same storitve kot tudi env-datoteke, ki jih potrebuje. <\/p>\n

        Poleg tega smo v repozitorij dodali skupen skript za namestitev, ki omogo\u010da zagon in namestitev va\u0161e storitve v produkcijo, v ustrezen okolje in cilj. Ko smo na\u0161 HCL-config pretvorili v predlogo, je ta HCL-datoteka, ki je prej bila obi\u010dajen Nomad config, v tem primeru izgledala nekoliko druga\u010de.<\/p>\n

        \"Dejstvo
        \n
        \nTo pomeni, da smo nekaj mest v konfiguraciji zamenjali z variablami, ki jih dobimo iz env-datotek ali drugih virov. Poleg tega smo pridobili mo\u017enost dinami\u010dnega sestavljanja HCL-datotek, torej lahko uporabljamo ne le obi\u010dajne vstavke variabl. Ker jinja podpira zanke in pogoje, lahko tam oblikujemo konfiguracijske datoteke, ki se spreminjajo glede na to, kam dejansko name\u0161\u010date svoje aplikacije. <\/p>\n

        Na primer, \u017eelite namestiti svojo storitev v preprodukcijo in v produkcijo. Recimo, da v preprodukciji ne \u017eelite zagnati cron-skriptov, ampak preprosto \u017eelite videti storitev na lo\u010deni domeni, da se prepri\u010date, da deluje. Za kogarkoli, ki namesti storitev, je postopek zelo enostaven in pregleden. Zadostuje, da izvedete datoteko deploy.sh, navedete, katero storitev \u017eelite namestiti in v kateri cilj. Na primer, \u010de \u017eelite namestiti neko sistem v Rusijo, Belorusijo ali Kazahstan. Za to je dovolj, da spremenite enega od parametrov, in pravilna konfiguracijska datoteka se bo sestavila. <\/p>\n

        Ko je storitev Nomad \u017ee name\u0161\u010dena v va\u0161em klastru, izgleda takole.<\/p>\n

        \"Dejstvo
        \n
        \nNajprej potrebujete nek zunanji uravnote\u017eevalec, ki bo sprejemal ves uporabni\u0161ki promet. Deloval bo skupaj s Consulom in od njega pridobil informacijo o tem, kje, na katerem vozli\u0161\u010du in po kak\u0161nem IP adresom<\/a> se nahaja dolo\u010dena storitev, ki ustreza dolo\u010denemu imenu domene. Storitve v Consulu se pojavijo iz samega Nomada. Ker gre za izdelke iste podjetja, so dobro povezani med seboj. Lahko bi rekli, da Nomad privzeto zna registrirati vse storitve, ki jih za\u017eene, znotraj Consula. <\/p>\n

        Ko se va\u0161 zunanji balansirnik nau\u010di, kam je treba usmeriti promet, ga preusmeri v ustrezen zabojnik ali ve\u010d zabojnikov, ki ustrezajo va\u0161i aplikaciji. Seveda je treba pri tem razmi\u0161ljati tudi o varnosti. Tudi \u010de se vsi storitve izvajajo na istih virtualnih strojih v zabojnikih, je obi\u010dajno potrebno prepovedati prost dostop katere koli storitve do katere koli druge. To smo dosegli s segmentacijo. Vsaka storitev je bila izvajana v svoji virtualni mre\u017ei, na kateri so bile dolo\u010dene smernice za usmerjanje in pravila za dovoljenje\/ prepoved dostopa do drugih sistemov in storitev. Teh sistemov in storitev je lahko bilo bodisi znotraj tega grozda bodisi zunaj njega. Na primer, \u010de \u017eelite prepovedati storitvi povezovanje z dolo\u010deno bazo podatkov, to lahko storite preko segmentacije na ravni mre\u017ee. To pomeni, da se niti po pomoti ne morete povezati iz testnega okolja z va\u0161o produkcijsko bazo.<\/p>\n

        Koliko \u010dlove\u0161kih virov nas je stala ta preklop? <\/p>\n

        Prehod celotne dru\u017ebe na Nomad je trajal pribli\u017eno 5-6 mesecev. Prehajali smo storitveno, vendar v dovolj hitrem tempu. Vsaka ekipa je morala ustvariti svoje lastne zabojnike za storitve. <\/p>\n

        Imamo sprejet tak pristop, da vsaka ekipa sama odgovarja za docker slike svojih sistemov. DevOps pa zagotavlja skupno infrastrukturo, potrebno za distribucijo, torej podporo samega grozda, podporo CI-sistemom in tako naprej. In v tistem trenutku je ve\u010d kot 60 sistemov pre\u0161lo na Nomad, nastalo je okoli 2000 zabojnikov. <\/p>\n

        DevOps odgovarja za skupno infrastrukturo vsega, kar je povezano z distribucijo, s stre\u017eniki. Vsaka razvijalska ekipa pa je odgovorna za implementacijo zabojnikov za svoj specifi\u010dni sistem, saj ekipa najbolje ve, kaj sploh potrebuje v tem ali onem zabojniku.<\/p>\n

        Razlogi za opustitev Nomada<\/h1>\n

        \nKak\u0161ne prednosti smo pridobili, ko smo pre\u0161li na distribucijo z Nomadom in dockerjem?<\/p>\n

          \n
        1. Mi zagotovili enake pogoje<\/b> za vse okolja. V razvoju, QA okolju, predprodukciji in produkciji se uporabljajo iste slike kontejnerjev z istimi odvisnostmi. Tako imate skoraj ni mo\u017enosti, da bi v produkciji pri\u0161lo nekaj drugega, kot ste prej testirali lokalno ali v testnem okolju. <\/li>\n
        2. Prav tako smo ugotovili, da je dovolj enostavno dodati novo storitev<\/b>. Katere koli nove sisteme z vidika namestitve je zelo enostavno zagnati. Zado\u0161\u010da, da greste v repozitorij, ki shranjuje konfiguracije, dodate nov konfiguracijski file za va\u0161 sistem in vse je pripravljeno. Svojo storitev lahko namestite v produkcijo brez dodatnih naporov s strani DevOps. <\/li>\n
        3. Vse konfiguracijske datoteke<\/b> v enem skupnem repozitoriju so bile pregledane<\/b>. V trenutku, ko smo name\u0161\u010dali na\u0161e sisteme z uporabo virtu\u00e1ln\u00edch server\u016f<\/a>, smo uporabljali Ansible, v katerem so bile konfiguracije shranjene v istem repozitoriju. Vendar je bilo za ve\u010dino razvijalcev delo s tem nekoliko bolj zapleteno. Obseg konfiguracij in kode, ki jo je bilo treba dodati za namestitev storitve, se je mo\u010dno zmanj\u0161al. Poleg tega je bilo za DevOps zelo enostavno popraviti ali spremeniti. V primeru prehodov, na primer, na novi razli\u010dici Nomad, so lahko mno\u017ei\u010dno posodobili vse operativne datoteke, ki le\u017eijo na istem mestu.<\/li>\n<\/ol>\n

          \nSoo\u010dili pa smo se tudi s \u0161tevilnimi pomanjkljivostmi: <\/p>\n

          Ugotovili smo, da nismo mogli dose\u010di brez\u0161ivnosti namestitev <\/b>v primeru Nomad. Pri uvajanju kontejnerjev iz razli\u010dnih okolij se lahko zgodi, da je bil kontejner zagnan in ga je Nomad zaznal kot pripravljenega za sprejem prometa. To se je zgodilo \u0161e preden se je aplikacija znotraj njega uspela zagnati. Zaradi tega je sistem za kratek \u010das za\u010del izdajati napake 500, ker je promet za\u010del priti na kontejner, ki \u0161e ni bil pripravljen za njegovo sprejemanje. <\/p>\n

          Soo\u010dili smo se z nekaterimi napakami<\/b>. Najsajtniji problem je u tome \u0161to Nomad nije ba\u0161 dobro osmi\u0161ljen za velike klastere, ako imate mnogo sistema i kontejnera. Kada \u017eelite da isklju\u010dite jedan od servera koji je deo Nomad klastera, postoji prili\u010dno velika verovatno\u0107a da \u0107e klaster reagovati lo\u0161e i raspasti se. Deo kontejnera mo\u017ee, na primer, pasti i ne podi\u0107i se \u2013 to \u0107e vam kasnije vrlo skupo ko\u0161tati, ako su svi va\u0161i sistemi u produkciji upravo u klasteru kojim upravlja Nomad. <\/p>\n

          Zato smo odlu\u010dili da razmislimo o tome kuda dalje. U tom trenutku smo postali mnogo svesniji onoga \u0161to \u017eelimo da postignemo. A to je: \u017eelimo pouzdanost, malo vi\u0161e funkcionalnosti nego \u0161to Nomad nudi, i zreliji, stabilniji sistem. <\/p>\n

          U tom smislu na\u0161 izbor je pao na Kubernetes kao najpopularniju platformu za pokretanje klastera. Pogotovo s obzirom na to da je veli\u010dina i broj na\u0161ih kontejnera bio prili\u010dno veliki. Za te svrhe Kubernetes se pokazao kao najprikladniji sistem me\u0111u onima koje smo mogli da razmotrimo. <\/p>\n

          Prelazak na Kubernetes<\/h1>\n

          \nMalo \u0107u govoriti o osnovnim pojmovima Kubernetes-a i kako se razlikuju od Nomad-a. <\/p>\n

          \"Dejstvo
          \n
          \nPre svega, osnovni pojam u Kubernetes-u je pojam pod. Pod<\/b> \u2013 to je grupa jednog ili vi\u0161e kontejnera koja se uvek pokre\u0107e zajedno. I rade kao da uvek strogo funkcioni\u0161u na jednoj virtuelnoj ma\u0161ini. Dostupni su jedni drugima putem IP adrese 127.0.0.1 na razli\u010ditim portovima. <\/p>\n

          Pretpostavimo da imate PHP aplikaciju koja se sastoji od nginx i php-fpm \u2013 klasi\u010dna shema. Verovatno \u0107ete \u017eeleti da i nginx i php-fpm kontejneri uvek budu zajedno. Kubernetes to omogu\u0107ava opisivanjem njih kao jednog zajedni\u010dkog poda. To je upravo ono \u0161to nismo mogli posti\u0107i uz pomo\u0107 Nomad-a.<\/p>\n

          Drugi pojam je deployment<\/b>. Naime, pod sam po sebi je efemerna stvar, pokre\u0107e se i nestaje. Da li \u017eelite prvo da ubijete sve prethodne kontejnere, a zatim da odmah pokrenete nove verzije, ili \u017eelite da ih pu\u0161tate postepeno \u2013 upravo za taj proces odgovara pojam deployment. On opisuje kako deploy-ujete svoje podele, u kojem broju i kako ih a\u017eurirati. <\/p>\n

          Tre\u0107i pojam je service<\/b>Va\u0161 service je v bistvu va\u0161 sistem, ki sprejema nek promet in ga nato usmerja na eno ali ve\u010d podov, povezanih z va\u0161im servisom. To pomeni, da omogo\u010da usmerjanje vsega prihajajo\u010dega prometa na dolo\u010den servis s to\u010dno dolo\u010denim imenom v te specifi\u010dne pode. Hkrati zagotavlja uravnote\u017eenje prometa. To pomeni, da lahko za\u017eenete dva poda va\u0161e aplikacije in bo ves prihajajo\u010di promet enakomerno uravnote\u017een med povezanimi podi tega servisa.<\/p>\n

          In \u010detrti osnovni koncept je Ingress<\/b>To je servis, ki se za\u017eene v Kubernetes klastru. Deluje kot zunanjega uravnote\u017eevalnika obremenitve, ki sprejema vse zahteve. S pomo\u010djo API-ja Kubernetes Ingress lahko dolo\u010di, kam je treba te zahteve usmeriti. In to po\u010dne zelo fleksibilno. Lahko re\u010dete, da vse zahteve za to gostiteljsko ime in tak URL po\u0161ljete na ta servis. Te zahteve, ki prihajajo na to gostiteljsko ime in drug URL, pa po\u0161ljete na drug servis. <\/p>\n

          Najbolj\u0161e z vidika razvijalca aplikacije je, da lahko vse to upravljate sami. Z nastavitvijo Ingress konfiguracije lahko celoten promet, ki prihaja na dolo\u010den API, usmerite na lo\u010dene kontejnere, npr. napisane v Go. Ta promet, ki prihaja na isto domeno, ampak na drug URL, pa usmerite na kontejnere, napisane v PHP, kjer je veliko logike, vendar niso zelo hitri.<\/p>\n

          \u010ce primerjamo vse te pojme z Nomad, lahko re\u010demo, da prvih treh pojmov ni mo\u017eno obravnavati lo\u010deno, saj skupaj sestavljajo Service. Zadnjega pojma v samem Nomadu ni. Za to smo uporabili zunanjega uravnote\u017eevalnika: to je lahko haproxy, nginx, nginx+ in tako naprej. Pri kubernetesu vam ni treba uvesti tega dodatnega pojma. Vendar, \u010de pogledate v notranjost Ingressa, je to bodisi nginx, bodisi haproxy, bodisi traefik, a vgrajeno v Kubernetes. <\/p>\n

          Vsa zgoraj opisana pojma so v bistvu viri, ki obstajajo znotraj Kubernetes klastru. Za njihovo opisovanje v kubernetesu se uporablja yaml-format, ki je bolj berljiv in znan kot HCL datoteke v primeru Nomada. Strukturalno pa opisujejo v primeru, na primer, poda enako. Pravijo - \u017eelim razporediti take pode tja, s tak\u0161nimi slikami, v tak\u0161ni koli\u010dini. <\/p>\n

          \"Dejstvo
          \n
          \nPoleg tega smo ugotovili, da ne \u017eelimo ro\u010dno ustvarjati vsakega posameznega vira: deployment, storitve, Ingress in podobno. Namesto tega smo \u017eeleli pri namestitvi opisati vsak na\u0161 sistem v pogojih Kubernetes, da nam ni treba ro\u010dno ponovno ustvarjati vseh potrebnih odvisnosti virov v pravem vrstnem redu. Kot tak\u0161en sistem, ki nam je omogo\u010dil to, smo izbrali Helm. <\/p>\n

          Osnovni pojmi v Helm<\/h1>\n

          \nHelm je paketni upravljalnik<\/b> za Kubernetes. Zelo je podoben delovanju paketnih upravljalnikov v programskih jezikih. Omogo\u010da vam shranjevanje storitve, ki se na primer sestoji iz deploymenta nginx, deploymenta php-fpm, konfiguracije za Ingress, configmaps (to je entiteta, ki vam omogo\u010da, da dolo\u010dite env in druge parametre za va\u0161 sistem) v obliki t.i. chartov. Pri tem Helm deluje nad Kubernetes<\/b>. Torej, to ni nek sistem, ki bi stal ob strani, ampak preprosto \u0161e ena storitev, ki se izvaja znotraj kupa. Z njim komunicirate preko njegovega API-ja preko konzolne ukazne vrstice. Njegova prednost in lepota je v tem, da celo, \u010de se helm pokvari ali ga izbri\u0161ete iz klasterja, va\u0161e storitve ne izginejo, saj helm slu\u017ei v bistvu le za zagon sistema. Za delovanje in stanje storitev naprej odgovarja sam Kubernetes. <\/p>\n

          Prav tako smo ugotovili, da templating<\/b>, ki smo ga prej morali izvajati sami z vklju\u010ditvijo jinja v na\u0161e konfiguracije, predstavlja eno od osnovnih funkcionalnosti helma. Vse konfiguracije, ki jih ustvarite za svoje sisteme, so shranjene v helm v obliki predlog, ki so nekoliko podobne jinja, vendar v resnici uporabljajo templating jezika Go, v katerem je helm napisan, kot tudi Kubernetes. <\/p>\n

          Helm nam dodaja \u0161e nekaj dodatnih pojmov. <\/p>\n

          Chart<\/b> \u2014 to je opis va\u0161e storitve. V drugih paketnih upravljalnikih bi ga imenovali paket, bundle ali kaj podobnega. Tukaj se imenuje chart. <\/p>\n

          Vrednosti <\/b>so spremenljivke, ki jih \u017eelite uporabiti za izdelavo va\u0161ih konfiguracij iz predlog. <\/p>\n

          Release<\/b>Vsakokrat, ko se storitev, ki jo namestimo s Helmom, posodobi, dobi inkrementalno razli\u010dico izpustitve. Helm si zapomni, kak\u0161na je bila konfiguracija storitve pri prej\u0161nji, predprej\u0161nji izpustitvi in tako naprej. Zato, \u010de je potrebno, se lahko preprosto vrnemo nazaj z ukazom helm rollback, ki mu dolo\u010dimo prej\u0161njo razli\u010dico izpustitve. Tudi \u010de v trenutku povratka ustrezna konfiguracija ni na voljo v va\u0161em repozitoriju, Helm vseeno ve, kak\u0161na je bila, in vrne va\u0161 sistem v stanje pred prej\u0161njo izpustitvijo. <\/p>\n

          V primeru, ko uporabljamo Helm, obi\u010dajne konfiguracije za Kubernetes postanejo tudi predloge, v katerih lahko uporabljamo spremenljivke, funkcije ter pogojne operatorje. Tako lahko sestavite konfiguracijo va\u0161e storitve glede na okolje.<\/p>\n

          \"Dejstvo
          \n
          \nNa prakti\u010dni ravni smo se odlo\u010dili malce druga\u010de kot pri Nomadu. Medtem ko smo v Nomadu shranjevali tako konfiguracije za namestitev kot n-spremenljivke, potrebne za namestitev na\u0161e storitve v enem istem repozitoriju, smo tu odlo\u010dili, da jih razdelimo na dva lo\u010dena repozitorija. V repozitoriju 'deploy' so shranjene zgolj n-spremenljivke, potrebne za namestitev, medtem ko so v repozitoriju 'helm' shranjene konfiguracije ali grafi.<\/p>\n

          \"Dejstvo
          \n
          \nKaj nam to prina\u0161a? <\/p>\n

          Kljub temu, da v samih konfiguracijskih datotekah ne shranjujemo dejansko ob\u010dutljivih podatkov, kot so gesla za podatkovne baze, ki jih hranimo kot secrets v Kubernetes, obstajajo kljub temu nekatere stvari, do katerih no\u010demo dati dostopa vsem. Zato je dostop do repozitorija 'deploy' bolj omejen, repozitorij 'helm' pa vsebuje zgolj opis storitve. Iz tega razloga lahko dostop do njega varno podelimo \u0161ir\u0161emu krogu posameznikov. <\/p>\n

          Ker imamo ne le produkcijsko okolje, temve\u010d tudi druge okolja, nam tak\u0161na razdelitev omogo\u010da ponovno uporabo na\u0161ih helm-grafov za namestitev storitev ne le v produkciji, temve\u010d tudi, na primer, v QA okolju. Tudi za lokalni razvoj uporabljamo. Minikube<\/i> \u2014 to je ta stvar za lokalno zagon Kubernetes. <\/p>\n

          Znotraj vsakega repozitorija smo ohranili lo\u010ditev na posamezne imenike za vsako storitev. To pomeni, da se znotraj vsakega imenika nahajajo predloge, ki se nana\u0161ajo na ustrezno shemo in opisujejo vire, ki jih je treba obdr\u017eati za zagon na\u0161ega sistema. V repozitoriju 'deploy' smo pustili samo envs. V tem primeru nismo uporabili predloge s pomo\u010djo jinja, ker helm sam ponuja predlaganje iz \u0161katle \u2013 to je ena njegovih osnovnih funkcij. <\/p>\n

          Pustili smo skripto za implementacijo \u2013 deploy.sh, ki poenostavi in standardizira zagon za implementacijo s pomo\u010djo helma. Tako za kogarkoli, ki \u017eeli izvesti implementacijo, vmesnik za implementacijo izgleda to\u010dno tako, kot je bil v primeru implementacije prek Nomada. Enaka deploy.sh, ime va\u0161e storitve in tja, kamor \u017eelite to implementirati. To pripelje do tega, da se znotraj za\u017eene helm. Ta nato zbere konfiguracije iz predlog, v njih vnese potrebne values-datoteke in nato izvede implementacijo, tako da jih po\u0161lje v Kubernetes. <\/p>\n

          Zaklju\u010dki<\/h1>\n

          \nStoritev Kubernetes se zdi bolj zapletena kot Nomad. <\/p>\n

          \"Dejstvo
          \n
          \nTukaj izhodni promet prihaja v Ingress. To je prednji kontroler, ki sprejema vse zahtevke in jih nato po\u0161ilja ustreznim storitvam, povezanih z zahtevkom. Dolo\u010da jih na podlagi konfiguracij, ki so del opisa va\u0161e aplikacije v helmu in ki jih dolo\u010dijo razvijalci sami. Storitev nato po\u0161ilja zahteve svojim podom, torej konkretnim vsebnim enotam, pri \u010demer uravnava prihajajo\u010di promet med vsemi vsebnimi enotami, ki se nana\u0161ajo na to storitev. In seveda ne smemo pozabiti na to, da na ravni omre\u017ene varnosti ne smemo nikamor odhajati. Zato v Kubernetes grozdu deluje segmentacija, ki se temelji na ozna\u010devanju. Vse storitve imajo dolo\u010dene oznake, s katerimi so povezane pravice dostopa storitev do dolo\u010denih zunanjih\/notranjih virov znotraj ali zunaj grozda. <\/p>\n

          Ko izvajamo prehod, smo opazili, da Kubernetes ponuja vse mo\u017enosti, ki jih je imel Nomad, ki smo ga uporabljali prej, ter dodaja \u0161tevilne nove funkcionalnosti. Razvijati ga je mogo\u010de preko vti\u010dnikov in dejansko preko prilagojenih tipov virov. To pomeni, da imate mo\u017enost ne le uporabljati tisto, kar je v Kubernetesu na voljo \u017ee privzeto, temve\u010d tudi ustvariti svoj lasten vir in storitev, ki bo brala ta vir. To omogo\u010da dodatne mo\u017enosti raz\u0161iritve va\u0161ega sistema brez potrebe po ponovni namestitvi Kubernetes in brez potrebnih sprememb. <\/p>\n

          Primer takega uporabljanja je Prometheus, ki se poganja znotraj na\u0161ega Kubernetes grozda. Da za\u010dne zbirati metrike z dolo\u010denih storitev, moramo v opis storitve dodati dodatno vrsto vira, imenovano servisni nadzornik. Prometheus zaradi svoje zmo\u017enosti branja, ko je zagnan v Kubernetesu, prilagojenih tipov virov, samodejno za\u010dne zbirati metrike iz novega sistema. To je precej priro\u010dno. <\/p>\n

          Prvi deployment, ki smo ga izvedli v Kubernetesu, je bil marca 2018. In v tem \u010dasu nikoli nismo imeli te\u017eav z njim. Deluje dovolj stabilno brez ve\u010djih napak. Poleg tega ga lahko \u0161e naprej razvijamo. Trenutno nam zado\u0161\u010dajo zmo\u017enosti, ki jih ima, in hitrost razvoja Kubernetes nam je zelo v\u0161e\u010d. Trenutno je v Kubernetesu ve\u010d kot 3000 kontejnerjev. Grozd zaseda ve\u010d vozli\u0161\u010d. Pri tem je dobro upravljan, stabilen in zelo obvladljiv.
          \n
          Izvor:           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\udd47Namestitev aplikacij v VM, Nomad in Kubernetes | ProHoster","description":"Pozdravljeni! Moje ime je Pavel Agaletski. Delam kot vodja ekipe, ki razvija sistem dostave Lamoda.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}