Cześć wszystkim! Nazywam się Paweł Agaletsky. Pracuję jako lider zespołu w zespole rozwijającym system dostarczania Lamoda. W 2018 roku przemawiałem na konferencji HighLoad++, a dziś chciałbym zaprezentować transkrypcję mojego raportu.

Mój temat poświęcony jest doświadczeniom naszej firmy we wdrażaniu systemów i usług w różnych środowiskach. Począwszy od naszych czasów prehistorycznych, kiedy wdrażaliśmy wszystkie systemy na zwykłych serwerach wirtualnych, kończąc na stopniowym przejściu od Nomada do wdrożenia w Kubernetesie. Powiem Ci, dlaczego to zrobiliśmy i jakie problemy napotkaliśmy podczas tego procesu.

Wdrażanie aplikacji na maszynie wirtualnej

Zacznijmy od tego, że 3 lata temu wszystkie systemy i usługi firmy zostały wdrożone na zwykłych serwerach wirtualnych. Technicznie rzecz biorąc, zostało to zorganizowane w taki sposób, że cały kod naszych systemów był przechowywany i montowany przy użyciu automatycznych narzędzi do montażu, przy użyciu Jenkinsa. Za pomocą Ansible został on wdrożony z naszego systemu kontroli wersji na serwery wirtualne. Co więcej, każdy system, który posiadała nasza firma, był wdrożony na co najmniej 2 serwerach: jeden na głowie, drugi na ogonie. Te dwa systemy były do ​​siebie absolutnie identyczne we wszystkich ustawieniach, mocy, konfiguracji itp. Jedyna różnica między nimi polegała na tym, że głowa otrzymywała ruch od użytkowników, podczas gdy ogon nigdy nie otrzymywał ruchu od użytkowników.

Po co to było?

Wdrażając nowe wersje naszej aplikacji, chcieliśmy zapewnić jej płynne wdrożenie, czyli bez zauważalnych konsekwencji dla użytkowników. Osiągnięto to dzięki temu, że kolejne skompilowane wydanie przy użyciu Ansible zostało wdrożone do końca. Tam osoby zaangażowane we wdrożenie mogły sprawdzić i upewnić się, że wszystko jest w porządku: wszystkie metryki, sekcje i aplikacje działają; uruchamiane są niezbędne skrypty. Dopiero po upewnieniu się, że wszystko jest w porządku, zmieniono ruch. Zaczął przechodzić do serwera, który wcześniej był ogonem. A ten, który wcześniej był głową, pozostał bez ruchu użytkowników, mając jednocześnie na sobie poprzednią wersję naszej aplikacji.

Więc było to bezproblemowe dla użytkowników. Bo przełączenie jest natychmiastowe, bo to po prostu przełączenie balansera. Możesz bardzo łatwo wrócić do poprzedniej wersji, po prostu przełączając balanser z powrotem. Mogliśmy także sprawdzić, czy aplikacja była zdolna do produkcji jeszcze przed otrzymaniem ruchu od użytkowników, co było całkiem wygodne.

Jakie zalety w tym wszystkim dostrzegliśmy?

1. Po pierwsze to wystarczy to po prostu działa. Każdy rozumie, jak działa taki schemat wdrażania, ponieważ większość ludzi kiedykolwiek wdrażała rozwiązania na zwykłych serwerach wirtualnych.
2. Wystarczy niezawodnie, ponieważ technologia wdrożenia jest prosta, przetestowana przez tysiące firm. W ten sposób wdrażane są miliony serwerów. Trudno coś zepsuć.
3. I w końcu mogliśmy dostać rozmieszczenia atomowe. Wdrożenia, które u użytkowników zachodzą jednocześnie, bez zauważalnego etapu przełączania pomiędzy starą wersją a nową.

Ale dostrzegliśmy w tym wszystkim także kilka niedociągnięć:

