Moduł 11. Migracja z Google App Engine do Cloud Functions

1. Omówienie

Seria ćwiczeń z programowania dla bezserwerowych stacji migracji (samouczek, samouczków) i podobnych filmów ma pomóc deweloperom bezserwerowych Google Cloud w modernizacji aplikacji przez przeprowadzenie co najmniej 1 migracji, w wyniku rezygnacji ze starszych usług. W ten sposób Twoje aplikacje stają się bardziej przenośne, mają więcej opcji i elastyczność, co pozwala na integrację z szerszą gamą usług Cloud i uzyskiwanie do nich dostępu, a także łatwiejsze przejście na nowsze wersje językowe. Choć początkowo koncentrowaliśmy się na pierwszych użytkownikach Cloud, głównie deweloperów korzystających ze środowiska App Engine (środowisko standardowe), ta seria jest na tyle szeroka, aby uwzględnić inne platformy bezserwerowe, takie jak Cloud Functions i Cloud Run, oraz inne, w stosownych przypadkach.

Istnieją sytuacje, gdy nie masz „całej aplikacji” wymaga zasobów App Engine lub Cloud Run. Jeśli Twój kod składa się tylko z mikroserwisu lub prostej funkcji, lepszym rozwiązaniem będzie Cloud Functions. Dzięki temu ćwiczeniu w Codelabs dowiesz się, jak migrować proste aplikacje App Engine (lub podzielić większe aplikacje na kilka mikroserwisów) i wdrożyć je w Cloud Functions – innej bezserwerowej platformie stworzonej specjalnie na potrzeby takich przypadków użycia.

Dowiesz się, jak:

  • Użyj Cloud Shell
  • Włączanie Google Cloud Translation API
  • Uwierzytelnianie żądań do interfejsu API
  • Konwertowanie małej aplikacji App Engine na potrzeby Cloud Functions
  • Wdrażanie kodu w Cloud Functions

Czego potrzebujesz

Ankieta

Jak wykorzystasz ten samouczek?

Tylko do przeczytania Przeczytaj go i wykonaj ćwiczenia

Jak oceniasz swoje doświadczenia z językiem Python?

Początkujący Poziom średnio zaawansowany Biegły

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Poziom średnio zaawansowany Biegły .

2. Tło

Systemy PaaS, takie jak Google App Engine i Cloud Functions, zapewniają użytkownikom wiele udogodnień. Dzięki tym bezserwerowym platformom Twój zespół techniczny może skupić się na tworzeniu rozwiązań biznesowych, zamiast poświęcać czas na analizowanie używanych platform i określanie ilości potrzebnego sprzętu. Aplikacje można autoskalować w górę w razie potrzeby, skalować w dół do zera za pomocą płatności za wykorzystanie, aby kontrolować koszty, a także pozwalają na korzystanie z wielu popularnych obecnie języków programowania.

Mimo że App Engine świetnie nadaje się do tworzenia aplikacji internetowych typu full-stack lub złożonych backendów dla aplikacji mobilnych, to często jest tak, że programiści usiłują umieścić pewne funkcje w internecie, np. aktualizację kanału z wiadomościami lub pobranie najnowszego wyniku rozgrywek play-off drużyny domowej. Choć logika kodowania jest stosowana w obu przypadkach, żadna z nich nie jest w pełni „aplikacjami” które wymagają możliwości App Engine. Właśnie tu do akcji wkracza usługa Cloud Functions.

Cloud Functions służy do wdrażania niewielkiego fragmentu kodu, który:

  • Nie jest częścią całej aplikacji
  • Nie jest potrzebny w całym stosie programowania
  • znajduje się w aplikacji lub w pojedynczym backendzie aplikacji mobilnej i koncentruje się na jednej funkcji,

Za pomocą Cloud Functions możesz też podzielić dużą, monolityczną aplikację na wiele mikroserwisów, z których każdy korzysta ze wspólnej bazy danych, takiej jak Cloud Firestore lub Cloud SQL. Możesz też to zrobić, jeśli chcesz, aby funkcja lub mikroserwis były skonteneryzowane i wykonywane bezserwerowo w Cloud Run.

