„A Veszély a középső nevem” – szokta mondani Austin Powers, egy nemzetközi titokzatos ember. De amit a szuperügynökök és a titkosszolgálatok nagyra tartanak, az egyáltalán nem alkalmas számítógépes szolgáltatásokra, ahol az unalom sokkal jobb, mint a veszély.
Az Istio az OpenShifttel és a Kubernetestel együtt pedig igazán unalmassá és kiszámíthatóvá teszi a mikroszolgáltatások telepítését – és ez nagyszerű. Erről és még sok másról fogunk beszélni az Istio sorozat negyedik, egyben utolsó bejegyzésében.
Amikor az unalom jogos
Nálunk az unalom csak a végső fázisban jelentkezik, amikor már csak ülni és figyelni kell a folyamatot. Ehhez azonban először mindent be kell állítania, és sok érdekes dolog vár itt.
Amikor szoftvere új verzióját telepíti, érdemes minden lehetőséget átgondolni a kockázatok minimalizálására. A párhuzamos futás nagyon hatékony és bevált módszer a tesztelésre, az Istio pedig lehetővé teszi egy „titkos szolgáltatás” (a mikroszolgáltatás rejtett változata) használatát, hogy ezt a termelési rendszer megzavarása nélkül végezze el. Még egy speciális kifejezés is létezik erre - „Dark Launch”, amelyet viszont egy ugyanilyen kémnévvel rendelkező funkció aktivál, „forgalmi tükrözés”.
Kérjük, vegye figyelembe, hogy az előző bekezdés első mondata a „telepítés” kifejezést használja a „kibocsátás” helyett. Valójában olyan gyakran telepítheti – és természetesen használhatja – a mikroszolgáltatását, ahányszor csak akarja. Ennek a szolgáltatásnak képesnek kell lennie a forgalom fogadására és feldolgozására, eredményeket produkálni, valamint naplókba írni és figyelni. De ugyanakkor magát ezt a szolgáltatást sem feltétlenül kell termelésbe bocsátani. A szoftver telepítése és kiadása nem mindig ugyanaz. Bármikor telepítheti, de csak akkor engedheti el, ha készen áll.
Az unalom megszervezése érdekes
Vessen egy pillantást a következő Istio útválasztási szabályra, amely az összes HTTP-kérést a mikroszolgáltatás v1-es ajánlásához irányítja (minden példa innen származik ), miközben egyidejűleg tükrözi őket az ajánlás v2 mikroszolgáltatásában:
Ügyeljen a címkére mirror: a képernyő alján - ez az, amely beállítja a forgalom tükrözését. Igen, ez ilyen egyszerű!
Ennek a szabálynak az lesz az eredménye, hogy az éles rendszer (v1) továbbra is feldolgozza a bejövő kéréseket, de maguk a kérések aszinkron módon tükröződnek a v2-re, vagyis a teljes duplikátumuk oda kerül. Így valós körülmények között – valós adatokon és forgalomon – tesztelheti a v2-t anélkül, hogy bármilyen módon megzavarná az éles rendszer működését. Ez unalmassá teszi a tesztelés megszervezését? Igen határozottan. De érdekes módon van megcsinálva.
Tegyük hozzá a drámát
Kérjük, vegye figyelembe, hogy a v2 kódban biztosítani kell azokat a helyzeteket, amikor a bejövő kérések adatváltozásokhoz vezethetnek. Maguk a kérések könnyen és átláthatóan tükröződnek, de a tesztben a feldolgozási mód kiválasztása Önön múlik – és ez egy kicsit aggasztó.
Ismételjünk meg egy fontos pontot
Titkos indítás forgalmi tükrözéssel (Dark Launch/Request Mirroring) végrehajtható anélkül, hogy a kódot bármilyen módon befolyásolná.
Szellemi táplálék
Mi van akkor, ha a kérések tükrözésének helye nem a v1-re, hanem a v2-re küldi el azokat? Például az összes kérés egy százaléka, vagy csak a felhasználók egy bizonyos csoportjától érkező kérések. És akkor, már megnézve a v2 működését, fokozatosan vigye át az összes kérést az új verzióra. Vagy fordítva, állítson vissza mindent a v1-re, ha valami baj van a v2-vel. Szerintem Canary Deploymentnek hívják. , és ha orosz eredetű lenne, valószínűleg utalást tartalmazna ), és most ezt nézzük meg részletesebben.
Canary Deployment in Istio: az üzembe helyezés egyszerűsítése
Óvatosan és fokozatosan
A Canary Deployment telepítési modell lényege rendkívül egyszerű: amikor elindítjuk a szoftverünk új verzióját (esetünkben egy mikroszolgáltatást), először hozzáférést adunk hozzá a felhasználók egy kis csoportjának. Ha minden jól megy, lassan növeli ezt a csoportot, amíg az új verzió működésbe lép, vagy ha nem, akkor végül minden felhasználót áttelepít rá. Egy új verzió átgondolt és fokozatos bevezetésével és a felhasználók ellenőrzött módon történő átállításával csökkentheti a kockázatokat és maximalizálhatja a visszajelzéseket.
Természetesen az Istio leegyszerűsíti a Canary Deployment szolgáltatást, mivel számos jó lehetőséget kínál az intelligens kérés-útválasztáshoz. És igen, mindez megtehető anélkül, hogy bármilyen módon hozzányúlna a forráskódjához.
A böngésző szűrése
Az egyik legegyszerűbb útválasztási kritérium a böngésző alapú átirányítás. Tegyük fel, hogy csak a Safari böngészőktől érkező kéréseket szeretné elérni a v2-re. Íme, hogyan történik:
Alkalmazzuk ezt az útválasztási szabályt, majd használjuk a parancsot curl Valódi kéréseket szimulálunk a mikroszolgáltatáshoz egy hurokban. Amint a képernyőképen látható, mindegyik a v1-re megy:
Hol van a forgalom a v2-n? Mivel példánkban minden kérés csak a saját parancssorunkból érkezett, egyszerűen nem létezik. De ügyeljen a fenti képernyő alsó soraira: ez egy reakció arra a tényre, hogy végrehajtottunk egy kérést a Safari böngészőtől, amely viszont ezt eredményezte:
Korlátlan teljesítmény
Korábban már írtunk arról, hogy a reguláris kifejezések nagyon hatékony lehetőségeket biztosítanak az útválasztási kérésekhez. Vessen egy pillantást a következő példára (szerintünk érteni fogja, mit csinál):
Mostanra valószínűleg már van fogalma arról, hogy mire képesek a reguláris kifejezések.
Cselekedj okosan
Az intelligens útválasztás, különösen a csomagfejlécek reguláris kifejezésekkel történő feldolgozása, lehetővé teszi a forgalom tetszés szerinti irányítását. És ez nagyban leegyszerűsíti az új kód megvalósítását - egyszerű, nem szükséges magának a kódnak megváltoztatnia, és szükség esetén mindent gyorsan vissza lehet adni úgy, ahogy volt.
Érdekelt?
Szívesen kísérletezik az Istio, a Kubernetes és az OpenShift programokkal a számítógépén? Csapat kiválót készített ebben a témában, és nyilvánosan elérhetővé tette az összes kísérő fájlt. Tehát menj előre, és ne tagadj meg magadtól semmit.
Istio Egress: kilépés a szuvenírbolton keresztül
Ha az Istio-t a Red Hat OpenShifttel és a Kubernetes-tel együtt használja, sokkal könnyebbé teheti életét mikroszolgáltatásokkal. Az Istio szolgáltatáshálója a Kubernetes podokban rejtőzik, és a kódja (többnyire) elszigetelten fut. Teljesítmény, könnyű csere, nyomon követés stb. – mindez könnyen használható az oldalkocsis konténerek használatának köszönhetően. De mi van akkor, ha a mikroszolgáltatásnak kommunikálnia kell más szolgáltatásokkal, amelyek az OpenShift-Kubernetes rendszeren kívül találhatók?
Itt az Istio Egress segít. Dióhéjban, egyszerűen lehetővé teszi az olyan erőforrásokhoz (értsd: „szolgáltatásokhoz”) való hozzáférést, amelyek nem részei a Kubernetes pod-rendszerének. Ha nem hajt végre további konfigurálást, akkor az Istio Egress környezetben a forgalom csak egy pod-fürtön belül és az ilyen fürtök között a belső IP-táblázatok alapján kerül továbbításra. És az ilyen bábozás remekül működik mindaddig, amíg nincs szüksége külső szolgáltatásokhoz.
Az Egress lehetővé teszi a fenti IP-táblák megkerülését, akár az Egress-szabályok, akár egy IP-címtartomány alapján.
Tegyük fel, hogy van egy Java programunk, amely GET kérést küld a httpbin.org/headers címre.
(A httpbin.org csak egy kényelmes forrás a kimenő szolgáltatáskérések teszteléséhez.)
Ha beírja a parancssorba curl http://httpbin.org/headers, a következőket fogjuk látni:
Vagy megnyithatja ugyanazt a címet a böngészőben:
Mint látható, az ott található szolgáltatás egyszerűen visszaadja a neki átadott fejléceket.
Határozottan pótoljuk az importot
Most vegyük ennek a szolgáltatásunknak a rendszerünkön kívüli Java kódját, és futtassuk le saját magunkon, ahol, emlékezz, az Istio telepítve van. (Ezt saját maga is megteheti, ha felveszi a kapcsolatot .) Miután elkészítettük a megfelelő képet és elindítottuk az OpenShift platformon, ezt a szolgáltatást a paranccsal hívjuk meg curl egresshttpbin-istioegress.$(minishift ip).nip.io, ami után ezt fogjuk látni a képernyőn:
Hoppá, mi történt? Minden egyszerűen működött. Mit jelent a Nem található? Csak neki csináltuk curl.
Az IP-táblázatok kiterjesztése a teljes Internetre
Istiót kell hibáztatni (vagy megköszönni) ezért. Végül is az Istio csak oldalkocsis konténerek, amelyek felelősek az észlelésért és az útválasztásért (és sok más dologért, amiről korábban beszéltünk). Emiatt az IP-táblák csak azt tudják, mi van a fürtrendszeren belül. A httpbin.org pedig kívül található, ezért elérhetetlen. És itt jön a segítség az Istio Egress – a forráskód legkisebb változtatása nélkül.
Az alábbi Kilépési szabály arra kényszeríti az Istiót, hogy keresse (ha szükséges, akkor az egész Interneten) a kívánt szolgáltatást, jelen esetben a httpbin.org webhelyet. Amint ebből a fájlból (egress_httpbin.yml) látható, a funkció meglehetősen egyszerű:
Már csak ezt a szabályt kell alkalmazni:
istioctl create -f egress_httpbin.yml -n istioegress
A kilépési szabályokat a paranccsal tekintheti meg istioctl get egressrules:
És végül újra futtatjuk a parancsot becsavar – és látjuk, hogy minden működik:
Nyíltan gondolkodunk
Amint látja, az Istio lehetővé teszi a külvilággal való interakció megszervezését. Más szavakkal, továbbra is létrehozhat OpenShift-szolgáltatásokat, és kezelheti őket a Kubernetesen keresztül, mindent olyan podokban tartva, amelyek szükség szerint fel- és leskálázhatók. Ugyanakkor biztonságosan hozzáférhet a környezetén kívüli szolgáltatásokhoz. És igen, még egyszer megismételjük, hogy mindez megtehető anélkül, hogy bármilyen módon hozzányúlna a kódjához.
Ez volt az utolsó bejegyzés a sorozatban az Istio-n. Maradjon velünk – sok érdekesség vár még!
Forrás: will.com