„Nebezpečí je moje druhé jméno,“ říkal Austin Powers, muž s mezinárodním tajemstvím. To, co je vysoce ceněno superagenty a tajnými službami, se však pro počítačové služby vůbec nehodí, kde je nuda mnohem lepší než nebezpečí.
A Istio spolu s OpenShift a Kubernetes mění nasazení mikroslužeb na skutečně nudný a předvídatelný proces – a to je skvělé. O tom a mnohém dalším si povíme ve čtvrtém a posledním příspěvku ze série o Istio.
Když je nuda to pravé
V našem případě se nuda objevuje pouze v konečné fázi, kdy zbývá jen sedět a sledovat proces. Ale k tomu je potřeba všechno předem nastavit, a zde vás čeká hodně zajímavého.
Při nasazení nové verze vašeho softwaru byste měli zvážit všechny možnosti minimalizace rizik. Práce v paralelním režimu je velmi efektivní a osvědčený způsob testování, a Istio umožňuje zapojit pro tento účel „tajnou službu“ (skrytou verzi vašeho mikroservisu bez zásahu do fungování produkčního systému). K tomu existuje dokonce speciální termín – „Tajné spuštění“ (Dark Launch), které se aktivuje funkcí s neméně špehovským názvem „zrcadlení provozu“.
Všimněte si, že v první větě předchozího odstavce se používá termín „nasazení“ (deploy), a ne „spuštění“ (release). Opravu byste měli mít možnost nasazovat – a samozřejmě používat – svůj mikroslužbu tak často, jak budete chtít. Tento služba by měla být schopna přijímat a zpracovávat provoz, vystavovat výsledky a také zapisovat do logů a monitorovat. Ale sama o sobě nemusí být tato služba nutně uvolněna do produkce. Nasazení a uvolnění softwaru nejsou vždy totéž. Nasazení můžete provádět vždy, když chcete, ale uvolnění – jen tehdy, když budete zcela připraveni.
Organizace nudy je zajímavá
Podívejte se na následující pravidlo směrování Istio, které směruje všechny HTTP požadavky na mikroslužbu recommendation v1 (všechny příklady jsou z ), zároveň je zrcadlí na mikroslužbu recommendation v2:
Všimněte si značky mirror: na spodní části obrazovky – právě ona určuje zrcadlení provozu. Ano, tak jednoduše!
Výsledkem tohoto pravidla bude to, že váš produkční systém (v1) nadále zpracovává příchozí dotazy, ale tyto dotazy budou asynchronně zrcadleny na v2, což znamená, že tam budou odesílány jejich plné duplikáty. Tímto způsobem budete moci testovat výkon v2 v reálných podmínkách – na skutečných datech a provozu – aniž byste zasahovali do činnosti produkčního systému. Převádí to testovací organizaci na nudnou činnost? Ano, bezpochyby. Ale dělá se to zajímavě.
Přidáme dramatično
Všimněte si, že v kódu v2 je třeba zohlednit situace, kdy příchozí dotazy mohou vést k změně dat. Samotné dotazy se zrcadlí snadno a průhledně, ale způsob zpracování v testovací verzi je na vás – a to už je trochu vzrušující.
Opakujme důležitý bod
Tajný start se zrcadlením provozu (Dark Launch/Request Mirroring) lze provádět, aniž by to jakkoli ovlivnilo kód.
Podnět k zamyšlení
A co když místo zrcadlení dotazů posílat část z nich nikoli na v1, ale na v2? Například jedno procento všech dotazů nebo pouze dotazy od určité skupiny uživatelů. A pak, při pohledu na to, jak funguje v2, postupně převést na novou verzi všechny dotazy. Nebo naopak vrátit vše na v1, pokud něco nepůjde u v2 podle plánu. Zdá se, že se tomu říká Canary Deployment („kanárové nasazení“ – termín , a pokud by měl ruský původ, pravděpodobně by obsahoval odkaz na ), a nyní se na to podíváme podrobněji.
Canary Deployment v Istio: usnadňujeme uvedení do provozu
Ostro a postupně
Podstata modelu Canary Deployment je velmi jednoduchá: při spuštění nové verze vašeho softwaru (v našem případě – mikroslužby) nejprve umožníte přístup malé skupině uživatelů. Pokud vše probíhá normálně, postupně tuto skupinu zvyšujete, dokud nová verze nezačne mít problémy, nebo – pokud se tak nikdy nestane – nakonec přejdete na tuto verzi všechny uživatele. Přemýšlivě a postupně zavádějte novou verzi a kontrolovaně přepínejte uživatele na ni, abyste minimalizovali rizika a maximalizovali zpětnou vazbu.
Samozřejmě, Istio usnadňuje Canary Deployment, neboť nabízí hned několik výborných možností pro inteligentní směrování požadavků. A ano, to vše lze provést, aniž byste se dotkli vašeho zdrojového kódu.
Filtrujeme prohlížeč
Jedním z nejjednodušších kritérií pro směrování je přesměrování na základě prohlížeče. Představte si, že chcete, aby na v2 odcházely pouze požadavky z prohlížeče Safari. Takhle to uděláte:
Aplikujeme toto pravidlo směrování a pak příkazem curl budeme v cyklu simulovat skutečné požadavky na mikroslužbu. Jak je vidět na obrázku, všechny odcházejí na v1:
A kde je provoz na v2? Protože v našem příkladu veškeré požadavky pocházely pouze z naší příkazové řádky, žádný tam prostě není. Ale věnujte pozornost dolním řádkům na obrázku nahoře: to je reakce na to, že jsme provedli požadavek z prohlížeče Safari, který vykázal toto:
Neomezená moc
Už jsme psali, že regulární výrazy nabízejí velmi silné možnosti pro směrování požadavků. Podívejte se na následující příklad (domníváme se, že chápete, co dělá):
Teď už si pravděpodobně dovedete představit, na co všechno jsou regulární výrazy schopné.
Působit chytře
Chytré směrování, zejména zpracování záhlaví paketů za použití regulárních výrazů, vám umožňuje řídit provoz podle vašich představ. A to výrazně zjednodušuje uvedení nového kódu do provozu – je to jednoduché, nevyžaduje to změnu samotného kódu a v případě potřeby lze vše rychle vrátit zpět.
Zaujalo vás to?
Máte chuť experimentovat s Istio, Kubernetes a OpenShift na svém počítači? Tým připravil skvělý na toto téma a zveřejnil všechny související soubory. Takže vpřed, a ničeho se neomezujte.
Istio Egress: výstup přes suvenýr
Používáním Istio spolu s Red Hat OpenShift a Kubernetes si můžete výrazně usnadnit život s mikroslužbami. Služební síť Istio je ukryta uvnitř podů Kubernetes, a váš kód se provádí (většinou) isolovaně. Výkon, snadnost změny, trasování a další – to vše je snadno použitelné právě díky využití sidecar kontejnerů. Ale co dělat, když váš mikroslužba musí komunikovat s jinými službami, které se nacházejí za hranicemi vašeho systému OpenShift-Kubernetes?
Zde přichází na pomoc Istio Egress. Stručně řečeno, umožňuje přístup k prostředkům (jinými slovy: „službám”), které nejsou součástí vašich podů Kubernetes. Pokud se neprovádí žádné dodatečné nastavení, v prostředí Istio Egress je provoz směrován pouze uvnitř clusteru podů a mezi takovými clustry na základě interních IP tabulek. A takové omezení funguje skvěle, dokud nepotřebujete přístup k službám zvenčí.
Egress umožňuje obejít výše uvedené IP tabulky, buď na základě pravidel Egress, nebo pro rozsah IP adres.
Představme si, že máme Java program, který provádí GET požadavek na httpbin.org/headers.
(httpbin.org je jen pohodlný prostředek pro testování odchozích služeb.)
Pokud zadáme do příkazového řádku curl http://httpbin.org/headers, uvidíme následující:
Nebo lze otevřít tuto adresu v prohlížeči:
Jak vidíme, nacházející se služba jednoduše vrací předané jí hlavičky.
Importujeme bez obalu
Nyní vezmeme Java kód této externí služby k naší systému a spustíme ji u sebe, kde, připomínáme, běží Istio. (Můžete to udělat sami, s odkazem na .) Po sestavení odpovídajícího obrazu a spuštění na platformě OpenShift vyvoláme tuto službu příkazem curl egresshttpbin-istioegress.$(minishift ip).nip.io, po čemž na obrazovce uvidíme toto:
Co se stalo? Před chvílí to fungovalo. Co znamená Not Found? Vždyť jsme pro něj právě udělali curl.
Rozšiřujeme IP tabulky na celý internet
Za to může (nebo má být vděčný) Istio. Vždyť Istio jsou jen sidecar kontejnery, které odpovídají za objevování a směrování (a za řadu dalších věcí, o kterých jsme mluvili dříve). Z tohoto důvodu tabulky IP vědí pouze o tom, co se nachází uvnitř vašeho clusteru. A httpbin.org se nachází zvenčí a tudíž není dostupný. A zde přichází Istio Egress – bez jakýchkoliv změn ve vašem zdrojovém kódu.
Následující pravidlo Egress nutí Istio hledat (pokud je to nutné, tak i po celém internetu) potřebnou službu, v tomto případě httpbin.org. Jak je vidět z tohoto souboru (egress_httpbin.yml), funkčnost zde je docela jednoduchá:
Stačí pouze aplikovat toto pravidlo:
istioctl create -f egress_httpbin.yml -n istioegress
Pravidla Egress lze zobrazit příkazem istioctl get egressrules:
A nakonec znovu spouštíme příkaz curl – a vidíme, že vše funguje:
Myslíme otevřeně
Jak vidíte, Istio umožňuje organizovat interakci i s vnějším světem. Jinými slovy, můžete stále vytvářet služby OpenShift a řídit je přes Kubernetes, přičemž vše držíte v podech, které se podle potřeby škálují nahoru a dolů. A zároveň můžete bez obav přistupovat k externím službám vzhledem k vašemu prostředí. A ano, ještě jednou opakujeme, že to vše můžete dělat, aniž byste se dotýkali svého kódu.
To byl poslední příspěvek z série o Istio. Zůstaňte s námi – čeká vás spousta zajímavého!
Zdroj: habr.com
