Rozszerzona obsługa pakietów App Engine: część 1 (moduł 17)

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.

Wcześniej deweloperzy musieli przejść z starszych „usług pakietowych” App Engine, takich jak Datastore i Memcache, zanim mogli uaktualnić wersje języka. Były to 2 trudne zadania wykonywane kolejno. Dzięki udostępnieniu wielu kluczowych usług pakietowych w usłudze App Engine 2 generacji deweloperzy mogą teraz przenosić swoje aplikacje do najnowszych środowisk wykonawczych, zachowując przy tym możliwość korzystania z (większości) usług pakietowych. W tym laboratorium dowiesz się, jak zaktualizować przykładową aplikację z Pythona 2 do Pythona 3, zachowując przy tym możliwość korzystania z usługi pakietowej Datastore (za pomocą biblioteki App Engine NDB). Korzystanie z większości usług pakietowych wymaga tylko niewielkiej aktualizacji kodu, co omówimy w tym samouczku. Istnieją jednak inne usługi, które wymagają bardziej rozległych zmian. Omówimy je w „Części 2”, czyli w module uzupełniającym i laboratorium kodowania.

Dowiesz się, jak:

  • Przenoszenie przykładowej aplikacji App Engine z Pythona 2 na Pythona 3
  • Aktualizowanie konfiguracji aplikacji, aby uwzględnić pakiet SDK App Engine
  • Dodaj do aplikacji kod pakietu SDK obsługujący usługi pakietowe w środowiskach wykonawczych drugiej generacji, takich jak Python 3.

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

Pierwotna usługa App Engine została wprowadzona w 2008 roku i zawierała zestaw starszych interfejsów API (obecnie znanych jako usługi pakietowe), aby ułatwić deweloperom tworzenie i wdrażanie aplikacji na całym świecie. Te usługi to Datastore, Memcache i Task Queue. Chociaż było to wygodne, użytkownicy zaczęli się martwić o przenośność aplikacji, gdy korzystali z zastrzeżonych interfejsów API, które wiązały ich z App Engine. Chcieli, aby ich aplikacje były bardziej przenośne. W połączeniu z faktem, że wiele z tych usług w pakiecie rozwinęło się i stało się samodzielnymi produktami w chmurze, zespół App Engine wprowadził w 2018 r. platformę nowej generacji bez tych usług.

Przejdźmy do czasów obecnych, gdy programiści Pythona 2 chętnie przechodzą na Pythona 3. Aplikacja w wersji 2.x korzystająca z usług w pakiecie wymagała migracji z tych usług, zanim można było przenieść ją do wersji 3.x. Oznaczało to dwie wymuszone migracje z rzędu, które mogły być trudne. Aby ułatwić tę zmianę, zespół App Engine jesienią 2021 r. wprowadził „wormhole” do przeszłości, który umożliwia aplikacjom działającym w środowiskach wykonawczych nowej generacji dostęp do wielu tych usług pakietowych. Ta wersja nie obejmuje wszystkich usług dostępnych w oryginalnych środowiskach wykonawczych, ale są w niej dostępne najważniejsze usługi, takie jak Datastore, kolejka zadań i Memcache.

W tym laboratorium kodowania pokazujemy, jakie zmiany należy wprowadzić, aby uaktualnić aplikację do Pythona 3 przy zachowaniu możliwości korzystania z usług pakietowych. Chcemy, aby Twoje aplikacje działały w najnowszych środowiskach wykonawczych, co umożliwi Ci przejście z usług pakietowych na samodzielne odpowiedniki w Cloud lub alternatywne rozwiązania innych firm w dogodnym dla Ciebie terminie, zamiast blokować uaktualnienie do wersji 3.x. Migracja z usług pakietowych nie jest już wymagana, ale zapewnia większą przenośność i elastyczność w zakresie hostowania aplikacji, w tym możliwość przejścia na platformy, które mogą lepiej obsługiwać Twoje zadania, lub po prostu pozostania w App Engine i przejścia na nowszą wersję języka, jak opisano powyżej.

