GSP699

Opis

Jakie korzyści płyną z przejścia z aplikacji monolitycznej na architekturę mikroserwisów? Podzielenie aplikacji na mikroserwisy daje opisane poniżej korzyści, z których większość wywodzi się z faktu, że mikroserwisy są ze sobą luźno powiązane:

• Mikroserwisy można testować i wdrażać niezależnie. Im mniejsza jest jednostka wdrożenia, tym łatwiej ją wdrożyć.
• Mogą być implementowane w różnych językach i na różnych platformach. Dla poszczególnych mikroserwisów można wybrać najlepszą technologię na potrzeby konkretnego przypadku użycia.
• Mogą być zarządzane przez różne zespoły. Dzięki istnieniu granic między mikroserwisami łatwiej jest przydzielić zespół do 1 lub kilku mikroserwisów.
• Przejście na technologię mikroserwisów przyczynia się do rozluźnienia zależności między zespołami. Poszczególne zespoły muszą się zajmować tylko interfejsami API tych mikroserwisów, z którymi łączą je współzależności. Członkowie zespołów nie muszą wiedzieć, jak te mikroserwisy zostały zaimplementowane, jakie są ich cykle wydań itd.
• Prostsze jest też projektowanie reakcji na awarie. Dzięki istnieniu wyraźnych granic między usługami łatwiej można określić, jakie czynności należy wykonać w przypadku wyłączenia usługi.

W porównaniu z monolitami mikroserwisy mają też swoje wady. Oto kilka z nich:

• Aplikacja bazująca na mikroserwisach to sieć różnych usług, które często wchodzą ze sobą w nieoczekiwane interakcje, dlatego ogólna złożoność takiego systemu staje się coraz większa.
• W przeciwieństwie do komponentów aplikacji monolitycznych mikroserwisy komunikują się przez sieć. W pewnych okolicznościach może to powodować problemy z zabezpieczeniami. Istio rozwiązuje ten problem przez automatyczne szyfrowanie ruchu między mikroserwisami.
• Osiągnięcie takiego samego poziomu wydajności, jakim charakteryzują się aplikacje monolityczne, może okazać się trudne z powodu występowania opóźnień między usługami.
• Zachowanie całego systemu jest wynikiem nie tylko zachowania pojedynczej usługi, ale wielu z nich oraz występujących między nimi interakcji. Z tego powodu trudniej jest zrozumieć, w jaki sposób system zachowa się w środowisku produkcyjnym (jaka będzie jego dostrzegalność). Istio oferuje rozwiązanie także tego problemu.

W tym module wdrożysz istniejącą aplikację monolityczną w klastrze Google Kubernetes Engine, a następnie podzielisz ją na mikroserwisy. Kubernetes to platforma umożliwiająca hostowanie, skalowanie i wdrażanie kontenerów oraz zarządzanie nimi. Kontenery to przenośny sposób pakowania i uruchamiania kodu. Są one szczególnie przydatne w modelu mikroserwisów, w którym poszczególne mikroserwisy działają we własnych kontenerach.

Schemat architektury naszych mikroserwisów

Zacznij od podzielenia monolitu kolejno na 3 mikroserwisy. Będą one nosiły nazwy Orders (Zamówienia), Products (Produkty) i Frontend. Za pomocą Cloud Build dla każdego z mikroserwisów utwórz obraz Dockera. Następnie wdróż i udostępnij te mikroserwisy w Google Kubernetes Engine (GKE) z usługą Kubernetes typu LoadBalancer. Wykonasz to zadanie dla każdej usługi z jednoczesną ich refaktoryzacją z monolitu. Podczas trwania tego procesu będą działały zarówno mikroserwisy, jak i monolit, aż do samego końca, kiedy monolit zostanie ostatecznie usunięty.

Czego się nauczysz

• Jak podzielić monolit na mikroserwisy
• Jak utworzyć klaster Google Kubernetes Engine
• Jak utworzyć obraz Dockera
• Jak wdrożyć obrazy Dockera w klastrach Kubernetes

Wymagania wstępne

