Jak używać pamięci App Engine Memcache w aplikacjach Flask (moduł 12)

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. Dzięki temu aplikacje stają się bardziej przenośne, a Ty mają więcej opcji i elastyczności, 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.

Dzięki temu ćwiczeniu w Codelabs dowiesz się, jak uwzględniać i używać App Engine Memcache w przykładowej aplikacji z modułu 1 Codelabs. W tym samouczku modułu 12 dodaliśmy informacje o wykorzystaniu Memcache, a następnie w następnej części modułu 13 przeniesiemy go do Cloud Memorystore.

Dowiesz się, jak:

  • Używanie interfejsu API/biblioteki App Engine Memcache
  • Dodaj buforowanie do podstawowej aplikacji w Pythonie 2 Flask App Engine NDB

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

Aby przeprowadzić migrację z App Engine Memcache, dodaj jej wykorzystanie do dotychczasowej aplikacji Flask i App Engine NDB wynikowej z modułu 1 Codelabs. Przykładowa aplikacja wyświetla 10 ostatnich wizyt użytkownika. Jeśli ten sam użytkownik odświeży przeglądarkę, ciągłe tworzenie nowych encji wizyt i pobieranie informacji o ostatnich wizytach z Datastore nie będzie optymalne, dlatego te ostatnie wizyty będziemy zapisywać w pamięci podręcznej.

Jeśli ten sam użytkownik odwiedza stronę, jego wizyty są zwracane z pamięci podręcznej. Jeśli witrynę odwiedzi nowy użytkownik lub minie godzina, pamięć podręczna zostanie opróżniona i zastąpiona najnowszymi wpisami (już nie wspominając o nowej wizycie). Po zaimplementowaniu tej integracji App Engine Memcache będziemy mogli przenieść ją do Cloud Memorystore w kolejnym ćwiczeniu z programowania (Moduł 13).

W tym samouczku omawiamy następujące kroki:

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

3. Konfiguracja/praca

Zanim przejdziemy do głównej części samouczka, skonfigurujmy projekt, pobierz kod, a potem wdróż aplikację bazową. W ten sposób wiemy, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz już za sobą ćwiczenia z programowania w module 1, 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łączona usługa 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 1. Jeśli nie masz jeszcze takiego samouczka, przed przejściem do tego miejsca wykonaj czynności opisane w jednym z samouczków (linki znajdziesz powyżej). W przeciwnym razie, jeśli znasz już jego treść, możesz zacząć od poniższego kodu Modułu 1.

Zacznijmy od kodu modułu 1 niezależnie od tego, czy używasz swojego czy naszego. To ćwiczenie w Codelabs przeprowadzi Cię przez poszczególne kroki, kończąc kodem przypominającym to, co znajduje się w folderze repozytorium modułu 11 (FINISH).

Katalog plików START (Twoich lub naszych) modułu 1 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 czynności i sprawdzeniu, że aplikacja internetowa działa (z danymi wyjściowymi podobnymi do widocznych poniżej), możesz dodać do niej funkcję zapisywania w pamięci podręcznej.

a7a9d2b80d706a2b.png

4. Aktualizacja konfiguracji

W standardowych plikach konfiguracji App Engine (app.yaml, requirements.txt, appengine_config.py) nie musisz wprowadzać żadnych zmian.

5. Modyfikowanie plików aplikacji

Dodajemy tylko interfejs App Engine API, więc nie wymagamy żadnych pakietów zewnętrznych, co oznacza, że nie trzeba aktualizować żadnych plików konfiguracji (app.yaml, requirements.txt, appengine_config.py). Masz tylko 1 plik aplikacji (main.py), więc wszystkie zmiany w tej sekcji dotyczą tylko tego pliku.

Importy

Najważniejszym krokiem jest zaimportowanie biblioteki Memcache google.appengine.api.memcache. Ponieważ ostatnie odwiedziny będą przechowywane w pamięci podręcznej przez godzinę, dodajmy również stałą liczbę sekund w ciągu godziny. Poniżej przedstawiono wygląd kodu przed wprowadzeniem tej zmiany:

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 memcache
from google.appengine.ext import ndb