1. Oprócz środowiska produkcyjnego, środowiska programistycznego, istnieją inne środowiska. Na przykład kontrola jakości i przedprodukcja. W tym czasie mieliśmy wiele serwerów i około 60 usług. Z tego powodu było to konieczne dla każdej usługi zachowaj jej najnowszą wersję maszyna wirtualna. Co więcej, jeśli chcesz zaktualizować biblioteki lub zainstalować nowe zależności, musisz to zrobić we wszystkich środowiskach. Należało także zsynchronizować czas wdrożenia kolejnej nowej wersji aplikacji z czasem, w którym devops dokonuje niezbędnych ustawień środowiska. W takim przypadku łatwo jest wpaść w sytuację, w której nasze otoczenie będzie nieco inne we wszystkich środowiskach jednocześnie. Na przykład w środowisku kontroli jakości będzie kilka wersji bibliotek, a w środowisku produkcyjnym będą inne, co będzie prowadzić do problemów.
2. Trudności w aktualizowaniu zależności Twoje zgłoszenie. To nie zależy od ciebie, ale od drugiej drużyny. Mianowicie od zespołu devops, który utrzymuje serwery. Musisz dać im odpowiednie zadanie i opis tego, co chcesz zrobić.
3. Chcieliśmy wtedy też podzielić duże, duże monolity, które mieliśmy, na osobne, małe usługi, bo wiedzieliśmy, że będzie ich coraz więcej. W tym czasie mieliśmy ich już ponad 100. Dla każdej nowej usługi konieczne było utworzenie osobnej nowej maszyny wirtualnej, którą również trzeba było utrzymać i wdrożyć. Ponadto nie potrzebujesz jednego samochodu, ale co najmniej dwóch. Do tego wszystkiego dochodzi środowisko kontroli jakości. Powoduje to problemy i utrudnia budowanie i uruchamianie nowych systemów. skomplikowany, kosztowny i długotrwały proces.

Dlatego zdecydowaliśmy, że wygodniej będzie przejść od wdrażania zwykłych maszyn wirtualnych do wdrażania naszych aplikacji w kontenerze dokowanym. Jeśli masz okno dokowane, potrzebujesz systemu, który może uruchomić aplikację w klastrze, ponieważ nie możesz po prostu podnieść kontenera. Zwykle chcesz śledzić, ile kontenerów zostało podniesionych, aby podnosiły się automatycznie. Z tego powodu musieliśmy wybrać system sterowania.

Długo zastanawialiśmy się, który z nich wybrać. Faktem jest, że w tamtym czasie ten stos wdrożeniowy na zwykłych serwerach wirtualnych był nieco przestarzały, ponieważ nie posiadały one najnowszych wersji systemów operacyjnych. W pewnym momencie istniał nawet FreeBSD, którego obsługa nie była zbyt wygodna. Zrozumieliśmy, że musimy jak najszybciej przeprowadzić migrację do platformy Docker. Nasi devops sprawdzili swoje dotychczasowe doświadczenia z różnymi rozwiązaniami i wybrali system taki jak Nomad.

Przełącz się na Nomada

Nomad jest produktem HashiCorp. Znani są także z innych rozwiązań:

"Konsul" to narzędzie do odkrywania usług.

„Terraforma” - system do zarządzania serwerami umożliwiający ich konfigurację poprzez konfigurację, tzw. infrastruktura jako kod.

"Włóczęga" umożliwia wdrażanie maszyn wirtualnych lokalnie lub w chmurze za pomocą określonych plików konfiguracyjnych.

Nomad wydawał się wówczas dość prostym rozwiązaniem, na które można było szybko się przestawić bez konieczności zmiany całej infrastruktury. Poza tym dość łatwo się go nauczyć. Dlatego wybraliśmy go jako system filtracji do naszego kontenera.

Czego potrzebujesz, aby wdrożyć swój system w Nomadzie?

1. Przede wszystkim potrzebujesz obraz dokera Twoje zgłoszenie. Musisz go zbudować i umieścić w repozytorium obrazów dokowanych. W naszym przypadku jest to artefakt – system pozwalający wpychać do niego różne artefakty różnego typu. Może przechowywać archiwa, obrazy dokerów, pakiety PHP kompozytora, pakiety NPM i tak dalej.
2. Również potrzebne plik konfiguracyjny, który powie Nomadowi, co, gdzie i w jakiej ilości chcesz wdrożyć.