• Konto Google Cloud z dostępem administracyjnym do tworzenia projektów lub projekt z rolą właściciela projektu
• Podstawowa znajomość technologii Docker i Kubernetes

Konfiguracja i wymagania

Zanim klikniesz przycisk Rozpocznij moduł

Zapoznaj się z tymi instrukcjami. Moduły mają limit czasowy i nie można ich zatrzymać. Gdy klikniesz Rozpocznij moduł, na liczniku wyświetli się informacja o tym, na jak długo udostępniamy Ci zasoby Google Cloud.

W tym praktycznym module możesz spróbować swoich sił w wykonywaniu opisywanych działań w prawdziwym środowisku chmury, a nie w jego symulacji lub wersji demonstracyjnej. Otrzymasz nowe, tymczasowe dane logowania, dzięki którym zalogujesz się i uzyskasz dostęp do Google Cloud na czas trwania modułu.

Do ukończenia modułu potrzebne będą:

• dostęp do standardowej przeglądarki internetowej (zalecamy korzystanie z przeglądarki Chrome).

Uwaga: uruchom ten moduł w oknie incognito lub przeglądania prywatnego. Dzięki temu unikniesz konfliktu między swoim kontem osobistym a kontem do nauki, co mogłoby spowodować naliczanie oddatkowych opłat na koncie osobistym.

• Odpowiednia ilość czasu na ukończenie modułu – pamiętaj, że gdy rozpoczniesz, nie możesz go wstrzymać.

Uwaga: jeśli masz już osobiste konto lub projekt w Google Cloud, nie używaj go w tym module, aby uniknąć naliczania opłat na koncie.

Rozpoczynanie modułu i logowanie się w konsoli Google Cloud

1. Kliknij przycisk Rozpocznij moduł. Jeśli moduł jest odpłatny, otworzy się wyskakujące okienko, w którym możesz wybrać formę płatności. Po lewej stronie znajduje się panel Szczegóły modułu z następującymi elementami:

   • przyciskiem Otwórz konsolę Google Cloud;
   • czasem, który Ci pozostał;
   • tymczasowymi danymi logowania, których musisz użyć w tym module;
   • innymi informacjami potrzebnymi do ukończenia modułu.

2. Kliknij Otwórz konsolę Google Cloud (lub kliknij prawym przyciskiem myszy i wybierz Otwórz link w oknie incognito, jeśli korzystasz z przeglądarki Chrome).

   Moduł uruchomi zasoby, po czym otworzy nową kartę ze stroną logowania.

   Wskazówka: otwórz karty obok siebie w osobnych oknach.

   Uwaga: jeśli pojawi się okno Wybierz konto, kliknij Użyj innego konta.

3. W razie potrzeby skopiuj nazwę użytkownika znajdującą się poniżej i wklej ją w oknie logowania.

   {{{user_0.username | "Username"}}}

   Nazwę użytkownika znajdziesz też w panelu Szczegóły modułu.

4. Kliknij Dalej.

5. Skopiuj podane niżej hasło i wklej je w oknie powitania.

   {{{user_0.password | "Password"}}}

   Hasło znajdziesz też w panelu Szczegóły modułu.

6. Kliknij Dalej.

   Ważne: musisz użyć danych logowania podanych w module. Nie używaj danych logowania na swoje konto Google Cloud. Uwaga: korzystanie z własnego konta Google Cloud w tym module może wiązać się z dodatkowymi opłatami.

7. Na kolejnych stronach wykonaj następujące czynności:

   • Zaakceptuj Warunki korzystania z usługi.
   • Nie dodawaj opcji odzyskiwania ani uwierzytelniania dwuskładnikowego (ponieważ konto ma charakter tymczasowy).
   • Nie rejestruj się w bezpłatnych wersjach próbnych.

Poczekaj, aż na karcie otworzy się konsola Google Cloud.

Uwaga: aby wyświetlić menu z listą produktów i usług Google Cloud, w lewym górnym rogu kliknij Menu nawigacyjne.

Aktywowanie Cloud Shell

Cloud Shell to maszyna wirtualna oferująca wiele narzędzi dla programistów. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud. Dzięki wierszowi poleceń Cloud Shell zyskujesz dostęp do swoich zasobów Google Cloud.

