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

Pozdrav svima! Moje ime je Pavel Agalecki. Radim kao tim lider u timu koji razvija sustav dostave Lamoda. Godine 2018. sam govorio na konferenciji HighLoad++, a danas \u017eelim predstaviti transkript svog izlaganja.<\/p>\n

Moja tema se fokusira na iskustvo na\u0161e tvrtke u implementaciji sustava i usluga u razli\u010ditim okru\u017eenjima. Po\u010dev\u0161i od na\u0161ih prapovijesnih vremena, kada smo implementirali sve sustave na obi\u010dne virtualne poslu\u017eitelje, do postupnog prelaska s Nomada na implementaciju u Kubernetes. Ispri\u010dat \u0107u za\u0161to smo to u\u010dinili i s kakvim smo se problemima susretali tijekom procesa.<\/p>\n

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

Implementacija aplikacija na VM<\/h1>\n

\nKrenut \u0107emo od toga da su prije 3 godine svi sustavi i usluge tvrtke bili implementirani na obi\u010dne virtualne poslu\u017eitelje. Tehni\u010dki je bilo organizirano tako da je sav kod na\u0161ih sustava bio pohranjen i sastavljen koriste\u0107i sredstva automatske izrade, uz pomo\u0107 jenkins-a. Pomo\u0107u Ansible-a, iz na\u0161eg sustava za kontrolu verzija, otpu\u0161tan je na virtualne poslu\u017eitelje. Svaki sustav koji je bio u na\u0161oj tvrtki bio je implementiran, bar, na 2 poslu\u017eitelja: jedan je bio head, a drugi tail. Ova dva sustava bila su apsolutno identi\u010dna po svim svojim postavkama, snagama, konfiguracijama i ostalom. Razlika izme\u0111u njih bila je samo u tome \u0161to je head primao korisni\u010dki promet, dok tail nikada nije primao promet korisnika. <\/p>\n

Za\u0161to je to u\u010dinjeno? <\/p>\n

Kada smo implementirali nove verzije na\u0161e aplikacije, \u017eeljeli smo osigurati mogu\u0107nost besprijekornog otpu\u0161tanja, tj. bez vidljivih posljedica za korisnike. To se postizalo tako da je nova sastavljena verzija pomo\u0107u Ansible-a otpu\u0161tena na tail. Tamo su ljudi koji su se bavili implementacijom mogli provjeriti i uvjeriti se da sve radi: sve metrike, odjeli i aplikacije rade; potrebni skripti se pokre\u0107u. Tek nakon \u0161to su se uvjerili da je sve u redu, promet se preusmjerio. Po\u010deo je i\u0107i na onaj poslu\u017eitelj koji je do tada bio tail. A onaj koji je do tada bio head ostao je bez korisni\u010dkog prometa, pri \u010demu je imao prethodnu verziju na\u0161e aplikacije.<\/p>\n

Dakle, za korisnike je to bilo neprimjetno. Budu\u0107i da je prebacivanje trenuta\u010dno, jer je to jednostavno prebacivanje balansira\u010da optere\u0107enja. Vrlo se lako mo\u017eete vratiti na prethodnu verziju jednostavnim prebacivanjem balansira\u010da natrag. Tako\u0111er smo mogli provjeriti sposobnosti aplikacije u produkciji prije nego \u0161to korisni\u010dki promet po\u010dne dolaziti, \u0161to je bilo vrlo prakti\u010dno. <\/p>\n

