So verwenden Sie App Engine Memcache in Flask-Anwendungen (Modul 12)

1. Übersicht

Die Codelabs der Reihe „Serverless Migration Station“ (selbstgesteuerte, praktische Anleitungen) und die zugehörigen Videos sollen serverlosen Google Cloud-Entwicklern helfen, ihre Anwendungen zu modernisieren. Dazu werden sie durch eine oder mehrere Migrationen geführt, bei denen es in erster Linie darum geht, von Legacy-Diensten wegzukommen. Dadurch werden Ihre Apps portierbarer und Sie erhalten mehr Optionen und Flexibilität. Sie können eine größere Auswahl an Cloud-Produkten einbinden und darauf zugreifen und einfacher auf neuere Sprachversionen upgraden. Die Reihe konzentriert sich zwar anfangs auf die ersten Cloud-Nutzer, vor allem auf App Engine-Entwickler (Standardumgebung), ist aber breit genug, um auch andere serverlose Plattformen wie Cloud Functions und Cloud Run oder andere Plattformen einzubeziehen, sofern zutreffend.

In diesem Codelab erfahren Sie, wie Sie App Engine Memcache in die Beispiel-App aus dem Codelab zu Modul 1 einbinden und verwenden. In dieser Anleitung für Modul 12 fügen wir die Verwendung von Memcache hinzu und migrieren dann in Modul 13 zu Cloud Memorystore.

Lerninhalte

  • App Engine Memcache API/Bibliothek verwenden
  • Caching zu einer einfachen Python 2-Flask-App Engine NDB-Anwendung hinzufügen

Voraussetzungen

Umfrage

Wie werden Sie diese Anleitung verwenden?

Nur lesen Lesen und Übungen durchführen

Wie würden Sie Ihre Erfahrung mit Python bewerten?

Anfänger Mittelstufe Fortgeschrittene

Wie würden Sie Ihre Erfahrungen mit Google Cloud-Diensten bewerten?

Anfänger Mittelstufe Fortgeschritten

2. Hintergrund

Um von App Engine Memcache zu migrieren, fügen Sie die Verwendung von App Engine Memcache der vorhandenen Flask- und App Engine NDB-App hinzu, die aus dem Codelab zu Modul 1 stammt. In der Beispiel-App werden die zehn letzten Besuche des Nutzers angezeigt. Wenn derselbe Nutzer seinen Browser aktualisiert, ist es nicht optimal, ständig neue Besuchs-Entitäten zu erstellen und die letzten Besuche aus dem Datenspeicher abzurufen. Daher werden die letzten Besuche im Cache gespeichert.

Wenn derselbe Besucher die Seite aufruft, werden diese Besuche aus dem Cache zurückgegeben. Wenn ein neuer Nutzer die Website besucht oder eine Stunde vergangen ist, wird der Cache geleert und durch die neuesten Einträge ersetzt. Außerdem wird ein neuer Besuch registriert. Nachdem wir diese App Engine Memcache-Integration implementiert haben, können wir sie im nächsten Codelab (Modul 13) zu Cloud Memorystore migrieren.

Diese Anleitung umfasst die folgenden Schritte:

  1. Einrichtung/Vorbereitung
  2. Konfiguration aktualisieren
  3. Anwendungscode ändern

3. Einrichtung/Vorbereitung

Bevor wir zum Hauptteil des Tutorials kommen, richten wir unser Projekt ein, rufen den Code ab und stellen die Baseline-App bereit, damit wir wissen, dass wir mit funktionierendem Code begonnen haben.

1. Projekt einrichten

Wenn Sie das Codelab zu Modul 1 abgeschlossen haben, empfehlen wir, dasselbe Projekt (und denselben Code) wiederzuverwenden. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Prüfen Sie, ob das Projekt ein aktives Rechnungskonto hat und App Engine aktiviert ist.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen für dieses Codelab ist eine funktionierende Beispiel-App aus Modul 1. Wenn Sie keine haben, arbeiten Sie eines der beiden Tutorials (siehe Links oben) durch, bevor Sie hier fortfahren. Wenn Sie sich bereits mit den Inhalten vertraut gemacht haben, können Sie direkt mit dem Code für Modul 1 unten beginnen.

