Navrhuji, abyste se seznámili s přepisem zprávy Alexandra Sigačeva Service Discovery v distribuovaných systémech na příkladu Consul.
Služba Discovery byla vytvořena tak, abyste s minimálními náklady mohli připojit novou aplikaci k našemu stávajícímu prostředí. Pomocí Service Discovery dokážeme maximálně oddělit buď kontejner v podobě dockeru, nebo virtuální službu od prostředí, ve kterém běží.
Všechny vítám! Jsem Alexander Sigachev a pracuji pro Inventos. A dnes vám představím takový koncept jako Service Discovery. Jako příklad budeme zvažovat zjišťování služeb pomocí služby Consul.
Jaké problémy řeší zjišťování služeb? Služba Discovery byla vytvořena tak, abyste s minimálními náklady mohli připojit novou aplikaci k našemu stávajícímu prostředí. Pomocí Service Discovery dokážeme maximálně oddělit buď kontejner v podobě dockeru, nebo virtuální službu od prostředí, ve kterém běží.
Jak to vypadá? V klasickém příkladu na webu se jedná o frontend, který přijímá požadavek uživatele. Poté jej směruje do backendu. V tomto příkladu tento load-balancer vyrovnává dva backendy.
Zde vidíme, že spouštíme třetí instanci aplikace. V souladu s tím se aplikace při spuštění zaregistruje ve službě Service Discovery. Služba zjišťování upozorní nástroj pro vyrovnávání zatížení. Load-balancer automaticky změní konfiguraci a nový backend je již připojen k práci. Backendy lze tedy přidávat, nebo naopak vyřazovat z práce.
Co dalšího je vhodné dělat s vyhledáváním služeb? Služba zjišťování může ukládat konfigurace nginx, certifikáty a seznam aktivních backendových serverů.
Service Discovery také umožňuje detekovat selhání, detekovat selhání. Jaká jsou možná schémata při zjištění poruch?
- Tato aplikace, kterou jsme vyvinuli, sama oznámí Service Discovery, že je stále funkční.
- Služba Discovery ze své strany dotazuje aplikaci na dostupnost.
- Nebo je použit skript nebo aplikace třetí strany, která zkontroluje dostupnost naší aplikace a upozorní Service Discovery, že je vše v pořádku a může fungovat, nebo naopak, že je vše špatné a tuto instanci aplikace je potřeba vyřadit z balancování.
Každé ze schémat lze použít v závislosti na tom, jaký software používáme. Například jsme právě začali vyvíjet nový projekt, pak můžeme snadno poskytnout schéma, kdy naše aplikace upozorní Service Discovery. Nebo se můžeme připojit, že Service Discovery kontroluje.
Pokud jsme aplikaci zdědili my nebo ji vyvinul někdo jiný, tak se zde hodí třetí možnost, kdy napíšeme handler a toto vše se nám dostane do práce automaticky.
Toto je jeden příklad. Load-balancer ve formě nginx je znovu načten. Toto je volitelný nástroj, který je dodáván s Consul. Toto je konzultační šablona. Popisujeme pravidlo. Říkáme, že používáme šablonu (Golang template engine). Když dojde k události, když se objeví upozornění, že došlo ke změnám, je to znovu vygenerováno a příkaz „reload“ je odeslán do Service Discovery. Nejjednodušší příklad je, když je nginx překonfigurován při události a restartován.
Co je Consul?
-
Za prvé je to Service Discovery.
-
Má mechanismus kontroly dostupnosti - Health Checking.
-
Má také KV Store.
-
A je založen na možnosti používat Multi Datacenter.
K čemu se to všechno dá využít? V KV Store můžeme ukládat příklady konfigurací. Kontrola stavu můžeme zkontrolovat místní servis a upozornit. Multi Datacenter se používá k tomu, aby bylo možné sestavit mapu služeb. Například Amazon má několik zón a směruje provoz tím nejoptimálnějším způsobem, aby nedocházelo ke zbytečným požadavkům mezi datovými centry, které jsou zpoplatněny odděleně od místního provozu, a mají tedy menší zpoždění.
Podívejme se trochu na pojmy, které se v Consul používají.
- Consul je služba napsaná v Go. Jednou z výhod programu Go je 1 binární soubor, který jste právě stáhli. Spouští se odkudkoli a nemáte žádné závislosti.
- Dále pomocí kláves můžeme tuto službu spustit buď v klientském režimu, nebo v režimu serveru.
- Atribut "datacenter" také umožňuje nastavit příznak, do kterého datového centra tento server patří.
- Konsensus – na základě raftového protokolu. Pokud by to někoho zajímalo, více si o tom můžete přečíst na webu Consul. Jedná se o protokol, který umožňuje určit vedoucí a určit, která data jsou považována za platná a dostupná.
- Gossip je protokol, který umožňuje komunikaci mezi uzly. Navíc je tento systém decentralizovaný. V rámci jednoho datového centra komunikují všechny uzly se svými sousedy. A podle toho se navzájem přenášejí informace o aktuálním stavu. Dá se říci, že jde o drby mezi sousedy.
- LAN Gossip – lokální výměna dat mezi sousedy v rámci stejného datového centra.
- WAN Gossip – používá se, když potřebujeme synchronizovat informace mezi dvěma datovými centry. Informace procházejí mezi uzly, které jsou označeny jako server.
- RPC - umožňuje zadávat požadavky prostřednictvím klienta na serveru.
Popis RPC. Řekněme, že Consul běží jako klient na virtuálním počítači nebo fyzickém serveru. Řešíme to lokálně. A pak místní klient požaduje informace ze serveru a synchronizuje se. Informace, v závislosti na nastavení, mohou být vydávány z místní mezipaměti nebo mohou být synchronizovány s vedoucím, s hlavním serverem.
Tato dvě schémata mají své plusy i mínusy. Pokud pracujeme s lokální cache, pak je to rychlé. Pokud pracujeme s daty uloženými na serveru, trvá to déle, ale dostáváme aktuálnější informace.
Pokud je to znázorněno graficky, pak zde je obrázek webu. Vidíme, že běží tři páni. Jeden je označen hvězdičkou jako vedoucí. V tomto příkladu jsou tři klienti, kteří spolu komunikují lokálně přes UDP/TCP. A informace mezi datovými centry se přenášejí mezi servery. Zde mezi sebou klienti lokálně interagují.
Jaké API poskytuje Consul? Za účelem získání informací má Consul dva druhy API.
Toto je DNS API. Ve výchozím nastavení běží Consul na portu 8600. Můžeme nakonfigurovat proxy server a poskytnout přístup prostřednictvím místního řešení, prostřednictvím místního DNS. Můžeme se dotazovat podle domény a získat v odpovědi informace o IP adrese.
HTTP API - nebo si můžeme vyžádat informace o konkrétní službě lokálně na portu 8500 a získat odpověď JSON, jakou IP má server, jaký hostitel, jaký port je registrován. A další informace lze předávat prostřednictvím tokenu.
Co potřebujete ke spuštění Consul?
V první volbě určíme příznak ve vývojářském režimu, že se jedná o vývojářský režim. Agent se spustí jako server. A celou funkci vykonává sám na jednom stroji. Pro první spuštění není potřeba pohodlné, rychlé a prakticky žádné další nastavení.
Druhý režim běží ve výrobě. Tady je spouštění trochu složitější. Pokud nemáme žádnou verzi konzula, pak musíme do bootstrapu uvést první stroj, tedy tento stroj, který převezme povinnosti vůdce. Zvedneme to, pak zvedneme druhou instanci serveru a předáme jí informace, kde máme master. Zvedněte třetí. Poté, co máme tři počítače v provozu, jsme na prvním počítači od spuštění bootstrapu a restartujeme jej v normálním režimu. Data jsou synchronizována a počáteční cluster je již aktivní.
Doporučuje se spouštět tři až sedm instancí v režimu serveru. To je způsobeno skutečností, že pokud počet serverů roste, zvyšuje se čas na synchronizaci informací mezi nimi. Aby bylo zajištěno kvorum, musí být počet uzlů lichý.
Jak jsou poskytovány zdravotní prohlídky? V konfiguračním adresáři Consul napíšeme ověřovací pravidlo ve tvaru Json. První možností je v tomto příkladu dostupnost domény google.com. A my říkáme, že po intervalu 30 sekund musíte tuto kontrolu provést. Zkontrolujeme tedy, že náš uzel má přístup k vnější síti.
Druhou možností je otestovat se. K vytažení localhost na zadaný port s intervalem 10 sekund používáme obvyklé curl.
Tyto kontroly jsou shrnuty a vkládány do Service Discovery. Na základě dostupnosti jsou tyto uzly buď vyloučeny, nebo se objeví v seznamu dostupných a správně fungujících strojů.
Consul také poskytuje uživatelské rozhraní, které se spouští se samostatným příznakem a bude dostupné na počítači. To vám umožní zobrazit informace a můžete také provést některé změny.
V tomto příkladu je otevřená karta Nástroje. Jsou zobrazeny tři služby spuštěné, jedna z nich je Consul. Počet provedených kontrol. A existují tři datová centra, ve kterých jsou stroje umístěny.
Toto je příklad záložky "Nodes". Vidíme, že mají složené názvy s účastí datových center. Ukazuje také, které služby běží, tj. vidíme, že nejsou nastaveny žádné značky. V těchto dalších značkách můžete nastavit některé informace, které může vývojář použít ke specifikaci dalších parametrů.
Konzulovi můžete také poslat informace o stavu disků, o průměrné zátěži.
otázky
Otázka: Máme dokovací kontejner, jak jej používat s Consul?
Odpověď: Existuje několik přístupů pro kontejner dokovacích stanic. Jedním z nejběžnějších je použití kontejneru dockeru třetí strany odpovědného za registraci. Při spuštění se do něj hodí docker socket. Všechny události pro registraci a zrušení publikování kontejneru jsou přihlášeny do Consul.
Otázka: Spouští tedy docker kontejner samotný Consul?
Odpověď: Ne. Provozujeme dokovací kontejner. A při konfiguraci určujeme - poslouchejte takovou a takovou zásuvku. To je asi stejné jako práce s certifikátem, když předáváme informace o tom, kde a co máme.
Otázka: Ukazuje se, že uvnitř kontejneru dockeru, který se snažíme připojit ke službě Service Discovery, musí být nějaká logika, která může poskytnout data konzulovi?
Odpověď: Ne přesně. Když se spustí, předáme proměnné prostředím proměnné. Řekněme název služby, port služby. Vyslechne si tyto informace v registru a zanese je do Consul.
Otázka: Mám další otázku ohledně uživatelského rozhraní. UI jsme nasadili například na produkční server. A co bezpečnost? Kde jsou data uložena? Existuje nějaký způsob, jak shromáždit data?
Odpověď: V uživatelském rozhraní pouze data z databáze a z vyhledávání služeb. Hesla si nastavujeme v nastavení sami.
Otázka: Dá se to zveřejnit na internetu?
Odpověď: Consul se standardně spouští na localhost. Chcete-li publikovat na tomto internetu, budete muset umístit nějaký druh proxy. Za bezpečnostní pravidla jsme odpovědní sami.
Otázka: Poskytuje historická data po vybalení? Je zajímavé vidět statistiky zdravotních kontrol. Můžete také diagnostikovat problémy, pokud server často selhává.
Odpověď: Nejsem si jistý, zda existují podrobnosti o kontrolách.
Otázka: Současný stav není tak důležitý, jako důležitá je dynamika.
Odpověď: Pro analýzu ano.
Otázka: Je lepší nepoužívat Service Discovery pro Consul docker?
Odpověď: Nedoporučoval bych to používat. Účelem zprávy je představit, co takový pojem je. Historicky ušel dlouhou cestu, dle mého názoru, až k 1. verzi. Nyní již existují ucelenější řešení, například Kubernetes, který má toto vše pod kapotou. Jako součást Kubernetes Service Discovery je nižší než Etcd. Ale neznám ho tak jako konzula. Proto jsem se rozhodl provést Service Discovery pomocí Consul jako příkladu.
Otázka: Zpomaluje schéma s vedoucím serveru start aplikace jako celku? A jak konzul určí nového vůdce, když tento lže?
Odpověď: Popsali celý protokol. Pokud máte zájem, můžete číst.
Otázka: Consul funguje jako plnohodnotný server a všechny požadavky přes něj létají?
Odpověď: Nechová se jako plnohodnotný server, ale zabírá určitou zónu. Obvykle to končí u service.consul. A pak jedeme logicky. V produkci nepoužíváme doménová jména, konkrétně vnitřní infrastrukturu, která je obvykle skryta za server caching, pokud pracujeme přes DNS.
Otázka: To znamená, že pokud chceme získat přístup k databázi, pak v každém případě nejprve přitáhneme konzula, aby tuto databázi našel, že?
Odpověď: Ano. Pokud pracujeme na DNS, pak to funguje jako bez Consul, když používáme DNS jména. Moderní aplikace obvykle netahají název domény v každém požadavku, protože připojení máme nainstalované, vše funguje a v blízké budoucnosti jej prakticky nepoužíváme. Pokud je spojení přerušeno, pak - ano, znovu se zeptáme, kde je naše základna a jdeme k ní.
— Chat uživatelů Hashicorp: Consul, Nomad, Terraform
PS Ohledně zdravotních kontrol. Consul, stejně jako Kubernetes, používá stejný systém pro kontrolu zdravotního stavu služby na základě stavu kódu.
200 OK for healthy
503 Service Unavailable for unhealthyZdroje:
Zdroj: www.habr.com