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

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.

Wcześniej deweloperzy musieli przeprowadzić migrację ze starszych „pakietów usług” App Engine. np. Datastore i Memcache, zanim będą mogli uaktualnić wersje językowe. Dzięki udostępnieniu w usłudze App Engine 2 generacji wielu kluczowych usług zawartych w pakiecie deweloperzy mogą teraz przenosić swoje aplikacje do najnowszych środowisk wykonawczych, a jednocześnie (w większości przypadków) korzystać z pakietów usług. Dzięki temu ćwiczeniu w Codelabs dowiesz się, jak uaktualnić przykładową aplikację z języka Python 2 do 3 przy zachowaniu możliwości korzystania z pakietu Datastore (za pomocą biblioteki App Engine NDB). Korzystanie z większości usług zawartych w pakiecie wymaga tylko drobnej aktualizacji kodu, które omówimy w tym samouczku, ale istnieją inne, które wymagają bardziej poważnych zmian. zostaną one uwzględnione w części 2, w ramach modułu podsumowującego i ćwiczeń z programowania.

Dowiesz się, jak:

  • Przeniesienie przykładowej aplikacji App Engine z Pythona 2 do 3
  • Zaktualizuj konfigurację aplikacji, aby uwzględnić pakiet SDK App Engine
  • Dodaj kod SDK do aplikacji obsługującej pakiety usług w środowiskach wykonawczych drugiej generacji, takich jak Python 3

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

Oryginalna usługa App Engine wprowadzona w 2008 roku i zawierała starsze interfejsy API (obecnie nazywane usługami w pakiecie), które ułatwiają deweloperom tworzenie i wdrażanie aplikacji na całym świecie. Te usługi to Datastore, Memcache i kolejka zadań. Użytkownicy, choć jest to wygodne, użytkownicy obawiają się możliwości przenoszenia aplikacji w przypadku korzystania z zastrzeżonych interfejsów API, które wiążą się z App Engine. Chcieli też, aby aplikacje były bardziej przenośne. Połączenie tych usług było spowodowane tym, że wiele z tych usług dojrzałych i stały się samodzielnymi usługami Cloud, co skłoniło zespół App Engine do wprowadzenia platformy nowej generacji w 2018 roku bez tych rozwiązań.

Przenieśmy się w czasie do rzeczywistości – z pomocą programistów korzystających z języka Python 2, którzy chcą przejść na Pythona 3. W przypadku aplikacji 2.x korzystających z pakietów usług wymagana była migracja z tych usług do wersji 3.x, co oznaczało 2 wymuszone migracje do drugiej, potencjalnie trudne w obsłudze. Aby ułatwić tę zmianę, zespół App Engine jesienią 2021 r. wprowadził „wormhole”. dzięki czemu aplikacje działające w środowiskach wykonawczych nowej generacji mają dostęp do wielu usług dostępnych w pakiecie. Ta wersja nie obejmuje wszystkich usług dostępnych w pierwotnych środowiskach wykonawczych, ale są dostępne główne odtwarzacze, takie jak Datastore, kolejka zadań i Memcache.

To ćwiczenie w Codelabs pokazuje zmiany niezbędne do uaktualnienia aplikacji do Pythona 3 przy jednoczesnym zachowaniu możliwości korzystania z pakietów usług. Dzięki temu Twoje aplikacje będą działać w najnowszych środowiskach wykonawczych, co pozwoli Ci przejść z usług w pakiecie na ich samodzielne odpowiedniki lub alternatywne rozwiązania innych firm w dogodnym dla Ciebie terminie, bez konieczności blokowania przeszkód do przejścia na wersję 3.x. Chociaż migracja z pakietów usług nie jest już wymagana, to zwiększa ona swobodę przenoszenia i elastyczność miejsc, w których mogą być hostowane aplikacje. Może na przykład przejść na platformy, które mogą lepiej obsługiwać Twoje zadania, lub po prostu pozostać w App Engine podczas przejścia na nowszą wersję językową zgodnie z opisem.