Unabhängig davon, ob Sie Ihren oder unseren Code verwenden, ist der Code aus Modul 1 der Ausgangspunkt. In diesem Codelab werden Sie durch jeden Schritt geführt. Am Ende erhalten Sie Code, der dem im Repo-Ordner für Modul 11 (FINISH) ähnelt.

Das Verzeichnis der START-Dateien für Modul 1 (Ihre oder unsere) sollte so aussehen:

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

3. Referenz-App (erneut) bereitstellen

Das sind die verbleibenden Schritte, die Sie jetzt ausführen müssen:

  1. gcloud-Befehlszeilentool
  2. Beispiel-App mit gcloud app deploy noch einmal bereitstellen
  3. Prüfen, ob die App problemlos in App Engine ausgeführt wird

Wenn Sie diese Schritte erfolgreich ausgeführt haben und Ihre Web-App funktioniert (mit einer Ausgabe, die der unten ähnelt), können Sie Ihrer App die Verwendung von Caching hinzufügen.

a7a9d2b80d706a2b.png

4. Konfiguration aktualisieren

An den Standardkonfigurationsdateien für App Engine (app.yaml, requirements.txt, appengine_config.py) sind keine Änderungen erforderlich.

5. Anwendungsdateien ändern

Da wir nur eine App Engine API hinzufügen, sind keine externen Pakete beteiligt. Das bedeutet, dass keine Konfigurationsdateien (app.yaml, requirements.txt, appengine_config.py) aktualisiert werden müssen. Es gibt nur eine Anwendungsdatei, main.py. Alle Änderungen in diesem Abschnitt wirken sich also nur auf diese Datei aus.

Importe

Der wichtigste Schritt ist das Importieren der Memcache-Bibliothek google.appengine.api.memcache. Da wir die letzten Besuche für eine Stunde im Cache speichern möchten, fügen wir auch eine Konstante für die Anzahl der Sekunden in einer Stunde hinzu. So sieht Ihr Code vor und nach dieser Änderung aus:

VORHER:

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

app = Flask(__name__)

DANACH:

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

app = Flask(__name__)
HOUR = 3600

Caching mit Memcache-Unterstützung hinzufügen

Die wichtigste Änderung ist die Verwendung von Caching in unserer Anwendung. Genauer gesagt sollten wir die letzten Besuche im Cache speichern, prüfen, ob Besuche im Cache verfügbar sind, und versuchen, die im Cache gespeicherten Ergebnisse so weit wie möglich zu verwenden. So geht die App vor, um unser Ziel zu erreichen:

  1. Lege den aktuellen Besuch fest und nenne ihn visitor.
  2. Versuche, die aktuelle visits aus dem Cache abzurufen
  3. Wenn der Cache leer ist oder sich der letzte Besucher (visits[0]['visitor']) vom aktuellen visitor unterscheidet, wird dieser letzte Besuch gespeichert, die letzten Besuche werden abgerufen und für eine Stunde im Cache gespeichert.
  4. visits über die Webvorlage für den Nutzer anzeigen

Hier sehen Sie die Änderungen im Vorher-Nachher-Vergleich:

VORHER:

@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)

DANACH:

@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)

Hier eine bildliche Darstellung der vorgenommenen Änderungen:

b1242503602f7bf0.png

Damit sind alle erforderlichen Änderungen abgeschlossen, um die Verwendung von App Engine memcache in die Beispiel-App aus Modul 1 aufzunehmen. Jetzt können wir die App erstellen und bereitstellen, um sie in Aktion zu sehen.

6. Zusammenfassung/Bereinigung

In diesem Abschnitt wird das Codelab abgeschlossen, indem die App bereitgestellt und geprüft wird, ob sie wie vorgesehen funktioniert und ob die Ausgabe korrekt ist. Führen Sie nach der App-Validierung alle erforderlichen Bereinigungsschritte aus und überlegen Sie sich, wie Sie weiter vorgehen möchten.

Anwendung bereitstellen und überprüfen

Stellen Sie die App mit gcloud app deploy noch einmal bereit und prüfen Sie, ob sie funktioniert. Ihr Code sollte jetzt mit dem Code im Ordner Modul 12 übereinstimmen. Die Ausgabe sollte mit der App aus Modul 1, die Sie zuvor bereitgestellt haben, identisch sein:

a7a9d2b80d706a2b.png

Wir haben lediglich die User Experience für denselben Nutzer beschleunigt. Wenn sie die Seite aktualisieren, sollten die Ergebnisse direkt aus dem Cache abgerufen werden. Dadurch wird weder ein neuer Besuch erstellt noch ein Datastore-Abruf ausgeführt.

