Von App Engine Memcache zu Cloud Memorystore migrieren (Modul 13)

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 wird Python 2-App Engine-Entwicklern gezeigt, wie sie von App Engine Memcache zu Cloud Memorystore (für Redis) migrieren. Es gibt auch eine implizite Migration von App Engine ndb zu Cloud NDB. Diese wird jedoch hauptsächlich im Codelab zu Modul 2 behandelt. Dort finden Sie weitere Schritt-für-Schritt-Informationen.

Lerninhalte

  • Cloud Memorystore-Instanz einrichten (über die Cloud Console oder das gcloud-Tool)
  • Connector für serverlosen VPC-Zugriff einrichten (über die Cloud Console oder das gcloud-Tool)
  • Von App Engine Memcache zu Cloud Memorystore migrieren
  • Caching mit Cloud Memorystore in einer Beispielanwendung implementieren
  • Von App Engine ndb zu Cloud NDB migrieren

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

In diesem Codelab wird gezeigt, wie Sie eine Beispielanwendung von App Engine Memcache (und NDB) zu Cloud Memorystore (und Cloud NDB) migrieren. Bei diesem Prozess werden Abhängigkeiten von gebündelten App Engine-Diensten ersetzt, wodurch Ihre Apps portierbarer werden. Sie können entweder weiterhin App Engine verwenden oder zu einer der zuvor beschriebenen Alternativen wechseln.

Diese Migration erfordert mehr Aufwand als die anderen in dieser Reihe. Der empfohlene Ersatz für App Engine Memcache ist Cloud Memorystore, ein vollständig verwalteter cloudbasierter Caching-Dienst. Memorystore unterstützt zwei beliebte Open-Source-Caching-Engines: Redis und Memcached. In diesem Migrationsmodul wird Cloud Memorystore for Redis verwendet. Weitere Informationen finden Sie in der Übersicht über Memorystore und Redis.

Da für Memorystore ein laufender Server erforderlich ist, ist auch Cloud VPC erforderlich. Insbesondere muss ein Connector für serverlosen VPC-Zugriff erstellt werden, damit die App Engine-Anwendung über die private IP-Adresse eine Verbindung zur Memorystore-Instanz herstellen kann. Nach Abschluss dieser Übung haben Sie die App so aktualisiert, dass sie sich wie zuvor verhält, aber Cloud Memorystore als Caching-Dienst verwendet wird und den Memcache-Dienst von App Engine ersetzt.

In dieser Anleitung wird zuerst die Beispiel-App aus Modul 12 in Python 2 verwendet. Anschließend wird ein optionales, kleines Upgrade auf Python 3 durchgeführt. Wenn Sie bereits mit dem Zugriff auf gebündelte App Engine-Dienste über Python 3 über das Python 3 App Engine SDK vertraut sind, können Sie stattdessen mit der Python 3-Version der Beispielanwendung aus Modul 12 beginnen. Dazu müssen Sie die Verwendung des SDK entfernen, da Memorystore kein gebündelter App Engine-Dienst ist. Die Verwendung des Python 3 App Engine SDK wird in dieser Anleitung nicht behandelt.

Diese Anleitung umfasst die folgenden wichtigen Schritte:

  1. Einrichtung/Vorbereitung
  2. Caching-Dienste einrichten
  3. Konfigurationsdateien aktualisieren
  4. Hauptanwendung aktualisieren

3. Einrichtung/Vorbereitung

Cloud-Projekt vorbereiten

Wir empfehlen, dass Sie dasselbe Projekt wie für das Codelab zu Modul 12 verwenden. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Jedes Codelab in dieser Reihe hat einen „START“ (der Baseline-Code, von dem aus Sie beginnen) und einen „FINISH“ (die migrierte App). Der FINISH-Code wird bereitgestellt, damit Sie Ihre Lösungen mit unseren vergleichen können, falls Probleme auftreten. Sie können jederzeit zu START zurückkehren, wenn etwas schiefgeht. Diese Kontrollpunkte sollen Ihnen helfen, die Migrationen erfolgreich durchzuführen.

Unabhängig davon, welches Cloud-Projekt Sie verwenden, muss es ein aktives Rechnungskonto haben. Prüfen Sie außerdem, ob App Engine aktiviert ist. Sehen Sie sich die allgemeinen Kostenfolgen dieser Anleitungen an und vergewissern Sie sich, dass Sie sie verstanden haben. Im Gegensatz zu anderen Codelabs in dieser Reihe werden in diesem Codelab jedoch Cloud-Ressourcen verwendet, für die es kein kostenloses Kontingent gibt. Für die Durchführung der Übung fallen daher Kosten an. Zusammen mit den Empfehlungen zur Reduzierung der Nutzung werden genauere Kosteninformationen bereitgestellt. Am Ende finden Sie eine Anleitung zum Freigeben von Ressourcen, um die Abrechnungskosten zu minimieren.

Beispiel-App für die Baseline abrufen

