Doporučuji se seznámit s vyhodnocením zprávy Alexandra Sigacheva o Service Discovery v distribuovaných systémech na příkladu Consul.
Service Discovery byl vytvořen, aby bylo možné s minimálními náklady připojit novou aplikaci do již existujícího našeho prostředí. Pomocí Service Discovery můžeme maximálně oddělit buď kontejner ve formě Dockeru, nebo virtuální službu od prostředí, ve kterém je spuštěna.
Všechny vás zdravím! Jsem Alexander Sigachev, pracuji ve společnosti Inventos. Dnes vás seznámím s pojmem Service Discovery. Podíváme se na Service Discovery na příkladu Consul.
Jaké problémy Service Discovery řeší? Service Discovery byl vytvořen, aby bylo možné s minimálními náklady připojit novou aplikaci do již existujícího našeho prostředí. Pomocí Service Discovery můžeme maximálně oddělit buď kontejner ve formě Dockeru, nebo virtuální službu od prostředí, ve kterém je spuštěna.
Jak to vypadá? Na klasickém příkladu ve webu – to je frontend, který přijímá uživatelské požadavky. Dále provádí směrování na backend. V tomto příkladu – load-balancer vyvažuje na dva backendy.
Zde vidíme, že spouštíme třetí instanci aplikace. Když se aplikace spustí, registruje se v Service Discovery. Service Discovery upozorní load-balancer. Load-balancer automaticky mění svůj konfigurační soubor a již je nový backend zapojen do provozu. Takto mohou být backendy přidávány nebo naopak vylučovány z provozu.
Co dalšího lze pohodlně dělat pomocí Service Discovery? V Service Discovery mohou být uloženy konfigurace nginx, certifikáty a seznam aktivních backendových serverů.
Service Discovery také umožňuje detekovat poruchy a zjišťovat selhání. Jaké možné schémata existují při detekci selhání?
- Tato aplikace, kterou jsme vyvinuli, sama upozorňuje Service Discovery, že je stále funkční.
- Service Discovery se ze své strany dotazuje aplikaci na dostupnost.
- Nebo se používá externí skript či aplikace, která kontroluje naši aplikaci na dostupnost a uvědomuje Service Discovery, že je vše v pořádku a může pracovat, nebo naopak, že je něco špatně a je třeba tuto instanci aplikace vyloučit z vyvažování.
Každý z plánů může být aplikován v závislosti na tom, jaký software používáme. Například, pokud jsme právě začali vyvíjet nový projekt, můžeme snadno zajistit scénář, kdy naše aplikace upozorňuje Service Discovery. Nebo můžeme zapojit, že Service Discovery provádí kontrolu.
Pokud však aplikace pochází z dědictví nebo byla vyvinuta někým jiným, pak zde platí třetí možnost, kdy napíšeme zpracovatel a vše se automaticky zapojí do naší práce.
To je jeden z příkladů. Load-balancer ve formě nginx se restartuje. To je další nástroj, který je poskytován spolu s Consul. To je consul-template. Popisujeme pravidlo. Říkáme, že používáme šablonu (šablonizátor Golang). Při událostech, při notifikacích o změnách, je znovu generováno a Service Discovery dostává příkaz „reload“. Nejjednodušší příklad, kdy se při události překonfiguruje nginx a restartuje.
Co je to Consul?
Především – je to Service Discovery.
Má mechanismus kontroly dostupnosti – Health Checking.
Také má KV Store.
A jeho základní možností je použití Multi Datacenter.
K čemu vše toto lze využít? V KV Store můžeme uchovávat příklady konfigurací. Health Checking můžeme provádět kontrolu místních služeb a upozorňovat na ně. Multi Datacenter se používá k tomu, abychom mohli vytvořit mapu služeb. Například Amazon má několik zón a optimálně směruje provoz, aby nedocházelo k zbytečným dotazům mezi datovými centry, které se účtují odděleně od místního provozu a mají tedy nižší latenci.
Trochu se podíváme na termíny, které se v Consul používají.
- Consul – služba napsaná v Go. Jednou z výhod programu napsaného v Go je, že tvůrce má jeden binární soubor, který si jednoduše stáhne. Spustí ho kdekoli a nemá žádné závislosti.
- Dále pomocí klíčů můžeme spustit tuto službu buď v režimu klienta, nebo v režimu serveru.
- Také atribut „datacenter“ umožňuje nastavit příznak, k jakému datovému centru tento server patří.
- Konsensus – vychází z protokolu raft. Pokud by někoho zajímalo, může si o tom podrobněji přečíst na stránkách Consul. Je to protokol, který umožňuje určit lídra a určit, které údaje se považují za platné a dostupné.
- Gossip je protokol, který zajišťuje komunikaci mezi uzly. Tento systém je decentralizovaný. V rámci jednoho datového centra si všechny uzly vyměňují informace se sousedy, čímž si předávají aktuální stav. Lze říci, že jde o drbání mezi sousedy.
- LAN Gossip – lokální výměna dat mezi sousedy v rámci jednoho datového centra.
- WAN Gossip – používá se, když je třeba synchronizovat informace mezi dvěma datovými centry. Informace putují mezi uzly, které jsou označeny jako servery.
- RPC – umožňuje provádět dotazy z klienta na server.
Popis RPC. Představme si, že na virtuálním nebo fyzickém serveru běží Consul jako klient. Lokálně se k němu připojíme, a poté lokální klient požádá server o informace a synchronizuje se. Informace mohou být v závislosti na nastavení poskytnuty z lokálního cache, nebo může být synchronizována s vůdcem, s hlavním serverem.
Tyto dva přístupy mají jak výhody, tak nevýhody. Pokud pracujeme s lokálním cache, je to rychlé. Pokud pracujeme s daty uloženými na serveru, je to pomalejší, ale získáváme aktuálnější informace.
Pokud to znázorníme graficky, máme takový obrázek stránek. Vidíme, že běží tři hlavní uzly. Jeden je označen hvězdičkou jako vůdce. V tomto příkladu jsou tři klienti, kteří si mezi sebou vyměňují informace lokálně přes UDP/TCP. Informace mezi datovými centry se přenášejí mezi servery. Klienti spolu interagují lokálně.
Jaké API poskytuje Consul? Pro získání informací má Consul dva typy API.
To je DNS API. Consul se standardně spouští na portu 8600. Můžeme nastavit proxy pro žádost a zajistit přístup přes lokální rozlišení, přes lokální DNS. Můžeme dotazovat podle domény a obdržíme informace o IP adrese.
HTTP API – nebo můžeme lokálně na portu 8500 požádat o informace o konkrétní službě a obdržíme JSON odpověď, jakou IP má server, jaký host, jaký port je zaregistrován. A dodatečné informace mohou být předány přes token.
Co je potřeba k spuštění Consulu?
V prvním režimu uvádíme v režimu vývojáře příznak, že se jedná o vývojářský režim. Agent se spouští jako server. A veškerou funkci vykonává již samostatně na jednom stroji. Je to pohodlné, rychlé a prakticky nevyžaduje žádné další nastavení pro první spuštění.
Druhý režim – to je spuštění v produkci. Zde se spuštění mírně komplikuje. Pokud nemáme žádnou verzi konzole, musíme uvést do bootstrapu první stroj, tj. ten, který převezme odpovědnost vůdce. Zvedáme ho, poté zvedáme druhý instance serveru, předáváme mu informace, kde máme master. Třetí zvedáme. Po zvednutí tří strojů, na prvním stroji ze spuštěného bootstrapu, restartujeme ho do běžného režimu. Údaje se synchronizují a počáteční cluster je již vytvořen.
Doporučuje se spouštět od tří do sedmi instancí v režimu serveru. To je dáno tím, že pokud se počet serverů zvyšuje, zvyšuje se také čas na synchronizaci informací mezi nimi. Počet uzlů by měl být lichý, aby se zajistila kvórum.
Jak se zajišťují Health Checks? Do adresáře pro konfiguraci Consul píšeme pravidlo kontroly ve formátu JSON. První možnost – je dostupnost v tomto příkladu domény google.com. A říkáme, že s intervalem 30 sekund je třeba tuto kontrolu provádět. Tímto způsobem kontrolujeme, že naše uzel má přístup do vnější sítě.
Druhá možnost – je kontrola sebe sama. Pomocí běžného curl dotazujeme localhost na uvedeném portu s intervalem 10 sekund.
Tyto kontroly se sčítají a vstupují do Service Discovery. Na základě dostupnosti jsou tyto uzly buď vyloučeny, nebo se objevují v seznamu dostupných a správně fungujících strojů.
Také Consul poskytuje uživatelské rozhraní, které se s jedním speciálním příznakem spouští a bude dostupné na stroji. To umožňuje zobrazovat informace a také lze provádět některé změny.
V tomto příkladu je otevřená záložka „Služba“. Je zobrazena informace, že jsou spuštěny tři služby, z nichž jedna je Consul. Počet provedených kontrol. A existují tři datová centra, v nichž se nacházejí stroje.
Toto je příklad záložky „Nodes“. Vidíme, že mají složené názvy na základě datových center. Zde je také zobrazeno, jaké služby jsou spuštěny, tj. vidíme, že tagy nejsou nastaveny. V těchto dodatečných tagách lze zadat nějaké informace, které může vývojář použít pro určení dalších parametrů.
Informace o stavu disků a průměrném zatížení lze také předávat do Consulu.
Otázky
Otázka: Máme docker kontejner, jak ho použít s Consulem?
Odpověď: Pro docker kontejner existuje několik přístupů. Jedním z nejběžnějších je použít externí docker kontejner odpovědný za registraci. Při spuštění mu je předán socket dockeru. Všechny události o registraci a de publikaci kontejneru jsou zaznamenávány v Consulu.
Otázka: Tedy, Consul sám spouští docker kontejner?
Odpověď: Ne. My spouštíme docker kontejner. A při konfiguraci udáváme – poslouchej tento socket. Je to přibližně tak, jako když pracujeme se certifikátem, kdy předáváme informace o tom, kde a co máme.
Otázka: Zřejmě by uvnitř docker kontejneru, který se snažíme připojit k Service Discovery, měla být nějaká logika, která umí poskytovat data Consulu?
Odpověď: Ne úplně. Když se spustí, předáváme proměnné prostředí. Například, název služby, port služby. Registr je poslouchá a zaznamenává do Consulu.
Otázka: Mám ještě otázku ohledně UI. Nasadili jsme UI, řekněme, na produkčním serveru. Jak to je s bezpečností? Kde se ukládají data? Můžeme nějak kumulovat data?
Odpověď: V UI jsou právě data z databáze a ze Service Discovery. Hesla nastavujeme v nastavení sami.
Otázka: Lze to publikovat na internetu?
Odpověď: Ve výchozím stavu Consul startuje na localhost. Abychom to publikovali na internet, bude potřeba nasadit nějaký proxy. Za bezpečnostní pravidla odpovídáme sami.
Otázka: Poskytuje historická data standardně? Zajímavé by bylo podívat se na statistiku Health Checks. Lze diagnostikovat problémy, pokud server často selhává.
Odpověď: Nejsem si jist, že tam jsou detaily kontrol.
Otázka: Není tolik důležité aktuální stav, jako důležitá dynamika.
Odpověď: Pro analýzu – ano.
Otázka: Je lepší nepoužívat Service Discovery pro docker s Consulem?
Odpověď: Nedoporučoval bych ho používat. Cílem zprávy je představit, co tento pojem znamená. Historicky ušel cestu, myslím, až k první verzi. Nyní již existují plnohodnotnější řešení, například Kubernetes, které to všechno má pod kapotou. V rámci Kubernetes Service Discovery ustupuje Etcd. Ale neznám ho tak podrobně jako Consul. Proto jsem se rozhodl ukázat Service Discovery na příkladu Consul.
Otázka: Schéma s lídrem serveru nezpůsobuje zpoždění při spuštění aplikace celkově? A jak Consul určuje nového lídra, pokud ten původní selže?
Odpověď: Mají popsán celý protokol. Pokud máte zájem, můžete si to přečíst.
Otázka: Consul u nás funguje jako plnohodnotný server a všechny požadavky procházejí přes něj?
Odpověď: Nepůsobí jako plnohodnotný server, ale pokrývá určitou oblast. Ta většinou končí service.consul. A dále už postupujeme logicky. V produkci nepoužíváme doménová jména, ale interní infrastrukturu, která se obvykle skrývá za kešováním serveru, pokud pracujeme s DNS.
Otázka: Tedy, pokud se chceme obrátit na databázi, budeme v každém případě muset zavolat Consul, abychom tuto databázi nejprve našli, že?
Odpověď: Ano. Pokud pracujeme s DNS, funguje to stejně jako bez Consul, když používáme DNS jména. Obvykle moderní aplikace nevytvářejí dotazy na doménová jména v každém požadavku, protože jsme navázali spojení, všechno funguje, a v blízké době to téměř nepoužíváme. Pokud se spojení rozpadne, pak – ano, znovu se ptáme, kde máme databázi a jdeme k ní.
— Chat uživatelů Hashicorp: Consul, Nomad, Terraform
P.S. Co se týče health checks. V Consul i v Kubernetes se používá stejný systém kontroly stavu živosti služby na základě status kódu.
200 OK pro zdravý
503 Service Unavailable pro nezdravýZdroje:
Zdroj: habr.com
