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

Tere k\u00f5igile! Minu nimi on Pavel Agaletckiy. Olen tiimi juht, mis arendab Lamoda tarnes\u00fcsteemi. Aastal 2018 esinesin konverentsil HighLoad++, ja t\u00e4na soovin tutvustada oma ettekande transkripti.<\/p>\n

Minu teema on p\u00fchendatud meie ettev\u00f5tte kogemusele s\u00fcsteemide ja teenuste juurutamisel erinevates keskkondades. Alustame meie eelajaloolistest aegadest, kui juurutati k\u00f5ik s\u00fcsteemid tavap\u00e4rastel virtuaalserveritel, ning liigume j\u00e4rk-j\u00e4rgult \u00fcle Nomadilt Kubernetesesse juurutamisele. R\u00e4\u00e4gin, miks me seda tegime ja millised probleemid meil protsessi k\u00e4igus olid.<\/p>\n

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

Rakenduste juurutamine VM-idele<\/h1>\n

\nAlustame sellest, et 3 aastat tagasi juurutati k\u00f5ik ettev\u00f5tte s\u00fcsteemid ja teenused tavap\u00e4rastel virtuaalserveritel. Tehniliselt oli see korraldatud nii, et kogu meie s\u00fcsteemide kood olid kogutud automatiseeritud koostamise vahendite abil Jenkins'i kaudu. Ansible'i abil laaditi see meie versioonihalduss\u00fcsteemist juba virtuaalserveritesse. Igal s\u00fcsteemil, mis meie ettev\u00f5ttes oli, juurutati v\u00e4hemalt kahte serverisse: \u00fcks neist oli head, teine tail. Need kaks s\u00fcsteemi olid omavahel t\u00e4iesti identsed k\u00f5iki seadistuste, j\u00f5udluse, konfiguratsiooni ja muude omaduste osas. Erinevus nende vahel oli vaid see, et head sai kasutaja liiklust, samas kui tail ei saanud kunagi kasutaja liiklust. <\/p>\n

Miks see nii tehti? <\/p>\n

Kui me juurutame uusi versioone meie rakendusest, soovisime tagada sujuva juurutamise v\u00f5imaluse, see t\u00e4hendab, et ilma kasutajatele m\u00e4rgatavate tagaj\u00e4rgedeta. See saavutati sellega, et j\u00e4rgmine koostatud versioon jagati Ansible'i kaudu tail'ile. Seal said juurutamisega tegelejad kontrollida ja veenduda, et k\u00f5ik on korras: k\u00f5ik m\u00f5\u00f5dikud, osad ja rakendused t\u00f6\u00f6tavad; vajalikud skriptid k\u00e4ivitatakse. Alles p\u00e4rast seda, kui nad veendusid, et k\u00f5ik on h\u00e4sti, suunati liiklus. See hakkas minema serverile, mis oli varem olnud tail. Ja see, mis oli varem olnud head, j\u00e4i ilma kasutajaliikluseta, samas kui sellel oli eelmine versioon meie rakendusest.<\/p>\n

Seega oli see kasutajatele l\u00e4bipaistev. Kuna vahetus toimub hetkega, kuna see on lihtsalt koormuse tasakaalustaja vahetamine. Eelmine versioon on v\u00e4ga lihtne tagasi v\u00f5tta, lihtsalt vahetades koormuse tasakaalustajat tagasi. Samuti saime veenduda rakenduse v\u00f5imes tootmises veel enne, kui kasutajate liiklus sellele suundub, mis oli v\u00e4ga mugav. <\/p>\n