app = Flask(__name__)
HOUR = 3600

Dodaj buforowanie z obsługą Memcache

Najważniejsza zmiana polega na dodaniu możliwości korzystania z buforowania w naszej aplikacji. Dokładniej rzecz ujmując, należy zapisywać ostatnie wizyty w pamięci podręcznej, sprawdzać, czy są one dostępne w pamięci podręcznej, i starać się jak najlepiej korzystać z wyników zapisanych w pamięci podręcznej zgodnie z planem. Oto kroki, jakie musi wykonać aplikacja, aby osiągnąć nasz cel:

  1. Ustaw bieżącą wizytę i nazwij ją visitor
  2. Spróbuj pobrać najnowszą wartość visits z pamięci podręcznej
  3. Jeśli pamięć podręczna jest pusta lub ostatni użytkownik (visits[0]['visitor']) różni się od bieżącego użytkownika visitor: zapisz ostatnią wizytę, pobierz najnowsze wizyty i zapisz je w pamięci podręcznej na godzinę.
  4. Wyświetlaj użytkownikowi visits za pomocą szablonu internetowego

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:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0]['visitor'] != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

Oto obrazowe przedstawienie wprowadzonych zmian:

b1242503602f7bf0.png

To koniec wszystkich zmian niezbędnych do dodania funkcji memcache App Engine do przykładowej aplikacji w module 1. Skompilujmy i wdróżmy tę aplikację, aby przekonać się, jak działa.

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 wykonaj czynności związane z czyszczeniem i zastanów się nad dalszymi czynnościami.

Wdróż i zweryfikuj aplikację

Wdróż ponownie aplikację za pomocą narzędzia gcloud app deploy i sprawdź, czy działa. Twój kod powinien być teraz zgodny z informacjami w pliku FINISH, czyli w folderze modułu 12. Dane wyjściowe powinny być takie same jak w przypadku wdrożonej wcześniej aplikacji z modułu 1:

a7a9d2b80d706a2b.png

Udało nam się tylko zwiększyć wygodę użytkowników. Po odświeżeniu strony wyniki powinny zostać pobrane bezpośrednio z pamięci podręcznej, która nie tworzy nowej wizyty ani nie wykonuje pobierania z Datastore.

Gratulujemy ukończenia modułu 12 z programowania dotyczącego dodania usługi App Engine memcache do naszej przykładowej aplikacji. W ramach dodatkowego kroku możesz teraz przenieść tę aplikację w Pythonie 2 na język Python 3.

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:

  • Usługa App Engine Memcache jest dostępna w dwóch wersjach, z których każdy ma odrębną cenę. Musisz więc śledzić jej wykorzystanie w kontekście płatności.
  • Usługa App Engine Datastore jest świadczona przez Cloud Datastore (Cloud Firestore w trybie Datastore), który również ma poziom bezpłatny. więcej informacji znajdziesz na stronie z cennikiem.

Dalsze kroki

Kolejna migracja logiczna, którą należy rozważyć, jest omówiona w module 13. Przedstawia on deweloperom, jak przejść z usługi App Engine memcache do Cloud Memorystore. Wszystkie te migracje są opcjonalne i dostępne dla użytkowników, którzy chcą podjąć różne kroki w celu modernizacji swoich aplikacji. Usługa Cloud Memorystore stanowi istotne uaktualnienie do memcache App Engine z wielu powodów:

  • Usługa Cloud Memorystore nie jest bezserwerowa. Oznacza to, że musisz przydzielić serwer do pamięci podręcznej. Cloud Memorystore nie ma także poziomu bezpłatnego. Oba te czynniki mogą mieć znaczący wpływ na koszty.
  • Cloud Memorystore obsługuje parę różnych bazowych mechanizmów przechowywania danych (mechanizmów buforowania) oraz Redis i Memcached.
  • Cloud Memorystore (for Redis) ma znacznie bogatszy i bardziej zaawansowany zestaw funkcji niż App Engine Memcache.
  • Aby używać Cloud Memorystore, musisz skonfigurować serwer Cloud Memorystore, dodać go do sieci Google Cloud VPC, a następnie pozwolić aplikacji App Engine używać tej sieci do komunikowania się z serwerem Memorystore.

