1. Wprowadzenie
Ostatnia aktualizacja: 6.05.2021
Mikroserwis Rainbow Rumpus
Czy kiedykolwiek brałeś/brałaś udział w bitwie na śnieżki, w której rzucasz śnieżkami w inne osoby? Jeśli nie, spróbuj to zrobić w przyszłości. Teraz, zamiast narażać się na fizyczne obrażenia, możesz zbudować małą usługę dostępną w sieci (mikroserwis), która weźmie udział w niezapomnianej walce z innymi mikroserwisami, rzucając tęcze zamiast śnieżek.
Być może zastanawiasz się... Ale jak mikroserwis „rzuca” tę tęczę do innych mikroserwisów? Mikroserwis może otrzymywać żądania sieciowe (zwykle przez HTTP) i zwracać odpowiedzi. Jest tu „menedżer areny” który wyśle do mikroserwisu bieżący stan areny, a mikroserwis zareaguje, wykonując polecenie określające, co należy zrobić.
Oczywiście celem jest zwycięstwo, ale przy okazji dowiesz się, jak tworzyć i wdrażać mikroserwisy w Google Cloud.
Jak to działa
Zbudujesz mikroserwis z dowolną technologią (lub wybierz startery w językach Go, Java, Kotlin, Scala, NodeJS bądź Python), a następnie wdrożysz go w Google Cloud. Po wdrożeniu podasz nam adres URL mikroserwisu, a my dodamy go do areny.
Hala zawiera wszystkich graczy biorących udział w danej bitwie. Tęczowa rumpus będzie miała swoje areny. Każdy gracz reprezentuje mikroserwis, który porusza się wokół i rzuca tęczą w stronę pozostałych graczy.
Nasz menedżer areny będzie co około sekundę wywoływać Twój mikroserwis, przesyłając aktualny stan areny (gdzie znajdują się gracze), a Twój mikroserwis będzie odpowiadać poleceniem, co należy zrobić. Na arenie możesz się poruszać do przodu, skręcać w lewo lub w prawo albo rzucać tęczę. Tęcza przemieszcza się w kierunku, w którym jest zwrócony gracz, maksymalnie trzy przestrzenie. Jeśli tęcza zacznie działać inny zawodnik, rzucający otrzymuje jeden punkt, a zawodnik uderzony traci punkt. Rozmiar areny jest automatycznie dostosowywany do bieżącej liczby graczy.
Tak wygląda arena z przeszłości:
Przykładowa arena Battle One
Konflikty dotyczące obrotu
Na arenie może się zdarzyć, że wielu graczy będzie próbowało wykonać sprzeczne z nimi działania. Na przykład dwóch graczy może próbować przejść do tego samego miejsca. W przypadku konfliktu zwycięża mikrousługa z najkrótszym czasem odpowiedzi.
Oglądanie bitwy
Aby zobaczyć, jak Twój mikroserwis radzi sobie w walce, odwiedź naszą arenę.
Battle API
Aby współpracować z naszym menedżerem areny, Twój mikroserwis musi wdrożyć odpowiedni interfejs API, aby mieć dostęp do tych funkcji. Menedżer areny wyśle bieżący stan areny w postu HTTP na podany przez Ciebie adres URL w ramach tej struktury JSON:
{
"_links": {
"self": {
"href": "https://YOUR_SERVICE_URL"
}
},
"arena": {
"dims": [4,3], // width, height
"state": {
"https://A_PLAYERS_URL": {
"x": 0, // zero-based x position, where 0 = left
"y": 0, // zero-based y position, where 0 = top
"direction": "N", // N = North, W = West, S = South, E = East
"wasHit": false,
"score": 0
}
... // also you and the other players
}
}
}
Odpowiedź HTTP musi mieć kod stanu 200 (OK) i tekst odpowiedzi zawierający następny ruch, zakodowany jako pojedynczy znak wielkich liter:
F <- move Forward
R <- turn Right
L <- turn Left
T <- Throw
To już wszystko. Zobaczmy, jak wdrożyć mikroserwis w Cloud Run, usłudze Google Cloud do uruchamiania mikroserwisów i innych aplikacji.
2. Logowanie do Google Cloud
Aby móc wdrożyć mikrousługę w Cloud Run, musisz się zalogować w Google Cloud. Uwzględnimy środki na Twoim koncie – nie musisz podawać danych karty kredytowej. Zwykle użycie konta osobistego (np. gmail.com) zamiast konta G Suite jest zazwyczaj mniej problemów, ponieważ czasami administratorzy G Suite uniemożliwiają użytkownikom korzystanie z niektórych funkcji Google Cloud. Używana konsola powinna też dobrze działać z przeglądarkami Chrome i Firefox, ale w Safari mogą występować problemy.
3. Wdrażanie mikroserwisu
Mikroserwis możesz tworzyć za pomocą dowolnej technologii i wdrażać w dowolnym miejscu, o ile jest publicznie dostępny i zgodny z interfejsem Battle API. Dla ułatwienia pomożemy Ci zacząć od przykładowej usługi i wdrożyć ją w Cloud Run.
Wybierz sampel na początek
Jest wiele przykładowych mikroserwisów bitewnych, od których możesz zacząć:
Kotlin i Spring Boot | ||
Kotlin i Mikronaut | ||
Kotlin i Quarkus | ||
Java i Trzewik wiosenny | ||
Java i Quark (język programowania) | ||
Przeczytaj | ||
Node.js i Express | ||
Python i Piersiówka |
Gdy zdecydujesz, od którego przykładu zacząć, kliknij przycisk „Wdróż w Cloud Run” powyżej. Spowoduje to uruchomienie Cloud Shell (internetowej konsoli maszyny wirtualnej w chmurze), w której zostanie sklonowane źródło, a następnie wbudowane w możliwy do wdrożenia pakiet (obraz kontenera Dockera), który następnie zostanie przesłany do Google Container Registry i wdrożony w Cloud Run.
Gdy pojawi się prośba, określ region us-central1
.
Zrzut ekranu poniżej przedstawia dane wyjściowe Cloud Shell dotyczące kompilacji i wdrażania mikroserwisów
Sprawdzanie działania mikrousługi
W Cloud Shell możesz wysłać żądanie do nowo wdrożonego mikroserwisu, zastępując YOUR_SERVICE_URL
adresem URL swojej usługi (znajdujący się w Cloud Shell po wierszu „Twoja aplikacja jest teraz aktywna”):
curl -d '{ "_links": { "self": { "href": "https://foo.com" } }, "arena": { "dims": [4,3], "state": { "https://foo.com": { "x": 0, "y": 0, "direction": "N", "wasHit": false, "score": 0 } } } }' -H "Content-Type: application/json" -X POST -w "\n" \ https://YOUR_SERVICE_URL
Powinieneś zobaczyć ciąg znaków odpowiedzi: F
, L
, R
lub T
.
4. Prośba o uwzględnienie w Arenach
Aby dołączyć do Rainbow Rumpus, musisz dołączyć do areny. Otwórz rainbowrumpus.dev, kliknij Dołącz na arenie, gdzie podasz adres URL swojej mikrousługi.
5. Marka i Wdrażanie zmian
Zanim wprowadzisz zmiany, musisz skonfigurować w Cloud Shell pewne informacje o projekcie GCP i użytym przykładzie. Najpierw wyświetl listę projektów GCP:
gcloud projects list
Prawdopodobnie masz tylko 1 projekt. Skopiuj wartość PROJECT_ID
z pierwszej kolumny i wklej ją w tym poleceniu (zastępując wartość YOUR_PROJECT_ID
swoim identyfikatorem projektu), aby ustawić zmienną środowiskową, której użyjemy w kolejnych poleceniach:
export PROJECT_ID=YOUR_PROJECT_ID
Teraz ustaw kolejną zmienną środowiskową dla użytego przykładu, aby w późniejszych poleceniach można było podać prawidłową nazwę katalogu i usługi:
# Copy and paste ONLY ONE of these export SAMPLE=kotlin-micronaut export SAMPLE=kotlin-quarkus export SAMPLE=kotlin-springboot export SAMPLE=java-quarkus export SAMPLE=java-springboot export SAMPLE=go export SAMPLE=nodejs export SAMPLE=python
Teraz możesz edytować źródło mikrousługi w Cloud Shell. Aby otworzyć internetowy edytor Cloud Shell, uruchom to polecenie:
cloudshell edit cloudbowl-microservice-game/samples/$SAMPLE/README.md
Zostaną wyświetlone dalsze instrukcje dotyczące wprowadzania zmian.
Cloud Shell z edytorem i otwartym przykładowym projektem
Po zapisaniu zmian uruchom aplikację w Cloud Shell za pomocą polecenia z pliku README.md
, ale najpierw upewnij się, że w Cloud Shell jesteś w prawidłowym katalogu przykładowym:
cd cloudbowl-microservice-game/samples/$SAMPLE
Gdy aplikacja się uruchomi, otwórz nową kartę Cloud Shell i przetestuj usługę za pomocą curl:
curl -d '{ "_links": { "self": { "href": "https://foo.com" } }, "arena": { "dims": [4,3], "state": { "https://foo.com": { "x": 0, "y": 0, "direction": "N", "wasHit": false, "score": 0 } } } }' -H "Content-Type: application/json" -X POST -w "\n" \ http://localhost:8080
Gdy zmiany będą gotowe do wdrożenia, utwórz projekt w Cloud Shell za pomocą polecenia pack
. To polecenie używa pakietów kompilacji do wykrywania typu projektu, skompilowania go i utworzenia możliwego do wdrożenia artefaktu (obrazu kontenera Dockera).
# Make sure you are in a Cloud Shell tab where you set the PROJECT_ID # and SAMPLE env vars. Otherwise, set them again. pack build gcr.io/$PROJECT_ID/$SAMPLE \ --path ~/cloudbowl-microservice-game/samples/$SAMPLE \ --builder gcr.io/buildpacks/builder
Po utworzeniu obrazu kontenera użyj polecenia docker (w Cloud Shell), aby przenieść obraz kontenera do rejestru kontenerów Google, aby był on dostępny dla Cloud Run:
docker push gcr.io/$PROJECT_ID/$SAMPLE
Teraz wdróż nową wersję w Cloud Run:
gcloud run deploy $SAMPLE \ --project=$PROJECT_ID \ --platform=managed \ --region=us-central1 \ --image=gcr.io/$PROJECT_ID/$SAMPLE \ --allow-unauthenticated
Arena będzie teraz używać nowej wersji.
6. Programuj lokalnie (opcjonalnie)
Aby pracować nad projektem lokalnie w swoim środowisku IDE, wykonaj te czynności:
- [W Cloud Shell] Spakuj przykład:
# Make sure the SAMPLE env var is still set. If not, re-set it. cd ~/cloudbowl-microservice-game/samples zip -r cloudbowl-sample.zip $SAMPLE
- [W Cloud Shell] Pobierz plik ZIP na swój komputer:
cloudshell download-file cloudbowl-sample.zip
- [Na Twoim komputerze] Rozpakuj plik, a następnie utwórz plik sprawdź zmiany
- [Na Twoim komputerze] Zainstaluj interfejs wiersza poleceń gcloud
- [Na komputerze] Zaloguj się w Google Cloud:
gcloud auth login
- [Na Twoim komputerze] Ustaw zmienne środowiskowe
PROJECT_ID
iSAMPLE
na te same wartości co w Cloud Shell. - [Na Twoim komputerze] Utwórz kontener za pomocą Cloud Build (z katalogu głównego projektu):
gcloud alpha builds submit . \ --pack=image=gcr.io/$PROJECT_ID/$SAMPLE \ --project=$PROJECT_ID
- [Na komputerze] Wdróż nowy kontener:
gcloud run deploy $SAMPLE \ --project=$PROJECT_ID \ --platform=managed \ --region=us-central1 \ --image=gcr.io/$PROJECT_ID/$SAMPLE \ --allow-unauthenticated
7. Tryb ciągłego dostarczania
Konfigurowanie SCM
Skonfiguruj GitHub, aby współpracować ze swoim zespołem nad mikroserwisem:
- Zaloguj się w GitHubie
- Tworzenie nowego repozytorium
- Jeśli pracujesz na komputerze lokalnym, możesz użyć interfejsu wiersza poleceń git (CLI) lub aplikacji GUI GitHub Desktop (Windows lub Mac). Jeśli korzystasz z Cloud Shell, musisz użyć interfejsu wiersza poleceń git. Aby pobrać kod mikroserwisu do GitHuba, postępuj zgodnie z instrukcjami interfejsu wiersza poleceń lub GitHub Desktop.
Pushowanie kodu za pomocą interfejsu wiersza poleceń git
- Postępuj zgodnie z instrukcjami git over https z osobistym tokenem dostępu
- Wybierz „repozytorium” zakres
- Skonfiguruj git:
git config --global credential.helper \ 'cache --timeout=172800' git config --global push.default current git config --global user.email "YOUR@EMAIL" git config --global user.name "YOUR NAME"
- Ustaw zmienne środowiskowe dla organizacji i repozytorium GitHub (
https://github.com/ORG/REPO
).
export GITHUB_ORG=YOUR_GITHUB_ORG export GITHUB_REPO=YOUR_GITHUB_REPO
- Przekazywanie kodu do nowego repozytorium
# Make sure the SAMPLE env var is still set. If not, re-set it. cd ~/cloudbowl-microservice-game/samples/$SAMPLE git init git add . git commit -m init git remote add origin https://github.com/$GITHUB_ORG/$GITHUB_REPO.git git branch -M main # This will now ask for your GitHub username & password # for the password use the personal access token git push -u origin main
- Po wprowadzeniu zmian możesz je zatwierdzić i przenieść do GitHuba:
git add . git status git diff --staged git commit -am "my changes" git push
Przekazywanie kodu za pomocą pulpitu GitHub
- Pobierz kod, postępując zgodnie z instrukcjami z poprzedniej części „Programowanie lokalnie”. moduł
- Zainstaluj aplikację GitHub Desktop, uruchom ją i zaloguj się
- Klonowanie nowo utworzonego repozytorium
- Otwórz Eksploratora plików i skopiuj projekt do nowego repozytorium
- Zatwierdź zmiany
- Publikowanie głównej gałęzi w GitHubie
Skonfiguruj ciągłe wdrażanie Cloud Run
Po skonfigurowaniu SCM w GitHubie możesz skonfigurować ciągłe dostarczanie, aby za każdym razem, gdy nowe zatwierdzenia zostaną przekazane do gałęzi main
, Cloud Build automatycznie kompilował i wdrażał zmiany. Możesz też dodać ciągłą integrację, która uruchamia testy przed wdrożeniem, ale ten krok pozostawiliśmy jako ćwiczenie, ponieważ gotowe przykłady nie zawierają żadnych testów.
- W konsoli Cloud otwórz usługę Cloud Run.
- Kliknij przycisk „Skonfiguruj ciągłe wdrażanie”.
- Uwierzytelnij się w GitHub i wybierz repozytorium mikrousługi
- Wybierz repozytorium GitHub i ustaw gałąź na:
^main$
- Ustaw typ kompilacji na Buildpacks
- Aby skonfigurować ciągłe wdrażanie, kliknij Zapisz.
8. Dostrzegalność
A teraz coś psuje. Dzięki możliwości obserwacji wiemy, kiedy to nastąpiło i dlaczego. Wskaźniki pokazują nam informacje o stanie i korzystaniu z naszej usługi. Logi pokazują ręcznie zinstruowane informacje wysyłane z naszej usługi. Dzięki alertom otrzymujesz powiadomienia, gdy coś poszło nie tak. Przyjrzyjmy się bliżej każdemu z nich.
Dane
- Znajdź swoją usługę na liście usług Cloud Run.
- Kliknij nazwę usługi, aby otworzyć panel danych tej usługi.
- Kliknij menu ⋮ danych i wybierz „Wyświetl w narzędziu Metrics Explorer”.
- Możesz teraz zmieniać dane zasobów, filtry, grupowanie i inne opcje. Możesz na przykład wyświetlić średnie czasy oczekiwania na usługę dla wszystkich usług:
Logi
Dane wyjściowe STDOUT z usług są wysyłane do systemu Google Cloud Logging. Na stronie administracyjnej usługi Cloud Run możesz uzyskać dostęp do podstawowego widoku logów, takiego jak:
W logach Cloud Run możesz filtrować według poziomu ważności i filtrować logi. Jeśli potrzebujesz większej swobody, kliknij:
Alerty
- Utwórz adres URL sprawdzania poprawności dla swojej usługi.
- W przypadku Spring Boot wystarczy dodać tę zależność:
org.springframework.boot:spring-boot-starter-actuator
- Utwórz lub zaktualizuj plik
src/main/resources/application.properties
i wyłącz sprawdzanie miejsca na dysku:
management.health.diskspace.enabled=false
- Utwórz alert dotyczący dostępności, podając protokół, nazwę hosta i ścieżkę. W przypadku Spring Boot ścieżka to:
/actuator/health
- Testowanie alertu
- Utwórz alert
9. Gratulacje
Gratulujemy! Udało Ci się utworzyć i wdrożyć mikroserwis, który radzi sobie z innymi mikroserwisami. Powodzenia!