Consul discovery to mechanizm automatycznego odnajdywania usług w klastrze, w którym adresy IP i numery portów zmieniają się przy każdym wdrożeniu. Tam, gdzie działa kilkadziesiąt kontenerów, consul discovery zastępuje ręczne wpisy w plikach konfiguracyjnych żywym katalogiem, odświeżanym co kilka sekund. Klasyczne podejście z listą adresów w zmiennych środowiskowych przestaje działać w momencie, gdy orkiestrator przenosi kontener na inny węzeł, a stary adres wskazuje na nieistniejący proces. Katalog usług rozwiązuje ten problem w warstwie infrastruktury, bez modyfikowania kodu aplikacji i bez dopisywania logiki ponawiania zapytań do każdego serwisu z osobna. Efektem jest krótszy czas przywracania usługi po awarii, przewidywalne wdrożenia i możliwość skalowania poziomego bez ręcznej edycji plików konfiguracyjnych na każdej maszynie. Poniższy przewodnik pokazuje, jak zbudować taki katalog od podstaw: od rejestracji pojedynczej usługi, przez testy zdrowia i zapytania DNS, aż po realny rachunek za serwery oraz wyposażenie stanowiska osoby, która ten klaster utrzymuje.
Katalog usług jako fundament architektury
Sercem systemu jest rozproszony katalog, w którym każda instancja aplikacji zapisuje swoją nazwę logiczną, adres, port oraz zestaw tagów. Zamiast twardo kodować adres bazy danych w pliku środowiskowym, aplikacja pyta katalog o aktualną listę zdrowych węzłów i otrzymuje odpowiedź w kilkanaście milisekund, niezależnie od tego, ile razy dziś przewinął się deployment.
Spójność danych utrzymuje protokół Raft: zapisy trafiają do wybranego lidera, a odczyty mogą obsługiwać pozostałe serwery. Trzy serwery wystarczają małemu środowisku produkcyjnemu, pięć daje zapas na jednoczesną awarię dwóch maszyn i nadal utrzymuje kworum potrzebne do przyjmowania nowych rejestracji.
Do wykrywania awarii służy protokół plotkarski SWIM, rozsyłający informacje o stanie węzłów bez centralnego odpytywania. Ruch kontrolny rośnie wtedy logarytmicznie, a nie liniowo, więc klaster liczący dwieście maszyn generuje zaskakująco mały narzut sieciowy w porównaniu z klasycznym monitoringiem odpytującym każdy host po kolei.
Agent w trybie klienta i serwera
Na każdej maszynie działa agent w trybie klienta: przekazuje rejestracje do serwerów, wykonuje lokalne testy zdrowia i buforuje odpowiedzi. Serwery przechowują pełny stan katalogu. Ten podział sprawia, że aplikacja rozmawia zawsze z interfejsem lokalnym, co eliminuje opóźnienia sieciowe i radykalnie upraszcza reguły zapory między strefami.
Rejestracja usług i testy zdrowia
Definicja usługi to kilkanaście linii w formacie HCL lub JSON: nazwa logiczna, na przykład payments-api, port 8080, waga w puli oraz tagi opisujące wersję i region. Tagi pozwalają później filtrować wyniki zapytania, dzięki czemu ruch testowy nigdy nie trafi do instancji oznaczonej jako produkcyjna.
Test zdrowia decyduje, czy instancja pojawi się w odpowiedziach katalogu. Do wyboru są sondy HTTP, TCP, gRPC, skrypty uruchamiane lokalnie oraz mechanizm TTL, w którym to aplikacja sama zgłasza swoją sprawność. Typowa konfiguracja produkcyjna używa interwału dziesięciu sekund i limitu czasu dwóch sekund.
- Sonda HTTP — sprawdza endpoint zdrowia i oczekuje kodu z zakresu 200-299
- Sonda TCP — potwierdza wyłącznie możliwość nawiązania połączenia z portem
- Sonda gRPC — korzysta ze standardowego protokołu health checking
- TTL — instancja musi cyklicznie potwierdzać, że nadal działa poprawnie
- Skrypt lokalny — dowolna logika, na przykład kontrola opóźnienia replikacji
Parametr wyrejestrowujący usługę po dziewięćdziesięciu sekundach w stanie krytycznym porządkuje katalog po awariach sprzętowych. Bez niego lista rośnie o widmowe wpisy, a klienci tracą czas na próby połączenia z węzłami, które fizycznie już nie istnieją w centrum danych ani w chmurze.
Odpytywanie katalogu: DNS, HTTP API i szablony
Najprostszy sposób integracji to interfejs DNS. Zapytanie o nazwę payments-api.service.consul zwraca rekordy A wyłącznie dla zdrowych instancji, a rekordy SRV dodają numer portu. Aplikacja napisana w dowolnym języku korzysta wtedy ze standardowego resolvera i nie potrzebuje żadnej dedykowanej biblioteki.
Bardziej wymagające scenariusze obsługuje HTTP API, które pozwala filtrować wyniki po tagach, centrum danych i metadanych. Zapytania blokujące utrzymują otwarte połączenie do momentu zmiany w katalogu, dzięki czemu szablon konfiguracji serwera proxy przeładowuje się natychmiast po dodaniu lub usunięciu instancji.
| Metoda odpytania | Typowy czas odpowiedzi | Zastosowanie |
|---|---|---|
| Rekord DNS typu A | 1-3 ms | proste klienty bez integracji z API |
| Rekord DNS typu SRV | 1-3 ms | usługi z dynamicznie przydzielanym portem |
| HTTP API health/service | 5-15 ms | filtrowanie po tagach i stanie sondy |
| Zapytanie blokujące | zależny od zmiany | generowanie konfiguracji i przeładowanie |
| Cache lokalnego agenta | poniżej 1 ms | ruch o bardzo wysokiej częstotliwości |
Wybór metody wpływa na budżet opóźnień całej ścieżki żądania. Przy dziesięciu tysiącach zapytań na sekundę różnica między odczytem z pamięci agenta a wywołaniem API po sieci przekłada się na kilkanaście procent całkowitego czasu odpowiedzi widocznego dla użytkownika końcowego.
Koszty wdrożenia i dobór infrastruktury
Trzy serwery katalogu o parametrach dwa rdzenie i cztery gigabajty pamięci to koszt rzędu 150-250 zł miesięcznie, jeśli wybierzemy popularne maszyny wirtualne w europejskich centrach danych. Konfiguracja typu ovh vps z dyskiem NVMe wystarcza katalogowi obsługującemu kilkaset zarejestrowanych usług bez zauważalnych opóźnień zapisu.
Do rachunku trzeba doliczyć narzędzia towarzyszące zespołowi. Google workspace cena zaczyna się od kilkudziesięciu złotych za użytkownika miesięcznie, a firmowy sklep zintegrowany z google merchant wymaga osobnego feedu produktowego i regularnej walidacji. Te pozycje rzadko trafiają do kosztorysu infrastruktury, a potrafią podwoić miesięczny wydatek na małe środowisko.
Warstwa publiczna zwykle żyje obok klastra: firmowy blog, panel redakcyjny, gdzie wordpress logowanie zabezpiecza się kluczem sprzętowym, oraz landing pages powstające w ramach projektowania stron internetowych. Pozycjonowanie strony traktuje szybkość odpowiedzi jako sygnał rankingowy, więc stabilny backend przekłada się na realny efekt marketingowy.
Kiedy klaster przestaje się opłacać
Przy trzech usługach i jednym serwerze aplikacyjnym cały mechanizm generuje więcej pracy operacyjnej niż oszczędza. Próg opłacalności zaczyna się mniej więcej przy ośmiu-dziesięciu usługach albo w momencie, gdy zespół wdraża zmiany częściej niż raz dziennie i ręczne przepisywanie adresów staje się źródłem błędów.
Stanowisko pracy operatora klastra
Diagnostyka rozproszonego systemu oznacza godziny spędzone w terminalu, dlatego sprzęt wejściowy ma znaczenie praktyczne, a nie estetyczne. Dobra klawiatura mechaniczna z przełącznikami liniowymi kosztuje 350-700 zł i wytrzymuje kilkadziesiąt milionów naciśnięć, czyli realnie kilka lat intensywnego pisania skryptów i konfiguracji.
Kompaktowy układ, znany jako klawiatura mechaniczna 60 procent, zwalnia miejsce na biurku i skraca drogę dłoni do myszy, choć wymaga przyzwyczajenia się do warstw funkcyjnych. Klawiatura gamingowa mechaniczna z podświetleniem i makrami bywa wygodna przy powtarzalnych komendach, lecz jej oprogramowanie rzadko działa dobrze poza systemem Windows.
Równie ważny jest monitor do komputera o przekątnej 27 cali i rozdzielczości QHD — pozwala trzymać obok siebie logi, dashboard metryk i edytor konfiguracji bez ciągłego przełączania okien. Tablet graficzny wacom przydaje się zaś przy szkicowaniu diagramów architektury podczas wideokonferencji z zespołem.
Jak wdrożyć consul discovery w środowisku kontenerowym?
Zacznij od uruchomienia trzech serwerów katalogu w trybie bootstrap-expect ustawionym na trzy, każdy na osobnej maszynie fizycznej lub w osobnej strefie dostępności. Następnie na każdym hoście aplikacyjnym uruchom agenta w trybie klienta i podłącz go do puli serwerów przez mechanizm automatycznego dołączania. Kolejny krok to rejestracja usług — albo przez plik definicji montowany do kontenera, albo przez wywołanie API w skrypcie startowym. Skonfiguruj sondy zdrowia odpowiadające faktycznej gotowości aplikacji, a nie samemu procesowi. Na koniec przekieruj zapytania DNS z portu 8600 do lokalnego resolvera systemowego, żeby kontenery mogły odpytywać katalog standardową składnią nazw domenowych bez dodatkowych bibliotek.
Czy consul discovery opłaca się w małym projekcie?
Przy dwóch lub trzech usługach odpowiedź brzmi zwykle nie — prosty plik konfiguracyjny albo wewnętrzny load balancer załatwia sprawę mniejszym kosztem. Sytuacja zmienia się, gdy liczba serwisów przekracza osiem, wdrożenia stają się codzienne albo pojawia się drugie centrum danych. Wtedy ręczna aktualizacja adresów zaczyna generować incydenty, a katalog usług zwraca zainwestowany czas w ciągu kilku tygodni. Warto policzyć to konkretnie: jeśli zespół traci tygodniowo dwie godziny na synchronizowanie konfiguracji i debugowanie nieaktualnych adresów, roczny koszt takiej pracy przekracza wydatek na trzy dodatkowe maszyny wirtualne wraz z ich utrzymaniem.
Co odróżnia katalog usług od klasycznego load balancera?
Load balancer jest punktem, przez który przechodzi ruch, natomiast katalog usług jest źródłem informacji o tym, dokąd ten ruch skierować. Klasyczny balancer wymaga ręcznej lub półautomatycznej aktualizacji puli węzłów i sam bywa wąskim gardłem oraz pojedynczym punktem awarii. Katalog przekazuje listę zdrowych instancji bezpośrednio klientowi, który może rozłożyć obciążenie po swojej stronie, co skraca ścieżkę sieciową o jeden przeskok. W praktyce oba rozwiązania współpracują: katalog zasila konfigurację balancera przez szablony, a ten obsługuje terminację TLS, limity zapytań i reguły dla ruchu przychodzącego z zewnątrz, na przykład z kampanii, których skuteczność wspiera pozycjonowanie strony w google.