Kiedy mówimy o Nomadzie, używa on języka HCL jako formatu pliku informacyjnego, co oznacza Język konfiguracji HashiCorp. Jest to nadzbiór Yaml, który pozwala opisać Twoją usługę w kategoriach Nomad.

Pozwala określić, ile kontenerów chcesz wdrożyć, z których obrazów mają one przekazywać im różne parametry podczas wdrażania. W ten sposób przekazujesz ten plik Nomadowi, a on zgodnie z nim uruchamia kontenery do produkcji.

W naszym przypadku zdaliśmy sobie sprawę, że samo napisanie absolutnie identycznych plików HCL dla każdej usługi nie byłoby zbyt wygodne, ponieważ usług jest dużo i czasami trzeba je zaktualizować. Zdarza się, że jedna usługa jest wdrażana nie w jednej instancji, ale w wielu różnych. Na przykład jeden z systemów, który mamy w produkcji, ma w produkcji ponad 100 instancji. Działają na podstawie tych samych obrazów, ale różnią się ustawieniami konfiguracyjnymi i plikami konfiguracyjnymi.

Dlatego zdecydowaliśmy, że wygodnie będzie nam przechowywać wszystkie nasze pliki konfiguracyjne do wdrożenia w jednym wspólnym repozytorium. Dzięki temu były widoczne: były łatwe w utrzymaniu i mogliśmy zobaczyć, jakie mamy systemy. W razie potrzeby łatwo jest też coś zaktualizować lub zmienić. Dodanie nowego systemu również nie jest trudne - wystarczy utworzyć plik konfiguracyjny w nowym katalogu. Znajdują się w nim pliki: service.hcl, który zawiera opis naszej usługi oraz kilka plików env, które pozwalają na konfigurację tej właśnie usługi, wdrażanej w środowisku produkcyjnym.

Jednak część naszych systemów wdrażana jest do produkcji nie w jednym egzemplarzu, a w kilku naraz. Dlatego zdecydowaliśmy, że wygodnie będzie nam przechowywać konfiguracje nie w ich czystej postaci, ale w formie szablonowej. I wybraliśmy dżinja 2. W tym formacie przechowujemy zarówno konfiguracje samej usługi, jak i potrzebne do niej pliki env.

Dodatkowo umieściliśmy w repozytorium wspólny dla wszystkich projektów skrypt wdrożeniowy, który pozwala na uruchomienie i wdrożenie Twojej usługi na produkcję, w wybrane środowisko, w pożądany cel. W przypadku gdy zamieniliśmy naszą konfigurację HCL na szablon, wówczas plik HCL, który wcześniej był zwykłą konfiguracją Nomada, w tym przypadku zaczął wyglądać nieco inaczej.

Oznacza to, że zastąpiliśmy niektóre zmienne lokalizacji konfiguracji wstawkami zmiennych pobranymi z plików env lub innych źródeł. Dodatkowo otrzymaliśmy możliwość dynamicznego gromadzenia plików HCL, czyli możemy wykorzystywać nie tylko zwykłe wstawienia zmiennych. Ponieważ jinja obsługuje pętle i warunki, możesz tam także tworzyć pliki konfiguracyjne, które zmieniają się w zależności od tego, gdzie dokładnie wdrażasz swoje aplikacje.

Na przykład chcesz wdrożyć usługę w fazie przedprodukcyjnej i produkcyjnej. Załóżmy, że w fazie przedprodukcyjnej nie chcesz uruchamiać skryptów cron, ale chcesz po prostu zobaczyć usługę w osobnej domenie, aby upewnić się, że działa. Dla każdego, kto wdraża usługę, proces wygląda bardzo prosto i przejrzyście. Wszystko, co musisz zrobić, to uruchomić plik Deploy.sh, określić, którą usługę chcesz wdrożyć i do jakiego celu. Na przykład chcesz wdrożyć określony system w Rosji, na Białorusi lub w Kazachstanie. Aby to zrobić, wystarczy zmienić jeden z parametrów, a otrzymasz poprawny plik konfiguracyjny.

