„Niebezpieczeństwo to moje drugie imię” – mawiał Austin Powers, międzynarodowy człowiek tajemnicy. Ale to, co cieszy się dużym uznaniem superagentów i służb wywiadowczych, zupełnie nie nadaje się do usług komputerowych, gdzie nuda jest o wiele lepsza niż niebezpieczeństwo.
Istio wraz z OpenShift i Kubernetes sprawia, że wdrażanie mikrousług jest naprawdę nudne i przewidywalne — i to jest świetne. O tym i wiele więcej porozmawiamy w czwartym i ostatnim poście z serii Istio.
Kiedy nuda jest dobra
W naszym przypadku nuda pojawia się dopiero w końcowej fazie, kiedy pozostaje już tylko siedzieć i przyglądać się procesowi. Ale w tym celu musisz najpierw wszystko skonfigurować, a tutaj czeka na Ciebie wiele ciekawych rzeczy.
Wdrażając nową wersję swojego oprogramowania warto rozważyć wszystkie możliwości minimalizacji ryzyka. Równoległe działanie to bardzo wydajny i sprawdzony sposób testowania, a Istio pozwala na użycie „tajnej usługi” (ukrytej wersji mikroserwisu), aby to zrobić bez ingerencji w system produkcyjny. Istnieje nawet specjalny termin na to - „Dark Launch”, który z kolei jest aktywowany przez funkcję o równie szpiegowskiej nazwie „traffic Mirroring”.
Należy pamiętać, że w pierwszym zdaniu poprzedniego akapitu zastosowano termin „wdrożenie”, a nie „wydanie”. Naprawdę powinieneś móc wdrażać – i oczywiście używać – swojej mikrousługi tak często, jak chcesz. Usługa ta musi być w stanie odbierać i przetwarzać ruch, generować wyniki, a także zapisywać w dziennikach i monitorować. Ale jednocześnie sama usługa nie musi być koniecznie wprowadzana do produkcji. Wdrażanie i wydawanie oprogramowania nie zawsze jest tym samym. Możesz wdrożyć, kiedy tylko chcesz, ale zwolnij dopiero wtedy, gdy będziesz gotowy.
Organizowanie nudy jest ciekawe
Przyjrzyj się poniższej regule routingu Istio, która kieruje wszystkie żądania HTTP do zalecenia mikrousług v1 (wszystkie przykłady zaczerpnięte z ), jednocześnie odzwierciedlając je w mikroserwisie rekomendacyjnym v2:
Zwróć uwagę na etykietę mirror: na dole ekranu - to właśnie ustawia odzwierciedlanie ruchu. Tak, to takie proste!
Rezultatem tej reguły będzie to, że Twój system produkcyjny (v1) będzie nadal przetwarzał przychodzące żądania, ale same żądania będą asynchronicznie odzwierciedlane w wersji 2, to znaczy, że ich kompletne duplikaty trafią tam. W ten sposób można przetestować v2 w rzeczywistych warunkach – na rzeczywistych danych i ruchu – nie ingerując w żaden sposób w działanie systemu produkcyjnego. Czy to sprawia, że organizowanie testów jest nudne? Tak, zdecydowanie. Ale zrobiono to w ciekawy sposób.
Dodajmy dramat
Należy pamiętać, że w kodzie v2 należy uwzględnić sytuacje, w których przychodzące żądania mogą prowadzić do zmiany danych. Same żądania są dublowane łatwo i przejrzyście, ale wybór metody przetwarzania w teście zależy od Ciebie – i jest to trochę niepokojące.
Powtórzmy ważną kwestię
Tajne uruchomienie z dublowaniem ruchu (Dark Launch/Request Mirroring) można wykonać bez żadnego wpływu na kod.
Jedzenie do przemyślenia
Co się stanie, jeśli miejsce, w którym dublowane są żądania, wyśle część z nich nie do wersji 1, ale do wersji 2? Na przykład jeden procent wszystkich żądań lub tylko żądania od określonej grupy użytkowników. A potem, już patrząc, jak działa v2, stopniowo przenoś wszystkie żądania do nowej wersji. Lub odwrotnie, przywróć wszystko do wersji 1, jeśli coś pójdzie nie tak z wersją 2. Myślę, że nazywa się to wdrożeniem na Wyspach Kanaryjskich. , a gdyby był pochodzenia rosyjskiego, prawdopodobnie zawierałby odniesienie do ), a teraz przyjrzymy się temu bardziej szczegółowo.
Wdrożenie Canary w Istio: uproszczenie uruchomienia
Ostrożnie i stopniowo
Istota modelu wdrożenia Canary Deployment jest niezwykle prosta: uruchamiając nową wersję swojego oprogramowania (w naszym przypadku mikroserwisu), najpierw dajesz do niego dostęp małej grupie użytkowników. Jeśli wszystko pójdzie dobrze, powoli zwiększaj tę grupę, aż nowa wersja zacznie działać, lub - jeśli nie - ostatecznie przenieś do niej wszystkich użytkowników. Przemyślanie i stopniowo wprowadzając nową wersję oraz przełączając do niej użytkowników w kontrolowany sposób, możesz zmniejszyć ryzyko i zmaksymalizować informację zwrotną.
Oczywiście Istio upraszcza wdrożenie Canary, oferując kilka dobrych opcji inteligentnego routingu żądań. I tak, wszystko to można zrobić bez dotykania w jakikolwiek sposób kodu źródłowego.
Filtrowanie przeglądarki
Jednym z najprostszych kryteriów routingu jest przekierowanie oparte na przeglądarce. Załóżmy, że chcesz, aby tylko żądania z przeglądarek Safari trafiały do wersji 2. Oto jak to się robi:
Zastosujmy tę regułę routingu, a następnie użyjmy polecenia curl Będziemy symulować rzeczywiste żądania do mikroserwisu w pętli. Jak widać na zrzucie ekranu, wszystkie idą do wersji 1:
Gdzie jest ruch na v2? Ponieważ w naszym przykładzie wszystkie żądania pochodziły wyłącznie z naszej linii poleceń, po prostu nie istnieje. Zwróć jednak uwagę na najważniejsze kwestie na powyższym ekranie: jest to reakcja na fakt, że wykonaliśmy żądanie z przeglądarki Safari, co z kolei wygenerowało następujący komunikat:
Nieskończona moc
Pisaliśmy już, że wyrażenia regularne zapewniają bardzo potężne możliwości routingu żądań. Spójrz na następujący przykład (myślimy, że zrozumiesz, co robi):
Prawdopodobnie już wiesz, co potrafią wyrażenia regularne.
Działaj mądrze
Inteligentny routing, w szczególności przetwarzanie nagłówków pakietów za pomocą wyrażeń regularnych, pozwala sterować ruchem tak, jak chcesz. A to znacznie upraszcza wdrażanie nowego kodu – jest proste, nie wymaga zmiany samego kodu, a w razie potrzeby wszystko można szybko przywrócić tak, jak było.
Zainteresowany?
Czy masz ochotę poeksperymentować z Istio, Kubernetes i OpenShift na swoim komputerze? Zespół przygotował znakomity na ten temat i udostępnił publicznie wszystkie towarzyszące pliki. Więc idź dalej i nie odmawiaj sobie niczego.
Istio Egress: wyjście przez sklep z pamiątkami
Używając Istio razem z Red Hat OpenShift i Kubernetes, możesz znacznie ułatwić sobie życie dzięki mikroserwisom. Siatka usług Istio jest ukryta w zasobnikach Kubernetes, a Twój kod działa (w większości) w izolacji. Wydajność, łatwość wymiany, śledzenie itp. – wszystko to jest łatwe w użyciu dzięki zastosowaniu kontenerów z przyczepą boczną. Ale co, jeśli Twoja mikrousługa musi komunikować się z innymi usługami, które znajdują się poza Twoim systemem OpenShift-Kubernetes?
I tu z pomocą przychodzi Istio Egress. Krótko mówiąc, umożliwia po prostu dostęp do zasobów (czytaj: „usług”), które nie są częścią Twojego systemu kubernetes podów. Jeśli nie wykonasz dodatkowej konfiguracji, to w środowisku Istio Egress ruch kierowany będzie wyłącznie w obrębie klastra podów oraz pomiędzy takimi klastrami w oparciu o wewnętrzne tablice IP. I takie przepoczwarczenie sprawdza się znakomicie, o ile nie potrzeba dostępu do usług z zewnątrz.
Usługa Egress umożliwia ominięcie powyższych tabel adresów IP w oparciu o reguły usługi Egress lub zakres adresów IP.
Załóżmy, że mamy program w Javie, który wysyła żądanie GET do httpbin.org/headers.
(httpbin.org to po prostu wygodne źródło do testowania wychodzących żądań usług).
Jeśli wpiszesz w wierszu poleceń curl http://httpbin.org/headers, zobaczymy co następuje:
Możesz też otworzyć ten sam adres w przeglądarce:
Jak widać, zlokalizowana tam usługa po prostu zwraca przekazane jej nagłówki.
Od razu zastępujemy import
Weźmy teraz kod Java tej usługi, zewnętrznej w stosunku do naszego systemu, i uruchommy go samodzielnie, gdzie, przypomnijmy, jest zainstalowany Istio. (Możesz to zrobić samodzielnie, kontaktując się .) Po zbudowaniu odpowiedniego obrazu i uruchomieniu go na platformie OpenShift wywołamy tę usługę poleceniem curl egresshttpbin-istioegress.$(minishift ip).nip.io, po czym na ekranie zobaczymy to:
Ups, co się stało? Wszystko po prostu zadziałało. Co oznacza komunikat Nie znaleziono? Po prostu zrobiliśmy to za niego curl.
Rozszerzenie tablic IP na cały Internet
Należy za to winić Istio (lub podziękować). W końcu Istio to tylko kontenery boczne, które odpowiadają za wykrywanie i routing (i wiele innych rzeczy, o których mówiliśmy wcześniej). Z tego powodu tabele IP znają tylko zawartość systemu klastrowego. A httpbin.org znajduje się na zewnątrz i dlatego jest niedostępny. I tu na ratunek przychodzi Istio Egress – bez najmniejszej zmiany w kodzie źródłowym.
Poniższa reguła Egress zmusza Istio do wyszukiwania (jeśli to konieczne, to w całym Internecie) żądanej usługi, w tym przypadku httpbin.org. Jak widać z tego pliku (egress_httpbin.yml), funkcjonalność jest tutaj dość prosta:
Pozostaje tylko zastosować tę zasadę:
istioctl create -f egress_httpbin.yml -n istioegress
Za pomocą polecenia możesz wyświetlić reguły wyjścia istioctl get egressrules:
Na koniec ponownie uruchamiamy polecenie curl – i widzimy, że wszystko działa:
Myślimy otwarcie
Jak widać, Istio pozwala organizować interakcję ze światem zewnętrznym. Innymi słowy, nadal możesz tworzyć usługi OpenShift i zarządzać nimi za pomocą Kubernetes, przechowując wszystko w zasobnikach, które można skalować w górę i w dół w zależności od potrzeb. Jednocześnie możesz bezpiecznie uzyskać dostęp do usług zewnętrznych w stosunku do Twojego środowiska. I tak, powtarzamy jeszcze raz, że wszystko to można zrobić bez dotykania w jakikolwiek sposób kodu.
To był ostatni post z serii na Istio. Bądźcie czujni – przed nami mnóstwo ciekawych rzeczy!
Źródło: www.habr.com