Navrhujem, aby ste si prečítali prepis správy Alexandra Sigačeva Objavenie služby v distribuovaných systémoch, pričom ako príklad použite službu Consul.
Služba Discovery bola vytvorená, aby ste mohli pripojiť novú aplikáciu k nášmu existujúcemu prostrediu s minimálnymi nákladmi. Pomocou Service Discovery dokážeme maximálne oddeliť či už docker kontajner alebo virtuálnu službu od prostredia, v ktorom beží.
Vítam všetkých! Som Alexander Sigachev a pracujem v Inventose. A dnes vám predstavím taký koncept ako Service Discovery. Pozrime sa na Service Discovery pomocou Consul ako príklad.
Aké problémy rieši Service Discovery? Služba Discovery bola vytvorená, aby ste mohli pripojiť novú aplikáciu k nášmu existujúcemu prostrediu s minimálnymi nákladmi. Pomocou Service Discovery dokážeme maximálne oddeliť či už docker kontajner alebo virtuálnu službu od prostredia, v ktorom beží.
Ako to vyzerá? V klasickom príklade na webe ide o klientske rozhranie, ktoré prijíma požiadavku používateľa. Potom ho nasmeruje do backendu. V tomto príklade tento vyvažovač záťaže vyvažuje dva koncové servery.
Tu vidíme, že spúšťame tretiu inštanciu aplikácie. Preto sa aplikácia pri spustení zaregistruje v službe Service Discovery. Služba Discovery upozorní nástroj na vyrovnávanie zaťaženia. Load-balancer automaticky zmení svoju konfiguráciu a nový backend sa uvedie do prevádzky. Takto sa dajú backendy pridávať, alebo naopak vyraďovať z práce.
Čo ešte je vhodné robiť s vyhľadávaním služby? Služba zisťovanie môže ukladať konfigurácie nginx, certifikáty a zoznam aktívnych backendových serverov.
Service Discovery vám tiež umožňuje odhaliť zlyhania a odhaliť zlyhania. Aké sú možné schémy zisťovania porúch?
- Táto aplikácia, ktorú sme vyvinuli, automaticky upozorní Service Discovery, že je stále funkčná.
- Služba Discovery zo svojej strany zisťuje dostupnosť aplikácie.
- Alebo použijeme skript alebo aplikáciu tretej strany, ktorá skontroluje dostupnosť našej aplikácie a upozorní Service Discovery, že je všetko v poriadku a môže fungovať, alebo naopak, že je všetko zlé a túto inštanciu aplikácie je potrebné vylúčiť z bilancovania.
Každá zo schém môže byť použitá v závislosti od toho, aký softvér používame. Napríklad sme práve začali vyvíjať nový projekt, potom môžeme jednoducho poskytnúť schému, keď naša aplikácia upozorní Service Discovery. Alebo môžeme pripojiť, že Service Discovery kontroluje.
Ak sme aplikáciu zdedili alebo bola vyvinutá niekým iným, potom je vhodná tretia možnosť, keď si napíšeme handler a toto všetko nám príde do práce automaticky.
Toto je jeden príklad. Load-balancer vo forme nginx sa reštartuje. Toto je voliteľný nástroj, ktorý sa dodáva s Consul. Toto je konzultačná šablóna. Opisujeme pravidlo. Hovoríme, že používame šablónu (Golang Template Engine). Keď sa vyskytnú udalosti, keď sa vyskytnú upozornenia, že sa vyskytli zmeny, vygeneruje sa a príkaz „reload“ sa odošle do Service Discovery. Najjednoduchší príklad je, keď je nginx prekonfigurovaný udalosťou a reštartovaný.
Čo je Consul?
V prvom rade ide o vyhľadávanie služieb.
Má mechanizmus kontroly dostupnosti – Health Checking.
Má aj obchod KV.
A je založená na možnosti používať Multi Datacenter.
Na čo všetko sa to dá využiť? V obchode KV Store môžeme ukladať príklady konfigurácií. Kontrola stavu môžeme skontrolovať miestnu službu a upozorniť. Multi Datacenter sa používa na vytvorenie mapy služieb. Napríklad Amazon má niekoľko zón a nasmeruje premávku tým najoptimálnejším spôsobom, aby nevznikali zbytočné požiadavky medzi dátovými centrami, ktoré sú spoplatňované oddelene od lokálnej prevádzky, a teda majú menšiu latenciu.
Poďme trochu pochopiť pojmy, ktoré sa používajú v Consul.
- Consul je služba napísaná v Go. Jednou z výhod programu Go je 1 binárny súbor, ktorý si len stiahnete. Spustené odkiaľkoľvek a nemáte žiadne závislosti.
- Potom pomocou kľúčov môžeme spustiť túto službu buď v režime klienta alebo v režime servera.
- Atribút „datacenter“ vám tiež umožňuje nastaviť príznak, do ktorého dátového centra tento server patrí.
- Konsenzus – na základe raftového protokolu. Ak by to niekoho zaujímalo, viac si o tom môžete prečítať na stránke Consul. Toto je protokol, ktorý vám umožňuje určiť vodcu a určiť, ktoré peniaze sa považujú za platné a dostupné.
- Gossip je protokol, ktorý umožňuje interakciu medzi uzlami. Tento systém je navyše decentralizovaný. V rámci jedného dátového centra komunikujú všetky uzly so svojimi susedmi. A podľa toho sa navzájom prenášajú informácie o aktuálnom stave. Môžeme povedať, že ide o klebety medzi susedmi.
- LAN Gossip – lokálna výmena dát medzi susedmi v rámci toho istého dátového centra.
- WAN Gossip – používa sa, keď potrebujeme synchronizovať informácie medzi dvoma dátovými centrami. Informácie prechádzajú medzi uzlami, ktoré sú označené ako server.
- RPC – umožňuje vykonávať požiadavky prostredníctvom klienta na serveri.
Popis RPC. Povedzme, že Consul beží ako klient na virtuálnom počítači alebo fyzickom serveri. Kontaktujeme ho lokálne. A potom lokálny klient požaduje informácie zo servera a je synchronizovaný. V závislosti od nastavení je možné informácie získať z lokálnej vyrovnávacej pamäte alebo ich možno synchronizovať s vedúcim servera s hlavným serverom.
Tieto dve schémy majú klady aj zápory. Ak pracujeme s lokálnou cache, tak je to rýchle. Ak pracujeme s údajmi, ktoré sú uložené na serveri, trvá to dlhšie, ale získame relevantnejšie informácie.
Ak to znázorníte graficky, potom je to obrázok stránky. Vidíme, že nám bežia traja páni. Jeden je označený hviezdičkou ako vedúci. V tomto príklade sú traja klienti, ktorí si medzi sebou vymieňajú informácie lokálne cez UDP/TCP. A informácie medzi dátovými centrami sa prenášajú medzi servermi. Klienti tu interagujú medzi sebou lokálne.
Aké API poskytuje Consul? Na získanie informácií má Consul dva typy API.
Toto je DNS API. V predvolenom nastavení Consul beží na porte 8600. Môžeme nakonfigurovať proxy server a poskytnúť prístup cez lokálne rozlíšenie, cez lokálny DNS. Môžeme sa pýtať podľa domény a ako odpoveď dostávať informácie o IP adrese.
HTTP API - alebo si môžeme lokálne vyžiadať informácie o konkrétnej službe na porte 8500 a dostať odpoveď JSON, akú IP má server, aký hostiteľ, aký port je zaregistrovaný. A ďalšie informácie môžu byť prenášané prostredníctvom tokenu.
Čo potrebujete na spustenie služby Consul?
V prvej možnosti v režime vývojára označujeme príznak, že ide o režim vývojára. Agent sa spustí ako server. A celú funkciu vykonáva nezávisle na jednom stroji. Na prvé spustenie nie je potrebné pohodlné, rýchle a prakticky žiadne dodatočné nastavenia.
Druhým režimom je spustenie vo výrobe. Tu začína byť trochu komplikované. Ak nemáme žiadnu verziu konzula, potom musíme uviesť do bootstrapu prvý stroj, teda tento stroj, ktorý prevezme zodpovednosť vodcu. Zdvihneme ho, potom zdvihneme druhú inštanciu servera a odovzdáme mu informácie, kde sa nachádza náš master. Zvyšujeme tretieho. Keď máme tri stroje hore, reštartujeme ho v normálnom režime na prvom stroji zo spusteného bootstrapu. Údaje sú synchronizované a počiatočný klaster je už aktívny.
Odporúča sa spustiť tri až sedem inštancií v serverovom režime. Je to spôsobené tým, že ak počet serverov rastie, zvyšuje sa čas na synchronizáciu informácií medzi nimi. Počet uzlov musí byť nepárny, aby sa zabezpečilo kvórum.
Ako sa poskytujú zdravotné prehliadky? V konfiguračnom adresári Consul napíšeme overovacie pravidlo v tvare Json. Prvou možnosťou je v tomto príklade dostupnosť domény google.com. A hovoríme, že túto kontrolu je potrebné vykonávať v intervaloch 30 sekúnd. Takto skontrolujeme, či má náš uzol prístup do externej siete.
Druhou možnosťou je skontrolovať sa. Bežné curl používame na volanie localhost na špecifikovanom porte v intervaloch 10 sekúnd.
Tieto kontroly sú zhrnuté a odoslané do Service Discovery. Na základe dostupnosti sú tieto uzly buď vylúčené, alebo sa objavia v zozname dostupných a správne fungujúcich strojov.
Consul tiež poskytuje používateľské rozhranie, ktoré sa spúšťa so samostatným príznakom a bude k dispozícii na počítači. To vám umožní prezerať informácie a tiež môžete vykonať nejaké zmeny.
V tomto príklade je otvorená karta „Služba“. Ukazuje sa, že sú spustené tri služby, jedna z nich je konzul. Počet vykonaných kontrol. A existujú tri dátové centrá, v ktorých sú stroje umiestnené.
Toto je príklad karty Uzly. Vidíme, že majú zložené názvy zahŕňajúce dátové centrá. Tiež ukazuje, ktoré služby sú spustené, t.j. vidíme, že neboli nastavené žiadne značky. Tieto dodatočné značky môžu poskytnúť niektoré informácie, ktoré môže vývojár použiť na špecifikáciu ďalších parametrov.
Konzulovi môžete tiež odovzdať informácie o stave diskov a priemernom zaťažení.
otázky
Otázka: Máme dokovací kontajner, ako ho používať s Consul?
Odpoveď: Existuje niekoľko prístupov pre dokovací kontajner. Jedným z najbežnejších je použitie dokovacieho kontajnera tretej strany zodpovedného za registráciu. Pri spustení sa mu odovzdá dokovacia zásuvka. Všetky udalosti registrácie a zrušenia zverejnenia kontajnera sa zaznamenávajú v konzuláte.
Otázka: Takže samotný konzul spúšťa dokovací kontajner?
odpoveď: Nie. Prevádzkujeme dokovací kontajner. A pri konfigurácii naznačujeme - počúvajte takú a takú zásuvku. Je to približne rovnaké, ako pracujeme s certifikátom, keď nahrávame informácie o tom, kde a čo máme.
Otázka: Ukazuje sa, že v kontajneri Docker, ktorý sa pokúšame pripojiť k zisťovaniu služby, by mala existovať nejaká logika, ktorá môže odosielať údaje konzulovi?
Odpoveď: V skutočnosti nie. Keď sa spustí, prechádzame premenné cez premennú prostredia. Povedzme názov služby, port služby. Register si vypočuje tieto informácie a zadá ich konzulovi.
Otázka: Mám ďalšiu otázku týkajúcu sa používateľského rozhrania. UI sme nasadili napríklad na produkčný server. A čo bezpečnosť? Kde sú údaje uložené? Je možné nejako akumulovať dáta?
Odpoveď: V používateľskom rozhraní sú údaje z databázy a z vyhľadávania služby. Heslá si nastavujeme v nastaveniach sami.
Otázka: Dá sa to zverejniť na internete?
Odpoveď: V predvolenom nastavení sa Consul spúšťa na localhost. Ak chcete publikovať na internete, budete si musieť nainštalovať nejaký druh proxy. Sme zodpovední za naše vlastné bezpečnostné pravidlá.
Otázka: Poskytuje historické údaje hneď po vybalení? Je zaujímavé pozrieť si štatistiky o zdravotných kontrolách. Môžete tiež diagnostikovať problémy, ak server často zlyháva.
Odpoveď: Nie som si istý, či tam sú podrobnosti o kontrolách.
Otázka: Súčasný stav nie je taký dôležitý ako dynamika.
Odpoveď: Na analýzu - áno.
Otázka: Je lepšie nepoužívať vyhľadávanie služby pre dokovaciu stanicu Consul?
odpoveď: Neodporúčam to používať. Účelom správy je predstaviť, čo takýto pojem existuje. Historicky sa to prebojovalo podľa mňa až k 1. verzii. Teraz už existujú kompletnejšie riešenia, napríklad Kubernetes, ktorý má toto všetko pod kapotou. Ako súčasť Kubernetes Service Discovery je nižšia ako Etcd. Ale nie som v tom tak oboznámený ako s konzulom. Preto som sa rozhodol urobiť Service Discovery pomocou Consul ako príkladu.
Otázka: Nespomalí schéma s vedúcim serverom štart aplikácie ako celku? A ako konzul určí nového vodcu, ak tento klame?
Odpoveď: Majú popísaný celý protokol. Ak máte záujem, môžete si ho prečítať.
Otázka: Consul pre nás funguje ako plnohodnotný server a všetky požiadavky prelietavajú cez neho?
Odpoveď: Nepôsobí ako plnohodnotný server, ale preberá špecifickú zónu. Zvyčajne to končí na service.consul. A potom ideme logicky ďalej. V produkcii nepoužívame názvy domén, ale internú infraštruktúru, ktorá je zvyčajne skrytá za cachovaním servera, ak pracujeme s DNS.
Otázka: To znamená, že ak chceme získať prístup k databáze, potom v každom prípade najprv potiahneme konzula, aby túto databázu našiel, však?
Odpoveď: Áno. Ak pracujeme pomocou DNS, potom to funguje rovnako ako bez Consul, keď používame názvy DNS. Moderné aplikácie zvyčajne nevyťahujú názov domény pri každej požiadavke, pretože sme nainštalovali pripojenie, všetko funguje a v blízkej budúcnosti ho prakticky nepoužívame. Ak je spojenie prerušené, potom áno, znova sa pýtame, kde je naša základňa a ideme k nej.
— Užívateľský chat Hashicorp: Consul, Nomad, Terraform
PS Čo sa týka zdravotných kontrol. Konzul, podobne ako Kubernetes, používa rovnaký systém na kontrolu stavu prežitia služby na základe stavu kódu.
200 OK for healthy
503 Service Unavailable for unhealthyZdroje:
Zdroj: hab.com
