Der Großteil der Funktionen der gebündelten Legacy-Dienste wird jetzt von den Cloud-Clientbibliotheken bereitgestellt. Weitere Informationen finden Sie unten in den empfohlenen Alternativen.
Wenn die Migration zu einer nicht gebündelten Lösung für Ihr Projekt nicht infrage kommt, dann können Sie weiterhin die gebündelten Legacy-Dienste in Ihren Python 3 Anwendungen als Fallback verwenden. Dieser Ansatz bietet Ihnen die Möglichkeit, später im Migrationszyklus zu ungebündelten Diensten zu wechseln.
Nachdem Sie die Migration von gebündelten Legacy-Diensten abgeschlossen haben, können Sie App Engine weiterhin verwenden oder zu Cloud Run migrieren. Cloud Run wurde zur Verbesserung der Nutzererfahrung von App Engine entwickelt. Es beinhaltet viele der besten Features sowohl der Standardumgebung als auch der flexiblen Umgebung. Einen Vergleich der Funktionen und Informationen zur Migration finden Sie im Leitfaden zum Vergleich von App Engine und Cloud Run.
Google Cloud bietet eigenständige Produkte mit ähnlichen Funktionen wie einige der gebündelten Legacy-Dienste in der Python-Laufzeit. Für gebündelte Legacy-Dienste , die nicht als separate Produkte in Google Cloudverfügbar sind, wie z. B. E-Mail und Messaging, enthält dieser Leitfaden Empfehlungen für Drittanbieter oder andere Problemumgehungen.
Auf dieser Seite wird der Migrationspfad für die gebündelten Legacy-Dienste erläutert.
Berechtigungen verstehen Google Cloud
Ihre migrierte Anwendung und die Google Cloud von ihr verwendeten Dienste werden nicht in derselben Sandbox-Umgebung ausgeführt. Ihre Anwendung benötigt eine Autorisierung für den Zugriff auf die einzelnen Dienste. Wenn Sie beispielsweise mit Firestore im Datastore-Modus (Datastore) oder Cloud Tasks interagieren möchten, muss Ihre Anwendung die Anmeldedaten eines Kontos bereitstellen, das zum Zugriff auf diese Dienste berechtigt ist.
Anwendungen, die in der App Engine-Standardumgebung ausgeführt werden, stellen standardmäßig die Anmeldedaten für das App Engine-Standard Dienstkonto bereit, das für den Zugriff auf Datenbanken im selben Projekt wie Ihre Anwendung autorisiert ist.
Wenn eine der folgenden Bedingungen zutrifft, verwenden Sie eine alternative Authentifizierungsmethode, die Anmeldedaten explizit bereitstellt:
Ihre Anwendung und die Memorystore-Datenbank befinden sich in verschiedenen Google Cloud Projekten.
Sie haben die Rollen geändert, die dem App Engine-Standarddienstkonto zugewiesen sind.
Informationen zu alternativen Authentifizierungsmethoden finden Sie unter Authentifizierung für Server-zu-Server-Produktionsanwendungen einrichten.
Authentifizierung für die lokale Entwicklung
Wenn Sie Ihre Anwendung lokal entwickeln oder testen möchten, erstellen Sie ein Dienstkonto und verwenden Sie es. Verwenden Sie nicht das App Engine-Standarddienstkonto , da es umfassende Berechtigungen für Ihr Projekt hat. Erstellen und nutzen Sie stattdessen ein Dienstkonto mit den Mindest Berechtigungen, die Sie benötigen für Ihre jeweiligen Entwicklungs- und Testaufgaben.
Informationen zum Einrichten eines Dienstkontos und zum Verknüpfen des Dienstkontos mit Ihrer Anwendung finden Sie unter Dienstkonto-Anmeldedaten manuell abrufen und bereitstellen.
Clientbibliotheken installieren
Wenn Sie Google Cloud Dienste aus einer Python-Anwendung verwenden möchten, installieren Sie die Python-Client bibliothek für den Dienst. Google Cloud Dienste bieten auch REST APIs und andere Schnittstellen.
So installieren Sie eine Clientbibliothek für die Python 3-Laufzeit:
Fügen Sie den Bibliotheksnamen der Datei
requirements.txtIhrer Anwendung hinzu. Beispiel:google-cloud-ndb
App Engine lädt automatisch alle in der Datei requirements.txt aufgeführten Bibliotheken in die Python 3-Laufzeit hoch.
Migrationspfade für gebündelte App Engine-Dienste
Blobstore
Verwenden Sie zum Speichern und Abrufen von Daten Cloud Storage über die Cloud-Clientbibliotheken. Eine Einführung finden Sie unter Cloud Storage verwenden und im Leitfaden Von Blobstore zu Cloud Storage migrieren. Wenn Sie diese Migration simulieren möchten, fügen Sie einer Beispielanwendung die Blobstore-Nutzung hinzu und migrieren Sie zu Cloud Storage.
Datastore
Wenn Ihre Python 2-Anwendung NDB zur Interaktion mit Datastore verwendet, migrieren Sie zur Cloud NDB-Bibliothek. Cloud NDB ist hauptsächlich als Umstellungstool für die Migration von Python 2-Anwendungen gedacht. Wir empfehlen, dass Python 3-Anwendungen die Clientbibliothek im Datastore-Modus verwenden.
Weitere Informationen finden Sie unter Zu Cloud NDB migrieren. Wenn Sie diese Migration mit einer Beispielanwendung simulieren möchten, lesen Sie den Migrationsleitfaden von App Engine NDB zu Cloud NDB.
Bilder
Sie können Bilder aus Cloud Storage bereitstellen, entweder direkt oder mit einem Content Delivery Network (CDN) eines Drittanbieters.
Zum Ändern der Bildgröße und zum Konvertieren bzw. Bearbeiten von Bildern verwenden Sie eine Bildverarbeitungsbibliothek wie Pillow oder eine Python-Schnittstelle für ImageMagick.
Wenn Sie eine dieser Drittanbieterbibliotheken nutzen möchten, fügen Sie die Bibliothek als Abhängigkeit hinzu und aktualisieren Ihren Code, um die APIs der Bibliothek aufzurufen.
Mit dem App Engine-Bilderdienst können Sie auch dynamische Anfragen an Ihre Anwendung vermeiden. Damit wird die Größe von Bildern mithilfe einer Bereitstellungs-URL geändert. Sie können stattdessen auch die Bilder mit der neuen Größe im Voraus generieren und dann zur Bereitstellung in Cloud Storage hochladen. Alternativ haben Sie die Möglichkeit, die Bildgröße mit einem entsprechenden externen CDN-Dienst (Content Delivery Network) zu ändern.
Logging
Wir empfehlen Ihnen, Ihre Anwendung auf die Verwendung von Cloud Logging zu aktualisieren. Diese unterstützt Funktionen wie das Aufrufen von Logs im Logs Explorer, das Herunterladen von Logs, das Filtern von Nachrichten nach Schweregrad und die Korrelation von Anwendungsnachrichten mit bestimmten Anfragen. Wenn Sie die Einfachheit der Datenerfassung der Datengenauigkeit vorziehen, können Sie strukturierte Logs auch in stdout oder stderr schreiben.
Weitere Informationen finden Sie unter
Logs schreiben und ansehen und unter Zu Cloud Logging migrieren.
Memcache
Verwenden Sie Memorystore for Redis zum Speichern von Anwendungsdaten im Cache.
Weitere Informationen finden Sie unter Memcache zu Memorystore migrieren. Wenn Sie diese Migration simulieren möchten, fügen Sie einer Beispielanwendung die Memcache Nutzung hinzu und migrieren Sie zu Memorystore for Redis.
Wenn Anwendungen Memcache nur verwenden, um die Latenz für NDB- (oder Cloud NDB-)Anfragen zu verringern, verwenden Sie die integrierte Unterstützung von Cloud NDB für Redis anstelle von Memcache oder Memorystore for Redis.
Module
Zum Abrufen von Informationen und zum Ändern der ausgeführten Dienste Ihrer Anwendung verwenden Sie eine Kombination aus Umgebungsvariablen und der App Engine Admin API:
| Dienstinformation | Zugriff |
|---|---|
| Aktuelle Anwendungs-ID | Umgebungsvariable GAE_APPLICATION |
| Aktuelle Projekt-ID | Umgebungsvariable GOOGLE_CLOUD_PROJECT |
| Aktueller Dienstname | Umgebungsvariable GAE_SERVICE |
| Aktuelle Dienstversion | Umgebungsvariable GAE_VERSION |
| Aktuelle Instanz-ID | Umgebungsvariable GAE_INSTANCE |
| Standardhostname | Admin API-Methode apps.get |
| Liste der Dienste | Admin API-Methode apps.services.list |
| Liste der Versionen für einen Dienst | Admin API-Methode apps.services.versions.list |
| Standardversion für einen Dienst, inklusive Traffic-Aufteilung | Admin API-Methode apps.services.get |
| Liste der für eine Version ausgeführten Instanzen | Admin API apps.services.versions.instances.list Methode |
Weitere Informationen zu den Daten, die zu den ausgeführten Diensten Ihrer Anwendung verfügbar sind, finden Sie unter Python 3 Laufzeitumgebung.
Namespaces
Mit der Namespaces API konnten mehrinstanzenfähige Anwendungen Daten nach Mandanten partitionieren. Dazu wurde für jeden Mandanten einfach ein eindeutiger Namespace-String festgelegt.
Datastore unterstützt die Mehrinstanzenfähigkeit direkt, andere Google Cloud Dienste dagegen nicht. Wenn Ihre mehrinstanzenfähige Anwendung andere Google Cloud Dienste verwendet, müssen Sie die Mehrinstanzenfähigkeit manuell festlegen. Sie können mit der Cloud Resource Manager API programmatisch neue Projekte erstellen und projektübergreifend auf Ressourcen zugreifen, um Dienstinstanzen vollständig zu isolieren.
OAuth
Verwenden Sie zum Prüfen von OAuth 2.0-Tokens nicht den App Engine-OAuth-Dienst, sondern die Methode oauth2.tokeninfo der OAuth 2.0-API.
Suche
Hosten Sie eine Volltextsuchdatenbank wie Elasticsearch in Compute Engine und greifen Sie von Ihrem Dienst aus darauf zu.
Aufgabenwarteschlange
Der App Engine-Dienst für Aufgabenwarteschlangen ist in zwei verschiedenen Modi verfügbar. Migration von einem Punkt zu zwei verschiedenen eigenständigen Cloud-Produkten.
Push-Aufgaben
Anstelle des Dienstes für Push-Aufgaben der Aufgabenwarteschlange von App Engine zur asynchronen Code-Ausführung verwenden Sie die Clientbibliotheken von Cloud Tasks mit einem Endpunkt der Python 3-Standardumgebung als Ziel. Weitere Informationen finden Sie unter Push-Warteschlangen zu Cloud Tasks migrieren.
Wenn Sie diese Migration mit einer Beispielanwendung simulieren möchten, lesen Sie den Migrationsleitfaden zur Verwendung von App Engine-Push-Warteschlangen in Flask-Anwendungen und zur Migration zu Cloud Tasks.
Pull-Aufgaben
Wenn Sie den Dienst für Pull-Aufgaben der Aufgabenwarteschlange verwenden, z. B. um Aufgaben oder Nachrichten in die Warteschlange zu stellen, die von unterschiedlichen Workern verarbeitet werden sollen, Cloud Pub/Sub kann eine gute Alternative sein. Cloud Pub/Sub bietet ähnliche Funktionen und Zustellgarantien. Wie andere Cloud-Dienste, Pub/Sub bietet praktische Client Bibliotheken für den Zugriff auf den Dienst. Weitere Informationen finden Sie unter Pub/Sub-Nachrichten schreiben und beantworten und in der Migrationsanleitung Pull-Aufgaben für Aufgabenwarteschlangen zu Pub/Sub.
Wenn Sie diese Migration mit einer Beispielanwendung simulieren möchten, lesen Sie den Migrationsleitfaden zur Verwendung von App Engine-Pull-Aufgaben in einer Beispielanwendung und zur Migration zu Pub/Sub.
URL-Abruf
Standardmäßig verwendet die Python 2.7-Laufzeit den URL-Abrufdienst zur Verarbeitung ausgehender HTTP(S)-Anfragen, auch wenn Sie zur Verarbeitung dieser Anfragen Standard-Python-Bibliotheken verwenden.
Wenn Ihre Anwendung URL Fetch APIs direkt verwendet, z. B. für asynchrone Anfragen, empfehlen wir die Migration zu einer Standard-Python-Bibliothek z. B. zur Bibliothek "requests".
Weitere Informationen finden Sie unter Ausgehende Anfragen migrieren.
Nutzerauthentifizierung
Verwenden Sie als Alternative zur Users API einen der HTTP-basierten Authentifizierungs mechanismen, die auf der Nutzerauthentifizierung Seite beschrieben werden.