{"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-is, Nomadis ja Kuberneteses","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere k\u00f5igile! Minu nimi on Pavel Agaletski. T\u00f6\u00f6sklen tiimijuhina meeskonnas, mis arendab Lamoda tarnes\u00fcsteemi. 2018. aastal esinesin HighLoad++ konverentsil ja t\u00e4na tahan tutvustada oma ettekande transkriptsiooni.<\/p>\n

Minu teema k\u00e4sitleb meie ettev\u00f5tte kogemusi s\u00fcsteemide ja teenuste juurutamisel erinevatesse keskkondadesse. Alustades meie eelajaloolistest aegadest, kui juurutame k\u00f5ik s\u00fcsteemid tavap\u00e4rastesse virtuaalserveritesse, ja l\u00f5petades j\u00e4rkj\u00e4rgulise \u00fcleminekuga Nomadilt Kubernetesesse. R\u00e4\u00e4gin, miks me seda tegime ja milliseid probleeme meil protsessis ette tuli.<\/p>\n

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

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

\nAlustuseks olgu \u00f6eldud, et kolm aastat tagasi paigaldati k\u00f5ik ettev\u00f5tte s\u00fcsteemid ja teenused tavalistele virtuaalserveritele. Tehniliselt oli see korraldatud nii, et kogu meie s\u00fcsteemide kood oli paigutatud ja kogutud automaatse kogumise vahendite abil, kasutades Jenkinsit. Ansible'i abil viidi see meie versioonihalduss\u00fcsteemist virtuaalserveritesse. Iga s\u00fcsteem, mis oli meie ettev\u00f5ttes, paigaldati v\u00e4hemalt kahele serverile: \u00fcks neist oli head ja teine tail. Need kaks s\u00fcsteemi olid omavahel t\u00e4iesti identsed k\u00f5igi oma seadete, v\u00f5imsuse, konfiguratsiooni ja muu osas. Nende vaheliseks erinevuseks oli ainult see, et head sai kasutajate liiklust, samas kui tail ei saanud kunagi kasutajate liiklust enda peale. <\/p>\n

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

Kui me juurutame uusi versioone meie rakendusest, soovisime tagada sujuva v\u00e4ljalaskmise, see t\u00e4hendab ilma m\u00e4rgatavate tagaj\u00e4rgedeta kasutajatele. See saavutati selle kaudu, et j\u00e4rgmine komponeeritud versioon kasutades Ansible'i viidi v\u00e4lja tail. Seal said inimesed, kes tegelesid juurutamisega, kontrollida ja veenduda, et k\u00f5ik on korras: k\u00f5ik m\u00f5\u00f5dikud, jaotised ja rakendused t\u00f6\u00f6tavad; vajalikke skripte k\u00e4ivitavad. Alles p\u00e4rast seda, kui nad veendusid, et k\u00f5ik on korras, suunati liiklus. See hakkas minema sellele serverile, mis oli varem olnud tail. Ja see, mis oli olnud head, j\u00e4i kasutajaliikluse vabaks, samas kui seal oli endiselt meie rakenduse eelmine versioon.<\/p>\n

Nii oli see kasutajatele sujuv. Kuna \u00fcleminek on kohene, kuna see on lihtsalt koormuse tasakaalustaja vahetamine. V\u00e4ga lihtne on naasta eelnevale versioonile, lihtsalt vahetades koormuse tasakaalustaja tagasi. Samuti saime enne, kui kasutajaliiklus hakkab sinna j\u00f5udma, veenduda rakenduse v\u00f5imes t\u00f6\u00f6tada tootmisj\u00e4rgus, mis oli \u00fcsna mugav. <\/p>\n

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

    \n
  1. Esimene ja k\u00f5ige t\u00e4htsam on see, et see t\u00f6\u00f6tab piisavalt h\u00e4sti. Lihtsalt toimib.<\/b> Kuidas selline juurutamise skeem toimib, on k\u00f5igile selge, sest enamik inimesi on kunagi juurutanud tavalistel virtuaalserveritel.<\/li>\n
  2. See on piisavalt usaldusv\u00e4\u00e4rne<\/b>, kuna juurutustehnoloogia on lihtne ja seda on testinud tuhanded ettev\u00f5tted. Miljonid serverid juurutatakse just nii. Midagi on keeruline katki teha. <\/li>\n
  3. Ja l\u00f5puks, me saime aatomaarseid juurutamisi<\/b>. Juurutamised toimuvad kasutajate jaoks korraga, ilma n\u00e4htava \u00fcleminemise etappita vana ja uue versiooni vahel. <\/li>\n<\/ol>\n

    \nAga koos sellega n\u00e4gime ka m\u00f5ningaid puudusi: <\/p>\n

      \n
    1. Lisaks tootmiskeskkonnale ja arenduskeskkonnale, on ka teisi keskkondi, nagu qa ja eeltootmine. Sel hetkel oli meil palju servereid ja umbes 60 teenust. Seet\u00f5ttu tuli iga teenuse jaoks toetada selle jaoks asjakohast versiooni. <\/b>virtuaalmasin. Kui soovite raamatukogusid uuendada v\u00f5i uusi s\u00f5ltuvusi installida, peate seda tegema k\u00f5igis keskkondades. Samuti tuleb s\u00fcnkroniseerida aeg, millal plaanite kasutada uut versiooni oma rakendusest, aegaga, mil devops teeb vajalikud keskkonna seaded. Sellisel juhul on lihtne sattuda olukorda, kus keskkond erineb kohe k\u00f5igis j\u00e4rjestikustes keskkondades. N\u00e4iteks QA-keskkonnas on teised raamatukogade versioonid kui toodangus, mis toob kaasa probleeme. <\/li>\n
    2. S\u00f5ltuvuste uuendamise keerukus<\/b> teie rakenduse. See ei s\u00f5ltu teist, vaid teisest meeskonnast. Eelk\u00f5ige devops meeskonnast, kes toetab servereid. Peate neile esitama vastava \u00fclesande ja andma kirjelduse sellest, mida soovite teha.<\/li>\n
    3. Toll ajal soovisime ka jagada meie suured monoliidid eraldi v\u00e4ikesteks teenusteks, kuna m\u00f5istsime, et neid tuleb j\u00e4rjest juurde. Sel ajal oli meil neid juba \u00fcle 100. Iga uue teenuse jaoks tuli luua eraldi uus virtuaalmasin, mida tuli ka teenindada ja k\u00e4ivitada. Peale selle ei piisanud \u00fchest masinast, vaid v\u00e4hemalt kahest oli vajalik. K\u00f5igile sellele lisandus QA-keskkond. See tekitab probleeme ja muudab uute s\u00fcsteemide loomise ja k\u00e4ivitamise keerulisemaks, kulukamaks ja aegan\u00f5udvamaks. protsessiks.<\/b><\/li>\n<\/ol>\n

      \nSeet\u00f5ttu otsustasime, et oleks mugavam \u00fcle minna tavaliste virtuaalmasinate juurutamiselt rakenduste juurutamisele Docker-konteineris. Dockeriga on vajalik s\u00fcsteem, mis suudab rakendust klastris k\u00e4ivitada, kuna konteinerit ei saa lihtsalt \u00fcles t\u00f5sta. Tavaliselt soovite j\u00e4lgida, kui palju konteinerit on \u00fcles t\u00f5stetud, et need t\u00f5useksid automaatselt. Seet\u00f5ttu tuli valida halduss\u00fcsteem. <\/p>\n

      Oleme pikka aega m\u00f5elnud, millist neist valida. Asi on selles, et toona oli meie tavalistele virtuaalserveritele m\u00f5eldud juurdep\u00e4\u00e4suhulk pisut vananenud, kuna seal olid mitte k\u00f5ige v\u00e4rskema versioonidega operatsioonis\u00fcsteemid. \u00dchel hetkel oli seal isegi FreeBSD, mida oli \u00fcsna ebamugav hallata. M\u00f5istsime, et peame kiiresti Dockerisse migreeruma. Meie DevOps vaatles oma olemasolevat kogemust erinevate lahendustega ja valis s\u00fcsteemi nimega Nomad. <\/p>\n

      \u00dcleminek Nomadile<\/h1>\n

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

      \"Rakenduste
      \n
      \n\u00abConsul\u00bb<\/b> on teenuste avastamise t\u00f6\u00f6riist.<\/p>\n

      \u00abTerraform\u00bb<\/b> on serverihalduse s\u00fcsteem, mis v\u00f5imaldab teil neid konfigureerida koodi kaudu, nn infrastructure-as-a-code.<\/p>\n

      \u00abVagrant\u00bb<\/b> v\u00f5imaldab teil lokaliseerida virtuaalmaju v\u00f5i pilves, kasutades teatud konfiguratsioonifailide seadeid. <\/p>\n

      Nomad n\u00e4is sel hetkel olevat piisavalt lihtne lahendus, kuhu saab kiiresti \u00fcle minna ilma kogu infrastruktuuuri muutmata. Lisaks on selle kasutamine piisavalt lihtne. Seet\u00f5ttu valisimegi selle meie konteineri filtreerimiss\u00fcsteemiks. <\/p>\n

      Mida on vaja, et \u00fcldse oma s\u00fcsteem Nomadis k\u00e4ivitada? <\/p>\n

        \n
      1. Esiteks on vajalik docker image<\/b> teie rakenduse jaoks. See tuleb koostada ja paigutada docker'i pildihoidlasse. Meie puhul on see artifactory \u2014 s\u00fcsteem, mis v\u00f5imaldab erinevat t\u00fc\u00fcpi artefakte sinna \u00fcles laadida. See suudab hoida arhiive, docker'i pilte, PHP composer pakette, NPM pakette jne. <\/li>\n
      2. Samuti on vajalik konfigureerimisfaili<\/b>, mis \u00fctleb Nomadile, mida, kuhu ja millisest kogusest soovite k\u00e4ivitada. <\/li>\n<\/ol>\n

        \nKui r\u00e4\u00e4gime Nomadist, siis kasutab see teavefaili formaadina HCL keelt, mis t\u00e4histab HashiCorp Configuration Language<\/i>. See on Yaml'i \u00fclekomplekteeritud versioon, mis v\u00f5imaldab teil oma teenust Nomadi m\u00f5istes kirjeldada. <\/p>\n

        \"Rakenduste
        \n
        \nSee v\u00f5imaldab m\u00e4\u00e4rata, kui palju konteinerit soovite kasutusele v\u00f5tta, millistest piltidest edastada neile erinevad parameetrid kasutuse v\u00f5tmisel. Nii anda fail Nomad'ile, mis k\u00e4ivitab konteinerid vastavalt sellele tootmises. <\/p>\n

        Meie juhul m\u00f5istsime, et lihtsalt iga teenuse jaoks t\u00e4iesti identsete HCL-failide kirjutamine ei ole eriti mugav, kuna teenuseid on palju ja neid on m\u00f5nikord soov uuendada. Juhtub, et \u00fcks teenus ei ole kasutusele v\u00f5etud \u00fches eksemplaris, vaid mitmes erinevas. N\u00e4iteks on \u00fcks s\u00fcsteem, mis meil tootmises on, \u00fcle 100 instantsi tootmises. Need k\u00e4ivituvad sama piltidest, kuid erinevad konfiguratsiooniseadete ja konfiguratsioonifailide poolest. <\/p>\n

        Seet\u00f5ttu otsustasime, et on mugav hoida k\u00f5ik meie rakenduseks vajalikud konfiguratsioonifailid \u00fches \u00fchises hoidlas. Nii saavad need olema \u00fclevaatlikud: neid on lihtne hallata ja n\u00e4ha, millised s\u00fcsteemid meil olemas on. Kui on vajalik, on ka lihtne midagi uuendada v\u00f5i vahetada. Uue s\u00fcsteemi lisamine on samuti vaevatu \u2014 piisab lihtsalt uue katalooge lisamisest koos konfiguratsioonifailiga. Selle sees asuvad failid: service.hcl, mis sisaldab meie teenuse kirjeldust, ning m\u00f5ned env-failid, mis v\u00f5imaldavad seda teenust, olles produtseeritud, seadistada. <\/p>\n

        \"Rakenduste
        \n
        \nKuid m\u00f5ned meie s\u00fcsteemid on produtseeritud mitte \u00fches ekskemplaris, vaid mitmes korraga. Seet\u00f5ttu otsustasime, et on mugav salvestada mitte puhtad konfiguratsioonid, vaid nende malliversioonid. Ja mallikeeleks valisime jinja 2<\/i>. Selles formaadis hoitakse nii teenuse konfiguratsioone kui ka vajalikku env-failide komplekti. <\/p>\n

        Lisaks sellele oleme k\u00f5ikide projektide jaoks \u00fchisesse reposse paigaldanud skriptide juurutamise, mis v\u00f5imaldab teie teenust k\u00e4ivitada ja juurutada tootmises, soovitud keskkonnas, soovitud sihtpunktis. Juhul, kui oleme oma HCL-konfiguratsiooni muutnud malliks, n\u00e4eb see HCL-fail, mis varem oli tavaline Nomadi konfiguratsioon, n\u00fc\u00fcd veidi erinev v\u00e4lja.<\/p>\n

        \"Rakenduste
        \n
        \nSee t\u00e4hendab, et oleme asendanud m\u00f5ned konfigureerimise muutuja kohad variatsioonidega, mis saadakse keskkonna failidest v\u00f5i teistest allikatest. Lisaks sellele oleme saanud v\u00f5imaluse koguda HCL-faile d\u00fcnaamiliselt, st v\u00f5ime rakendada mitte ainult tavalisi muutuja sisestusi. Kuna jinja toetab ts\u00fckleid ja tingimusi, saab sinna luua ka konfigureerimisfaile, mis muutuvad s\u00f5ltuvalt sellest, kuhu t\u00e4pselt oma rakendusi juurutate. <\/p>\n

        N\u00e4iteks, kui soovite oma teenust eeltootmisse ja tootmisse panna. Oletame, et eeltootmises ei soovi te k\u00e4ivitada cron-skripte, vaid lihtsalt n\u00e4ha teenust eraldi domeenil, et veenduda, et see t\u00f6\u00f6tab. Iga\u00fche jaoks, kes teenust juurutab, tundub protsess v\u00e4ga lihtne ja l\u00e4bipaistev. Piisab, kui k\u00e4itada fail deploy.sh, n\u00e4idata, millist teenust soovite juurutada ja millisesse sihtkohta. N\u00e4iteks, kui soovite juurutada m\u00f5nda s\u00fcsteemi Venemaale, Valgevenesse v\u00f5i Kasahstani. Selleks piisab lihtsalt \u00fche parameetri muutmisest ja teil on \u00f5ige konfiguratsioonifail valmis. <\/p>\n

        Kui teenus Nomad on teie klastris juba juurutatud, n\u00e4eb see v\u00e4lja j\u00e4rgmine.<\/p>\n

        \"Rakenduste
        \n
        \nEsiteks vajate v\u00e4list tasakaalustajat, mis v\u00f5tab kogu kasutajaliikluse enda peale. See t\u00f6\u00f6tab koos Consuliga ja k\u00fcsib temalt, kus, millisel s\u00f5lmel ja millise IP-aadressi<\/a> on olemas konkreetne teenus, mis vastab sellele v\u00f5i teisele domeeninimele. Teenused Consulis ilmuvad otse Nomadist. Kuna need on sama ettev\u00f5tte tooted, on need omavahel h\u00e4sti seotud. V\u00f5ib \u00f6elda, et Nomad suudab vaikimisi registreerida k\u00f5ik selle sees k\u00e4ivituvad teenused Consuli sees. <\/p>\n

        Kui teie v\u00e4line tasakaalustaja teab, kuhu teenusesse liiklus suunata, suunab ta selle vastavasse konteinerisse v\u00f5i mitmesse konteinerisse, mis vastavad teie rakendusele. Loomulikult tuleb samal ajal m\u00f5elda ka turvalisusele. Isegi kui k\u00f5ik teenused k\u00e4ivitatakse \u00fchesugustes virtuaalmasinates konteinerites, on tavaliselt vajalik keelata vabaks juurdep\u00e4\u00e4suks \u00fcksk\u00f5ik millisest teenusest \u00fcksk\u00f5ik millisele teisele. Oleme seda saavutanud segmentimise kaudu. Iga teenus k\u00e4ivitati oma virtuaalses v\u00f5rgus, kus olid m\u00e4\u00e4ratud marsruutimise reeglid ja juurdep\u00e4\u00e4su lubamise\/keelamise reeglid teistele s\u00fcsteemidele ja teenustele. Need v\u00f5isid asuda nii selle klastre sees kui ka v\u00e4ljaspool seda. N\u00e4iteks, kui soovite keelata teenusel teatud andmebaasi \u00fchenduse loomise, saab seda teha segmenteerimise kaudu v\u00f5rgu tasemel. See t\u00e4hendab, et isegi ekslikult ei saa te testkeskkonnast teie tootmisandmebaasi juhuslikult \u00fchenduda.<\/p>\n

        Kui palju maksma l\u00e4ks meespetsialistide ressursi \u00fclemineku protsess? <\/p>\n

        Ettevaatuslikult kulus kogu ettev\u00f5tte \u00fcleminek Nomadi peale umbes 5\u20136 kuud. \u00dcleminek toimus teenuse kaupa, kuid piisavalt kiirelt. Iga meeskond pidi looma oma teenuste jaoks oma konteinerid. <\/p>\n

        Meil on selline l\u00e4henemine, et iga meeskond vastutab oma s\u00fcsteemide docker-piltide eest iseseisvalt. DevOps pakub \u00fcldiselt vajalikku infrastruktuuri, mis on vajalik juurutamiseks, sealhulgas klastritoe, CI-s\u00fcsteemi toe jne. Ja tol ajal oli meil rohkem kui 60 s\u00fcsteemi, mis olid Nomadi peale \u00fcle viidud, kokku oli umbes 2000 konteinerit. <\/p>\n

        DevOps vastutab kogu juurutamise ja serveritega seotud \u00fcldise infrastruktuuri eest. Iga arendustiim on vastutav oma konkreetse s\u00fcsteemi konteinerite rakendamise eest, kuna just meeskond teab, mida tal konkreetses konteineris \u00fcldse vaja on.<\/p>\n

        P\u00f5hjused Nomadist loobumiseks<\/h1>\n

        \nMillised eelised me saime, kui l\u00e4ksime \u00fcle Nomadi ja Dockeriga juurutamisele?<\/p>\n

          \n
        1. Meie tagasime \u00fchtlased tingimused<\/b> k\u00f5ikides keskkondades. Arenduses, QA-keskkonnas, eess\u00fcndmuses ja tootmisprotsessis kasutatakse samu konteineri pilte, samade s\u00f5ltuvustega. Seega on teil peaaegu pole v\u00f5imalust, et tootmisesse satub midagi, mida te ei ole varem lokaalselt v\u00f5i testkeskkonnas testinud. <\/li>\n
        2. Samuti oleme leidnud, et on piisavalt lihtne lisada uus teenus<\/b>. Igasugused uued s\u00fcsteemid k\u00e4ivituvad rakendamise vaatenurgast v\u00e4ga lihtsalt. Piisab minna seadistusi hoidvasse reposse, lisada sinna j\u00e4rgmine konfiguratsioon teie s\u00fcsteemi jaoks, ja k\u00f5ik on valmis. Saab teha teie s\u00fcsteemi tootmisse ilma DevOps'i t\u00e4iendava pingutuseta. <\/li>\n
        3. K\u00f5ik konfiguratsioonifailid<\/b> \u00fches \u00fchises reposes olid \u00fclevaatavad<\/b>. Hetkel, kui me rakendasime meie s\u00fcsteeme koos virtuaalservereid<\/a>, me kasutasime Ansible't, kus konfiguratsioonid olid samas hoidlas. Kuid enamik arendajatest leidis selle kasutamise natuke keeruliseks. Siin on konfiguratsioonide ja koodi maht, mida peate teenuse juurutamiseks lisama, oluliselt v\u00e4henenud. Lisaks on DevOps'il lihtne neid muuta v\u00f5i parandada. N\u00e4iteks versioonide vahetamisel, nagu uue versiooni puhul Nomad's, saavad nad massiliselt uuendada k\u00f5iki operatsioonifailide, mis asuvad samas kohas.<\/li>\n<\/ol>\n

          \nAga me kohtasime ka m\u00f5ningaid puudusi: <\/p>\n

          Selgus, et me ei suutnud saavutada sujuvat juurutamist <\/b>Nomad'i puhul. Kui konteinerid k\u00e4ivitati erinevate tingimustega, v\u00f5is juhtuda, et see k\u00e4ivitus ja Nomad n\u00e4gi seda kui liiklusele vastuv\u00f5etavat konteinerit. See juhtus juba enne, kui rakendus selle sees j\u00f5udis k\u00e4ima minna. Selle t\u00f5ttu hakkas s\u00fcsteem l\u00fchikese aja jooksul andma 500. vigu, kuna liiklus hakkas minema konteinerisse, mis ei olnud veel valmis seda vastu v\u00f5tma. <\/p>\n

          Me kohtasime m\u00f5ningaid vea<\/b>. K\u00f5ige olulisem probleem on see, et Nomad ei suuda h\u00e4sti hallata suurt klastrit, eriti kui teil on palju s\u00fcsteeme ja konteinerit. Kui soovite v\u00f5tta hooldusse \u00fche serveri, mis kuulub Nomadi klastrisse, on piisavalt suur t\u00f5en\u00e4osus, et klaster ei tunne end h\u00e4sti ja laguneb. Osad konteinerid v\u00f5ivad n\u00e4iteks eba\u00f5nnestuda ja mitte taastuda \u2014 see v\u00f5ib teid hiljem kalliks maksma minna, kui k\u00f5ik teie tootmiss\u00fcsteemid asuvad just Nomadi hallatavas klastris. <\/p>\n

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

          Selles osas langetati meie valik Kubernetes'e kasuks kui k\u00f5ige populaarsema platvormi, et k\u00e4itada klastreid. Eriti arvestades seda, et meie konteinerite suurus ja arv olid piisavalt suured. Selliste eesm\u00e4rkide saavutamiseks tundus Kubernetes k\u00f5ige sobivama s\u00fcsteemina, mida me vaadates leidsime. <\/p>\n

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

          \nNatuke r\u00e4\u00e4gin, millised on Kubernetes'i p\u00f5hikontseptsioonid ja kuidas need erinevad Nomadist. <\/p>\n

          \"Rakenduste
          \n
          \nEsiteks on Kubernetes'i k\u00f5ige p\u00f5hilisem m\u00f5isted pod. Pod<\/b> on r\u00fchm \u00fchest v\u00f5i mitmest konteinerist, mis k\u00e4ivitatakse alati koos. Need t\u00f6\u00f6tavad nagu nad oleksid alati kindlal virtuaalmasinal. Nad on omavahel juurdep\u00e4\u00e4setavad aadressi 127.0.0.1 kaudu erinevatele portidele. <\/p>\n

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

          Teine m\u00f5isted on deployment<\/b>. Asi on selles, et pod ise on efemeerne asi, see k\u00e4ivitub ja kaob. Kas soovite k\u00f5igepealt l\u00f5petada k\u00f5ik teie eelnevad konteinerid ja seej\u00e4rel korraga k\u00e4ivitada uued versioonid v\u00f5i soovite neid j\u00e4rk-j\u00e4rgult kasutada \u2013 selle protsessi eest vastutab deployment m\u00f5isted. See kirjeldab, kuidas te oma pod'e juurutate, kui palju ning kuidas neid uuendada. <\/p>\n

          Kolmas m\u00f5isted on teenus<\/b>. Teie teenus on sisuliselt teie s\u00fcsteem, mis v\u00f5tab vastu teatud liikluse ja suunab selle siis \u00fchele v\u00f5i mitmele podile, mis vastavad teie teenusele. See t\u00e4hendab, et saate m\u00e4\u00e4rata, et kogu sissetulev liiklus teatud nimega teenusele tuleb suunata just nendele podidele. Samuti tagab see teile liikluse tasakaalustamise. Seega v\u00f5ite k\u00e4ivitada kaks teie rakenduse podi, ning kogu sissetulev liiklus jaotatakse v\u00f5rdselt nende teenusele kuuluvate podide vahel.<\/p>\n

          Ja neljas p\u00f5hikontseptsioon \u2014 Ingress<\/b>. See on teenus, mis k\u00e4ivitatakse Kubernetes'i klastris. See toimib v\u00e4lise koormuse tasakaalustajana, mis v\u00f5tab endale k\u00f5ik p\u00e4ringud. Kubernetes Ingress API abil saab m\u00e4\u00e4rata, kuhu need p\u00e4ringud suunata. Ta teeb seda v\u00e4ga paindlikult. Saate m\u00e4\u00e4rata, et k\u00f5ik p\u00e4ringud sellest hostist ja sellisest URL-ist saadetakse sellele teenusele. Ja need p\u00e4ringud, mis tulevad sellele hostile ja teisele URL-ile, saadetakse teisele teenusele. <\/p>\n

          Arendaja jaoks on k\u00f5ige \u00e4gedam asi see, et saate seda k\u00f5ike iseseisvalt hallata. Kui seadistate Ingressi konfiguratsiooni, v\u00f5ite kogu liikluse, mis siseneb teatud API-le, suunata eraldi konteineritesse, mis on n\u00e4iteks kirjutatud Go-s. Ja sellel samal domeenil liikluse suunamine teisele URL-ile v\u00f5ib viia konteineritesse, mis on kirjutatud PHP-s, kus on palju loogikat, kuid need ei ole eriti kiired.<\/p>\n

          Kui v\u00f5rrelda neid m\u00f5isted Nomadiga, siis v\u00f5ib \u00f6elda, et esimesed kolm m\u00f5istet moodustavad koos \u00fche teenuse. Kuid viimane m\u00f5iste ei ole Nomadis olemas. Selle asemel kasutasime me v\u00e4list tasakaalustajat: see v\u00f5ib olla haproxy, nginx, nginx+ ja nii edasi. Kubermetide puhul ei pea te seda t\u00e4iendavat m\u00f5istet eraldi tutvustama. Siiski, kui vaadata Ingressi seest, siis on see kas nginx, haproxy v\u00f5i traefik, kuid nagu oleks see Kubernetesesse sisseehitatud. <\/p>\n

          K\u00f5ik minu kirjeldatud m\u00f5isted on tegelikult ressursid, mis eksisteerivad Kuberneteses klastris. Nende kirjeldamiseks kasutatakse YAML-formaati, mis on loetavam ja tuttavam kui HCL-failid Nomadi puhul. Kuid struktuurilt kirjeldavad nad n\u00e4iteks podi sama asja. Nad \u00fctlevad \u2013 soovin juurutada sellised podid sinna, selliste imid\u017eidega, sellises koguses. <\/p>\n

          \"Rakenduste
          \n
          \nLisaks sellele m\u00f5istsime, et me ei soovi k\u00e4sitsi luua iga eraldi ressursi: juurutamisi, teenuseid, Ingressit ja muud. Selle asemel soovisime juurutamisel kirjeldada iga meie s\u00fcsteemi, mis eksisteerib Kubernetes termini kohaselt, et ei peaks k\u00e4sitsi uuesti looma k\u00f5iki vajalikke resursside s\u00f5ltuvusi \u00f5iges j\u00e4rjekorras. Sellise s\u00fcsteemi, mis v\u00f5imaldas meil seda teha, valisime Helm. <\/p>\n

          Helmi p\u00f5h m\u00f5isted<\/h1>\n

          \nHelm on paketihaldur<\/b> Kubernetesi jaoks. See sarnaneb v\u00e4ga pakettide halduritega programmeerimiskeeltes. Need v\u00f5imaldavad teil salvestada teenuse, mis koosneb n\u00e4iteks nginxi deploymentist, php-fpmi deploymentist, Ingressi konfiguratsioonist, configmapsist (see on entiteet, mis v\u00f5imaldab teil m\u00e4\u00e4ratleda keskkonna ja muid parameetreid teie s\u00fcsteemis) nii nimetatud chartide kujul. Sellega seoses on Helm Kubernetesi peal.<\/b>. See t\u00e4hendab, et see ei ole m\u00f5ni eraldi s\u00fcsteem, vaid lihtsalt veel \u00fcks teenus, mis k\u00e4ivitub klastris. Te suhtlete temaga tema API kaudu k\u00e4sureak\u00e4skude kaudu. Selle mugavus ja ilu seisneb selles, et isegi kui helm l\u00e4heb katki v\u00f5i kustutate selle klastrist, ei kao teie teenused, kuna helm teenib p\u00f5him\u00f5tteliselt vaid s\u00fcsteemi k\u00e4ivitamiseks. Tal on vastutus teenuste t\u00f6\u00f6kindluse ja seisundi eest edasi Kubernetes. <\/p>\n

          Samuti oleme m\u00f5istnud, et mallimine<\/b>, mille tehti ise l\u00e4bi jinja rakendamise meie konfiguratsioonides, on helm \u00fcks peamisi funktsioone. K\u00f5ik konfiguratsioonid, mida loote oma s\u00fcsteemide jaoks, salvestatakse helm'is mallidena, mis on sarnased jinja'le, kuid tegelikult kasutavad Go keele mallimist, milles helm on kirjutatud, nagu ka Kubernetes. <\/p>\n

          Helm lisab meile veel m\u00f5ningaid t\u00e4iendavaid m\u00f5isted. <\/p>\n

          Chart<\/b> \u2014 on teie teenuse kirjeldus. Teistes pakihaldurites kutsutakse seda paketiks, bundle'iks v\u00f5i millegiks sarnaseks. Siin nimetatakse seda chart'iks. <\/p>\n

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

          Release<\/b>. Iga kord, kui teenus, mida haldab helm, saab inkrementaalse versiooni v\u00e4ljaandest. Helm m\u00e4letab, milline oli teenuse konfigureerimine eelmisel, \u00fcleelmisel v\u00e4ljaandel jne. Seet\u00f5ttu, kui on vaja tagasi minna, piisab helm callback k\u00e4su t\u00e4itmisest, osutades sellele eelnevale v\u00e4ljaande versioonile. I even if at the time of rollback the corresponding configuration in your repository is not available, helm still remembers what it was and will revert your system to the state it was in the previous release. <\/p>\n

          Juhul, kui kasutame helm'i, muutuvad tavalised Kubernetes'i konfgid ka mallideks, kus on v\u00f5imalik kasutada muutujaid, funktsioone ja rakendada tingimuslikke operaatoreid. Nii saate oma teenuse konfigureerimist \u00fcles ehitada s\u00f5ltuvalt keskkonnast.<\/p>\n

          \"Rakenduste
          \n
          \nPraktiliselt otsustasime toimida veidi teisiti kui Nomadi puhul. Kui Nomadis hoiti \u00fches repertuaaris nii deploymenti konfiguratsioone kui ka n-muutujaid, mis on vajalikud meie teenuse rakendamiseks, siis siin otsustasime need jagada kaheks eraldi repertuaariks. Repertuaaris \"deploy\" hoitakse ainult n-muutujaid, mis on vajalikud deploymentiks, ja repertuaaris \"helm\" hoitakse konfiguratsioone v\u00f5i chart'e.<\/p>\n

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

          Kuigi me ei hoia enda konfiguratsioonifailides t\u00f5eliselt tundlikke andmeid, n\u00e4iteks andmebaasi paroole, mis on salvestatud Kuberneteses secrets'ina, on seal siiski eraldi asju, millele me ei soovi, et k\u00f5ik p\u00e4\u00e4seksid ligi. Seet\u00f5ttu on juurdep\u00e4\u00e4s repertuaarile \"deploy\" rohkem piiratud, samas kui repertuaar \"helm\" sisaldab lihtsalt teenuse kirjelduse. Sel p\u00f5hjusel saab sellele anda ligip\u00e4\u00e4su turvaliselt laiemale ringile inimestele. <\/p>\n

          Kuna meil on mitte ainult tootmis-, vaid ka teised keskkonnad, saame sellise jaotuse t\u00f5ttu taaskasutada meie helm-chart'e, et juurutada teenuseid mitte ainult tootmises, vaid ka n\u00e4iteks QA-keskkonnas. Isegi nende lokaalset k\u00e4ivitamist silmas pidades, kasutades Minikube<\/i> \u2014 see on selline t\u00f6\u00f6riist, mis v\u00f5imaldab k\u00e4ivitada Kubernetes'e kohapeal. <\/p>\n

          Iga repositooriumi sees oleme j\u00e4tnud jagunemise eraldi kaustadesse iga teenuse jaoks. See t\u00e4hendab, et iga kausta sees on malli, mis kuulub vastavasse chart'i ja kirjeldab neid ressursside, mille juurutamine on vajalik meie s\u00fcsteemi k\u00e4ivitamiseks. Repositooriumis \u201edeploy\u201d oleme j\u00e4tnud ainult keskkondade muutujad. Sellisel juhul ei kasutanud me templaatimist jinja abil, kuna helm pakub ise templaatimist v\u00e4lja pakkumisel \u2013 see on \u00fcks selle p\u00f5hifunktsioone. <\/p>\n

          Oleme j\u00e4tnud deployimiseks skripti \u2013 deploy.sh, mis lihtsustab ja standardiseerib helm'i kaudu k\u00e4ivitamise. Nii n\u00e4eb deployimise liides v\u00e4lja t\u00e4pselt sama, nagu see oli Nomad'i kaudu deployides. Sama deploy.sh, teie teenuse nimi ja koht, kuhu soovite selle paigutada. See toob kaasa helm'i k\u00e4ivitamise. See omakorda kogub seadistused mallidest, sisestab vajalikud value-failid ja seej\u00e4rel viib need Kubernetesesse. <\/p>\n

          J\u00e4reldused<\/h1>\n

          \nKubernetes'i teenus tundub keerulisem kui Nomad. <\/p>\n

          \"Rakenduste
          \n
          \nSiin suunatakse v\u00e4ljaminev liiklus Ingressisse. See on just see eesmine kontroller, mis v\u00f5tab vastu k\u00f5ik p\u00e4ringud ja suunab need vastavatesse teenustesse, mis p\u00f5hinevad p\u00e4ringu andmetel. Ta m\u00e4\u00e4rab need konfiguratsioonide alusel, mis on osa teie rakenduse kirjeldusest helm'is ja mille arendajad m\u00e4\u00e4ravad ise. Teenus suunab p\u00e4ringud oma pod'idele, st konkreetsetele konteineritele, tasakaalustades sissetulevat liiklust k\u00f5ikide nende konteinerite vahel, mis kuuluvad antud teenusele. Ja muidugi ei tohi unustada, et v\u00f5rgu tasemel turvalisusest ei tohi k\u00f5rvale kalduda. Seet\u00f5ttu on Kubernetes klasteris segmenteerimine, mis p\u00f5hineb siltide m\u00e4\u00e4ramisel. K\u00f5igil teenustel on teatud sildid, millega on seotud teenuste juurdep\u00e4\u00e4su \u00f5igused erinevatele v\u00e4listingimustes v\u00f5i sisetingimustes olevatele ressurssidele klastris. <\/p>\n

          \u00dcleminekut tehes n\u00e4gime, et Kubernetes omab k\u00f5iki Nomadi v\u00f5imalusi, mida olime varem kasutanud, ja lisab palju uut. Seda saab laiendada l\u00e4bi pluginade ning tegelikult ka kohandatud ressursit\u00fc\u00fcpide kaudu. See t\u00e4hendab, et teil on v\u00f5imalus mitte ainult kasutada seda, mis tuleb Kubernetesiga kaasa, vaid luua oma ressurss ja teenus, mis seda ressursi loeb. See pakub t\u00e4iendavaid laiendamisv\u00f5imalusi teie s\u00fcsteemi ilma Kubernetesit uuesti installimata ja ilma muudatusteta. <\/p>\n

          \u00dche sellise kasutuse n\u00e4ide on Prometheus, mis t\u00f6\u00f6tab meie Kubernetes klastris. Et see hakkaks koguma m\u00f5\u00f5dikute teavet m\u00f5nest teenusest, peame teenuse kirjeldusele lisama t\u00e4iendava ressursit\u00fc\u00fcbi, nn teenuse monitori. Prometheus, olles k\u00e4ivitatud Kuberneteses ja osates lugeda kohandatud ressursit\u00fc\u00fcpe, hakkab automaatselt koguma m\u00f5\u00f5dikute teavet uue s\u00fcsteemi kohta. See on piisavalt mugav. <\/p>\n

          Meie esimene Kubernetes'e deploy toimus m\u00e4rtsis 2018. Aja jooksul ei ole me sellega kunagi probleeme olnud. See t\u00f6\u00f6tab piisavalt stabiilselt, ilma oluliste t\u00f5rgeteta. Lisaks saame seda ka edasi laiendada. T\u00e4na piisab meile hetkel olemasolevatest v\u00f5imalustest, ja meeldib v\u00e4ga, kui kiiresti Kubernetes areneb. Praegu on Kubernetes'is \u00fcle 3000 konteineri. Klaster h\u00f5lmab mitmeid Node'e. Samas on see hooldatav, 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, Nomad'is ja Kubernetes'is | ProHoster","description":"Tere k\u00f5igile! Minu nimi on Pavel Agaletski. T\u00f6\u00f6tab tiimijuhina meeskonnas, mis arendab Lamoda tarnes\u00fcsteemi. 2018. aastal esinesin konverentsil HighLoad++, ja t\u00e4na soovin esitleda oma ettekande transkriptsiooni. Minu teema k\u00e4sitleb meie ettev\u00f5tte kogemusi s\u00fcsteemide ja teenuste sutitamisel erinevatesse keskkondadesse. Alustades meie eelhistorii ajast, mil me deploysime k\u00f5iki s\u00fcsteeme.","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. \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","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"},"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}]}}