Gdy usługa Nomad jest już wdrożona w Twoim klastrze, wygląda to tak.

Po pierwsze, potrzebujesz jakiegoś modułu równoważącego na zewnątrz, który będzie odbierał cały ruch użytkowników. Będzie współpracować z Consulem i dowiedzieć się z niego, gdzie, na jakim węźle, pod jakim adresem IP znajduje się konkretna usługa odpowiadająca konkretnej nazwie domeny. Usługi w Consul pochodzą od samego Nomada. Ponieważ są to produkty tej samej firmy, są ze sobą dość powiązane. Można powiedzieć, że Nomad od razu po wyjęciu z pudełka potrafi zarejestrować w Consulu wszystkie uruchomione w nim usługi.

Gdy moduł równoważenia obciążenia frontonu wie, do której usługi wysłać ruch, przekazuje go do odpowiedniego kontenera lub wielu kontenerów pasujących do Twojej aplikacji. Naturalnie trzeba także pomyśleć o bezpieczeństwie. Mimo że wszystkie usługi działają na tych samych maszynach wirtualnych w kontenerach, zwykle wymaga to uniemożliwienia swobodnego dostępu z którejkolwiek usługi do innej. Osiągnęliśmy to poprzez segmentację. Każda usługa została uruchomiona we własnej sieci wirtualnej, na której zostały określone reguły routingu oraz reguły zezwalania/odmawiania dostępu do innych systemów i usług. Mogą znajdować się zarówno wewnątrz tej gromady, jak i poza nią. Na przykład, jeśli chcesz uniemożliwić usłudze łączenie się z określoną bazą danych, można to zrobić poprzez segmentację na poziomie sieci. Oznacza to, że nawet przez pomyłkę nie można przypadkowo połączyć się ze środowiska testowego z produkcyjną bazą danych.

Ile kosztowało nas przejście pod względem zasobów ludzkich?

Przejście całej firmy do Nomada trwało około 5-6 miesięcy. Poruszaliśmy się usługa po usłudze, ale w dość szybkim tempie. Każdy zespół musiał stworzyć własne kontenery na usługi.

Przyjęliśmy takie podejście, że każdy zespół jest samodzielnie odpowiedzialny za obrazy dokerów swoich systemów. DevOps zapewniają ogólną infrastrukturę niezbędną do wdrożenia, czyli obsługę samego klastra, obsługę systemu CI i tak dalej. A w tym czasie przenieśliśmy do Nomada ponad 60 systemów, co stanowiło około 2 tysiące kontenerów.

Devops jest odpowiedzialny za ogólną infrastrukturę wszystkiego, co jest związane z wdrażaniem i serwerami. Z kolei każdy zespół programistów jest odpowiedzialny za wdrożenie kontenerów dla swojego konkretnego systemu, ponieważ to zespół wie, czego ogólnie potrzebuje w konkretnym kontenerze.

Powody porzucenia Nomada

Jakie korzyści uzyskaliśmy przechodząc na wdrożenie m.in. za pomocą Nomada i dockera?

