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

Hej alla! Jag heter Pavel Agaletsky. Jag arbetar som teamledare i ett team som utvecklar Lamodas leveranssystem. \u00c5r 2018 talade jag p\u00e5 konferensen HighLoad++, och idag vill jag presentera en transkription av mitt f\u00f6redrag.<\/p>\n

Min \u00e4mne handlar om v\u00e5r f\u00f6retags erfarenhet av att distribuera system och tj\u00e4nster i olika milj\u00f6er. Fr\u00e5n v\u00e5ra f\u00f6rhistoriska tider, n\u00e4r vi distribuerade alla system p\u00e5 vanliga virtuella servrar, till den gradvisa \u00f6verg\u00e5ngen fr\u00e5n Nomad till distribution i Kubernetes. Jag kommer att ber\u00e4tta om varf\u00f6r vi gjorde detta och vilka problem vi hade under processen.<\/p>\n

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

Distribution av applikationer p\u00e5 VM<\/h1>\n

\nVi b\u00f6rjar med att konstatera att f\u00f6r tre \u00e5r sedan distribuerades alla f\u00f6retagets system och tj\u00e4nster p\u00e5 vanliga virtuella servrar. Tekniskt sett organiserades det s\u00e5 att all kod f\u00f6r v\u00e5ra system l\u00e5g och byggdes via automatiserad byggprocess med hj\u00e4lp av Jenkins. Med Ansible distribuerades den fr\u00e5n v\u00e5rt versionskontrollsystem till de virtuella servrarna. Varje system som fanns i v\u00e5rt f\u00f6retag distribuerades p\u00e5 minst tv\u00e5 servrar: en av dem var head och den andra var tail. Dessa tv\u00e5 system var helt identiska med avseende p\u00e5 alla sina inst\u00e4llningar, kapacitet, konfiguration och s\u00e5 vidare. Skillnaden mellan dem var endast att head tog emot anv\u00e4ndartj\u00e4nst, medan tail aldrig fick n\u00e5got anv\u00e4ndartrafik. <\/p>\n

Varf\u00f6r gjorde vi detta? <\/p>\n

N\u00e4r vi distribuerade nya versioner av v\u00e5r applikation ville vi s\u00e4kerst\u00e4lla att det fanns en s\u00f6ml\u00f6s distribution, det vill s\u00e4ga utan m\u00e4rkbara konsekvenser f\u00f6r anv\u00e4ndarna. Detta uppn\u00e5ddes genom att den senaste sammanst\u00e4llda versionen med hj\u00e4lp av Ansible distribuerades till tail. D\u00e4r kunde de personer som ansvarade f\u00f6r distributionen kontrollera och se till att allt fungerade bra: alla m\u00e4tv\u00e4rden, sektioner och applikationer fungerade; n\u00f6dv\u00e4ndiga skript k\u00f6rdes. Endast efter att de var \u00f6vertygade om att allt var i ordning, v\u00e4xlades trafiken. Den b\u00f6rjade g\u00e5 till den server som tidigare var tail. Och den som tidigare var head f\u00f6rblev utan anv\u00e4ndartj\u00e4nst, men hade den tidigare versionen av v\u00e5r applikation.<\/p>\n

D\u00e4rmed var det s\u00f6ml\u00f6st f\u00f6r anv\u00e4ndarna. Eftersom v\u00e4xlingen \u00e4r omedelbar, d\u00e5 det bara handlar om att byta lastbalanserare. Det \u00e4r mycket enkelt att \u00e5terg\u00e5 till en tidigare version genom att helt enkelt byta tillbaka lastbalanseraren. Vi kunde ocks\u00e5 f\u00f6rs\u00e4kra oss om applikationens kapabiliteter i produktion innan den fick anv\u00e4ndartrafik, vilket var ganska bekv\u00e4mt. <\/p>\n

