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

1. Przegląd

Seria codelabów Serverless Migration Station (samodzielne, praktyczne samouczki) i powiązane z nimi filmy mają na celu pomóc deweloperom usług bezserwerowych Google Cloud w modernizacji aplikacji poprzez przeprowadzenie ich przez co najmniej jedną migrację, głównie z usług starszego typu. Dzięki temu Twoje aplikacje będą bardziej przenośne, a Ty zyskasz więcej opcji i elastyczności, co umożliwi Ci integrację z szerszą gamą usług w chmurze i łatwiejsze przechodzenie na nowsze wersje języka. Chociaż początkowo skupialiśmy się na pierwszych użytkownikach usług w chmurze, głównie na deweloperach App Engine (środowisko standardowe), ta seria jest wystarczająco szeroka, aby obejmować inne platformy bezserwerowe, takie jak Cloud Functions i Cloud Run, lub inne, jeśli ma to zastosowanie.

Czasami nie masz „całej aplikacji”, która wymagałaby zasobów App Engine lub Cloud Run. Jeśli Twój kod składa się tylko z mikrousługi lub prostej funkcji, lepszym rozwiązaniem będzie prawdopodobnie Cloud Functions. W tym samouczku dowiesz się, jak przenieść proste aplikacje App Engine (lub podzielić większe aplikacje na wiele mikroserwisów) i wdrożyć je w Cloud Functions, czyli na innej platformie bezserwerowej stworzonej specjalnie do takich przypadków użycia.

Dowiesz się, jak:

  • Korzystanie z Cloud Shell
  • Włączanie interfejsu Google Cloud Translation API
  • Uwierzytelnianie żądań do interfejsu API
  • Konwertowanie małej aplikacji App Engine, aby można było ją uruchamiać w Cloud Functions
  • Wdrażanie kodu w Cloud Functions

Czego potrzebujesz

Ankieta

Jak zamierzasz korzystać z tego samouczka?

Tylko przeczytaj Przeczytaj i wykonaj ćwiczenia

Jak oceniasz swoje doświadczenie z Pythonem?

Początkujący Średnio zaawansowany Zaawansowany

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Średnio zaawansowany Zaawansowany

2. Tło

Systemy PaaS, takie jak Google App Engine i Cloud Functions, zapewniają użytkownikom wiele udogodnień. Te platformy bezserwerowe umożliwiają zespołowi technicznemu skupienie się na tworzeniu rozwiązań biznesowych zamiast na badaniu platform, z których można korzystać, i określaniu ilości potrzebnego sprzętu. Aplikacje mogą automatycznie skalować się w górę w miarę potrzeb, skalować w dół do zera z płatnościami za użycie, aby kontrolować koszty, i obsługują różne popularne obecnie języki programowania.

Chociaż App Engine doskonale nadaje się do tworzenia pełnych aplikacji internetowych lub złożonych backendów aplikacji mobilnych, często zdarza się, że deweloperzy chcą po prostu udostępnić w internecie jakąś funkcję, np. aktualizować kanał wiadomości lub pobierać najnowsze wyniki meczu play-off drużyny gospodarzy. Logika kodowania istnieje w obu scenariuszach, ale żaden z nich nie jest pełną „aplikacją” wymagającą mocy App Engine. W tym miejscu przydają się Cloud Functions.

Cloud Functions służy do wdrażania małych fragmentów kodu, które:

  • Nie jest częścią całej aplikacji
  • Nie jest potrzebny w całym stosie technologicznym
  • jest w aplikacji lub pojedynczym backendzie aplikacji mobilnej, który koncentruje się na jednej rzeczy;

Możesz też użyć Cloud Functions, aby 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. Jeśli chcesz, aby Twoja funkcja lub mikrousługa była skonteneryzowana i wykonywana bezserwerowo w Cloud Run, możesz to zrobić.

Nasza przykładowa aplikacja App Engine, która pojawiła się 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ę, aby działała w Cloud Functions. Z perspektywy App Engine funkcje są prostsze niż całe aplikacje, więc rozpoczęcie pracy powinno być łatwiejsze (i szybsze) oraz ogólnie mniej „obciążające”. Migracja obejmuje te kroki:

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