1. My pod warunkiem równych warunków dla wszystkich środowisk. W środowisku programistycznym, QA, przedprodukcyjnym, produkcyjnym używane są te same obrazy kontenerów, z tymi samymi zależnościami. W związku z tym praktycznie nie masz szans, że to, co trafi do środowiska produkcyjnego, nie będzie tym, co wcześniej testowałeś lokalnie lub w środowisku testowym.
2. Stwierdziliśmy również, że to wystarczy łatwo dodać nową usługę. Z punktu widzenia wdrożenia nowe systemy są uruchamiane w bardzo prosty sposób. Po prostu przejdź do repozytorium, w którym przechowywane są konfiguracje, dodaj tam kolejną konfigurację dla swojego systemu i gotowe. Możesz wdrożyć swój system w środowisku produkcyjnym bez dodatkowego wysiłku ze strony devops.
3. Wszystkie pliki konfiguracyjne w jednym wspólnym repozytorium okazało się, że jest w trakcie przeglądu. W momencie wdrażania naszych systemów przy użyciu serwerów wirtualnych korzystaliśmy z Ansible, w którym konfiguracje znajdowały się w tym samym repozytorium. Jednak dla większości programistów praca z tym była nieco trudniejsza. W tym przypadku ilość konfiguracji i kodu, które należy dodać, aby wdrożyć usługę, stała się znacznie mniejsza. Co więcej, devops bardzo łatwo to naprawić lub zmienić. W przypadku przejścia np. na nową wersję Nomada, mogą pobrać i zbiorczo zaktualizować wszystkie pliki operacyjne znajdujące się w tym samym miejscu.

Ale napotkaliśmy również kilka wad:

Okazało się, że my nie udało się osiągnąć bezproblemowego wdrożenia w przypadku Nomada. Podczas wdrażania kontenerów w różnych warunkach mogło się okazać, że działają, a Nomad postrzegał go jako kontener gotowy do przyjęcia ruchu. Stało się to zanim znajdująca się w nim aplikacja miała szansę się uruchomić. Z tego powodu system przez krótki czas zaczął generować 500 błędów, gdyż ruch zaczął trafiać do kontenera, który nie był jeszcze gotowy na jego przyjęcie.

Spotkaliśmy kilku błędy. Najbardziej znaczącym błędem jest to, że Nomad nie radzi sobie zbyt dobrze z dużym klastrem, jeśli masz wiele systemów i kontenerów. Gdy chcemy wyjąć do konserwacji jeden z serwerów wchodzących w skład klastra Nomad, istnieje dość duże prawdopodobieństwo, że klaster nie będzie czuł się zbyt dobrze i się rozpadnie. Niektóre kontenery mogą np. spadać, a nie podnosić się – będzie Cię to później bardzo dużo kosztować, jeśli wszystkie Twoje systemy produkcyjne będą zlokalizowane w klastrze zarządzanym przez Nomada.

Postanowiliśmy więc zastanowić się, dokąd powinniśmy się udać dalej. W tym momencie staliśmy się znacznie bardziej świadomi tego, co chcemy osiągnąć. Mianowicie: chcemy niezawodności, trochę więcej funkcji niż zapewnia Nomad i systemu bardziej dojrzałego, stabilniejszego.

Pod tym względem nasz wybór padł na Kubernetes jako najpopularniejszą platformę do uruchamiania klastrów. Tym bardziej, że wielkość i ilość naszych kontenerów była odpowiednio duża. Do takich celów Kubernetes wydawał się najodpowiedniejszym systemem, na jaki mogliśmy spojrzeć.

Przejście na Kubernetes

Opowiem Wam trochę o podstawowych koncepcjach Kubernetesa i czym różnią się one od Nomada.

Po pierwsze, najbardziej podstawową koncepcją w Kubernetesie jest koncepcja podu. Strąk to grupa jednego lub większej liczby kontenerów, które zawsze działają razem. I zawsze działają jakby ściśle na jednej maszynie wirtualnej. Są one dostępne dla siebie nawzajem poprzez IP 127.0.0.1 na różnych portach.

Załóżmy, że masz aplikację PHP składającą się z nginx i php-fpm - klasyczny schemat. Najprawdopodobniej będziesz chciał przez cały czas przechowywać razem kontenery nginx i php-fpm. Kubernetes pozwala to osiągnąć, opisując je jako jeden wspólny pod. To jest dokładnie to, czego nie mogliśmy osiągnąć w przypadku Nomada.