In diesem Codelab wird die Migration Schritt für Schritt anhand des Baseline-Codes aus Modul 12 erläutert. Wenn Sie fertig sind, haben Sie eine funktionierende App für Modul 13, die dem Code in einem der FINISH-Ordner sehr ähnlich ist. Hier sind die entsprechenden Ressourcen:

Der Ordner „START“ sollte die folgenden Dateien enthalten:

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

Wenn Sie mit der Python 2-Version beginnen, gibt es auch eine appengine_config.py-Datei und möglicherweise einen lib-Ordner, wenn Sie das Codelab für Modul 12 abgeschlossen haben.

Modul 12-App (erneut) bereitstellen

Ihre verbleibenden Vorbereitungsaufgaben:

  1. Machen Sie sich bei Bedarf noch einmal mit dem gcloud-Befehlszeilentool vertraut.
  2. Modul 12-Code in App Engine (neu) bereitstellen (falls erforderlich)

Nutzer von Python 2 sollten den Ordner lib mit diesen Befehlen löschen und neu installieren:

rm -rf ./lib; pip install -t lib -r requirements.txt

Jetzt sollten alle (Python 2- und Python 3-Nutzer) den Code mit diesem Befehl in App Engine hochladen:

gcloud app deploy

Wenn die Bereitstellung erfolgreich war, prüfen Sie, ob die App genauso aussieht und funktioniert wie die App in Modul 12, eine Web-App, die Besuche erfasst und für denselben Nutzer eine Stunde lang im Cache speichert:

dfe56a02ae59ddd8.png

Da die letzten Besuche im Cache gespeichert werden, sollten Seitenaktualisierungen relativ schnell geladen werden.

4. Caching-Dienste einrichten

Cloud Memorystore ist nicht serverlos. Eine Instanz ist erforderlich, in diesem Fall eine laufende Redis-Instanz. Im Gegensatz zu Memcache ist Memorystore ein eigenständiges Cloud-Produkt und hat keine kostenlose Stufe. Sehen Sie sich daher vor dem Fortfahren die Preisinformationen zu Memorystore for Redis an. Um die Kosten für diese Übung zu minimieren, empfehlen wir die geringste Menge an Ressourcen, die für den Betrieb erforderlich ist: ein Basic-Dienst und eine Kapazität von 1 GB.

Die Memorystore-Instanz befindet sich in einem anderen Netzwerk als Ihre App Engine-Anwendung (Instanzen). Daher muss ein Connector für serverlosen VPC-Zugriff erstellt werden, damit App Engine auf Ihre Memorystore-Ressourcen zugreifen kann. Um die VPC-Kosten zu minimieren, sollten Sie den Instanztyp (f1-micro) und die geringste Anzahl von Instanzen auswählen (wir empfehlen mindestens 2 und maximal 3). Sehen Sie sich auch die Seite mit den VPC-Preisinformationen an.

Wir wiederholen diese Empfehlungen zur Kostensenkung, wenn wir Sie durch die Erstellung der einzelnen erforderlichen Ressourcen führen. Wenn Sie Memorystore- und VPC-Ressourcen in der Cloud Console erstellen, wird außerdem rechts oben der Preisrechner für jedes Produkt angezeigt. So erhalten Sie eine Schätzung der monatlichen Kosten (siehe Abbildung unten). Diese Werte werden automatisch angepasst, wenn Sie Ihre Optionen ändern. So sollte es in etwa aussehen:

7eb35ebf7248c010.png

Beide Ressourcen sind erforderlich. Es spielt keine Rolle, welche Sie zuerst erstellen. Wenn Sie die Memorystore-Instanz zuerst erstellen, kann Ihre App Engine-Anwendung sie ohne den VPC-Connector nicht erreichen. Wenn Sie den VPC-Connector zuerst erstellen, gibt es in diesem VPC-Netzwerk nichts, womit Ihre App Engine-Anwendung kommunizieren kann. In dieser Anleitung erstellen Sie zuerst die Memorystore-Instanz und dann den VPC-Connector.

Sobald beide Ressourcen online sind, fügen Sie die relevanten Informationen zu app.yaml hinzu, damit Ihre App auf den Cache zugreifen kann. Sie können auch die Anleitungen zu Python 2 oder Python 3 in der offiziellen Dokumentation aufrufen. Es empfiehlt sich auch, den Leitfaden zum Zwischenspeichern von Daten auf der Cloud NDB-Migrationsseite ( Python 2 oder Python 3) zu lesen.

Cloud Memorystore-Instanz erstellen

Da Cloud Memorystore keine kostenlose Stufe hat, empfehlen wir, für das Codelab die geringste Menge an Ressourcen zuzuweisen. Mit den folgenden Einstellungen können Sie die Kosten niedrig halten:

  • Wählen Sie die niedrigste Dienststufe aus: Basic (Konsolenstandard: „Standard“, gcloud-Standard: „Basic“).
  • Wählen Sie die geringste Menge an Speicherplatz aus: 1 GB (Konsolenstandard: 16 GB, gcloud-Standard: 1 GB).
  • In der Regel benötigen die neuesten Versionen jeder Software die meisten Ressourcen. Die älteste Version auszuwählen ist aber wahrscheinlich auch nicht empfehlenswert. Die zweitneueste Version ist derzeit Redis-Version 5.0 (Konsolenstandard: 6.x).