Jeśli nie potrzebujesz wszystkich funkcji dostępnych w Cloud Memorystore lub obawiasz się, jak wpłynie to na koszty, możesz pozostać przy App Engine Memcache.

Poza modułem 13 jest cała masa innych możliwych migracji, takich jak Cloud NDB, Cloud Datastore czy Cloud Tasks. Dostępne są też migracje z różnych usług do Cloud Run i Cloud Functions. Znajdziesz je wszystkie w repozytorium migracji.

Kolejnym możliwym krokiem jest przejście na Pythona 3, które zostało opisane w następnej sekcji (jako opcjonalny krok).

7. BONUS: migracja do Pythona 3

Omówienie

Ta sekcja zawiera opcjonalną dodatkową treść przenoszącą aplikację modułu 12, którą właśnie zakończyliśmy, do Pythona 3. Zaczynamy od konfiguracji, po której następuje aplikacja.

Uprość plik app.yaml

Jedną z zalet środowiska wykonawczego Pythona 3 jest to, że app.yaml można znacznie uprościć.

PRZED:

Poniżej znajdziesz podsumowanie modułu 12, który zawiera: app.yaml:

runtime: python27
threadsafe: yes
api_version: 1

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

Środowisko wykonawcze Pythona 3 wymaga od platform internetowych samodzielnego routingu, dlatego wszystkie moduły obsługi tras w app.yaml należy zmienić na auto. Jeśli nie wyświetlają się żadne pliki statyczne, użytkownicy mogą po prostu usunąć całą sekcję handlers:. Dodatkowo obiekty threadsafe i api_version zostały wycofane.

PO:

Po omówieniu opisanych wymaganych zmian jest to zastąpienie app.yaml dla Pythona 3:

runtime: python39
app_engine_apis: true

Jedyny wiersz, który wymaga wyjaśnienia, to app_engine_apis: true. Gdy w 2021 r. starsze usługi App Engine stały się dostępne dla środowisk wykonawczych drugiej generacji, niektóre środowiska wykonawcze, w tym Python 3, wymagają dodatkowego wczytywania, aby uzyskać dostęp do tych interfejsów API, takich jak ndb, taskqueue i memcache. Ten wiersz w konfiguracji służy do tego celu.

Zaktualizuj plik requirements.txt

W requirements.txt wymagane jest kolejne uruchomienie oryginalnych interfejsów API: musisz uwzględnić dostęp do nowego pakietu SDK App Engine.

PRZED:

Poniżej znajdziesz podsumowanie modułu 12, który zawiera: app.yaml:

flask

PO:

Wystarczy, że dodasz pakiet App Engine Python SDK, który powinien być gotowy:

flask
appengine-python-standard

Usuń plik appengine_config.py i lib

Środowiska wykonawcze App Engine nowej generacji ulepszają wykorzystanie pakietów innych firm:

  • Biblioteki wbudowane to sprawdzone przez Google i udostępnione na serwerach App Engine, prawdopodobnie dlatego, że zawierają kod C/C++, którego programiści nie mogą wdrażać w chmurze. Nie są one już dostępne w środowiskach wykonawczych drugiej generacji.
  • W środowiskach wykonawczych drugiej generacji nie trzeba już kopiować niewbudowanych bibliotek (nazywanych czasem „vendoring” lub „samodzielnym grupowaniem”). Zamiast tego powinny znajdować się w regionie requirements.txt, gdzie system kompilacji automatycznie instaluje je w Twoim imieniu podczas wdrażania.