Druga koncepcja to Wdrożenie. Faktem jest, że kapsuła sama w sobie jest rzeczą efemeryczną, zaczyna się i znika. Czy chcesz najpierw zabić wszystkie swoje poprzednie kontenery, a potem od razu uruchomić nowe wersje, czy też chcesz je wdrażać stopniowo?To jest proces, za który odpowiada koncepcja wdrożenia. Opisuje, w jaki sposób wdrażasz swoje pody, w jakiej ilości i jak je aktualizować.

Trzecia koncepcja to usługa. Twoja usługa to tak naprawdę Twój system, który odbiera pewien ruch, a następnie przekazuje go do jednego lub większej liczby podów odpowiadających Twojej usłudze. Oznacza to, że można powiedzieć, że cały ruch przychodzący do takiej a takiej usługi o takiej a takiej nazwie musi być wysyłany do tych konkretnych podów. Jednocześnie zapewnia równoważenie ruchu. Oznacza to, że możesz uruchomić dwa pody swojej aplikacji, a cały ruch przychodzący będzie równomiernie równoważony pomiędzy podami związanymi z tą usługą.

Czwartą podstawową koncepcją jest Ingres. Jest to usługa działająca na klastrze Kubernetes. Działa jako zewnętrzny moduł równoważenia obciążenia, który przejmuje wszystkie żądania. Korzystając z Kubernetes API, Ingress może określić, gdzie te żądania powinny zostać wysłane. Co więcej, robi to bardzo elastycznie. Można powiedzieć, że wszystkie żądania kierowane do tego hosta i takiego a takiego adresu URL są wysyłane do tej usługi. A te żądania przychodzące do tego hosta i na inny adres URL są wysyłane do innej usługi.

Najfajniejszą rzeczą z punktu widzenia osoby tworzącej aplikację jest to, że możesz sam nią zarządzać. Ustawiając konfigurację Ingress, możesz cały ruch przychodzący do takiego a takiego API wysyłać do osobnych kontenerów zapisanych np. w Go. Ale ten ruch, przychodzący do tej samej domeny, ale pod inny adres URL, powinien być wysyłany do kontenerów napisanych w PHP, gdzie jest dużo logiki, ale nie są one zbyt szybkie.

Jeśli porównamy wszystkie te koncepcje z Nomadą, możemy powiedzieć, że pierwsze trzy koncepcje to razem Usługa. A tej ostatniej koncepcji nie ma w samym Nomadzie. Użyliśmy zewnętrznego balansera: może to być haproxy, nginx, nginx+ i tak dalej. W przypadku kostki nie trzeba osobno wprowadzać tego dodatkowego pojęcia. Jeśli jednak spojrzysz na Ingress wewnętrznie, jest to albo nginx, haproxy, albo traefik, ale w pewnym sensie wbudowany w Kubernetes.

Wszystkie koncepcje, które opisałem, to tak naprawdę zasoby, które istnieją w ramach klastra Kubernetes. Do ich opisania w kostce zastosowano format yaml, który jest bardziej czytelny i znajomy niż pliki HCL w przypadku Nomada. Ale strukturalnie opisują to samo w przypadku np. strąka. Mówią – chcę tam rozmieścić takie a takie kapsuły, z takimi a takimi obrazami, w takich a takich ilościach.

Ponadto zdaliśmy sobie sprawę, że nie chcemy ręcznie tworzyć każdego zasobu z osobna: wdrożenia, usług, Ingressu itp. Zamiast tego chcieliśmy opisać każdy z naszych systemów pod względem Kubernetesa podczas wdrożenia, abyśmy nie musieli ręcznie odtwarzać wszystkich niezbędnych zależności zasobów w odpowiedniej kolejności. Jako system, który nam to umożliwił, wybrano Helm.

Podstawowe pojęcia w Helmie

