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

Cze\u015b\u0107 wszystkim! Nazywam si\u0119 Pawe\u0142 Agalewski. Pracuj\u0119 jako team leader w zespole, kt\u00f3ry opracowuje system dostaw Lamoda. W 2018 roku wyst\u0119powa\u0142em na konferencji HighLoad++, a dzi\u015b chc\u0119 przedstawi\u0107 transkrypcj\u0119 swojego wyst\u0105pienia.<\/p>\n

M\u00f3j temat jest po\u015bwi\u0119cony do\u015bwiadczeniu naszej firmy w zakresie wdra\u017cania system\u00f3w i us\u0142ug w r\u00f3\u017cne \u015brodowiska. Zaczynaj\u0105c od naszych prehistorycznych czas\u00f3w, kiedy wdra\u017cali\u015bmy wszystkie systemy na standardowe serwery wirtualne, a\u017c po stopniowe przej\u015bcie od Nomad do wdro\u017ce\u0144 w Kubernetes. Opowiem o tym, dlaczego to zrobili\u015bmy i jakie mieli\u015bmy w tym procesie problemy.<\/p>\n

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

Wdra\u017canie aplikacji na VM<\/h1>\n

\nZacznijmy od tego, \u017ce 3 lata temu wszystkie systemy i us\u0142ugi w firmie by\u0142y wdra\u017cane na standardowych serwerach wirtualnych. Technicznie by\u0142o to zorganizowane tak, \u017ce ca\u0142y kod naszych system\u00f3w by\u0142 przechowywany i kompilowany za pomoc\u0105 automatycznego systemu budowania, przy pomocy jenkins. Przy pomocy Ansible by\u0142a on wdra\u017cana z naszej systemu kontroli wersji na serwery wirtualne. Przy tym ka\u017cdy system, kt\u00f3ry by\u0142 w naszej firmie, by\u0142 wdra\u017cany na przynajmniej 2 serwery: jeden z nich - na head, drugi - na tail. Te dwa systemy by\u0142y absolutnie identyczne pod wzgl\u0119dem wszystkich swoich ustawie\u0144, mocy, konfiguracji i innych aspekt\u00f3w. R\u00f3\u017cnica mi\u0119dzy nimi polega\u0142a jedynie na tym, \u017ce head otrzymywa\u0142 ruch u\u017cytkownik\u00f3w, a tail nigdy nie otrzymywa\u0142 ruchu u\u017cytkownik\u00f3w. <\/p>\n

Dlaczego to zosta\u0142o zrobione? <\/p>\n

Gdy wdra\u017cali\u015bmy nowe wersje naszej aplikacji, chcieli\u015bmy zapewni\u0107 mo\u017cliwo\u015b\u0107 p\u0142ynnego wdro\u017cenia, to znaczy bez zauwa\u017calnych konsekwencji dla u\u017cytkownik\u00f3w. Osi\u0105gano to poprzez to, \u017ce kolejna skompilowana wersja za pomoc\u0105 Ansible by\u0142a wdra\u017cana na tail. Tam osoby zajmuj\u0105ce si\u0119 wdro\u017ceniem mog\u0142y sprawdzi\u0107 i upewni\u0107 si\u0119, \u017ce wszystko dzia\u0142a: wszelkie metryki, sekcje i aplikacje dzia\u0142aj\u0105; uruchamiane s\u0105 potrzebne skrypty. Dopiero po upewnieniu si\u0119, \u017ce wszystko jest w porz\u0105dku, ruch by\u0142 prze\u0142\u0105czany. Zaczyna\u0142 kierowa\u0107 si\u0119 na ten serwer, kt\u00f3ry wcze\u015bniej by\u0142 tail. A ten, kt\u00f3ry wcze\u015bniej by\u0142 head-em, pozostawa\u0142 bez ruchu u\u017cytkownik\u00f3w, aczkolwiek z istniej\u0105c\u0105 na nim poprzedni\u0105 wersj\u0105 naszej aplikacji.<\/p>\n

W ten spos\u00f3b dla u\u017cytkownik\u00f3w by\u0142o to bezproblemowe. Poniewa\u017c prze\u0142\u0105czenie odbywa si\u0119 natychmiast, jako \u017ce to po prostu prze\u0142\u0105czenie r\u00f3wnowa\u017cnika obci\u0105\u017cenia. Bardzo \u0142atwo mo\u017cna wr\u00f3ci\u0107 do poprzedniej wersji, po prostu prze\u0142\u0105czaj\u0105c r\u00f3wnowa\u017cnik z powrotem. R\u00f3wnie\u017c mogli\u015bmy upewni\u0107 si\u0119 o zdolno\u015bci aplikacji w produkcji jeszcze zanim u\u017cytkownikowy ruch zacznie na ni\u0105 nap\u0142ywa\u0107, co by\u0142o do\u015b\u0107 wygodne. <\/p>\n

Jakie widzieli\u015bmy w tym wszystkim korzy\u015bci?<\/p>\n

    \n
  1. Przede wszystkim, to do\u015b\u0107 prosto dzia\u0142a.<\/b> Wszyscy rozumiej\u0105, jak funkcjonuje podobny schemat wdro\u017cenia, poniewa\u017c wi\u0119kszo\u015b\u0107 ludzi kiedykolwiek wdra\u017ca\u0142a na zwyk\u0142e serwery wirtualne.<\/li>\n
  2. To do\u015b\u0107 niezawodne<\/b>, poniewa\u017c technologia wdro\u017cenia jest prosta, przetestowana przez tysi\u0105ce firm. Miliony serwer\u00f3w wdra\u017ca si\u0119 w ten spos\u00f3b. Trudno co\u015b zepsu\u0107. <\/li>\n
  3. I w ko\u0144cu mogli\u015bmy uzyska\u0107 atomowe wdro\u017cenia<\/b>. Wdro\u017cenia, kt\u00f3re dla u\u017cytkownik\u00f3w odbywaj\u0105 si\u0119 natychmiast, bez widocznego etapu prze\u0142\u0105czania mi\u0119dzy star\u0105 a now\u0105 wersj\u0105. <\/li>\n<\/ol>\n

    \nAle w tym wszystkim widzieli\u015bmy tak\u017ce kilka wad: <\/p>\n

      \n
    1. Opr\u00f3cz \u015brodowiska produkcyjnego, jest tak\u017ce \u015brodowisko deweloperskie i inne. Na przyk\u0142ad, qa i preproduction. W tamtym czasie mieli\u015bmy du\u017co serwer\u00f3w i oko\u0142o 60 us\u0142ug. Z tego powodu musieli\u015bmy utrzymywa\u0107 aktualn\u0105 wersj\u0119 <\/b>maszyny wirtualnej dla ka\u017cdej us\u0142ugi. Co wi\u0119cej, je\u015bli chcesz zaktualizowa\u0107 biblioteki lub zainstalowa\u0107 nowe zale\u017cno\u015bci, musisz to zrobi\u0107 we wszystkich \u015brodowiskach. R\u00f3wnie\u017c trzeba by\u0142o synchronizowa\u0107 czas, kiedy zamierzasz wdro\u017cy\u0107 now\u0105 wersj\u0119 swojej aplikacji, z czasem, kiedy devops wykona niezb\u0119dne konfiguracje \u015brodowiska. W takim przypadku \u0142atwo wpa\u015b\u0107 w sytuacj\u0119, w kt\u00f3rej \u015brodowisko r\u00f3\u017cni si\u0119 nieco w ka\u017cdym \u015brodowisku. Na przyk\u0142ad, w \u015brodowisku QA b\u0119d\u0105 inne wersje bibliotek, a w produkcji \u2014 inne, co doprowadzi do problem\u00f3w. <\/li>\n
    2. Trudno\u015bci w aktualizacji zale\u017cno\u015bci<\/b> twojej aplikacji. To nie zale\u017cy od Ciebie, ale od innego zespo\u0142u. A mianowicie, od zespo\u0142u devops, kt\u00f3ry utrzymuje serwery. Musisz postawi\u0107 przed nimi odpowiednie zadanie i poda\u0107 opis tego, co chcesz zrobi\u0107.<\/li>\n
    3. W tamtym czasie r\u00f3wnie\u017c chcieli\u015bmy podzieli\u0107 istniej\u0105ce du\u017ce monolity na osobne ma\u0142e serwisy, poniewa\u017c zdawali\u015bmy sobie spraw\u0119, \u017ce b\u0119dzie ich coraz wi\u0119cej. Na ten moment mieli\u015bmy ju\u017c ich ponad 100. By\u0142o konieczne tworzenie dla ka\u017cdego nowego serwisu oddzielnej nowej maszyny wirtualnej, kt\u00f3r\u0105 r\u00f3wnie\u017c trzeba by\u0142o obs\u0142ugiwa\u0107 i wdra\u017ca\u0107. Poza tym potrzebna by\u0142a nie jedna, a przynajmniej dwie maszyny. Do tego dochodzi jeszcze \u015brodowisko QA. To powoduje problemy i sprawia, \u017ce tworzenie i uruchamianie nowych system\u00f3w staje si\u0119 bardziej skomplikowane, kosztowne i czasoch\u0142onne.<\/b><\/li>\n<\/ol>\n

      \nDlatego podj\u0119li\u015bmy decyzj\u0119, \u017ce \u0142atwiej b\u0119dzie przej\u015b\u0107 z wdro\u017cenia zwyk\u0142ych maszyn wirtualnych na wdro\u017cenie naszych aplikacji w kontenerze docker. Przy obecno\u015bci dockera potrzebny jest system, kt\u00f3ry b\u0119dzie w stanie uruchomi\u0107 aplikacj\u0119 w klastrze, poniewa\u017c nie mo\u017cna po prostu tak podnie\u015b\u0107 kontenera. Zazwyczaj chce si\u0119 \u015bledzi\u0107, ile kontener\u00f3w jest uruchomionych, aby uruchamia\u0142y si\u0119 automatycznie. Z tego powodu musieli\u015bmy wybra\u0107 system zarz\u0105dzania. <\/p>\n

      D\u0142ugo zastanawiali\u015bmy si\u0119, kt\u00f3ry z nich m\u00f3g\u0142by by\u0107 odpowiedni. Chodzi o to, \u017ce w tamtym czasie nasza stos wdro\u017ceniowy na zwyk\u0142e serwery wirtualne by\u0142 nieco przestarza\u0142y, poniewa\u017c by\u0142y tam nie najnowsze wersje system\u00f3w operacyjnych. W pewnym momencie by\u0142 tam nawet FreeBSD, kt\u00f3rego nie by\u0142o \u0142atwo utrzyma\u0107. Zdawali\u015bmy sobie spraw\u0119, \u017ce musimy jak najszybciej migrowa\u0107 do dockera. Nasi devops przyjrzeli si\u0119 swojemu dotychczasowemu do\u015bwiadczeniu z r\u00f3\u017cnymi rozwi\u0105zaniami i wybrali system Nomad. <\/p>\n

      Przej\u015bcie na Nomad<\/h1>\n

      \nNomad to produkt firmy \"HashiCorp\". S\u0105 oni r\u00f3wnie\u017c znani z innych swoich rozwi\u0105za\u0144:<\/p>\n

      \"Wdra\u017canie
      \n
      \n\"Consul\"<\/b> \u2014 to narz\u0119dzie do odkrywania serwis\u00f3w.<\/p>\n

      \"Terraform\"<\/b> \u2014 to system do zarz\u0105dzania serwerami, kt\u00f3ry pozwala na ich konfiguracj\u0119 za pomoc\u0105 tzw. infrastructure-as-a-code.<\/p>\n

      \"Vagrant\"<\/b> pozwala na uruchamianie maszyn wirtualnych lokalnie lub w chmurze za pomoc\u0105 okre\u015blonych plik\u00f3w konfiguracyjnych. <\/p>\n

      Na ten moment Nomad wydawa\u0142 si\u0119 wystarczaj\u0105co prostym rozwi\u0105zaniem, na kt\u00f3re mo\u017cna szybko przej\u015b\u0107 bez zmiany ca\u0142ej infrastruktury. Co wi\u0119cej, jest do\u015b\u0107 \u0142atwy do opanowania. Dlatego w\u0142a\u015bnie jego wybrali\u015bmy jako system filtracji naszego kontenera. <\/p>\n

      Co jest potrzebne, aby w og\u00f3le wdro\u017cy\u0107 Tw\u00f3j system w Nomad? <\/p>\n

        \n
      1. Przede wszystkim potrzebny jest obraz docker<\/b> Twojej aplikacji. Nale\u017cy j\u0105 zebra\u0107 i umie\u015bci\u0107 w magazynie obraz\u00f3w docker. W naszym przypadku jest to artifactory \u2013 taki system, kt\u00f3ry pozwala na wgrywanie do niego r\u00f3\u017cnych artefakt\u00f3w r\u00f3\u017cnego typu. Potrafi przechowywa\u0107 archiwa, obrazy docker, pakiety composer PHP, pakiety NPM i tak dalej. <\/li>\n
      2. R\u00f3wnie\u017c potrzebny plik konfiguracyjny<\/b>, kt\u00f3ry powie Nomadowi, co, gdzie i w jakiej ilo\u015bci chcesz wdro\u017cy\u0107. <\/li>\n<\/ol>\n

        \nKiedy m\u00f3wimy o Nomadzie, u\u017cywa on j\u0119zyka HCL jako formatu pliku informacyjnego, co rozszyfrowuje si\u0119 jako HashiCorp Configuration Language<\/i>. To jest nadzbi\u00f3r j\u0119zyka Yaml, kt\u00f3ry pozwala na opisanie twojej us\u0142ugi w terminach Nomada. <\/p>\n

        \"Wdra\u017canie
        \n
        \nPozwala on okre\u015bli\u0107, ile kontener\u00f3w chcesz wdro\u017cy\u0107, przekaza\u0107 im r\u00f3\u017cne parametry podczas wdro\u017cenia. W ten spos\u00f3b podajesz ten plik Nomadowi, a on uruchamia kontenery w produkcji zgodnie z jego zawarto\u015bci\u0105. <\/p>\n

        W naszym przypadku zrozumieli\u015bmy, \u017ce pisanie absolutnie identycznych plik\u00f3w HCL dla ka\u017cdej us\u0142ugi nie b\u0119dzie zbyt wygodne, poniewa\u017c us\u0142ug jest wiele i czasami chcemy je zaktualizowa\u0107. Bywa, \u017ce jedna us\u0142uga jest wdro\u017cona w wielu egzemplarzach. Na przyk\u0142ad jeden z system\u00f3w, kt\u00f3ry mamy w produkcji, ma ponad 100 instancji w produkcji. Uruchamiane s\u0105 z tych samych obraz\u00f3w, ale r\u00f3\u017cni\u0105 si\u0119 ustawieniami konfiguracyjnymi i plikami konfiguracyjnymi. <\/p>\n

        Dlatego postanowili\u015bmy, \u017ce wygodniej b\u0119dzie przechowywa\u0107 wszystkie nasze pliki konfiguracyjne do wdro\u017cenia w jednym wsp\u00f3lnym repozytorium. W ten spos\u00f3b staj\u0105 si\u0119 one przegl\u0105dane: \u0142atwo je utrzyma\u0107 i mo\u017cna zobaczy\u0107, jakie systemy mamy. W razie potrzeby r\u00f3wnie\u017c \u0142atwo co\u015b zaktualizowa\u0107 lub zmieni\u0107. Dodanie nowego systemu r\u00f3wnie\u017c nie sprawi problemu \u2013 wystarczy po prostu stworzy\u0107 plik konfiguracyjny w nowym katalogu. Wewn\u0105trz znajduj\u0105 si\u0119 pliki: service.hcl, kt\u00f3ry zawiera opis naszej us\u0142ugi, oraz kilka plik\u00f3w env, kt\u00f3re pozwalaj\u0105 skonfigurowa\u0107 t\u0119 us\u0142ug\u0119, b\u0119d\u0105c wdro\u017con\u0105 w produkcji. <\/p>\n

        \"Wdra\u017canie
        \n
        \nJednak niekt\u00f3re nasze systemy s\u0105 wdro\u017cone w produkcji nie w jednym egzemplarzu, a w kilku naraz. Dlatego postanowili\u015bmy, \u017ce wygodniej b\u0119dzie przechowywa\u0107 ich nie w czystej postaci, lecz w formie z szablonami. Jako j\u0119zyk szablon\u00f3w wybrali\u015bmy jinja 2<\/i>. W takim formacie przechowujemy zar\u00f3wno konfiguracje samej us\u0142ugi, jak i pliki env, kt\u00f3re s\u0105 dla niej potrzebne. <\/p>\n

        Ponadto umie\u015bcili\u015bmy w repozytorium wsp\u00f3lny skrypt wdro\u017ceniowy dla wszystkich projekt\u00f3w, kt\u00f3ry pozwala uruchomi\u0107 i wdro\u017cy\u0107 us\u0142ug\u0119 na produkcji, w odpowiednim \u015brodowisku i w odpowiednim celu. W przypadku, gdy przekszta\u0142cili\u015bmy nasz\u0105 konfiguracj\u0119 HCL w szablon, ten plik HCL, kt\u00f3ry wcze\u015bniej by\u0142 zwyk\u0142\u0105 konfiguracj\u0105 Nomad, w tym przypadku wygl\u0105da troch\u0119 inaczej.<\/p>\n

        \"Wdra\u017canie
        \n
        \nTo znaczy, \u017ce zast\u0105pili\u015bmy niekt\u00f3re zmienne miejsca konfiguracji wstawieniami zmiennych, kt\u00f3re pochodz\u0105 z plik\u00f3w env lub innych \u017ar\u00f3de\u0142. Opr\u00f3cz tego uzyskali\u015bmy mo\u017cliwo\u015b\u0107 dynamicznego generowania plik\u00f3w HCL, co oznacza, \u017ce mo\u017cemy stosowa\u0107 nie tylko zwyk\u0142e wstawienia zmiennych. Poniewa\u017c jinja obs\u0142uguje p\u0119tle i warunki, mo\u017cna r\u00f3wnie\u017c tworzy\u0107 pliki konfiguracyjne, kt\u00f3re zmieniaj\u0105 si\u0119 w zale\u017cno\u015bci od tego, gdzie dok\u0142adnie wdra\u017casz swoje aplikacje. <\/p>\n

        Na przyk\u0142ad chcesz wdro\u017cy\u0107 swoj\u0105 us\u0142ug\u0119 w \u015brodowisku przedprodukcyjnym i produkcyjnym. Za\u0142\u00f3\u017cmy, \u017ce w \u015brodowisku przedprodukcyjnym nie chcesz uruchamia\u0107 skrypt\u00f3w cron, a po prostu chcesz zobaczy\u0107 us\u0142ug\u0119 na osobnej domenie, aby upewni\u0107 si\u0119, \u017ce dzia\u0142a. Dla ka\u017cdego, kto wdra\u017ca us\u0142ug\u0119, proces wygl\u0105da bardzo prosto i przejrzy\u015bcie. Wystarczy wykona\u0107 plik deploy.sh, wskaza\u0107, kt\u00f3r\u0105 us\u0142ug\u0119 chcesz wdro\u017cy\u0107 i w jakim celu. Na przyk\u0142ad, chcesz wdro\u017cy\u0107 jaki\u015b system w Rosji, Bia\u0142orusi lub Kazachstanie. Wystarczy po prostu zmieni\u0107 jeden z parametr\u00f3w, a odpowiedni plik konfiguracyjny zostanie wygenerowany. <\/p>\n

        Gdy us\u0142uga Nomad zostanie wdro\u017cona w klastrze, wygl\u0105da to nast\u0119puj\u0105co.<\/p>\n

        \"Wdra\u017canie
        \n
        \nNa pocz\u0105tek potrzebujesz zunifikowanego balansu na zewn\u0105trz, kt\u00f3ry przyjmuje ca\u0142y ruch u\u017cytkownik\u00f3w. B\u0119dzie wsp\u00f3\u0142pracowa\u0142 z Consul i dowie si\u0119 od niego, gdzie, na kt\u00f3rej nodzie, pod jakim adresem IP<\/a> znajduje si\u0119 konkretna us\u0142uga, kt\u00f3ra odpowiada odpowiedniemu nazwie domeny. Us\u0142ugi w Consul pojawiaj\u0105 si\u0119 z samego Nomad. Poniewa\u017c s\u0105 to produkty tej samej firmy, s\u0105 dobrze ze sob\u0105 powi\u0105zane. Mo\u017cna powiedzie\u0107, \u017ce Nomad z pude\u0142ka potrafi rejestrowa\u0107 wszystkie uruchamiane w nim us\u0142ugi wewn\u0105trz Consul. <\/p>\n

        Po tym, jak zewn\u0119trzny load balancer dowie si\u0119, do kt\u00f3rego serwisu nale\u017cy wys\u0142a\u0107 ruch, przekierowuje go do odpowiedniego kontenera lub do kilku kontener\u00f3w, kt\u00f3re odpowiadaj\u0105 twojej aplikacji. Oczywi\u015bcie nale\u017cy r\u00f3wnie\u017c pomy\u015ble\u0107 o bezpiecze\u0144stwie. Nawet mimo \u017ce wszystkie serwisy dzia\u0142aj\u0105 na tych samych maszynach wirtualnych w kontenerach, zazwyczaj wymaga to zakazu swobodnego dost\u0119pu z jakiego\u015b serwisu do innego. Osi\u0105gali\u015bmy to poprzez segmentacj\u0119. Ka\u017cdy serwis dzia\u0142a\u0142 w swojej w\u0142asnej sieci wirtualnej, w kt\u00f3rej ustalono zasady routingu i zasady zezwalania\/zakazu dost\u0119pu do innych system\u00f3w i serwis\u00f3w. Mog\u0142y one znajdowa\u0107 si\u0119 zar\u00f3wno wewn\u0105trz tego klastra, jak i na zewn\u0105trz. Na przyk\u0142ad, je\u015bli chcesz zabroni\u0107 serwisowi \u0142\u0105czenia si\u0119 z okre\u015blon\u0105 baz\u0105 danych, mo\u017cna to zrobi\u0107 poprzez segmentacj\u0119 na poziomie sieci. Oznacza to, \u017ce nie mo\u017cesz przypadkowo po\u0142\u0105czy\u0107 si\u0119 z baz\u0105 danych produkcyjn\u0105 z \u015brodowiska testowego.<\/p>\n

        Ile nas kosztowa\u0142 proces przej\u015bcia pod wzgl\u0119dem zasob\u00f3w ludzkich? <\/p>\n

        Przej\u015bcie ca\u0142ej firmy na Nomad zaj\u0119\u0142o oko\u0142o 5-6 miesi\u0119cy. Przechodzili\u015bmy serwis po serwisie, ale w do\u015b\u0107 szybkim tempie. Ka\u017cdy zesp\u00f3\u0142 musia\u0142 stworzy\u0107 w\u0142asne kontenery dla swoich serwis\u00f3w. <\/p>\n

        Mamy przyj\u0119te podej\u015bcie, \u017ce ka\u017cdy zesp\u00f3\u0142 odpowiada samodzielnie za obrazy docker swoich system\u00f3w. DevOps zapewniaj\u0105 wsp\u00f3ln\u0105 infrastruktur\u0119 niezb\u0119dn\u0105 do wdro\u017ce\u0144, czyli wsparcie samego klastra, wsparcie systemu CI i tak dalej. W tym czasie ponad 60 system\u00f3w przesz\u0142o na Nomad, co zaowocowa\u0142o oko\u0142o 2000 kontener\u00f3w. <\/p>\n

        DevOps odpowiadaj\u0105 za og\u00f3ln\u0105 infrastruktur\u0119 wszystkiego, co zwi\u0105zane z wdro\u017ceniem i serwerami. Natomiast ka\u017cdy zesp\u00f3\u0142 deweloperski odpowiada za implementacj\u0119 kontener\u00f3w dla swojego konkretnego systemu, poniewa\u017c to w\u0142a\u015bnie zesp\u00f3\u0142 wie, co tak naprawd\u0119 potrzebuje w danym kontenerze.<\/p>\n

        Powody rezygnacji z Nomad<\/h1>\n

        \nJakie korzy\u015bci uzyskali\u015bmy, przechodz\u0105c na wdro\u017cenie z pomoc\u0105 Nomad i Dockera?<\/p>\n

          \n
        1. My zapewnili\u015bmy r\u00f3wne warunki<\/b> dla wszystkich \u015brodowisk. W \u015brodowisku deweloperskim, QA, prerelease i produkcyjnym u\u017cywane s\u0105 te same obrazy kontener\u00f3w, z tymi samymi zale\u017cno\u015bciami. Z tego powodu praktycznie nie ma szans, \u017ce na produkcj\u0119 trafi co\u015b, czego wcze\u015bniej nie przetestowano lokalnie lub w \u015brodowisku testowym. <\/li>\n
        2. Zauwa\u017cyli\u015bmy r\u00f3wnie\u017c, \u017ce wystarczy \u0142atwo doda\u0107 now\u0105 us\u0142ug\u0119<\/b>. Jakiekolwiek nowe systemy z perspektywy wdro\u017cenia uruchamia si\u0119 bardzo prosto. Wystarczy przej\u015b\u0107 do repozytorium, w kt\u00f3rym przechowywane s\u0105 konfiguracje, doda\u0107 tam kolejn\u0105 konfiguracj\u0119 dla swojego systemu, a wszystko jest gotowe. Mo\u017cesz wdro\u017cy\u0107 sw\u00f3j system na produkcj\u0119 bez dodatkowego wysi\u0142ku ze strony DevOps. <\/li>\n
        3. Wszystkie pliki konfiguracyjne<\/b> w jednym og\u00f3lnym repozytorium okaza\u0142y si\u0119 przegl\u0105dane<\/b>. W momencie, gdy wdra\u017cali\u015bmy nasze systemy przy pomocy serwer\u00f3w wirtualnych<\/a>, u\u017cywali\u015bmy Ansible, w kt\u00f3rym konfiguracje znajdowa\u0142y si\u0119 w jednym i tym samym repozytorium. Jednak dla wi\u0119kszo\u015bci programist\u00f3w praca z tym by\u0142a nieco trudniejsza. Tutaj obj\u0119to\u015b\u0107 konfiguracji i kodu, kt\u00f3ry musisz doda\u0107, aby wdro\u017cy\u0107 us\u0142ug\u0119, sta\u0142a si\u0119 znacznie mniejsza. Dodatkowo, dla DevOps bardzo \u0142atwo jest to poprawi\u0107 lub zmieni\u0107. W przypadku przej\u015b\u0107, na przyk\u0142ad na nowej wersji Nomad, mog\u0105 oni zaktualizowa\u0107 masowo wszystkie pliki operacyjne znajduj\u0105ce si\u0119 w tym samym miejscu.<\/li>\n<\/ol>\n

          \nAle napotkali\u015bmy r\u00f3wnie\u017c kilka wad: <\/p>\n

          Okaza\u0142o si\u0119, \u017ce nie uda\u0142o nam si\u0119 osi\u0105gn\u0105\u0107 bezszwowo\u015bci wdro\u017ce\u0144 <\/b>w przypadku Nomad. Podczas wdra\u017cania kontener\u00f3w z r\u00f3\u017cnych warunk\u00f3w mo\u017ce si\u0119 zdarzy\u0107, \u017ce zostanie uruchomiony, a Nomad traktuje go jako gotowy do przyj\u0119cia ruchu kontener. To zdarza\u0142o si\u0119 jeszcze przed tym, jak aplikacja w \u015brodku mia\u0142a czas, aby si\u0119 uruchomi\u0107. Z tego powodu system przez kr\u00f3tki czas zaczyna\u0142 zwraca\u0107 b\u0142\u0119dy 500, poniewa\u017c ruch zaczyna\u0142 trafia\u0107 do kontenera, kt\u00f3ry jeszcze nie by\u0142 gotowy do jego przyj\u0119cia. <\/p>\n

          Napotkali\u015bmy na kilka b\u0142\u0119d\u00f3w<\/b>. Najistotniejszy b\u0142\u0105d polega na tym, \u017ce Nomad nie radzi sobie dobrze z du\u017cym klastrem, je\u015bli masz wiele system\u00f3w i kontener\u00f3w. Kiedy chcesz wy\u0142\u0105czy\u0107 jeden z serwer\u00f3w, kt\u00f3ry jest cz\u0119\u015bci\u0105 klastra Nomad, istnieje do\u015b\u0107 du\u017ca szansa, \u017ce klaster nie b\u0119dzie si\u0119 czu\u0142 dobrze i rozpadnie si\u0119 na kawa\u0142ki. Cz\u0119\u015b\u0107 kontener\u00f3w mo\u017ce na przyk\u0142ad upa\u015b\u0107 i nie wsta\u0107 \u2014 to p\u00f3\u017aniej kosztuje ci\u0119 bardzo drogo, je\u015bli wszystkie twoje systemy produkcyjne znajduj\u0105 si\u0119 w klastrze zarz\u0105dzanym przez Nomad. <\/p>\n

          Dlatego postanowili\u015bmy zastanowi\u0107 si\u0119, w jakim kierunku dalej i\u015b\u0107. W tamtym momencie znacznie lepiej zacz\u0119li\u015bmy rozumie\u0107, co chcemy osi\u0105gn\u0105\u0107. A mianowicie: chcemy niezawodno\u015bci, troch\u0119 wi\u0119cej funkcji ni\u017c daje Nomad oraz bardziej dojrza\u0142ego, stabilniejszego systemu. <\/p>\n

          W tym kontek\u015bcie nasz wyb\u00f3r pad\u0142 na Kubernetes jako na najpopularniejsz\u0105 platform\u0119 do uruchamiania klastr\u00f3w. Szczeg\u00f3lnie bior\u0105c pod uwag\u0119, \u017ce rozmiar i liczba naszych kontener\u00f3w by\u0142y do\u015b\u0107 du\u017ce. Do takich cel\u00f3w Kubernetes wydawa\u0142 si\u0119 najbardziej odpowiednim systemem z tych, kt\u00f3re mogli\u015bmy rozwa\u017cy\u0107. <\/p>\n

          Przej\u015bcie na Kubernetes<\/h1>\n

          \nTroch\u0119 opowiem o tym, jakie s\u0105 podstawowe poj\u0119cia Kubernetes i czym r\u00f3\u017cni\u0105 si\u0119 one od Nomad. <\/p>\n

          \"Wdra\u017canie
          \n
          \nPrzede wszystkim najwa\u017cniejszym poj\u0119ciem w Kubernetes jest poj\u0119cie pod. Pod<\/b> \u2014 to grupa jednego lub kilku kontener\u00f3w, kt\u00f3re zawsze uruchamiane s\u0105 razem. Dzia\u0142aj\u0105 one jakby zawsze by\u0142y \u015bci\u015ble na jednej maszynie wirtualnej. S\u0105 dla siebie dost\u0119pne pod adresem IP 127.0.0.1 na r\u00f3\u017cnych portach. <\/p>\n

          Za\u0142\u00f3\u017cmy, \u017ce masz aplikacj\u0119 PHP, kt\u00f3ra sk\u0142ada si\u0119 z nginx i php-fpm \u2013 klasyczny schemat. Prawdopodobnie chcesz, aby kontenery nginx i php-fpm zawsze by\u0142y razem. Kubernetes pozwala na to, opisuj\u0105c je jako jeden wsp\u00f3lny pod. Dok\u0142adnie tego nie mogli\u015bmy osi\u0105gn\u0105\u0107 przy u\u017cyciu Nomad.<\/p>\n

          Drugim poj\u0119ciem jest deployment<\/b>. Chodzi o to, \u017ce pod sam w sobie to rzecz efemeryczna, uruchamia si\u0119 i znika. Chcesz najpierw usun\u0105\u0107 wszystkie swoje wcze\u015bniejsze kontenery, a potem uruchomi\u0107 od razu nowe wersje, czy wolisz wprowadza\u0107 je stopniowo \u2014 to w\u0142a\u015bnie za ten proces odpowiada poj\u0119cie deployment. Opisuje to, jak wdra\u017casz swoje pod'y, w jakiej liczbie i jak je aktualizowa\u0107. <\/p>\n

          Trzecim poj\u0119ciem jest service<\/b>. Tw\u00f3j service to w zasadzie tw\u00f3j system, kt\u00f3ry przyjmuje pewien ruch, a nast\u0119pnie kieruje go do jednego lub kilku pod\u00f3w odpowiadaj\u0105cych twojemu serwisowi. Innymi s\u0142owy, umo\u017cliwia to przekazywanie ca\u0142ego przychodz\u0105cego ruchu do takiego serwisu o takim nazwie na konkretne te pody. Przy tym zapewnia ci balansowanie ruchu. Mo\u017cesz uruchomi\u0107 dwa pody twojej aplikacji, a ca\u0142y przychodz\u0105cy ruch b\u0119dzie r\u00f3wnomiernie rozdzielany pomi\u0119dzy odpowiednie pody zwi\u0105zane z tym serwisem.<\/p>\n

          Czwarta podstawowa koncepcja \u2014 Ingress<\/b>. To serwis uruchamiany w klastrze Kubernetes. Dzia\u0142a jako zewn\u0119trzny balancer obci\u0105\u017cenia, kt\u00f3ry przyjmuje wszystkie zapytania. Dzi\u0119ki API Kubernetes Ingress mo\u017ce okre\u015bli\u0107, dok\u0105d nale\u017cy wys\u0142a\u0107 te zapytania. Co wa\u017cne, robi to w bardzo elastyczny spos\u00f3b. Mo\u017cesz powiedzie\u0107, \u017ce wszystkie zapytania na ten host i dany URL wysy\u0142amy do tego serwisu. Natomiast te zapytania, kt\u00f3re przychodz\u0105 do tego hosta na inny URL, wysy\u0142amy do innego serwisu. <\/p>\n

          Najlepsze dla dewelopera aplikacji to to, \u017ce mo\u017cesz tym wszystkim zarz\u0105dza\u0107 samodzielnie. Ustalaj\u0105c konfiguracj\u0119 Ingress, mo\u017cesz kierowa\u0107 ca\u0142y ruch przychodz\u0105cy na okre\u015blone API do oddzielnych kontener\u00f3w, zapisanych na przyk\u0142ad w Go. A ten ruch przychodz\u0105cy na ten sam domen, ale na inny URL, przesy\u0142asz do kontener\u00f3w napisanych w PHP, gdzie jest du\u017co logiki, ale nie s\u0105 one bardzo szybkie.<\/p>\n

          Por\u00f3wnuj\u0105c wszystkie te poj\u0119cia z Nomad, mo\u017cna powiedzie\u0107, \u017ce pierwsze trzy pojmowania to w sumie Service. A ostatnia koncepcja w Nomadzie nie istnieje. Wykorzystali\u015bmy zewn\u0119trzny balancer: mo\u017ce to by\u0107 haproxy, nginx, nginx+ i tak dalej. W przypadku Kubernetesa nie musisz wprowadza\u0107 tej dodatkowej koncepcji osobno. Jednak, patrz\u0105c na Ingress w \u015brodku, to jest albo nginx, albo haproxy, albo traefik, ale wbudowany w Kubernetes. <\/p>\n

          Wszystkie opisane przeze mnie poj\u0119cia to w zasadzie zasoby, kt\u00f3re istniej\u0105 w klastrze Kubernetes. Do ich opisu w kubie u\u017cywany jest format yaml, bardziej czytelny i znajomy ni\u017c pliki HCL w przypadku Nomada. Strukturalnie opisuj\u0105 one dla przyk\u0142adu pod to samo. M\u00f3wi\u0105 \u2014 chc\u0119 wdro\u017cy\u0107 takie cuda w tamto miejsce, z takimi obrazkami, w takiej liczbie. <\/p>\n

          \"Wdra\u017canie
          \n
          \nPonadto zrozumieli\u015bmy, \u017ce nie chcemy r\u0119cznie tworzy\u0107 ka\u017cdego pojedynczego zasobu: wdro\u017cenia, us\u0142ug, Ingress i innych. Zamiast tego chcieli\u015bmy w trakcie wdro\u017cenia opisa\u0107 ka\u017cdy nasz system w terminach Kubernetes, aby nie musie\u0107 r\u0119cznie odtworzy\u0107 w odpowiedniej kolejno\u015bci wszystkich niezb\u0119dnych zale\u017cno\u015bci zasob\u00f3w. Jako system, kt\u00f3ry pozwoli\u0142 nam to zrobi\u0107, wybrano Helm. <\/p>\n

          Podstawowe poj\u0119cia w Helm<\/h1>\n

          \nHelm to mened\u017cer pakiet\u00f3w<\/b> dla Kubernetes. Jest bardzo podobny do tego, jak dzia\u0142aj\u0105 mened\u017cery pakiet\u00f3w w j\u0119zykach programowania. Pozwala on na przechowywanie us\u0142ugi, sk\u0142adaj\u0105cej si\u0119 na przyk\u0142ad z wdro\u017cenia nginx, wdro\u017cenia php-fpm, konfiguracji dla Ingress, configmaps (to jest byt, kt\u00f3ry pozwala na okre\u015blenie env i innych parametr\u00f3w dla twojego systemu) w postaci tzw. chart\u00f3w. Przy tym Helm dzia\u0142a na Kubernetes<\/b>. To znaczy, \u017ce nie jest to jaki\u015b system stoj\u0105cy z boku, a po prostu jeszcze jedna us\u0142uga uruchamiana wewn\u0105trz klastra. Interakcj\u0119 z nim odbywasz przez jego API za pomoc\u0105 polecenia w konsoli. Jego wygoda i zaleta polega na tym, \u017ce nawet je\u015bli Helm przestanie dzia\u0142a\u0107 lub usuniesz go z klastra, twoje us\u0142ugi nie znikn\u0105, poniewa\u017c Helm s\u0142u\u017cy zasadniczo tylko do uruchamiania systemu. Za sprawno\u015b\u0107 i stan us\u0142ug dalej odpowiada sam Kubernetes. <\/p>\n

          Zrozumieli\u015bmy r\u00f3wnie\u017c, \u017ce szablonowanie<\/b>, kt\u00f3re wcze\u015bniej musieli\u015bmy robi\u0107 samodzielnie poprzez wdro\u017cenie jinja w nasze konfiguracje, jest jedn\u0105 z podstawowych mo\u017cliwo\u015bci Helma. Wszystkie konfiguracje, kt\u00f3re tworzysz dla swoich system\u00f3w, s\u0105 przechowywane w Helmie w postaci szablon\u00f3w, kt\u00f3re s\u0105 troch\u0119 podobne do jinja, ale w rzeczywisto\u015bci korzystaj\u0105 z szablonowania j\u0119zyka Go, w kt\u00f3rym napisano Helma, tak samo jak Kubernetes. <\/p>\n

          Helm dodaje nam jeszcze kilka dodatkowych poj\u0119\u0107. <\/p>\n

          Chart<\/b> to opis twojej us\u0142ugi. W innych mened\u017cerach pakiet\u00f3w nazwano by to pakietem, bundlem lub czym\u015b podobnym. Tutaj nazywa si\u0119 to chart. <\/p>\n

          Values <\/b>to zmienne, kt\u00f3re chcesz u\u017cy\u0107 do tworzenia swoich konfiguracji z szablon\u00f3w. <\/p>\n

          Release<\/b>Za ka\u017cdym razem serwis, kt\u00f3ry jest wdra\u017cany za pomoc\u0105 helm, otrzymuje inkrementaln\u0105 wersj\u0119 wydania. Helm zapami\u0119tuje, jaka by\u0142a konfiguracja serwisu przy poprzednim, przedpoprzednim wydaniu i tak dalej. Dlatego, je\u015bli trzeba si\u0119 cofn\u0105\u0107, wystarczy wykona\u0107 polecenie helm callback, wskazuj\u0105c mu poprzedni\u0105 wersj\u0119 wydania. Nawet je\u015bli w momencie cofania odpowiednia konfiguracja w Twoim repozytorium nie b\u0119dzie dost\u0119pna, helm wci\u0105\u017c pami\u0119ta, jak ona wygl\u0105da\u0142a, i przywr\u00f3ci Tw\u00f3j system do stanu, w jakim by\u0142 przy poprzednim wydaniu. <\/p>\n

          W przypadku, gdy u\u017cywamy helma, zwyk\u0142e konfiguracje dla Kubernetes r\u00f3wnie\u017c przekszta\u0142caj\u0105 si\u0119 w szablony, w kt\u00f3rych mo\u017cna u\u017cywa\u0107 zmiennych, funkcji, stosowa\u0107 operatory warunkowe. W ten spos\u00f3b mo\u017cesz tworzy\u0107 konfiguracj\u0119 swojego serwisu w zale\u017cno\u015bci od \u015brodowiska.<\/p>\n

          \"Wdra\u017canie
          \n
          \nW praktyce zdecydowali\u015bmy si\u0119 post\u0105pi\u0107 nieco inaczej ni\u017c w przypadku Nomad. Je\u015bli w Nomad w jednym repozytorium przechowywane by\u0142y zar\u00f3wno konfiguracje do wdro\u017cenia, jak i zmienne n, kt\u00f3re s\u0105 potrzebne do wdro\u017cenia naszego serwisu, to tutaj zdecydowali\u015bmy si\u0119 je podzieli\u0107 na dwa osobne repozytoria. W repozytorium \"deploy\" przechowywane s\u0105 tylko zmienne n potrzebne do wdro\u017cenia, a w repozytorium \"helm\" znajduj\u0105 si\u0119 konfiguracje lub wykresy.<\/p>\n

          \"Wdra\u017canie
          \n
          \nCo nam to da\u0142o? <\/p>\n

          Mimo \u017ce w samych plikach konfiguracyjnych nie przechowujemy \u017cadnych naprawd\u0119 wra\u017cliwych danych, na przyk\u0142ad hase\u0142 do baz danych. S\u0105 one przechowywane jako sekrety w Kubernetes, jednak wci\u0105\u017c istniej\u0105 tam oddzielne rzeczy, do kt\u00f3rych nie chcemy dawa\u0107 dost\u0119pu wszystkim. Dlatego dost\u0119p do repozytorium \"deploy\" jest bardziej ograniczony, a repozytorium \"helm\" zawiera tylko opis serwisu. Z tego powodu mo\u017cna tam bezpiecznie da\u0107 dost\u0119p szerszemu gronu os\u00f3b. <\/p>\n

          Poniewa\u017c mamy nie tylko produkcj\u0119, ale i inne \u015brodowiska, dzi\u0119ki takiemu podzia\u0142owi mo\u017cemy ponownie wykorzysta\u0107 nasze wykresy helm, aby wdra\u017ca\u0107 serwisy nie tylko w produkcji, ale tak\u017ce na przyk\u0142ad w \u015brodowisku QA. Nawet do tego, aby uruchamia\u0107 je lokalnie, u\u017cywaj\u0105c Minikube<\/i> \u2014 to taka rzecz do lokalnego uruchamiania Kubernetes. <\/p>\n

          Wewn\u0105trz ka\u017cdego repozytorium pozostawili\u015bmy podzia\u0142 na oddzielne katalogi dla ka\u017cdego serwisu. To znaczy, \u017ce w ka\u017cdym katalogu znajduj\u0105 si\u0119 szablony zwi\u0105zane z odpowiednim wykresem i opisuj\u0105ce zasoby, kt\u00f3re nale\u017cy wdro\u017cy\u0107, aby uruchomi\u0107 nasz system. W repozytorium \u201edeploy\u201d pozostawili\u015bmy tylko zmienne \u015brodowiskowe. W tym przypadku nie zdecydowali\u015bmy si\u0119 na u\u017cycie szablonizacji za pomoc\u0105 jinja, poniewa\u017c helm sam oferuje szablonizacj\u0119 z pude\u0142ka \u2013 to jedna z jego podstawowych funkcji. <\/p>\n

          Zostawili\u015bmy skrypt do wdro\u017cenia \u2013 deploy.sh, kt\u00f3ry upraszcza i standaryzuje uruchamianie wdro\u017cenia za pomoc\u0105 helma. Tak wi\u0119c dla ka\u017cdego, kto chce wdro\u017cy\u0107, interfejs wdro\u017cenia wygl\u0105da dok\u0142adnie tak samo, jak w przypadku wdro\u017cenia przez Nomad. Taki sam deploy.sh, nazwa Twojego serwisu i miejsce, w kt\u00f3re chcesz go wdro\u017cy\u0107. To prowadzi do uruchomienia helma, kt\u00f3ry z kolei zbiera konfiguracje z szablon\u00f3w, podstawia w nich niezb\u0119dne pliki values, a nast\u0119pnie wdra\u017ca je, wysy\u0142aj\u0105c do Kubernetes. <\/p>\n

          Wnioski<\/h1>\n

          \nSerwis Kubernetes wydaje si\u0119 bardziej skomplikowany ni\u017c Nomad. <\/p>\n

          \"Wdra\u017canie
          \n
          \nTutaj wychodz\u0105cy ruch trafia do Ingress. To w\u0142a\u015bnie frontowy kontroler, kt\u00f3ry przyjmuje wszystkie \u017c\u0105dania i nast\u0119pnie kieruje je do odpowiednich serwis\u00f3w zgodnych z danymi \u017c\u0105dania. Okre\u015bla je na podstawie konfiguracji, kt\u00f3re stanowi\u0105 cz\u0119\u015b\u0107 opisu Twojej aplikacji w helmie i kt\u00f3re programi\u015bci okre\u015blaj\u0105 sami. Serwis wysy\u0142a \u017c\u0105dania do swoich pod\u00f3w, czyli konkretnych kontener\u00f3w, r\u00f3wnowa\u017c\u0105c przychodz\u0105cy ruch mi\u0119dzy wszystkimi kontenerami, kt\u00f3re odnosz\u0105 si\u0119 do danego serwisu. No i oczywi\u015bcie nie mo\u017cna zapomina\u0107 o tym, \u017ce w zakresie bezpiecze\u0144stwa na poziomie sieci, nie powinni\u015bmy nigdzie ucieka\u0107. Dlatego w klastrze Kubernetes dzia\u0142a segmentacja, kt\u00f3ra opiera si\u0119 na tagowaniu. Wszystkie serwisy maj\u0105 okre\u015blone tagi, do kt\u00f3rych s\u0105 przypisane prawa dost\u0119pu serwis\u00f3w do r\u00f3\u017cnych zewn\u0119trznych\/wewn\u0119trznych zasob\u00f3w w lub poza klastrem. <\/p>\n

          Przechodz\u0105c do Kubernetes, zauwa\u017cyli\u015bmy, \u017ce ma on wszystkie mo\u017cliwo\u015bci, kt\u00f3re oferowa\u0142 wcze\u015bniej u\u017cywany przez nas Nomad, a tak\u017ce wiele nowych funkcji. Mo\u017cna go rozszerza\u0107 za pomoc\u0105 wtyczek, a w\u0142a\u015bciwie przez w\u0142asne typy zasob\u00f3w. Oznacza to, \u017ce masz mo\u017cliwo\u015b\u0107 nie tylko korzysta\u0107 z tego, co jest dost\u0119pne w Kubernetes od r\u0119ki, ale tak\u017ce stworzy\u0107 w\u0142asny zas\u00f3b i us\u0142ug\u0119, kt\u00f3ra b\u0119dzie odczytywa\u0107 tw\u00f3j zas\u00f3b. To daje dodatkowe mo\u017cliwo\u015bci rozszerzenia twojego systemu bez konieczno\u015bci reinstalacji Kubernetes i bez potrzeby jakichkolwiek zmian. <\/p>\n

          Przyk\u0142adem takiego u\u017cycia jest Prometheus, kt\u00f3ry jest uruchamiany w naszym klastrze Kubernetes. Aby m\u00f3g\u0142 zacz\u0105\u0107 zbiera\u0107 metryki z danego serwisu, musimy doda\u0107 do opisu serwisu dodatkowy typ zasobu, tak zwany monitor serwisowy. Prometheus, dzi\u0119ki temu, \u017ce umie odczytywa\u0107 w\u0142asne typy zasob\u00f3w, automatycznie zaczyna zbiera\u0107 metryki z nowego systemu. To jest bardzo wygodne. <\/p>\n

          Pierwszy deploy, kt\u00f3ry przeprowadzili\u015bmy w Kubernetes, mia\u0142 miejsce w marcu 2018 roku. Od tego czasu nigdy nie mieli\u015bmy z nim \u017cadnych problem\u00f3w. Dzia\u0142a stosunkowo stabilnie, bez powa\u017cnych b\u0142\u0119d\u00f3w. Ponadto, mo\u017cemy go dalej rozwija\u0107. Na dzie\u0144 dzisiejszy wystarczaj\u0105 nam mo\u017cliwo\u015bci, kt\u00f3re oferuje, a tempo rozwoju Kubernetes bardzo nam si\u0119 podoba. Obecnie w Kubernetes znajduje si\u0119 ponad 3000 kontener\u00f3w. Klaster zajmuje kilka Node. Jest przy tym zarz\u0105dzany, stabilny i bardzo kontrolowany.
          \n
          \u0179r\u00f3d\u0142o:           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\udd47Wdra\u017canie aplikacji w VM, Nomad i Kubernetes | ProHoster","description":"Cze\u015b\u0107 wszystkim! Mam na imi\u0119 Pawe\u0142 Agalec. Pracuj\u0119 jako lider zespo\u0142u w grupie, kt\u00f3ra opracowuje system dostaw Lamoda.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}