W wyniku tych zmian w zarządzaniu pakietami innych firm nie jest potrzebny ani plik appengine_config.py, ani folder lib. Usuń te pliki. W środowiskach wykonawczych 2 generacji App Engine automatycznie instaluje pakiety innych firm wymienione w zasadzie requirements.txt. Podsumowanie:

  1. Zakaz korzystania z pakietów samodzielnie lub skopiowanych bibliotek zewnętrznych. wymień je w folderze requirements.txt
  2. Brak elementów pip install do folderu lib, co oznacza brak okresu folderu lib
  3. Brak informacji o wbudowanych bibliotekach innych firm (czyli brak sekcji libraries) w app.yaml; wymień je w usłudze requirements.txt
  4. Brak bibliotek innych firm, do których można się odwoływać z aplikacji, oznacza brak pliku appengine_config.py

Jedynym wymaganiem programistycznym jest umieszczenie w pliku requirements.txt wszystkich bibliotek innych firm.

Zaktualizuj aplikację, aby używać pakietu SDK App Engine

Jak wspomnieliśmy powyżej, aplikacje w języku Python 3 wymagają pewnych zmian, aby uzyskać dostęp do usług pakietu App Engine:

  1. Pakiet SDK App Engine (w requirements.txt)
  2. Aktywuj pakiet SDK App Engine (w lokalizacji app.yaml)
  3. Zawijaj obiekt WSGI (w main.py)

Pierwsza para została ukończona powyżej, więc ostatnim wymaganiem jest zaktualizowanie main.py.

PRZED:

Poniżej znajdziesz informacje na temat main.py w języku Python 2 na zakończenie modułu 12:

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

app = Flask(__name__)
HOUR = 3600

PO:

W przypadku portu Pythona 3 zaimportuj pakiet SDK i opakuj z nim obiekt aplikacji Flask (kod pakietu SDK). Spowoduje to następujący wynik:

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

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

Deweloperzy, którzy przechodzą z wersji 2.x na 3.x, muszą wprowadzić te zmiany w swoich aplikacjach w języku Python, aby uzyskać dostęp do pakietów usług. Jeśli nie używasz Flask, w dokumentacji znajdziesz też przykłady Django i Pyramid. Jeśli Twój kod w Pythonie 2 nie jest aplikacją internetową, przy przenoszeniu go do Pythona 3 wystarczy dołączyć pakiet SDK. Nasz kod aplikacji został pierwotnie przygotowany do działania w językach Python 2 i 3, więc nie są wymagane dodatkowe zmiany w zakresie zgodności.

Wdróż aplikację

Po wprowadzeniu powyższych zmian możesz wdrożyć zaktualizowaną przykładową aplikację. Podczas wdrażania aplikacji w języku Python 3 zamiast oryginalnej wersji Pythona 2 w tym samym projekcie GCP nie ma problemów. Działanie aplikacji powinno pozostać takie samo. Jeśli chcesz porównać zaktualizowaną aplikację z naszą, patrz folder Moduł 12b w repozytorium migracji. Aby dowiedzieć się więcej o obsłudze pakietów App Engine w najnowszych środowiskach wykonawczych, takich jak Python 3, zapoznaj się z ogłoszeniem o wprowadzeniu funkcji oraz ćwiczeniami z programowania w module 17.

Gratulujemy wykonania dodatkowego kroku w module 12. Zapoznaj się też z dokumentacją dotyczącą przygotowywania plików konfiguracji na potrzeby środowiska wykonawczego Pythona 3. Zapoznaj się z sekcją Podsumowanie/Czyszczenie, aby poznać następne kroki i czyszczenie.

8. 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 2 (START) i modułach 12 (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ęść 1

kod

code (kod nie jest omówiony w tym samouczku)

Moduł 12 (to ćwiczenia z programowania)

kod

kod

Dokumentacja online

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

App Engine

Cloud Memorystore i Cloud Datastore

Inne informacje o Google Cloud

Filmy

Licencja

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