3. Konfiguracja/przygotowanie

Ten samouczek zaczyna się od wersji przykładowej aplikacji Module 2 Cloud NDB App Engine w języku Python 3, ponieważ Cloud Functions nie obsługuje języka Python 2. Najpierw skonfigurujemy projekt, pobierzemy kod, a potem wdrożymy aplikację podstawową, aby potwierdzić, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz za sobą moduł 2 (i przeniesiesz go do języka Python 3), zalecamy ponowne użycie tego samego projektu (i kodu). Możesz też utworzyć zupełnie nowy projekt lub ponownie wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe z włączoną usługą App Engine.

2. Pobieranie przykładowej aplikacji podstawowej

Jednym z wymagań wstępnych do tych ćwiczeń z programowania jest działająca przykładowa aplikacja z modułu 2. Jeśli jej nie masz, przed przejściem dalej wykonaj jeden z samouczków, do których linki znajdziesz powyżej. Jeśli znasz już jego zawartość, możesz zacząć od pobrania kodu modułu 2 poniżej.

Niezależnie od tego, czy używasz własnego kodu, czy naszego, ZACZNIEMY od kodu modułu 2 w języku Python 3. W tym module 11 Codelabs znajdziesz instrukcje krok po kroku, a na końcu kod podobny do tego, który znajduje się w folderze repozytorium modułu 11 (FINISH).

Katalog plików STARTOWYCH modułu 2 języka Python 3 (Twój lub nasz) powinien wyglądać tak:

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

3. (Ponowne) wdrażanie aplikacji bazowej

Pozostałe czynności przygotowawcze, które musisz teraz wykonać:

  1. Przypomnij sobie, jak działa narzędzie wiersza poleceń gcloud.
  2. Ponowne wdrażanie przykładowej aplikacji za pomocą gcloud app deploy
  3. Sprawdź, czy aplikacja działa w App Engine bez problemów.

Po wykonaniu tych czynności możesz przekształcić go w funkcję Cloud Function.

4. Usuwanie plików konfiguracji

Plik app.yaml jest artefaktem App Engine, który nie jest używany w Cloud Functions, więc usuń go teraz. Jeśli tego nie zrobisz lub o tym zapomnisz, nic się nie stanie, ponieważ Cloud Functions nie używa tej wartości. To jedyna zmiana konfiguracji, ponieważ requirements.txt pozostaje identyczne jak w module 2.

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

5. Modyfikowanie plików aplikacji

Jest tylko jeden plik aplikacji, main.py, więc wszystkie niezbędne zmiany, które trzeba wprowadzić, aby przejść na Cloud Functions, są w nim zawarte.

Importy

Ponieważ pracujemy tylko z funkcjami, nie potrzebujemy platformy aplikacji internetowej. Jednak dla wygody, gdy wywoływane są funkcje Cloud Functions oparte na Pythonie, automatycznie przekazywany jest do nich obiekt żądania, którego kod może używać w razie potrzeby. (Zespół Cloud Functions wybrał go jako obiekt żądania Flask przekazywany do funkcji).

Platformy internetowe nie są częścią środowiska Cloud Functions, więc nie ma importów z Flaska, chyba że aplikacja korzysta z innych funkcji Flaska. Tak jest w naszym przypadku, ponieważ renderowanie szablonu nadal odbywa się po przekształceniu go w funkcję, co oznacza, że nadal wymagane jest wywołanie flask.render_template(), a tym samym jego importowanie z Flask. Brak platformy internetowej oznacza, że nie musisz tworzyć instancji aplikacji Flask, więc usuń app = Flask(__name__). Przed wprowadzeniem zmian i po ich wprowadzeniu kod powinien 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 lub całkowicie usunąć ich użycie albo znaleźć serwery proxy. Dopiero wtedy możesz przekształcić kod w funkcję Cloud Function. W przeciwnym razie lepiej pozostać w App Engine lub skonteneryzować aplikację na potrzeby Cloud Run.