Przykładowa aplikacja z modułu 1 w języku Python 2 korzysta z usługi pakietowej Datastore za pomocą App Engine NDB. Aplikacja ma już przeniesione frameworki z webapp2 na Flask – zostało to zrobione w Module 1 codelab – ale jej użycie Datastore pozostało bez zmian.

Ten samouczek obejmuje te kroki:

  1. Konfiguracja/przygotowanie
  2. Aktualizacja konfiguracji
  3. Modyfikowanie kodu aplikacji

3. Konfiguracja/przygotowanie

Z tej sekcji dowiesz się, jak:

  1. Konfigurowanie projektu w chmurze
  2. Pobieranie przykładowej aplikacji podstawowej
  3. (Ponowne) wdrażanie i weryfikowanie aplikacji podstawowej

Dzięki tym czynnościom masz pewność, że zaczynasz od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz już za sobą moduł 1, zalecamy ponowne użycie tego samego projektu (i kodu). Możesz też utworzyć zupełnie nowy projekt w chmurze lub użyć innego istniejącego projektu. Sprawdź, czy projekt ma aktywne konto rozliczeniowe, na którym włączona jest usługa App Engine.

2. Pobieranie przykładowej aplikacji podstawowej

Jednym z wymagań wstępnych tego modułu jest działająca aplikacja App Engine z modułu 1: wykonaj moduł 1 (zalecane) lub skopiuj aplikację z modułu 1 z repozytorium. Niezależnie od tego, czy używasz własnego kodu, czy naszego, kod modułu 1 to miejsce, w którym „ZACZNIEMY”. W tym Codelabs znajdziesz instrukcje krok po kroku. Na końcu znajdziesz kod podobny do tego w folderze „FINISH” w repozytorium modułu 7.

Niezależnie od tego, której aplikacji z modułu 1 używasz, folder powinien wyglądać jak poniżej. Może też zawierać folder lib:

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

3. (Ponowne) wdrażanie aplikacji bazowej

Aby (ponownie) wdrożyć aplikację z modułu 1, wykonaj te czynności:

  1. Usuń folder lib, jeśli istnieje, i uruchom polecenie: pip install -t lib -r requirements.txt, aby ponownie wypełnić folder lib. Jeśli masz zainstalowane obie wersje Pythona (2 i 3), może być konieczne użycie polecenia pip2.
  2. Sprawdź, czy narzędzie wiersza poleceń gcloud zostało zainstalowane i zainicjowane oraz czy znasz sposób jego użycia.
  3. Ustaw projekt w chmurze za pomocą polecenia gcloud config set project PROJECT_ID, jeśli nie chcesz wpisywać PROJECT_ID przy każdym wydaniu polecenia gcloud.
  4. Wdrażanie przykładowej aplikacji za pomocą gcloud app deploy
  5. Sprawdź, czy aplikacja Moduł 1 działa zgodnie z oczekiwaniami i wyświetla najnowsze wizyty (jak na ilustracji poniżej).

a7a9d2b80d706a2b.png

4. Aktualizacja konfiguracji

Gdy wykonasz te czynności i zobaczysz, że aplikacja internetowa działa, możesz przenieść ją do Pythona 3, zaczynając od konfiguracji.

Dodawanie pakietu SDK do pliku requirements.txt

Środowisko wykonawcze App Engine Python 3 znacznie zmniejsza obciążenie związane z korzystaniem z bibliotek innych firm. Wystarczy, że wymienisz je w requirements.txt. Aby korzystać z usług pakietowych w Pythonie 3, dodaj do niego pakiet App Engine SDK appengine-python-standard. Pakiet SDK dołącza do Flaska z modułu 1:

flask
appengine-python-standard

Aktualizowanie pliku app.yaml

