Moduł 5. Migracja z Google App Engine do Cloud Run z użyciem pakietów Cloud Buildpack

1. Omówienie

Ta seria ćwiczeń z programowania (do samodzielnego ukończenia, praktycznych samouczków) ma pomóc deweloperom w modernizacji aplikacji korzystających z Google App Engine (wersja standardowa) przez przeprowadzenie serii migracji. Dzięki temu użytkownicy mogą zwiększyć przenośność swoich aplikacji, jawnie skonteneryzując je w Cloud Run, siostrzanej usłudze Google Cloud hostującej kontenery w App Engine i innych usługach hostowania kontenerów.

Z tego samouczka dowiesz się, jak konteneryzować aplikacje App Engine na potrzeby wdrażania w usłudze w pełni zarządzanej Cloud Run za pomocą Cloud Buildpacks, która jest alternatywą dla Dockera. Cloud Buildpacks skonteneryzują Twoje aplikacje bez konieczności zarządzania plikami Dockerfile czy nawet znajomości Dockera.

To ćwiczenie w Codelabs jest przeznaczone dla programistów App Engine w języku Python 2, którzy wycofali swoje aplikacje z oryginalnych wbudowanych usług i przenieśli je na język Python 3, a teraz chcą uruchamiać je w kontenerze. Ćwiczenia w Codelabs zaczynają się od ukończonej aplikacji w module 2 lub 3 w Pythonie 3.

Dowiesz się,

  • Konteneryzowanie aplikacji za pomocą Cloud Buildpacks
  • Wdrażanie obrazów kontenerów w Cloud Run

Czego potrzebujesz

Ankieta

Jak będziesz używać tego ćwiczenia z programowania?

tylko do przeczytania. Przeczytaj go i wykonaj ćwiczenia .

2. Tło

Systemy PaaS, takie jak App Engine i Cloud Functions, zapewniają wiele udogodnień dla zespołów i aplikacji. Na przykład te bezserwerowe platformy umożliwiają SysAdmin/Devopsa skupienie się na tworzeniu rozwiązań. Aplikację można autoskalować w górę w razie potrzeby, a rozliczać w dół do zera dzięki płatnościom na podstawie płatności za wykorzystanie, co ułatwia kontrolowanie kosztów. Aplikacje te są tworzone w różnych popularnych językach programowania.

Jednak elastyczność kontenerów także jest przekonująca – można wybrać dowolny język, dowolną bibliotekę, dowolny plik binarny. Google Cloud Run zapewnia użytkownikom to, co najlepsze w obu rozwiązaniach – wygodę korzystania z technologii bezserwerowych i elastyczność kontenerów.

W ramach tego ćwiczenia z programowania dowiesz się, jak korzystać z Cloud Run. które znajdziesz w dokumentacji Cloud Run. Dzięki temu dowiesz się, jak skonteneryzować aplikację App Engine na potrzeby Cloud Run (lub innych usług). Jest kilka rzeczy, o których należy wiedzieć przed przejściem. Przede wszystkim sposób korzystania z usługi będzie nieco inny, nieco niższy, ponieważ nie będzie już trzeba pobierać kodu aplikacji ani go wdrażać.

Zamiast tego musisz dowiedzieć się o kontenerach, na przykład jak je tworzyć i wdrażać. Musisz też zdecydować, co umieścić w obrazie kontenera, w tym także na serwerze WWW, ponieważ nie będzie już używany serwer WWW App Engine. Jeśli nie chcesz podążać tą ścieżką, pozostawienie aplikacji w App Engine nie jest złym rozwiązaniem.

Z tego samouczka dowiesz się, jak skonteneryzować aplikację, usunąć pliki konfiguracji App Engine, zarządzać serwerem WWW i jak uruchomić aplikację.

Ta migracja obejmuje te kroki:

  1. Konfiguracja/praca
  2. Konteneryzowanie aplikacji
    • Zastąp pliki konfiguracji
    • Modyfikowanie plików aplikacji

3. Konfiguracja/praca

Zanim przejdziemy do głównej części samouczka, skonfigurujmy projekt, pobierz kod, a potem wdróż aplikację bazową. Dzięki temu będziemy wiedzieć, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz już ukończony Moduł 2 lub Moduł 3 w Codelabs, zalecamy ponowne wykorzystanie tego samego projektu (i kodu). Możesz też utworzyć nowy projekt lub wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe i jest włączone (aplikacja) App Engine.

2. Pobierz przykładową aplikację bazową