Im nächsten Abschnitt wird beschrieben, wie Sie die Instanz in der Cloud Console erstellen. Wenn Sie das lieber über die Befehlszeile erledigen möchten, können Sie diesen Abschnitt überspringen.

Über die Cloud Console

Rufen Sie in der Cloud Console die Seite „Cloud Memorystore“ auf. Möglicherweise werden Sie aufgefordert, Abrechnungsinformationen anzugeben. Wenn Sie Memorystore noch nicht aktiviert haben, werden Sie dazu aufgefordert:

68318997e3105db6.png

Nachdem Sie die Funktion aktiviert haben (möglicherweise zusammen mit der Abrechnung), gelangen Sie zum Memorystore-Dashboard. Hier sehen Sie alle Instanzen, die in Ihrem Projekt erstellt wurden. Das unten gezeigte Projekt enthält keine. Daher wird „Keine Zeilen zum Anzeigen“ angezeigt. Klicken Sie oben auf Instanz erstellen, um eine Memorystore-Instanz zu erstellen:

63547aa575838a36.png

Auf dieser Seite finden Sie ein Formular, in das Sie die gewünschten Einstellungen eingeben können, um die Memorystore-Instanz zu erstellen:

b77d927287fdf4c7.png

Um die Kosten für diese Anleitung und die zugehörige Beispiel-App niedrig zu halten, sollten Sie die oben genannten Empfehlungen befolgen. Nachdem Sie Ihre Auswahl getroffen haben, klicken Sie auf Erstellen. Das Erstellen dauert einige Minuten. Wenn der Vorgang abgeschlossen ist, kopieren Sie die IP-Adresse und Portnummer der Instanz, um sie app.yaml hinzuzufügen.

Über die Befehlszeile

Es ist zwar visuell informativ, Memorystore-Instanzen über die Cloud Console zu erstellen, aber einige Nutzer bevorzugen die Befehlszeile. Achten Sie darauf, dass gcloud installiert und initialisiert ist, bevor Sie fortfahren.

Wie bei der Cloud Console muss Cloud Memorystore for Redis aktiviert sein. Geben Sie den Befehl gcloud services enable redis.googleapis.com ein und warten Sie, bis er abgeschlossen ist. Beispiel:

$ gcloud services enable redis.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Wenn der Dienst bereits aktiviert wurde, hat die (erneute) Ausführung des Befehls keine (negativen) Nebenwirkungen. Nachdem der Dienst aktiviert wurde, erstellen wir eine Memorystore-Instanz. Der Befehl sieht so aus:

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

Wählen Sie einen Namen für Ihre Memorystore-Instanz aus. In diesem Lab wird „demo-ms“ als Name und „my-project“ als Projekt-ID verwendet. Die Region dieser Beispiel-App ist us-central1 (identisch mit us-central). Sie können jedoch eine Region verwenden, die näher an Ihrem Standort liegt, wenn die Latenz ein Problem darstellt. Sie müssen dieselbe Region wie für Ihre App Engine-Anwendung auswählen. Sie können eine beliebige Redis-Version auswählen, aber wir verwenden Version 5, wie zuvor empfohlen. Bei diesen Einstellungen sieht der Befehl (mit zugehöriger Ausgabe) so aus:

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

Im Gegensatz zu den Cloud Console-Standardeinstellungen werden für gcloud standardmäßig minimale Ressourcen verwendet. Daher waren weder das Service-Tier noch die Menge des Speichers in diesem Befehl erforderlich. Das Erstellen einer Memorystore-Instanz dauert einige Minuten. Wenn der Vorgang abgeschlossen ist, notieren Sie sich die IP-Adresse und die Portnummer der Instanz, da sie bald zu app.yaml hinzugefügt werden.

Erstellung der Instanz bestätigen

Über die Cloud Console oder die Befehlszeile

Unabhängig davon, ob Sie Ihre Instanz über die Cloud Console oder die Befehlszeile erstellt haben, können Sie mit dem folgenden Befehl bestätigen, dass sie verfügbar und einsatzbereit ist: gcloud redis instances list --region REGION

Hier ist der Befehl zum Prüfen von Instanzen in der Region us-central1 zusammen mit der erwarteten Ausgabe, die die gerade erstellte Instanz zeigt:

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

Wenn Sie nach den Instanzinformationen gefragt werden oder Ihre App konfigurieren müssen, verwenden Sie HOST und PORT (nicht RESERVED_IP). Das Cloud Memorystore-Dashboard in der Cloud Console sollte jetzt diese Instanz anzeigen:

c5a6948ec1c056ed.png

Über eine Compute Engine-VM

