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

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.

Z tych ćwiczeń z programowania dowiesz się, jak w przykładowej aplikacji z ćwiczeń z programowania w module 1 uwzględnić i używać pamięci podręcznej Memcache w App Engine. W tym samouczku z modułu 12 dodamy użycie Memcache, a następnie w module 13 przejdziemy na Cloud Memorystore.

Dowiesz się, jak:

  • Korzystanie z interfejsu API lub biblioteki Memcache App Engine
  • Dodawanie buforowania do podstawowej aplikacji w Pythonie 2 Flask App Engine NDB

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

Aby przeprowadzić migrację z App Engine Memcache, dodaj jego użycie do istniejącej aplikacji Flask i App Engine NDB, która powstała w wyniku ćwiczenia z modułu 1. 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 obiektów Visit i pobieranie najnowszych wizyt z Datastore nie jest optymalne, dlatego będziemy buforować te najnowsze wizyty.

Jeśli ten sam użytkownik odwiedzi stronę ponownie, wizyty zostaną zwrócone z pamięci podręcznej. Jeśli nowy użytkownik odwiedzi witrynę lub minie godzina, pamięć podręczna zostanie wyczyszczona i zastąpiona najnowszymi wpisami (nie wspominając o zarejestrowaniu nowej wizyty). Po zaimplementowaniu tej integracji App Engine Memcache możemy przenieść ją do Cloud Memorystore w kolejnych ćwiczeniach (moduł 13).

Ten samouczek obejmuje te kroki:

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

3. Konfiguracja/przygotowanie

Zanim przejdziemy do głównej części samouczka, skonfigurujmy projekt, pobierzmy kod i wdrożymy aplikację podstawową, aby mieć pewność, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz za sobą moduł 1, 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 i czy usługa App Engine jest włączona.

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 1. Jeśli jej nie masz, przed przejściem do dalszej części wykonaj jeden z powyższych samouczków. Jeśli znasz już jego zawartość, możesz od razu przejść do kodu modułu 1 poniżej.

Niezależnie od tego, czy używasz własnego kodu, czy naszego, zaczniemy od kodu modułu 1. Te warsztaty programistyczne przeprowadzą Cię przez wszystkie etapy i zakończą się kodem podobnym do tego, który znajduje się w folderze repozytorium modułu 11 (FINISH).