1. Kliknij Aktywuj Cloud Shell  na górze konsoli Google Cloud.

Po połączeniu użytkownik od razu jest uwierzytelniony. Uruchomi się Twój projekt o identyfikatorze PROJECT_ID. Dane wyjściowe zawierają wiersz z zadeklarowanym identyfikatorem PROJECT_ID dla tej sesji:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud to narzędzie wiersza poleceń Google Cloud. Jest ono już zainstalowane w Cloud Shell i obsługuje funkcję autouzupełniania po naciśnięciu tabulatora.

2. (Opcjonalnie) Aby wyświetlić listę aktywnych kont, użyj tego polecenia:

gcloud auth list

3. Kliknij Autoryzuj.

4. Dane wyjściowe powinny wyglądać tak:

Dane wyjściowe:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Opcjonalnie) Aby wyświetlić identyfikator projektu, użyj tego polecenia:

gcloud config list project

Dane wyjściowe:

[core] project = <project_ID>

Przykładowe dane wyjściowe:

[core] project = qwiklabs-gcp-44776a13dea667a6 Uwaga: pełną dokumentację gcloud w Google Cloud znajdziesz w opisie narzędzia wiersza poleceń gcloud.

Ustaw domyślną strefę i konfigurację projektu:

gcloud config set compute/zone {{{project_0.default_zone | (zone)}}}

Zadanie 1. Klonowanie repozytorium źródłowego

Skorzystasz z istniejącej aplikacji monolitycznej pochodzącej z fikcyjnej witryny e-commerce, w skład której wchodzi prosta strona powitalna, strona z produktami oraz strona z historią zamówień. Po sklonowaniu kodu źródłowego z repozytorium Git będzie można skoncentrować się na podzieleniu aplikacji na mikroserwisy i wdrożeniu ich w Google Kubernetes Engine (GKE).

• Uruchom następujące polecenia, aby sklonować repozytorium Git do instancji Cloud Shell i przejść do odpowiedniego katalogu. Zainstalujesz również zależności NodeJS umożliwiające przetestowanie monolitu przed wdrożeniem:

cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh

Działanie tego skryptu może potrwać kilka minut.

Zadanie 2. Tworzenie klastra GKE

Skoro masz już działające środowisko programistyczne, potrzebujesz teraz klastra Kubernetes, w którym wdrożysz swój monolit, a na koniec także mikroserwisy. Przed utworzeniem klastra upewnij się, że są włączone odpowiednie interfejsy API.

1. Uruchom następujące polecenie, aby włączyć interfejs API kontenerów umożliwiający skorzystanie z Google Kubernetes Engine:

gcloud services enable container.googleapis.com

2. Uruchom poniższe polecenie, aby utworzyć klaster GKE o nazwie fancy-cluster z 3 węzłami:

gcloud container clusters create fancy-cluster --num-nodes 3 --machine-type=e2-standard-4 Ostrzeżenie: jeśli pojawi się komunikat o błędzie z informacją, że nie określono regionu lub strefy, przejdź do sekcji konfiguracji środowiska i upewnij się, że ustawiono domyślną strefę obliczeniową.

Tworzenie klastra może potrwać kilka minut.

3. Po zakończeniu wykonywania tego polecenia uruchom następujące polecenie, aby wyświetlić 3 instancje robocze znajdujące się w klastrze:

gcloud compute instances list

Dane wyjściowe:

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.6 XX.XX.XX.XX RUNNING

Klaster Kubernetes oraz związane z nim informacje możesz również wyświetlić w konsoli Cloud. W menu nawigacyjnym przewiń w dół do Kubernetes Engine i kliknij Klastry.

Zobaczysz klaster o nazwie fancy-cluster.

Gratulacje! Właśnie udało Ci się utworzyć pierwszy klaster Kubernetes.

Kliknij Sprawdź postępy, aby zobaczyć, jak Ci poszło. Utworzenie klastra GKE

Zadanie 3. Wdrażanie istniejącego monolitu

Ponieważ najważniejszym zadaniem do wykonania w tym module jest podzielenie monolitu na mikroserwisy, najpierw musisz uruchomić aplikację monolityczną.