Jednym z warunków wstępnych tego ćwiczenia z programowania jest posiadanie działającego modułu 2 lub 3 przykładowej aplikacji. Jeśli nie masz takiego samouczka, zalecamy wykonanie dowolnego z tych samouczków (linki powyżej), zanim przejdziesz dalej. Jeśli nie znasz już ich zawartości, możesz po prostu pobrać poniżej jeden z folderów z ich kodem.

Ten samouczek rozpoczyna się bez względu na to, czy używasz swoich czy naszych. To ćwiczenie w Codelabs przeprowadzi Cię przez proces migracji, a gdy skończysz, powinien być w większości zgodny z tym, co znajduje się w folderze repozytorium FINISH modułu 5.

Katalog plików START (Twoich lub naszych) powinien wyglądać następująco:

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

3. (Ponowne) wdrażanie aplikacji podstawowej

Pozostałe kroki do wykonania:

  1. Ponownie zapoznaj się z narzędziem wiersza poleceń gcloud
  2. Wdróż ponownie przykładową aplikację za pomocą gcloud app deploy
  3. Sprawdź, czy aplikacja działa w App Engine bez problemów

Po wykonaniu tych czynności możesz je skonteneryzować.

4. Konteneryzowanie aplikacji

Docker to obecnie standardowa platforma konteneryzacji w branży. Korzystanie z niej, jak już wspominaliśmy, wymaga dużego nakładu pracy ze strony Dockerfile, czyli pliku konfiguracji, który określa sposób tworzenia obrazów kontenerów. Z kolei pakiety Buildpacks wymagają niewielkiego wysiłku, ponieważ do określania zależności aplikacji wykorzystują introspekcję, dzięki czemu kontener Buildpacks jest maksymalnie wydajny.

Jesteś we właściwym miejscu, jeśli nie chcesz poznawać Dockera i chcesz skonteneryzować aplikację App Engine, aby działała w Cloud Run lub na dowolnej innej platformie hostującej kontenery. Jeśli chcesz się dowiedzieć, jak używać Dockera do konteneryzacji aplikacji, po ukończeniu tego możesz wykonać moduł 4 Codelabs. Jest identyczna z tą, ale wykorzystuje Dockera, aby pomóc Ci lepiej zrozumieć, jak zarządzać obrazami kontenerów.

Etapy migracji obejmują zastąpienie plików konfiguracji App Engine i określenie sposobu uruchamiania aplikacji. Poniżej znajdziesz tabelę z podsumowaniem plików konfiguracji, których możesz się spodziewać w przypadku poszczególnych typów platform. Porównaj kolumnę App Engine z kolumną Buildpacks (i opcjonalnie Dockera):

Opis

App Engine

Docker

Pakiety kompilacji

Konfiguracja ogólna

app.yaml

Dockerfile

(service.yaml)

Biblioteki zewnętrzne

requirements.txt

requirements.txt

requirements.txt

Konfiguracja zewnętrzna

app.yaml (plus appengine_config.py i lib [tylko 2.x])

(nd.)

(nd.)

Uruchamianie

(nie dotyczy) lub app.yaml (jeśli używana jest wartość entrypoint)

Dockerfile

Procfile

Ignoruj pliki

.gcloudignore i .gitignore

.gcloudignore, .gitignore i .dockerignore

.gcloudignore i .gitignore

Skonteneryzowaną aplikację możesz wdrożyć w Cloud Run. Inne opcje platform kontenerów Google Cloud to Compute Engine, GKE i Anthos.

Konfiguracja ogólna

App Engine automatycznie uruchamia aplikację, ale Cloud Run tego nie robi. Element Procfile pełni podobną rolę co dyrektywa app.yaml entrypoint. W przypadku naszej przykładowej aplikacji Procfile uruchomi python main.py, aby uruchomić serwer programistyczny Flask. W razie potrzeby możesz też użyć produkcyjnego serwera WWW, takiego jak gunicorn. Pamiętaj, by dodać go do requirements.txt. Więcej informacji o wdrażaniu z kodu źródłowego przy użyciu pakietów Buildpacks znajdziesz na tej stronie z dokumentacją Cloud Run.

Wystarczy, że przeniesiesz dyrektywę app.yaml entrypoint do elementu Procfile. Jeśli nie masz takiego serwera, możesz na razie użyć serwera programistycznego platformy Flask, ponieważ jest to tylko przykładowa aplikacja testowa, która ma zaznajomić użytkowników z tą migracją. Twoja aplikacja to specjalne polecenie uruchamiania, które znasz najlepiej. Pod osłonami usługa Cloud Run tworzy service.yaml, który wygląda lub działa bardziej jak app.yaml. Możesz zobaczyć automatycznie wygenerowany tekst service.yaml, klikając ten link, ale dotyczący Twojej usługi SVC_NAME i REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Biblioteki zewnętrzne

