{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes w produkcji: Wdra\u017canie Blue\/Green, automatyczne skalowanie i automatyzacja wdro\u017ce\u0144. Cz\u0119\u015b\u0107 2.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes to doskona\u0142e narz\u0119dzie do uruchamiania kontener\u00f3w Docker w zgrupowanym \u015brodowisku produkcyjnym. Istniej\u0105 jednak zadania, kt\u00f3re Kubernetes nie jest w stanie rozwi\u0105za\u0107. Przy cz\u0119stym wdra\u017caniu w \u015brodowisku produkcyjnym potrzebujemy w pe\u0142ni zautomatyzowanego wdro\u017cenia Blue\/Green, aby unikn\u0105\u0107 przestoj\u00f3w w tym procesie, kt\u00f3ry r\u00f3wnie\u017c wymaga obs\u0142ugi zewn\u0119trznych \u017c\u0105da\u0144 HTTP i realizacji eksportu SSL. Wymaga to integracji z takim serwerem r\u00f3wnowa\u017c\u0105cym, jak ha-proxy. Kolejnym zadaniem jest p\u00f3\u0142automatyczne skalowanie samego klastra Kubernetes w chmurze, na przyk\u0142ad cz\u0119\u015bciowe zmniejszanie skali klastra w nocy.<\/p>\n

Cho\u0107 Kubernetes nie ma tych funkcji \"prosto z pude\u0142ka\", oferuje API, z kt\u00f3rego mo\u017cna skorzysta\u0107, aby rozwi\u0105za\u0107 podobne problemy. Narz\u0119dzia do automatyzowanego wdro\u017cenia Blue\/Green i skalowania klastra Kubernetes zosta\u0142y opracowane w ramach projektu Cloud RTI, kt\u00f3ry stworzono na podstawie open-source.<\/p>\n

W tym artykule, b\u0119d\u0105cym transkrypcj\u0105 wideo, opisano, jak skonfigurowa\u0107 Kubernetes wraz z innymi komponentami open-source, aby uzyska\u0107 gotowe do produkcji \u015brodowisko, kt\u00f3re bez przestoj\u00f3w w produkcji przyjmuje kod z commita git commit.<\/p>\n

\"DEVOXX<\/a><\/noindex><\/p>\n

DEVOXX UK. Kubernetes w produkcji: wdro\u017cenie Blue\/Green, automatyczne skalowanie i automatyzacja wdra\u017cania. Cz\u0119\u015b\u0107 1<\/a><\/noindex><\/p>\n

A wi\u0119c, po uzyskaniu dost\u0119pu do swoich aplikacji z zewn\u0105trz, mo\u017cna przyst\u0105pi\u0107 do pe\u0142nej konfiguracji automatyzacji, czyli doprowadzi\u0107 j\u0105 do etapu, na kt\u00f3rym mo\u017cna wykona\u0107 git commit i upewni\u0107 si\u0119, \u017ce ten git commit ko\u0144czy si\u0119 w produkcji. Oczywi\u015bcie, przy realizacji tych krok\u00f3w, podczas wdra\u017cania, nie chcemy do\u015bwiadcza\u0107 przestoj\u00f3w. Zatem wszelka automatyzacja w Kubernetes zaczyna si\u0119 od API. <\/p>\n

\"DEVOXX
\n
\nKubernetes to nie jest narz\u0119dzie, kt\u00f3re mo\u017cna efektywnie wykorzystywa\u0107 \"prosto z pude\u0142ka\". Oczywi\u015bcie, mo\u017cna tak zrobi\u0107, u\u017cywaj\u0105c kubectl i tak dalej, ale to API jest najciekawsz\u0105 i najbardziej przydatn\u0105 cz\u0119\u015bci\u0105 tej platformy. Korzystaj\u0105c z API jako zestawu funkcji, mo\u017cna uzyska\u0107 dost\u0119p niemal do wszystkiego, co chcesz zrobi\u0107 w Kubernetes. Sam kubectl r\u00f3wnie\u017c korzysta z REST API. <\/p>\n

To jest REST, wi\u0119c mo\u017cesz u\u017cywa\u0107 dowolnych j\u0119zyk\u00f3w i narz\u0119dzi do pracy z tym API, ale znacznie u\u0142atwi\u0105 ci \u017cycie biblioteki u\u017cytkownik\u00f3w. M\u00f3j zesp\u00f3\u0142 napisa\u0142 2 takie biblioteki: jedn\u0105 dla Java \/ OSGi i jedn\u0105 dla Go. Ta druga nie jest cz\u0119sto u\u017cywana, ale w ka\u017cdym razie masz te u\u017cyteczne narz\u0119dzia do dyspozycji. S\u0105 one cz\u0119\u015bciowo licencjonowanym projektem open-source. Istnieje wiele takich bibliotek dla r\u00f3\u017cnych j\u0119zyk\u00f3w, wi\u0119c mo\u017cesz wybra\u0107 najbardziej odpowiednie. <\/p>\n

\"DEVOXX
\n
\nZanim jednak przyst\u0105pisz do automatyzacji wdra\u017cania, musisz upewni\u0107 si\u0119, \u017ce ten proces nie b\u0119dzie nara\u017cony na jakiekolwiek przestoje. Na przyk\u0142ad nasz zesp\u00f3\u0142 przeprowadza wdro\u017cenia produkcyjne w po\u0142udnie, kiedy ludzie maksymalnie korzystaj\u0105 z aplikacji, dlatego bardzo wa\u017cne jest, aby unikn\u0105\u0107 op\u00f3\u017anie\u0144 w tym procesie. Aby unikn\u0105\u0107 przestoj\u00f3w, stosuje si\u0119 2 metody: wdra\u017canie blue\/green lub skrolling update. W tym drugim przypadku, je\u015bli masz 5 replik aplikacji, s\u0105 one aktualizowane jedna po drugiej. Ta metoda dzia\u0142a \u015bwietnie, ale nie jest odpowiednia, gdy podczas wdra\u017cania masz uruchomione r\u00f3\u017cne wersje aplikacji. W takim przypadku mo\u017cesz zaktualizowa\u0107 interfejs u\u017cytkownika, podczas gdy backend b\u0119dzie pracowa\u0107 ze starsz\u0105 wersj\u0105, co spowoduje przerwanie dzia\u0142ania aplikacji. Dlatego z punktu widzenia programowania praca w takich warunkach jest do\u015b\u0107 trudna. <\/p>\n

Jednym z powod\u00f3w, dla kt\u00f3rych preferujemy u\u017cywa\u0107 wdro\u017cenia blue\/green do automatyzacji wdra\u017cania naszych aplikacji, jest to, \u017ce w tym podej\u015bciu musisz upewni\u0107 si\u0119, \u017ce w danym momencie aktywna jest tylko jedna wersja aplikacji. <\/p>\n

Mechanizm wdro\u017cenia blue\/green wygl\u0105da nast\u0119puj\u0105co. Otrzymujemy ruch dla naszych aplikacji przez ha-proxy, kt\u00f3re kieruje go do uruchomionych replik aplikacji tej samej wersji. <\/p>\n

Kiedy nast\u0119puje nowe wdro\u017cenie, u\u017cywamy Deployer, kt\u00f3remu dostarczane s\u0105 nowe komponenty, a on przeprowadza wdro\u017cenie nowej wersji. Wdro\u017cenie nowej wersji aplikacji oznacza, \u017ce \"podnosi si\u0119\" nowy zestaw replik, po czym te repliki nowej wersji uruchamiane s\u0105 w oddzielnym, nowym podzie. Jednak ha-proxy nic o nich nie wie i na razie nie kieruje do nich \u017cadnego obci\u0105\u017cenia.<\/p>\n

Dlatego w pierwszej kolejno\u015bci nale\u017cy przeprowadzi\u0107 testy sprawno\u015bci nowych wersji health checking, aby upewni\u0107 si\u0119, \u017ce repliki s\u0105 gotowe do obs\u0142ugi obci\u0105\u017cenia.<\/p>\n

\"DEVOXX
\n
\nWszystkie komponenty wdro\u017ceniowe musz\u0105 wspiera\u0107 jak\u0105\u015b form\u0119 health check. Mo\u017ce to by\u0107 bardzo prosta kontrola HTTP z wywo\u0142aniem, kiedy otrzymujesz kod ze statusem 200, lub bardziej szczeg\u00f3\u0142owa kontrola, w kt\u00f3rej sprawdzasz po\u0142\u0105czenie replik z baz\u0105 danych i innymi us\u0142ugami, stabilno\u015b\u0107 po\u0142\u0105cze\u0144 w dynamicznym \u015brodowisku, czy wszystko dzia\u0142a i funkcjonuje poprawnie. Proces ten mo\u017ce by\u0107 do\u015b\u0107 skomplikowany. <\/p>\n

\"DEVOXX
\n
\nPo tym, jak system upewni si\u0119 w sprawno\u015bci wszystkich zaktualizowanych replik, Deployer zaktualizuje konfiguracj\u0119 i przeka\u017ce w\u0142a\u015bciwy confd, kt\u00f3ry przestawi ha-proxy. <\/p>\n

\"DEVOXX
\n
\nTylko po tym ruch b\u0119dzie kierowany do podu z replikami nowej wersji, a stary pod zniknie. <\/p>\n

\"DEVOXX
\n
\nTen mechanizm nie jest cech\u0105 Kubernetes. Koncepcja Blue\/green deployment istnieje od d\u0142u\u017cszego czasu i zawsze wykorzystywa\u0142a load balancer. Najpierw kierujesz ca\u0142y ruch do starej wersji aplikacji, a po aktualizacji ca\u0142kowicie przekierowujesz go na now\u0105 wersj\u0119. Ta zasada jest stosowana nie tylko w Kubernetes.<\/p>\n

Teraz przedstawi\u0119 wam nowy komponent wdro\u017cenia \u2013 Deployer, kt\u00f3ry wykonuje testy sprawno\u015bci, rekonfiguruje proxy i tak dalej. To koncept, kt\u00f3ry nie odnosi si\u0119 do \u015bwiata zewn\u0119trznego i istnieje wewn\u0105trz Kubernetes. Poka\u017c\u0119, jak stworzy\u0107 w\u0142asny koncept Deployer przy u\u017cyciu narz\u0119dzi open-source. <\/p>\n

Pierwsz\u0105 rzecz\u0105, jak\u0105 robi Deployer, jest stworzenie kontrolera replikacji RC za pomoc\u0105 API Kubernetes. To API tworzy pody i us\u0142ugi do dalszego wdro\u017cenia, czyli tworzy ca\u0142kowicie nowy klaster dla naszych aplikacji. Gdy tylko RC upewni si\u0119, \u017ce repliki zosta\u0142y uruchomione, przeprowadzi ich kontrol\u0119 zdrowia poprzez Health check. W tym celu w Deployerze wykorzystuje si\u0119 polecenie GET \/health. Uruchamia ono odpowiednie komponenty weryfikuj\u0105ce i sprawdza wszystkie elementy odpowiadaj\u0105ce za dzia\u0142anie klastra. <\/p>\n

\"DEVOXX
\n
\nPo tym, jak wszystkie pody zg\u0142osz\u0105 swoje \"zdrowie\", Deployer tworzy nowy element konfiguracji \u2013 rozproszone magazynowanie etcd, kt\u00f3re jest u\u017cywane wewn\u0105trz Kubernetes, w tym do przechowywania konfiguracji load balancera. Zapisujemy dane w etcd, a ma\u0142e narz\u0119dzie confd monitoruje etcd w poszukiwaniu nowych danych. <\/p>\n

Je\u015bli znajdzie jakie\u015b zmiany w pocz\u0105tkowej konfiguracji, generuje nowy plik konfiguracyjny i przekazuje go ha-proxy. W takim przypadku ha-proxy jest restartowane bez utraty jakichkolwiek po\u0142\u0105cze\u0144 i kieruje obci\u0105\u017cenie do nowych us\u0142ug, kt\u00f3re zapewniaj\u0105 dzia\u0142anie nowej wersji naszych aplikacji. <\/p>\n

\"DEVOXX
\n
\nJak widzicie, pomimo du\u017cej liczby komponent\u00f3w, nie ma tu nic skomplikowanego. Musisz po prostu po\u015bwi\u0119ci\u0107 wi\u0119cej uwagi API i etcd. Chc\u0119 wam opowiedzie\u0107 o open-source'owym deploerze, z kt\u00f3rego sami korzystamy \u2013 to Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nTo narz\u0119dzie do orkiestracji wdro\u017ce\u0144 Kubernetes z takimi funkcjami: <\/p>\n