Aby zastosować zmiany konfiguracji w pliku app.yaml, wykonaj te czynności:

  1. Zastąp dyrektywę runtime obsługiwaną wersją Pythona 3. Na przykład w przypadku Pythona 3.10 wpisz python310.
  2. Usuń dyrektywy threadsafe i api_version, ponieważ nie są one używane w Pythonie 3.
  3. Usuń całą sekcję handlers, ponieważ ta aplikacja ma tylko procedury obsługi skryptów. Jeśli aplikacja ma statyczne moduły obsługi plików, pozostaw je bez zmian w handlers.
  4. Środowisko wykonawcze języka Python 3 nie obsługuje wbudowanych bibliotek innych firm, tak jak środowisko wykonawcze języka Python 2. Jeśli Twoja aplikacja ma sekcję libraries w app.yaml, usuń całą sekcję. (Wymagane pakiety muszą być wymienione w requirements.txt, tak jak biblioteki inne niż wbudowane). Nasza przykładowa aplikacja nie ma sekcji libraries, więc przejdź do następnego kroku.
  5. Utwórz zestaw dyrektyw app_engine_apis ustawiony na true, aby go użyć. Odpowiada to dodaniu pakietu SDK App Engine do requirements.txt powyżej.

Podsumowanie wymaganych zmian w przypadku tych danych: app.yaml

PRZED:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

PO:

runtime: python310
app_engine_apis: true

Inne pliki konfiguracji

Wszystkie pakiety innych firm muszą być wymienione tylko w requirements.txt. Jeśli nie masz niczego specjalnego w appengine_config.py, nie jest on potrzebny, więc go usuń. Podobnie, ponieważ wszystkie biblioteki innych firm są automatycznie instalowane podczas procesu kompilacji, nie trzeba ich kopiować ani dostarczać, co oznacza, że nie ma już polecenia pip install ani folderu lib, więc usuń go. Podsumowywanie:

  • Usuwanie pliku appengine_config.py
  • Usuwanie folderu lib

Wszystkie niezbędne zmiany konfiguracji zostały wprowadzone.

5. Modyfikowanie kodu aplikacji

Dostęp do większości dostępnych usług pakietowych w środowisku wykonawczym Python 3 wymaga krótkiego fragmentu kodu, który opakowuje obiekt aplikacji Web Server Gateway Interface (WSGI) w main.py. Funkcja opakowująca to google.appengine.api.wrap_wsgi_app(). Aby jej użyć, musisz ją zaimportować i opakować nią obiekt WSGI. Wprowadź poniższe zmiany, aby odzwierciedlić wymaganą aktualizację Flask w main.py:

PRZED:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

PO:

from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)

Przykłady opakowywania WSGI w przypadku innych platform Pythona znajdziesz w dokumentacji.

Ten przykład umożliwia aplikacji dostęp do większości usług pakietowych w Pythonie 3, ale inne usługi, takie jak Blobstore i Mail, wymagają dodatkowego kodu. Omówimy te sample w innym module dotyczącym migracji.

To wszystkie zmiany, które musisz wprowadzić, aby dodać korzystanie z usług pakietowych App Engine do przykładowej aplikacji z modułu 1. Aplikacja jest już zgodna z Pythonem 2 i 3, więc nie musisz wprowadzać żadnych dodatkowych zmian, aby przenieść ją do Pythona 3. Ostatni krok: wdróż zmodyfikowaną aplikację w środowisku wykonawczym App Engine Python 3 nowej generacji i potwierdź, że aktualizacje się powiodły.

6. Podsumowanie i czyszczenie

W tej sekcji podsumowujemy te warsztaty, wdrażając aplikację i sprawdzając, czy działa zgodnie z oczekiwaniami i czy dane wyjściowe są prawidłowe. Po zweryfikowaniu aplikacji wykonaj czyszczenie i rozważ kolejne kroki.

Wdrażanie i weryfikowanie aplikacji

Wdróż aplikację w Pythonie 3 za pomocą gcloud app deploy i sprawdź, czy działa tak samo jak w Pythonie 2. Funkcjonalność nie ulegnie zmianie, więc dane wyjściowe powinny być identyczne jak w przypadku aplikacji z modułu 1:

a7a9d2b80d706a2b.png

Uwagi końcowe

Gratulujemy wykonania pierwszego kroku w przenoszeniu aplikacji App Engine w Pythonie 2 do Pythona 3 przy jednoczesnym zachowaniu korzystania z usług pakietowych.

Czyszczenie danych

Ogólne

