„A veszély a második nevem” – mondta Austin Powers, a nemzetközi rejtély. De ami a szuperügynökök és titkosszolgálatok körében népszerű, az cseppet sem megfelelő a számítástechnikai szolgálatok számára, ahol a unalom sokkal kívánatosabb a veszélyeknél.
Az Istio, az OpenShift és a Kubernetes együtt valóban unalmassá és kiszámíthatóvá teszik a mikroszolgáltatások telepítését – és ez nagyszerű. Erről, és sok minden másról beszélünk a sorozat negyedik és utolsó posztjában az Istioról.
Amikor az unalom helyénvaló
A mi esetünkben az unalom csupán a végső fázisban jelentkezik, amikor csak ülni és figyelni kell a folyamatot. De ehhez mindent előre be kell állítani, és itt sok érdekesség vár rátok.
Új verzió telepítésekor érdemes megfontolni a kockázatok minimalizálásának minden lehetőségét. A párhuzamos üzemmód egy nagyon hatékony és kipróbált tesztelési módszer, és az Istio lehetővé teszi egy 'titkos szolgálat' (a kívülállók elől rejtett verzió a mikroszolgáltatásodból) bevonását anélkül, hogy beavatkozna a termelési rendszer működésébe. Ehhez van egy kifejezés – 'Titkos indítás' (Dark Launch), amelyet a nem kevésbé kémes nevű 'forgalom tükrözés' funkció aktivál.
Vegyétek észre, hogy az előző bekezdés első mondatában a 'telepítés' (deploy) kifejezést használjuk, nem a 'kiadás' (release) kifejezést. Valóban képesnek kell lenned telepíteni – és természetesen használni – a mikroszolgáltatásodat annyiszor, ahányszor csak akarod. Ennek a szolgáltatásnak képesnek kell lennie fogadni és feldolgozni a forgalmat, eredményeket kiadni, valamint naplózni és monitorozni. De magát a szolgáltatást nem szükséges a termelési környezetbe kiadni. A telepítés és a szoftverkiadás nem mindig ugyanaz. A telepítést bármikor elvégezheted, amikor csak akarod, a kiadást viszont csak akkor, amikor véglegesen készen állsz.
A unalom szervezése érdekes
Nézd meg a következő Istio útválasztási szabályt, amely az összes HTTP-kérést a recommendation v1 mikroszolgáltatásra irányítja (minden példa innen van, ), miközben tükrözi azokat a recommendation v2 mikroszolgáltatásra:
Figyelj a címkére mirror: a képernyő alján – ez határozza meg a forgalom tükrözését. Igen, ennyire egyszerű!
Ennek a szabálynak a következtében a termelési rendszered (v1) továbbra is feldolgozza a beérkező kéréseket, de maguk a kérések aszinkron módon tükröződnek a v2-re, azaz teljes másolatuk ott fognak távozni. Így valós körülmények között, valódi adatokkal és forgalommal tudod tesztelni a v2 működését anélkül, hogy beavatkoznál a termelési rendszer működésébe. Teszi ez a tesztelési folyamatot unalmassá? Igen, kétségtelenül. De érdekes módon valósul meg.
Adjunk drámai elemet
Fontos megjegyezni, hogy a v2 kódjában figyelembe kell venni azokat a helyzeteket, amikor a beérkező kérések adatváltozáshoz vezethetnek. Maguk a kérések könnyen és átláthatóan tükröződnek, de a tesztelés módjának kiválasztása már a te döntésed – és ez egy kicsit izgalmas.
Ismételjük meg a fontos pillanatot
A forgalom tükörfényezésével végzett sötét indítás (Dark Launch/Request Mirroring) a kód érintése nélkül is végezhető.
Gondolkodásra késztető
Mi van, ha a kéréseket nem kizárólag v1-re tükrözzük, hanem egy részüket v2-re irányítjuk? Például az összes kérés egy százalékát, vagy csak bizonyos felhasználói csoportok kéréseit. Majd, miután láttuk, hogyan működik a v2, fokozatosan átállíthatjuk az összes kérést az új verzióra. Vagy visszakozhatunk v1-re, ha a v2-vel valami nem működik. Azt hiszem, ezt nevezik Canary Deploymentnek ("kanáros telepítés" – kifejezés , és ha orosz eredetű lenne, valószínűleg utalna a ), és most ezt részletesebben megvizsgáljuk.
Canary Deployment Istio-ban: egyszerűsítjük az üzembe helyezést
Óvatosan és fokozatosan
A Canary Deployment telepítési modell lényege rendkívül egyszerű: amikor új verziót indítasz a szoftveredből (esetünkben – mikroserviszből), először egy kis felhasználói csoportnak adsz hozzáférést. Ha minden rendben megy, lassan növeled ezt a csoportot, amíg az új verzió problémákat nem kezd okozni, vagy – ha ez nem történik meg – végül az összes felhasználót az új verzióra állítod át. A fokozatos és átgondolt bevezetés lehetővé teszi a kockázatok csökkentését és a visszajelzés maximalizálását.
Természetesen az Istio leegyszerűsíti a Canary Deployment-et, számos jó lehetőséget kínál az intelligens kérésirányításhoz. Igen, mindezt úgy lehet megtenni, hogy egyáltalán nem nyúl hozzá a forráskódhoz.
Böngésző szűrése
Az egyik legegyszerűbb irányítási kritérium a böngésző szerinti átirányítás. Tegyük fel, hogy azt szeretné, hogy a v2-re csak a Safari böngészőkből érkező kérések menjenek. Íme, hogyan lehet ezt megtenni:
Alkalmazzuk ezt az irányítási szabályt, majd a parancssal curl ciklusban szimuláljuk a valós kéréseket a mikroszolgáltatáshoz. Ahogy a képernyőképen látható, mindegyik a v1-re megy:
De hol van a forgalom a v2-re? Mivel a példánkban az összes kérés csak a parancssorból érkezett, egyszerűen nincs. De figyeljen a fenti képernyő alján lévő sorokra: ez a reakció arra, hogy a Safari böngészőből hajtottunk végre egy kérést, amely a következőt adta:
Korlátlan hatalom
Már írtunk arról, hogy a reguláris kifejezések nagyon erős lehetőségeket kínálnak a kérések irányítására. Nézze meg a következő példát (gondoljuk, maga is megérti, mit csinál):
Most valószínűleg már tudja, mire képesek a reguláris kifejezések.
Cselekedjen okosan
Az intelligens irányítás, különösen a csomagok fejlécének kezelése reguláris kifejezések használatával, lehetővé teszi, hogy úgy irányítsa a forgalmat, ahogy szeretné. Ez jelentősen megkönnyíti az új kód bevezetését - ez egyszerű, nem igényel módosítást a kódban, és szükség esetén minden gyorsan visszaállítható.
Érdekli?
Itt az idő kísérletezni az Istio, Kubernetes és OpenShift használatával a számítógépén? A csapat nagyszerű készített erről a témáról, és megosztotta az összes kapcsolódó fájlt. Szóval hátra, és ne tartsanak vissza magukat.
Istio Egress: kijárat a szuvenír boltján keresztül
Az Istio alkalmazása a Red Hat OpenShift és Kubernetes segítségével jelentősen megkönnyíti az életet a mikroszolgáltatásokkal. Az Istio szolgáltatás hálózata el van rejtve a Kubernetes pod-jaiban, és a kódja (főként) elszigetelten fut. A teljesítmény, a változtatás egyszerűsége, a nyomkövetés és mások - mindez könnyen használható a sidecar konténerek alkalmazása révén. De mi a teendő, ha a mikroszolgáltatása kapcsolatba kell lépnie más szolgáltatásokkal, amelyek a rendszerén kívül helyezkednek el, OpenShift-Kubernetes?
Itt jön segítségül az Istio Egress. Röviden fogalmazva: lehetővé teszi, hogy hozzáférjünk olyan erőforrásokhoz (értsd: „szolgáltatások”), amelyek nem részei a Kubernetes pod-jainknak. Ha nem végzünk el további beállításokat, a forgalom az Istio Egress környezetében csak a pod klaszteren belül és az ilyen klaszterek között az internális IP-táblák alapján irányítódik. Ez a titkosítás remekül működik, amíg nem kell hozzáférnünk a külső szolgáltatásokhoz.
Az Egress lehetővé teszi a fenti IP-táblák megkerülését, akár Egress szabályok alapján, akár IP-cím tartományok 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 egyszerűen egy kényelmes erőforrás a kimenő szolgáltatás kérések tesztelésére.)
Ha beírjuk a parancssorba curl http://httpbin.org/headers, akkor a következőket látjuk:
Vagy megnyithatjuk ezt a címet a böngészőben is:
Ahogy látjuk, a szolgáltatás csak visszaadja a neki átadott fejlécet.
Importálunk a lényegre térve
Most vegyük a Java kódot a külső szolgáltatásunkhoz, és futtassuk a saját rendszerünkben, ahol Istio áll. (Ezt megteheted magad is, ha ellátogatsz a .) A megfelelő képfájl összeállítása után futtassuk a platformunkon az OpenShift-en a következő parancsot: curl egresshttpbin-istioegress.$(minishift ip).nip.io, és ezt követően a képernyőn ezt fogjuk látni:
Mi történt? Hiszen ez az imént még működött. Mit jelent a Not Found? Hiszen éppen most állítottuk be. curl.
Kiterjesztjük az IP-táblákat az egész internetre.
Ezt Istionak köszönhetjük (vagy hibáztathatjuk). Az Istio tulajdonképpen oldalsó konténerekből áll, amelyek a felfedezésért és az irányításért felelnek (és számos más dologért, amiről korábban beszéltünk). Emiatt az IP-táblák csak arról tudnak, ami a klasztereid rendszerén belül található. A httpbin.org kívül található, így nem hozzáférhető. Itt jön segítségül az Istio Egress – a forráskódodban lévő legkisebb módosítás nélkül.
Az alábbi Egress-szabály arra kényszeríti az Istio-t, hogy keressen (ha szükséges, akkor az egész világhálón) a szükséges szolgáltatás után, ebben az esetben a httpbin.org-ot. Ahogy ebből a fájlból (egress_httpbin.yml) látható, a funkcionalitás meglehetősen egyszerű:
Már csak ezt a szabályt kell alkalmaznunk:
istioctl create -f egress_httpbin.yml -n istioegress
Az Egress szabályokat a következő parancs segítségével tekinthetjük meg: istioctl get egressrules:
És végül, újra futtatjuk a parancsot curl – és látjuk, hogy minden működik:
Gondolkodjunk nyitottan
Ahogy látjátok, az Istio lehetővé teszi, hogy együttműködjünk a külvilággal. Más szóval, továbbra is létrehozhattok OpenShift szolgáltatásokat és kezelhetitek őket Kubernetes-en keresztül, mindent pod-okban tartva, amelyek igény szerint felnőnek vagy csökkennek. És emellett nyugodtan hivatkozhattok a környezetetekhez képest külső szolgáltatásokra is. Igen, még egyszer hangsúlyozzuk, hogy mindezt úgy tehetitek meg, hogy egyáltalán nem érintitek a kódotokat.
Ez volt az utolsó bejegyzés a sorozatban az Istio-ról. Maradjatok velünk – előre sok érdekesség vár rátok!
Forrás: habr.com