Wenn Sie eine Compute Engine-VM haben, können Sie auch direkte Befehle von einer VM an Ihre Memorystore-Instanz senden, um zu bestätigen, dass sie funktioniert. Die Verwendung einer VM kann mit Kosten verbunden sein, die unabhängig von den Ressourcen anfallen, die Sie bereits verwenden.

Connector für serverlosen VPC-Zugriff erstellen

Wie bei Cloud Memorystore können Sie den serverlosen Cloud VPC-Connector in der Cloud Console oder über die Befehlszeile erstellen. Cloud VPC hat ebenfalls kein kostenloses Kontingent. Wir empfehlen daher, die geringste Menge an Ressourcen zuzuweisen, die für die Durchführung des Codelabs erforderlich ist, um die Kosten so gering wie möglich zu halten. Das ist mit den folgenden Einstellungen möglich:

  • Wählen Sie die niedrigste maximale Anzahl von Instanzen aus: 3 (Konsole & gcloud-Standard: 10)
  • Wählen Sie den kostengünstigsten Maschinentyp aus: f1-micro (Konsolenstandard: e2-micro, kein gcloud-Standard)

Im nächsten Abschnitt erfahren Sie, wie Sie den Connector über die Cloud Console mit den oben genannten Cloud VPC-Einstellungen erstellen. Wenn Sie die Einrichtung lieber über die Befehlszeile vornehmen möchten, fahren Sie mit dem nächsten Abschnitt fort.

Über die Cloud Console

Rufen Sie in der Cloud Console die Seite Cloud Networking "Serverless VPC Access" auf. Möglicherweise werden Sie aufgefordert, Abrechnungsinformationen anzugeben. Wenn Sie die API noch nicht aktiviert haben, werden Sie dazu aufgefordert:

e3b9c0651de25e97.png

Nachdem Sie die API (und möglicherweise die Abrechnung) aktiviert haben, gelangen Sie zum Dashboard, auf dem alle erstellten VPC-Connectors angezeigt werden. Das im Screenshot unten verwendete Projekt enthält keine. Daher wird die Meldung „Keine Zeilen zum Anzeigen“ angezeigt. Klicken Sie oben in der Console auf Connector erstellen:

b74b49b9d73b7dcf.png

Füllen Sie das Formular mit den gewünschten Einstellungen aus:

6b26b2aafa719f73.png

Wählen Sie die entsprechenden Einstellungen für Ihre eigenen Anwendungen aus. Für dieses Tutorial und die zugehörige Beispiel-App mit minimalen Anforderungen ist es sinnvoll, die Kosten zu minimieren. Folgen Sie daher den Empfehlungen, die wir bereits besprochen haben. Wenn Sie Ihre Auswahl getroffen haben, klicken Sie auf Erstellen. Die Anforderung eines VPC-Connectors dauert einige Minuten.

Über die Befehlszeile

Bevor Sie einen VPC-Connector erstellen, müssen Sie zuerst die Serverless VPC Access API aktivieren. Nach der Ausführung des folgenden Befehls sollte eine ähnliche Ausgabe angezeigt werden:

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Wenn die API aktiviert ist, wird ein VPC-Connector mit einem Befehl wie dem folgenden erstellt:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

Wählen Sie einen Namen für den Connector sowie eine nicht verwendete Start-IP-Adresse für den CIDR-Block /28 aus. In dieser Anleitung wird von folgenden Annahmen ausgegangen:

  • Project ID: my-project
  • Name des VPC-Connectors: demo-vpc
  • Mindestanzahl von Instanzen: 2 (Standard) und maximale Anzahl von Instanzen: 3
  • Instanztyp: f1-micro
  • Region: us-central1
  • IPv4-CIDR-Block: 10.8.0.0/28 (wie in der Cloud Console empfohlen)

Wenn Sie den folgenden Befehl unter den oben genannten Annahmen ausführen, sollte die Ausgabe in etwa so aussehen:

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

Im obigen Befehl werden keine Standardwerte angegeben, z. B. die Mindestanzahl von Instanzen (2) und ein Netzwerk namens default. Das Erstellen eines VPC-Connectors dauert einige Minuten.

Erstellung des Connectors bestätigen

Wenn der Vorgang abgeschlossen ist, führen Sie den folgenden gcloud-Befehl aus (vorausgesetzt, es handelt sich um die Region us-central1), um zu bestätigen, dass er erstellt wurde und einsatzbereit ist:

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

Entsprechend sollte im Dashboard jetzt der Connector angezeigt werden, den Sie gerade erstellt haben:

e03db2c8140ed014.png

Notieren Sie sich die Cloud-Projekt-ID, den Namen des VPC-Connectors und die Region.

Nachdem Sie die erforderlichen zusätzlichen Cloud-Ressourcen über die Befehlszeile oder in der Console erstellt haben, müssen Sie die Anwendungskonfiguration aktualisieren, um ihre Verwendung zu unterstützen.

5. Konfigurationsdateien aktualisieren