Hełm jest menedżer pakietów dla Kubernetesa. Jest to bardzo podobne do działania menedżerów pakietów w językach programowania. Pozwalają na przechowywanie usługi składającej się np. z Deployment nginx, Deployment php-fpm, config dla Ingress, configmaps (jest to encja pozwalająca na ustawienie env i innych parametrów dla Twojego systemu) w postaci tzw. zwane wykresami. W tym samym czasie Helm działa na platformie Kubernetes. Oznacza to, że nie jest to jakiś system stojący na uboczu, ale po prostu kolejna usługa uruchomiona wewnątrz kostki. Komunikujesz się z nim za pośrednictwem interfejsu API za pomocą polecenia konsoli. Jego wygoda i piękno polega na tym, że nawet jeśli ster się zepsuje lub usuniesz go z klastra, Twoje usługi nie znikną, ponieważ ster zasadniczo służy jedynie do uruchomienia systemu. Sam Kubernetes odpowiada wówczas za wydajność i stan usług.

Zdaliśmy sobie z tego również sprawę szablonyzacja, do czego byliśmy wcześniej zmuszeni sami, wprowadzając jinję do naszych konfiguracji, jest jedną z głównych cech hełmu. Wszystkie konfiguracje, które tworzysz dla swoich systemów, są przechowywane w hełmie w formie szablonów, trochę podobnych do jinja, ale w rzeczywistości przy użyciu szablonów języka Go, w którym napisany jest hełm, podobnie jak Kubernetes.

Helm dodaje dla nas jeszcze kilka koncepcji.

Wykres - to jest opis Twojej usługi. W innych menedżerach pakietów nazywałoby się to pakietem, pakietem lub czymś podobnym. Tutaj nazywa się to wykresem.

Wartości to zmienne, których chcesz użyć do zbudowania konfiguracji na podstawie szablonów.

Wydanie. Za każdym razem, gdy usługa wdrożona przy użyciu Helm otrzymuje przyrostową wersję wydania. Helm pamięta konfigurację usługi w poprzedniej wersji, wersji wcześniejszej i tak dalej. Dlatego jeśli chcesz wycofać zmiany, po prostu uruchom komendę wywołania zwrotnego steru, wskazując ją na poprzednią wersję. Nawet jeśli odpowiednia konfiguracja w repozytorium nie jest dostępna w momencie wycofywania zmian, Helm nadal będzie pamiętał, jaka była i przywróci system do stanu, w jakim znajdował się w poprzedniej wersji.

W przypadku gdy korzystamy z helm, zwykłe konfiguracje dla Kubernetesa zamieniają się także w szablony, w których możliwe jest wykorzystanie zmiennych, funkcji, a także zastosowanie instrukcji warunkowych. W ten sposób możesz zebrać konfigurację usługi w zależności od środowiska.

W praktyce postanowiliśmy zrobić trochę inaczej niż w przypadku Nomada. Jeśli w Nomadzie zarówno konfiguracje wdrożeniowe, jak i n-zmiennych, które były potrzebne do wdrożenia naszej usługi, były przechowywane w jednym repozytorium, tutaj postanowiliśmy podzielić je na dwa osobne repozytoria. Repozytorium „deploy” przechowuje tylko n zmiennych potrzebnych do wdrożenia, a repozytorium „helm” przechowuje konfiguracje lub wykresy.

Co nam to dało?

Pomimo tego, że w samych plikach konfiguracyjnych nie przechowujemy żadnych szczególnie wrażliwych danych. Na przykład hasła do baz danych. Są one przechowywane jako tajemnice w Kubernetesie, niemniej jednak wciąż są tam pewne rzeczy, do których nie chcemy dawać każdemu dostępu. Dlatego dostęp do repozytorium „wdrożenia” jest bardziej ograniczony, a repozytorium „sterowania” zawiera jedynie opis usługi. Z tego powodu dostęp do niego może bezpiecznie uzyskać szersze grono osób.

Ponieważ mamy nie tylko środowiska produkcyjne, ale także inne środowiska, dzięki temu rozdzieleniu możemy ponownie wykorzystać nasze wykresy steru do wdrożenia usług nie tylko na produkcję, ale także na przykład na środowisko kontroli jakości. Nawet do wdrożenia ich lokalnie przy użyciu Minikube - to kwestia lokalnego uruchamiania Kubernetesa.

