{"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\/ro\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"Dezvoltarea aplica\u021biilor \u00een VM, Nomad \u0219i Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut tuturor! Numele meu este Pavel Agaletsky. Lucrez ca team leader \u00eentr-o echip\u0103 care dezvolt\u0103 sistemul de livrare Lamoda. \u00cen 2018 am vorbit la conferin\u021ba HighLoad++, iar ast\u0103zi vreau s\u0103 v\u0103 prezint transcrierea prezent\u0103rii mele.<\/p>\n

Subiectul meu se concentreaz\u0103 pe experien\u021ba companiei noastre \u00een implementarea sistemelor \u0219i serviciilor \u00een diverse medii. \u00cencep\u00e2nd cu vremurile noastre preistorice, c\u00e2nd implementam toate sistemele pe servere virtuale obi\u0219nuite, p\u00e2n\u0103 la tranzi\u021bia treptat\u0103 de la Nomad la implementarea \u00een Kubernetes. Voi vorbi despre motivele pentru care am f\u0103cut asta \u0219i ce probleme am \u00eent\u00e2mpinat \u00een proces.<\/p>\n

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

Implementarea aplica\u021biilor pe VM<\/h1>\n

\nS\u0103 \u00eenceap\u0103 cu faptul c\u0103 acum 3 ani toate sistemele \u0219i serviciile companiei erau implementate pe servere virtuale obi\u0219nuite. Din punct de vedere tehnic, totul era organizat astfel \u00eenc\u00e2t tot codul sistemelor noastre era salvat \u0219i compilat prin sisteme de compilare automate, cu ajutorul Jenkins. Cu Ansible, acesta era desf\u0103\u0219urat de pe sistemul nostru de control al versiunilor pe serverele virtuale. Fiecare sistem din compania noastr\u0103 era implementat pe cel pu\u021bin 2 servere: unul era head, iar cel\u0103lalt era tail. Aceste dou\u0103 sisteme erau absolut identice \u00een toate set\u0103rile, puterea, configura\u021bia \u0219i altele. Singura diferen\u021b\u0103 era c\u0103 head primea traficul utilizatorilor, iar tail nu primea niciodat\u0103 traficul utilizatorilor. <\/p>\n

De ce a fost necesar acest lucru? <\/p>\n

C\u00e2nd implementam noi versiuni ale aplica\u021biei noastre, voiam s\u0103 asigur\u0103m o desf\u0103\u0219urare f\u0103r\u0103 \u00eentreruperi, adic\u0103 f\u0103r\u0103 consecin\u021be vizibile pentru utilizatori. Aceasta era realizat\u0103 prin faptul c\u0103 versiunea compilat\u0103 era desf\u0103\u0219urat\u0103 cu ajutorul Ansible pe serverul tail. Acolo, persoanele care se ocupau cu desf\u0103\u0219urarea puteau verifica \u0219i se asigurau c\u0103 totul func\u021bioneaz\u0103 bine: toate metricile, sec\u021biunile \u0219i aplica\u021biile func\u021bioneaz\u0103; scripturile necesare sunt lansate. Numai dup\u0103 ce se asigurau c\u0103 totul este \u00een regul\u0103, traficul era comutat. Acesta \u00eencepea s\u0103 curg\u0103 pe serverul care p\u00e2n\u0103 atunci era tail. Iar serverul care anterior era head r\u0103m\u00e2nea f\u0103r\u0103 trafic de utilizatori, av\u00e2nd \u00een continuare versiunea anterioar\u0103 a aplica\u021biei noastre.<\/p>\n

Astfel, pentru utilizatori, a fost f\u0103r\u0103 \u00eentreruperi. Deoarece comutarea este instantanee, fiindc\u0103 este pur \u0219i simplu o schimbare a echilibratorului. Este foarte u\u0219or s\u0103 reveni\u021bi la versiunea anterioar\u0103, pur \u0219i simplu comut\u00e2nd echilibratorul \u00eenapoi. De asemenea, am putut verifica capacitatea aplica\u021biei \u00een produc\u021bie \u00eenainte ca traficul utilizatorilor s\u0103 ajung\u0103 la ea, ceea ce a fost destul de convenabil. <\/p>\n

Ce avantaje am observat \u00een tot acest proces?<\/p>\n

    \n
  1. \u00cen primul r\u00e2nd, este destul de simplu de utilizat.<\/b> Toat\u0103 lumea \u00een\u021belege cum func\u021bioneaz\u0103 un astfel de sistem de implementare, deoarece majoritatea oamenilor au implementat vreodat\u0103 pe servere virtuale obi\u0219nuite.<\/li>\n
  2. Este destul de fiabil<\/b>, deoarece tehnologia de implementare este simpl\u0103, testat\u0103 de mii de companii. Milioane de servere sunt implementate \u00een acest fel. Este greu s\u0103 strici ceva. <\/li>\n
  3. \u0218i \u00een final, am putut ob\u021bine implement\u0103ri atomice<\/b>. Implement\u0103rile care au loc instantaneu pentru utilizatori, f\u0103r\u0103 o etap\u0103 vizibil\u0103 de comutare \u00eentre versiunea veche \u0219i cea nou\u0103. <\/li>\n<\/ol>\n

    \nDar \u00een tot acest proces am observat \u0219i c\u00e2teva dezavantaje: <\/p>\n

      \n
    1. Pe l\u00e2ng\u0103 mediul de produc\u021bie, mediile de dezvoltare, exist\u0103 \u0219i alte medii. De exemplu, QA \u0219i preproduc\u021bie. La acel moment, aveam multe servere \u0219i aproximativ 60 de servicii. Din acest motiv, a fost necesar s\u0103 men\u021binem o versiune relevant\u0103 pentru fiecare serviciu <\/b>a ma\u0219inii virtuale. \u00cen plus, dac\u0103 dori\u021bi s\u0103 actualiza\u021bi bibliotecile sau s\u0103 ad\u0103uga\u021bi noi dependen\u021be, trebuie s\u0103 face\u021bi asta \u00een toate mediile. De asemenea, era necesar s\u0103 sincroniz\u0103m momentul \u00een care dori\u021bi s\u0103 implementa\u021bi o nou\u0103 versiune a aplica\u021biei cu momentul \u00een care devops-ul va efectua set\u0103rile necesare ale mediului. \u00cen acest caz, este u\u0219or s\u0103 ajunge\u021bi \u00eentr-o situa\u021bie \u00een care mediul s\u0103 difere considerabil \u00eentre toate mediile. De exemplu, \u00een mediul QA vor fi versiuni diferite ale bibliotecilor, iar \u00een produc\u021bie alte versiuni, ceea ce va duce la probleme. <\/li>\n
    2. Dificult\u0103\u021bi \u00een actualizarea dependen\u021belor<\/b> aplica\u021biei dumneavoastr\u0103. Aceasta nu depinde de dumneavoastr\u0103, ci de o alt\u0103 echip\u0103. Anume, echipa devops, care \u00eentre\u021bine serverele. Trebuie s\u0103 le stabili\u021bi sarcinile corespunz\u0103toare \u0219i s\u0103 le oferi\u021bi o descriere a ceea ce dori\u021bi s\u0103 realiza\u021bi.<\/li>\n
    3. \u00cen acea perioad\u0103, ne-am dorit s\u0103 \u00eemp\u0103r\u021bim monoli\u021bii mari pe care \u00eei aveam \u00een servicii mici, deoarece ne-am dat seama c\u0103 num\u0103rul acestora va cre\u0219te constant. La acel moment, deja aveam peste 100 dintre ele. Era necesar s\u0103 cre\u0103m o ma\u0219in\u0103 virtual\u0103 separat\u0103 pentru fiecare nou serviciu, care necesita \u00eentre\u021binere \u0219i implementare. \u00cen plus, era nevoie de cel pu\u021bin dou\u0103 ma\u0219ini. La toate acestea se ad\u0103uga \u0219i un mediu QA. Acest lucru provoac\u0103 probleme \u0219i face ca crearea \u0219i lansarea de noi sisteme s\u0103 fie mai complex, costisitor \u0219i de lung\u0103 durat\u0103.<\/b><\/li>\n<\/ol>\n

      \nPrin urmare, am decis c\u0103 va fi mai convenabil s\u0103 trecem de la implementarea ma\u0219inilor virtuale obi\u0219nuite la implementarea aplica\u021biilor noastre \u00eentr-un container Docker. Av\u00e2nd Docker, este necesar\u0103 o sistem\u0103 care s\u0103 poat\u0103 rula aplica\u021bia \u00eentr-un cluster, deoarece nu po\u021bi lansa pur \u0219i simplu un container. De obicei, vrei s\u0103 monitorizezi c\u00e2te containere sunt active, astfel \u00eenc\u00e2t s\u0103 se porneasc\u0103 automat. Din acest motiv, a trebuit s\u0103 alegem un sistem de management. <\/p>\n

      Am reflectat mult la care dintre ele s\u0103 alegem. Problema era c\u0103, la acel moment, acest stack de implementare pe servere virtuale obi\u0219nuite era oarecum \u00eenvechit, deoarece nu aveam cele mai recente versiuni ale sistemelor de operare. La un moment dat, avea chiar \u0219i FreeBSD, care era greu de \u00eentre\u021binut. Ne-am dat seama c\u0103 trebuie s\u0103 migram c\u00e2t mai repede \u00een Docker. DevOps-ii no\u0219tri s-au uitat la experien\u021ba lor existent\u0103 cu diferite solu\u021bii \u0219i au ales un sistem numit Nomad. <\/p>\n

      Trecerea la Nomad<\/h1>\n

      \nNomad este un produs de la compania \"HashiCorp\". Ace\u0219tia sunt cunoscu\u021bi \u0219i pentru alte solu\u021bii ale lor:<\/p>\n

      \"Dezvoltarea
      \n
      \n\"Consul\"<\/b> \u2014 este un instrument pentru descoperirea serviciilor.<\/p>\n

      \"Terraform\"<\/b> \u2014 este un sistem pentru gestionarea serverelor, care v\u0103 permite s\u0103 le configura\u021bi printr-o configurare, numit\u0103 infrastructure-as-code.<\/p>\n

      \"Vagrant\"<\/b> permite desf\u0103\u0219urarea de ma\u0219ini virtuale local sau \u00een cloud prin intermediul unor fi\u0219iere de configurare specifice. <\/p>\n

      Nomad ni s-a p\u0103rut o solu\u021bie suficient de simpl\u0103, la care putem trece rapid f\u0103r\u0103 a modifica \u00eentreaga infrastructur\u0103. \u00cen plus, este destul de u\u0219or de st\u0103p\u00e2nit. De aceea, l-am ales ca sistem de filtrare a containerelor noastre. <\/p>\n

      Ce ave\u021bi nevoie pentru a implementa efectiv sistemul dvs. \u00een Nomad? <\/p>\n

        \n
      1. \u00cen primul r\u00e2nd, ave\u021bi nevoie de imagine Docker<\/b> aplica\u021biei dumneavoastr\u0103. Este necesar s\u0103 o construi\u021bi \u0219i s\u0103 o plasa\u021bi \u00een depozitul de imagini docker. \u00cen cazul nostru, acesta este artifactory - un sistem care permite \u00eenc\u0103rcarea \u00een el a diferitelor artefacte de diverse tipuri. Poate stoca arhive, imagini docker, pachete composer PHP, pachete NPM \u0219i a\u0219a mai departe. <\/li>\n
      2. De asemenea, este necesar de configurare<\/b>, care va informa Nomad ce, unde \u0219i \u00een ce cantitate dori\u021bi s\u0103 desf\u0103\u0219ura\u021bi. <\/li>\n<\/ol>\n

        \nC\u00e2nd vorbim despre Nomad, acesta folose\u0219te ca format de fi\u0219ier informa\u021bional limbajul HCL, care se decodific\u0103 ca HashiCorp Configuration Language<\/i>. Este un superset al Yaml, care v\u0103 permite s\u0103 descrie\u021bi serviciul dumneavoastr\u0103 \u00een termenii Nomad. <\/p>\n

        \"Dezvoltarea
        \n
        \nAcesta permite s\u0103 specifica\u021bi c\u00e2te containere dori\u021bi s\u0103 desf\u0103\u0219ura\u021bi, din ce imagini s\u0103 le transmite\u021bi diferite parametrii \u00een timpul desf\u0103\u0219ur\u0103rii. Astfel, alimenta\u021bi acest fi\u0219ier Nomad \u0219i el porne\u0219te containerele \u00een produc\u021bie conform lui. <\/p>\n

        \u00cen cazul nostru, am realizat c\u0103 pur \u0219i simplu scrierea de fi\u0219iere HCL complet identice pentru fiecare serviciu nu va fi foarte convenabil\u0103, deoarece sunt multe servicii \u0219i uneori dorim s\u0103 le actualiz\u0103m. Exist\u0103 cazuri \u00een care un serviciu nu este desf\u0103\u0219urat \u00eentr-un singur exemplar, ci \u00een mai multe. De exemplu, unul dintre sistemele noastre aflate \u00een produc\u021bie are peste 100 de instan\u021be \u00een produc\u021bie. Acestea sunt lansate din acelea\u0219i imagini, dar difer\u0103 \u00een set\u0103rile de configurare \u0219i fi\u0219ierele de configurare. <\/p>\n

        De aceea, am decis c\u0103 va fi convenabil s\u0103 p\u0103str\u0103m toate fi\u0219ierele noastre de configurare pentru desf\u0103\u0219urare \u00eentr-un singur repository comun. Astfel, acestea devin vizibile: este u\u0219or s\u0103 le \u00eentre\u021bine\u021bi \u0219i este posibil s\u0103 vede\u021bi ce sisteme avem. \u00cen caz de necesitate, nu este greu s\u0103 actualiz\u0103m sau s\u0103 schimb\u0103m ceva. Ad\u0103ugarea unui nou sistem nu va fi nici ea dificil\u0103 \u2013 este suficient s\u0103 crea\u021bi un fi\u0219ier de configurare \u00een interiorul unui nou director. \u00cen interiorul acestuia se afl\u0103 fi\u0219ierele: service.hcl, care con\u021bine descrierea serviciului nostru, \u0219i c\u00e2teva fi\u0219iere env, care permit acest serviciu, odat\u0103 desf\u0103\u0219urat \u00een produc\u021bie, s\u0103 fie configurat. <\/p>\n

        \"Dezvoltarea
        \n
        \nCu toate acestea, unele dintre sistemele noastre sunt desf\u0103\u0219urate \u00een produc\u021bie nu \u00eentr-un singur exemplar, ci simultan \u00een mai multe. Prin urmare, am decis c\u0103 ne va fi convenabil s\u0103 stoc\u0103m nu configura\u021biile \u00een form\u0103 pur\u0103, ci versiunea lor \u0219ablonizat\u0103. \u0218i limbajul de \u0219ablonizare pe care l-am ales este jinja 2<\/i>. \u00cen acest format, p\u0103str\u0103m at\u00e2t configura\u021biile serviciului, c\u00e2t \u0219i fi\u0219ierele env necesare pentru acesta. <\/p>\n

        \u00cen plus, am plasat \u00een repository-ul comun pentru toate proiectele un script-deploy care permite lansarea \u0219i desf\u0103\u0219urarea serviciului dvs. \u00een produc\u021bie, \u00een mediu dorit \u0219i c\u0103tre \u021binta dorit\u0103. \u00cen cazul \u00een care am transformat configura\u021bia noastr\u0103 HCL \u00eentr-un \u0219ablon, fi\u0219ierul HCL care anterior era o configura\u021bie obi\u0219nuit\u0103 Nomad a devenit \u00eentr-un fel diferit.<\/p>\n

        \"Dezvoltarea
        \n
        \nAsta \u00eenseamn\u0103 c\u0103 am \u00eenlocuit anumite variabile ale configura\u021biei cu inser\u021bii de variabile provenite din fi\u0219ierele env sau din alte surse. \u00cen plus, am ob\u021binut capacitatea de a genera fi\u0219iere HCL dinamic, adic\u0103 putem aplica nu doar inser\u021bii obi\u0219nuite de variabile. Deoarece jinja suport\u0103 bucle \u0219i condi\u021bii, putem crea fi\u0219iere de configura\u021bie care se schimb\u0103 \u00een func\u021bie de locul unde desf\u0103\u0219ura\u021bi aplica\u021biile dvs. <\/p>\n

        De exemplu, dori\u021bi s\u0103 desf\u0103\u0219ura\u021bi serviciul dvs. \u00een pre-produc\u021bie \u0219i \u00een produc\u021bie. S\u0103 presupunem c\u0103 \u00een pre-produc\u021bie nu dori\u021bi s\u0103 lansa\u021bi cron-scripte, ci doar dori\u021bi s\u0103 vede\u021bi serviciul pe un domeniu separat pentru a verifica dac\u0103 func\u021bioneaz\u0103. Pentru oricine desf\u0103\u0219oar\u0103 un serviciu, procesul pare foarte simplu \u0219i transparent. E suficient s\u0103 rula\u021bi fi\u0219ierul deploy.sh, s\u0103 specifica\u021bi ce serviciu dori\u021bi s\u0103 desf\u0103\u0219ura\u021bi \u0219i c\u0103tre ce \u021bint\u0103. De exemplu, dori\u021bi s\u0103 desf\u0103\u0219ura\u021bi o anumit\u0103 sistem \u00een Rusia, Belarus sau Kazahstan. Pentru aceasta, e suficient s\u0103 schimba\u021bi unul dintre parametrii, iar fi\u0219ierul de configura\u021bie corect va fi generat. <\/p>\n

        C\u00e2nd serviciul Nomad este deja desf\u0103\u0219urat \u00een clusterul dvs., acesta va ar\u0103ta astfel.<\/p>\n

        \"Dezvoltarea
        \n
        \nPentru \u00eenceput, ave\u021bi nevoie de un anumit echilibrator extern, care va accepta tot traficul utilizatorilor. Acesta va func\u021biona \u00eempreun\u0103 cu Consul \u0219i va afla de la el unde, pe ce nod, \u0219i prin ce adresa IP<\/a> se afl\u0103 serviciul specific care corespunde unui anumit nume de domeniu. Serviciile \u00een Consul apar din Nomad. Deoarece sunt produse ale acelea\u0219i companii, sunt bine interconectate. Se poate spune c\u0103 Nomad \u0219tie din cutie s\u0103 \u00eenregistreze toate serviciile desf\u0103\u0219urate \u00een el \u00een cadrul Consul. <\/p>\n

        Dup\u0103 ce echilibratorul dvs. extern afl\u0103 c\u0103tre ce serviciu trebuie s\u0103 redirec\u021bioneze traficul, acesta \u00eel trimite \u00een containerele corespunz\u0103toare aplica\u021biei dvs. Este evident c\u0103 trebuie s\u0103 \u021binem cont \u0219i de securitate. Chiar dac\u0103 toate serviciile ruleaz\u0103 pe acelea\u0219i ma\u0219ini virtuale \u00een containere, este necesar s\u0103 interzicem accesul liber din orice serviciu c\u0103tre orice alt serviciu. Am realizat acest lucru prin segmentare. Fiecare serviciu era rulat \u00eentr-o re\u021bea virtual\u0103 separat\u0103, pe care erau definite reguli de rutare \u0219i reguli de permisiune\/interzicere a accesului la celelalte sisteme \u0219i servicii. Acestea puteau fi at\u00e2t \u00een interiorul acestui cluster, c\u00e2t \u0219i \u00een afara sa. De exemplu, dac\u0103 dori\u021bi s\u0103 interzice\u021bi unui serviciu s\u0103 se conecteze la o anumit\u0103 baz\u0103 de date, acest lucru se poate face prin segmentare la nivel de re\u021bea. Asta \u00eenseamn\u0103 c\u0103, chiar \u0219i din gre\u0219eal\u0103, nu pute\u021bi conecta din mediu de testare la baza dvs. de date de produc\u021bie.<\/p>\n

        C\u00e2t ne-a costat procesul de tranzi\u021bie \u00een termeni de resurse umane? <\/p>\n

        Tranzi\u021bia \u00eentregii companii la Nomad a durat aproximativ 5-6 luni. Am migrat serviciile unul c\u00e2te unul, dar \u00eentr-un ritm suficient de rapid. Fiecare echip\u0103 a trebuit s\u0103 creeze propriile sale containere pentru servicii. <\/p>\n

        Adopt\u0103m o abordare conform c\u0103reia fiecare echip\u0103 este responsabil\u0103 de imaginile docker ale sistemelor sale. DevOps ofer\u0103 infrastructura comun\u0103 necesar\u0103 pentru desf\u0103\u0219urare, adic\u0103 suportul pentru cluster, suportul pentru sistemul CI etc. \u00cen acel moment, mai mult de 60 de sisteme au migrat la Nomad, rezult\u00e2nd aproximativ 2000 de containere. <\/p>\n

        DevOps este responsabil pentru infrastructura general\u0103 a tot ceea ce \u021bine de desf\u0103\u0219urare \u0219i servere. \u00cen acela\u0219i timp, fiecare echip\u0103 de dezvoltare este responsabil\u0103 pentru implementarea containerelor pentru sistemul s\u0103u specific, deoarece echipa \u0219tie exact ce are nevoie \u00een acel container.<\/p>\n

        Motivele pentru care am renun\u021bat la Nomad<\/h1>\n

        \nCe avantaje am ob\u021binut prin migrarea la desf\u0103\u0219urarea cu ajutorul Nomad \u0219i Docker, printre altele?<\/p>\n

          \n
        1. Noi am asigurat condi\u021bii uniforme<\/b> pentru toate medii. \u00cen dezvoltare, mediu QA, pre-produc\u021bie, produc\u021bie se utilizeaz\u0103 acelea\u0219i imagini de containere, cu acelea\u0219i dependen\u021be. Prin urmare, avem practic o \u0219ans\u0103 minim\u0103 ca \u00een produc\u021bie s\u0103 ajung\u0103 ceva diferit de ceea ce a\u021bi testat local sau \u00een mediul de testare. <\/li>\n
        2. De asemenea, am descoperit c\u0103 este suficient s\u0103 ad\u0103ug\u0103m un nou serviciu<\/b>. Orice sisteme noi, din punct de vedere al desf\u0103\u0219ur\u0103rii, sunt foarte u\u0219or de lansat. Este suficient s\u0103 merge\u021bi \u00een depozitul care stocheaz\u0103 configur\u0103rile, s\u0103 ad\u0103uga\u021bi acolo o nou\u0103 configura\u021bie pentru sistemul dvs. \u0219i totul este preg\u0103tit. Pute\u021bi desf\u0103\u0219ura sistemul dvs. \u00een produc\u021bie f\u0103r\u0103 eforturi suplimentare din partea DevOps. <\/li>\n
        3. Toate fi\u0219ierele de configurare<\/b> \u00eentr-un singur depozit comun s-au dovedit a fi revizuite<\/b>. \u00cen momentul \u00een care desf\u0103\u0219uram sistemele noastre folosind servere virtuale<\/a>, am folosit Ansible, unde configura\u021biile erau p\u0103strate \u00een acela\u0219i depozit. Totu\u0219i, pentru cea mai mare parte a dezvoltatorilor, lucrul cu acest lucru a fost pu\u021bin mai complicat. Volumul de configura\u021bii \u0219i cod pe care trebuie s\u0103-l ad\u0103uga\u021bi pentru a desf\u0103\u0219ura un serviciu a devenit mult mai mic. \u00cen plus, pentru DevOps este foarte simplu s\u0103-l corecteze sau s\u0103-l schimbe. \u00cen cazul tranzi\u021biilor, de exemplu, atunci c\u00e2nd se trece la o nou\u0103 versiune a Nomad, ei pot s\u0103 ia \u0219i s\u0103 actualizeze masiv toate fi\u0219ierele opera\u021bionale care se afl\u0103 \u00een acela\u0219i loc.<\/li>\n<\/ol>\n

          \nDar ne-am confruntat \u0219i cu c\u00e2teva dezavantaje: <\/p>\n

          S-a dovedit c\u0103 nu am putut s\u0103 atingem desf\u0103\u0219ur\u0103ri f\u0103r\u0103 cusur <\/b>\u00een cazul Nomad. La lansarea containerelor din diferite condi\u021bii, s-a putut \u00eent\u00e2mpla ca acesta s\u0103 fie pornit, iar Nomad s\u0103-l perceap\u0103 ca fiind gata s\u0103 primeasc\u0103 trafic. Acest lucru se \u00eent\u00e2mpla \u00eenainte ca aplica\u021bia din interior s\u0103 apuce s\u0103 porneasc\u0103. Din acest motiv, sistemul \u00eencepea s\u0103 returneze erori 500 pentru o perioad\u0103 scurt\u0103, deoarece traficul \u00eencepea s\u0103 se \u00eendrepte c\u0103tre un container care nu era \u00eenc\u0103 preg\u0103tit s\u0103-l primeasc\u0103. <\/p>\n

          Ne-am confruntat cu unele bug-uri<\/b>. Cea mai semnificativ\u0103 problem\u0103 este c\u0103 Nomad nu gestioneaz\u0103 foarte bine un cluster mare, dac\u0103 ave\u021bi multe sisteme \u0219i containere. C\u00e2nd dori\u021bi s\u0103 scoate\u021bi din func\u021bionare unul dintre serverele care face parte din clusterul Nomad, exist\u0103 o probabilitate destul de mare ca clusterul s\u0103 nu se simt\u0103 foarte bine \u0219i s\u0103 se destrame. Unele containere pot, de exemplu, s\u0103 cad\u0103 \u0219i s\u0103 nu se reporneasc\u0103 \u2013 acest lucru v\u0103 va costa foarte mult dac\u0103 toate sistemele dumneavoastr\u0103 de produc\u021bie se afl\u0103 \u00een clusterul gestionat de Nomad. <\/p>\n

          De aceea, am decis s\u0103 ne g\u00e2ndim la direc\u021bia pe care s\u0103 o lu\u0103m mai departe. La acea vreme am devenit mult mai con\u0219tien\u021bi de ceea ce ne dorim s\u0103 realiz\u0103m. Adic\u0103: vrem fiabilitate, pu\u021bin mai multe func\u021bionalit\u0103\u021bi dec\u00e2t ofer\u0103 Nomad \u0219i un sistem mai matur, mai stabil. <\/p>\n

          \u00cen aceast\u0103 privin\u021b\u0103, alegerea noastr\u0103 a c\u0103zut pe Kubernetes ca cea mai popular\u0103 platform\u0103 pentru lansarea clusterelor. Mai ales av\u00e2nd \u00een vedere c\u0103 dimensiunea \u0219i num\u0103rul containerelor noastre erau destul de mari. Pentru aceste scopuri, Kubernetes s-a dovedit a fi sistemul cel mai potrivit dintre cele pe care le-am putut evalua. <\/p>\n

          Tranzi\u021bia la Kubernetes<\/h1>\n

          \nVoi explica pu\u021bin care sunt conceptele de baz\u0103 \u00een Kubernetes \u0219i cu ce se diferen\u021biaz\u0103 acestea fa\u021b\u0103 de Nomad. <\/p>\n

          \"Dezvoltarea
          \n
          \n\u00cen primul r\u00e2nd, cel mai de baz\u0103 concept \u00een Kubernetes este conceptul de pod. Pod<\/b> \u2013 este un grup de unul sau mai multe containere care sunt \u00eentotdeauna lansate \u00eempreun\u0103. \u0218i ele func\u021bioneaz\u0103 ca \u0219i cum ar rula \u00eentotdeauna strict pe aceea\u0219i ma\u0219in\u0103 virtual\u0103. Ele sunt accesibile \u00eentre ele prin adresa IP 127.0.0.1 pe por\u021bi diferite. <\/p>\n

          S\u0103 presupunem c\u0103 ave\u021bi o aplica\u021bie PHP care const\u0103 din nginx \u0219i php-fpm \u2013 o schem\u0103 clasic\u0103. Cel mai probabil, ve\u021bi dori ca at\u00e2t containerele nginx c\u00e2t \u0219i php-fpm s\u0103 fie \u00eentotdeauna \u00eempreun\u0103. Kubernetes permite acest lucru, descriindu-le ca un singur pod comun. Acesta este exact ceea ce nu puteam ob\u021bine cu ajutorul Nomad.<\/p>\n

          Al doilea concept este deployment<\/b>. Problema este c\u0103 un pod \u00een sine este o entitate efemer\u0103, se lanseaz\u0103 \u0219i dispare. Vre\u021bi s\u0103 omor\u00e2\u021bi mai \u00eent\u00e2i toate containerele anterioare \u0219i apoi s\u0103 lansa\u021bi direct versiunile noi sau dori\u021bi s\u0103 le lansa\u021bi treptat \u2013 exact de acest proces se ocup\u0103 conceptul de deployment. Acesta descrie modul \u00een care desf\u0103\u0219ura\u021bi pod-urile, \u00een ce num\u0103r \u0219i cum s\u0103 le actualiza\u021bi. <\/p>\n

          Al treilea concept este service<\/b>. Serviciul dvs. este, de fapt, sistemul dvs. care prime\u0219te un anumit trafic \u0219i apoi \u00eel direc\u021bioneaz\u0103 c\u0103tre unul sau mai multe poduri corespunz\u0103toare serviciului dvs. Asta \u00eenseamn\u0103 c\u0103 permite\u021bi s\u0103 se spun\u0103 c\u0103 tot traficul de intrare pentru un anumit serviciu cu un anumit nume trebuie trimis exact la aceste poduri. \u0218i, \u00een acela\u0219i timp, v\u0103 ofer\u0103 un echilibru al traficului. Adic\u0103 pute\u021bi lansa dou\u0103 poduri ale aplica\u021biei dvs. \u0219i tot traficul de intrare va fi echilibrat uniform \u00eentre podurile care sunt asociate cu acest serviciu.<\/p>\n

          \u0218i al patrulea concept de baz\u0103 \u2014 Ingress<\/b>. Acesta este un serviciu care ruleaz\u0103 \u00een clusterul Kubernetes. Acesta ac\u021bioneaz\u0103 ca un echilibrator extern de sarcin\u0103 care preia toate cererile. Prin intermediul API-ului Kubernetes Ingress, poate determina unde trebuie direc\u021bionate aceste cereri. \u0218i face acest lucru foarte flexibil. Pute\u021bi spune c\u0103 toate cererile pentru acest host \u0219i acest URL sunt trimise la acest serviciu. Iar aceste cereri, care sosesc la acest host \u0219i un alt URL, sunt trimise la un alt serviciu. <\/p>\n

          Cel mai interesant din perspectiva celui care dezvolt\u0103 aplica\u021bia este c\u0103 ave\u021bi capacitatea de a gestiona totul singur. Definind configura\u021bia Ingress, pute\u021bi trimite tot traficul care vine pe un anumit API la containere separate, specificate, de exemplu, \u00een Go. Iar acest trafic, care vine pe acela\u0219i domeniu, dar la un alt URL, este trimis pe containere scrise \u00een PHP, unde exist\u0103 mult\u0103 logic\u0103, dar nu sunt foarte rapide.<\/p>\n

          Dac\u0103 compar\u0103m toate aceste concepte cu Nomad, putem spune c\u0103 primele trei concepte \u00eempreun\u0103 constituie un serviciu. Iar ultimul concept este, \u00een Nomad, inexistent. Am folosit un echilibrator extern pentru acesta: ar putea fi haproxy, nginx, nginx+ \u0219i a\u0219a mai departe. \u00cen cazul Kubernetes, nu trebuie s\u0103 introduce\u021bi acest concept suplimentar separat. Totu\u0219i, dac\u0103 privim Ingress din interior, acesta este fie nginx, fie haproxy, fie traefik, dar cumva integrat \u00een Kubernetes. <\/p>\n

          Toate conceptele descrise de mine sunt, \u00een esen\u021b\u0103, resurse care exist\u0103 \u00een interiorul clusterului Kubernetes. Pentru a le descrie \u00een Kubernetes, este utilizat formatul yaml, care este mai u\u0219or de citit \u0219i mai familiar dec\u00e2t fi\u0219ierele HCL \u00een cazul Nomad. Dar, din punct de vedere structural, ele descriu, de exemplu, podurile aceea\u0219i lucru. Spun \u2013 vreau s\u0103 desf\u0103\u0219or anumite poduri acolo, cu anumite imagini, \u00eentr-un anumit num\u0103r. <\/p>\n

          \"Dezvoltarea
          \n
          \n\u00cen plus, am realizat c\u0103 nu vrem s\u0103 cre\u0103m manual fiecare resurs\u0103 individual\u0103: deployment, servicii, Ingress \u0219i altele. \u00cen schimb, ne-am dorit s\u0103 descriem fiecare sistem existent \u00een termeni de Kubernetes la desf\u0103\u0219urare, pentru a nu fi nevoi\u021bi s\u0103 recre\u0103m manual toate dependen\u021bele necesare \u00een ordinea dorit\u0103. Sistemul ales pentru a ne permite acest lucru a fost Helm. <\/p>\n

          Conceptelor fundamentale \u00een Helm<\/h1>\n

          \nHelm este un manager de pachete<\/b> pentru Kubernetes. Este foarte similar cu modul \u00een care func\u021bioneaz\u0103 managerii de pachete \u00een limbajele de programare. Ei v\u0103 permit s\u0103 stoca\u021bi un serviciu format, de exemplu, din deployment nginx, deployment php-fpm, configura\u021bia pentru Ingress, configmaps (aceasta este o entitate care v\u0103 permite s\u0103 defini\u021bi env \u0219i alte parametri pentru sistemul dumneavoastr\u0103) sub form\u0103 de a\u0219a-numite chart-uri. \u00cen acest context, Helm func\u021bioneaz\u0103 deasupra Kubernetes<\/b>. Adic\u0103 nu este un sistem separat, ci un alt serviciu care ruleaz\u0103 \u00een interiorul cluster-ului. Interac\u021biona\u021bi cu el prin API-ul s\u0103u folosind comenzi \u00een linia de comand\u0103. Avantajul \u0219i frumuse\u021bea sa const\u0103 \u00een faptul c\u0103, chiar dac\u0103 Helm se stric\u0103 sau \u00eel \u0219terge\u021bi din cluster, serviciile dumneavoastr\u0103 nu dispar, deoarece Helm serve\u0219te practic doar pentru a lansa sistemul. Func\u021bionarea \u0219i starea serviciilor sunt gestionate ulterior de Kubernetes. <\/p>\n

          De asemenea, am realizat c\u0103 \u0219ablonizarea<\/b>, pe care anterior eram nevoi\u021bi s\u0103 o facem manual prin integrarea jinja \u00een configura\u021biile noastre, este una dintre func\u021bionalit\u0103\u021bile principale ale Helm. Toate configura\u021biile pe care le crea\u021bi pentru sistemele dumneavoastr\u0103 sunt stocate \u00een Helm sub form\u0103 de \u0219abloane, care seam\u0103n\u0103 pu\u021bin cu jinja, dar, de fapt, folosesc \u0219ablonizarea limbajului Go, pe care Helm este scris, la fel ca \u0219i Kubernetes. <\/p>\n

          Helm ne adaug\u0103 \u00eenc\u0103 c\u00e2teva concepte suplimentare. <\/p>\n

          Chart<\/b> \u2014 este descrierea serviciului dumneavoastr\u0103. \u00cen alte manageri de pachete, ar fi fost numit pachet, bundle sau ceva de genul acesta. Aici se nume\u0219te chart. <\/p>\n

          Values <\/b>\u2013 sunt variabilele pe care dori\u021bi s\u0103 le folosi\u021bi pentru construirea configura\u021biilor din \u0219abloane. <\/p>\n

          Release<\/b>. De fiecare dat\u0103 c\u00e2nd un serviciu este implementat prin helm, prime\u0219te o versiune incremental\u0103 a lans\u0103rii. Helm \u00ee\u0219i aminte\u0219te care a fost configura\u021bia serviciului la lans\u0103rile anterioare. A\u0219adar, dac\u0103 trebuie s\u0103 reveni\u021bi, este suficient s\u0103 executa\u021bi comanda helm callback, specific\u00e2nd versiunea anterioar\u0103 a lans\u0103rii. Chiar dac\u0103 configura\u021bia corespunz\u0103toare nu este disponibil\u0103 \u00een depozitul dvs. \u00een momentul revenirii, helm \u00ee\u0219i aminte\u0219te cum era \u0219i va restaura sistemul la starea pe care o avea la lansarea anterioar\u0103. <\/p>\n

          \u00cen cazul \u00een care folosim helm, configura\u021biile obi\u0219nuite pentru Kubernetes se transform\u0103, de asemenea, \u00een template-uri, \u00een care exist\u0103 op\u021biunea de a folosi variabile, func\u021bii \u0219i de a aplica operatori condi\u021bionali. Astfel, pute\u021bi construi configura\u021bia serviciului dvs. \u00een func\u021bie de mediu.<\/p>\n

          \"Dezvoltarea
          \n
          \n\u00cen practic\u0103, am decis s\u0103 proced\u0103m pu\u021bin diferit fa\u021b\u0103 de modul \u00een care am ac\u021bionat cu Nomad. Dac\u0103 \u00een Nomad configura\u021biile pentru implement\u0103ri \u0219i variabilele necesare pentru a implementa serviciul erau p\u0103strate \u00eentr-un singur depozit, aici am decis s\u0103 le separ\u0103m \u00een dou\u0103 depozite distincte. \u00cen depozitul \u201edeploy\u201d sunt stocate doar variabilele necesare pentru implementare, iar \u00een depozitul \u201ehelm\u201d sunt stocate configura\u021biile sau chart-urile.<\/p>\n

          \"Dezvoltarea
          \n
          \nCe ne-a adus asta? <\/p>\n

          De\u0219i \u00een fi\u0219ierele de configura\u021bie nu stoc\u0103m date cu adev\u0103rat sensibile, cum ar fi parolele pentru bazele de date. Acestea sunt stocate sub form\u0103 de secrets \u00een Kubernetes, dar totu\u0219i, exist\u0103 anumite lucruri la care nu dorim s\u0103 oferim acces tuturor. Prin urmare, accesul la depozitul \u201edeploy\u201d este mai restric\u021bionat, iar depozitul \u201ehelm\u201d con\u021bine doar o descriere a serviciului. Din acest motiv, acesta poate fi accesat \u00een siguran\u021b\u0103 de un cerc mai larg de persoane. <\/p>\n

          Av\u00e2nd \u00een vedere c\u0103 avem nu doar produc\u021bie, ci \u0219i alte medii, aceast\u0103 separare ne permite s\u0103 reutiliz\u0103m chart-urile helm pentru a implementa servicii nu doar \u00een produc\u021bie, ci \u0219i, de exemplu, \u00een medii QA. Chiar \u0219i pentru a le desf\u0103\u0219ura local, folosind Minikube<\/i> \u2014 este un astfel de instrument pentru rularea local\u0103 a Kubernetes. <\/p>\n

          \u00cen fiecare repository, am l\u0103sat o separare \u00een directoare separate pentru fiecare serviciu. Astfel, \u00een interiorul fiec\u0103rui director se afl\u0103 \u0219abloanele care se refer\u0103 la graficul corespunz\u0103tor \u0219i descriu resursele care trebuie desf\u0103\u0219urate pentru a lansa sistemul nostru. \u00cen repository-ul \u201edeploy\u201d, am l\u0103sat doar env-urile. \u00cen acest caz, nu am folosit \u0219ablonizarea cu jinja, deoarece helm ofer\u0103 deja \u0219ablonizare din cutie \u2013 aceasta este una dintre func\u021biile principale ale sale. <\/p>\n

          Am l\u0103sat un script pentru desf\u0103\u0219urare \u2013 deploy.sh, care simplific\u0103 \u0219i standardizeaz\u0103 lansarea desf\u0103\u0219ur\u0103rii utiliz\u00e2nd helm. Astfel, pentru oricine dore\u0219te s\u0103 desf\u0103\u0219oare, interfa\u021ba de desf\u0103\u0219urare arat\u0103 exact la fel ca \u00een cazul desf\u0103\u0219ur\u0103rii prin Nomad. Acela\u0219i deploy.sh, numele serviciului dvs. \u0219i locul unde dori\u021bi s\u0103-l desf\u0103\u0219ura\u021bi. Acest lucru determin\u0103 ca helm s\u0103 fie invocat. Acesta, la r\u00e2ndul s\u0103u, adun\u0103 configura\u021biile din \u0219abloane, le integreaz\u0103 cu fi\u0219ierele values necesare, apoi desf\u0103\u0219oar\u0103, lans\u00e2ndu-le \u00een Kubernetes. <\/p>\n

          Conclusions<\/h1>\n

          \nServiciul Kubernetes pare mai complex dec\u00e2t Nomad. <\/p>\n

          \"Dezvoltarea
          \n
          \nAici, traficul de ie\u0219ire ajunge \u00een Ingress. Acesta este controller-ul frontal care preia toate cererile \u0219i ulterior le trimite serviciilor corespunz\u0103toare datelor cererii. El le identific\u0103 pe baza configura\u021biilor care fac parte din descrierea aplica\u021biei dvs. \u00een helm \u0219i pe care dezvoltatorii le stabilesc singuri. Serviciul, la r\u00e2ndul s\u0103u, trimite cererile c\u0103tre pod-urile sale, adic\u0103 containerele specifice, balans\u00e2nd traficul de intrare \u00eentre toate containerele aferente acestui serviciu. \u0218i, bine\u00een\u021beles, nu trebuie s\u0103 uit\u0103m c\u0103 la nivel de re\u021bea, nu ar trebui s\u0103 ne abatem de la securitate. De aceea, segmentarea func\u021bioneaz\u0103 \u00een clusterul Kubernetes, bazat\u0103 pe etichetare. Toate serviciile au anumite etichete, la care sunt ata\u0219ate drepturile de acces ale serviciilor la resursele externe \/ interne, \u00een interiorul sau \u00een afara clusterului. <\/p>\n

          \u00cen timpul tranzi\u021biei, am observat c\u0103 Kubernetes are toate func\u021bionalit\u0103\u021bile lui Nomad, pe care l-am folosit anterior, dar adaug\u0103 \u0219i multe altele noi. Poate fi extins prin pluginuri \u0219i, de fapt, prin tipuri personalizate de resurse. Asta \u00eenseamn\u0103 c\u0103 ave\u021bi posibilitatea nu doar de a folosi ceva ce vine implicit \u00een Kubernetes, ci de a crea propria resurs\u0103 \u0219i serviciu care va citi acea resurs\u0103. Aceasta ofer\u0103 oportunit\u0103\u021bi suplimentare de extindere a sistemului dumneavoastr\u0103 f\u0103r\u0103 a fi nevoie de reinstalarea Kubernetes \u0219i f\u0103r\u0103 a necesita modific\u0103ri. <\/p>\n

          Un exemplu de utilizare este Prometheus, care ruleaz\u0103 \u00een interiorul clusterei Kubernetes. Pentru a \u00eencepe s\u0103 colecteze metrici de la un anumit serviciu, trebuie s\u0103 ad\u0103ug\u0103m \u00een descrierea serviciului un tip suplimentar de resurs\u0103, numit serviciu-monitor. Datorit\u0103 faptului c\u0103 Prometheus poate citi tipuri personalizate de resurse, odat\u0103 ce este pornit \u00een Kubernetes, \u00eencepe automat s\u0103 colecteze metrici de la noua sistem\u0103. Acest lucru este destul de convenabil. <\/p>\n

          Primul deploy pe care l-am realizat \u00een Kubernetes a fost \u00een martie 2018. \u0218i \u00een tot acest timp nu am avut nicio problem\u0103. Func\u021bioneaz\u0103 destul de stabil f\u0103r\u0103 erori semnificative. \u00cen plus, putem continua s\u0103-l extindem. \u00cen prezent, avem suficiente func\u021bionalit\u0103\u021bi \u00een el, iar ritmul de dezvoltare al Kubernetes ne place foarte mult. \u00cen acest moment, exist\u0103 peste 3000 de containere \u00een Kubernetes. Clusterul ocup\u0103 c\u00e2teva noduri. \u00cen acela\u0219i timp, este gestionat, stabil \u0219i foarte controlabil.
          \n
          Sursa:           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\udd47Deploy de aplica\u021bii \u00een VM, Nomad \u0219i Kubernetes | ProHoster","description":"Bun\u0103 ziua tuturor! Numele meu este Pavel Agaletki. Lucrez ca lider de echip\u0103 \u00eentr-o echip\u0103 care dezvolt\u0103 sistemul de livrare Lamoda.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}