Aktualizowanie podpisu głównej funkcji obsługi

Wymagane zmiany w sygnaturze funkcji są następujące:

  1. Po przekształceniu aplikacji w funkcję Cloud Function Flask nie jest już używany, więc usuń dekoratory tras.
  2. Cloud Functions automatycznie przekazuje obiekt Flask Request jako parametr, więc utwórz dla niego zmienną. W naszej przykładowej aplikacji nazwiemy ją request.
  3. Wdrożone funkcje w Cloud Functions muszą mieć nazwy. Nasz główny moduł obsługi w App Engine miał odpowiednią nazwę root(), która opisywała jego funkcję (główny moduł obsługi aplikacji). W przypadku Cloud Functions używanie tej nazwy ma mniejszy sens. Zamiast tego wdrożymy funkcję Cloud Function o nazwie visitme, więc użyj jej również jako nazwy funkcji Pythona. Podobnie w modułach 4 i 5 nazwaliśmy usługę Cloud Run visitme.

Oto przykłady przed i po wprowadzeniu tych zmian:

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 wszystkie niezbędne aktualizacje. Pamiętaj, że wprowadzone zmiany dotyczyły tylko kodu „infrastruktury” aplikacji. Nie trzeba wprowadzać żadnych zmian w głównym kodzie aplikacji ani modyfikować jej funkcji. Aby to zilustrować, przedstawiamy graficznie wprowadzone zmiany:

668f30e3865b27a9.png

Lokalne programowanie i testowanie

App Engine ma dev_appserver.py lokalny serwer programistyczny, a Cloud Functions ma Functions Framework. Za pomocą tej platformy możesz tworzyć i testować aplikacje lokalnie. Kod można wdrożyć w Cloud Functions, ale także na innych platformach obliczeniowych, takich jak Compute Engine, Cloud Run, a nawet w systemach lokalnych lub chmury hybrydowej obsługujących Knative. Poniżej znajdziesz dodatkowe linki do platformy funkcji.

6. Tworzenie i wdrażanie

Wdrażanie w Cloud Functions różni się nieco od wdrażania w App Engine. Ponieważ poza requirements.txt nie są używane żadne pliki konfiguracyjne, więcej informacji o kodzie należy podać w wierszu poleceń. Wdróż nową funkcję w Cloud Functions aktywowaną przez HTTP, która działa w Pythonie 3.10, za pomocą tego polecenia:

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

Dane wyjściowe powinny być 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ć identyczne z tymi, które pojawiły się podczas wcześniejszego wdrażania w App Engine:

2732ae9218f011a2.png

Podobnie jak w przypadku większości innych ćwiczeń z programowania i filmów z tej serii podstawowa funkcjonalność aplikacji nie ulega zmianie. Chodzi o zastosowanie jednej techniki modernizacji i zapewnienie, że aplikacja będzie działać dokładnie tak jak wcześniej, ale na nowszej infrastrukturze. Może to być np. migracja ze starszej usługi App Engine do jej zamiennika, czyli samodzielnej usługi Cloud, lub, jak w przypadku tego samouczka, przeniesienie aplikacji na inną bezserwerową platformę Google Cloud.

7. Podsumowanie i czyszczenie

Gratulujemy przekształcenia tej małej aplikacji App Engine w funkcję w Cloud Functions. Inny odpowiedni przypadek użycia: podzielenie dużej monolitycznej aplikacji App Engine na serię mikroserwisów, z których każdy jest funkcją Cloud Function. Jest to nowocześniejsza technika tworzenia, która pozwala uzyskać komponent w stylu „plug-and-play” (np. „ JAM stack”). Umożliwia to łączenie i dopasowywanie oraz ponowne wykorzystywanie kodu, co jest korzystne, ale kolejną zaletą jest to, że te mikroserwisy będą z czasem debugowane, co oznacza stabilny kod i niższe koszty utrzymania.

Czyszczenie danych