Wewnątrz każdego repozytorium pozostawiliśmy podział na osobne katalogi dla każdej usługi. Oznacza to, że wewnątrz każdego katalogu znajdują się szablony powiązane z odpowiednim wykresem i opisujące zasoby, które należy wdrożyć, aby uruchomić nasz system. W repozytorium „deploy” zostawiliśmy tylko env. W tym przypadku nie korzystaliśmy z szablonowania za pomocą jinja, ponieważ sam hełm zapewnia gotowe szablony - jest to jedna z jego głównych funkcji.

Zostawiliśmy skrypt wdrożeniowy - Deploy.sh, który upraszcza i standaryzuje uruchamianie wdrożeń za pomocą helm. Zatem dla każdego, kto chce wdrożyć, interfejs wdrażania wygląda dokładnie tak samo, jak podczas wdrażania za pośrednictwem Nomada. Ten sam plik Deploy.sh, nazwa Twojej usługi i miejsce, w którym chcesz ją wdrożyć. Powoduje to wewnętrzne uruchomienie steru. Ten z kolei zbiera konfiguracje z szablonów, wstawia do nich niezbędne pliki z wartościami, a następnie wdraża je, uruchamiając je w Kubernetesie.

odkrycia

Usługa Kubernetes wydaje się być bardziej złożona niż Nomad.

Tutaj ruch wychodzący trafia do Ingress. To po prostu kontroler frontowy, który przejmuje wszystkie żądania, a następnie wysyła je do usług odpowiadających danym żądania. Określa je na podstawie konfiguracji, które są częścią opisu aplikacji w sterze i które programiści ustawili samodzielnie. Usługa wysyła żądania do swoich podów, czyli konkretnych kontenerów, równoważąc ruch przychodzący pomiędzy wszystkimi kontenerami należącymi do tej usługi. I oczywiście nie powinniśmy zapominać, że nie powinniśmy odchodzić od bezpieczeństwa na poziomie sieci. Dlatego segmentacja działa w klastrze Kubernetes, który opiera się na tagowaniu. Wszystkie usługi mają określone tagi, z którymi powiązane są prawa dostępu usług do określonych zasobów zewnętrznych/wewnętrznych wewnątrz lub na zewnątrz klastra.

Kiedy dokonaliśmy przejścia, zobaczyliśmy, że Kubernetes ma wszystkie możliwości Nomada, z których korzystaliśmy wcześniej, a także dodał wiele nowych rzeczy. Można go rozszerzać poprzez wtyczki, a właściwie poprzez niestandardowe typy zasobów. Oznacza to, że masz możliwość nie tylko użycia czegoś, co jest dostarczane z Kubernetesem od razu po wyjęciu z pudełka, ale także stworzenia własnego zasobu i usługi, która będzie czytać Twoje zasoby. Daje to dodatkowe możliwości rozbudowy systemu bez konieczności ponownej instalacji Kubernetesa i bez konieczności modyfikacji.

Przykładem takiego zastosowania jest Prometheus, który działa wewnątrz naszego klastra Kubernetes. Aby zaczął zbierać metryki z konkretnej usługi, musimy do opisu usługi dodać dodatkowy rodzaj zasobu, tzw. monitor usługi. Prometheus, z uwagi na to, że po uruchomieniu w Kubernetesie potrafi odczytać niestandardowy typ zasobu, automatycznie rozpoczyna zbieranie metryk z nowego systemu. To całkiem wygodne.

Pierwsze wdrożenie w Kubernetesie odbyło się w marcu 2018 r. I przez ten czas nigdy nie doświadczyliśmy z nim żadnych problemów. Działa dość stabilnie, bez znaczących błędów. Dodatkowo możemy go jeszcze bardziej rozbudować. Dziś mamy już dość jego możliwości i bardzo podoba nam się tempo rozwoju Kubernetesa. Obecnie w Kubernetesie znajduje się ponad 3000 kontenerów. Klaster zajmuje kilka węzłów. Jednocześnie jest sprawny, stabilny i bardzo łatwy w sterowaniu.

Źródło: www.habr.com