Przykładowa aplikacja w module 1 w Pythonie 2 korzysta z pakietu Datastore dostępnego w App Engine NDB. Aplikacja przeniosła już platformy z webapp2 do Flask, co zostało ukończone w module kodowania w module 1, ale wykorzystanie Datastore pozostaje bez zmian.

W tym samouczku omawiamy następujące kroki:

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

3. Konfiguracja/praca

W tej sekcji dowiesz się, jak:

  1. Konfigurowanie projektu Cloud
  2. Pobierz przykładową aplikację bazową
  3. (Ponowne) wdrażanie i weryfikowanie aplikacji bazowej

Dzięki tym krokom zaczynasz od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz ukończony Moduł 1 ćwiczenia z programowania, zalecamy ponowne wykorzystanie tego samego projektu (i kodu). Możesz też utworzyć nowy projekt Cloud lub wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe, na którym włączono 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 aplikacji App Engine 1 w module 1. Wykonaj ćwiczenie z modułu 1 (zalecane) lub skopiuj aplikację z modułu 1 z repozytorium. Bez względu na to, czy używasz swojego czy naszego, „ROZPOCZNIJ” kod Modułu 1. To ćwiczenie w Codelabs przeprowadzi Cię przez poszczególne kroki, kończąc kodem przypominającym zawartość folderu repozytorium modułu 7 „FINISH”.

Niezależnie od tego, której aplikacji w module 1 używasz, folder powinien wyglądać tak jak poniżej (może być też zawierający folder lib):

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

3. (Ponowne) wdrażanie aplikacji podstawowej

Aby (ponownie) wdrożyć aplikację w module 1, wykonaj te czynności:

  1. Usuń folder lib (jeśli istnieje), a następnie uruchom polecenie pip install -t lib -r requirements.txt, aby ponownie uzupełnić dane lib. Jeśli masz zainstalowany język Python 2 i 3, może być konieczne użycie polecenia pip2.
  2. Upewnij się, że narzędzie wiersza poleceń gcloud zostało zainstalowane i zainicjowane, a także sprawdzisz jego użycie.
  3. Jeśli nie chcesz wpisywać PROJECT_ID w projekcie Cloud z każdym wydanym poleceniem gcloud, ustaw w nim gcloud config set project PROJECT_ID.
  4. Wdróż przykładową aplikację za pomocą: gcloud app deploy
  5. Potwierdź, że aplikacja w module 1 działa zgodnie z oczekiwaniami, bez problemów z wyświetlaniem ostatnich wizyt (poniżej).

a7a9d2b80d706a2b.png

4. Aktualizacja konfiguracji

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

Dodaj pakiet SDK do pliku requirements.txt

Środowisko wykonawcze App Engine Python 3 znacznie zmniejsza nakład pracy związanej z korzystaniem z bibliotek innych firm. Wystarczy, że wymienisz je w usłudze requirements.txt. Aby korzystać z pakietów w języku Python 3, dodaj do niego pakiet SDK App Engine o nazwie appengine-python-standard. Pakiet SDK dołącza Flask z modułu 1:

flask
appengine-python-standard

Zaktualizuj plik app.yaml

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

  1. Zastąp dyrektywę runtime obsługiwaną wersją Pythona 3. na przykład wpisz python310 w przypadku Pythona 3.10.
  2. Usuń dyrektywę threadsafe i api_version, ponieważ żadna z nich nie jest używana w Pythonie 3.
  3. Usuń całkowicie sekcję handlers, ponieważ ta aplikacja zawiera tylko moduły obsługi skryptów. Jeśli aplikacja ma statyczne moduły obsługi plików, pozostaw je w pliku handlers bez zmian.
  4. Środowisko wykonawcze Pythona 3 nie obsługuje wbudowanych bibliotek innych firm, tak jak środowisko Python 2. Jeśli Twoja aplikacja ma sekcję libraries w języku: app.yaml, usuń ją całą. (Wymagane pakiety muszą być wymienione tylko w usłudze requirements.txt – tak jak biblioteki niewbudowane). Nasza przykładowa aplikacja nie ma sekcji libraries, więc przejdź do następnego kroku.
  5. Aby jej użyć, utwórz dyrektywę app_engine_apis z wartością true – odpowiada to dodaniu pakietu SDK App Engine do biblioteki requirements.txt powyżej.