• Uruchom następujący skrypt, aby wdrożyć aplikację monolityczną w klastrze GKE:

cd ~/monolith-to-microservices ./deploy-monolith.sh

Uzyskiwanie dostępu do monolitu

1. Aby znaleźć zewnętrzny adres IP aplikacji monolitycznej, uruchom następujące polecenie:

kubectl get service monolith

Zostaną wyświetlone dane wyjściowe podobne do tych:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d

2. Jeśli w danych wyjściowych zewnętrzny adres IP jest określony jako <pending>, odczekaj chwilę i ponownie uruchom to polecenie.

3. Skopiuj wyświetlony zewnętrzny adres IP monolitu. Wpisz ten adres URL (na przykład http://203.0.113.0) w przeglądarce, aby sprawdzić, czy do monolitu można uzyskać dostęp.

Uwaga: zapamiętaj ten adres IP, ponieważ będzie on potrzebny w następnych krokach. W razie potrzeby zawsze możesz go wyświetlić za pomocą tego samego polecenia.

Powinna wyświetlić się strona powitalna witryny monolitycznej. Strona powitalna jest stroną statyczną, która później będzie udostępniana przez mikroserwis Frontend. Twój monolit działa teraz całkowicie w klastrze Kubernetes.

Kliknij Sprawdź postępy, aby zobaczyć, jak Ci poszło. Wdrożenie istniejącego monolitu

Zadanie 4. Przeniesienie usługi Orders do mikroserwisu

Teraz gdy Twoja witryna monolitowa działa w GKE, nadszedł czas na podzielenie poszczególnych usług na mikroserwisy. Dobrym rozwiązaniem jest wcześniejsze zaplanowanie, które usługi mają zostać podzielone na mniejsze fragmenty. Zwykle najlepiej nadają się do tego poszczególne części aplikacji obsługujące konkretne obszary biznesowe.

W tym module utworzysz przykładową aplikację i wydzielisz z niej poszczególne usługi według obsługiwanych obszarów biznesowych: Orders (Zamówienia), Products (Produkty) i Frontend. Kod został już przeniesiony, więc możesz skupić się na tworzeniu i wdrażaniu usług w Google Kubernetes Engine (GKE).

Tworzenie nowego mikroserwisu do obsługi zamówień

Najpierw wydzielisz usługę Orders (Zamówienia). Korzystając z udostępnionej oddzielnej bazy kodu, utwórz osobny kontener Dockera dla tej usługi.

Tworzenie kontenera Dockera za pomocą Cloud Build

Ponieważ baza kodu jest już dostępna, pierwszym krokiem będzie utworzenie kontenera Dockera z usługą Order za pomocą Cloud Build.

Zwykle na ten proces składają się 2 kroki: utworzenie kontenera Dockera i przeniesienie go do rejestru w celu zapisania obrazu pobieranego potem przez GKE. Jeśli skorzystasz z Cloud Build, możesz za pomocą jednego polecenia utworzyć kontener Dockera oraz umieścić obraz w Container Registry. Dzięki temu, wykonując jedno polecenie, możesz utworzyć obraz i przenieść go do rejestru kontenerów. Aby prześledzić proces ręcznego tworzenia pliku Dockera i jego przenoszenia, zapoznaj się z krótkim wprowadzeniem do Container Registry (w języku angielskim), które znajduje się w dokumentacji Google Cloud Container Registry.

Google Cloud Build skompresuje pliki znajdujące się w katalogu i przeniesie je do zasobnika Cloud Storage. Następnie w procesie kompilacji wszystkie pliki z zasobnika razem z plikiem Dockerfile zostaną użyte do uruchomienia procesu kompilacji Dockera. Dla obrazu Dockera jest określana flaga --tag z hostem gcr.io, a wynikowy obraz Dockera jest przenoszony do Google Cloud Container Registry.

1. Uruchom następujące polecenie, aby utworzyć kontener Dockera i przenieść go do Google Container Registry:

cd ~/monolith-to-microservices/microservices/src/orders gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .

Ten proces może chwilę potrwać, a po jego zakończeniu w terminalu pojawią się dane wyjściowe podobne do tych poniżej:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io//orders:1.0.0 SUCCESS

2. Aby wyświetlić historię kompilacji lub obserwować ten proces w czasie rzeczywistym, w lewym górnym rogu w konsoli kliknij przycisk Menu nawigacyjne, przewiń w dół do sekcji CI/CD i kliknij Cloud Build > Historia. Tutaj znajdziesz listę wszystkich utworzonych do tej pory kompilacji. Na razie powinna być tam widoczna tylko 1 kompilacja utworzona przed chwilą.

Po kliknięciu identyfikatora kompilacji zostaną wyświetlone wszystkie jej szczegóły, w tym dane wyjściowe dzienników.

Aby wyświetlić utworzony obraz kontenera, na stronie ze szczegółami kompilacji, w sekcji po prawej, kliknij kartę Szczegóły wykonania, a następnie „Zobacz obraz”.

Wdrażanie kontenera w GKE

Po umieszczeniu witryny w kontenerze i przeniesieniu kontenera do Google Container Registry nadszedł czas na wdrożenie w Kubernetes.

Kubernetes prezentuje aplikacje jako pody, czyli jednostki reprezentujące kontener (lub grupę ściśle połączonych kontenerów). Pod to najmniejsza możliwa do wdrożenia jednostka w Kubernetes. W tym samouczku poszczególne pody zawierają tylko kontenery mikroserwisów.

Aby móc wdrażać aplikacje w klastrze GKE i nimi zarządzać, należy skomunikować się z systemem zarządzania klastrami Kubernetes. Zwykle robi się to za pomocą narzędzia wiersza poleceń kubectl w Cloud Shell.

Najpierw utwórz zasób Deployment. Deployment zarządza wieloma kopiami aplikacji nazywanymi replikami i planuje ich uruchamianie w poszczególnych węzłach w klastrze. W tym przypadku Deployment uruchomi tylko jeden pod Twojej aplikacji. Aby wszystko działało bezproblemowo, zasoby Deployment tworzą kontroler ReplicaSet. ReplicaSet odpowiada za to, aby zawsze działała określona liczba replik.

Widoczne poniżej polecenie kubectl create deployment powoduje utworzenie w klastrze Kubernetes zasobu Deployment o nazwie Orders z 1 repliką.

• Uruchom to polecenie, aby wdrożyć swoją aplikację:

kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 Uwaga: zalecaną praktyką jest użycie pliku YAML do zadeklarowania zmian w klastrze Kubernetes (np. utworzenia lub zmodyfikowania wdrożenia albo usługi) oraz systemu kontroli źródła, takiego jak GitHub lub Cloud Source Repositories, w którym te zmiany są przechowywane. Więcej informacji na ten temat znajdziesz w dokumentacji dotyczącej wdrożeń Kubernetes (w języku angielskim).

Sprawdzanie wdrożenia

• Aby sprawdzić, czy zasób Deployment został utworzony, uruchom następujące polecenie:

kubectl get all

Zmiana stanu poda na Uruchomiono może chwilę potrwać.

Dane wyjściowe:

NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s

Widać zasób Deployment, który jest aktualny, kontroler replicaset z pożądaną liczbą podów równą 1 oraz działający pod. Wygląda na to, że udało się utworzyć wszystkie elementy.

Wdrożenia Kubernetes można również wyświetlić w konsoli Cloud. W tym celu w menu nawigacyjnym wybierz Kubernetes Engine > Zadania.

Udostępnianie kontenera GKE

Wdrożyliśmy naszą aplikację w GKE, ale nie mamy możliwości uzyskania do niej dostępu spoza klastra. Domyślnie kontenery działające w GKE nie są dostępne z internetu, ponieważ nie mają zewnętrznych adresów IP. Należy bezpośrednio udostępnić aplikację dla ruchu z internetu za pomocą zasobu Service. Zasób Service udostępnia dla podów aplikacji obsługę sieci i adresu IP. GKE tworzy na potrzeby Twojej aplikacji zewnętrzny adres IP i system równoważenia obciążenia (podlega opłacie – zapoznaj się z cennikiem Compute Engine na stronie internetowej Google Cloud).

Na potrzeby tego modułu uprościliśmy proces udostępniania usługi. Zwykle do zabezpieczania publicznych punktów końcowych jest używana brama API. Zapoznaj się ze sprawdzonymi metodami obsługi mikroserwisów w Centrum architektury Google Cloud.

Po wdrożeniu usługi Orders została ona wewnętrznie udostępniona na porcie 8081 za pomocą wdrożenia Kubernetes. Aby udostępnić tę usługę zewnętrznie, musisz utworzyć usługę Kubernetes typu LoadBalancer, która skieruje ruch zewnętrzny z portu 80 na wewnętrzny port 8081.

• Aby udostępnić stronę w internecie, uruchom następujące polecenie:

kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081

Uzyskiwanie dostępu do usługi

GKE przypisuje zewnętrzny adres IP do zasobu Service, a nie do zasobu Deployment.

• Aby dowiedzieć się, jaki jest zewnętrzny adres IP udostępniony przez GKE dla aplikacji, możesz sprawdzić zasób Service za pomocą polecenia kubectl get service:

kubectl get service orders

Dane wyjściowe:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3s

Skopiuj wyświetlony zewnętrzny adres IP aplikacji. Zapisz go, ponieważ będzie on potrzebny w następnym kroku, w którym zmodyfikujesz monolit, aby wskazywał na nową usługę Orders.

Ponowne konfigurowanie monolitu

Ponieważ z monolitu usunięto usługę Orders, należy go zmodyfikować w taki sposób, aby wskazywał na nowy zewnętrzny mikroserwis Orders.

Rozdzielanie monolitu polega na usunięciu fragmentów kodu z pojedynczej bazy kodu i umieszczeniu ich w wielu mikroserwisach, które są następnie oddzielnie wdrażane. Mikroserwisy działają na innym serwerze, dlatego nie możesz już przywoływać adresów URL usług w postaci ścieżek bezwzględnych – musisz zastosować przekierowanie na adres serwera mikroserwisu zamówień. Konieczne będzie wyłączenie usługi monolitu na pewien czas, aby zaktualizować adresy URL poszczególnych usług, które zostały usunięte z monolitu. Weź to pod uwagę, gdy planujesz przenoszenie mikroserwisów i monolitu do środowiska produkcyjnego w czasie migracji do mikroserwisów.

Musisz też zaktualizować plik konfiguracyjny monolitu tak, aby wskazywał na nowy adres IP mikroserwisu Orders.

1. W edytorze nano zastąp lokalny adres URL adresem IP mikroserwisu Orders:

cd ~/monolith-to-microservices/react-app nano .env.monolith

Po otwarciu w edytorze Twój plik powinien wyglądać tak:

REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products

2. Zapisz adres REACT_APP_ORDERS_URL w nowym formacie, zastępując go adresem IP mikroserwisu Orders. Całość powinna wyglądać tak jak poniżej:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products

3. Naciśnij kolejno CTRL + O, ENTER i CTRL + X, aby zapisać plik w edytorze nano.

4. Przetestuj nowy mikroserwis, przechodząc do adresu URL ustawionego w pliku. Strona internetowa powinna zwrócić odpowiedź JSON z mikroserwisu Orders.

5. Teraz utwórz ponownie frontend monolitu, powtórz proces kompilacji, aby utworzyć kontener dla monolitu, a na koniec przeprowadź ponowne wdrożenie w klastrze GKE:

• Ponownie utwórz pliki konfiguracyjne monolitu:

npm run build:monolith

6. Utwórz kontener Dockera za pomocą Cloud Build:

cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

7. Wdróż kontener w GKE:

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0

8. Sprawdź, czy aplikacja może się komunikować z mikroserwisem Orders. W tym celu przejdź do swojej aplikacji monolitycznej w przeglądarce i spróbuj wyświetlić stronę Orders (Zamówienia). Wszystkie identyfikatory zamówień powinny się kończyć ciągiem -MICROSERVICE, jak poniżej:

9. Kliknij Sprawdź postępy, aby zobaczyć, jak Ci poszło. Przeniesienie usługi Orders do mikroserwisu

Zadanie 5. Przeniesienie usługi Products do mikroserwisu

Tworzenie nowego mikroserwisu Products

Kontynuuj proces odłączania usług, migrując tym razem usługę Products. Zastosuj taką samą procedurę jak poprzednio. Uruchom następujące polecenia, aby utworzyć kontener Dockera, wdrożyć go i udostępnić za pomocą usługi Kubernetes.

1. Utwórz kontener Dockera za pomocą Cloud Build:

cd ~/monolith-to-microservices/microservices/src/products gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .

2. Wdróż kontener w GKE:

kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0

3. Udostępnij kontener GKE:

kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082

4. Znajdź publiczny adres IP usługi Products w taki sam sposób jak w przypadku usługi Orders:

kubectl get service products

Dane wyjściowe:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d

Będziesz potrzebować tego adresu IP w następnym kroku podczas ponownego konfigurowania monolitu, aby wskazywał na nowy mikroserwis Products.

Ponowne konfigurowanie monolitu

1. W edytorze nano zastąp lokalny adres URL adresem IP nowego mikroserwisu produktów:

cd ~/monolith-to-microservices/react-app nano .env.monolith

Po otwarciu w edytorze Twój plik powinien wyglądać tak:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products

2. Zapisz adres REACT_APP_PRODUCTS_URL w nowym formacie, zastępując go adresem IP mikroserwisu produktów. Całość powinna wyglądać tak jak poniżej:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products

3. Naciśnij kolejno CTRL + O, ENTER i CTRL + X, aby zapisać plik.

4. Przetestuj nowy mikroserwis, przechodząc do adresu URL ustawionego w pliku. Strona internetowa powinna zwrócić odpowiedź JSON z mikroserwisu Products.

5. Teraz utwórz ponownie frontend monolitu, powtórz proces kompilacji w celu utworzenia kontenera dla monolitu, a na koniec przeprowadź ponowne wdrożenie w klastrze GKE. Uruchom następujące polecenia, aby zakończyć te kroki:

6. Ponownie utwórz pliki konfiguracyjne monolitu:

npm run build:monolith

7. Utwórz kontener Dockera za pomocą Cloud Build:

cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .

8. Wdróż kontener w GKE:

kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0

9. Sprawdź, czy aplikacja może się komunikować z nowym mikroserwisem Products. W tym celu przejdź do aplikacji monolitycznej w przeglądarce i spróbuj wyświetlić stronę Products (Produkty). Wszystkie nazwy produktów powinny mieć prefiks MS-, jak poniżej:

10. Kliknij Sprawdź postępy, aby zobaczyć, jak Ci poszło. Przeniesienie usługi Products do mikroserwisu

Zadanie 6. Przeniesienie frontendu do mikroserwisu

Ostatnim krokiem w procesie migracji jest przeniesienie kodu frontendu do mikroserwisu i wyłączenie monolitu. Zakończenie tego kroku będzie oznaczać pomyślne przejście z monolitu na architekturę mikroserwisów.

Tworzenie nowego mikroserwisu frontendu

Aby utworzyć nowy mikroserwis frontendu, zastosuj taką samą procedurę jak w ostatnich 2 krokach.

Poprzednio podczas rekompilacji monolitu aktualizowała się też konfiguracja, aby wskazywać na monolit. Teraz zastosuj taką samą konfigurację dla mikroserwisu frontendu.

1. Uruchom następujące polecenia, aby skopiować pliki konfiguracyjne adresów URL mikroserwisów do bazy kodu mikroserwisu frontendu:

cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build

2. Po zakończeniu działania tych poleceń wykonaj takie same czynności jak w poprzednich krokach. Uruchom następujące polecenia, aby utworzyć kontener Dockera, wdrożyć go i udostępnić za pomocą usługi Kubernetes.

3. Utwórz kontener Dockera za pomocą Google Cloud Build:

cd ~/monolith-to-microservices/microservices/src/frontend gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .

4. Wdróż kontener w GKE:

kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0

5. Udostępnij kontener GKE

kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080

6. Kliknij Sprawdź postępy, aby zobaczyć, jak Ci poszło. Przeniesienie frontendu do mikroserwisu

Usuwanie monolitu

Teraz gdy wszystkie usługi działają jako mikroserwisy, możesz usunąć aplikację monolityczną. Pamiętaj, że w przypadku rzeczywistej migracji konieczne byłoby również dokonanie zmian DNS itd., aby istniejące nazwy domen wskazywały nowy mikroserwis frontendu naszej aplikacji.

• Uruchom następujące polecenia, aby usunąć monolit:

kubectl delete deployment monolith kubectl delete service monolith

Sprawdzanie efektów pracy

Jeśli wszystko zostało wykonane prawidłowo, stary adres IP usługi monolitu nie powinien teraz działać, a pod nowym adresem IP usługi frontendu powinna być hostowana nowa aplikacja.

• Aby wyświetlić listę wszystkich usług i adresów IP, uruchom następujące polecenie:

kubectl get services

Dane wyjściowe powinny wyglądać podobnie do tych:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m

Skopiuj wyświetlony zewnętrzny adres IP mikroserwisu frontendu. Wpisz ten adres URL (na przykład http://203.0.113.0) w przeglądarce, aby sprawdzić, czy można uzyskać dostęp do frontendu. Twoja witryna powinna wyglądać tak samo jak przed podzieleniem monolitu na mikroserwisy.

Gratulacje!

Udało Ci się podzielić aplikację monolityczną na mikroserwisy i wdrożyć je w Google Kubernetes Engine.

Ukończ kurs

Ten moduł do samodzielnego ukończenia wchodzi w skład kursu Website on Google Cloud. Każdy kurs składa się z zestawu powiązanych ze sobą modułów, które razem tworzą ścieżkę szkoleniową. Jeśli zapiszesz się na ten kurs, ukończony dziś moduł zostanie w nim automatycznie zaliczony. Zapoznaj się z katalogiem Google Cloud Skills Boost, aby zobaczyć inne dostępne kursy.

Poszukujesz modułu praktycznego typu Challenge Lab (moduł-wyzwanie), aby wykazać się nowymi umiejętnościami i sprawdzić swoją wiedzę? Po ukończeniu kursu przejdź ten moduł Challenge Lab.

Przejdź do kolejnego modułu

Kontynuuj naukę, oglądając to filmowe studium przypadku na temat hostowania skalowalnych aplikacji internetowych w Google Cloud, lub zapoznaj się z tymi propozycjami:

• Tworzenie aplikacji internetowej w Google Cloud z użyciem Compute Engine
• Obejrzyj ten film na temat tworzenia statycznej aplikacji internetowej w Google Cloud

Kolejne kroki / dodatkowe materiały

• [Dokumentacja Dockera]https://docs.docker.com/
• Dokumentacja Kubernetes
• Dokumentacja Google Kubernetes Engine (GKE)
• Dokumentacja Google Cloud Build
• Dokumentacja Google Container Registry
• Migracja monolitów do mikroserwisów
• Sprawdzone metody związane z mikroserwisami

Szkolenia i certyfikaty Google Cloud

…pomogą Ci wykorzystać wszystkie możliwości technologii Google Cloud. Nasze zajęcia obejmują umiejętności techniczne oraz sprawdzone metody, które ułatwią Ci szybką naukę i umożliwią jej kontynuację. Oferujemy szkolenia na poziomach od podstawowego po zaawansowany prowadzone w trybach wirtualnym, na żądanie i na żywo, dzięki czemu możesz dopasować program szkoleń do swojego napiętego harmonogramu. Certyfikaty umożliwią udokumentowanie i potwierdzenie Twoich umiejętności oraz doświadczenia w zakresie technologii Google Cloud.

Ostatnia aktualizacja instrukcji: 20 września 2023 r.

Ostatni test modułu: 20 września 2023 r.

Copyright 2024 Google LLC. Wszelkie prawa zastrzeżone. Google i logo Google są znakami towarowymi Google LLC. Wszelkie inne nazwy firm i produktów mogą być znakami towarowymi odpowiednich podmiotów, z którymi są powiązane.