Javaslom, hogy ismerkedjen meg Alexander Sigachev Service Discovery szövegének magyarázatával a Consul példáján keresztül.
A Service Discovery célja, hogy minimális költségekkel csatlakoztathassa az új alkalmazást a meglévő környezetünkhöz. A Service Discovery használatával maximálisan elválaszthatjuk a konténert, mint például a dockert, vagy a virtuális szolgáltatást attól a környezettől, amelyben fut.
Mindenkit üdvözlök! Sigachev Alexander vagyok, az Inventos cég munkatársa. Ma bemutatom önöknek a Service Discovery fogalmát. A Service Discovery-t a Consul példáján fogjuk áttekinteni.
Milyen problémákat old meg a Service Discovery? A Service Discovery célja, hogy minimális költségekkel csatlakoztathassa az új alkalmazást a meglévő környezetünkhöz. A Service Discovery használatával maximálisan elválaszthatjuk a konténert, mint például a dockert, vagy a virtuális szolgáltatást attól a környezettől, amelyben fut.
Hogyan néz ki ez? Egy klasszikus példa a webben – a frontend, amely fogadja a felhasználói kéréseket. Ezt követően végrehajtja a kérés irányítását a backend felé. Ebben a példában a load-balancer két backend között egyensúlyoz.
Itt láthatjuk, hogy elindítunk egy harmadik példányt az alkalmazásból. Amikor az alkalmazás elindul, regisztrálja magát a Service Discovery-ben. A Service Discovery értesíti a load-balancert. A load-balancer automatikusan megváltoztatja a konfigurációját, és az új backend már részt vesz a munkában. Így backend-ek adhatók hozzá, vagy éppen ellenkezőleg, ki is vonhatók a munkából.
Milyen egyéb hasznos dolgot lehet tenni a Service Discovery segítségével? A Service Discovery-ben tárolhatók az nginx konfigurációk, tanúsítványok és az aktív backend szerverek listája.
A Service Discovery lehetővé teszi a hibák észlelését, a meghibásodások azonosítását. Milyen lehetséges sémák léteznek a hibák észlelésére?
- Ez az alkalmazás, amelyet fejlesztettünk, önállóan értesíti a Service Discovery-t, hogy még mindig működőképes.
- A Service Discovery a maga részéről megkérdezi az alkalmazást a hozzáférhetőségről.
- Vagy használható egy külső szkript vagy alkalmazás, amely ellenőrzi az alkalmazásunk elérhetőségét, és értesíti a Service Discovery-t, hogy minden rendben van, és működhetünk, vagy éppen ellenkezőleg, hogy minden rossz, és ezt a példányt ki kell zárni a terheléselosztásból.
Minden egyes séma alkalmazható attól függően, hogy milyen szoftvert használunk. Például, ha most kezdtük el egy új projekt fejlesztését, akkor könnyedén biztosíthatjuk azt a sémát, amikor az alkalmazásunk értesíti a Service Discovery-t. Vagy csatlakozhatunk ahhoz, hogy a Service Discovery ellenőrzést végez.
Ha az alkalmazás örökségként maradt ránk, vagy valaki más fejlesztette, akkor itt a harmadik lehetőség jön szóba, amikor írunk egy kezelőt, és ez automatikusan integrálódik a munkánkba.
Ez az egyik példa. Az nginx alapú terheléskiegyenlítő újraindul. Ez egy további segédprogram, amely a Consul-lal együtt érkezik. Ez a consul-template. Leírunk egy szabályt. Megmondjuk, hogy használunk egy sablont (Golang sablonkezelő). Események bekövetkeztekor, amikor változások történnek, ez újragenerálódik, és a Service Discovery kap egy 'reload' parancsot. Egyszerű példa, amikor az nginx újrakonfigurálódik és újraindul egy esemény hatására.
Mi az a Consul?
Elsősorban – ez a Service Discovery.
Ez rendelkezik egy elérhetőségi ellenőrző mechanizmussal – Health Checking.
Továbbá van KV Store-ja.
Alapvetően beépítve van a Multi Datacenter használatának lehetősége.
Mire használható mindez? A KV Store-ban tárolhatunk példákat a konfigurációkról. A Health Checking segítségével ellenőrizhetjük a helyi szolgáltatást és értesíthetjük a változásokról. A Multi Datacenter arra szolgál, hogy egy szolgáltatáskartát építhessünk fel. Például az Amazon több zóna kínálattal rendelkezik, és a forgalmat optimalizálja, hogy elkerülje a felesleges kéréseket a data center-ek között, amelyek külön díjat számítanak fel a helyi forgalmon kívül, így alacsonyabb késleltetést biztosítva.
Kis mélységeiben nézzük meg a Consulban használt kifejezéseket.
- A Consul egy Go nyelven írt szolgáltatás. A Go program egyik előnye – hogy csak egy bináris fájl, amit egyszerűen letölthetsz. Bármilyen helyről elindíthatod, és nincs szükséged függőségekre.
- Ezután kulcsok segítségével indíthatjuk ezt a szolgáltatást ügyfél vagy szerver módban.
- A 'datacenter' attribútum lehetőséget ad arra, hogy megjelöljük, hogy melyik adatközponthoz tartozik a szerver.
- A konszenzus a raft protokollon alapul. Ha valakit érdekel, akkor erről részletesebben olvashat a Consul webhelyén. Ez egy olyan protokoll, amely lehetővé teszi a vezető meghatározását és a valid válaszok, valamint az elérhető adatok megállapítását.
- A Gossip – ez egy protokoll, amely a csomópontok közötti interakciót biztosít. Ez a rendszer decentralizált. Egy adatközponton belül minden csomópont a szomszédaival kommunikál. Ennek megfelelően az aktuális állapotinformációt továbbítják egymás számára. Mondhatjuk, hogy ez pletyka a szomszédok között.
- LAN Gossip – helyi adatcsere a szomszédok között egy adatközpont keretein belül.
- WAN Gossip – akkor használatos, amikor szinkronizálnunk kell az információt két adatközpont között. Az információ a szerverként megjelölt csomópontok között áramlik.
- RPC – lehetővé teszi a kérések végrehajtását a kliens és a szerver között.
Az RPC leírása. Tegyük fel, hogy egy virtuális gépen vagy fizikailag egy szerveren a Consul kliensként fut. Helyben hívjuk meg. Ezt követően a helyi kliens információt kér a szervertől és szinkronizálódik. Az információ a beállításoktól függően érkezhet a helyi gyorsítótárból, vagy szinkronizálható a vezetővel, a szerver mesterével.
Ezeknek a két séma előnyei és hátrányai is vannak. Ha a helyi gyorsítótárral dolgozunk, az gyors. Ha az adatok a szerveren vannak tárolva, az lassabb, de frissebb információt kapunk.
Ha grafikus formában ábrázoljuk, akkor ez a weboldal így néz ki. Látjuk, hogy három mester fut. Az egyik csillaggal van megjelölve, mint vezető. Ebben a példában három kliens van, amelyek helyben osztanak meg információt UDP/TCP-n keresztül. Az információ az adatközpontok között a szerverek között áramlik. Itt a kliensek helyben kölcsönösen kommunikálnak.
Milyen API-t biztosít a Consul? Az információk megszerzésére a Consul kétféle API-val rendelkezik.
Ez a DNS API. Alapértelmezés szerint a Consul a 8600-as porton fut. Beállíthatjuk a kérés proxyzását, és biztosíthatjuk a helyi feloldást, a helyi DNS-en keresztül történő hozzáférést. Kérhetünk a domain alapján, és válaszként megkapjuk az IP-cím információját.
HTTP API – vagy kérhetjük helyben a 8500-as porton egy konkrét szolgáltatás információját, és JSON választ kapunk arról, hogy melyik IP-vel rendelkezik a szerver, melyik host, melyik port van regisztrálva. További információt át lehet adni tokenen keresztül.
Mi szükséges a Consul elindításához?
Az első változatban fejlesztői módban jelöljük, hogy ez a fejlesztői mód. Az Agent szerverként indul. Az összes funkciót már önállóan, egy gépen végzi el. Kényelmes, gyors, és szinte semmilyen további beállításra nincs szükség az első indításhoz.
A második mód a production indítás. Itt az indítás kicsit bonyolultabb. Ha nincs egyetlen konzolváltozatunk sem, akkor először el kell indítanunk a bootstrap első gépét, azaz azt a gépet, amely átveszi a vezető szerepét. Elindítjuk azt, majd elindítunk egy második szerverpéldányt, átadva neki az információt arról, hol található a mester. A harmadikat is elindítjuk. Miután három gépünk van, az első gépet a futó bootstrapból normál módban újraindítjuk. Az adatok szinkronizálódnak, és a kezdeti klaszter már fel van állítva.
Ajánlott három és hét példányt indítani szerver módban. Ezt az indokolja, hogy ha a szerverek száma növekszik, akkor nő az információk szinkronizálásának ideje közöttük. A csomópontok számának páratlan számúnak kell lennie a kvórum biztosítása érdekében.
Hogyan valósulnak meg az egészségügyi ellenőrzések? A Consul konfigurációs könyvtárába JSON formátumban írjuk a vizsgálati szabályt. Az első változat a google.com domain elérhetősége. Azt mondjuk, hogy 30 másodpercenként el kell végezni ezt az ellenőrzést. Ily módon ellenőrizzük, hogy a csomópontunk hozzáfér-e a külső hálózathoz.
A második változat az önellenőrzés. A localhost-ot hívjuk meg egy adott porton, 10 másodperces időközönként a curl segítségével.
Ezek az ellenőrzések összegződnek és a Szolgáltatás-felfedezésbe kerülnek. Az elérhetőségtől függően ezek a csomópontok vagy kizáródnak, vagy megjelennek az elérhető és megfelelően működő gépek listáján.
A Consul egy UI felületet is biztosít, amely külön zászlóval indítható, és elérhetővé válik a gépen. Ez lehetővé teszi az információk megtekintését, valamint néhány módosítás végrehajtását is.
Ebben a példában a „Szolgáltatás” fül van megnyitva. Látható, hogy három szolgáltatás fut, az egyik a Consul. Megjelenik az elvégzett ellenőrzések száma, és három adatközpont is látható, ahol a gépek találhatók.
Ez a „Nodes” fül példája. Láthatjuk, hogy összetett neveik vannak, amelyeket az adatközpontok hoznak létre. Itt látható az is, hogy milyen szolgáltatások futnak, tehát azt látjuk, hogy a címkék nincsenek megadva. Ezekben a kiegészítő címkékben megadhatunk néhány információt, amelyet a fejlesztő felhasználhat további paraméterek megadására.
Információt is átadhatunk a Consulnak a lemezek állapotáról és a középterhelésről.
Kérdések
Kérdés: Van egy Docker konténerünk, hogyan használhatjuk azt a Consul-lal?
Válasz: A Docker konténerhez több módszer is létezik. Az egyik legelterjedtebb, ha külső Docker konténert használunk a regisztrálásra. Indításkor a Docker socketet átadjuk neki. Minden regisztrálási és eltávolítási eseményt a Consulba rögzítünk.
Kérdés: Tehát a Consul indítja el a Docker konténert?
Válasz: Nem. Mi indítjuk el a Docker konténert. A konfigurálás során pedig megadjuk – figyelj arra a socketre. Ez körülbelül olyan, mint a tanúsítvánnyal végzett munka, amikor átadunk információkat arról, hogy hol és mi található.
Kérdés: Tehát a Docker konténeren, amelyet csatlakoztatni próbálunk a Service Discovery-hoz, kell lennie valamilyen logikának, amely képes adatokat szolgáltatni a Consulnak?
Válasz: Nem egészen. Amikor elindul, akkor környezeti változókon keresztül átadunk változókat. Például a szolgáltatás neve, szolgáltatás portja. A regiszter figyeli ezeket az információkat és rögzíti a Consulban.
Kérdés: Még egy kérdésem lenne a UI-ról. Telepítettük a UI-t, mondjuk, a produkciós szerveren. Mi a helyzet a biztonsággal? Hol vannak az adatok? Lehet-e valahogy összegyűjteni az adatokat?
Válasz: A UI éppen az adatbázisból és a Service Discovery-ból származik. A jelszavakat saját magunk állítjuk be a beállításokban.
Kérdés: Ezt lehet közzétenni az interneten?
Válasz: Alapértelmezés szerint a Consul a localhoston indul. Ahhoz, hogy az interneten közzétegyük, szükség lesz egy proxy beállítására. A biztonsági szabályokért mi vagyunk a felelősek.
Kérdés: Történeti adatokat alapértelmezés szerint szolgáltat? Érdekes lenne megnézni a Health Checks statisztikáit. Diagnosztizálhatók a problémák, ha a szerver gyakran meghibásodik.
Válasz: Nem vagyok biztos benne, hogy ott vannak a részletek a ellenőrzésekről.
Kérdés: Nem olyan fontos a jelenlegi állapot, mint a dinamika.
Válasz: Az elemzéshez – igen.
Kérdés: A Dockerhez a Consul Service Discovery-t jobb nem használni?
Válasz: Nem javaslom a használatát. A beszámoló célja, hogy megismertesse, mi is az a fogalom. Történelmileg 1. verziójáig jutott el, azt hiszem. Most már léteznek átfogóbb megoldások, például a Kubernetes, amely mindezt a háttérben kezeli. A Kubernetes Service Discovery a Etcd-nek alárendelt. De nem ismerem annyira, mint a Consul-t. Ezért a Service Discovery-t a Consul példájával szerettem volna bemutatni.
Kérdés: A vezető szerverrel kialakított séma nem késlelteti az alkalmazás indítását? Hogyan határozza meg a Consul az új vezetőt, ha az elérhetetlen?
Válasz: Van egy jól leírt protokolljuk. Ha érdekli, elolvashatja.
Kérdés: A Consul teljes értékű szerverként működik, és minden kérés rajta keresztül zajlik?
Válasz: Nem teljes értékű szerverként működik, hanem egy meghatározott zónát fed le. Ez általában service.consul-zal végződik. Innentől kezdve a logika szerint haladunk. Production környezetben nem használunk domain neveket, hanem kizárólag a belső infrastruktúrát, ami általában a szerver cache-én keresztül rejtőzik el, ha DNS-t használunk.
Kérdés: Tehát, ha az adatbázishoz szeretnénk hozzáférni, akkor mindenképpen a Consul-t kell megkeresnünk, hogy először megtaláljuk azt, igaz?
Válasz: Igen. Ha DNS-en dolgozunk, ez úgy működik, mint a Consul nélkül, amikor DNS neveket használunk. A modern alkalmazások általában nem küldenek minden kéréskor domain nevet, mert az összeköttetést már létrehoztuk, és ez a következő időszakban szinte soha nem használatos. Ha az összeköttetés megszakad, akkor igen, újra megkérdezzük, hol található az adatbázis, és odamegyünk.
— Hashicorp felhasználói chat: Consul, Nomad, Terraform
P.S. Az állapotellenőrzésekről. A Consul-ban, akárcsak a Kubernetes-ben, azonos rendszer használatos a szolgáltatás élőképességének ellenőrzésére, a státuszkód alapján.
200 OK az egészséges
503 Szolgáltatás nem elérhető az egészségtelenhezForrások:
Forrás: habr.com