Jeśli na razie nie chcesz już korzystać z usługi, zalecamy wyłączenie aplikacji App Engine, aby uniknąć naliczania opłat. Jeśli jednak chcesz przeprowadzić więcej testów lub eksperymentów, platforma App Engine ma bezpłatny limit, więc dopóki nie przekroczysz tego poziomu wykorzystania, nie powinny być naliczane żadne opłaty. Dotyczy to obliczeń, ale mogą też wystąpić opłaty za odpowiednie usługi App Engine, więc więcej informacji znajdziesz na stronie z cennikiem. Jeśli migracja obejmuje inne usługi w chmurze, są one rozliczane oddzielnie. W każdym przypadku, jeśli to konieczne, zapoznaj się z sekcją „Specyficzne dla tego laboratorium” poniżej.

Wdrożenie na bezserwerowej platformie obliczeniowej Google Cloud, takiej jak App Engine, wiąże się z niewielkimi kosztami kompilacji i przechowywania. Cloud Build ma własny bezpłatny limit, podobnie jak Cloud Storage. Przechowywanie tego obrazu wykorzystuje część tego limitu. Możesz jednak mieszkać w regionie, w którym nie ma takiego bezpłatnego pakietu, więc kontroluj wykorzystanie miejsca na dane, aby zminimalizować potencjalne koszty. Sprawdź te „foldery” Cloud Storage:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • Linki do pamięci masowej powyżej zależą od PROJECT_ID i *LOC*acji, np. „us”, jeśli Twoja aplikacja jest hostowana w Stanach Zjednoczonych.

Jeśli nie zamierzasz kontynuować pracy z tą aplikacją ani innymi powiązanymi z nią samouczkami dotyczącymi migracji i chcesz wszystko całkowicie usunąć, wyłącz projekt.

Dotyczy tych ćwiczeń z programowania

Usługi wymienione poniżej są dostępne tylko w tym laboratorium. Więcej informacji znajdziesz w dokumentacji poszczególnych usług:

Dalsze kroki

Możesz teraz wykonać kilka czynności:

  1. Aktualizowanie kodu za pomocą usług pakietowych wymagających więcej zmian w kodzie
  2. Migracja z pakietów usług do samodzielnych usług w chmurze
  3. Migracja z App Engine na inną bezserwerową platformę w chmurze

Dostęp do innych usług pakietowych, takich jak Blobstore, Mail i Deferred, wymaga większych zmian w kodzie. Moduły migracji, które warto wziąć pod uwagę w przypadku przejścia ze starszych pakietów usług App Engine:

App Engine nie jest już jedyną platformą bezserwerową w Google Cloud. Jeśli masz małą aplikację App Engine lub aplikację o ograniczonej funkcjonalności i chcesz przekształcić ją w samodzielny mikroserwis albo podzielić aplikację monolityczną na wiele komponentów wielokrotnego użytku, warto rozważyć przejście na Cloud Functions. 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. Te scenariusze są omówione w tych modułach:

  • Migracja z App Engine do Cloud Functions: patrz moduł 11
  • Migracja z App Engine do Cloud Run: w module 4 dowiesz się, jak skonteneryzować aplikację za pomocą Dockera, a w module 5 – jak to zrobić bez kontenerów, wiedzy o Dockerze ani Dockerfiles

Przejście na inną platformę bezserwerową 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.

7. Dodatkowe materiały

Poniżej znajdziesz dodatkowe materiały dla programistów, którzy chcą dowiedzieć się więcej o tym lub powiązanym module migracji, a także o powiązanych produktach. Znajdziesz tu m.in. miejsca, w których możesz przesłać opinię o tych treściach, linki do kodu i różne dokumenty, które mogą Ci się przydać.

Problemy z ćwiczeniami z programowania i opinie na ich temat

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 1 (START) i modułu 1b (FINISH) znajdziesz w tabeli poniżej. Można je też znaleźć w repozytorium wszystkich migracji ćwiczeń z programowania App Engine.

Ćwiczenia z programowania

Python 2

Python 3

Moduł 1

kod

Nie dotyczy

Moduł 17 (te ćwiczenia z programowania)

Nie dotyczy

code (mod1b-flask)

Zasoby online

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

Usługi pakietowe App Engine

Ogólna dokumentacja App Engine

Inne informacje o chmurze

Filmy

Licencja

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