"Niebezpieczeństwo to moje drugie imię" – mawiał Austin Powers, człowiek-zagadka o międzynarodowej renomie. Lecz to, co jest cenione przez superagentów i służby, zupełnie się nie nadaje do służb komputerowych, gdzie nuda jest znacznie lepsza od niebezpieczeństw.
A Istio wspólnie z OpenShift i Kubernetes sprawiają, że wdrożenie mikrousług staje się prawdziwie nudnym i przewidywalnym procesem – i to jest wspaniałe. O tym i wielu innych rzeczach porozmawiamy w czwartym i ostatnim poście z serii poświęconej Istio.
Kiedy nuda – to dobrze
W naszym przypadku nuda pojawia się tylko w końcowej fazie, gdy pozostaje jedynie siedzieć i obserwować proces. Ale aby do tego doszło, trzeba wszystko wcześniej skonfigurować, a tutaj czeka na Was wiele interesujących rzeczy.
Podczas wdrażania nowej wersji oprogramowania warto rozważyć wszystkie opcje minimalizowania ryzyka. Praca w trybie równoległym to bardzo silny i sprawdzony sposób na testowanie, a Istio pozwala korzystać z "tajnej służby" (ukrytej przed obcymi wersji Waszej mikrousługi) bez ingerencji w działanie systemu produkcyjnego. Istnieje nawet specjalny termin – "Tajny start" (Dark Launch), który z kolei uruchamia funkcja o co najmniej szpiegowskiej nazwie "lustrzane odbicie ruchu".
Zwróć uwagę, że w pierwszym zdaniu poprzedniego akapitu użyto terminu „wdrożenie” (deploy), a nie „uruchomienie” (release). Rzeczywiście musisz mieć możliwość wdrażania – a oczywiście także korzystania – z mikrousługi tak często, jak tylko chcesz. Usługa ta powinna być w stanie przyjmować i przetwarzać ruch, zwracać wyniki oraz rejestrować w logach i być monitorowana. Ale sama ta usługa wcale nie musi być wypuszczona na produkcję. Wdrożenie i wydanie oprogramowania to nie zawsze to samo. Wdrożenie możesz realizować zawsze, gdy chcesz, podczas gdy wydanie – tylko wtedy, gdy będziesz całkowicie gotowy.
Organizacja nudy – to interesujące
Zobaczcie następne reguły routingu Istio, które kierują wszystkie żądania HTTP do mikrousługi recommendation v1 (wszystkie przykłady zaczerpnięte z ), jednocześnie lustrzanie je na mikrousługę recommendation v2:
Zwróćcie uwagę na etykietę mirror: na dole zrzutu ekranu – to ona definiuje lustrzane odbicie ruchu. Tak, to takie proste!
Wynikiem działania tej zasady jest to, że twój system produkcyjny (v1) wciąż będzie przetwarzał nadchodzące żądania, ale same żądania będą asynchronicznie lustrzane na v2, tzn. tam będą wysyłane ich pełne duplikaty. Dzięki temu będziesz mógł przetestować działanie v2 w rzeczywistych warunkach – na prawdziwych danych i ruchu, nie ingerując w działanie systemu produkcyjnego. Czy zamienia to organizację testowania w nudny proces? Tak, zdecydowanie. Ale jest to przeprowadzane w interesujący sposób.
Dodajmy dramatyzmu
Zwróć uwagę, że w kodzie v2 trzeba przewidzieć sytuacje, w których nadchodzące żądania mogą prowadzić do zmiany danych. Same żądania są lustrzane łatwo i przezroczysto, ale to jak je obsłużysz w teście pozostaje w twoich rękach – a to już jest trochę ekscytujące.
Powtórzmy ważny punkt
Tajny start z lustrzeniem ruchu (Dark Launch/Request Mirroring) można realizować, nie wpływając na kod.
Karma do przemyślenia
A co jeśli miejsce lustrzenia żądań rozdzielić część z nich nie na v1, a na v2? Na przykład jeden procent wszystkich żądań lub tylko żądania od określonej grupy użytkowników. A potem, patrząc na to, jak działa v2, stopniowo przekazywać wszystkie żądania na nową wersję. Lub przeciwnie, wrócić wszystko na v1, jeśli z v2 coś pójdzie nie tak. Wydaje się, że nazywa się to Canary Deployment ("kanarkowe wdrożenie" – termin , a gdyby miał rosyjskie pochodzenie, prawdopodobnie zawierałby odniesienie do ), i teraz przyjrzymy się temu bliżej.
Canary Deployment w Istio: ułatwiamy wprowadzenie do eksploatacji
Ostrożnie i stopniowo
Istota modelu wdrożenia Canary Deployment jest ekstremalnie prosta: podczas uruchamiania nowej wersji oprogramowania (w naszym przypadku – mikroserwisu) najpierw dajesz dostęp małej grupie użytkowników. Jeśli wszystko przebiega pomyślnie, powoli zwiększasz tę grupę, aż nowa wersja zacznie się psuć, lub – jeśli tak się nie stanie – ostatecznie przekazujesz ją wszystkim użytkownikom. Wprowadzając nową wersję w przemyślany i stopniowy sposób oraz kontrolując przełączanie użytkowników, można zminimalizować ryzyko i maksymalizować opinie zwrotne.
Oczywiście, Istio ułatwia wdrożenia Canary, oferując kilka dobrych opcji dla inteligentnego routingu zapytań. I tak, wszystko to można zrobić bez modyfikowania twojego kodu źródłowego.
Filtrujemy przeglądarkę
Jednym z najprostszych kryteriów routingu jest przekierowanie w zależności od przeglądarki. Załóżmy, że chcesz, aby na v2 kierowane były tylko zapytania z przeglądarek Safari. Oto jak to zrobić:
Zastosujmy tę zasadę routingu, a następnie poleceniem curl będziemy w pętli symulować rzeczywiste zapytania do mikroserwisu. Jak widać na zrzucie ekranu, wszystkie one kierowane są na v1:
A gdzie jest ruch na v2? Ponieważ w naszym przykładzie wszystkie zapytania pochodziły tylko z wiersza poleceń, po prostu go nie ma. Ale zwróć uwagę na dolne linie na powyższym zrzucie ekranu: to odpowiedź na zapytanie z przeglądarki Safari, która z kolei zwróciła to:
Nieograniczona władza
Już pisaliśmy, że wyrażenia regularne dają bardzo potężne możliwości dla routingu zapytań. Zobacz przykład poniżej (myślimy, że sam zrozumiesz, co robi):
Teraz prawdopodobnie już wiesz, na co stać 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 zarządzać ruchem tak, jak chcesz. I znacznie ułatwia wprowadzenie nowego kodu – jest to proste, nie wymaga zmiany samego kodu, a w razie potrzeby wszystko można szybko przywrócić do stanu poprzedniego.
Zainteresowany?
Czy masz ochotę poeksperymentować z Istio, Kubernetes i OpenShift na swoim komputerze? Zespół przygotował doskonały na ten temat i udostępnił wszystkie towarzyszące pliki. Więc naprzód, nie oszczędzaj na sobie.
Istio Egress: wyjście przez sklep z pamiątkami
Stosując Istio razem z Red Hat OpenShift i Kubernetes, możesz znacznie ułatwić sobie życie z mikroserwisami. Siatka usług Istio jest schowana w pod’ach Kubernetes, a twój kod działa (głównie) w izolacji. Wydajność, łatwość modyfikacji, śledzenie i inne – wszystko to można łatwo wykorzystać dzięki zastosowaniu kontenerów sidecar. Ale co zrobić, jeśli twój mikroserwis musi komunikować się z innymi usługami, które znajdują się poza twoim systemem OpenShift-Kubernetes?
Tutaj z pomocą przychodzi Istio Egress. Mówiąc krótko, pozwala on na dostęp do zasobów (czytaj: „usług”), które nie znajdują się w systemie podów Kubernetes. Jeśli nie dokonasz dodatkowej konfiguracji, ruch w środowisku Istio Egress jest kierowany tylko wewnątrz klastra podów oraz między takimi klastrami na podstawie wewnętrznych tabel IP. Tego rodzaju izolacja działa doskonale, dopóki nie potrzebujesz dostępu do usług spoza klastra.
Egress pozwala ominąć wspomniane powyżej tabele IP, zarówno na podstawie reguł Egress, jak i dla zakresu adresów IP.
Załóżmy, że mamy program Java, który wykonuje zapytanie GET do httpbin.org/headers.
(httpbin.org to po prostu wygodny zasób do testowania wyjściowych zapytań usługowych.)
Jeśli wpiszesz w wierszu poleceń curl http://httpbin.org/headers, zobaczymy następujące:
Można też otworzyć ten sam adres w przeglądarce:
Jak widzimy, usługa tam umieszczona po prostu zwraca przesłane jej nagłówki.
Zamieniamy w locie
Teraz weźmy kod Java tej usługi zewnętrznej względem naszego systemu i uruchomimy go u siebie, gdzie, przypomnijmy, działa Istio. (Możesz zrobić to samodzielnie, korzystając z .) Po zbudowaniu odpowiedniego obrazu i uruchomieniu go na platformie OpenShift, wywołamy tę usługę komendą curl egresshttpbin-istioegress.$(minishift ip).nip.io, po czym na ekranie zobaczymy to:
O co chodzi, co się stało? Dopiero co to działało. Co to znaczy Not Found? Przecież właśnie zrobiliśmy to dla niego. curl.
Rozszerzamy tabele IP na cały internet
Winimy (lub dziękujemy) za to Istio. Otóż Istio to po prostu kontenery sidecar, które odpowiadają za wykrywanie i kierowanie (i wiele innych rzeczy, o których mówiliśmy wcześniej). Z tego powodu tabele IP wiedzą tylko o tym, co znajduje się wewnątrz twojego systemu klastrów. A httpbin.org znajduje się na zewnątrz i dlatego jest niedostępne. I tu z pomocą przychodzi Istio Egress – bez najmniejszych zmian w twoim kodzie źródłowym.
Podana poniżej reguła Egress zmusza Istio do wyszukiwania (jeśli to konieczne, to i w całej sieci) potrzebnej usługi, w tym przypadku httpbin.org. Jak widać z tego pliku (egress_httpbin.yml), funkcjonalność jest tutaj dość prosta:
Pozostaje tylko zastosować tę regułę:
istioctl create -f egress_httpbin.yml -n istioegress
Aby wyświetlić reguły Egress, można użyć komendy istioctl get egressrules:
I w końcu ponownie uruchamiamy polecenie curl – i widzimy, że wszystko działa:
Myślimy otwarcie
Jak widać, Istio umożliwia interakcję z zewnętrznym światem. Innymi słowy, nadal możesz tworzyć usługi OpenShift i zarządzać nimi za pośrednictwem Kubernetes, trzymając wszystko w podach, które skalują się w górę i w dół w razie potrzeby. A jednocześnie możesz swobodnie korzystać z usług zewnętrznych w stosunku do twojego środowiska. I tak, jeszcze raz powtórzymy, że wszystko to można robić, nie zmieniając swojego kodu.
To był ostatni post z serii o Istio. Pozostańcie z nami – czeka nas wiele interesujących rzeczy!
Źródło: habr.com