Als Erstes müssen Sie alle erforderlichen Änderungen an den Konfigurationsdateien vornehmen. Das Hauptziel dieses Codelabs ist es, Python 2-Nutzern bei der Migration zu helfen. In den einzelnen Abschnitten unten finden Sie jedoch in der Regel auch Informationen zur weiteren Portierung zu Python 3.

requirements.txt

In diesem Abschnitt fügen wir Pakete hinzu, um Cloud Memorystore und Cloud NDB zu unterstützen. Für Cloud Memorystore for Redis reicht es aus, den Standard-Redis-Client für Python (redis) zu verwenden, da es keine eigene Cloud Memorystore-Clientbibliothek gibt. Hängen Sie sowohl redis als auch google-cloud-ndb an requirements.txt an und verwenden Sie dabei flask aus Modul 12:

flask
redis
google-cloud-ndb

Diese requirements.txt-Datei enthält keine Versionsnummern. Daher sind die neuesten Versionen ausgewählt. Wenn Inkompatibilitäten auftreten, geben Sie Versionsnummern an, um funktionierende Versionen zu verwenden.

app.yaml

Neue Abschnitte hinzufügen

Für die Python 2-Laufzeit von App Engine sind bestimmte Drittanbieterpakete erforderlich, wenn Cloud-APIs wie Cloud NDB verwendet werden, nämlich grpcio und setuptools. Python 2-Nutzer müssen integrierte Bibliotheken wie diese zusammen mit einer verfügbaren Version in app.yaml auflisten. Wenn Sie noch keinen libraries-Abschnitt haben, erstellen Sie einen und fügen Sie beide Bibliotheken wie folgt hinzu:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

Wenn Sie Ihre App migrieren, hat sie möglicherweise bereits einen libraries-Abschnitt. Wenn das der Fall ist und entweder grpcio oder setuptools fehlt, fügen Sie sie einfach dem vorhandenen libraries-Abschnitt hinzu.

Als Nächstes benötigt unsere Beispielanwendung die Informationen zur Cloud Memorystore-Instanz und zum VPC-Connector. Fügen Sie daher die folgenden beiden neuen Abschnitte zu app.yaml hinzu, unabhängig davon, welche Python-Laufzeit Sie verwenden:

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Das war es mit den erforderlichen Aktualisierungen. Die aktualisierte app.yaml sollte nun so aussehen:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Unten sehen Sie einen Vorher-Nachher-Vergleich, der die Änderungen veranschaulicht, die Sie an app.yaml vornehmen sollten:

ec2bb027a67debb6.png

*Unterschiede bei Python 3

Dieser Abschnitt ist optional und nur relevant, wenn Sie zu Python 3 migrieren. Dazu müssen Sie einige Änderungen an Ihrer Python 2-Konfiguration vornehmen. Überspringen Sie diesen Abschnitt, wenn Sie derzeit kein Upgrade durchführen.

Weder threadsafe noch api_version werden für die Python 3-Laufzeit verwendet. Löschen Sie daher beide Einstellungen. Die aktuelle App Engine-Laufzeit unterstützt weder integrierte Drittanbieterbibliotheken noch das Kopieren von nicht integrierten Bibliotheken. Die einzige Anforderung für Drittanbieterpakete ist, dass sie in requirements.txt aufgeführt werden. Daher kann der gesamte Abschnitt libraries von app.yaml gelöscht werden.

Als Nächstes ist in der Python 3-Laufzeit die Verwendung von Web-Frameworks erforderlich, die ihr eigenes Routing durchführen. Daher haben wir Entwicklern in Modul 1 gezeigt, wie sie von webp2 zu Flask migrieren. Daher müssen alle Skript-Handler in auto geändert werden. Da diese App keine statischen Dateien bereitstellt, ist es „sinnlos“, Handler aufzulisten (da sie alle auto sind). Daher kann auch der gesamte handlers-Abschnitt entfernt werden. Daher sollte Ihr neuer, für Python 3 optimierter, abgekürzter app.yaml so aussehen:

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Zusammenfassung der Unterschiede in app.yaml bei der Portierung zu Python 3:

  • Einstellungen für threadsafe und api_version löschen
  • Abschnitt „libraries“ löschen
  • Löschen Sie den Abschnitt handlers (oder nur script-Handler, wenn Ihre App statische Dateien bereitstellt).

Werte ersetzen

Die Werte in den neuen Abschnitten für Memorystore und den VPC-Connector sind nur Platzhalter. Ersetzen Sie diese Werte in Großbuchstaben (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) durch die Werte, die Sie beim Erstellen dieser Ressourcen gespeichert haben. Verwenden Sie für Ihre Memorystore-Instanz HOST (nicht RESERVED_IP) und PORT. Hier ist eine schnelle Befehlszeilenmethode zum Abrufen von HOST und PORT, wobei der Instanzname demo-ms und der REGION us-central1 ist:

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

Wenn die IP-Adresse unserer Beispiel-Redis-Instanz 10.10.10.10 mit Port 6379 in unserem Projekt my-project in der Region us-central1 mit dem VPC-Connector-Namen demo-vpc war, sehen diese Abschnitte in app.yaml so aus:

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