Nasza przykładowa aplikacja App Engine przedstawiona w niemal wszystkich samouczkach dotyczących migracji to krótka aplikacja z podstawowymi funkcjami, która działa równie dobrze w Cloud Functions. Z tego samouczka dowiesz się, jak zmodyfikować tę aplikację tak, aby działała w Cloud Functions. Ze względu na to, że funkcje w App Engine są prostsze niż całe aplikacje, rozpoczęcie korzystania z usługi powinno być łatwiejsze (i szybsze) i mniejsze „nakład pracy”. i ogólnie. Ta migracja obejmuje te kroki:

  • Konfiguracja/praca
  • Usuwanie plików konfiguracji
  • Modyfikowanie plików aplikacji

3. Konfiguracja/praca

To ćwiczenie z programowania rozpoczyna się od wersji Pythona 3 przykładowej aplikacji Cloud NDB App Engine modułu 2, ponieważ Cloud Functions nie obsługuje Pythona 2. Najpierw skonfigurujmy nasz projekt, pobierz kod, a potem wdróżmy aplikację podstawową, aby upewnić się, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli udało Ci się ukończyć ćwiczenia z programowania w module 2 (i przenieść je do Pythona 3), 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 z włączoną usługą App Engine.

2. Pobierz przykładową aplikację bazową

Jednym z warunków wstępnych tego ćwiczenia z programowania jest posiadanie działającej przykładowej aplikacji w module 2. Jeśli go nie masz, przed przejściem do kolejnego kroku wykonaj czynności z każdego samouczka, do którego link znajdziesz powyżej. Jeśli nie znasz już jej zawartości, możesz zacząć od pobrania poniższego kodu Modułu 2.

Niezależnie od tego, czy używasz swojego czy naszego, zaczynamy od kodu w części 2 w Pythonie 3. To ćwiczenie z programowania w części 11 przedstawi każdy krok po kroku, kończący się kodem przypominającym folder z repozytorium w module 11 (FINISH).

Katalog z plikami START (Twoimi lub naszym) modułu 2 w języku Python 3 powinien wyglądać tak:

$ 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 kroków możesz przekonwertować je na funkcję w Cloud Functions.

4. Usuwanie plików konfiguracji

Plik app.yaml to artefakt App Engine, który nie jest używany w Cloud Functions, dlatego usuń go teraz. Jeśli o tym zapomnisz lub o tym zapomnisz, nic się nie stanie, ponieważ Cloud Functions nie będzie z niego korzystać. To jedyna zmiana w konfiguracji, ponieważ element requirements.txt pozostaje taki sam jak w module 2.

Jeśli przenosisz też aplikację App Engine w języku Python 2 do języka Python 3, usuń appengine_config.py i folder lib, jeśli taki masz. Są to artefakty App Engine nieużywane w środowisku wykonawczym Pythona 3.

5. Modyfikowanie plików aplikacji

Masz tylko 1 plik aplikacji (main.py), więc zawiera on wszystkie zmiany niezbędne do przejścia do Cloud Functions.

Importy

Zajmujemy się tylko funkcjami, więc nie ma potrzeby korzystania z platformy aplikacji internetowej. Jednak dla wygody po wywołaniu funkcji w Cloud Functions opartych na języku Python automatycznie trafiają one do obiektu żądania, którego kod może używać zgodnie z potrzebami. Zespół Cloud Functions wybrał go jako obiekt Flask Request, który jest przekazywany do Twojej funkcji.

Platformy internetowe nie są częścią środowiska Cloud Functions, więc importowanie z platformy Flask jest niemożliwe, chyba że aplikacja używa innych funkcji platformy Flask. Tak jest w naszym przypadku, ponieważ po konwersji na funkcję nadal trwa renderowanie szablonu, co oznacza, że nadal wymagane jest wywołanie funkcji flask.render_template(), a przez to zaimportowanie pliku z platformy Flask. Brak platformy internetowej oznacza, że nie trzeba tworzyć instancji aplikacji Flask, więc usuń app = Flask(__name__). Twój kod przed zastosowaniem zmian i po nim wygląda tak:

PRZED:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

PO:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Jeśli korzystasz z obiektu aplikacji (app) lub innej infrastruktury platformy internetowej, musisz rozwiązać wszystkie te zależności, znaleźć odpowiednie obejścia, całkowicie zrezygnować z ich używania lub znaleźć serwery proxy. Dopiero wtedy możesz przekonwertować kod na funkcję w Cloud Functions. W przeciwnym razie lepiej pozostanie w App Engine lub konteneryzację aplikacji na potrzeby Cloud Run.