Podsumowanie zmian, które należy wprowadzić w usłudze 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 regionie requirements.txt. Jeśli nie masz w usłudze appengine_config.py czegoś specjalnego, usuń je. Podobnie jest w przypadku, gdy wszystkie biblioteki zewnętrzne są instalowane automatycznie podczas procesu kompilacji, więc nie trzeba kopiować ani dodawać ich dostawcy. Nie ma już polecenia pip install ani folderu lib – usuń je. Podsumowanie:

  • Usuń appengine_config.py plik
  • Usuń lib folder

To już koniec wszystkich niezbędnych zmian w konfiguracji.

5. Modyfikowanie kodu aplikacji

Dostęp do większości usług dostępnych w pakiecie w środowisku wykonawczym Pythona 3 wymaga krótkiego fragmentu kodu opakowującego obiekt aplikacji Web Server Gateway Interface (WSGI) w main.py. Funkcja opakowań to google.appengine.api.wrap_wsgi_app(). Używa się jej, importując i pakując z nią obiekt WSGI. Wprowadź zmiany poniżej, aby odzwierciedlić wymaganą aktualizację platformy 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 dodawania kodu WSGI znajdziesz w dokumentacji dotyczącej innych platform Python.

Ten przykład daje aplikacji dostęp do większości pakietów usług w języku Python 3, ale inne, takie jak Blobstore i Mail, wymagają dodatkowego kodu. Omówimy te przykłady w innym module migracji.

To już koniec wszystkich zmian niezbędnych do dodania korzystania z pakietów App Engine do przykładowej aplikacji w module 1. Ta aplikacja jest już zgodna z językami Python 2 i 3, więc nie wprowadza żadnych dodatkowych zmian w jej przeniesieniu do Pythona 3 poza tymi w konfiguracji. Ostatni krok: wdrożenie zmodyfikowanej aplikacji w środowisku wykonawczym nowej generacji App Engine Python 3 i potwierdzenie powodzenia aktualizacji.

6. Podsumowanie/Czyszczenie

W tej sekcji znajdziesz podsumowanie tego ćwiczenia w programie przez wdrożenie aplikacji oraz sprawdzenie, czy działa ona zgodnie z oczekiwaniami i we wszystkich uwzględnionych danych wyjściowych. Po sprawdzeniu aplikacji oczyść ją i zastanów się nad dalszymi czynnościami.

Wdróż i zweryfikuj aplikację

Wdróż aplikację w języku Python 3 za pomocą narzędzia gcloud app deploy i sprawdź, czy działa ona tak samo jak w Pythonie 2. Funkcje nie ulegają zmianie, dlatego dane wyjściowe powinny być takie same jak w aplikacji pochodzącej z Modułu 1:

a7a9d2b80d706a2b.png

Uwagi końcowe

Gratulujemy wykonania pierwszego kroku w kierunku przeniesienia aplikacji z App Engine w języku Python 2 do języka Python 3 przy zachowaniu możliwości korzystania z pakietów usług.

Czyszczenie danych

Ogólne

Jeśli na razie wszystko jest gotowe, wyłącz aplikację App Engine, aby uniknąć naliczania opłat. Jeśli jednak chcesz jeszcze bardziej przetestować lub poeksperymentować, platforma App Engine ma bezpłatny limit. Dopóki nie przekroczysz tego limitu, nie pobierzemy żadnych opłat. Oznacza to obliczenia, ale mogą być też naliczane opłaty za odpowiednie usługi App Engine. Więcej informacji znajdziesz na stronie z cennikiem. Jeśli ta migracja obejmuje inne usługi Cloud, są one rozliczane osobno. W obu przypadkach zapoznaj się z sekcją „Zapoznaj się z tymi ćwiczeniami”. sekcji poniżej.