Herzlichen Glückwunsch zum Abschluss des Codelabs für Modul 12, in dem wir unserer Beispielanwendung die Verwendung des App Engine-Dienstes memcache hinzugefügt haben. Im Bonusschritt haben Sie jetzt die Möglichkeit, diese Python 2-Anwendung zu Python 3 zu portieren.

Bereinigen

Allgemein

Wenn Sie die App vorerst nicht mehr benötigen, empfehlen wir Ihnen, sie zu deaktivieren, um Abrechnungen zu vermeiden. Wenn Sie jedoch weitere Tests durchführen möchten, bietet die App Engine-Plattform ein kostenloses Kontingent. Solange Sie diese Nutzungsebene nicht überschreiten, werden Ihnen keine Gebühren berechnet. Das gilt für die Rechenleistung. Es können aber auch Gebühren für relevante App Engine-Dienste anfallen. Weitere Informationen finden Sie auf der Preisseite. Wenn bei dieser Migration andere Cloud-Dienste beteiligt sind, werden diese separat abgerechnet. Sehen Sie sich in beiden Fällen gegebenenfalls den Abschnitt „Spezifisch für dieses Codelab“ unten an.

Die Bereitstellung auf einer serverlosen Google Cloud-Compute-Plattform wie App Engine verursacht geringe Build- und Speicherkosten. Cloud Build und Cloud Storage haben jeweils ein eigenes kostenloses Kontingent. Das Speichern dieses Bildes verbraucht einen Teil dieses Kontingents. Möglicherweise leben Sie jedoch in einer Region, in der es kein solches kostenloses Kontingent gibt. Achten Sie daher auf Ihre Speichernutzung, um potenzielle Kosten zu minimieren. Folgende Cloud Storage-„Ordner“ sollten Sie sich ansehen:

  • 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
  • Die oben genannten Speicherlinks hängen von Ihrem PROJECT_ID und *LOC*ab, z. B. „us“, wenn Ihre App in den USA gehostet wird.

Wenn Sie diese Anwendung oder andere zugehörige Migrations-Codelabs nicht weiter verwenden und alles vollständig löschen möchten, beenden Sie Ihr Projekt.

Spezifisch für dieses Codelab

Die unten aufgeführten Dienste sind nur für dieses Codelab verfügbar. Weitere Informationen finden Sie in der Dokumentation der einzelnen Produkte:

  • Der App Engine Memcache-Dienst ist in zwei verschiedenen Varianten verfügbar, die jeweils eine eigene Preisstruktur haben. Sie müssen die Nutzung also im Hinblick auf die Abrechnung im Blick behalten.
  • Der Dienst App Engine Datastore wird von Cloud Datastore (Cloud Firestore im Datastore-Modus) bereitgestellt, das ebenfalls eine kostenlose Stufe bietet. Weitere Informationen finden Sie auf der Preisseite.

Nächste Schritte

Die nächste logische Migration wird in Modul 13 behandelt. Dort wird Entwicklern gezeigt, wie sie vom App Engine-Dienst memcache zu Cloud Memorystore migrieren. Diese Migrationen sind alle optional und für Nutzer verfügbar, die ihre Anwendungen modernisieren möchten. Der Cloud Memorystore-Dienst ist aus vielen Gründen eine erhebliche Verbesserung gegenüber dem memcache von App Engine:

  • Cloud Memorystore ist nicht serverlos. Das bedeutet, dass Sie einen Server für den Cache zuweisen müssen. Cloud Memorystore bietet keine kostenlose Stufe. Beide Faktoren können sich erheblich auf die Kosten auswirken.
  • Cloud Memorystore unterstützt zwei verschiedene zugrunde liegende Speichermechanismen (Caching-Engines): Redis und Memcached.
  • Cloud Memorystore (für Redis) bietet einen viel umfangreicheren und detaillierteren Funktionsumfang als App Engine Memcache.
  • Wenn Sie Cloud Memorystore verwenden möchten, müssen Sie einen Cloud Memorystore-Server einrichten, ihn einem Google Cloud-VPC-Netzwerk hinzufügen und dann Ihre App Engine-Anwendung dieses Netzwerk zur Kommunikation mit Ihrem Memorystore-Server verwenden lassen.