Zaktualizuj podpis funkcji głównego modułu obsługi

Zmiany w podpisie funkcji są wymagane:

  1. Po przekonwertowaniu aplikacji na funkcję w Cloud Functions usługa Flask nie jest już używana, dlatego usuń dekoratory tras.
  2. Usługa Cloud Functions automatycznie przekazuje jako parametr w obiekcie Flask Request, musisz więc utworzyć dla niego zmienną. Nazwiemy ją request.
  3. Wdrożone funkcje w Cloud Functions muszą mieć nazwy. Nasz główny moduł obsługi nazywał się w App Engine odpowiednio root(), aby opisać, co to było (główny moduł obsługi aplikacji). Używanie tej nazwy w Cloud Functions jest mniej sensowne. Zamiast tego wdrożymy funkcję w Cloud Functions o nazwie visitme, więc użyj jej również jako nazwy funkcji w Pythonie. Podobnie w modułach 4 i 5 usługę Cloud Run nazwaliśmy visitme.

Oto, co się dzieje przed i po tych zmianach:

PRZED:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

PO:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

To koniec wszystkich niezbędnych aktualizacji. Pamiętaj, że wprowadzone zmiany wpłynęły tylko na „infrastrukturę” aplikacji w kodzie. Nie trzeba wprowadzać żadnych zmian w głównym kodzie aplikacji ani modyfikować jej funkcji. Oto obrazowe przedstawienie zmian wprowadzonych w celu zilustrowania tego stwierdzenia:

668f30e3865b27a9.png

Programowanie i testowanie na poziomie lokalnym

App Engine ma lokalny serwer programistyczny dev_appserver.py, a Cloud Functions ma platformę funkcji. Dzięki tej platformie możesz programować i testować lokalnie. Twój kod możesz wdrożyć w Cloud Functions, ale możesz go też wdrożyć na innych platformach obliczeniowych, takich jak Compute Engine, Cloud Run, a nawet w lokalnych lub hybrydowych systemach chmurowych obsługujących Knative. Poniżej znajdziesz dodatkowe linki do platformy funkcji.

6. Kompiluj i wdróż

Wdrażanie w Cloud Functions różni się nieco od w App Engine. Ponieważ pliki konfiguracji nie są używane poza domeną requirements.txt, należy podać więcej informacji o kodzie w wierszu poleceń. Wdróż nową funkcję w Cloud Functions wyzwalaną przez HTTP w języku Python 3.10 za pomocą tego polecenia:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

Oczekiwane dane wyjściowe będą podobne do tych:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Po wdrożeniu funkcji użyj adresu URL z danych wyjściowych wdrożenia i otwórz aplikację. Adres URL ma postać: REGION-PROJECT_ID.cloudfunctions.net/visitme. Dane wyjściowe powinny być takie same jak w przypadku wdrożenia go wcześniej w App Engine:

2732ae9218f011a2.png

Podobnie jak w przypadku większości innych ćwiczeń z programowania i filmów w tej serii podstawowe funkcje aplikacji pozostają takie same. Celem jest zastosowanie jednej techniki modernizacji i utrzymanie aplikacji w dotychczasowy sposób, ale z wykorzystaniem nowszej infrastruktury. Może to być na przykład przejście ze starszej wersji App Engine na samodzielną usługę Cloud lub, jak w przypadku tego samouczka, przeniesienie aplikacji na inną bezserwerową platformę Google Cloud.

7. Podsumowanie/Czyszczenie

Gratulujemy przekonwertowania tej małej aplikacji App Engine na funkcję w Cloud Functions. Inny odpowiedni przypadek użycia: podzielenie dużej monolitycznej aplikacji App Engine na szereg mikroserwisów, z których każdy pełni funkcję funkcji w Cloud Functions. To bardziej nowoczesna technika programowania, która wymaga „plug and play”. (algorytm stosu Jamu”). Umożliwia to mieszanie i dopasowywanie kodu oraz ponowne wykorzystywanie kodu – to 2 cele. Kolejną zaletą jest to, że z czasem te mikroserwisy będą nadal debugowane, co oznacza stabilny kod i obniża ogólne koszty obsługi.

Czyszczenie danych