Vilka f\u00f6rdelar s\u00e5g vi i allt detta?<\/p>\n

    \n
  1. Framf\u00f6r allt \u00e4r det ganska enkelt att f\u00e5 det att fungera.<\/b> Det \u00e4r tydligt f\u00f6r alla hur ett s\u00e5dant distributionsschema fungerar, eftersom de flesta m\u00e4nniskor har distribuerat p\u00e5 vanliga virtuella servrar n\u00e5gon g\u00e5ng.<\/li>\n
  2. Det \u00e4r ganska p\u00e5litligt<\/b>, eftersom distributionsmetoden \u00e4r enkel och har pr\u00f6vats av tusentals f\u00f6retag. Miljoner servrar distribueras p\u00e5 detta s\u00e4tt. Det \u00e4r sv\u00e5rt att bryta n\u00e5got. <\/li>\n
  3. Och slutligen kunde vi f\u00e5 atom\u00e4ra distributioner<\/b>. Distributioner som sker f\u00f6r anv\u00e4ndarna samtidigt, utan en m\u00e4rkbar \u00f6verg\u00e5ng mellan den gamla och nya versionen. <\/li>\n<\/ol>\n

    \nMen i allt detta s\u00e5g vi ocks\u00e5 n\u00e5gra nackdelar: <\/p>\n

      \n
    1. F\u00f6rutom produktionsmilj\u00f6n och utvecklingsmilj\u00f6n finns det \u00e4ven andra milj\u00f6er. Till exempel QA och preproduktion. Vid det tillf\u00e4llet hade vi m\u00e5nga servrar och cirka 60 tj\u00e4nster. D\u00e4rf\u00f6r var vi tvungna att bibeh\u00e5lla den aktuella versionen <\/b>av den virtuella maskinen f\u00f6r varje tj\u00e4nst. Dessutom, om du vill uppdatera bibliotek eller installera nya beroenden, m\u00e5ste du g\u00f6ra det i alla milj\u00f6er. Tidpunkten f\u00f6r n\u00e4r du t\u00e4nker distribuera den nya versionen av din applikation m\u00e5ste ocks\u00e5 synkroniseras med tidpunkten d\u00e5 devops utf\u00f6r de n\u00f6dv\u00e4ndiga konfigurationerna av milj\u00f6n. I s\u00e5dana fall \u00e4r det l\u00e4tt att hamna i en situation d\u00e4r milj\u00f6n ser helt olika ut i alla milj\u00f6er direkt efter varandra. Till exempel kan det finnas en upps\u00e4ttning bibliotek i QA-milj\u00f6n, medan det finns en annan i produktion, vilket kan leda till problem. <\/li>\n
    2. Sv\u00e5righeten med att uppdatera beroenden<\/b> av din applikation. Det beror inte p\u00e5 dig, utan p\u00e5 ett annat team. N\u00e4mligen devops-teamet, som st\u00f6der servrarna. Du m\u00e5ste ge dem en l\u00e4mplig uppgift och beskriva vad du vill \u00e5stadkomma.<\/li>\n
    3. Vid den tiden ville vi ocks\u00e5 dela upp v\u00e5ra stora monoliter i mindre tj\u00e4nster, eftersom vi ins\u00e5g att antalet skulle \u00f6ka st\u00e4ndigt. D\u00e5 hade vi redan \u00f6ver 100 s\u00e5dana. F\u00f6r varje ny tj\u00e4nst beh\u00f6vde vi skapa en ny virtuell maskin, som ocks\u00e5 m\u00e5ste underh\u00e5llas och distribueras. Dessutom beh\u00f6vdes det inte bara en maskin, utan minst tv\u00e5. Dessutom tillkom en QA-milj\u00f6. Detta skapar problem och g\u00f6r det mer komplicerat, kostsamt och tidskr\u00e4vande att skapa och lansera nya system.<\/b><\/li>\n<\/ol>\n

      \nD\u00e4rf\u00f6r beslutade vi att det skulle vara mer praktiskt att \u00f6verg\u00e5 fr\u00e5n att distribuera vanliga virtuella maskiner till att k\u00f6ra v\u00e5ra applikationer i Docker-containrar. Med Docker beh\u00f6vs ett system som kan k\u00f6ra applikationen i ett kluster, eftersom man inte bara kan starta en container utan vidare. Vanligtvis vill man h\u00e5lla koll p\u00e5 hur m\u00e5nga containrar som \u00e4r aktiva, s\u00e5 att de startas automatiskt. Av den anledningen beh\u00f6vde vi v\u00e4lja ett administrationssystem. <\/p>\n

      Vi funderade l\u00e4nge p\u00e5 vilket av dem som skulle vara l\u00e4mpligt. Problemet var att v\u00e5r deployment-stack f\u00f6r vanliga virtuella servrar vid den tiden var n\u00e5got f\u00f6r\u00e5ldrad, eftersom det fanns inte de senaste versionerna av operativsystemen. Vid n\u00e5got tillf\u00e4lle hade vi till och med FreeBSD, som var ganska besv\u00e4rligt att underh\u00e5lla. Vi ins\u00e5g att vi beh\u00f6vde migrera till Docker s\u00e5 snart som m\u00f6jligt. V\u00e5rt DevOps-team tittade p\u00e5 sin befintliga erfarenhet av olika l\u00f6sningar och valde ett system som Nomad. <\/p>\n

      \u00d6verg\u00e5ngen till Nomad<\/h1>\n

      \nNomad \u00e4r en produkt fr\u00e5n f\u00f6retaget \"HashiCorp\". De \u00e4r ocks\u00e5 k\u00e4nda f\u00f6r sina andra l\u00f6sningar:<\/p>\n

      \"Deployment
      \n
      \n\"Consul\"<\/b> \u2014 ett verktyg f\u00f6r tj\u00e4nstedetektering.<\/p>\n

      \"Terraform\"<\/b> \u2014 ett system f\u00f6r serverhantering som l\u00e5ter dig konfigurera dem via kod, s\u00e5 kallad infrastructure-as-code.<\/p>\n

      \"Vagrant\"<\/b> m\u00f6jligg\u00f6r lokal eller moln-baserad distribution av virtuella maskiner genom specifika konfigurationsfiler. <\/p>\n

      Nomad verkade vid den tiden vara en ganska enkel l\u00f6sning att snabbt \u00f6verg\u00e5 till utan att \u00e4ndra hela infrastrukturen. Dessutom \u00e4r det ganska l\u00e4tt att l\u00e4ra sig. D\u00e4rf\u00f6r valde vi just det som v\u00e5rt filtreringssystem f\u00f6r containrar. <\/p>\n

      Vad beh\u00f6vs f\u00f6r att \u00f6verhuvudtaget distribuera ditt system i Nomad? <\/p>\n

        \n
      1. F\u00f6rst och fr\u00e4mst beh\u00f6vs en docker image<\/b> din applikation. Den m\u00e5ste byggas och placeras i dockerbildens lagring. I v\u00e5rt fall \u00e4r det artifactory \u2014 en s\u00e5dan system som g\u00f6r det m\u00f6jligt att pusha olika typer av artefakter. Det kan lagra arkiv, dockerbilder, PHP Composer-paket, NPM-paket och s\u00e5 vidare. <\/li>\n
      2. Det \u00e4r ocks\u00e5 n\u00f6dv\u00e4ndigt konfigurationsfilen<\/b>, vilket talar om f\u00f6r Nomad vad, var och i vilken m\u00e4ngd du vill distribuera. <\/li>\n<\/ol>\n

        \nN\u00e4r vi pratar om Nomad anv\u00e4nds HCL som format f\u00f6r informationsfilen, vilket st\u00e5r f\u00f6r HashiCorp Configuration Language<\/i>. Det \u00e4r en \u00f6verm\u00e4ngd av Yaml som l\u00e5ter dig beskriva din tj\u00e4nst i termer av Nomad. <\/p>\n

        \"Deployment
        \n
        \nDet till\u00e5ter dig att ange hur m\u00e5nga containrar du vill distribuera, fr\u00e5n vilka bilder, och f\u00f6r att \u00f6verf\u00f6ra olika parametrar vid distribution. P\u00e5 s\u00e5 s\u00e4tt matar du in denna fil till Nomad, och den startar containrar i produktion i enlighet med den. <\/p>\n

        I v\u00e5rt fall ins\u00e5g vi att det inte skulle vara praktiskt att skriva helt identiska HCL-filer f\u00f6r varje tj\u00e4nst, eftersom det finns s\u00e5 m\u00e5nga tj\u00e4nster och ibland vill man uppdatera dem. Det h\u00e4nder att en tj\u00e4nst distribueras i flera exemplar, inte bara ett. Till exempel har ett av systemen som ligger i produktion \u00f6ver 100 instanser i drift. De k\u00f6rs fr\u00e5n samma bilder, men med olika konfigurationsinst\u00e4llningar och konfigurationsfiler. <\/p>\n

        D\u00e4rf\u00f6r best\u00e4mde vi att det skulle vara praktiskt att lagra alla v\u00e5ra konfigurationsfiler f\u00f6r distribution i ett gemensamt f\u00f6rr\u00e5d. P\u00e5 s\u00e5 s\u00e4tt kan de granskas: de \u00e4r l\u00e4tta att underh\u00e5lla och man kan se vilka system vi har. Vid behov \u00e4r det inte sv\u00e5rt att uppdatera eller \u00e4ndra n\u00e5got. Att l\u00e4gga till ett nytt system \u00e4r heller inget problem \u2014 det r\u00e4cker med att skapa en konfigurationsfil i en ny mapp. Inuti den finns filerna: service.hcl, som inneh\u00e5ller beskrivningen av v\u00e5r tj\u00e4nst, och vissa env-filer, som g\u00f6r att denna tj\u00e4nst, n\u00e4r den v\u00e4l \u00e4r distribuerad i produktion, kan konfigureras. <\/p>\n

        \"Deployment
        \n
        \nMen n\u00e5gra av v\u00e5ra system \u00e4r inte distribuerade i produktion i ett exemplar utan i flera samtidigt. D\u00e4rf\u00f6r beslutade vi att det skulle vara bekv\u00e4mt att lagra inte konfigurerade filer i sin rena form, utan i deras templatiserade form. Som spr\u00e5k f\u00f6r templatisering valde vi jinja 2<\/i>. I detta format lagras b\u00e5de konfigurationerna f\u00f6r tj\u00e4nsten och de env-filer som den beh\u00f6ver. <\/p>\n

        Dessutom har vi inkluderat ett gemensamt skript f\u00f6r distribution i repositoryt f\u00f6r alla projekt, vilket g\u00f6r att du kan starta och distribuera din tj\u00e4nst till produktion, i r\u00e4tt milj\u00f6 och till r\u00e4tt m\u00e5l. N\u00e4r vi omvandlade v\u00e5r HCL-konfiguration till en mall, s\u00e5g HCL-filen, som tidigare var en vanlig Nomad-konfiguration, lite annorlunda ut.<\/p>\n

        \"Deployment
        \n
        \nDet vill s\u00e4ga att vi ersatte vissa variabler i konfigurationen med ins\u00e4ttningar av variabler som h\u00e4mtas fr\u00e5n env-filer eller andra k\u00e4llor. Dessutom fick vi m\u00f6jlighet att dynamiskt sammanst\u00e4lla HCL-filer, vilket inneb\u00e4r att vi kan anv\u00e4nda mer \u00e4n bara vanliga variabelins\u00e4ttningar. Eftersom Jinja st\u00f6djer loopar och villkor, kan vi \u00e4ven skapa konfigurationsfiler som \u00e4ndras beroende p\u00e5 var du faktiskt distribuerar dina applikationer. <\/p>\n

        Till exempel, om du vill distribuera din tj\u00e4nst till pre-production och produktion. Anta att du i pre-production inte vill k\u00f6ra cron-skript utan bara vill se tj\u00e4nsten p\u00e5 en separat dom\u00e4n f\u00f6r att kontrollera att den fungerar. F\u00f6r alla som distribuerar en tj\u00e4nst ser processen mycket enkel och transparent ut. Det r\u00e4cker med att k\u00f6ra filen deploy.sh, ange vilken tj\u00e4nst du vill distribuera och till vilket m\u00e5l. Till exempel, om du vill distribuera ett visst system till Ryssland, Vitryssland eller Kazakstan. F\u00f6r att g\u00f6ra detta r\u00e4cker det att bara \u00e4ndra en av parametrarna, s\u00e5 kommer r\u00e4tt konfigurationsfil att skapas. <\/p>\n

        N\u00e4r Nomadtj\u00e4nsten redan \u00e4r distribuerad i din kluster ser den ut p\u00e5 f\u00f6ljande s\u00e4tt.<\/p>\n

        \"Deployment
        \n
        \nF\u00f6rst beh\u00f6ver du en viss extern lastbalanserare som kommer att ta emot all anv\u00e4ndartj\u00e4nsttrafik. Den kommer att arbeta tillsammans med Consul och fr\u00e5ga den var, p\u00e5 vilken nod, med vilken IP-adress<\/a> den specifika tj\u00e4nsten som motsvarar det specifika dom\u00e4nnamnet finns. Tj\u00e4nsterna i Consul dyker upp fr\u00e5n Nomad sj\u00e4lv. Eftersom detta \u00e4r produkter fr\u00e5n samma f\u00f6retag \u00e4r de v\u00e4l integrerade. Man kan s\u00e4ga att Nomad direkt st\u00f6djer registreringen av alla tj\u00e4nster som startas i Consul. <\/p>\n

        N\u00e4r din externa lastbalanserare har f\u00e5tt reda p\u00e5 vilken tj\u00e4nst den ska skicka trafik till, omdirigerar den trafiken till motsvarande container eller flera containrar som h\u00f6r till din applikation. Sj\u00e4lvklart m\u00e5ste man ocks\u00e5 t\u00e4nka p\u00e5 s\u00e4kerheten. \u00c4ven om alla tj\u00e4nster k\u00f6rs p\u00e5 samma virtuella maskiner i containrar, kr\u00e4vs det vanligtvis att man f\u00f6rbjuder obeh\u00f6rig tillg\u00e5ng fr\u00e5n en tj\u00e4nst till en annan. Vi \u00e5stadkom detta genom segmentering. Varje tj\u00e4nst k\u00f6rdes i sitt egna virtuella n\u00e4tverk, d\u00e4r regler f\u00f6r routing och regler f\u00f6r \u00e5tkomsttillst\u00e5nd\/blockering till andra system och tj\u00e4nster var definierade. De kunde befinna sig b\u00e5de inom denna kluster och utanf\u00f6r. Till exempel, om du vill f\u00f6rbjuda en tj\u00e4nst att koppla upp sig mot en viss databas, kan detta g\u00f6ras genom segmentering p\u00e5 n\u00e4tverksniv\u00e5. Det inneb\u00e4r att du inte av misstag kan koppla upp dig fr\u00e5n testmilj\u00f6n till din produktionsdatabas.<\/p>\n

        Vad kostade \u00f6verg\u00e5ngsprocessen i form av personalresurser? <\/p>\n

        \u00d6verg\u00e5ngen av hela f\u00f6retaget till Nomad tog ungef\u00e4r 5-6 m\u00e5nader. Vi genomf\u00f6rde det tj\u00e4nst f\u00f6r tj\u00e4nst, men i ett ganska snabbt tempo. Varje team var tvungna att skapa sina egna containrar f\u00f6r sina tj\u00e4nster. <\/p>\n

        Vi har antagit en s\u00e5dan tillv\u00e4gag\u00e5ngss\u00e4tt d\u00e4r varje team ansvarar f\u00f6r docker images av sina system sj\u00e4lva. DevOps tillhandah\u00e5ller den gemensamma infrastrukturen som \u00e4r n\u00f6dv\u00e4ndig f\u00f6r distribution, det vill s\u00e4ga st\u00f6d f\u00f6r sj\u00e4lva klustret, st\u00f6d f\u00f6r CI-systemet och s\u00e5 vidare. Vid den tiden hade \u00f6ver 60 system flyttat \u00f6ver till Nomad, vilket resulterade i ungef\u00e4r 2 000 containrar. <\/p>\n

        DevOps ansvarar f\u00f6r den gemensamma infrastrukturen f\u00f6r allt som r\u00f6r distribution och servrar. Varje utvecklingsteam ansvarar i sin tur f\u00f6r implementeringen av containrar f\u00f6r sitt specifika system, eftersom det \u00e4r just teamet som vet vad de beh\u00f6ver i den eller den containern.<\/p>\n

        Orsaker till att avbryta anv\u00e4ndningen av Nomad<\/h1>\n

        \nVilka f\u00f6rdelar fick vi av att \u00f6verg\u00e5 till distribution via Nomad och Docker?<\/p>\n

          \n
        1. Vi s\u00e4kra likv\u00e4rdiga villkor<\/b> f\u00f6r alla milj\u00f6er. I utveckling, QA-milj\u00f6er, f\u00f6rproduktionen och produktionen anv\u00e4nds samma containerbilder, med samma beroenden. S\u00e5ledes har ni knappt n\u00e5gon chans att det som hamnar i produktion \u00e4r n\u00e5got annat \u00e4n vad ni tidigare har testat lokalt eller i testmilj\u00f6n. <\/li>\n
        2. Vi har ocks\u00e5 uppt\u00e4ckt att det \u00e4r tillr\u00e4ckligt enkelt att l\u00e4gga till en ny tj\u00e4nst<\/b>. Alla nya system kan enkelt startas upp n\u00e4r det kommer till deployment. Det r\u00e4cker att g\u00e5 till det repository som lagrar konfigurationerna, l\u00e4gga till en ny konfigurationsfil f\u00f6r ert system, och s\u00e5 \u00e4r ni klara. Ni kan deploya ert system till produktion utan ytterligare anstr\u00e4ngningar fr\u00e5n DevOps. <\/li>\n
        3. Alla konfigurationsfiler<\/b> i ett gemensamt repository visade sig vara \u00f6versk\u00e5dliga<\/b>. I det \u00f6gonblicket vi deployade v\u00e5ra system med hj\u00e4lp av virtuella servrar<\/a>, anv\u00e4nde vi Ansible, d\u00e4r konfigurationerna l\u00e5g i samma repository. Men f\u00f6r de flesta utvecklare var det lite mer komplicerat att arbeta med detta. Volymen av konfigurationer och kod som ni beh\u00f6ver l\u00e4gga till f\u00f6r att deploya tj\u00e4nsten har blivit mycket mindre. Dessutom \u00e4r det v\u00e4ldigt enkelt f\u00f6r DevOps att justera eller \u00e4ndra detta. Vid \u00f6verg\u00e5ngar, till exempel till en ny version av Nomad, kan de enkelt massuppdatera alla operativa filer som ligger p\u00e5 samma st\u00e4lle.<\/li>\n<\/ol>\n

          \nMen vi st\u00f6tte ocks\u00e5 p\u00e5 flera nackdelar: <\/p>\n

          Det visade sig att vi inte kunde uppn\u00e5 s\u00f6ml\u00f6s deployment <\/b>i fallet med Nomad. Vid utrullning av containrar fr\u00e5n olika milj\u00f6er kunde det h\u00e4nda att den blev k\u00f6rd, och Nomad uppfattade den som redo att ta emot trafik. Detta h\u00e4nde innan applikationen inne i den hade tid att starta. P\u00e5 grund av detta b\u00f6rjade systemet under en kort tid att ge 500-fel, eftersom trafiken b\u00f6rjade g\u00e5 till en container som \u00e4nnu inte var redo att ta emot den. <\/p>\n

          Vi st\u00f6tte p\u00e5 n\u00e5gra buggar<\/b>Det mest betydande felet \u00e4r att Nomad inte hanterar stora kluster s\u00e4rskilt bra om du har m\u00e5nga system och containrar. N\u00e4r du vill ta en av servrarna i klustret Nomad ur drift finns det en ganska stor sannolikhet att klustret inte m\u00e5r s\u00e4rskilt bra och g\u00e5r s\u00f6nder. Vissa containrar kan till exempel falla och inte starta igen \u2013 det kan bli v\u00e4ldigt dyrt f\u00f6r dig senare om alla dina system \u00e4r i produktion just i klustret som hanteras av Nomad. <\/p>\n

          D\u00e4rf\u00f6r best\u00e4mde vi oss f\u00f6r att t\u00e4nka p\u00e5 vad vi skulle g\u00f6ra h\u00e4rn\u00e4st. Vid den tidpunkten ins\u00e5g vi mycket b\u00e4ttre vad vi ville uppn\u00e5. N\u00e4mligen: vi vill ha p\u00e5litlighet, lite fler funktioner \u00e4n vad Nomad erbjuder, och ett mer moget, stabilt system. <\/p>\n

          I detta avseende valde vi Kubernetes som den mest popul\u00e4ra plattformen f\u00f6r att k\u00f6ra kluster. S\u00e4rskilt med tanke p\u00e5 att storleken och antalet av v\u00e5ra containrar var ganska stort. F\u00f6r s\u00e5dana \u00e4ndam\u00e5l verkade Kubernetes vara det mest l\u00e4mpliga systemet av de vi kunde \u00f6verv\u00e4ga. <\/p>\n

          \u00d6verg\u00e5ng till Kubernetes<\/h1>\n

          \nJag ska kort ber\u00e4tta om de grundl\u00e4ggande begreppen i Kubernetes och vad som skiljer dem fr\u00e5n Nomad. <\/p>\n

          \"Deployment
          \n
          \nF\u00f6rst och fr\u00e4mst \u00e4r det mest grundl\u00e4ggande begreppet i Kubernetes begreppet pod. Pod<\/b> \u00e4r en grupp av en eller flera containrar som alltid k\u00f6rs tillsammans. Och de fungerar som om de alltid strikt finns p\u00e5 en och samma virtuella maskin. De \u00e4r tillg\u00e4ngliga f\u00f6r varandra via IP-adressen 127.0.0.1 p\u00e5 olika portar. <\/p>\n

          Anta att du har en PHP-applikation som best\u00e5r av nginx och php-fpm \u2013 en klassisk konfiguration. Du kommer sannolikt att vilja att b\u00e5de nginx- och php-fpm-containrar alltid \u00e4r tillsammans. Kubernetes g\u00f6r det m\u00f6jligt att uppn\u00e5 detta genom att beskriva dem som en gemensam pod. Precis det kunde vi inte f\u00e5 till st\u00e5nd med hj\u00e4lp av Nomad.<\/p>\n

          Det andra begreppet \u00e4r deployment<\/b>. Po\u00e4ngen \u00e4r att pod sj\u00e4lv \u00e4r en flyktig sak, den startar och f\u00f6rsvinner. Vill du f\u00f6rst d\u00f6da alla dina tidigare containrar och sedan starta om nya versioner, eller vill du rulla ut dem gradvis \u2013 just denna process hanteras av begreppet deployment. Det beskriver hur du distribuerar dina podar, i vilken m\u00e4ngd och hur du uppdaterar dem. <\/p>\n

          Det tredje begreppet \u00e4r service<\/b>. Ditt service \u00e4r faktiskt ditt system som tar emot viss trafik och sedan dirigerar den till en eller flera poddar som motsvarar ditt service. Det betyder att den l\u00e5ter dig specificera att all inkommande trafik till en s\u00e5dan tj\u00e4nst med ett visst namn ska skickas till just dessa poddar. Och samtidigt s\u00e4kerst\u00e4ller den att du f\u00e5r en lastbalansering. Det inneb\u00e4r att du kan starta tv\u00e5 poddar av din applikation, och all inkommande trafik kommer att balanseras j\u00e4mnt mellan de poddar som tillh\u00f6r denna tj\u00e4nst.<\/p>\n

          Och det fj\u00e4rde grundl\u00e4ggande begreppet \u2014 Ingress<\/b>. Det \u00e4r en tj\u00e4nst som k\u00f6rs i ett Kubernetes-kluster. Den fungerar som en extern lastbalanserare som tar emot alla f\u00f6rfr\u00e5gningar. Med hj\u00e4lp av API:n i Kubernetes Ingress kan den avg\u00f6ra vart dessa f\u00f6rfr\u00e5gningar ska skickas. Dessutom g\u00f6r den det v\u00e4ldigt flexibelt. Du kan s\u00e4ga att alla f\u00f6rfr\u00e5gningar till denna v\u00e4rd och denna URL skickas till denna tj\u00e4nst. Och dessa f\u00f6rfr\u00e5gningar som kommer till denna v\u00e4rd och till en annan URL skickas till en annan tj\u00e4nst. <\/p>\n

          Det mest fantastiska ur perspektivet f\u00f6r den som utvecklar applikationen \u2014 \u00e4r att du kan hantera allt detta sj\u00e4lv. Genom att s\u00e4tta upp Ingress-konfigurationen kan du skicka all trafik som kommer till en viss API till separata containrar, till exempel skrivna i Go. Och den h\u00e4r trafiken som kommer till samma dom\u00e4n, men till en annan URL, kan skickas till containrar skrivna i PHP, d\u00e4r det finns mycket logik, men som inte \u00e4r s\u00e4rskilt snabba.<\/p>\n

          Om man j\u00e4mf\u00f6r alla dessa begrepp med Nomad kan man s\u00e4ga att de tre f\u00f6rsta begreppen tillsammans utg\u00f6r Service. Det sista begreppet finns inte i Nomad. Vi har anv\u00e4nt en extern lastbalanserare f\u00f6r detta: det kan vara haproxy, nginx, nginx+ och s\u00e5 vidare. I fallet med Kubernetes beh\u00f6ver du inte inf\u00f6ra detta ytterligare begrepp separat. Men om du tittar p\u00e5 Ingress inuti, s\u00e5 \u00e4r det antingen nginx, haproxy eller traefik, men inbyggt i Kubernetes. <\/p>\n

          Alla de begrepp jag n\u00e4mnt \u00e4r i stort sett resurser som finns inom Kubernetes-klustret. F\u00f6r att beskriva dem i Kubernetes anv\u00e4nds yaml-format, som \u00e4r mer l\u00e4sbart och bekant \u00e4n HCL-filerna i Nomad. Men strukturellt beskriver de, till exempel f\u00f6r en pod, i princip detsamma. De s\u00e4ger \u2014 jag vill distribuera s\u00e5dana poddar dit, med s\u00e5dana bilder, i s\u00e5dant antal. <\/p>\n

          \"Deployment
          \n
          \nDessutom ins\u00e5g vi att vi inte ville skapa varje enskild resurs f\u00f6r hand: deployment, tj\u00e4nster, Ingress och s\u00e5 vidare. Ist\u00e4llet ville vi vid deployment beskriva varje system vi har i termer av Kubernetes, s\u00e5 att vi inte beh\u00f6ver \u00e5terskapa alla n\u00f6dv\u00e4ndiga resursberoenden i r\u00e4tt ordning manuellt. F\u00f6r detta \u00e4ndam\u00e5l valde vi Helm som system. <\/p>\n

          Grundl\u00e4ggande begrepp i Helm<\/h1>\n

          \nHelm \u00e4r paketchef<\/b> f\u00f6r Kubernetes. Det liknar hur paketf\u00f6rvaltare fungerar i programmeringsspr\u00e5k. De l\u00e5ter dig lagra en tj\u00e4nst som best\u00e5r av exempelvis en deployment f\u00f6r nginx, en deployment f\u00f6r php-fpm, en konfiguration f\u00f6r Ingress och configmaps (detta \u00e4r en enhet som l\u00e5ter dig ange env och andra parametrar f\u00f6r ditt system) i form av s\u00e5 kallade charts. Helm fungerar ovanp\u00e5 Kubernetes<\/b>. Det \u00e4r allts\u00e5 inget system som st\u00e5r vid sidan av, utan bara en annan tj\u00e4nst som k\u00f6rs inuti klustret. Du interagerar med det via dess API genom kommandoraden. Dess bekv\u00e4mlighet och f\u00f6rdelar ligger i att \u00e4ven om helm skulle krascha eller du tar bort det fr\u00e5n klustret, s\u00e5 f\u00f6rsvinner inte dina tj\u00e4nster, eftersom helm i princip bara tj\u00e4nar till att starta systemet. Sj\u00e4lva Kubernetes ansvarar f\u00f6r tj\u00e4nsternas funktion och tillst\u00e5nd. <\/p>\n

          Vi ins\u00e5g ocks\u00e5 att mallning<\/b>, som vi tidigare var tvungna att g\u00f6ra sj\u00e4lva genom att inf\u00f6ra jinja i v\u00e5ra konfigurationer, \u00e4r en av de viktigaste funktionerna i helm. Alla konfigurationer du skapar f\u00f6r dina system lagras i helm i form av mallar, liknande jinja, men som egentligen anv\u00e4nder mallningsspr\u00e5ket Go, som helm \u00e4r skrivet p\u00e5, precis som Kubernetes. <\/p>\n

          Helm l\u00e4gger till ett par ytterligare begrepp. <\/p>\n

          Diagram<\/b> \u2014 detta \u00e4r en beskrivning av din tj\u00e4nst. I andra paketf\u00f6rvaltare skulle detta kallas paket, bundle eller n\u00e5got liknande. H\u00e4r kallas det chart. <\/p>\n

          Values <\/b>\u2013 det \u00e4r variabler som du vill anv\u00e4nda f\u00f6r att bygga dina konfigurationer fr\u00e5n mallar. <\/p>\n

          Release<\/b>Varje g\u00e5ng en tj\u00e4nst som deployas med hj\u00e4lp av helm f\u00e5r en inkrementell version av releasen. Helm kommer ih\u00e5g vilken konfiguration tj\u00e4nsten hade vid tidigare och f\u00f6reg\u00e5ende releaser. D\u00e4rf\u00f6r r\u00e4cker det med att k\u00f6ra kommandot helm callback och ange den tidigare versionen av releasen f\u00f6r att \u00e5terst\u00e4lla. \u00c4ven om den motsvarande konfigurationen inte \u00e4r tillg\u00e4nglig i ditt repository vid tidpunkten f\u00f6r \u00e5terst\u00e4llning, kommer helm fortfarande att komma ih\u00e5g vilken den var och \u00e5terst\u00e4lla ditt system till det tillst\u00e5nd det var i vid den tidigare releasen. <\/p>\n

          N\u00e4r vi anv\u00e4nder helm omvandlas vanliga konfigurationer f\u00f6r Kubernetes ocks\u00e5 till mallar, d\u00e4r det finns m\u00f6jlighet att anv\u00e4nda variabler, funktioner och till\u00e4mpa villkorssatser. P\u00e5 s\u00e5 s\u00e4tt kan du bygga konfigurationen av din tj\u00e4nst beroende p\u00e5 milj\u00f6n.<\/p>\n

          \"Deployment
          \n
          \nI praktiken har vi valt att g\u00f6ra n\u00e5got annorlunda \u00e4n vad vi gjorde i fallet med Nomad. Om i Nomad alla konfigurationer f\u00f6r deployment och n-variabler som beh\u00f6vs f\u00f6r att deploya v\u00e5r tj\u00e4nst lagrades i ett och samma repository, s\u00e5 har vi h\u00e4r valt att dela upp dem i tv\u00e5 separata repositories. I repositoryt 'deploy' lagras endast n-variablerna som beh\u00f6vs f\u00f6r deployment, medan repositoryt 'helm' inneh\u00e5ller konfigurationer eller charts.<\/p>\n

          \"Deployment
          \n
          \nVad gav detta oss? <\/p>\n

          Trots att vi inte lagrar n\u00e5gra verkligt k\u00e4nsliga uppgifter i konfigurationsfilerna, till exempel databasanv\u00e4ndarnamn och l\u00f6senord, som lagras som secrets i Kubernetes, finns det \u00e4nd\u00e5 s\u00e4rskilda saker dit vi inte vill ge \u00e5tkomst f\u00f6r alla. D\u00e4rf\u00f6r \u00e4r tillg\u00e5ngen till repositoryt 'deploy' mer begr\u00e4nsad, medan repositoryt 'helm' bara inneh\u00e5ller en beskrivning av tj\u00e4nsten. Av denna anledning kan vi ge tillg\u00e5ng till det p\u00e5 ett s\u00e4kert s\u00e4tt till en st\u00f6rre krets av personer. <\/p>\n

          Eftersom vi har inte bara produktionsmilj\u00f6er utan \u00e4ven andra milj\u00f6er, kan vi tack vare denna uppdelning \u00e5teranv\u00e4nda v\u00e5ra helm-charts f\u00f6r att deploya tj\u00e4nster inte bara i produktion, utan \u00e4ven till exempel i QA-milj\u00f6er. \u00c4ven f\u00f6r att drifts\u00e4tta dem lokalt med hj\u00e4lp av Minikube<\/i> \u2014 det \u00e4r en s\u00e5dan grej f\u00f6r lokal k\u00f6rning av Kubernetes. <\/p>\n

          Inom varje repository har vi gjort en uppdelning i separata kataloger f\u00f6r varje tj\u00e4nst. Det betyder att inom varje katalog finns mallar som \u00e4r relaterade till motsvarande diagram och beskriver de resurser som beh\u00f6ver distribueras f\u00f6r att starta v\u00e5rt system. I repositoryt \"deploy\" har vi endast l\u00e4mnat envars. I detta fall har vi inte anv\u00e4nt mallning med jinja, eftersom helm sj\u00e4lv erbjuder mallning direkt - det \u00e4r en av dess grundl\u00e4ggande funktioner. <\/p>\n

          Vi har l\u00e4mnat ett skript f\u00f6r distribution - deploy.sh, som f\u00f6renklar och standardiserar start av distribution med hj\u00e4lp av helm. S\u00e5ledes ser distributionsgr\u00e4nssnittet ut exakt som det gjorde i fallet med distribution via Nomad. Samma deploy.sh, namnet p\u00e5 din tj\u00e4nst och dit du vill distribuera den. Detta resulterar i att helm k\u00f6rs inuti. Den samlar konfigurationer fr\u00e5n mallarna, ers\u00e4tter dem med n\u00f6dv\u00e4ndiga values-filer och distribuerar dem i Kubernetes. <\/p>\n

          Slutsatser<\/h1>\n

          \nKubernetes-tj\u00e4nsten verkar mer komplex \u00e4n Nomad. <\/p>\n

          \"Deployment
          \n
          \nH\u00e4r kommer utg\u00e5ende trafik in i Ingress. Det \u00e4r just frontkontrollern som tar emot alla f\u00f6rfr\u00e5gningar och skickar dem vidare till de tj\u00e4nster som \u00e4r relevanta f\u00f6r de aktuella f\u00f6rfr\u00e5gningarna. Den best\u00e4mmer dessa baserat p\u00e5 konfigurationer som \u00e4r en del av beskrivningen av din applikation i helm och som utvecklarna specificerar sj\u00e4lva. Tj\u00e4nsten skickar f\u00f6rfr\u00e5gningar till sina pods, det vill s\u00e4ga specifika containrar, och balanserar den inkommande trafiken mellan alla containrar som tillh\u00f6r den aktuella tj\u00e4nsten. Och naturligtvis f\u00e5r vi inte gl\u00f6mma att s\u00e4kerheten p\u00e5 n\u00e4tverksniv\u00e5 \u00e4r avg\u00f6rande. D\u00e4rf\u00f6r \u00e4r det segmentering i Kubernetes-klustret, som baseras p\u00e5 taggning. Alla tj\u00e4nster har specifika taggar, till vilka r\u00e4ttigheter f\u00f6r tj\u00e4nsternas tillg\u00e5ng till olika externa\/interna resurser inuti eller utanf\u00f6r klustret \u00e4r kopplade. <\/p>\n

          N\u00e4r vi genomf\u00f6rde \u00f6verg\u00e5ngen s\u00e5g vi att Kubernetes har alla funktioner som Nomad, som vi tidigare anv\u00e4nde, hade, och dessutom l\u00e4gger till mycket nytt. Det kan utvidgas genom plugins och faktiskt genom anpassade resurstyper. Det inneb\u00e4r att du inte bara kan anv\u00e4nda det som f\u00f6ljer med Kubernetes utanf\u00f6r boxen, utan ocks\u00e5 skapa din egen resurs och tj\u00e4nst som kommer att l\u00e4sa din resurs. Detta ger ytterligare m\u00f6jligheter att ut\u00f6ka ditt system utan att beh\u00f6va installera om Kubernetes och utan behov av f\u00f6r\u00e4ndringar. <\/p>\n

          Ett exempel p\u00e5 s\u00e5dan anv\u00e4ndning \u00e4r Prometheus, som k\u00f6rs inom v\u00e5r Kubernetes-kluster. F\u00f6r att det ska b\u00f6rja samla in metrik fr\u00e5n en viss tj\u00e4nst beh\u00f6ver vi l\u00e4gga till en extra resurstyp i tj\u00e4nstbeskrivningen, s\u00e5 kallad servicemonitor. Eftersom Prometheus kan l\u00e4sa anpassade resurstyper n\u00e4r det k\u00f6rs i Kubernetes, b\u00f6rjar det automatiskt samla in metrik fr\u00e5n det nya systemet. Det \u00e4r ganska praktiskt. <\/p>\n

          Den f\u00f6rsta deployment vi gjorde i Kubernetes var i mars 2018. Och under den tiden har vi aldrig haft n\u00e5gra problem med det. Det fungerar ganska stabilt utan betydande buggar. Dessutom kan vi vidareutveckla det. Idag r\u00e4cker de m\u00f6jligheter som finns i det, och vi gillar verkligen hastigheten p\u00e5 utvecklingen av Kubernetes. F\u00f6r n\u00e4rvarande finns det mer \u00e4n 3000 containrar i Kubernetes. Klustret best\u00e5r av flera noder. Vidare \u00e4r det underh\u00e5llit, stabilt och mycket kontrollerat.
          \n
          K\u00e4lla:           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\udd47Deployment av applikationer i VM, Nomad och Kubernetes | ProHoster","description":"Hej allihopa! Jag heter Pavel Agaletckij. Jag arbetar som teamledare i det team som utvecklar Lamodas leveranssystem.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}