Pliku requirements.txt nie trzeba zmieniać. Narzędzie Flask powinno być tam wraz z biblioteką klienta Datastore (Cloud Datastore lub Cloud NDB). Jeśli chcesz użyć innego serwera HTTP zgodnego z WSGI, takiego jak Gunicorn – w momencie tworzenia tego tekstu bieżąca wersja to 20.0.4 – dodaj gunicorn==20.0.4 do requirements.txt.

Konfiguracja zewnętrzna

Pakiet Buildpack nie obsługuje Pythona 2, więc nie omawiamy tego tutaj. Aplikacje w języku Python 3 działające w kontenerach w Cloud Run są podobne do aplikacji App Engine w języku Python 3 pod tym względem, że biblioteki zewnętrzne muszą być określone w polu requirements.txt.

Uruchamianie

Użytkownicy języka Python 3 mogą przekonwertować swoje pliki app.yaml tak, aby w sekcji handlers zamiast script: auto znajdowały się dyrektywy entrypoint. Jeśli użycie polecenia entrypoint w języku app.yaml w języku Python 3 spowoduje, że będzie to wyglądać mniej więcej tak:

runtime: python38
entrypoint: python main.py

Dyrektywa entrypoint informuje App Engine o tym, jak uruchomić serwer. Możesz je przenieść niemal bezpośrednio do urządzenia Procfile. Podsumowanie miejsc, w których pomiędzy obiema platformami pojawiłaby się dyrektywa punktu wejścia: pokazując też odpowiednik Dockera jako FYI:

  • Pakiety kompilacji: wiersz w zakresie Procfile: web: python main.py
  • Docker: wiersz w pliku Dockerfile: ENTRYPOINT ["python", "main.py"]

Na potrzeby testowania i testowania łatwo jest uruchomić serwer programistyczny Flask z Pythona (jak pokazano powyżej), ale deweloperzy mogą wybrać coś bardziej wydajnego w środowisku produkcyjnym, na przykład krótkie wprowadzenie do Cloud Run, w którym zastosowano gunicorn.

Pliki aplikacji

Wszystkie aplikacje modułów 2 i 3 są w pełni zgodne z językiem Python 2–3, co oznacza, że nie wprowadzamy żadnych zmian w podstawowych komponentach main.py. dodajemy tylko kilka wierszy kodu startowego. Dodaj parę wierszy na dole strony main.py, aby uruchomić serwer programistyczny, ponieważ Cloud Run wymaga otwartego portu 8080, aby mógł wywołać Twoją aplikację:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. Kompiluj i wdróż

Gdy konfiguracja App Engine została zastąpiona pakietami Buildpacks i aktualizacjami plików źródłowych, możesz już ją uruchomić w Cloud Run. Zanim przejdziemy dalej, porozmawiajmy o usługach.

Usługi a aplikacje

Chociaż App Engine został stworzony przede wszystkim do hostowania aplikacji, jest to również platforma do hostowania usług internetowych lub aplikacji składających się ze zbioru mikroserwisów. W Cloud Run wszystko jest usługą – może to być rzeczywista usługa lub aplikacja z interfejsem internetowym – dlatego traktuj ją jako wdrożenie usługi, a nie aplikacji.

Jeśli Twoja aplikacja App Engine składa się z wielu usług, podczas wdrażania aplikacji nie trzeba było wybierać nazw. Zmienia się to w Cloud Run, co oznacza, że trzeba wymyślić nazwę usługi. Natomiast domena appspot.com App Engine zawiera identyfikator projektu, np. https://PROJECT_ID.appspot.com i może to być skrót identyfikatora regionu, np. http://PROJECT_ID.REGION_ID.r.appspot.com.

Domena usługi Cloud Run zawiera jednak nazwę usługi, skrót identyfikatora regionu i hasz, ale nie identyfikator projektu, np. https://SVC_NAME-HASH-REG_ABBR.a.run.app. W skrócie – zacznij myśleć o nazwie usługi.

Wdróż usługę

Wykonaj poniższe polecenie, aby utworzyć obraz kontenera i wdrożyć go w Cloud Run. Gdy pojawi się prośba, wybierz region i zezwól na nieuwierzytelnione połączenia, aby ułatwić testowanie, i odpowiednio wybierz region, gdzie SVC_NAME to nazwa wdrażanej usługi.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Aby sprawdzić, czy wdrożenie się udało, otwórz w przeglądarce podany adres URL.