Po ukończeniu tego ćwiczenia w Codelabs możesz wyłączyć aplikację App Engine modułu 2 (tymczasowo lub na stałe), aby uniknąć opłat. Platforma App Engine ma bezpłatny limit, więc nie będziemy naliczać opłat, jeśli będziesz utrzymywać swój poziom wykorzystania. To samo dotyczy Datastore, Więcej informacji znajdziesz na stronie z cennikiem Cloud Datastore.

Wdrożenie na platformach takich jak App Engine i Cloud Functions wiąże się z niewielkimi kosztami kompilacji i przechowywania danych. W niektórych regionach Cloud Build i Cloud Storage mają własny bezpłatny limit. Kompilacje zużywają część tego limitu. Pamiętaj o wykorzystaniu miejsca na dane, aby zminimalizować potencjalne koszty, zwłaszcza jeśli w Twoim regionie nie ma takiego poziomu bezpłatnego.

Niestety w Cloud Functions nie ma opcji „Wyłącz” funkcji. Utwórz kopię zapasową kodu i usuń funkcję. Zawsze możesz ją później wdrożyć ponownie pod tą samą nazwą. Jeśli jednak nie zamierzasz kontynuować żadnych innych ćwiczeń z programowania dotyczących migracji i chcesz całkowicie usunąć wszystko, zamknij projekty Cloud.

Dalsze kroki

Oprócz tego samouczka inne moduły migracji, które warto przeanalizować, obejmują konteneryzację aplikacji App Engine na potrzeby Cloud Run. Zapoznaj się z linkami do modułów 4 i 5 z programowania:

  • Moduł 4: Migracja do Cloud Run z wykorzystaniem Dockera
  • Konteneryzowanie aplikacji w celu uruchamiania jej w Cloud Run za pomocą Dockera
  • Ta migracja pozwoli Ci pozostać w Pythonie 2.
  • Moduł 5: Migracja do Cloud Run z użyciem Cloud Buildpacks
  • Konteneryzowanie aplikacji na potrzeby uruchamiania jej w Cloud Run za pomocą pakietów Cloud Buildpack
  • Nie musisz wiedzieć nic o Dockerze, kontenerach ani Dockerfile.
  • Wymaga, aby aplikacja została już przeniesiona do Pythona 3 (pakiety Buildpacki nie obsługują Pythona 2).

Wiele pozostałych modułów skupia się na pokazaniu deweloperom, jak przejść z pakietów usług App Engine na samodzielne zamienniki Cloud:

  • Moduł 2. Migracja z App Engine ndb do Cloud NDB
  • Moduły 7–9. Migracja z kolejki zadań App Engine w trybie push do Cloud Tasks
  • Moduły 12–13: migracja z App Engine Memcache do Cloud Memorystore
  • Moduły 15–16: migracja z App Engine Blobstore do Cloud Storage
  • Moduły 18–19: migracja z kolejki zadań App Engine (pobierania zadań) do Cloud Pub/Sub

Jeśli konteneryzacja stała się częścią przepływu pracy przy tworzeniu aplikacji, zwłaszcza jeśli składa się ona z potoku CI/CD (ciągła integracja/ciągłe dostarczanie lub wdrażanie), rozważ migrację do Cloud Run zamiast Cloud Functions. Zapoznaj się z Modułem 4, aby skonteneryzować aplikację za pomocą Dockera, lub Modułem 5, aby zrobić to bez kontenerów, Dockera lub Dockerfile. Niezależnie od tego, czy rozważasz korzystanie z Cloud Functions czy Cloud Run, przejście na inną platformę bezserwerową jest opcjonalne. Przed wprowadzeniem jakichkolwiek zmian zalecamy rozważenie najlepszych opcji dla Twoich aplikacji i przypadków użycia.

Niezależnie od tego, który moduł migracji wykorzystasz w następnej kolejności, wszystkie materiały z serwerowej platformy migracji (laboratorium, filmy, kod źródłowy [jeśli jest dostępne]) są dostępne w repozytorium open source. README repozytorium zawiera też wskazówki dotyczące migracji, które warto wziąć pod uwagę, i wszelkich odpowiednich „zamówień” modułów migracji.

8. 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 8 (START) i modułach 9 (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 3

Część 2

kod

Część 11

kod

Zasoby online

Poniżej znajdują się zasoby online, które mogą być pomocne w przypadku tego samouczka:

App Engine

Cloud Functions

Inne informacje o Google Cloud

Filmy

Licencja

To zadanie jest licencjonowane na podstawie ogólnej licencji Creative Commons Attribution 2.0.