"Nebezpečí je mé druhé jméno," říkával Austin Powers, mezinárodní záhadný muž. Jenže to, co si váží super agenti a zpravodajské služby, se vůbec nehodí do počítačových služeb, kde je nuda mnohem lepší než nebezpečí.
A díky Istio spolu s OpenShift a Kubernetes je nasazení mikroslužeb opravdu nudné a předvídatelné – a to je skvělé. O tom a mnohem více si povíme ve čtvrtém a posledním příspěvku v sérii Istio.
Když je nuda správná
U nás nastává nuda až v závěrečné fázi, kdy nezbývá než sedět a sledovat proces. K tomu je ale potřeba vše nejprve nakonfigurovat a zde na vás čeká spousta zajímavých věcí.
Při nasazování nové verze vašeho softwaru se vyplatí zvážit všechny možnosti, jak rizika minimalizovat. Paralelní běh je velmi výkonný a osvědčený způsob testování a Istio vám umožňuje použít „tajnou službu“ (skrytou verzi vaší mikroslužby), aniž byste zasahovali do produkčního systému. Existuje pro to dokonce speciální termín – „Dark Launch“, který zase aktivuje funkce se stejně špionážním názvem „traffic mirroring“.
Vezměte prosím na vědomí, že první věta předchozího odstavce používá termín „nasadit“ spíše než „uvolnit“. Měli byste být skutečně schopni nasadit – a samozřejmě používat – svou mikroslužbu tak často, jak chcete. Tato služba musí být schopna přijímat a zpracovávat provoz, produkovat výsledky a také zapisovat do protokolů a monitorovat. Ale zároveň tato služba samotná nemusí být nutně uvolněna do výroby. Nasazení a uvolnění softwaru nejsou vždy totéž. Můžete nasadit, kdykoli chcete, ale uvolněte pouze tehdy, když budete připraveni.
Organizování nudy je zajímavé
Podívejte se na následující směrovací pravidlo Istio, které směruje všechny požadavky HTTP na doporučení mikroslužby v1 (všechny příklady převzaty z ), přičemž je současně zrcadlíte do mikroslužby doporučení v2:
Dávejte pozor na štítek mirror: ve spodní části obrazovky – to je to, co nastavuje zrcadlení provozu. Ano, je to tak jednoduché!
Výsledkem tohoto pravidla bude, že váš produkční systém (v1) bude nadále zpracovávat příchozí požadavky, ale samotné požadavky budou asynchronně zrcadleny do v2, to znamená, že tam budou chodit jejich úplné duplikáty. V2 tak můžete testovat v reálných podmínkách – na reálných datech a provozu – aniž byste jakkoli zasahovali do provozu produkčního systému. Je kvůli tomu organizování testování nudné? Ano, určitě. Ale je to udělané zajímavým způsobem.
Přidáme drama
Upozorňujeme, že v kódu v2 je nutné zajistit situace, kdy příchozí požadavky mohou vést ke změnám dat. Samotné požadavky se zrcadlí snadno a transparentně, ale výběr způsobu zpracování v testu je na vás – a to je trochu znepokojivé.
Zopakujme si důležitý bod
Tajné spuštění se zrcadlením provozu (Dark Launch/Request Mirroring) lze provést bez jakéhokoli ovlivnění kódu.
K zamyšlení
Co když místo, kde jsou požadavky zrcadleny, pošle některé z nich nikoli do v1, ale do v2? Například jedno procento všech požadavků nebo pouze požadavky od určité skupiny uživatelů. A pak, když už se podíváte na to, jak v2 funguje, postupně přeneste všechny požadavky do nové verze. Nebo naopak, vraťte vše do v1, pokud se něco pokazí s v2. Myslím, že se tomu říká Canary Deployment. , a pokud by byl ruského původu, pravděpodobně by obsahoval odkaz na ), a nyní se na to podíváme podrobněji.
Canary Deployment in Istio: zjednodušení uvedení do provozu
Opatrně a postupně
Podstata modelu nasazení Canary Deployment je extrémně jednoduchá: když spustíte novou verzi svého softwaru (v našem případě mikroslužbu), nejprve k ní poskytnete přístup malé skupině uživatelů. Pokud vše půjde dobře, pomalu tuto skupinu zvětšujete, dokud nezačne fungovat nová verze, nebo – pokud ne – nakonec do ní migrujete všechny uživatele. Promyšleným a postupným zaváděním nové verze a kontrolovaným přepínáním uživatelů na ni můžete snížit rizika a maximalizovat zpětnou vazbu.
Istio samozřejmě zjednodušuje Canary Deployment tím, že nabízí několik dobrých možností pro inteligentní směrování požadavků. A ano, to vše lze provést, aniž byste se jakýmkoli způsobem dotkli vašeho zdrojového kódu.
Filtrování prohlížeče
Jedním z nejjednodušších kritérií směrování je přesměrování založené na prohlížeči. Řekněme, že chcete, aby do v2 přecházely pouze požadavky z prohlížečů Safari. Zde je návod, jak se to dělá:
Aplikujme toto pravidlo směrování a poté použijte příkaz curl Ve smyčce budeme simulovat skutečné požadavky na mikroslužbu. Jak můžete vidět na snímku obrazovky, všichni jdou do v1:
Kde je provoz na v2? Protože v našem příkladu všechny požadavky přicházely pouze z našeho vlastního příkazového řádku, jednoduše neexistuje. Ale věnujte pozornost spodním řádkům na obrazovce výše: toto je reakce na skutečnost, že jsme provedli požadavek z prohlížeče Safari, který zase vytvořil toto:
Neomezený výkon
Již jsme psali, že regulární výrazy poskytují velmi výkonné možnosti pro směrování požadavků. Podívejte se na následující příklad (myslíme, že pochopíte, co dělá):
Nyní už pravděpodobně máte představu o tom, co regulární výrazy dokážou.
Chovejte se chytře
Inteligentní směrování, zejména zpracování hlaviček paketů pomocí regulárních výrazů, vám umožňuje řídit provoz tak, jak chcete. A to výrazně zjednodušuje implementaci nového kódu - je to jednoduché, nevyžaduje změnu samotného kódu a v případě potřeby lze vše rychle vrátit tak, jak bylo.
Zájem?
Toužíte experimentovat s Istio, Kubernetes a OpenShift na vašem počítači? tým připravil vynikající na toto téma a zpřístupnil všechny doprovodné soubory veřejnosti. Tak do toho a nic si neodpírej.
Istio Egress: výstup přes obchod se suvenýry
Používáním Istio společně s Red Hat OpenShift a Kubernetes si můžete život s mikroslužbami výrazně usnadnit. Síť služeb Istio je skryta uvnitř modulů Kubernetes a váš kód běží (většinou) izolovaně. Výkon, snadná výměna, sledování atd. – to vše se snadno používá díky použití kontejnerů postranních vozíků. Co když ale vaše mikroslužba potřebuje komunikovat s ostatními službami, které se nacházejí mimo váš systém OpenShift-Kubernetes?
Zde přichází na pomoc Istio Egress. Stručně řečeno, jednoduše vám umožňuje přístup ke zdrojům (čti: „službám“), které nejsou součástí vašeho systému modulů Kubernetes. Pokud neprovedete další konfiguraci, pak je v prostředí Istio Egress provoz směrován pouze v rámci clusteru podů a mezi takovými clustery na základě interních IP tabulek. A takové zakuklení funguje skvěle, pokud nepotřebujete přístup ke službám zvenčí.
Egress umožňuje obejít výše uvedené tabulky IP, buď na základě pravidel Egress nebo na základě rozsahu IP adres.
Řekněme, že máme Java program, který odešle požadavek GET na httpbin.org/headers.
(httpbin.org je pouze pohodlný zdroj pro testování odchozích požadavků na služby.)
Pokud zadáte na příkazovém řádku curl http://httpbin.org/headers, uvidíme následující:
Nebo můžete stejnou adresu otevřít v prohlížeči:
Jak vidíte, služba tam umístěná jednoduše vrací hlavičky, které jí byly předány.
Dovozy nahrazujeme čelně
Nyní vezmeme kód Java této služby, externí pro náš systém, a spustíme ji sami, kde je, připomeňme, nainstalován Istio. (Můžete to udělat sami kontaktováním .) Po vytvoření příslušného obrazu a jeho spuštění na platformě OpenShift zavoláme tuto službu příkazem curl egresshttpbin-istioegress.$(minishift ip).nip.io, po kterém uvidíme na obrazovce toto:
Jejda, co se stalo? Všechno prostě fungovalo. Co znamená Nenalezeno? Udělali jsme to pro něj curl.
Rozšíření IP tabulek na celý internet
Istio by za to měl být obviňován (nebo děkován). Koneckonců, Istio jsou jen kontejnery postranních vozíků, které jsou zodpovědné za detekci a směrování (a spoustu dalších věcí, o kterých jsme mluvili dříve). Z tohoto důvodu tabulky IP vědí pouze to, co je uvnitř vašeho clusterového systému. A httpbin.org se nachází mimo, a proto je nepřístupný. A tady přichází na pomoc Istio Egress – bez sebemenší změny vašeho zdrojového kódu.
Níže uvedené pravidlo Egress nutí Istio hledat (v případě potřeby pak na celém internetu) požadovanou službu, v tomto případě httpbin.org. Jak můžete vidět z tohoto souboru (egress_httpbin.yml), funkce je zde poměrně jednoduchá:
Zbývá pouze použít toto pravidlo:
istioctl create -f egress_httpbin.yml -n istioegress
Pomocí příkazu můžete zobrazit pravidla Egress istioctl get egressrules:
A nakonec příkaz spustíme znovu kadeř – a vidíme, že vše funguje:
Myslíme otevřeně
Jak můžete vidět, Istio vám umožňuje organizovat interakci s vnějším světem. Jinými slovy, stále můžete vytvářet služby OpenShift a spravovat je prostřednictvím Kubernetes, přičemž vše budete mít v modulech, které se podle potřeby zvětšují a zmenšují. A zároveň můžete bezpečně přistupovat ke službám mimo vaše prostředí. A ano, ještě jednou opakujeme, že to vše lze provést, aniž byste se jakýmkoliv způsobem dotkli vašeho kódu.
Toto byl poslední příspěvek v sérii na Istio. Zůstaňte naladěni – před námi je spousta zajímavých věcí!
Zdroj: www.habr.com