Po ukończeniu tego laboratorium możesz wyłączyć aplikację App Engine z modułu 2 (tymczasowo lub na stałe), aby uniknąć naliczania opłat. Platforma App Engine ma bezpłatny limit, więc dopóki nie przekroczysz poziomu wykorzystania, nie będziesz obciążany(-a) opłatami. To samo dotyczy usługi Datastore. Więcej informacji znajdziesz na stronie z cennikiem Cloud Datastore.

Wdrażanie na platformach takich jak App Engine i Cloud Functions wiąże się z niewielkimi kosztami kompilacji i przechowywania. W niektórych regionach Cloud Build ma własny bezpłatny limit, podobnie jak Cloud Storage. Kompilacje wykorzystują część tego limitu. Monitoruj wykorzystanie miejsca na dane, aby zminimalizować potencjalne koszty, zwłaszcza jeśli w Twoim regionie nie ma takiego bezpłatnego poziomu.

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

Dalsze kroki

Oprócz tego samouczka warto zapoznać się z innymi modułami migracji, np. dotyczącymi kontenerowania aplikacji App Engine na potrzeby Cloud Run. Zobacz linki do ćwiczeń z programowania w modułach 4 i 5:

  • Moduł 4. Migracja do Cloud Run za pomocą Dockera
  • Konteneryzowanie aplikacji do uruchamiania w Cloud Run za pomocą Dockera
  • Ta migracja umożliwia dalsze korzystanie z języka Python 2.
  • Moduł 5. Migracja do Cloud Run za pomocą Cloud Buildpacks
  • Konteneryzowanie aplikacji do uruchamiania w Cloud Run za pomocą pakietów kompilacji Cloud Build
  • Nie musisz nic wiedzieć o Dockerze, kontenerach ani Dockerfile.
  • Wymaga migracji aplikacji do języka Python 3 (pakiety kompilacji nie obsługują języka Python 2).

Wiele innych modułów skupia się na pokazaniu deweloperom, jak przejść z pakietu usług App Engine na samodzielne usługi Cloud:

Jeśli konteneryzacja stała się częścią procesu tworzenia aplikacji, zwłaszcza jeśli obejmuje potok CI/CD (tryb ciągłej integracji/tryb ciągłego dostarczania lub wdrażanie), rozważ migrację do Cloud Run zamiast Cloud Functions. Aby umieścić aplikację w kontenerze za pomocą Dockera, zapoznaj się z modułem 4. Jeśli chcesz to zrobić bez kontenerów, wiedzy o Dockerze lub Dockerfile, przeczytaj moduł 5. Przejście na inną platformę bezserwerową, np. Cloud Functions lub Cloud Run, jest opcjonalne. Zanim wprowadzisz jakiekolwiek zmiany, zalecamy rozważenie najlepszych opcji dla Twoich aplikacji i przypadków użycia.

Niezależnie od tego, który moduł migracji wybierzesz, wszystkie materiały dotyczące Serverless Migration Station (ćwiczenia z programowania, filmy, kod źródłowy [jeśli jest dostępny]) znajdziesz w repozytorium open source. W repozytorium README znajdziesz też wskazówki dotyczące migracji, które warto rozważyć, oraz odpowiednią „kolejność” modułów migracji.

8. Dodatkowe materiały

Problemy i opinie dotyczące ćwiczeń z programowania modułu migracji App Engine

Jeśli zauważysz jakieś problemy z tym kursem, najpierw poszukaj rozwiązania, a dopiero potem zgłoś problem. Linki do wyszukiwania i tworzenia nowych problemów:

Materiały dotyczące migracji

Linki do folderów repozytorium dla modułu 8 (START) i modułu 9 (FINISH) znajdziesz w tabeli poniżej. Możesz też uzyskać do nich dostęp w repozytorium wszystkich migracji codelabów App Engine, które możesz sklonować lub pobrać jako plik ZIP.

Ćwiczenia z programowania

Python 3

Moduł 2

kod

Module 11

kod

Zasoby online

Poniżej znajdziesz zasoby online, które mogą być przydatne w tym samouczku:

App Engine

Cloud Functions

Inne informacje o chmurze

Filmy

Licencja

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