Wenn Sie nicht alle Funktionen von Cloud Memorystore benötigen oder sich Sorgen über die Auswirkungen auf die Kosten machen, können Sie App Engine Memcache weiterhin verwenden.

Über Modul 13 hinaus gibt es eine Vielzahl weiterer möglicher Migrationen, z. B. Cloud NDB und Cloud Datastore oder Cloud Tasks. Es gibt auch produktübergreifende Migrationen zu Cloud Run und Cloud Functions. Sie finden sie alle im Migrations-Repository.

Ein weiterer möglicher nächster Schritt ist die Portierung zu Python 3, die im nächsten Abschnitt als optionaler Schritt behandelt wird.

7. BONUS: Migration zu Python 3

Übersicht

Dieser Abschnitt enthält optionalen Bonusinhalt zur Migration der Anwendung aus Modul 12, die wir oben behandelt haben, zu Python 3. Wir beginnen mit der Konfiguration und fahren dann mit der Anwendung fort.

app.yaml vereinfachen

Einer der Vorteile der Python 3-Laufzeit ist, dass die app.yaml deutlich vereinfacht werden kann.

VORHER:

Das ist der Inhalt von app.yaml am Ende von Modul 12:

runtime: python27
threadsafe: yes
api_version: 1

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

Da die Python 3-Laufzeit erfordert, dass Web-Frameworks ihr eigenes Routing durchführen, müssen alle Routenhandler in app.yaml in auto geändert werden. Wenn keine statischen Dateien bereitgestellt werden, können Nutzer den gesamten handlers:-Abschnitt einfach entfernen. Außerdem wurden sowohl threadsafe als auch api_version verworfen.

DANACH:

Mit den gerade beschriebenen erforderlichen Änderungen ist dies der Ersatz für app.yaml für Python 3:

runtime: python39
app_engine_apis: true

Nur für die Zeile app_engine_apis: true ist eine Erklärung erforderlich. Als die Legacy-App Engine-Dienste 2021 für Laufzeiten der zweiten Generation verfügbar wurden, war für einige Laufzeiten, darunter Python 3, zusätzliches Bootstrapping erforderlich, um auf diese APIs wie ndb, taskqueue und memcache zuzugreifen. Diese Zeile in der Konfiguration dient diesem Zweck.

requirements.txt aktualisieren

In requirements.txt ist ein weiteres Bootstrapping der ursprünglichen APIs erforderlich: Der Zugriff auf das neue App Engine SDK muss enthalten sein.

VORHER:

Das ist der Inhalt von app.yaml am Ende von Modul 12:

flask

DANACH:

Fügen Sie einfach das App Engine Python SDK hinzu. Sie sollten dann Folgendes haben:

flask
appengine-python-standard

appengine_config.py und lib löschen

Bei App Engine-Laufzeiten der nächsten Generation wird die Verwendung von Drittanbieterpaketen überarbeitet:

  • Integrierte Bibliotheken sind Bibliotheken, die von Google geprüft und auf App Engine-Servern verfügbar gemacht wurden, wahrscheinlich weil sie C/C++-Code enthalten, den Entwickler nicht in der Cloud bereitstellen dürfen. Diese Bibliotheken sind in den Laufzeitumgebungen der 2. Generation nicht mehr verfügbar.
  • Das Kopieren von nicht integrierten Bibliotheken (manchmal auch als „Vendoring“ oder „Self-Bundling“ bezeichnet) ist in Laufzeiten der 2. Generation nicht mehr erforderlich. Stattdessen sollten sie in requirements.txt aufgeführt werden, wo das Build-System sie bei der Bereitstellung automatisch für Sie installiert.

Aufgrund dieser Änderungen an der Verwaltung von Drittanbieterpaketen sind weder die Datei appengine_config.py noch der Ordner lib erforderlich. Löschen Sie sie daher. In Laufzeiten der zweiten Generation installiert App Engine automatisch Drittanbieterpakete, die in requirements.txt aufgeführt sind. Zusammenfassen:

  1. Keine selbst gebündelten oder kopierten Bibliotheken von Drittanbietern; listen Sie sie in requirements.txt auf.
  2. Kein pip install in einem lib-Ordner, d. h. kein lib-Ordnerzeitraum
  3. Keine integrierten Drittanbieterbibliotheken in app.yaml (daher kein libraries-Abschnitt); Liste in requirements.txt
  4. Wenn Sie keine Drittanbieterbibliotheken in Ihrer App referenzieren, benötigen Sie keine appengine_config.py-Datei.