Katalog plików STARTowych modułu 1 (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.

Gdy wykonasz te czynności i zobaczysz, że aplikacja internetowa działa (z danymi wyjściowymi podobnymi do poniższych), możesz dodać do niej korzystanie z pamięci podręcznej.

a7a9d2b80d706a2b.png

4. Aktualizacja konfiguracji

Nie trzeba wprowadzać żadnych zmian w standardowych plikach konfiguracyjnych App Engine (app.yaml, requirements.txt, appengine_config.py).

5. Modyfikowanie plików aplikacji

Dodajemy tylko interfejs API App Engine, więc nie ma potrzeby aktualizowania żadnych pakietów zewnętrznych ani plików konfiguracyjnych (app.yaml, requirements.txt, appengine_config.py). Jest tylko jeden 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ż będziemy buforować najnowsze wizyty przez godzinę, dodajmy też stałą określającą liczbę sekund w godzinie. Poniżej znajdziesz wygląd kodu przed wprowadzeniem tej zmiany i po niej:

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

Dodawanie buforowania z obsługą Memcache

Najważniejszą zmianą jest dodanie do naszej aplikacji korzystania z pamięci podręcznej. Powinniśmy w szczególności przechowywać w pamięci podręcznej ostatnie wizyty, sprawdzać, czy są dostępne, i w miarę możliwości korzystać z wyników przechowywanych w pamięci podręcznej w ramach naszego planu. Aby osiągnąć nasz cel, aplikacja wykona te czynności:

  1. Ustaw bieżącą wizytę i nazwij ją visitor
  2. Próba pobrania najnowszej wersji visits z pamięci podręcznej
  3. Jeśli pamięć podręczna jest pusta lub ostatni odwiedzający (visits[0]['visitor']) różni się od bieżącego visitor: zapisz tę najnowszą wizytę, pobierz ostatnie wizyty i zapisz je w pamięci podręcznej na godzinę.
  4. Wyświetlanie symbolu visits użytkownikowi za pomocą szablonu internetowego

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:

@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 ilustracja wprowadzonych zmian:

b1242503602f7bf0.png

To wszystkie niezbędne zmiany, które należy wprowadzić, aby dodać korzystanie z App Engine memcache do przykładowej aplikacji z modułu 1. Skompilujmy i wdrożmy tę aplikację, aby sprawdzić, jak działa.

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 czynności związane z czyszczeniem i zastanów się, co dalej zrobić.

Wdrażanie i weryfikowanie aplikacji

Ponownie wdróż aplikację za pomocą gcloud app deploy i sprawdź, czy działa. Twój kod powinien teraz być zgodny z kodem w folderze Moduł 12 w sekcji ZAKOŃCZ. Dane wyjściowe powinny być identyczne z aplikacją z modułu 1, którą wdrożono wcześniej:

a7a9d2b80d706a2b.png

Po prostu przyspieszyliśmy działanie usługi dla tego samego użytkownika. Po odświeżeniu strony wyniki powinny być pobierane bezpośrednio z pamięci podręcznej, co nie powoduje utworzenia nowej wizyty ani pobrania danych z Datastore.

Gratulujemy ukończenia ćwiczenia (w Codelabs) z modułu 12, w którym dodaliśmy do naszej przykładowej aplikacji korzystanie z usługi App Engine memcache. W kroku dodatkowym możesz teraz przenieść tę aplikację w Pythonie 2 do Pythona 3.

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:

  • Usługa App Engine Memcache występuje w 2 wariantach, z których każdy ma własną strukturę cenową. Musisz więc śledzić wykorzystanie tej usługi w kontekście rozliczeń.
  • Usługa App Engine Datastore jest udostępniana przez Cloud Datastore (Cloud Firestore w trybie Datastore), która również ma bezpłatny poziom. Więcej informacji znajdziesz na stronie z cennikiem.

Dalsze kroki

Kolejna logiczna migracja, którą warto rozważyć, jest opisana w module 13. Pokazuje on programistom, jak przeprowadzić migrację 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 jest znaczącym ulepszeniem memcache w App Engine z wielu powodów:

  • Cloud Memorystore nie jest usługą bezserwerową. Oznacza to, że musisz przydzielić serwer do pamięci podręcznej. Cloud Memorystore nie ma też poziomu bezpłatnego. Oba te czynniki mogą mieć znaczący wpływ na koszt.
  • Cloud Memorystore obsługuje 2 różne mechanizmy pamięci masowej (silniki pamięci podręcznej): Redis i Memcached.
  • Cloud Memorystore (for Redis) ma znacznie bogatszy i bardziej zaawansowany zestaw funkcji niż App Engine Memcache.
  • Aby korzystać z Cloud Memorystore, musisz skonfigurować serwer Cloud Memorystore, dodać go do sieci VPC Google Cloud, a następnie skonfigurować aplikację App Engine tak, aby używała tej sieci do komunikacji z serwerem Memorystore.

Jeśli nie potrzebujesz wszystkich funkcji dostępnych w Cloud Memorystore lub martwisz się o ich wpływ na koszty, możesz nadal korzystać z App Engine Memcache.

Po module 13 znajdziesz wiele innych możliwych migracji, takich jak Cloud NDB i Cloud Datastore czy Cloud Tasks. Istnieją też migracje między usługami do Cloud Run i Cloud Functions. Znajdziesz je w repozytorium migracji.

Kolejnym możliwym krokiem jest przeniesienie kodu do Pythona 3, co zostało opisane w następnej sekcji jako krok opcjonalny.

7. BONUS: Migracja do Pythona 3

Przegląd

Ta sekcja zawiera opcjonalne treści dodatkowe dotyczące przenoszenia aplikacji z modułu 12, którą właśnie skończyliśmy, do Pythona 3. Zaczynamy od konfiguracji, a potem przechodzimy do aplikacji.

Uproszczenie pliku app.yaml

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

PRZED:

Oto, co znajduje się w app.yaml na zakończenie modułu 12:

runtime: python27
threadsafe: yes
api_version: 1

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

Środowisko wykonawcze Pythona 3 wymaga, aby platformy internetowe samodzielnie wykonywały routing, dlatego wszystkie moduły obsługi tras w app.yaml muszą zostać zmienione na auto. Jeśli nie ma statycznych plików, użytkownicy mogą po prostu usunąć całą sekcję handlers:. Zostały też wycofane threadsafe i api_version.

PO:

Po wprowadzeniu opisanych powyżej zmian app.yaml zastępuje Pythona 3:

runtime: python39
app_engine_apis: true

Wyjaśnienia wymaga tylko wiersz app_engine_apis: true. Gdy w 2021 roku starsze usługi App Engine stały się dostępne dla środowisk wykonawczych drugiej generacji, niektóre środowiska wykonawcze, w tym Python 3, wymagały dodatkowego uruchamiania, aby uzyskać dostęp do interfejsów API, takich jak ndb, taskqueue i memcache. Temu służy ten wiersz w konfiguracji.

Aktualizowanie pliku requirements.txt

W requirements.txt wymagane jest kolejne uruchomienie pierwotnych interfejsów API: musi być uwzględniony dostęp do nowego pakietu SDK App Engine.

PRZED:

Oto, co znajduje się w app.yaml na zakończenie modułu 12:

flask

PO:

Wystarczy dodać pakiet App Engine Python SDK, aby uzyskać:

flask
appengine-python-standard

Usuwanie plików appengine_config.py i lib

Środowiska wykonawcze App Engine nowej generacji zmieniają sposób korzystania z pakietów innych firm:

  • Wbudowane biblioteki to biblioteki sprawdzone przez Google i udostępnione na serwerach App Engine, prawdopodobnie dlatego, że zawierają kod C/C++, którego deweloperzy nie mogą wdrażać w chmurze. Nie są one już dostępne w środowiskach wykonawczych 2 generacji.
  • Kopiowanie bibliotek wbudowanych (czasami nazywane „dostarczaniem” lub „samodzielnym pakowaniem”) nie jest już potrzebne w środowiskach wykonawczych drugiej generacji. Zamiast tego powinny być wymienione w requirements.txt, gdzie system kompilacji automatycznie zainstaluje je w Twoim imieniu w momencie wdrażania.

W wyniku tych zmian w zarządzaniu pakietami innych firm plik appengine_config.py ani folder lib nie są już potrzebne, więc je usuń. W środowiskach wykonawczych drugiej generacji App Engine automatycznie instaluje pakiety innych firm wymienione w requirements.txt. Podsumowywanie:

  1. Brak bibliotek innych firm w pakiecie lub skopiowanych; wymień je w requirements.txt
  2. Brak pip install w folderze lib, co oznacza, że nie ma folderu lib.
  3. Brak wbudowanych bibliotek innych firm w informacjach o produkcie (a tym samym brak sekcji libraries) w app.yaml; wymień je w requirements.txt
  4. Brak bibliotek innych firm, do których można się odwoływać w aplikacji, oznacza brak pliku appengine_config.py.

Wymaganiem dla dewelopera jest tylko wymienienie wszystkich żądanych bibliotek innych firm w requirements.txt.

Modyfikowanie aplikacji w celu wykorzystania pakietu SDK App Engine

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

  1. Pakiet SDK App Engine (w requirements.txt)
  2. Aktywowanie pakietu SDK App Engine (w app.yaml)
  3. Zawijanie obiektu WSGI (w main.py)

Pierwsza para została już uzupełniona, więc ostatnim wymaganiem jest zaktualizowanie main.py.

PRZED:

Poniżej znajduje się kod w Pythonie 2 main.py na końcu 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 Python 3 zaimportuj pakiet SDK i otocz nim obiekt aplikacji Flask (otoczka pakietu SDK), co da następujący efekt:

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 muszą wprowadzić te zmiany w aplikacjach w języku Python podczas przenoszenia ich z wersji 2.x do wersji 3.x, aby uzyskać dostęp do usług pakietowych. Jeśli nie używasz Flaska, w dokumentacji znajdziesz też przykłady Django i Pyramid. Jeśli Twój kod w języku Python 2 nie jest aplikacją internetową, podczas przenoszenia go do języka Python 3 wystarczy uwzględnić pakiet SDK. Kod naszej aplikacji został pierwotnie opracowany tak, aby działał w językach Python 2 i 3, więc nie są potrzebne żadne dodatkowe zmiany związane ze zgodnością.

Wdróż aplikację

Po wprowadzeniu powyższych zmian możesz wdrożyć zaktualizowaną przykładową aplikację. (Wdrożenie wersji aplikacji w Pythonie 3 na oryginalną wersję w Pythonie 2 w tym samym projekcie GCP nie powoduje problemów). Działanie aplikacji powinno pozostać takie samo. Jeśli chcesz porównać zaktualizowaną aplikację z naszą, zajrzyj do folderu Moduł 12b w repozytorium migracji. Więcej informacji o obsłudze pakietów usług App Engine w najnowszych środowiskach wykonawczych, takich jak Python 3, znajdziesz w ogłoszeniu o wprowadzeniu funkcji oraz w module 17 codelabu.

Gratulujemy ukończenia dodatkowego kroku w module 12. Zapoznaj się też z dokumentacją dotyczącą przygotowywania plików konfiguracyjnych dla środowiska wykonawczego Python 3. W sekcji Podsumowanie/Czyszczenie powyżej znajdziesz dalsze kroki i instrukcje czyszczenia.

8. 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 2 (START) i modułu 12 (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 2

Python 3

Moduł 1

kod

kod (nie jest omawiany w tym samouczku)

Moduł 12 (te ćwiczenia z programowania)

kod

kod

Odsyłacze online

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

App Engine

Cloud Memorystore i Cloud Datastore

Inne informacje o chmurze

Filmy

Licencja

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