Aby w pełni wyjaśnić wszystkie kwestie, wdrożenie na bezserwerowej platformie obliczeniowej Google Cloud, takiej jak App Engine, wiąże się z niewielkimi kosztami kompilacji i przechowywania danych. 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 poziomu bezpłatnego. Dlatego pamiętaj o wykorzystaniu miejsca na dane, aby zminimalizować potencjalne koszty. Określone „foldery” Cloud Storage należy sprawdzić m.in.:

  • 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
  • Powyższe linki do miejsca na dane zależą od Twoich danych PROJECT_ID oraz *LOC*, np. „us” jeśli aplikacja jest hostowana w Stanach Zjednoczonych.

Jeśli natomiast nie zamierzasz dalej korzystać z tej aplikacji lub innych powiązanych z nią ćwiczeń w Codelabs i chcesz całkowicie usunąć wszystko, zamknij projekt.

Powiązane z tym ćwiczeniam z programowania

Wymienione poniżej usługi są dostępne tylko w ramach tego ćwiczenia z programowania. Więcej informacji znajdziesz w dokumentacji poszczególnych usług:

Dalsze kroki

Tutaj znajdziesz kilka wskazówek:

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

Dostęp do innych pakietów usług, takich jak Blobstore, Mail i Deferred, wymaga wprowadzenia dodatkowych zmian w kodzie. Moduły migracji skupiające się na odejściu od starszych pakietów usług App Engine, które obejmują:

App Engine nie jest już jedyną bezserwerową platformą w Google Cloud. Jeśli masz małą aplikację App Engine lub taką, która ma ograniczoną funkcjonalność i chcesz przekształcić ją w samodzielny mikroserwis, albo chcesz podzielić aplikację monolityczną na kilka komponentów wielokrotnego użytku, rozważ przejście na Cloud Functions. Jeśli konteneryzacja stała się częścią przepływu pracy przy tworzeniu aplikacji, zwłaszcza jeśli składa się z potoku CI/CD (ciągła integracja/ciągłe dostarczanie lub wdrażanie), rozważ migrację do Cloud Run. Te scenariusze są opisane w tych modułach:

  • Migracja z App Engine do Cloud Functions: patrz Moduł 11.
  • Migracja z App Engine do Cloud Run: zapoznaj się z Modułem 4, aby skonteneryzować aplikację za pomocą Dockera, lub Moduł 5, aby zrobić to bez kontenerów, Dockera lub Dockerfile.

Przejście na inną bezserwerową platformę jest opcjonalne. Zalecamy, aby przed wprowadzeniem jakichkolwiek zmian wybrać najlepsze opcje dla swoich 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.

7. Dodatkowe materiały

Poniżej znajdziesz dodatkowe materiały dla deweloperów omawiające ten lub powiązany moduł migracji oraz powiązane usługi. Są to miejsca, w których można przesłać opinię o tych treściach, linki do kodu i różne artykuły, które mogą Ci się przydać.

Problemy z ćwiczeniami w Codelabs/opinie

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 1 (START) i modułach 1b (FINISH) znajdziesz w tabeli poniżej. Dostęp do nich możesz też uzyskać z repozytorium w przypadku wszystkich migracji ćwiczeń z programowania App Engine.

Codelab

Python 2

Python 3

Część 1

kod

Nie dotyczy

Moduł 17 (to ćwiczenie z programowania)

Nie dotyczy

code (mod1b-flask)

Zasoby online

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

Pakiety usług App Engine

Dokumentacja ogólna App Engine

Inne informacje o Google Cloud

Filmy

Licencja

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