Die einzige Anforderung für Entwickler besteht darin, alle gewünschten Drittanbieterbibliotheken in requirements.txt aufzulisten.

Anwendung zur Verwendung des App Engine SDK aktualisieren

Wie oben erwähnt, sind für Python 3-Anwendungen einige Änderungen erforderlich, um auf gebündelte App Engine-Dienste zuzugreifen:

  1. App Engine SDK bündeln (in requirements.txt)
  2. App Engine SDK aktivieren (in app.yaml)
  3. WSGI-Objekt umschließen (in main.py)

Das erste Paar wurde oben abgeschlossen. Die letzte Anforderung besteht also darin, main.py zu aktualisieren.

VORHER:

Unten sehen Sie die Python 2-Version von main.py am Ende von Modul 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

DANACH:

Importieren Sie für den Python 3-Port das SDK und umschließen Sie das Flask-App-Objekt damit (dem SDK-Wrapper). Das Ergebnis sieht so aus:

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

Entwickler müssen diese Änderungen an ihren Python-Apps vornehmen, wenn sie von 2.x zu 3.x portieren, um auf die gebündelten Dienste zuzugreifen. Wenn Sie Flask nicht verwenden, finden Sie in der Dokumentation auch Django- und Pyramid-Beispiele. Wenn Ihr Python 2-Code keine Webanwendung ist, sollte es beim Portieren zu Python 3 ausreichen, das SDK-Paket einzufügen. Unser Anwendungscode wurde ursprünglich für Python 2 und 3 entwickelt, sodass keine zusätzlichen Kompatibilitätsänderungen erforderlich sind.

Anwendung bereitstellen

Nachdem Sie die oben genannten Änderungen vorgenommen haben, können Sie die aktualisierte Beispiel-App bereitstellen. (Es gibt kein Problem, wenn Sie eine Python 3-Version Ihrer App in demselben GCP-Projekt über einer ursprünglichen Python 2-Version bereitstellen.) Das Verhalten der App sollte gleich bleiben. Wenn Sie Ihre aktualisierte App mit unserer vergleichen möchten, sehen Sie sich den Ordner „Module 12b“ im Migrations-Repository an. Weitere Informationen zur Unterstützung gebündelter App Engine-Dienste in den neuesten Laufzeiten wie Python 3 finden Sie in der Ankündigung der Einführung der Funktion sowie im Codelab zu Modul 17.

Herzlichen Glückwunsch zum Abschluss des Bonusschritts in Modul 12! Weitere Informationen zum Vorbereiten von Konfigurationsdateien für die Python 3-Laufzeit Im Abschnitt „Zusammenfassung/Bereinigung“ oben finden Sie Informationen zu den nächsten Schritten und zur Bereinigung.

8. Zusätzliche Ressourcen

Unten finden Sie weitere Ressourcen für Entwickler, die sich näher mit diesem oder einem ähnlichen Migrationsmodul sowie mit zugehörigen Produkten befassen möchten. Dazu gehören Orte, an denen Sie Feedback zu diesen Inhalten geben können, Links zum Code und verschiedene Dokumentationen, die für Sie nützlich sein könnten.

Probleme mit Codelabs/Feedback

Wenn Sie Probleme mit diesem Codelab feststellen, suchen Sie bitte zuerst nach Ihrem Problem, bevor Sie es melden. Links zum Suchen und Erstellen neuer Probleme:

Migrationsressourcen

Links zu den Repository-Ordnern für Modul 2 (START) und Modul 12 (FINISH) finden Sie in der Tabelle unten. Sie können auch über das Repository für alle App Engine-Codelab-Migrationen auf sie zugreifen. Sie können es klonen oder eine ZIP-Datei herunterladen.

Codelab

Python 2

Python 3

Modul 1

code

Code (nicht in diesem Tutorial enthalten)

Modul 12 (dieses Codelab)

code

code

Online-Referenzen

Unten finden Sie Online-Ressourcen, die für diese Anleitung relevant sein könnten:

App Engine

Cloud Memorystore und Cloud Datastore

Andere Cloud-Informationen

Videos

Lizenz

Dieser Text ist mit einer Creative Commons Attribution 2.0 Generic License lizenziert.