appengine_config.py erstellen oder aktualisieren

Unterstützung für integrierte Drittanbieterbibliotheken hinzufügen

Fügen Sie die Verwendung der Bibliotheken grpcio und setuptools hinzu, wie Sie es zuvor mit app.yaml getan haben. Ändern Sie appengine_config.py, um integrierte Bibliotheken von Drittanbietern zu unterstützen. Wenn Ihnen das bekannt vorkommt, liegt das daran, dass dies auch in Modul 2 bei der Migration von App Engine ndb zu Cloud NDB erforderlich war. Die erforderliche Änderung besteht darin, den Ordner lib dem Arbeitsset setuptools.pkg_resources hinzuzufügen:

4140b3800694f77e.png

*Unterschiede bei Python 3

Dieser Abschnitt ist optional und nur relevant, wenn Sie zu Python 3 migrieren. Eine der willkommenen Änderungen in App Engine der zweiten Generation ist, dass das Kopieren (manchmal auch als „Vendoring“ bezeichnet) von (nicht integrierten) Drittanbieterpaketen und das Verweisen auf integrierte Drittanbieterpakete in app.yaml nicht mehr erforderlich ist. Das bedeutet, dass Sie die gesamte Datei appengine_config.py löschen können.

6. Anwendungsdateien aktualisieren

Es gibt nur eine Anwendungsdatei, main.py. Alle Änderungen in diesem Abschnitt wirken sich also nur auf diese Datei aus. Wir haben eine bildliche Darstellung der Änderungen bereitgestellt, die wir vornehmen werden, um diese Anwendung zu Cloud Memorystore zu migrieren. Es dient nur zur Veranschaulichung und ist nicht dazu gedacht, dass Sie es genau analysieren. Die eigentliche Arbeit besteht in den Änderungen, die wir am Code vornehmen.

5d043768ba7be742.png

Sehen wir uns die einzelnen Abschnitte an, beginnend mit dem oberen.

Importe aktualisieren

Im Importabschnitt in main.py für Modul 12 werden Cloud NDB und Cloud Tasks verwendet. Hier sind die entsprechenden Importe:

VORHER:

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

Für den Wechsel zu Memorystore müssen Umgebungsvariablen gelesen werden. Daher benötigen wir das Python-Modul os sowie redis, den Python-Redis-Client. Da in Redis keine Python-Objekte im Cache gespeichert werden können, muss die Liste der letzten Besuche mit pickle serialisiert werden. Importieren Sie sie also auch. Ein Vorteil von Memcache ist, dass die Objektserialisierung automatisch erfolgt, während Memorystore etwas mehr „Do-it-yourself“ ist. Führen Sie schließlich ein Upgrade von App Engine ndb auf Cloud NDB durch, indem Sie google.appengine.ext.ndb durch google.cloud.ndb ersetzen. Nach diesen Änderungen sollten Ihre Importe jetzt so aussehen:

DANACH:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

Initialisierung aktualisieren

Die Initialisierung von Modul 12 besteht aus dem Instanziieren des Flask-Anwendungsobjekts app und dem Festlegen einer Konstanten für eine Stunde Caching:

VORHER:

app = Flask(__name__)
HOUR = 3600

Für die Verwendung von Cloud APIs ist ein Client erforderlich. Instanziieren Sie daher direkt nach Flask einen Cloud NDB-Client. Rufen Sie als Nächstes die IP-Adresse und die Portnummer für die Memorystore-Instanz aus den Umgebungsvariablen ab, die Sie in app.yaml festgelegt haben. Instanziieren Sie mit diesen Informationen einen Redis-Client. So sieht Ihr Code nach diesen Aktualisierungen aus:

DANACH:

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

*Migration zu Python 3

Dieser Abschnitt ist optional und gilt nur, wenn Sie mit der Python 3-Version der App aus Modul 12 beginnen. In diesem Fall sind mehrere erforderliche Änderungen in Bezug auf Importe und Initialisierung erforderlich.

Erstens ist Memcache ein gebündelter App Engine-Dienst. Für die Verwendung in einer Python 3-Anwendung ist daher das App Engine SDK erforderlich, insbesondere das Wrapping der WSGI-Anwendung (sowie andere erforderliche Konfigurationen):

VORHER:

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

Da wir zu Cloud Memorystore migrieren (kein gebündelter App Engine-Dienst wie Memcache), muss die SDK-Nutzung entfernt werden. Das ist ganz einfach, da Sie nur die gesamte Zeile löschen müssen, in der sowohl memcache als auch wrap_wsgi_app importiert werden. Löschen Sie auch die Zeile, in der wrap_wsgi_app() aufgerufen wird. Durch diese Updates bleibt dieser Teil der App (eigentlich die gesamte App) identisch mit der Python 2-Version.

DANACH:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

Entfernen Sie schließlich die Verwendung des SDK aus app.yaml (löschen Sie die Zeile: app_engine_apis: true) und requirements.txt (löschen Sie die Zeile: appengine-python-standard).

Zu Cloud Memorystore (und Cloud NDB) migrieren

Das Datenmodell von Cloud NDB ist mit dem von App Engine ndb kompatibel. Das bedeutet, dass die Definition von Visit-Objekten gleich bleibt. Wie bei der Migration von Modul 2 zu Cloud NDB werden alle Datastore-Aufrufe in store_visit() und fetch_visits() erweitert und in einen neuen with-Block eingebettet, da die Verwendung des Cloud NDB-Kontextmanagers erforderlich ist. So sahen diese Anrufe vor der Änderung aus:

VORHER:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

Fügen Sie beiden Funktionen einen with ds_client.context()-Block hinzu und setzen Sie die Datenspeicheraufrufe in den Block ein (und rücken Sie sie ein). In diesem Fall sind keine Änderungen an den Anrufen selbst erforderlich:

DANACH:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

Sehen wir uns als Nächstes die Änderungen beim Caching an. Hier ist die Funktion main() aus Modul 12:

VORHER:

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

Redis hat wie Memcache „get“- und „set“-Aufrufe. Wir tauschen doch nur die entsprechenden Clientbibliotheken aus, oder? Fast. Wie bereits erwähnt, können wir eine Python-Liste nicht mit Redis im Cache speichern, da sie zuerst serialisiert werden muss. Memcache übernimmt das automatisch. Daher wird im set()-Aufruf mit pickle.dumps() ein String aus den Besuchen erstellt. Wenn Sie Besuche aus dem Cache abrufen, müssen Sie sie mit pickle.loads() direkt nach dem get() entpickeln. Hier ist der Haupthandler nach der Implementierung dieser Änderungen:

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)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # 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))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

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

Damit sind die erforderlichen Änderungen in main.py abgeschlossen, um die Verwendung von Memcache in der Beispielanwendung in Cloud Memorystore zu konvertieren. Was ist mit der HTML-Vorlage und der Portierung zu Python 3?

HTML-Vorlagendatei aktualisieren und zu Python 3 portieren?

Überraschung! Hier ist nichts zu tun, da die Anwendung so konzipiert wurde, dass sie sowohl unter Python 2 als auch unter Python 3 ohne Codeänderungen oder Kompatibilitätsbibliotheken ausgeführt werden kann. Sie finden main.py. identisch in den Ordnern „FINISH“ für mod13a (2.x) und mod13b (3.x). Dasselbe gilt für requirements.txt , abgesehen von etwaigen Unterschieden bei den Versionsnummern (falls verwendet). Da die Benutzeroberfläche unverändert bleibt, gibt es auch keine Änderungen an templates/index.html.

Alles, was zum Ausführen dieser App in Python 3 App Engine erforderlich ist, wurde bereits in der Konfiguration erledigt: Unnötige Direktiven wurden aus app.yaml entfernt und sowohl appengine_config.py als auch der Ordner lib wurden gelöscht, da sie in Python 3 nicht verwendet werden.

7. 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 Bereinigungen durch und überlegen Sie sich die nächsten Schritte.

Anwendung bereitstellen und überprüfen

Als letzten Schritt müssen Sie die Beispiel-App bereitstellen. Python 2-Entwickler: Löschen Sie lib und installieren Sie es mit den folgenden Befehlen neu. Wenn sowohl Python 2 als auch Python 3 auf Ihrem System installiert sind, müssen Sie möglicherweise stattdessen pip2 ausführen.

rm -rf ./lib
pip install -t lib -r requirements.txt

Entwickler, die Python 2 und Python 3 verwenden, sollten ihre Apps jetzt mit Folgendem bereitstellen:

gcloud app deploy

Da Sie nur die interne Verkabelung für einen völlig anderen Caching-Dienst geändert haben, sollte die App selbst genauso funktionieren wie Ihre App aus Modul 12:

Modul 7: visitme-App

Damit ist das Codelab abgeschlossen. Vergleichen Sie Ihre aktualisierte Beispiel-App mit einem der Ordner aus Modul 13, entweder mod13a (Python 2) oder mod13b (Python 3).

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:

  • Für Cloud Memorystore sind Instanzen erforderlich und es gibt keine kostenlose Stufe. Weitere Informationen zu den Nutzungskosten finden Sie auf der Preisseite.
  • Für Connectors für serverlosen VPC-Zugriff sind Instanzen erforderlich und es gibt kein kostenloses Kontingent. Weitere Informationen zu den Nutzungskosten finden Sie im entsprechenden Abschnitt auf der Seite „VPC-Preise“.
  • Cloud Datastore (Cloud Firestore im Datastore-Modus) bietet ein kostenloses Kontingent. Weitere Informationen finden Sie auf der Preisseite.

In dieser Anleitung wurden vier Cloud-Produkte verwendet:

  • App Engine
  • Cloud Datastore
  • Cloud Memorystore
  • Cloud VPC

Unten finden Sie eine Anleitung zum Freigeben dieser Ressourcen, um Abrechnungsgebühren zu vermeiden oder zu minimieren.

Memorystore-Instanz und VPC-Connector herunterfahren

Dies sind die Produkte ohne kostenlose Stufe. Die Abrechnung erfolgt also sofort. Wenn Sie Ihr Cloud-Projekt nicht herunterfahren (siehe nächsten Abschnitt), müssen Sie sowohl Ihre Memorystore-Instanz als auch den VPC-Connector löschen, um die Abrechnung zu beenden. Ähnlich wie beim Erstellen dieser Ressourcen können Sie sie auch über die Cloud Console oder die Befehlszeile freigeben.

Über die Cloud Console

Wenn Sie die Memorystore-Instanz löschen möchten, kehren Sie zum Memorystore-Dashboard zurück und klicken Sie auf die Instanz-ID:

2b09baf1aa2e0a25.png

Klicken Sie auf der Detailseite der Instanz auf „Löschen“ und bestätigen Sie den Vorgang:

f9d9eb1c1d4c6107.png

Wenn Sie den VPC-Connector löschen möchten, rufen Sie sein Dashboard auf, klicken Sie das Kästchen neben dem zu löschenden Connector an, klicken Sie auf „Löschen“ und bestätigen Sie den Vorgang:

ca5fbd9f4c7c9b60.png

Über die Befehlszeile

Mit den folgenden gcloud-Befehlen werden die Memorystore-Instanz bzw. der VPC-Connector gelöscht:

  • gcloud redis instances delete INSTANCE --region REGION
  • gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

Wenn Sie Ihre Projekt-ID nicht mit gcloud config set project festgelegt haben, müssen Sie möglicherweise --project PROJECT_ID angeben. Wenn Ihre Memorystore-Instanz demo-ms und Ihr VPC-Connector demo-vpc heißt und sich beide in der Region us-central1 befinden, führen Sie die folgenden beiden Befehle aus und bestätigen Sie:

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

Jede Anfrage kann einige Minuten in Anspruch nehmen. Diese Schritte sind optional, wenn Sie Ihr gesamtes Cloud-Projekt wie oben beschrieben schließen. Die Abrechnung erfolgt jedoch weiterhin, bis der Schließungsprozess abgeschlossen ist.

Nächste Schritte

Neben dieser Anleitung gibt es weitere Migrationsmodule, die sich mit der Umstellung von den gebündelten Legacy-Diensten befassen:

  • Modul 2: Von App Engine ndb zu Cloud NDB migrieren
  • Module 7–9: Push-Aufgaben von App Engine Task Queue zu Cloud Tasks migrieren
  • Module 12–13: Von App Engine Memcache zu Cloud Memorystore migrieren
  • Module 15–16: Migration von App Engine Blobstore zu Cloud Storage
  • Module 18–19: Von App Engine-Aufgabenwarteschlange (Pull-Aufgaben) zu Cloud Pub/Sub migrieren

App Engine ist nicht mehr die einzige serverlose Plattform in Google Cloud. Wenn Sie eine kleine App Engine-Anwendung oder eine Anwendung mit eingeschränkter Funktionalität haben und sie in einen eigenständigen Mikrodienst umwandeln möchten oder eine monolithische Anwendung in mehrere wiederverwendbare Komponenten aufteilen möchten, sind dies gute Gründe für einen Wechsel zu Cloud Functions. Wenn die Containerisierung Teil Ihres Anwendungsentwicklungs-Workflows geworden ist, insbesondere wenn er aus einer CI/CD-Pipeline (Continuous Integration/Continuous Delivery oder Deployment) besteht, sollten Sie eine Migration zu Cloud Run in Betracht ziehen. Diese Szenarien werden in den folgenden Modulen behandelt:

  • Von App Engine zu Cloud Functions migrieren: Modul 11
  • Von App Engine zu Cloud Run migrieren: Modul 4 enthält Informationen zum Containerisieren Ihrer App mit Docker und Modul 5 zum Containerisieren ohne Container, Docker-Kenntnisse oder Dockerfiles.

Der Wechsel zu einer anderen serverlosen Plattform ist optional. Wir empfehlen, die besten Optionen für Ihre Apps und Anwendungsfälle zu prüfen, bevor Sie Änderungen vornehmen.

Unabhängig davon, welches Migrationsmodul Sie als Nächstes in Betracht ziehen, können Sie auf alle Serverless Migration Station-Inhalte (Codelabs, Videos, Quellcode [sofern verfügbar]) über das zugehörige Open-Source-Repository zugreifen. Das README des Repositorys enthält auch Informationen dazu, welche Migrationen infrage kommen und welche Reihenfolge der Migrationsmodule relevant ist.

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 12 (START) und Modul 13 (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 12

code

code

Modul 13 (dieses Codelab)

code

code

Online-Referenzen

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

App Engine

App Engine NDB und Cloud NDB

App Engine Memcache und Cloud Memorystore

Cloud VPC

Andere Cloud-Informationen

Lizenz

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