Zachęcam do zapoznania się z transkrypcją wykładu Aleksandra Sigaczewa na temat Service Discovery w systemach rozproszonych na przykładzie Consul.
Service Discovery został stworzony, aby z minimalnymi kosztami można było podłączyć nowe aplikacje do już istniejącego środowiska. Dzięki Service Discovery możemy maksymalnie oddzielić zarówno kontener w postaci Dockera, jak i wirtualną usługę od środowiska, w którym jest uruchomiona.
Witam wszystkich! Nazywam się Aleksandr Sigaczew, pracuję w firmie Inventos. Dziś zapoznacie się z pojęciem, jakim jest Service Discovery. Omówimy Service Discovery na przykładzie Consul.
Jakie problemy rozwiązuje Service Discovery? Service Discovery został stworzony, aby z minimalnymi kosztami można było podłączyć nowe aplikacje do już istniejącego środowiska. Dzięki Service Discovery możemy maksymalnie oddzielić zarówno kontener w postaci Dockera, jak i wirtualną usługę od środowiska, w którym jest uruchomiona.
Jak to wygląda? Na klasycznym przykładzie w sieci – to front-end, który przyjmuje zapytania od użytkowników. Następnie wykonuje ich routowanie na backend. W tym przypadku – load-balancer rozkłada obciążenie na dwa backendy.
Tutaj widzimy, że uruchamiamy trzecią instancję aplikacji. Gdy aplikacja jest uruchamiana, rejestruje się w Service Discovery. Service Discovery informuje load-balancer. Load-balancer automatycznie zmienia swoją konfigurację, a nowy backend zostaje podłączony do pracy. W ten sposób można dodawać backendy lub, wręcz przeciwnie, wyłączać je z pracy.
Jakie inne wygodne funkcje oferuje Service Discovery? W Service Discovery można przechowywać konfiguracje nginx, certyfikaty oraz listę aktywnych serwerów backendowych.
Ponadto Service Discovery pozwala na wykrywanie awarii i problemów. Jakie mogą być schematy wykrywania awarii?
- Ta aplikacja, którą opracowaliśmy, sama powiadamia Service Discovery, że nadal działa.
- Service Discovery z kolei pyta aplikację o dostępność.
- Można także użyć zewnętrznego skryptu lub aplikacji, która sprawdza dostępność naszej aplikacji i informuje Service Discovery, że wszystko jest w porządku i można pracować, lub wręcz przeciwnie, że coś nie działa i ta instancja aplikacji powinna być wyłączona z równoważenia obciążenia.
Każdy z schematów można zastosować w zależności od tego, jakie oprogramowanie używamy. Na przykład, gdy dopiero zaczynamy rozwijać nowy projekt, bez problemu możemy zapewnić schemat, w którym nasze aplikacje powiadamiają Service Discovery. Możemy też podłączyć, że Service Discovery przeprowadza kontrolę.
Jeśli aplikacja trafiła do nas w spadku lub została opracowana przez kogoś innego, to tutaj odpowiedni jest trzeci wariant, gdy piszemy obsługę, a wszystko to wchodzi w naszą pracę automatycznie.
To jeden z przykładów. Load-balancer w postaci nginx jest przeładowywany. To dodatkowe narzędzie, które jest dostarczane razem z Consul. To consul-template. Opisujemy regułę. Mówimy, że używamy szablonu (Szablon Golanga). Przy wystąpieniu zdarzeń, przy powiadomieniach, że zaszły zmiany, jest on regenerowany, a Service Discovery otrzymuje komendę „reload”. Najprostszy przykład, kiedy po zdarzeniu nginx jest rekonfigurowany i ponownie uruchamiany.
Czym jest Consul?
Przede wszystkim – to Service Discovery.
Ma mechanizm sprawdzania dostępności – Health Checking.
Zawiera również KV Store.
Na jego podstawie można korzystać z Multi Datacenter.
Do czego to wszystko można wykorzystać? W KV Store możemy przechowywać przykłady konfiguracji. Health Checking możemy przeprowadzać testy lokalnej usługi i powiadamiać. Multi Datacenter służy do budowy mapy usług. Na przykład Amazon ma kilka stref i kieruje ruch w najbardziej optymalny sposób, aby nie generować dodatkowych zapytań między centrami danych, za które są oddzielnie naliczane opłaty, a co za tym idzie mają mniejsze opóźnienia.
Trochę przyjrzymy się terminom, które są używane w Consul.
- Consul – serwis napisany w Go. Jedną z zalet programów w Go jest to, że to jeden plik binarny, który po prostu pobierasz. Uruchamiasz z dowolnego miejsca i nie masz żadnych zależności.
- Następnie przy pomocy kluczy możemy uruchomić ten serwis w trybie klienta lub serwera.
- Atrybut „datacenter” pozwala oznaczyć, do którego centrum danych należy dany serwer.
- Consensus – oparty na protokole raft. Jeśli kogoś to interesuje, można poczytać o tym więcej na stronie Consul. To protokół, który pozwala określić lidera i ustalić, które dane można uznać za ważne i dostępne.
- Gossip – to protokół, który zapewnia interakcję między węzłami. System ten jest zdecentralizowany. W obrębie jednego centrum danych wszystkie węzły komunikują się z sąsiadami, przekazując sobie nawzajem informacje o aktualnym stanie. Można powiedzieć, że to plotki między sąsiadami.
- LAN Gossip – lokalna wymiana danych między sąsiadami w obrębie jednego centrum danych.
- WAN Gossip – używany, gdy potrzebujemy synchronizować informacje między dwoma centrami danych. Informacje przepływają między węzłami oznaczonymi jako serwer.
- RPC – pozwala na wysyłanie zapytań przez klienta do serwera.
Opis RPC. Załóżmy, że na maszynie wirtualnej lub fizycznym serwerze uruchomiony jest Consul jako klient. Zwracamy się do niego lokalnie. Następnie lokalny klient wysyła zapytanie do serwera i synchronizuje się. Informacje, w zależności od ustawień, mogą pochodzić z lokalnej pamięci podręcznej lub mogą być synchronizowane z liderem, głównym serwerem.
Obie te schemy mają swoje plusy i minusy. Jeśli pracujemy z lokalną pamięcią podręczną, to jest szybko. Jeśli pracujemy z danymi przechowywanymi na serwerze, to trwa dłużej, ale uzyskujemy bardziej aktualne informacje.
Gdyby to zobrazować graficznie, wyglądałoby to tak: uruchomione są trzy węzły główne. Jeden oznaczony gwiazdką jest liderem. W tym przykładzie trzy klientów wymieniają się lokalnie informacjami przez UDP/TCP. A informacje między centrami danych są przesyłane między serwerami. Klienci współdziałają lokalnie.
Jakie API oferuje Consul? Aby uzyskać informacje, Consul ma dwa rodzaje API.
To API DNS. Domyślnie Consul działa na porcie 8600. Możemy skonfigurować proxy zapytań i zapewnić dostęp przez lokalne rozwiązywanie, przez lokalny DNS. Możemy zapytać o domenę i otrzymamy informacje o adresie IP.
API HTTP – możemy lokalnie na porcie 8500 zapytać o konkretną usługę i otrzymać odpowiedź w formacie JSON zawierającą jaki adres IP ma serwer, jaki host i jaki port jest zarejestrowany. Dodatkowe informacje mogą być przesyłane przez token.
Co jest potrzebne, aby uruchomić Consul?
W pierwszej opcji w trybie dewelopera wskazujemy flagę, że to jest tryb dewelopera. Agent uruchamia się jako serwer. I całą funkcję wykonuje już samodzielnie na jednej maszynie. Wygodne, szybkie i praktycznie żadnych dodatkowych ustawień na pierwszy start nie jest wymagane.
Drugi tryb to uruchomienie w produkcji. Tutaj uruchomienie jest nieco bardziej skomplikowane. Jeśli nie mamy żadnej wersji konsula, musimy wprowadzić bootstrap w pierwszej maszynie, tzn. ta maszyna, która przejmie obowiązki lidera. Podnosimy ją, następnie podnosimy drugi egzemplarz serwera, przekazując mu informacje, gdzie znajduje się master. Podnosimy trzecią. Po tym, jak mamy trzy maszyny uruchomione, na pierwszej maszynie z uruchomionego bootstrapu, uruchamiamy ją w normalnym trybie. Dane synchronizują się, a początkowy klaster już jest uruchomiony.
Zaleca się uruchamianie od trzech do siedmiu egzemplarzy w trybie serwera. Jest to uzasadnione tym, że jeśli liczba serwerów wzrasta, to wydłuża się czas synchronizacji informacji między nimi. Liczba węzłów powinna być nieparzysta, aby zapewnić quorum.
Jak zapewniane są Health Checks? W katalogu do konfiguracji Consul zapisujemy w formacie Json zasady sprawdzania. Pierwsza opcja to dostępność w tym przykładzie domeny google.com. I mówimy, że co 30 sekund należy wykonywać to sprawdzenie. W ten sposób sprawdzamy, czy nasz węzeł ma dostęp do sieci zewnętrznej.
Druga opcja to sprawdzanie samego siebie. Używamy zwykłego curl, aby zapytać localhost na wskazanym porcie co 10 sekund.
Te kontrole są sumowane i trafiają do Service Discovery. Na podstawie dostępności te węzły są albo wykluczane, albo pojawiają się na liście dostępnych i poprawnie działających maszyn.
Consul udostępnia także interfejs UI, który z oddzielną flagą uruchamia się i będzie dostępny na maszynie. Umożliwia to przeglądanie informacji oraz wprowadzanie niektórych zmian.
W tym przykładzie otwarta jest zakładka "Usługa". Pokazuje, że uruchomione są trzy usługi, z czego jedna to Consul. Liczba przeprowadzonych kontroli. I są trzy centra danych, w których znajdują się maszyny.
To jest przykładowa zakładka „Węzły”. Widzimy, że mają złożone nazwy związane z centrum danych. Pokazuje to również, jakie usługi są uruchomione, tj. widzimy, że tagi nie są ustawione. W tych dodatkowych tagach można podać jakąś informację, którą programista może wykorzystać do określenia dodatkowych parametrów.
Można również przesyłać informacje do Consul o stanie dysków, o średnim obciążeniu.
Pytania
Pytanie: Mamy kontener dockerowy, jak go użyć z Consul?
Odpowiedź: Dla kontenera dockerowego jest kilka podejść. Jednym z najczęstszych jest użycie zewnętrznego kontenera dockerowego, który odpowiada za rejestrację. Podczas uruchamiania przekazuje się mu gniazdo dockera. Wszystkie zdarzenia dotyczące rejestracji i dejestracji kontenera są zapisywane w Consul.
Pytanie: Tzn. Consul sam uruchamia kontener dockerowy?
Odpowiedź: Nie. My uruchamiamy kontener dockerowy. I w konfiguracji wskazujemy – słuchaj tego gniazda. To mniej więcej tak, jak działa praca z certyfikatem, kiedy przekazujemy informacje, gdzie i co mamy.
Pytanie: Czyli w kontenerze dockerowym, który próbujemy podłączyć do Odkrywania Usług, powinna być jakaś logika, która potrafi zwracać dane do Consul?
Odpowiedź: Nie do końca. Kiedy się uruchamia, za pomocą zmiennych środowiskowych przekazujemy zmienne. Powiedzmy, nazwa usługi, port usługi. W rejestrze odbierają te informacje i zapisują w Consul.
Pytanie: Mam jeszcze pytanie o UI. Rozwinęliśmy UI, powiedzmy, na serwerze produkcyjnym. Co z bezpieczeństwem? Gdzie są przechowywane dane? Czy można jakoś akumulować dane?
Odpowiedź: W UI dane pochodzą z bazy i z Odkrywania Usług. Hasła ustawiamy w ustawieniach samodzielnie.
Pytanie: Czy można to publikować w internecie?
Odpowiedź: Domyślnie Consul startuje na localhost. Aby publikować to w internecie, trzeba będzie postawić jakiś proxy. Za zasady bezpieczeństwa odpowiadamy sami.
Pytanie: Czy dane historyczne są wydawane od razu? Interesuje mnie, aby zobaczyć statystyki dotyczące Health Checks. Można przecież diagnozować problemy, jeśli serwer często się wyłącza.
Odpowiedź: Nie jestem pewien, czy są tam szczegóły kontroli.
Pytanie: Nie tak ważny jest aktualny stan, co ważna jest dynamika.
Odpowiedź: Do analizy – tak.
Pytanie: Czy Odkrywanie Usług dla dockera w Consul lepiej nie używać?
Odpowiedź: Nie polecałbym go używać. Celem referatu jest zapoznanie z pojęciem. Historycznie przeszedł, moim zdaniem, do wersji 1.0. Teraz istnieją już bardziej zaawansowane rozwiązania, takie jak Kubernetes, które mają to wszystko w zanadrzu. W przypadku Kubernetes Service Discovery ustępuje Etcd. Jednak nie znam go tak dobrze, jak Consul. Dlatego Service Discovery postanowiłem przedstawić na przykładzie Consul.
Pytanie: Schemat z serwerem liderem nie spowalnia startu aplikacji w ogóle? Jak Consul określa nowego lidera, jeśli dzisiejszy jest niedostępny?
Odpowiedź: Opisano cały protokół. Jeśli to interesujące, można poczytać.
Pytanie: Consul działa jako pełnoprawny serwer i wszystkie zapytania przechodzą przez niego?
Odpowiedź: Nie pełni roli pełnoprawnego serwera, a zajmuje określoną strefę. Kończy się ona zazwyczaj na service.consul. A dalej idziemy już według logiki. Nie używamy w produkcji nazw domenowych, a właśnie wewnętrzną infrastrukturę, która zazwyczaj jest ukryta za serwerem buforującym, jeśli pracujemy w DNS.
Pytanie: Tzn. jeśli chcemy odwołać się do bazy danych, to w każdym przypadku będziemy musieli najpierw zwrócić się do Consul, aby znaleźć tę bazę, prawda?
Odpowiedź: Tak. Jeśli działamy w DNS, to działa bez Consul, gdy używamy nazw DNS. Zazwyczaj nowoczesne aplikacje nie wywołują nazwy domenowej w każdym zapytaniu, ponieważ nawiązałyśmy połączenie, wszystko działa i w najbliższym czasie praktycznie tego nie używamy. Jeśli połączenie zostanie zerwane, to tak, ponownie pytamy, gdzie znajdujemy bazę i idziemy do niej.
— Czat użytkowników Hashicorp: Consul, Nomad, Terraform
P.S. W sprawie health checks. W Consul, tak jak w Kubernetes, używa się tego samego systemu sprawdzania stanu żywotności usługi na podstawie kodu statusu.
200 OK dla zdrowych
503 Service Unavailable dla chorychŹródła:
Źródło: habr.com