Milliseid eeliseid me k\u00f5ik selle juures n\u00e4gime?<\/p>\n

    \n
  1. Esiteks, see on piisavalt lihtsalt toimiv.<\/b> K\u00f5igile on selge, kuidas selline juurutusmehhanism t\u00f6\u00f6tab, sest enamik inimesi on kunagi juurutanud tavaliselt virtuaalsetele serveritele.<\/li>\n
  2. See on piisavalt usaldusv\u00e4\u00e4rne<\/b>, kuna juurutustehnoloogia on lihtne ja testitud tuhandeid ettev\u00f5tteid. Miljonid serverid juurutatakse just nii. Midagi on keeruline katki teha. <\/li>\n
  3. Ja l\u00f5puks saime aatomse juurutuse<\/b>. Juurutused toimuvad kasutajatele momentaalselt, ilma m\u00e4rgatava etapita vana ja uue versiooni vahel. <\/li>\n<\/ol>\n

    \nKuid kogu selle juures n\u00e4gime ka m\u00f5ningaid puuduseid: <\/p>\n

      \n
    1. Lisaks tootmis\u00fcsteemile, arenduss\u00fcsteemile, on olemas ka teised keskkonnad. N\u00e4iteks qa ja eeltoodang. Sellel hetkel oli meil palju servereid ja umbes 60 teenust. Sel p\u00f5hjusel oli vajalik iga teenuse jaoks hoida selle jaoks asjakohast versiooni <\/b>virtuaalsest masinast. Ja kui soovite uuendada teeke v\u00f5i installida uusi s\u00f5ltuvusi, peate seda tegema k\u00f5ikides keskkondades. Samuti pidi s\u00fcnkroniseerima aja, mil kavatsete juurutada j\u00e4rgmise uue versiooni oma rakendusest, ajaga, mil devops teostab keskkonna vajalikud konfiguratsioonid. Sellisel juhul on lihtne sattuda olukorda, kus keskkondade vahel on koos erinevusi j\u00e4rjestikku. N\u00e4iteks qa keskkonnas on teised teekide versioonid ja tootmises teised, mis toob kaasa probleeme. <\/li>\n
    2. S\u00f5ltuvuste uuendamise keerukus<\/b> teie rakenduses. See ei s\u00f5ltu teist, vaid teisest meeskonnast. Nimelt, devops meeskonnast, kes toetab servereid. Peate neile esitama vastava \u00fclesande ja kirjeldama, mida soovite teha.<\/li>\n
    3. Sellest ajast alates soovisime jagada suured monoliidid v\u00e4iksemateks teenusteks, kuna m\u00f5istsime, et neid hakkab j\u00e4rjest rohkem olema. Tol hetkel oli neid juba \u00fcle 100. Iga uue teenuse jaoks oli vajalik luua eraldi uus virtuaalmasin, mida tuli samuti hallata ja juurutada. Lisaks sellele ei piisanud \u00fchest masinast, vaid v\u00e4hemalt kahest. K\u00f5igile nendele lisandus QA-keskkond. See tekitab probleeme ja muudab teie uute s\u00fcsteemide loomise ja k\u00e4ivitamise keerukaks, kulukaks ja ajamahukaks protsessiks.<\/b><\/li>\n<\/ol>\n

      \nSeet\u00f5ttu otsustasime, et oleks mugavam liikuda tavalisest virtuaalmasinate juurutamisest oma rakenduste juurutamisele Dockeris. Dockeri olemasolul on vajalik s\u00fcsteem, mis suudab rakenduse klastris k\u00e4ivitada, kuna te ei saa lihtsalt konteinerit \u00fcles t\u00f5sta. Tavaliselt soovitakse j\u00e4lgida, kui palju konteinerite on \u00fcles t\u00f5stetud, et need automaatselt k\u00e4ivituksid. Seet\u00f5ttu pidi meil valima juhtimiss\u00fcsteemi. <\/p>\n

      Me m\u00f5tlesime pikalt, millist neist v\u00f5iks kasutada. Probleemiks oli see, et tol hetkel oli meie tavap\u00e4raste virtuaalserverite juurutamistehnoloogia pisut aegunud, kuna seal olid vanad operatsioonis\u00fcsteemide versioonid. \u00dchel hetkel oli seal isegi FreeBSD, mida ei olnud just mugav hallata. Me m\u00f5istsime, et peame Dockerisse v\u00f5imalikult kiiresti migreerima. Meie devopsid vaatasid oma olemasolevat kogemust erinevate lahendustega ja valisid s\u00fcsteemi nimega Nomad. <\/p>\n

      \u00dcleminek Nomadile<\/h1>\n

      \nNomad on ettev\u00f5tte \u201cHashiCorp\u201d toode. Nad on tuntud ka teiste oma lahenduste poolest:<\/p>\n

      \"Rakenduste
      \n
      \n\u00abConsul\u00bb<\/b> \u2014 teenuste avastamiseks m\u00f5eldud t\u00f6\u00f6riist.<\/p>\n

      \u00abTerraform\u00bb<\/b> \u2014 serverihalduse s\u00fcsteem, mis v\u00f5imaldab teil neid konfigureerida infrastruktuuri koodina.<\/p>\n

      \u00abVagrant\u00bb<\/b> \u2014 v\u00f5imaldab teil hankida virtuaalmasinaid kohapeal v\u00f5i pilves, kasutades teatud konfigureerimisfaile. <\/p>\n

      Tol hetkel tundus Nomad piisavalt lihtne lahendus, kuhu saaks kiiresti \u00fcle minna, ilma kogu infrastruktuuri muutmata. Lisaks sellele on seda lihtne \u00f5ppida. Seet\u00f5ttu valisimegi selle meie konteineri filtreerimise s\u00fcsteemiks. <\/p>\n

      Mida on \u00fcldse vaja, et teie s\u00fcsteemi Nomadis juurutada? <\/p>\n

        \n
      1. Esiteks on vajalik docker image<\/b> teie rakendust. Tuleb see koguda ning paigutada docker'i piltide hoidlasse. Meie puhul on selleks artifactory \u2014 selline s\u00fcsteem, mis v\u00f5imaldab erinevaid artefakte erinevat t\u00fc\u00fcpi sinna saata. See suudab hoida arhiive, docker'i pilte, PHP composer pakette, NPM pakette jms. <\/li>\n
      2. Samuti on vajalik konfiguratsioonifail<\/b>, mis \u00fctleb Nomadile, mida, kuhu ja kui palju soovite juurutada. <\/li>\n<\/ol>\n

        \nKui r\u00e4\u00e4gime Nomadist, kasutab see informatiivse faili formaadina HCL keelt, mis t\u00e4histab HashiCorp Configuration Language<\/i>. See on Yaml'i \u00fclehulk, mis v\u00f5imaldab teil oma teenust Nomadi terminoloogias kirjeldada. <\/p>\n

        \"Rakenduste
        \n
        \nSee v\u00f5imaldab teil \u00f6elda, kui palju konteinerite soovite juurutada, millistest piltidest nendele erinevaid parameetreid juurutamisel anda. Nii toidate selle faili Nomadile ja see k\u00e4ivitab vastavalt sellele konteinerid tootmises. <\/p>\n

        Meie puhul m\u00f5istsime, et lihtsalt iga teenuse jaoks t\u00e4iesti identsete HCL-failide kirjutamine poleks v\u00e4ga mugav, kuna teenuseid on palju ja neid tahaks vahel uuendada. On juhtumeid, kui \u00fcks teenus ei ole juurutatud \u00fches eksemplaris, vaid mitmetes erinevates. N\u00e4iteks on \u00fcks meie tootmises olevatest s\u00fcsteemidest rohkem kui 100 instantsi tootmises. Need k\u00e4ivitatakse samadest piltidest, kuid erinevad konfiguratsiooni seadetest ja konfiguratsioonifailidest. <\/p>\n

        Seet\u00f5ttu otsustasime, et meil oleks mugav hoida k\u00f5iki meie juurutamise konfiguratsioonifaile \u00fches \u00fchises hoidlas. Nii muutuvad need l\u00e4bipaistvaks: neid on lihtne hallata ja n\u00e4ha, millised s\u00fcsteemid meil on. Vajadusel ei ole ka raske midagi uuendada v\u00f5i muuta. Uue s\u00fcsteemi lisamine ei valmista samuti raskusi \u2014 piisab lihtsalt, kui luua konfiguratsioonifail uue kausta sisse. Selles kaustas on failid: service.hcl, mis sisaldab meie teenuse kirjeldust, ja m\u00f5ned env-failid, mis v\u00f5imaldavad seda teenust, olles tootmises juurutatud, seadistada. <\/p>\n

        \"Rakenduste
        \n
        \nKuid m\u00f5ned meie s\u00fcsteemidest on tootmises juurutatud mitte \u00fches, vaid mitmes eksemplaris korraga. Seega otsustasime, et meile oleks mugav hoida mitte puhtaid konfiguratsioonifaile, vaid nende mallitud kujul. Ja mallimise keeleks valisime jinja 2<\/i>. Sellise vormingu abil salvestame nii teenuse konfiguratsioonid kui ka selleks vajalikud env-failid. <\/p>\n

        Lisaks oleme paigutanud projektide \u00fchisesse hoidlasse \u00fcldise skripti, mis v\u00f5imaldab teie teenust k\u00e4ivitada ja tootmisse paigaldada sobivasse keskkonda ja sihtkohta. Kui oleme oma HCL-konfiguratsiooni muundanud malliks, siis tundub, et see HCL-fail, mis oli seni tavaline Nomad'i konfiguratsioon, on n\u00fc\u00fcd pisut muutunud.<\/p>\n

        \"Rakenduste
        \n
        \nSee t\u00e4hendab, et oleme asendanud teatud konfiguratsiooni muutujad variablitega, mis p\u00e4rinevad env-failidest v\u00f5i muudest allikatest. Lisaks oleme saanud v\u00f5imaluse koguda HCL-faile d\u00fcnaamiliselt, st saame rakendada mitte ainult tavalisi variablite sisestusi. Kuna jinja toetab ts\u00fckleid ja tingimusi, saame seal ka luua konfiguratsioonifaile, mis muutuvad s\u00f5ltuvalt sellest, kuhu oma rakendusi paigaldate. <\/p>\n

        N\u00e4iteks soovite paigaldada oma teenuse eeltootmisse ja tootmisse. Oletame, et te ei soovi eeltootmises k\u00e4ivitada cron-skripte, vaid tahate lihtsalt n\u00e4ha teenust eraldi domeenil, et veenduda, et see t\u00f6\u00f6tab. Iga\u00fchele, kes teenust paigaldab, tundub protsess v\u00e4ga lihtne ja l\u00e4bipaistev. Piisab, kui k\u00e4ivitate fail deploy.sh, m\u00e4rkite, millist teenust soovite paigaldada ja kuhu sihtkohta. N\u00e4iteks soovite paigaldada mingit s\u00fcsteemi Venemaale, Valgevenesse v\u00f5i Kasahstani. Selleks piisab lihtsalt \u00fche parameetri muutmisest ja teil on \u00f5ige konfiguratsioonifail koostatud. <\/p>\n

        Kui Nomad teenus on teie klastrisse paigaldatud, n\u00e4eb see v\u00e4lja j\u00e4rgmine.<\/p>\n

        \"Rakenduste
        \n
        \nEsiteks vajate v\u00e4listingimustes m\u00f5nda tasakaalustajat, mis j\u00e4tab kogu kasutajatrafiku enda alla. See t\u00f6\u00f6tab koos Consuliga ja k\u00fcsib temalt, kus, millisel noodil, millise IP-aadressiga<\/a> hulgast asub konkreetne teenus, mis vastab mingile domeeninimele. Teenused Consulis ilmuvad otse Nomad'ist. Kuna need on sama ettev\u00f5tte tooted, on nad omavahel h\u00e4sti seotud. V\u00f5ib \u00f6elda, et Nomad oskab kohe registreerida k\u00f5ik selles k\u00e4ivitatud teenused Consulis. <\/p>\n

        P\u00e4rast seda, kui teie v\u00e4line koormuse jaotaja saab teada, kuhu teenusesse suunata liiklust, edastab ta selle vastavasse konteinerisse v\u00f5i mitmesse konteinerisse, mis vastavad teie rakendusele. Loomulikult tuleb sellega kaasas m\u00f5elda ka turvalisusele. Isegi kui k\u00f5ik teenused k\u00e4ivitatakse samadel virtuaalmasinatel konteinerites, tuleb tavaliselt keelata tasuta juurdep\u00e4\u00e4s igast teenusest igale teisele. Oleme seda saavutanud segmentatsiooni abil. Iga teenus k\u00e4ivitati oma virtuaalses v\u00f5rgus, kus olid m\u00e4\u00e4ratud marsruutimise reeglid ja reeglid juurdep\u00e4\u00e4su lubamiseks\/keelamiseks teistele s\u00fcsteemidele ja teenustele. Need v\u00f5isid asuda kas selle klastris v\u00f5i v\u00e4ljaspool seda. N\u00e4iteks, kui soovite keelata teenusel teatud andmebaasi \u00fchendamise, saab seda teha segmentatsiooni abil v\u00f5rgu tasemel. Seega pole teil isegi eksikombel v\u00f5imalik teie testkeskkonnast tootmisandmebaasi \u00fchenduda.<\/p>\n

        Kui palju maksis meile inimressursside poolest \u00fclemineku protsess? <\/p>\n

        Umbes 5\u20136 kuud v\u00f5ttis kogu ettev\u00f5tte \u00fcleminek Nomadile. Me tegime \u00fclemineku teenuste kaupa, kuid piisavalt kiiresti. Iga meeskond pidi looma oma konteinerid teenuste jaoks. <\/p>\n

        Meie l\u00e4henemine on selline, et iga meeskond vastutab iseseisvalt oma s\u00fcsteemide docker piltide eest. DevOps tagab vajalikud \u00fchisinfrastruktuurid deploymiseks, st klastrite toetamine, CI-s\u00fcsteemi toetamine ja nii edasi. Sel ajal oli meil \u00fcle 60 s\u00fcsteemi, mis kolisid Nomadisse, kokku t\u00f6\u00f6tati v\u00e4lja umbes 2000 konteinerit. <\/p>\n

        DevOps vastutab kogu infrastuktuuri eest, mis on seotud deploymise ja serveritega. Iga arendustiim vastutab omakorda oma konkreetse s\u00fcsteemi konteinerite rakendamise eest, kuna just nemad teavad, mida nad selle v\u00f5i tolle konteineri puhul vajavad.<\/p>\n

        P\u00f5hjused, miks loobuda Nomadist<\/h1>\n

        \nMilliseid eeliseid me saime, liikudes Nomadi ja dockeriga deploymise suunas?<\/p>\n

          \n
        1. Meie tagasime \u00fchtlased tingimused<\/b> k\u00f5ikides keskkondades. Arenduses, QA-keskkonnas, ettevalmistuses ja tootmises kasutatakse samu konteinerite pilte, samade s\u00f5ltuvustega. Seega on teil praktiliselt null v\u00f5imalust, et tootmisse satub midagi, mida te ei ole varem kohalikult v\u00f5i testkeskkonnas testinud. <\/li>\n
        2. Samuti selgus, et on piisavalt lihtne lisada uus teenus<\/b>. Iga uus s\u00fcsteem on juurutamise vaatenurgast v\u00e4ga lihtne k\u00e4ivitada. Piisab, kui minna konfiguratsioonide hoidlasse, lisada sinna j\u00e4rjekordne konfogi teie s\u00fcsteemi jaoks ja k\u00f5ik on valmis. Saate juurutada oma s\u00fcsteemi tootmisse ilma DevOps'i lisap\u00fc\u00fcdlusteta. <\/li>\n
        3. Kogu konfiguratsioonifailid<\/b> \u00fches \u00fchises hoidlas olid \u00fclevaatavad<\/b>. Hetkel, kui me juurutasime oma s\u00fcsteeme virtuaalserverite<\/a>, kasutasime Ansible'it, kus konfogid asusid samas hoidlas. Siiski oli enamikule arendajatest sellega t\u00f6\u00f6tamine m\u00f5nev\u00f5rra keerulisem. Siin on konfiguratsioonide ja koodi kogus, mida peate teenuse juurutamiseks lisama, oluliselt v\u00e4iksem. Pluss seisukohalt on DevOps'il seda v\u00e4ga lihtne parandada v\u00f5i muuta. N\u00e4iteks uue versiooniga, n\u00e4iteks Nomadiga, v\u00f5ivad nad lihtsalt ja massiliselt uuendada k\u00f5iki operatiivfailide, mis asuvad samas kohas.<\/li>\n<\/ol>\n

          \nKuid me seisime silmitsi ka mitmete puudustega: <\/p>\n

          Selgus, et me ei suutnud saavutada sujuvust juurutustes <\/b>Nomadi korral. Kui konteinerid erinevatest tingimustest v\u00e4lja vabastatakse, v\u00f5is juhtuda, et see k\u00e4ivitati ja Nomad n\u00e4gi seda kui valmisolekut liikluse vastuv\u00f5tmiseks. See juhtus veel enne, kui rakendus selle sees j\u00f5udis k\u00e4ivituda. Seet\u00f5ttu hakkas s\u00fcsteem l\u00fchikeseks ajaks andma 500-e vigu, kuna liiklus hakkas minema konteinerisse, mis ei olnud veel valmis selle vastuv\u00f5tmiseks. <\/p>\n

          Me kohtasime m\u00f5ningaid b\u00fcge<\/b>. Peamine probleem seisneb selles, et Nomad ei suuda h\u00e4sti t\u00f6\u00f6delda suurt klastrit, kui teil on palju s\u00fcsteeme ja konteinerit. Kui soovite v\u00f5tta hooldusse \u00fche serveri, mis on klastris Nomad, on \u00fcsna suur t\u00f5en\u00e4osus, et klaster ei tunne end h\u00e4sti ja puruneb t\u00fckkideks. Osa konteineritest v\u00f5ib n\u00e4iteks kukkuda ja mitte t\u00f5usta \u2014 see v\u00f5ib teile hiljem v\u00e4ga kalliks maksma minna, kui k\u00f5ik teie tootmisse kuuluvad s\u00fcsteemid asuvad just Nomadi haldusalas. <\/p>\n

          Seet\u00f5ttu otsustasime m\u00f5elda, kuhu edasi minna. Sel hetkel olime juba palju paremini teadlikud, mida tahame saavutada. Nimelt: tahame usaldusv\u00e4\u00e4rsust, natuke rohkem funktsioone kui Nomad pakub, ja k\u00fcpsemat, stabiilsemat s\u00fcsteemi. <\/p>\n

          Selles osas langetatud valik langes Kubernetes'e kasuks, kuna see on k\u00f5ige populaarsem platvorm klastrite k\u00e4itamiseks. Eriti arvestades, et meie konteinerite suurus ja arv olid piisavalt suured. Selliste eesm\u00e4rkide saavutamiseks tundus Kubernetes olevat k\u00f5ige sobivam s\u00fcsteem, mida saime vaadata. <\/p>\n

          \u00dcleminek Kubernetes'e<\/h1>\n

          \nR\u00e4\u00e4gin veidi sellest, millised on p\u00f5hikontseptsioonid Kubernetes'es ja kuidas need erinevad Nomad'st. <\/p>\n

          \"Rakenduste
          \n
          \nEsiteks on Kubernetes'e k\u00f5ige alusm\u00f5isted pod. Pod<\/b> \u2014 see on \u00fche v\u00f5i mitme konteineri grupp, mis k\u00e4ivitub alati koos. Ja nad t\u00f6\u00f6tavad justkui alati rangelt \u00fchel virtuaalsel masinal. Nad on \u00fcksteisele juurdep\u00e4\u00e4setavad IP-aadressil 127.0.0.1 erinevatel portidel. <\/p>\n

          Oletame, et teil on PHP-rakendus, mis koosneb nginx'ist ja php-fpm'ist \u2013 klassikaline skeem. T\u00f5en\u00e4oliselt soovite, et nii nginx kui php-fpm konteinerid oleksid alati koos. Kubernetes v\u00f5imaldab seda saavutada, kirjeldades neid \u00fchise pod'ina. Just seda me ei saanud Nomad'i abil.<\/p>\n

          Teine m\u00f5isted on deployment<\/b>. Asi on selles, et pod iseenesest on efemeerne asi, see k\u00e4ivitub ja kaob. Kas soovite k\u00f5igepealt tapada k\u00f5ik oma eelnevad konteinerid ja seej\u00e4rel k\u00e4ivitada kohe uued versioonid v\u00f5i soovite neid j\u00e4rk-j\u00e4rgult v\u00e4lja anda \u2013 just selle protsessi eest vastutab m\u00f5isted deployment. See kirjeldab, kuidas te oma pod\u2019e deponeerite, kui palju ja kuidas neid uuendada. <\/p>\n

          Kolmas m\u00f5isted on teenus<\/b>. Teie teenus on tegelikult teie s\u00fcsteem, mis v\u00f5tab vastu teatud liikluse ja suunab selle \u00fche v\u00f5i mitme teie teenusele vastava podi juurde. See t\u00e4hendab, et saate \u00f6elda, et kogu sissetulev liiklus selle kindla nimega teenusele tuleb suunata just nendele podidele. Ja see tagab teile ka koormuse jaotuse. Seega, kui k\u00e4ivitate kaks teie rakenduse poodi, ja kogu sisse tulev liiklus jaotatakse \u00fchtlaselt nende teenusega seotud podide vahel.<\/p>\n

          Ja neljas p\u00f5hikontseptsioon \u2014 Ingress<\/b>. See on teenus, mis k\u00e4ivitatakse Kubernetes klastris. See toimib kui v\u00e4line koormuse tasakaalustaja, mis v\u00f5tab k\u00f5ik p\u00e4ringud enda peale. Kubernetes Ingress API kaudu saab m\u00e4\u00e4ratleda, kuhu need p\u00e4ringud saatma peab. Ja ta teeb seda v\u00e4ga paindlikult. Saate \u00f6elda, et k\u00f5ik selle hosti ja kindla URL-i p\u00e4ringud saadetakse sellele teenusele. Need p\u00e4ringud, mis tulevad sellele hostile ja teisele URL-ile, saadetakse aga teisele teenusele. <\/p>\n

          K\u00f5ige \u00e4gedam asi arendaja seisukohalt on see, et saate seda k\u00f5ike ise hallata. Seades Ingressi konfiguratsiooni, saate kogu liikluse, mis tuleb kindla API-le, suunata eraldi konteineritesse, mis on n\u00e4iteks kirjutatud Go-s. Ja see liiklus, mis tuleb sama domeeni, kuid teisele URL-ile, suunatakse konteineritesse, mis on kirjutatud PHP-s, kus on palju loogikat, kuid nad ei ole eriti kiired.<\/p>\n

          Kui v\u00f5rrelda neid m\u00f5isteid Nomadi kontekstis, siis v\u00f5ib \u00f6elda, et esimesed kolm m\u00f5istet on k\u00f5ik koos teenus. Viimane m\u00f5isted Nomadi puhul aga puudub. Selle asemel kasutasime v\u00e4list koormuse tasakaalustajat: see v\u00f5ib olla haproxy, nginx, nginx+ ja nii edasi. Kube puhul ei pea te seda t\u00e4iendavat m\u00f5istet eraldi tooma. Siiski, kui vaadata Ingressi seest, siis see on kas nginx, haproxy v\u00f5i traefik, kuid nagu ka Kubernetese sisse ehitatud. <\/p>\n

          K\u00f5ik, mida ma olen kirjeldanud, on p\u00f5him\u00f5tteliselt ressursid, mis eksisteerivad Kubernetese klastris. Nende kirjeldamiseks kube'is kasutatakse yaml-formaati, mis on loetavam ja harjumusek\u00fcllasem kui HCL-failid Nomadi puhul. Kuid struktuurselt kirjeldavad need n\u00e4iteks pod-i sama asja. Nad \u00fctlevad \u2013 tahan deployida sellised pod'id sinna, koos selliste imagetega, sellises koguses. <\/p>\n

          \"Rakenduste
          \n
          \nLisaks sellele m\u00f5istsime, et me ei soovi iga eraldi ressursi k\u00e4sitsi loomisega tegeleda: deployment, teenused, Ingress jne. Selle asemel soovisime, et saaksime iga meie s\u00fcsteemi Kubernetes'e terminite j\u00e4rgi kirjeldada, et ei peaks k\u00e4sitsi k\u00f5iki vajalikke ressursi s\u00f5ltuvusi \u00f5igesse j\u00e4rjekorda taastama. Sellise s\u00fcsteemina, mis v\u00f5imaldas meil seda teha, valisime Helm. <\/p>\n

          Peamised m\u00f5isted Helm'is<\/h1>\n

          \nHelm on paketihaldur<\/b> Kubernetes'e jaoks. See sarnaneb v\u00e4ga programmikeelte paketihaldurite t\u00f6\u00f6le. Need v\u00f5imaldavad sul hoida teenust, mis koosneb n\u00e4iteks nginx'i deployment'ist, php-fpm deployment'ist, Ingress'i konfiguratsioonist, configmap'idest (see on objekt, mis v\u00f5imaldab sul m\u00e4\u00e4rata env'i ja muid parameetreid oma s\u00fcsteemi jaoks) nii-\u00f6elda chart'idena. Samal ajal t\u00f6\u00f6tab Helm Kubernetes'e kohal<\/b>. See ei ole eraldiseisev s\u00fcsteem, vaid lihtsalt veel \u00fcks teenus, mis t\u00f6\u00f6tab klusteris. Sa suhtled temaga tema API kaudu k\u00e4surea k\u00e4su abil. Tema mugavus ja ilu seisneb selles, et isegi kui helm puruneb v\u00f5i sa eemaldad selle klastrist, ei kao sinu teenused, kuna helm teenib tegelikult vaid s\u00fcsteemi k\u00e4ivitamiseks. Teenuste toimivuse ja oleku eest vastutab edaspidi Kubernetes. <\/p>\n

          Samuti m\u00f5istsime, et mallimine<\/b>, mida olime varem sunnitud ise jinja kaudu oma konfiguratsioonidesse lisama, on helm'i \u00fcks peamisi v\u00f5imalusi. K\u00f5ik konfiguratsioonid, mille sa oma s\u00fcsteemide jaoks loote, hoitakse helm'is mallidena, mis sarnanevad natuke jinja'le, kuid tegelikult kasutavad Go keele mallimist, millel helm on kirjutatud, nagu ka Kubernetes. <\/p>\n

          Helm lisab meile veel paar t\u00e4iendavat m\u00f5istet. <\/p>\n

          Diagramm<\/b> \u2014 see on sinu teenuse kirjeldus. Teistes paketihaldurites nimetataks seda paketiks, bundle'iks v\u00f5i millegiks sarnaseks. Siin kutsutakse seda chart'iks. <\/p>\n

          Values <\/b>\u2013 nad on muutujad, mida soovid kasutada oma konfiguratsioonide koostamiseks mallidest. <\/p>\n

          Release<\/b>. Iga kord, kui teenus, mis on paigaldatud helm'i abil, saab inkrementaalse versiooni vabastusest. Helm m\u00e4letab, milliseks konfiguratsioon teenus oli eelmisel, eel-eelmisel vabastamisel jne. Seet\u00f5ttu, kui on vaja tagasi minna, piisab helm callback k\u00e4skluse t\u00e4itmisest, m\u00e4\u00e4rates selle eelneva vabastuse versiooni. Isegi kui vastav konfiguratsioon teie hoidlas ei ole tagasimineku ajal saadaval, m\u00e4letab helm ikkagi, milline see oli, ja viib teie s\u00fcsteemi tagasi eelneva vabastuse olekusse. <\/p>\n

          Kui me kasutame helm'i, muutuvad tavalised konfiguratsioonid Kuberneteses samuti mallideks, kus on v\u00f5imalik kasutada muutujaid, funktsioone ja rakendada tingimuslikke operaatorite. Nii saate oma teenuse konfiguratsiooni koguda vastavalt keskkonnale.<\/p>\n

          \"Rakenduste
          \n
          \nK\u00e4 praktikas otsustasime toimida veidi teisiti kui Nomadi puhul. Kui Nomadi puhul hoiti \u00fches hoidlas nii paigalduskonfiguratsioone kui ka n-muutujaid, mis on vajalikud meie teenuse paigaldamiseks, siis siin otsustasime need eraldada kahte eraldi hoidlasse. Hoidlas \u00abdeploy\u00bb hoitakse ainult n-muutujaid, mis on vajalikud paigalduseks, ja hoidlas \u00abhelm\u00bb hoitakse konfiguratsioone v\u00f5i chart'e.<\/p>\n

          \"Rakenduste
          \n
          \nMida see meile andis? <\/p>\n

          Kuna me ei hoia endi konfiguratsioonifailides t\u00f5eliselt tundlikke andmeid, n\u00e4iteks andmebaaside paroole. Need hoitakse Kuberneteses secrets kujul, kuid seal on ikkagi eraldi asju, millele me ei taha k\u00f5igile juurdep\u00e4\u00e4su anda. Seet\u00f5ttu on juurdep\u00e4\u00e4s hoidla \u00abdeploy\u00bb rohkem piiratud, samas kui hoidla \u00abhelm\u00bb sisaldab lihtsalt teenuse kirjeldust. Selle t\u00f5ttu saab sellele ohutult anda juurdep\u00e4\u00e4su laiemale ringile. <\/p>\n

          Kuna meil on mitte ainult tootmis- vaid ka teisi keskkondi, siis t\u00e4nu sellele eraldamisele saame uuesti kasutada meie helm chart'e, et paigaldada teenuseid mitte ainult tootmisse, vaid n\u00e4iteks QA-keskkonda. Isegi nende kohapeal k\u00e4ivitamiseks kasutades Minikube<\/i> \u2014 see on selline asi kohaliku Kubernetes'e k\u00e4ivitamiseks. <\/p>\n

          Iga repootris oleme jaganud iga teenuse jaoks eraldi katalooge. See t\u00e4hendab, et iga katalooge sisaldab mallide, mis kuuluvad vastavale graafikule ja kirjeldavad ressursse, mis tuleb meie s\u00fcsteemi k\u00e4ivitamiseks juurutada. Repositooriumis \"deploy\" on meil ainult env-d. Sellisel juhul ei kasutanud me jinja kaudu mallide koostamist, kuna helm pakub mallide koostamist otse \u2013 see on \u00fcks selle p\u00f5hifunktsioone. <\/p>\n

          Olemas on juurutamiseks m\u00f5eldud skript \u2013 deploy.sh, mis lihtsustab ja standardiseerib juurutamise k\u00e4ivitamist helmiga. Seega, iga\u00fchele, kes soovib juurutada, n\u00e4eb juurutamise liides v\u00e4lja t\u00e4pselt sama, nagu see oli Nomadi kaudu juurutamisel. Sama deploy.sh, teie teenuse nimi ja koht, kuhu soovite selle juurutada. See toob kaasa, et helm k\u00e4ivitatakse. See kogub seej\u00e4rel konfiguratsioonid mallidest, asendab vajalikud value-failid ja juurutab need Kubernetesesse. <\/p>\n

          J\u00e4reldused<\/h1>\n

          \nKubernetes teenus n\u00e4eb keerulisem v\u00e4lja kui Nomad. <\/p>\n

          \"Rakenduste
          \n
          \nSiin tuleb v\u00e4ljuv liiklus Ingressi. See on t\u00e4pselt front-controller, kes v\u00f5tab k\u00f5ik p\u00e4ringud vastu ja saadab need hiljem vastavatele teenustele vastavalt p\u00e4ringu andmetele. Ta m\u00e4\u00e4rab need konfiguratsioonide p\u00f5hjal, mis on osa teie rakenduse kirjeldusest helmiga ja mida arendajad ise m\u00e4\u00e4ratlevad. Teenus saadab p\u00e4ringud oma pod-idele, st konkreetsetele konteineritele, tasakaalustades sisenevat liiklust k\u00f5ikide konteinerite vahel, mis kuuluvad antud teenusele. Ja loomulikult ei tohi unustada, et turvalisusest v\u00f5rgu tasemel ei saa me lahkuda. Seet\u00f5ttu t\u00f6\u00f6tab Kubernetes klastris segmentatsioon, mis p\u00f5hineb m\u00e4rgistamisel. K\u00f5igil teenustel on kindlad sildid, millega on seotud teenuste juurdep\u00e4\u00e4su \u00f5igused nende v\u00f5i teiste v\u00e4listest\/sisestest ressurssidest klastris v\u00f5i v\u00e4ljaspool. <\/p>\n

          Tehes olles, n\u00e4gime, et Kubernetes omab k\u00f5iki Nomadi v\u00f5imalusi, mida olime varem kasutanud, ning lisab palju uut. Seda saab laiendada pluginatega ja praktiliselt kohandatud ressursside t\u00fc\u00fcpide kaudu. See t\u00e4hendab, et teil on v\u00f5imalus mitte ainult kasutada midagi, mis tuleb Kubernetesiga standardina, vaid luua omaenda ressurss ja teenus, mis seda ressurssi loeb. See avab t\u00e4iendavad laiendusv\u00f5imalused teie s\u00fcsteemi jaoks ilma Kubernetes'e uuesti installimata ja muutusteta. <\/p>\n

          Sellise kasutamise n\u00e4iteks on Prometheus, mis t\u00f6\u00f6tab meie Kubernetes'i klastris. Selleks, et see hakkaks koguma m\u00f5\u00f5dikuid m\u00f5nest teenusest, peame teenuse kirjeldusse lisama t\u00e4iendava ressursit\u00fc\u00fcbi, nn teenuse j\u00e4lgija. Prometheus suudab peaaegu automaatselt alustada uue s\u00fcsteemi m\u00f5\u00f5dikute kogumist, kuna see oskab lugeda kohandatud ressursside t\u00fc\u00fcpe t\u00f6\u00f6tades Kubernetes'is. See on piisavalt mugav. <\/p>\n

          Esimene deploy, mille me Kubernetes'e puhul tegime, oli m\u00e4rtsis 2018. Ja selle aja jooksul pole me kunagi selle kasutamisel mingeid probleeme kogenud. See t\u00f6\u00f6tab piisavalt stabiilselt ja \u00f5igetel p\u00f5hjustel teeme otsekohe laiendusi. T\u00e4nasel p\u00e4eval on meil piisavalt v\u00f5imalusi, mis seal on, ja meile meeldivad Kubernetes'e arengukiirus. Hetkel on Kubernetes'is \u00fcle 3000 konteineri. Klaster h\u00f5lmab mitut Node'i. Samal ajal on see hallatav, stabiilne ja v\u00e4ga kontrollitav.
          \n
          Allikas:           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\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\udd47Rakenduste deploy VM-s, Nomadis ja Kubernetes'is | ProHoster","description":"Tere k\u00f5igile! Minu nimi on Pavel Agaletsky. Olen tiimijuht meeskonnas, mis arendab Lamoda kohaletoimetamismissiooni.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}