Koje smo prednosti vidjeli u svemu tome?<\/p>\n

    \n
  1. Prije svega, to je dovoljno jednostavno funkcionira.<\/b> Svima je jasno kako takva shema implementacije radi, jer je ve\u0107ina ljudi ikada radila implementaciju na obi\u010dne virtualne poslu\u017eitelje.<\/li>\n
  2. To je dovoljno sigurno<\/b>, budu\u0107i da je tehnologija implementacije jednostavna, ispitana od strane tisu\u0107a tvrtki. Milijuni poslu\u017eitelja se upravo tako implementiraju. Te\u0161ko je ne\u0161to pokvariti. <\/li>\n
  3. I kona\u010dno, mogli smo dobiti atomsku implementaciju<\/b>. Implementacije koje se korisnicima doga\u0111aju trenuta\u010dno, bez uo\u010dljivog koraka prebacivanja izme\u0111u stare i nove verzije. <\/li>\n<\/ol>\n

    \nNo u svemu tome tako\u0111er smo vidjeli nekoliko nedostataka: <\/p>\n

      \n
    1. Osim produkcijskog okru\u017eenja, postoji i okru\u017eenje za razvoj, kao i druga okru\u017eenja. Na primjer, QA i predprodukcija. U tom trenutku imali smo mnogo poslu\u017eitelja i oko 60 servisa. Iz tog razloga smo morali za svaki servis odr\u017eavati a\u017euriranu verziju <\/b>virtualne ma\u0161ine. Ako \u017eelite a\u017eurirati biblioteke ili instalirati nove ovisnosti, morate to u\u010diniti u svim okru\u017eenjima. Tako\u0111er je bilo potrebno uskladiti vrijeme kada planirate implementirati novu verziju va\u0161e aplikacije s vremenom kada devops izvr\u0161i potrebne postavke okru\u017eenja. U tom slu\u010daju lako mo\u017eete zavr\u0161iti u situaciji gdje se okru\u017eenja malo razlikuju odmah u svim okru\u017eenjima. Na primjer, u QA okru\u017eenju bit \u0107e jedne verzije biblioteka, a u produkciji druge, \u0161to mo\u017ee dovesti do problema. <\/li>\n
    2. Kompleksnost u a\u017euriranju ovisnosti<\/b> va\u0161e aplikacije. Ovo ne zavisi od vas, ve\u0107 od drugog tima. Naime, od devops tima koji odr\u017eava poslu\u017eitelje. Morate im postaviti odgovaraju\u0107i zadatak i dati opis onoga \u0161to \u017eelite u\u010diniti.<\/li>\n
    3. U to vrijeme smo tako\u0111er htjeli podijeliti na\u0161e velike monolite na manje usluge, kako bismo shvatili da \u0107e ih vjerojatno biti sve vi\u0161e. Tada smo ve\u0107 imali vi\u0161e od 100 njih. Za svaku novu uslugu trebalo je kreirati novu virtualnu ma\u0161inu koju je tako\u0111er trebalo odr\u017eavati i postavljati. Osim toga, bila je potrebna najmanje jedna druga ma\u0161ina. Tome je dodatno trebala i QA okolina. To uzrokuje probleme i \u010dini stvaranje i pokretanje novih sustava za vas kompliniranim, skupim i dugotrajnim procesom. Zbog toga smo odlu\u010dili da \u0107e biti lak\u0161e pre\u0107i s postavljanja obi\u010dnih virtualnih ma\u0161ina na postavljanje na\u0161ih aplikacija u docker kontejnerima. Uz docker, potrebna je i sustav koji mo\u017ee pokrenuti aplikacije u klasteru, jer jednostavno ne mo\u017eete pokrenuti kontejner samo tako. Obi\u010dno \u017eelite pratiti koliko je kontejnera pokrenuto, tako da se pokre\u0107u automatski. Iz tog razloga trebali smo odabrati sustav upravljanja.<\/b><\/li>\n<\/ol>\n

      \nDugo smo razmi\u0161ljali o tome koju od njih uzeti. \u010cinjenica je da je tada ovaj stak od obi\u010dnih virtualnih servera bio pomalo zastario, jer su tu bile starije verzije operativnih sustava. U nekom trenutku je \u010dak bila instalirana FreeBSD, koja nije bila ba\u0161 jednostavna za odr\u017eavanje. Razumjeli smo da moramo \u0161to br\u017ee migrirati u docker. Na\u0161i DevOps su pogledali svoje iskustvo s razli\u010ditim rje\u0161enjima i odabrali sustav poput Nomada. <\/p>\n

      Prijelaz na Nomad <\/p>\n

      Nomad je proizvod tvrtke \u201cHashiCorp\u201d. Oni su poznati i po drugim svojim rje\u0161enjima:<\/h1>\n

      \n\u00abConsul\u00bb<\/p>\n

      \"Deploy
      \n
      \n\u2014 to je sredstvo za otkrivanje usluga.<\/b> \u00abTerraform\u00bb<\/p>\n

      \u2014 sustav za upravljanje serverima koji vam omogu\u0107uje da ih postavite putem konfiguracije, poznate kao infrastructure-as-code.<\/b> \u00abVagrant\u00bb<\/p>\n

      omogu\u0107uje vam postavljanje virtualnih ma\u0161ina lokalno ili u oblaku putem odre\u0111enih konfiguracijskih datoteka.<\/b> Nomad se tada \u010dinio kao dovoljno jednostavno rje\u0161enje na koje se mo\u017ee brzo pre\u0107i bez promjene cijele infrastrukture. Osim toga, dovoljno je lako za nau\u010diti. Stoga je upravo njega izabran kao sustav filtriranja na\u0161eg kontejnera. <\/p>\n

      \u0160to vam je potrebno da uop\u0107e postavite svoj sustav u Nomad? <\/p>\n

      Prije svega, potreban vam je <\/p>\n

        \n
      1. docker image docker slika<\/b> aplikacije. Potrebno ga je izraditi i smjestiti u spremi\u0161te slika docker. U na\u0161em slu\u010daju to je artifactory \u2014 sustav koji omogu\u0107ava pu\u0161tanje raznih artefakata razli\u010ditih tipova. Mo\u017ee pohraniti arhive, docker slike, PHP composer pakete, NPM pakete i tako dalje. <\/li>\n
      2. Tako\u0111er je potrebno konfiguracijske datoteke<\/b>, koji \u0107e re\u0107i Nomadu \u0161to, gdje i u kojim koli\u010dinama \u017eelite deployati. <\/li>\n<\/ol>\n

        \nKada govorimo o Nomadu, kao format informacijske datoteke koristi HCL jezik, \u0161to je skra\u0107enica za HashiCorp Configuration Language<\/i>. To je nadmno\u0161tvo Yaml-a, koje vam omogu\u0107ava da opi\u0161ete svoju uslugu u terminima Nomada. <\/p>\n

        \"Deploy
        \n
        \nOmogu\u0107ava vam da navedete koliko kontejnera \u017eelite deployati, iz kojih slika im proslijedite razne parametre pri deployanju. Na taj na\u010din, alimentirate ovu datoteku Nomadu, a on pokre\u0107e kontejneru u produkciji prema njoj. <\/p>\n

        U na\u0161em slu\u010daju shvatili smo da bi bilo neprakti\u010dno pisati potpuno iste, identi\u010dne HCL datoteke za svaku uslugu, jer ih ima puno i ponekad ih \u017eelite a\u017eurirati. Ponekad se dogodi da jedna usluga nije deployana u jednom primjerku, ve\u0107 u vi\u0161e varijanti. Na primjer, jedan od sustava koji imamo u produkciji ima vi\u0161e od 100 instanci u produkciji. Pokre\u0107u se iz istih slika, ali se razlikuju po konfiguracijskim postavkama i datotekama. <\/p>\n

        Stoga smo odlu\u010dili da \u0107e nam biti zgodno pohraniti sve na\u0161e konfiguracijske datoteke za deploy u jednom zajedni\u010dkom repozitoriju. Na taj na\u010din postaju pregledne: lako ih je odr\u017eavati i mo\u017eete vidjeti koje sustave imamo. U slu\u010daju potrebe tako\u0111er nije te\u0161ko ne\u0161to a\u017eurirati ili promijeniti. Dodavanje novog sustava tako\u0111er ne\u0107e biti problem \u2014 dovoljno je jednostavno stvoriti konfiguracijsku datoteku unutar novog direktorija. Unutar tog direktorija nalaze se datoteke: service.hcl, koja sadr\u017ei opis na\u0161e usluge i neki env-datoteke, koje omogu\u0107avaju da se ta usluga, nakon deployanja u produkciju, konfigurira. <\/p>\n

        \"Deploy
        \n
        \nMe\u0111utim, neke na\u0161e usluge nisu deployane u produkciji u jednom primjerku, ve\u0107 u vi\u0161e odjednom. Zato smo odlu\u010dili da \u0107e nam biti prakti\u010dno pohranjivati ih ne u \u010distom obliku, ve\u0107 u \u0161abloniziranom obliku. Kao jezik \u0161ablonizacije odabrali smo jinja 2<\/i>. U tom formatu \u010duvamo kako konfiguracije samog servisa, tako i env datoteke potrebne za njega. <\/p>\n

        Osim toga, stavili smo u repozitorij zajedni\u010dki skript za implementaciju koji omogu\u0107ava pokretanje i implementaciju va\u0161eg servisa u produkciji, u potrebnom okru\u017eenju, u ciljanom odredi\u0161tu. Kada smo pretvorili na\u0161 HCL konfiguraciju u predlo\u017eak, ta HCL datoteka, koja je prije bila obi\u010dna Nomad konfiguracija, sada izgleda malo druga\u010dije.<\/p>\n

        \"Deploy
        \n
        \nOdnosno, zamijenili smo neka mjesta s promenjivim u konfiguraciji s umetanjima promenjivih koje se uzimaju iz env datoteka ili drugih izvora. Osim toga, dobili smo mogu\u0107nost dinami\u010dkog generisanja HCL datoteka, \u0161to zna\u010di da mo\u017eemo primenjivati ne samo obi\u010dna umetanja promenjivih. Budu\u0107i da jinja podr\u017eava petlje i uslove, tako\u0111e mo\u017eemo kreirati konfiguracijske datoteke koje se menjaju u zavisnosti od toga gde ta\u010dno implementirate svoje aplikacije. <\/p>\n

        Na primjer, \u017eelite implementirati svoj servis u preprodukciji i u produkciji. Recimo da u preprodukciji ne \u017eelite pokretati cron skripte, ve\u0107 samo \u017eelite videti servis na odvojenoj domeni, kako biste se uverili da funkcioni\u0161e. Za svakoga ko implementira servis, proces izgleda vrlo jednostavno i jasno. Potrebno je samo izvr\u0161iti datoteku deploy.sh, navesti koji servis \u017eelite implementirati i u koje odredi\u0161te. Na primjer, \u017eelite implementirati neku sistemu u Rusiju, Belorusiju ili Kazahstan. Za to je dovoljno samo promijeniti jedan od parametara, i dobi\u0107ete ispravnu konfiguracijsku datoteku. <\/p>\n

        Kada je Nomad servis ve\u0107 implementiran u va\u0161em klasteru, izgleda ovako.<\/p>\n

        \"Deploy
        \n
        \nZa po\u010detak, potreban vam je neki balancer izvana koji \u0107e primati sav korisni\u010dki promet. On \u0107e raditi zajedno s Consulom i saznati od njega gde se, na kojoj nodi, po kojem IP-adresu<\/a> se nalazi odre\u0111eni servis koji odgovara nekom domenskom imenu. Servisi u Consulu pojavljuju se iz samog Nomada. Budu\u0107i da su to proizvodi iste kompanije, me\u0111usobno su prili\u010dno povezani. Mo\u017eemo re\u0107i da Nomad iz kutije mo\u017ee registrovati sve servise pokrenute unutar Consula. <\/p>\n

        Nakon \u0161to va\u0161 vanjski balancer sazna kojem servisu treba preusmjeriti promet, preusmjerava ga u odgovaraju\u0107i kontejner ili u vi\u0161e kontejnera koji odgovaraju va\u0161oj aplikaciji. Naravno, potrebno je razmi\u0161ljati i o sigurnosti. Iako se svi servisi pokre\u0107u na istim virtualnim strojevima unutar kontejnera, obi\u010dno je potrebno zabraniti slobodan pristup iz bilo kojeg servisa drugom. To smo postigli segmentacijom. Svaki servis pokretan je u svojoj virtualnoj mre\u017ei, na kojoj su postavljena pravila usmjeravanja i pravila dopu\u0161tanja\/zabranjivanja pristupa drugim sustavima i servisima. Oni su mogli biti unutar ovog klastera ili izvan njega. Na primjer, ako \u017eelite zabraniti servisu da se pove\u017ee s odre\u0111enom bazom podataka, to mo\u017eete posti\u0107i segmentacijom na razini mre\u017ee. To zna\u010di da \u010dak ni gre\u0161kom ne mo\u017eete slu\u010dajno povezati iz testnog okru\u017eenja na va\u0161u produkcijsku bazu.<\/p>\n

        Koliko nas je ko\u0161tao proces prelaska u smislu ljudskih resursa? <\/p>\n

        Prelazak cijele kompanije na Nomad trajao je otprilike 5-6 mjeseci. Prelazili smo uslugu po uslugu, ali prili\u010dno brzim tempom. Svaki tim trebao je stvoriti vlastite kontejneri za usluge. <\/p>\n

        Kod nas je usvojen pristup u kojem svaka ekipa samostalno odgovara za docker slike svojih sustava. DevOps pru\u017eaju zajedni\u010dku infrastrukturu potrebnu za implementaciju, tj. podr\u0161ku samom klasteru, podr\u0161ku CI sustavu i tako dalje. U to vrijeme vi\u0161e od 60 sustava pre\u0161lo je na Nomad, \u0161to je rezultiralo s oko 2000 kontejnera. <\/p>\n

        DevOps odgovara za zajedni\u010dku infrastrukturu svega \u0161to je vezano uz implementaciju, s poslu\u017eiteljima. Svaka razvojna ekipa, s druge strane, odgovara za realizaciju kontejnera za svoj konkretni sustav, budu\u0107i da samo tim zna \u0161to im je zapravo potrebno u tom ili onom kontejneru.<\/p>\n

        Razlozi za napu\u0161tanje Nomada<\/h1>\n

        \nKoje smo prednosti dobili prelaskom na implementaciju pomo\u0107u Nomada i dockera?<\/p>\n

          \n
        1. Mi osigurali jednake uvjete<\/b> za sve okru\u017eenja. U razvoju, QA okru\u017eenju, predprodukciji i produkciji koriste se isti kontejnerski obrasci sa istim zavisnostima. Stoga imate gotovo nula \u0161anse da u produkciju stigne ne\u0161to \u0161to niste prethodno testirali lokalno ili u testnom okru\u017eenju. <\/li>\n
        2. Tako\u0111er smo otkrili da je dovoljno lako dodati novu uslugu<\/b>. Bilo koji novi sistemi s aspekta implementacije pokre\u0107u se vrlo jednostavno. Dovoljno je oti\u0107i u repozitorij koji sadr\u017ei konfiguracije, dodati jo\u0161 jednu konfiguraciju za va\u0161 sistem i sve je spremno. Mo\u017eete implementirati va\u0161 sistem u produkciju bez dodatnog napora od devops-a. <\/li>\n
        3. Sve konfiguracijske datoteke<\/b> u jednom zajedni\u010dkom repozitoriju bile su pregledne<\/b>. U trenutku kada smo implementirali na\u0161e sisteme pomo\u0107u virtualnih servera<\/a>, koristili smo Ansible, gdje su konfiguracije bile u istom repozitoriju. Me\u0111utim, za ve\u0107inu programera, raditi s tim je bilo malo te\u017ee. Ovde je volumen konfiguracija i koda koji trebate dodati da biste implementirali uslugu zna\u010dajno smanjen. Tako\u0111er, za devops je vrlo lako popraviti ili promeniti to. U slu\u010daju prijelaza, na primer, na novu verziju Nomad-a, mogu masovno a\u017eurirati sve operativne datoteke koje se nalaze na istom mestu.<\/li>\n<\/ol>\n

          \nAli smo se tako\u0111er suo\u010dili s nekim nedostacima: <\/p>\n

          Ispostavilo se da nismo uspjeli posti\u0107i bez\u0161avne implementacije <\/b>u slu\u010daju Nomad-a. Prilikom pu\u0161tanja kontejnera iz razli\u010ditih okru\u017eenja moglo se desiti da je on bio pokrenut i Nomad ga je prepoznavao kao spremnog za primanje saobra\u0107aja. To se doga\u0111alo jo\u0161 pre nego \u0161to se aplikacija unutar njega uspela pokrenuti. Iz tog razloga je sistem tokom kratkog perioda po\u010deo davati 500 gre\u0161ke, jer je saobra\u0107aj po\u010deo da ide na kontejner koji jo\u0161 nije bio spreman da ga primi. <\/p>\n

          Suo\u010dili smo se sa nekim gre\u0161kama<\/b>Najve\u0107a gre\u0161ka je u tome \u0161to Nomad ne mo\u017ee dobro upravljati velikim klasterima, posebno ako imate mnogo sustava i kontejnera. Kada \u017eelite staviti jedan od servera u odr\u017eavanje koji je uklju\u010den u Nomad klaster, postoji velika vjerojatnost da \u0107e klaster po\u010deti lo\u0161e reagirati i raspasti se. Neki kontejneri mogu, na primjer, pasti i nisu u mogu\u0107nosti da se ponovno pokrenu\u2014to \u0107e vas kasnije ko\u0161tati mnogo, ako su svi va\u0161i sustavi u produkciji unutar klastera upravljanog Nomadom. <\/p>\n

          Zbog toga smo odlu\u010dili razmisliti o tome kuda dalje i\u0107i. Tada smo ve\u0107 puno bolje razumjeli \u0161to \u017eelimo posti\u0107i. Naime, \u017eelimo pouzdanost, malo vi\u0161e funkcionalnosti nego \u0161to nudi Nomad i zreliji, stabilniji sustav. <\/p>\n

          U tom smislu, na\u0161 izbor je pao na Kubernetes kao najpopularniju platformu za pokretanje klastera. Osobito s obzirom na to da je veli\u010dina i broj na\u0161ih kontejnera bili prili\u010dno veliki. Za takve ciljeve, Kubernetes se pokazao kao najprikladniji sustav koji smo mogli razmotriti. <\/p>\n

          Prijelaz na Kubernetes<\/h1>\n

          \nMalo \u0107u re\u0107i o osnovnim konceptima Kubernetesa i kako se razlikuju od Nomada. <\/p>\n

          \"Deploy
          \n
          \nPrvo, osnovni koncept u Kubernetesu je pojam pod. Pod<\/b> \u2014 to je grupa jednog ili vi\u0161e kontejnera koji se uvijek pokre\u0107u zajedno. Oni rade kao da su uvijek na jednoj virtualnoj ma\u0161ini. Imaju me\u0111usobnu dostupnost 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 \u2014 klasi\u010dna shema. Vjerojatno \u0107ete htjeti da nginx i php-fpm kontejneri uvijek budu zajedno. Kubernetes to omogu\u0107uje opisivanjem njih kao jednog zajedni\u010dkog poda. Upravo to nismo mogli dobiti pomo\u0107u Nomada.<\/p>\n

          Drugi koncept je deployment<\/b>. Naime, pod kao takav je efemerna stvar, pokre\u0107e se i nestaje. \u017delite li prvo ubiti sve svoje prethodne kontejnere, a zatim odmah pokrenuti nove verzije, ili ih \u017eelite izdavati postupno\u2014za ovaj proces je odgovoran koncept deployment. On opisuje kako implementirate svoje pode, u kojem broju i kako ih a\u017eurirati. <\/p>\n

          Tre\u0107i koncept je usluga<\/b>. Va\u0161 service je zapravo va\u0161 sustav koji prima odre\u0111eni promet i zatim ga usmjerava na jedan ili vi\u0161e podova koji odgovaraju va\u0161em servisu. To zna\u010di da omogu\u0107uje slanje cijelog ulaznog prometa na odre\u0111eni servis s odre\u0111enim imenom na te konkretne podove. Osim toga, osigurava vam ravnote\u017eu prometa. Mo\u017eete pokrenuti dva poda svoje aplikacije i cijeli ulazni promet \u0107e se ravnomjerno rasporediti izme\u0111u povezanih podova ovog servisa.<\/p>\n

          I \u010detvrti osnovni pojam \u2014 Ingress<\/b>. To je servis koji se pokre\u0107e u Kubernetes klasteru. On djeluje kao vanjski balansirnik optere\u0107enja koji preuzima sve zahtjeve. Zahvaljuju\u0107i API-ju Kubernetes Ingress mo\u017ee odrediti kamo treba poslati te zahtjeve. A to \u010dini vrlo fleksibilno. Mo\u017eete re\u0107i da sve zahtjeve za ovaj host i odre\u0111eni URL \u0161aljete na ovaj servis. A te zahtjeve koji dolaze na ovaj host i drugi URL \u0161aljemo na drugi servis. <\/p>\n

          Najbolje u pogledu onoga tko razvija aplikaciju je to \u0161to mo\u017eete sami upravljati tim svime. Definiranjem Ingress konfiguracije, mo\u017eete cijeli promet koji dolazi na odre\u0111eni API slati na posebne kontejnere, na primjer, one napisane u Go-u. A ovaj promet, koji dolazi na istu domenu, ali na drugi URL, slati na kontejnere napisane u PHP-u, gdje ima puno logike, ali nisu ba\u0161 brzi.<\/p>\n

          Ako usporedimo sve ove pojmove s Nomad-om, mo\u017eemo re\u0107i da su prva tri pojma zajedno Service. A posljednji pojam u Nomad-u ne postoji. Umjesto toga, koristili smo vanjski balansirnik: to mo\u017ee biti haproxy, nginx, nginx+ i sli\u010dno. U slu\u010daju Kubernetesa ne morate uvesti ovaj dodatni pojam odvojeno. Me\u0111utim, ako pogledate Ingress iznutra, to mo\u017ee biti ili nginx, ili haproxy, ili traefik, ali kao da je ugra\u0111en u Kubernetes. <\/p>\n

          Svi pojmovi koje sam opisao su, u su\u0161tini, resursi koji postoje unutar Kubernetes klastera. Za njihovo opisivanje u klasteru koriste se yaml-format, koji je \u010ditljiviji i poznatiji od HCL datoteka u slu\u010daju Nomada. Ali strukturno opisuju, primjerice, pod isto to. Ka\u017eu \u2014 \u017eelim deploy-ati takve podove ondje, s takvim slikama, u takvom broju. <\/p>\n

          \"Deploy
          \n
          \nOsim toga, shvatili smo da ne \u017eelimo ru\u010dno kreirati svaki pojedina\u010dni resurs: deployment, servise, Ingress i sli\u010dno. Umjesto toga, \u017eeljeli smo pri deployu opisati svaki na\u0161 sustav u terminima Kubernetesa, kako ne bismo morali ru\u010dno ponovo kreirati sve potrebne zavisnosti resursa u pravom redoslijedu. Kao takav sustav, koji nam je omogu\u0107io to, odabran je Helm. <\/p>\n

          Osnovni pojmovi u Helmu<\/h1>\n

          \nHelm \u2013 to je menad\u017eer paketa<\/b> za Kubernetes. Vrlo je sli\u010dan tome kako rade upravitelji paketa u programskim jezicima. Omogu\u0107uje vam pohranu servisa, koji se sastoji, na primjer, od deploymenta nginx-a, deploymenta php-fpm-a, konfiguracije za Ingress, configmaps (to je entitet koji vam omogu\u0107uje definiranje env i drugih parametara za va\u0161 sustav) u obliku takozvanih chartova. Pri tome Helm radi iznad Kubernetesa<\/b>. Dakle, to nije neka sustav koja stoji sa strane, ve\u0107 jednostavno jo\u0161 jedan servis koji se pokre\u0107e unutar klastera. Komunicirate s njim putem njegovog API-ja kroz konzolnu naredbu. Njegova pogodnost i ljepota le\u017ee u tome \u0161to, \u010dak i ako se helm pokvari ili ga izbri\u0161ete iz klastera, va\u0161i servisi ne\u0107e nestati, jer helm slu\u017ei u su\u0161tini samo za pokretanje sustava. Za funkcionalnost i stanje servisa dalje odgovara sam Kubernetes. <\/p>\n

          Tako\u0111er smo shvatili da templating<\/b>, koju smo ranije bili prisiljeni raditi sami putem ugra\u0111ivanja jinj-a u na\u0161e konfiguracije, predstavlja jednu od glavnih mogu\u0107nosti helma. Sve konfiguracije koje stvarate za va\u0161e sustave pohranjuju se u helmu u obliku predlo\u017eaka, koji su malo sli\u010dni jinja, ali zapravo koriste templating jezika Go, na kojem je helm napisan, kao i Kubernetes. <\/p>\n

          Helm nam dodaje jo\u0161 nekoliko dodatnih pojmova. <\/p>\n

          Chart<\/b> \u2014 to je opis va\u0161eg servisa. U drugim upraviteljima paketa nazvali bi ga paketom, bundleom ili ne\u010dim sli\u010dnim. Ovdje se to naziva chart. <\/p>\n

          Values <\/b>\u2013 to su varijable koje \u017eelite koristiti za sastavljanje va\u0161ih konfiguracija iz predlo\u017eaka. <\/p>\n

          Objava<\/b>Svaki put kada se usluga koja se implementira pomo\u0107u helma a\u017eurira, dobiva inkrementalnu verziju izdanja. Helm pamti kakva je bila konfiguracija usluge pri prethodnim izdanjima. Stoga, ako je potrebno vratiti se, dovoljno je izvr\u0161iti naredbu helm rollback, navode\u0107i prethodnu verziju izdanja. \u010cak i ako u trenutku vra\u0107anja odgovaraju\u0107a konfiguracija u va\u0161em repozitoriju nije dostupna, helm se i dalje sje\u0107a kakva je ona bila i vratit \u0107e va\u0161 sustav u stanje u kojem je bio pri prethodnom izdanju. <\/p>\n

          Kada koristimo helm, obi\u010dne konfiguracije za Kubernetes tako\u0111er postaju predlo\u0161ci u kojima mo\u017eete koristiti varijable, funkcije i primjenjivati uvjetne operatore. Na taj na\u010din mo\u017eete sastaviti konfiguraciju va\u0161e usluge ovisno o okru\u017eenju.<\/p>\n

          \"Deploy
          \n
          \nU praksi smo odlu\u010dili postupiti malo druga\u010dije nego smo to radili s Nomadom. Ako su u Nomadu u jednom repozitoriju bile pohranjene i konfiguracije za implementaciju, te n-varijable potrebne za implementaciju na\u0161e usluge, ovdje smo odlu\u010dili podijeliti ih na dva razli\u010dita repozitorija. U repozitoriju \u201edeploy\u201c pohranjuju se samo n-varijable potrebne za implementaciju, dok su u repozitoriju \u201ehelm\u201c pohranjene konfiguracije ili chartovi.<\/p>\n

          \"Deploy
          \n
          \n\u0160to nam je to donijelo? <\/p>\n

          Iako u samim konfiguracijskim datotekama ne pohranjujemo neke zaista osjetljive podatke, poput lozinki za baze podataka. One se pohranjuju kao tajne u Kubernetesu, no ipak postoje posebne stvari kojima ne \u017eelimo dati pristup svima. Stoga je pristup repozitoriju \u201edeploy\u201c vi\u0161e ograni\u010den, a repozitorij \u201ehelm\u201c sadr\u017ei samo opis usluge. Iz tog razloga mu se mo\u017ee sigurno osigurati pristup \u0161irem krugu osoba. <\/p>\n

          Budu\u0107i da imamo ne samo produkcijsko, nego i druga okru\u017eenja, zahvaljuju\u0107i ovakvom razdvajanju mo\u017eemo ponovno koristiti na\u0161e helm-chartove za implementaciju usluga ne samo u produkciji, nego i, na primjer, u QA-okru\u017eenju. \u010cak i za lokalno pokretanje koriste\u0107i Minikube<\/i> \u2014 to je stvar za lokalno pokretanje Kubernetesa. <\/p>\n

          Unutar svake repozitorija ostavili smo razdvajanje na posebne direktorije za svaku uslugu. To jest, unutar svake direktorije nalaze se predlo\u0161ci koji se odnose na odgovaraju\u0107i chart i opisuju resurse koje je potrebno implementirati za pokretanje na\u0161eg sustava. U repozitoriju 'deploy' ostavili smo samo env datoteke. U ovom slu\u010daju nismo koristili templating putem jinja, jer helm sam po sebi nudi templating funkcionalnost ve\u0107 u osnovi \u2013 to je jedna od njegovih klju\u010dnih zna\u010dajki. <\/p>\n

          Ostavili smo skriptu za implementaciju \u2013 deploy.sh, koja pojednostavljuje i standardizira pokretanje za implementaciju putem helma. Tako, za bilo koga tko \u017eeli implementirati, su\u010delje implementacije izgleda to\u010dno onako kao \u0161to je bilo u slu\u010daju implementacije putem Nomada. Isti deploy.sh, naziv va\u0161e usluge i mjesto na koje je \u017eelite implementirati. To dovodi do toga da se unutar pokre\u0107e helm. On zauzvrat prikuplja konfiguracije iz predlo\u017eaka, ubacuje potrebne values datoteke, a zatim implementira, proslje\u0111uju\u0107i ih u Kubernetes. <\/p>\n

          Zaklju\u010dci<\/h1>\n

          \nKubernetes usluga izgleda slo\u017eenije nego Nomad. <\/p>\n

          \"Deploy
          \n
          \nOvdje izlazni promet dolazi u Ingress. To je upravo front-kontroler koji preuzima sve zahtjeve i potom ih \u0161alje odgovaraju\u0107im uslugama na temelju zahtjeva. Odre\u0111uje ih na osnovu konfiguracija, koje su dio opisa va\u0161e aplikacije u helmu i koje programeri postavljaju samostalno. Usluga zatim \u0161alje zahtjeve na svoje podove, tj. konkretne kontejnere, balansiraju\u0107i ulazni promet izme\u0111u svih kontejnera koji pripadaju toj usluzi. I, naravno, ne smijemo zaboraviti da, kada je rije\u010d o sigurnosti na razini mre\u017ee, ne trebamo nikamo odlaziti. Stoga se u Kubernetes klasteru provodi segmentacija koja se temelji na ozna\u010davanju. Sve usluge imaju odre\u0111ene oznake, kojima su pridru\u017eena prava pristupa tim ili onim vanjskim\/unutarnjim resursima unutar ili izvan klastera. <\/p>\n

          Prilikom prelaska, primijetili smo da Kubernetes ima sve mogu\u0107nosti koje je imao Nomad, koji smo ranije koristili, a tako\u0111er dodaje mnogo novog. Mo\u017ee se pro\u0161iriti putem plugina, kao i kroz prilago\u0111ene tipove resursa. To zna\u010di da imate mogu\u0107nost ne samo koristiti ne\u0161to \u0161to dolazi s Kubernetesom, ve\u0107 i kreirati vlastiti resurs i servis koji \u0107e \u010ditati taj resurs. To pru\u017ea dodatne mogu\u0107nosti za pro\u0161irenje va\u0161eg sustava bez potrebe za reinstaliranjem Kubernetesa ili promjenama. <\/p>\n

          Primjer takve upotrebe je Prometheus, koji se pokre\u0107e unutar na\u0161eg Kubernetes klastera. Da bi po\u010deo prikupljati metrike s odre\u0111enog servisa, moramo dodati dodatni tip resursa u opis servisa, takozvani servis-monitor. Prometheus, zbog svoje sposobnosti da \u010dita prilago\u0111ene tipove resursa dok se pokre\u0107e u Kubernetesu, automatski po\u010dinje prikupljati metrike iz novog sustava. To je vrlo prakti\u010dno. <\/p>\n

          Prvi deploy koji smo napravili u Kubernetesu bio je u o\u017eujku 2018. I tijekom tog vremena nikada nismo imali problema s njim. Dovoljno stabilno radi bez zna\u010dajnih gre\u0161aka. Osim toga, mo\u017eemo ga dalje pro\u0161irivati. Za sada, mo\u017eemo re\u0107i da nam njegove mogu\u0107nosti odgovaraju, a tempo razvoja Kubernetesa nam se jako svi\u0111a. Trenutno se vi\u0161e od 3000 kontejnera nalazi u Kubernetesu. Klaster se sastoji od nekoliko Node-a. Ujedno je odr\u017eavan, stabilan i vrlo kontroliran.
          \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\udd47Deploy aplikacija u VM, Nomad i Kubernetes | ProHoster","description":"Pozdrav svima! Moje ime je Pavel Agaletski. Radim kao tim lider u timu koji razvija sustav isporuke Lamoda.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}