Polecenie gcloud wskazuje, że użytkownicy mogą skonfigurować różne ustawienia domyślne, aby zmniejszyć dane wyjściowe i interaktywność, jak pokazano powyżej. Aby na przykład uniknąć całej interakcji, możesz zamiast tego użyć tego jednowierszowego polecenia wdrożenia:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Jeśli chcesz użyć tej usługi, pamiętaj, aby wybrać tę samą nazwę usługi SVC_NAME i żądaną nazwę elementu REGION, a nie wybór zindeksowanego menu (jak w interaktywny sposób powyżej).

6. Podsumowanie/Czyszczenie

Sprawdź, czy aplikacja działa w Cloud Run tak samo jak w App Engine. Jeśli dołączysz do tej serii bez wykonania żadnego z poprzednich ćwiczeń z programowania, aplikacja się nie zmieni. rejestruje wszystkie odwiedziny głównej strony internetowej (/) i wygląda tak po tym, jak kilka razy odwiedzisz witrynę:

aplikacja visitme

Kod powinien być teraz zgodny z zawartością w folderze repozytorium modułu 5. Gratulujemy ukończenia modułu 5 dotyczącego programowania.

Opcjonalnie: wyczyść

A co z czyszczeniem, aby uniknąć opłat, dopóki nie wszystko będzie gotowe do przejścia do kolejnego ćwiczenia z programowania dotyczącego migracji? Ponieważ używasz teraz innej usługi, zapoznaj się z cennikiem Cloud Run.

Opcjonalnie: wyłącz usługę

Jeśli nie chcesz na razie przejść do następnego samouczka, wyłącz usługę, aby uniknąć dodatkowych opłat. Gdy uznasz, że chcesz przejść do kolejnego ćwiczenia w programowaniu, możesz je ponownie włączyć. Gdy Twoja aplikacja jest wyłączona, nie generuje ona opłat za ruch, ale opłaty mogą być jednak naliczane za wykorzystanie magazynu danychw przypadku przekroczenia bezpłatnego limitu, więc usuń tyle miejsca, aby nie przekroczyć tego limitu.

Jeśli natomiast nie zamierzasz kontynuować migracji i chcesz całkowicie usunąć wszystko, możesz usunąć usługę lub wyłączyć projekt.

Dalsze kroki

Gratulacje! Udało Ci się skonteneryzować aplikację – to już koniec samouczka. Teraz dowiesz się, jak zrobić to samo z Dockerem w ćwiczeniu z programowania w module 4 (link poniżej) lub przeprowadzić inną migrację do App Engine:

  • Moduł 4: Migracja do Cloud Run z wykorzystaniem Dockera
    • Konteneryzowanie aplikacji w celu uruchamiania jej w Cloud Run za pomocą Dockera
    • Pozwala na pozostanie w Pythonie 2
  • Moduł 7. Kolejki zadań App Engine (wymagane, jeśli korzystasz z kolejek zadań [push])
    • Dodaje zadania push taskqueue w App Engine do aplikacji w module 1
    • Przygotowuje użytkowników do migracji do Cloud Tasks w module 8.
  • Część 3.
    • Modernizacja dostępu do Datastore z Cloud NDB na Cloud Datastore
    • To jest biblioteka używana na potrzeby aplikacji App Engine w Pythonie 3 i aplikacji innych niż App Engine
  • Moduł 6. Migracja do Cloud Firestore
    • Przejdź na Cloud Firestore, aby uzyskać dostęp do funkcji Firebase
    • Cloud Firestore obsługuje język Python 2, ale to ćwiczenia z programowania są dostępne tylko w Pythonie 3.

7. Dodatkowe materiały

Problemy/opinie dotyczące modułu migracji App Engine

Jeśli podczas korzystania z tych ćwiczeń z programowania zauważysz jakiekolwiek problemy, najpierw je wyszukaj. Linki do wyszukiwania i tworzenia nowych problemów:

Zasoby migracji

Linki do folderów repozytorium w modułach 2 i 3 (START) oraz modułach 5 (FINISH) znajdziesz w tabeli poniżej. Dostęp do nich możesz też uzyskać z repozytorium wszystkich migracji z ćwiczeń z programowania App Engine, które możesz sklonować lub pobrać w postaci pliku ZIP.

Codelab

Python 2

Python 3

Część 2

kod

(kod).

Część 3

(kod).

kod

Część 5

(nd.)

kod

Zasoby App Engine i Cloud Run

Poniżej znajdziesz dodatkowe materiały na temat tej migracji: