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

1. Übersicht

Die Codelabs-Reihe zur Serverless Migration Station (zum Selbststudium, praxisorientierte Anleitungen) und ähnliche Videos sollen Entwickler von Google Cloud Serverless bei der Modernisierung ihrer Anwendungen unterstützen, indem sie eine oder mehrere Migrationen durchgehen, in erster Linie von Legacy-Diensten. Dadurch werden Ihre Anwendungen portabler und bieten mehr Optionen und Flexibilität, sodass Sie eine breitere Palette von Cloud-Produkten einbinden und darauf zugreifen sowie einfacher auf neuere Sprachversionen upgraden können. Der Schwerpunkt dieser Reihe liegt anfangs auf die ersten Cloud-Nutzer, in erster Linie auf Entwicklern von App Engine (Standardumgebung). Sie ist aber umfassend genug, um auch andere serverlose Plattformen wie Cloud Functions und Cloud Run oder gegebenenfalls andere Plattformen einzubeziehen.

In diesem Codelab erfahren Sie, wie App Engine-Entwickler für Python 2 von App Engine Memcache zu Cloud Memorystore (für Redis) migrieren. Es gibt auch eine implizite Migration von App Engine ndb zu Cloud NDB, die jedoch hauptsächlich im Codelab für Modul 2 behandelt wird. erhalten Sie eine detaillierte Anleitung.

Sie verwenden Memcache nicht?

Wenn Ihre Anwendung App Engine Memcache nicht verwendet, können Sie dieses Codelab überspringen oder es als Übung ausführen, um sich mit der Migration zu Cloud Memorystore vertraut zu machen.

Sie werden lernen,

• Cloud Memorystore-Instanz einrichten (über die Cloud Console oder das gcloud-Tool)
• Richten Sie einen Cloud-Connector für serverlosen VPC-Zugriff ein (ü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

• Ein Google Cloud-Projekt mit einem aktiven Rechnungskonto (dies ist kein kostenloses Codelab)
• Grundlegende Python-Kenntnisse
• Erfahrung mit gängigen Linux-Befehlen
• Grundkenntnisse zum Entwickeln und Bereitstellen von App Engine-Anwendungen
• Eine funktionierende App Engine-Anwendung für Modul 12. Schließen Sie das Codelab für Modul 12 ab [empfohlen] oder kopieren Sie die Anwendung für Modul 12 aus dem Repository.

Umfrage

Wie möchten Sie diese Anleitung nutzen?

<ph type="x-smartling-placeholder"></ph> Lesen Sie sie nur durch. Lies sie dir durch und absolviere die Übungen

Wie würden Sie Ihre Erfahrung mit Python bewerten?

<ph type="x-smartling-placeholder"></ph> Neuling Mittel Kompetent

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

<ph type="x-smartling-placeholder"></ph> Neuling Mittel Kompetent

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 Vorgang werden Abhängigkeiten von gebündelten App Engine-Diensten ersetzt, wodurch Ihre Anwendungen portabler werden. Sie können entweder bei App Engine bleiben oder zu einer der oben beschriebenen Alternativen wechseln.

Diese Migration erfordert mehr Aufwand als die anderen in dieser Reihe. Als Ersatz für App Engine Memcache wird Cloud Memorystore empfohlen, ein vollständig verwalteter cloudbasierter Caching-Dienst. Memorystore unterstützt zwei beliebte Open-Source-Caching-Engines: Redis und Memcached. Dieses Migrationsmodul verwendet Cloud Memorystore for Redis. Weitere Informationen finden Sie in der Übersicht zu 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 ihre private IP-Adresse eine Verbindung zur Memorystore-Instanz herstellen kann. Wenn Sie diese Übung abgeschlossen haben, werden Sie die Anwendung so aktualisiert haben, dass sie sich zwar wie zuvor verhält, aber Cloud Memorystore der Caching-Dienst ist und den Memcache-Dienst von App Engine ersetzt.

Diese Anleitung beginnt mit der Beispiel-App für Modul 12 in Python 2, gefolgt von einem zusätzlichen, optionalen, kleineren Upgrade auf Python 3. Wenn Sie bereits mit dem Zugriff auf gebündelte App Engine-Dienste aus Python 3 über das Python 3 App Engine SDK vertraut sind, können Sie stattdessen mit der Python 3-Version der Beispiel-App für Modul 12 beginnen. Andernfalls wird das SDK nicht mehr verwendet, da es sich bei Memorystore nicht um einen gebündelten App Engine-Dienst handelt. Das Erlernen der Verwendung des Python 3 App Engine SDK wird in dieser Anleitung nicht behandelt.

In dieser Anleitung werden die folgenden wichtigen Schritte beschrieben:

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

3. Einrichtung/Vorarbeit

Cloud-Projekt vorbereiten

Wir empfehlen, dasselbe Projekt zu verwenden, das Sie auch für das Codelab für Modul 12 verwendet haben. Alternativ können Sie ein ganz neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Jedes Codelab in dieser Reihe hat einen „START“ (Basiscode, mit dem der Ausgangspunkt beginnen soll) und ein FINISH (die migrierte Anwendung). Der FINISH-Code wird bereitgestellt, damit Sie Ihre Lösungen mit unserer Lösung vergleichen können, falls Probleme auftreten. Sollte ein Fehler auftreten, können Sie jederzeit einen Rollback zu „START“ durchführen. Mit diesen Prüfpunkten soll sichergestellt werden, dass Sie erfolgreich lernen, wie die Migrationen durchgeführt werden.

Unabhängig davon, welches Cloud-Projekt Sie verwenden, muss es ein aktives Rechnungskonto haben. Achten Sie außerdem darauf, dass App Engine aktiviert ist. Lesen Sie sich diese Anleitungen durch und machen Sie sich mit den Auswirkungen auf die allgemeinen Kosten vertraut. Im Gegensatz zu anderen in dieser Reihe werden in diesem Codelab jedoch Cloud-Ressourcen verwendet, die keine kostenlose Stufe haben. Daher fallen für die Übung einige Kosten an. Es werden spezifischere Kosteninformationen zusammen mit Empfehlungen für die reduzierte Nutzung bereitgestellt, einschließlich einer Anleitung am Ende der Freigabe von Ressourcen, um die Gebühren zu minimieren.

Baseline-Beispiel-App abrufen

In diesem Codelab wird die Migration Schritt für Schritt beschrieben. Wenn Sie fertig sind, erreichen Sie eine funktionierende Modul 13-App, die dem Code in einem der FINISH-Ordner ähnelt. Hier sind diese Ressourcen:

• START: Modul 12 Python 2 (mod12) oder Python 3 (mod12b)-Anwendung
• FINISH: Anwendung Modul 13 Python 2 (mod13a) oder Python 3 (mod13b)
• Gesamtes Migrations-Repository (Klonen oder ZIP-Datei herunterladen)

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.

Anwendung von Modul 12 (erneut) bereitstellen

Verbleibende vorbereitende Schritte:

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

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

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

Nun sollte jeder Nutzer (Python 2- und 3-Nutzer) den Code mit dem folgenden Befehl in App Engine hochladen:

gcloud app deploy                

Überprüfen Sie nach erfolgreicher Bereitstellung, ob die App wie die App in Modul 12 aussieht und funktioniert. Modul 12 ist eine Webanwendung, die Besuche verfolgt und sie eine Stunde lang für denselben Nutzer im Cache speichert:

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 Redis. Im Gegensatz zu Memcache ist Memorystore ein eigenständiges Cloud-Produkt und hat keine kostenlose Stufe. Sehen Sie sich deshalb die Preisinformationen zu Memorystore for Redis an, bevor Sie fortfahren. Um die Kosten für diese Übung zu minimieren, empfehlen wir die geringsten Ressourcen für den Betrieb: die Dienststufe Basic und eine Kapazität von 1 GB.

Die Memorystore-Instanz befindet sich in einem anderen Netzwerk als Ihre App Engine-Anwendung (Instanzen). Aus diesem Grund muss ein Connector für serverlosen VPC-Zugriff erstellt werden, damit App Engine auf Ihre Memorystore-Ressourcen zugreifen kann. Verwenden Sie zum Minimieren der VPC-Kosten den Instanztyp (f1-micro) und die geringste Anzahl von Instanzen, die angefragt werden soll. Wir empfehlen mindestens 2, maximal 3). Weitere Informationen finden Sie auf der Seite VPC-Preise.

Kosten: Diese Anleitung ist NICHT kostenlos.

Die meisten Codelabs zur Migration in dieser Reihe können kostenlos abgeschlossen werden. Dieses hier ist eine Ausnahme. Weder Cloud Memorystore noch Cloud VPC haben eine kostenlose Stufe. Sie können also nicht ohne Abrechnung fortfahren. Wir empfehlen Ihnen dringend, die Preisinformationen für beide Produkte zu lesen, bevor Sie fortfahren. Falls Ihre Kosten sehr wichtig sind, Sie dies jedoch fortsetzen möchten, empfehlen wir die Verwendung der kostengünstigsten Optionen. Geben Sie diese Ressourcen nach Abschluss des Codelabs sofort frei, um die Kosten auf ein Minimum zu reduzieren.

Wir wiederholen diese Empfehlungen zur Kostensenkung, während wir Sie durch die Erstellung der erforderlichen Ressourcen führen. Wenn Sie in der Cloud Console Memorystore- und VPC-Ressourcen erstellen, sehen Sie außerdem in der oberen rechten Ecke den Preisrechner für die einzelnen Produkte. So erhalten Sie eine Schätzung der monatlichen Kosten (siehe Abbildung unten). Diese Werte werden automatisch angepasst, wenn Sie die Optionen ändern. Das sollten Sie ungefähr so sehen:

Beide Ressourcen sind erforderlich und 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 zuerst den VPC-Connector erstellen, gibt es in diesem VPC-Netzwerk nichts, mit dem 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 Anwendung auf den Cache zugreifen kann. Sie können auch die Leitfäden zu Python 2 oder Python 3 in der offiziellen Dokumentation verwenden. Es lohnt sich auch, den Leitfaden zum Daten-Caching auf der Cloud NDB-Migrationsseite ( Python 2 oder Python 3) heranzuziehen.

Alle Ressourcen in der App Engine-Region erstellen

Im Folgenden erstellen Sie alle zusätzlichen Cloud-Ressourcen, die zur Verwendung von Cloud Memorystore als Caching-Dienst Ihrer App Engine-Anwendung erforderlich sind. Beachten Sie, dass Sie sowohl die Memorystore-Instanz als auch den Connector für serverlosen VPC-Zugriff in derselben Region wie die App Engine-Anwendung erstellen müssen.

Cloud Memorystore-Instanz erstellen

Da es für Cloud Memorystore keine kostenlose Stufe gibt, empfehlen wir, für das Codelab möglichst wenige Ressourcen zuzuweisen. Mit den folgenden Einstellungen können Sie die Kosten auf ein Minimum reduzieren:

• Wählen Sie die niedrigste Dienststufe aus: Basic (Standardeinstellung in der Console: „Standard“, gcloud Standardwert: „Basic“).
• Wählen Sie die geringste Speicherplatzmenge aus: 1 GB (Standardeinstellung auf der Konsole: 16 GB, gcloud Standardeinstellung: 1 GB).
• In der Regel benötigen die neuesten Versionen jeder Software die meisten Ressourcen. Es ist jedoch wahrscheinlich nicht empfehlenswert, die älteste Version auszuwählen. Die zweitneueste Version ist derzeit die Redis-Version 5.0 (Console-Standardeinstellung: 6.x).

Unter Berücksichtigung dieser Einstellungen werden Sie im nächsten Abschnitt durch die Erstellung der Instanz in der Cloud Console geführt. Wenn Sie es lieber von der Befehlszeile aus tun möchten, überspringen Sie diesen Schritt.

Über die Cloud Console

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

Nach der Aktivierung (und möglicherweise zusammen mit der Abrechnung) gelangen Sie zum Memorystore-Dashboard. Hier können Sie alle Instanzen sehen, die in Ihrem Projekt erstellt wurden. Im unten angezeigten Projekt gibt es keine. Daher wird „Keine anzuzeigenden Zeilen“ angezeigt. Zum Erstellen einer Memorystore-Instanz klicken Sie oben auf Instanz erstellen:

Cloud Console-Updates

Die Benutzeroberfläche der Cloud Console ändert sich von Zeit zu Zeit. Daher kann es sein, dass sie nicht genau wie in den Screenshots dargestellt wird.

Diese Seite enthält ein Formular, in das Sie die gewünschten Einstellungen eintragen können, um die Memorystore-Instanz zu erstellen:

Folgen Sie den zuvor beschriebenen Empfehlungen, um die Kosten für diese Anleitung und die zugehörige Beispiel-App niedrig zu halten. Nachdem Sie Ihre Auswahl getroffen haben, klicken Sie auf Erstellen. Die Erstellung dauert einige Minuten. Kopieren Sie nach Abschluss des Vorgangs die IP-Adresse der Instanz und die Portnummer und fügen Sie sie in app.yaml hinzu.

Über die Befehlszeile

Das Erstellen von Memorystore-Instanzen über die Cloud Console ist zwar visuell informativ, einige bevorzugen jedoch 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 wie in diesem Beispiel aus und warten Sie, bis er abgeschlossen ist:

$ 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 das (erneute) Ausführen des Befehls keine (negativen) Nebenwirkungen. Erstellen Sie mit dem aktivierten Dienst eine Memorystore-Instanz. Dieser 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“ verwendet als Namen zusammen mit der Projekt-ID "my-project" ein. Die Region dieser Beispielanwendung ist us-central1 (genau wie us-central). Sie können jedoch eine Region in Ihrer Nähe verwenden, wenn die Latenz ein Problem darstellt. Sie müssen dieselbe Region wie in Ihrer App Engine-Anwendung auswählen. Sie können jede beliebige Redis-Version auswählen, wir verwenden jedoch wie zuvor empfohlen Version 5. Angesichts dieser Einstellungen würden Sie folgenden Befehl ausführen (zusammen mit der zugehörigen Ausgabe):

$ 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 Standardeinstellungen der Cloud Console verwendet gcloud standardmäßig nur minimale Ressourcen. Das Ergebnis ist, dass bei diesem Befehl weder die Dienststufe noch die Speichermenge erforderlich waren. Das Erstellen einer Memorystore-Instanz dauert einige Minuten. Notieren Sie sich anschließend die IP-Adresse und die Portnummer der Instanz, da diese 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 prüfen, ob sie verfügbar und einsatzbereit ist: gcloud redis instances list --region REGION

Mit dem folgenden Befehl können Sie die Instanzen in der Region us-central1 zusammen mit der erwarteten Ausgabe der gerade erstellten Instanz prüfen:

$ 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 oder zur Konfiguration Ihrer Anwendung gefragt werden, verwenden Sie HOST und PORT (nicht RESERVED_IP). Im Cloud Memorystore-Dashboard in der Cloud Console sollte diese Instanz jetzt angezeigt werden:

Von virtueller Compute Engine-Maschine

Wenn Sie eine virtuelle Maschine (VM) von Compute Engine haben, können Sie auch direkte Befehle von Ihrer Memorystore-Instanz von einer VM senden, um zu prüfen, ob sie funktioniert. Beachten Sie, dass die Verwendung einer VM unabhängig von den bereits verwendeten Ressourcen mit Kosten verbunden sein kann.

Connector für serverlosen VPC-Zugriff erstellen

Wie bei Cloud Memorystore können Sie den serverlosen Cloud VPC-Connector in der Cloud Console oder in der Befehlszeile erstellen. Ebenso gibt es bei Cloud VPC keine kostenlose Stufe. Daher empfehlen wir, für das Codelab so viele Ressourcen wie möglich zuzuweisen, damit die Kosten auf ein Minimum reduziert werden. Das kann mit den folgenden Einstellungen erreicht werden:

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

Im nächsten Abschnitt erfahren Sie, wie Sie den Connector mithilfe der obigen Cloud VPC-Einstellungen in der Cloud Console erstellen. Wenn Sie es lieber von der Befehlszeile aus tun möchten, fahren Sie mit dem nächsten Abschnitt fort.

Über die Cloud Console

Rufen Sie im Cloud-Netzwerk den Abschnitt Serverloser VPC-Zugriff“ auf. (möglicherweise werden Sie aufgefordert, Zahlungsinformationen einzugeben). Falls Sie die API noch nicht aktiviert haben, werden Sie dazu aufgefordert:

Sobald Sie die API (möglicherweise zusammen mit der Abrechnung) aktiviert haben, gelangen Sie zum Dashboard, in dem alle erstellten VPC-Connectors angezeigt werden. Für das im Screenshot unten verwendete Projekt gibt es keine. Daher steht hier „Keine anzuzeigenden Zeilen“. Klicken Sie in der Konsole oben auf Connector erstellen:

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

Wählen Sie die entsprechenden Einstellungen für Ihre Anwendungen aus. Für diese Anleitung und die Beispielanwendung mit minimalem Bedarf ist es sinnvoll, die Kosten zu minimieren. Folgen Sie daher den zuvor beschriebenen Empfehlungen. Nachdem Sie Ihre Auswahl getroffen haben, klicken Sie auf Erstellen. Das Anfordern 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. Die Ausgabe sollte ähnlich aussehen, nachdem Sie den folgenden Befehl ausgeführt haben:

$ 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 erstellt, der so aussieht:

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 IP-Adresse des CIDR-Blocks /28 aus. In dieser Anleitung wird von folgenden Annahmen ausgegangen:

• Project ID: my-project
• VPC-Connector-Name: demo-vpc
• Min. Instanzenanzahl: 2 (Standardeinstellung) und Höchstzahl der 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 Berücksichtigung der 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].

Mit dem obigen Befehl lassen sich Standardwerte wie die Mindestanzahl von Instanzen von 2 und ein Netzwerk mit dem Namen default angeben. Das Erstellen eines VPC-Connectors dauert einige Minuten.

Erstellen des Connectors bestätigen

Sobald der Vorgang abgeschlossen ist, geben Sie den folgenden gcloud-Befehl aus, sofern es sich um die Region us-central1 handelt. So können Sie prüfen, ob der Dienst 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

Auf ähnliche Weise sollte im Dashboard jetzt der soeben erstellte Connector angezeigt werden:

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

Nachdem Sie die zusätzlichen erforderlichen Cloud-Ressourcen erstellt haben, sei es über die Befehlszeile oder in der Console, ist es an der Zeit, die Anwendungskonfiguration zu aktualisieren, damit sie ihre Verwendung unterstützen.

5. Konfigurationsdateien aktualisieren

Der erste Schritt besteht darin, alle erforderlichen Aktualisierungen an den Konfigurationsdateien vorzunehmen. Das Hauptziel dieses Codelab ist es, Python 2-Nutzern bei der Migration zu helfen. Im Anschluss werden jedoch in den folgenden Abschnitten Informationen zur weiteren Portierung zu Python 3 aufgeführt.

requirements.txt

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

flask
redis
google-cloud-ndb

Diese requirements.txt-Datei enthält keine Versionsnummern. Es sind also die neuesten Versionen ausgewählt. Falls Inkompatibilitäten auftreten, geben Sie Versionsnummern an, die in Arbeitsversionen gesperrt werden sollen.

app.yaml

Neue Bereiche zum Hinzufügen

Die Python 2-Laufzeit in App Engine erfordert bestimmte Drittanbieterpakete, 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 hinzu:

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

Wenn du deine App migrierst, verfügt sie möglicherweise bereits über einen libraries-Bereich. Wenn dies der Fall ist und entweder grpcio oder setuptools fehlen, 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 deshalb 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 waren die erforderlichen Updates. Die aktualisierte app.yaml sollte jetzt 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, zur Veranschaulichung der Aktualisierungen, die auf app.yaml angewendet werden sollen:

*Unterschiede bei Python 3

Dieser Abschnitt ist optional und nur für die Portierung zu Python 3 erforderlich. Dazu müssen Sie eine Reihe von Änderungen an Ihrer Python 2-Konfiguration vornehmen. Überspringen Sie diesen Abschnitt, wenn Sie zu diesem Zeitpunkt kein Upgrade ausführen.

Weder threadsafe noch api_version werden für die Python 3-Laufzeit verwendet. Löschen Sie daher diese beiden Einstellungen. Die neueste App Engine-Laufzeit unterstützt weder integrierte Drittanbieterbibliotheken noch das Kopieren nicht integrierter Bibliotheken. Die einzige Voraussetzung für Drittanbieterpakete besteht darin, sie in requirements.txt aufzulisten. Daher kann der gesamte libraries-Abschnitt von app.yaml gelöscht werden.

Als Nächstes erfordert die Python 3-Laufzeit die Verwendung von Web-Frameworks, die ihr eigenes Routing erstellen. Daher haben wir Entwicklern gezeigt, wie sie in Modul 1 von webp2 zu Flask migrieren. Daher müssen alle Skript-Handler in auto geändert werden. Da diese Anwendung keine statischen Dateien bereitstellt, ist sie zwecklos. , um Handler aufgelistet zu haben (da sie alle auto sind), sodass auch der gesamte handlers-Abschnitt entfernt werden kann. Daher sollte Ihre neue, abgekürzte app.yaml, die für Python 3 optimiert wurde, wie folgt gekürzt werden:

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
• Bereich „libraries“ löschen
• Abschnitt handlers löschen (oder nur script-Handler, wenn deine Anwendung statische Dateien bereitstellt)

Werte ersetzen

Die Werte in den neuen Abschnitten für Memorystore und den VPC-Connector sind nur Platzhalter. Ersetzen Sie die Werte in Großbuchstaben (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) durch die Werte, die beim Erstellen dieser Ressourcen zuvor gespeichert wurden. Für die Memorystore-Instanz müssen Sie HOST (nicht RESERVED_IP) und PORT verwenden. Hier sehen Sie eine schnelle Befehlszeile, mit der Sie HOST und PORT abrufen können. Dabei wird davon ausgegangen, dass 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 unsere Beispiel-IP-Adresse der Redis-Instanz 10.10.10.10 mit Port 6379 in unserem Projekt my-project in der Region us-central1 und dem VPC-Connector-Namen demo-vpc lautete, 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 wie zuvor bei app.yaml die Nutzung der Bibliotheken grpcio und setuptools hinzu. Ändern Sie appengine_config.py, um integrierte Drittanbieterbibliotheken zu unterstützen. Wenn Ihnen dies bekannt vorkommt, liegt es daran, dass dies auch in Modul 2 bei der Migration von App Engine ndb zu Cloud NDB erforderlich war. Die genaue Änderung besteht darin, den Ordner lib dem Arbeitssatz setuptools.pkg_resources hinzuzufügen:

*Unterschiede bei Python 3

Dieser Abschnitt ist optional und nur für die Portierung zu Python 3 erforderlich. Eine der erfreulichen Änderungen der zweiten Generation von App Engine besteht darin, dass das Kopieren (manchmal als „Vendoring“ bezeichnet) von (nicht integrierten) Drittanbieterpaketen und das Verweisen auf integrierte Drittanbieterpakete in app.yaml nicht mehr erforderlich ist. Sie können also die gesamte Datei appengine_config.py löschen.

6. Anwendungsdateien aktualisieren

Es gibt nur die Anwendungsdatei main.py. Daher wirken sich alle Änderungen in diesem Abschnitt 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. Sie dient lediglich der Veranschaulichung und ist nicht für eine genaue Analyse bestimmt. Die ganze Arbeit besteht in den Änderungen, die wir am Code vornehmen.

Gehen wir diese Abschnitte nacheinander an und beginnen wir oben.

Importe aktualisieren

Im Importabschnitt in main.py für Modul 12 werden Cloud NDB und Cloud Tasks verwendet. Hier sind ihre 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, d. h. wir benötigen das Python-Modul os sowie redis, den Python-Redis-Client. Da Redis keine Python-Objekte im Cache speichern kann, wird die Liste der letzten Besuche mit pickle marschiert. Importieren Sie diese Liste also ebenfalls. Ein Vorteil von Memcache besteht darin, dass die Objektserialisierung automatisch erfolgt, während Memorystore eine eher DIY-Option ist. Führen Sie abschließend ein Upgrade von App Engine ndb auf Cloud NDB durch. Ersetzen Sie dazu google.appengine.ext.ndb durch google.cloud.ndb. Nach diesen Änderungen sollten Ihre Importe jetzt so aussehen:

NACHHER:

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

Initialisierung der Aktualisierung

Bei der Initialisierung von Modul 12 wird das Flask-Anwendungsobjekt app instanziiert und eine Konstante für das Caching einer Stunde festgelegt:

VORHER:

app = Flask(__name__)
HOUR = 3600

Für die Verwendung von Cloud APIs ist ein Client erforderlich. Instanziieren Sie daher einen Cloud NDB-Client direkt nach Flask. 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 einen Redis-Client mit diesen Informationen. So sieht Ihr Code nach diesen Aktualisierungen aus:

NACHHER:

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)

*Python 3-Migration

Dieser Abschnitt ist optional und wenn Sie mit der Python 3-Version der Modul 12-Anwendung beginnen. In diesem Fall sind mehrere Änderungen im Zusammenhang mit Importen und der Initialisierung erforderlich.

Da Memcache ein gebündelter App Engine-Dienst ist, erfordert seine Verwendung in einer Python 3-Anwendung das App Engine SDK. Dabei wird insbesondere die WSGI-Anwendung sowie andere erforderliche Konfigurationen verpackt:

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 (nicht zu einem gebündelten App Engine-Dienst wie Memcache), muss die SDK-Nutzung entfernt werden. Das ist unkompliziert, da Sie einfach die gesamte Zeile löschen, die sowohl memcache als auch wrap_wsgi_app importiert. Löschen Sie auch die Zeile, die wrap_wsgi_app() aufruft. Durch diese Updates ist dieser Teil der Anwendung, also die gesamte Anwendung, identisch mit der Python 2-Version.

NACHHER:

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)

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

Zu Cloud Memorystore (und Cloud NDB) migrieren

Das Datenmodell von Cloud NDB ist so ausgelegt, dass es mit dem ndb-Datenmodell von App Engine kompatibel ist, d. h. die Definition von Visit-Objekten bleibt gleich. Nach 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). Dies sind die Aufrufe vor dieser Änderung:

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 platzieren Sie die Datastore-Aufrufe darin (und eingerückt). In diesem Fall sind keine Änderungen für die Aufrufe selbst erforderlich:

NACHHER:

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)

Als Nächstes schauen wir uns die Caching-Änderungen an. Hier ist die main()-Funktion 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 enthält „get“ und „set“. wie Memcache. Wir tauschen lediglich die jeweiligen Client-Bibliotheken aus. Fast geschafft. Wie bereits erwähnt, können wir eine Python-Liste nicht mit Redis im Cache speichern (da sie zuerst serialisiert werden muss, was Memcache automatisch erledigt). Deshalb geben Sie im set()-Aufruf "pickle" an. die Besuche in einen String mit pickle.dumps() umwandeln. Ähnlich verhält es sich beim Abrufen von Besuchen aus dem Cache. Du musst es mit pickle.loads() direkt nach get() entpacken. Nach der Implementierung dieser Änderungen sieht der Haupt-Handler so aus:

NACHHER:

@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 Änderungen abgeschlossen, die für die main.py-Konvertierung der Verwendung von Memcache durch die Beispielanwendung in Cloud Memorystore erforderlich sind. Wie sieht es mit der HTML-Vorlage und der Portierung zu Python 3 aus?

HTML-Vorlagendatei und Port auf Python 3 aktualisieren?

Überraschung! Sie müssen nichts weiter tun, da die Anwendung sowohl unter Python 2 als auch unter Python 3 ausgeführt werden kann, ohne dass dafür Codeänderungen oder Kompatibilitätsbibliotheken erforderlich sind. Sie finden main.py. identisch bei mod13a (2.x) und mod13b (3.x) "FINISH" Ordner. Dasselbe gilt für requirements.txt , abgesehen von Unterschieden bei den Versionsnummern (falls verwendet). Da die Benutzeroberfläche unverändert bleibt, gibt es auch keine Updates für templates/index.html.

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

App Engine NDB und Cloud NDB bieten automatisiertes Caching

Während wir explizit von App Engine Memcache zu Cloud Memorystore migrieren, können Sie beachten, dass sowohl App Engine ndb als auch Cloud NDB automatisiertes Caching für Memcache bzw. Memorystore für Python 2 oder 3 bieten. Lesen Sie mehr über das ndb-Caching beim NDB-Caching und das Cloud NDB-Caching unter Daten-Caching aktivieren. Die Anweisungen spiegeln die Anweisungen in diesem Codelab wider. Weitere Funktionen finden Sie unter Kontext- und Transaktionsoptionen.

Der Grund, warum wir auf dieses automatisierte Caching verzichtet haben, ist, dass unsere Beispielanwendung nicht nach einzelnen Datastore-Entitäten abfragt (wobei auf diese über den Cache problemlos zugegriffen werden könnte). Stattdessen speichert diese App ein Array von Entitäten (letzte Besuche) im Cache. Dies ist ein zu spezifischer Anwendungsfall und wird von der automatisierten Caching-Ebene nicht unterstützt. Ihre App kann jedoch solche Anfragen ausführen und diese Funktion nutzen, was Ihre Nutzung insgesamt vereinfacht.

7. Zusammenfassung/Bereinigung

In diesem Abschnitt wird dieses Codelab abgeschlossen. Dazu wird die App bereitgestellt und geprüft, ob sie wie vorgesehen und in allen ausgegebenen Ausgabedaten funktioniert. Führen Sie nach der App-Überprüfung alle Bereinigungsschritte durch und erwägen Sie die nächsten Schritte.

Anwendung bereitstellen und prüfen

Die letzte Prüfung besteht immer darin, die Beispielanwendung bereitzustellen. Python 2-Entwickler: Löschen Sie lib und installieren Sie es mit den folgenden Befehlen neu. (Wenn Sie Python 2 und 3 auf Ihrem System installiert haben, müssen Sie stattdessen möglicherweise explizit pip2 ausführen.)

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

Sowohl Python 2- als auch Python 3-Entwickler sollten ihre Anwendungen jetzt mit folgenden Funktionen bereitstellen:

gcloud app deploy

Da Sie nur die Elemente im Hintergrund für einen völlig anderen Caching-Dienst neu verkabelt haben, sollte die App selbst genauso funktionieren wie die App in Modul 12:

Mit diesem Schritt wird das Codelab abgeschlossen. Wir empfehlen Ihnen, Ihre aktualisierte Beispiel-App mit einem der Ordner für Modul 13, mod13a (Python 2) oder mod13b (Python 3) zu vergleichen.

Bereinigen

Allgemein

Falls Sie vorerst fertig sind, empfehlen wir Ihnen, Ihre App Engine-Anwendung zu deaktivieren, um Gebühren zu vermeiden. Wenn Sie jedoch weitere Tests oder Experimente durchführen möchten, bietet die App Engine-Plattform ein kostenloses Kontingent. Solange Sie diese Nutzungsstufe nicht überschreiten, sollten Ihnen keine Kosten in Rechnung gestellt werden. Das bezieht sich auf die Rechenleistung. Es können jedoch auch Gebühren für relevante App Engine-Dienste anfallen. Weitere Informationen finden Sie auf der Preisseite. Wenn diese Migration andere Cloud-Dienste betrifft, werden diese separat abgerechnet. Lesen Sie in beiden Fällen gegebenenfalls den Abschnitt „Speziell für dieses Codelab“. weiter unten.

Zur vollständigen Offenlegung fallen bei der Bereitstellung auf einer serverlosen Computing-Plattform von Google Cloud wie App Engine geringfügige Build- und Speicherkosten an. Für Cloud Build und Cloud Storage gibt es ein eigenes kostenloses Kontingent. Die Speicherung dieses Images verbraucht einen Teil dieses Kontingents. Möglicherweise leben Sie in einer Region, in der es keine solche kostenlose Stufe gibt. Achten Sie daher auf Ihre Speichernutzung, um potenzielle Kosten zu minimieren. Bestimmte Cloud Storage-„Ordner“ sollten Sie Folgendes überprüfen:

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

Wenn Sie jedoch nicht mit dieser Anwendung oder anderen verwandten Migrations-Codelabs fortfahren und alles vollständig löschen möchten, beenden Sie Ihr Projekt.

Nur für dieses Codelab

Die unten aufgeführten Dienste gelten nur für dieses Codelab. Weitere Informationen finden Sie in der Dokumentation des jeweiligen Produkts:

• Cloud Memorystore erfordert Instanzen und hat keine kostenlose Stufe. Weitere Informationen zu den Nutzungskosten finden Sie auf der Preisseite.
• Für Connectors für serverlosen VPC-Zugriff von Cloud sind Instanzen erforderlich. Sie haben keine kostenlose Stufe. Weitere Informationen zu Nutzungskosten finden Sie im Abschnitt auf der Cloud VPC-Preisseite.
• Cloud Datastore (Cloud Firestore im Datastore-Modus) hat eine kostenlose Stufe. Weitere Informationen finden Sie auf der Preisseite.

In dieser Anleitung wurden vier Cloud-Produkte verwendet:

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

Nachfolgend finden Sie Anweisungen zur Freigabe dieser Ressourcen und zur Vermeidung bzw. Minimierung von Gebühren.

Memorystore-Instanz und VPC-Connector herunterfahren

Dies sind die Produkte ohne kostenlose Stufe. Die Abrechnung erfolgt daher jetzt. Wenn Sie Ihr Cloud-Projekt nicht beenden (siehe nächster Abschnitt), müssen Sie sowohl die 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

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

Klicken Sie dann auf der Detailseite der Instanz auf „Löschen“. und bestätige Folgendes:

Rufen Sie zum Löschen des VPC-Connectors sein Dashboard auf, klicken Sie das Kästchen neben dem zu löschenden Connector an und klicken Sie dann auf „Löschen“. und bestätige Folgendes:

Über die Befehlszeile

Mit dem folgenden Paar von gcloud-Befehlen werden sowohl die Memorystore-Instanz als auch 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 bei gcloud config set project festgelegt haben, müssen Sie möglicherweise --project PROJECT_ID angeben. Wenn Ihre Memorystore-Instanz demo-ms und der VPC-Connector demo-vpc heißt und sich beide in der Region us-central1 befinden, führen Sie das folgende Befehlspaar 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].

Die Ausführung jeder Anfrage dauert einige Minuten. Diese Schritte sind optional, wenn Sie Ihr gesamtes Cloud-Projekt wie zuvor beschrieben herunterfahren. Bis zum Abschluss des Beendigungsvorgangs fallen jedoch weiterhin Kosten an.

Nächste Schritte

Abgesehen von dieser Anleitung gibt es weitere Migrationsmodule, die sich auf die Umstellung von den gebündelten Legacy-Diensten konzentrieren:

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

App Engine ist nicht mehr die einzige serverlose Plattform in Google Cloud. Wenn Sie eine kleine App Engine-Anwendung oder eine 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 Workflows für die Anwendungsentwicklung geworden ist, insbesondere wenn sie aus einer CI/CD-Pipeline (Continuous Integration/Continuous Delivery oder Bereitstellung) besteht, sollten Sie eine Migration zu Cloud Run in Betracht ziehen. Diese Szenarien werden in den folgenden Modulen behandelt:

• Migration von App Engine zu Cloud Functions: siehe Modul 11
• Migration von App Engine zu Cloud Run: Siehe Modul 4 zum Containerisieren Ihrer Anwendung mit Docker oder Modul 5 zur Implementierung von Containern, Docker-Kenntnissen oder Dockerfile

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

Unabhängig davon, welches Migrationsmodul Sie als Nächstes in Betracht ziehen, können Sie auf alle Inhalte der Serverless Migration Station (Codelabs, Videos, Quellcode [falls verfügbar]) über das Open-Source-Repository zugreifen. Im README des Repositorys finden Sie außerdem Informationen dazu, welche Migrationen berücksichtigt werden müssen und welche relevante „Reihenfolge“ Sie haben Migrationsmodule.

8. Zusätzliche Ressourcen

Im Folgenden finden Sie zusätzliche Ressourcen für Entwickler, die sich näher mit diesem oder verwandten Migrationsmodul und ähnlichen Produkten befassen. 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/Feedback mit Codelabs

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

• Nach Problemen suchen
• Neues Problem melden/Feedback geben

Migrationsressourcen

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

Codelab	Python 2	Python 3
Modul 12	code	code
Modul 13 (dieses Codelab)	code	code

Onlinereferenzen

Nachfolgend finden Sie Onlineressourcen, die für diese Anleitung relevant sein könnten:

App Engine

• App Engine-Dokumentation
• Python 2-Laufzeit der App Engine (Standardumgebung)
• Integrierte App Engine-Bibliotheken in Python 2 App Engine verwenden
• Python 3-Laufzeit von App Engine (Standardumgebung)
• Unterschiede zwischen Python 2 und 3 Laufzeiten der App Engine (Standardumgebung)
• Python 2 zu 3 Migrationsanleitung für App Engine (Standardumgebung)
• Informationen zu Preisen und Kontingenten für App Engine

App Engine NDB und Cloud NDB

• App Engine NDB – Übersicht
• Nutzung des NDB-Datenspeichers in App Engine
• Google Cloud NDB-Dokumentation
• Google Cloud NDB-Repository
• Cloud Datastore-Preisinformationen

App Engine Memcache und Cloud Memorystore

• App Engine Memcache – Übersicht
• memcache-Referenz für Python 2 in App Engine
• memcache-Referenz für Python 3 in App Engine
• Anleitung für die Migration von memcache zu Cloud Memorystore von App Engine
• Cloud Memorystore-Dokumentation
• Dokumentation zu Cloud Memorystore for Redis
• Preisinformationen zu Cloud Memorystore for Redis
• Von Cloud Memorystore unterstützte Redis-Versionen
• Startseite von Cloud Memorystore
• Neue Memorystore-Instanz in der Cloud Console erstellen
• Startseite des Python Redis-Clients
• Dokumentation zur Python-Redis-Clientbibliothek

Cloud VPC

• Google Cloud VPC-Dokumentation
• Google Cloud VPC-Startseite
• Cloud VPC – Preisinformationen
• Neuen Connector für serverlosen VPC-Zugriff in der Cloud Console erstellen

Weitere Cloud-Informationen

• Python auf der Google Cloud Platform
• Google Cloud-Clientbibliotheken für Python
• „Immer kostenlos“ von Google Cloud Stufe
• Google Cloud SDK (gcloud-Befehlszeilentool)
• Gesamte Google Cloud-Dokumentation

Lizenz

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