So verwenden Sie App Engine Blobstore (Modul 15)

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 zu Modul 15 wird erläutert, wie Sie die Verwendung von App Engine blobstore in die Beispiel-App aus Modul 0 einfügen. Anschließend können Sie diese Nutzung in Modul 16 auf Cloud Storage migrieren.

Lerninhalte

  • Verwendung der App Engine Blobstore API/Bibliothek hinzufügen
  • Nutzeruploads im Dienst blobstore speichern
  • Nächsten Schritt für die Migration zu Cloud Storage vorbereiten

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

Wenn Sie von der App Engine Blobstore API migrieren möchten, fügen Sie die Verwendung der API der vorhandenen App Engine-ndb-App aus Modul 0 hinzu. In der Beispiel-App werden die zehn letzten Besuche des Nutzers angezeigt. Wir ändern die App so, dass der Endnutzer aufgefordert wird, ein Artefakt (eine Datei) hochzuladen, das seinem „Besuch“ entspricht. Wenn der Nutzer das nicht möchte, kann er die Einrichtung überspringen. Unabhängig von der Entscheidung des Nutzers wird auf der nächsten Seite dieselbe Ausgabe wie in der App aus Modul 0 (und vielen anderen Modulen dieser Reihe) gerendert. Nachdem wir diese App Engine-blobstore-Integration implementiert haben, können wir sie im nächsten Codelab (Modul 16) zu Cloud Storage migrieren.

App Engine bietet Zugriff auf die Vorlagensysteme Django und Jinja2. Dieses Beispiel unterscheidet sich (abgesehen vom Blobstore-Zugriff) dadurch, dass hier in Modul 15 von Django in Modul 0 zu Jinja2 gewechselt wird. Ein wichtiger Schritt bei der Modernisierung von App Engine-Anwendungen ist die Migration von Web-Frameworks von webapp2 zu Flask. Für das Letztere wird Jinja2 als Standardvorlagensystem verwendet. Wir beginnen also, uns in diese Richtung zu bewegen, indem wir Jinja2 implementieren und gleichzeitig webapp2 für den Blobstore-Zugriff beibehalten. Da Flask standardmäßig Jinja2 verwendet, sind in Modul 16 keine Änderungen an der Vorlage erforderlich.

3. Einrichtung/Vorbereitung

Bevor wir zum Hauptteil des Tutorials kommen, richten Sie Ihr Projekt ein, rufen Sie den Code ab und stellen Sie die Baseline-App bereit, um mit funktionierendem Code zu beginnen.

1. Projekt einrichten

Wenn Sie die App aus Modul 0 bereits bereitgestellt haben, empfehlen wir, dass Sie dasselbe Projekt und denselben Code wiederverwenden. Alternativ können Sie ein neues Projekt erstellen oder ein anderes vorhandenes Projekt wiederverwenden. Prüfen Sie, ob das Projekt ein aktives Rechnungskonto hat und App Engine aktiviert ist.

2. Beispiel-App für die Baseline abrufen

Eine der Voraussetzungen für dieses Codelab ist, dass Sie eine funktionierende Beispiel-App für Modul 0 haben. Wenn Sie keine haben, können Sie sie aus dem Ordner „START“ für Modul 0 (Link unten) herunterladen. In diesem Codelab werden Sie durch jeden Schritt geführt. Am Ende erhalten Sie Code, der dem Code im Ordner „FINISH“ von Modul 15 ähnelt.

Das Verzeichnis der START-Dateien für Modul 0 sollte so aussehen:

$ ls
README.md               index.html
app.yaml                main.py

3. Referenz-App (erneut) bereitstellen

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

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

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

a7a9d2b80d706a2b.png

4. Konfigurationsdateien aktualisieren

app.yaml

An der Anwendungskonfiguration ändert sich nichts. Wie bereits erwähnt, wird jedoch von Django-Vorlagen (Standard) zu Jinja2 gewechselt. Um den Wechsel vorzunehmen, müssen Nutzer die neueste Version von Jinja2 angeben, die auf App Engine-Servern verfügbar ist. Dazu fügen Sie sie dem Abschnitt mit den integrierten Drittanbieterbibliotheken von app.yaml hinzu.

VORHER:

runtime: python27
threadsafe: yes
api_version: 1

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

Bearbeiten Sie die Datei app.yaml, indem Sie einen neuen Abschnitt libraries wie hier gezeigt hinzufügen:

DANACH:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: jinja2
  version: latest

Es müssen keine anderen Konfigurationsdateien aktualisiert werden. Fahren wir also mit den Anwendungsdateien fort.

5. Anwendungsdateien ändern

Importe und Jinja2-Unterstützung

Die erste Gruppe von Änderungen für main.py umfasst das Hinzufügen der Verwendung der Blobstore API und das Ersetzen von Django-Vorlagen durch Jinja2. Folgendes wird sich ändern:

  1. Das Modul os dient zum Erstellen eines Dateipfads zu einer Django-Vorlage. Da wir zu Jinja2 wechseln, wo dies gehandhabt wird, sind die Verwendung von os sowie des Django-Vorlagenrenderers google.appengine.ext.webapp.template nicht mehr erforderlich und werden daher entfernt.
  2. Importieren Sie die Blobstore API: google.appengine.ext.blobstore
  3. Importieren Sie die Blobstore-Handler aus dem ursprünglichen webapp-Framework. Sie sind in webapp2 nicht verfügbar: google.appengine.ext.webapp.blobstore_handlers
  4. Jinja2-Unterstützung aus dem Paket webapp2_extras importieren

VORHER:

import os
import webapp2
from google.appengine.ext import ndb
from google.appengine.ext.webapp import template

Implementieren Sie die Änderungen in der Liste oben, indem Sie den aktuellen Importbereich in main.py durch das folgende Code-Snippet ersetzen.

DANACH:

import webapp2
from webapp2_extras import jinja2
from google.appengine.ext import blobstore, ndb
from google.appengine.ext.webapp import blobstore_handlers

Fügen Sie nach den Importen etwas Boilerplate-Code hinzu, um die Verwendung von Jinja2 zu unterstützen, wie in der webapp2_extras-Dokumentation definiert. Das folgende Code-Snippet umschließt die Standard-Webapp2-Anfragehandler-Klasse mit Jinja2-Funktionen. Fügen Sie diesen Codeblock also in main.py direkt nach den Importen ein:

class BaseHandler(webapp2.RequestHandler):
    'Derived request handler mixing-in Jinja2 support'
    @webapp2.cached_property
    def jinja2(self):
        return jinja2.get_jinja2(app=self.app)

    def render_response(self, _template, **context):
        self.response.write(self.jinja2.render_template(_template, **context))

Blobstore-Unterstützung hinzufügen

Im Gegensatz zu anderen Migrationen in dieser Reihe, bei denen wir die Funktionalität oder Ausgabe der Beispiel-App identisch (oder nahezu identisch) beibehalten, ohne die Benutzeroberfläche (groß) zu ändern, weicht dieses Beispiel radikaler von der Norm ab. Anstatt einen neuen Besuch sofort zu registrieren und dann die zehn letzten Besuche anzuzeigen, wird der Nutzer in der aktualisierten App aufgefordert, ein Datei-Artefakt anzugeben, um seinen Besuch zu registrieren. Endnutzer können dann entweder eine entsprechende Datei hochladen oder „Überspringen“ auswählen, um nichts hochzuladen. Nach Abschluss dieses Schritts wird die Seite „Letzte Besuche“ angezeigt.

Durch diese Änderung kann unsere App den Blobstore-Dienst verwenden, um dieses Bild oder einen anderen Dateityp auf der Seite „Letzte Besuche“ zu speichern (und möglicherweise später zu rendern).

Datenmodell aktualisieren und verwenden

Wir speichern mehr Daten. Das Datenmodell wird aktualisiert, um die ID (BlobKey) der in Blobstore hochgeladenen Datei zu speichern, und es wird ein Verweis hinzugefügt, um diese in store_visit() zu speichern. Da diese zusätzlichen Daten bei der Abfrage zusammen mit allen anderen Daten zurückgegeben werden, bleibt fetch_visits() unverändert.

Hier sehen Sie die Vorher- und Nachher-Versionen mit diesen Updates mit file_blob, einem ndb.BlobKeyProperty:

VORHER:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

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)

DANACH:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)
    file_blob = ndb.BlobKeyProperty()

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

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

Hier eine bildliche Darstellung der bisher vorgenommenen Änderungen:

2270783776759f7f.png

Dateiuploads unterstützen

Die wichtigste Änderung der Funktionalität ist die Unterstützung von Dateiuploads, unabhängig davon, ob der Nutzer nach einer Datei gefragt wird, die Funktion „Überspringen“ unterstützt wird oder eine Datei entsprechend einem Besuch gerendert wird. Alles ist Teil des Bildes. Das sind die Änderungen, die für die Unterstützung von Dateiuploads erforderlich sind:

  1. Der Haupthandler GET ruft nicht mehr die letzten Besuche zur Anzeige ab. Stattdessen wird der Nutzer aufgefordert, etwas hochzuladen.
  2. Wenn ein Endnutzer eine Datei zum Hochladen einreicht oder diesen Vorgang überspringt, wird die Steuerung durch ein POST aus dem Formular an das neue UploadHandler übergeben, das von google.appengine.ext.webapp.blobstore_handlers.BlobstoreUploadHandler abgeleitet wird.
  3. Die POST-Methode von UploadHandler führt den Upload aus, ruft store_visit() auf, um den Besuch zu registrieren, und löst eine HTTP-307-Weiterleitung aus, um den Nutzer zurück zu „/“ zu senden, wo…
  4. Die POST-Methode des Haupthandlers fragt die letzten Besuche ab (über fetch_visits()) und zeigt sie an. Wenn der Nutzer „Überspringen“ auswählt, wird keine Datei hochgeladen, der Besuch wird aber trotzdem registriert und es erfolgt dieselbe Weiterleitung.
  5. Die Anzeige der letzten Besuche enthält ein neues Feld, das dem Nutzer angezeigt wird: entweder ein verlinkter „Aufruf“, wenn eine Upload-Datei verfügbar ist, oder „Keine“. Diese Änderungen werden in der HTML-Vorlage umgesetzt. Außerdem wird ein Uploadformular hinzugefügt (weitere Informationen folgen in Kürze).
  6. Wenn ein Endnutzer auf den Link „Ansehen“ für einen Besuch mit einem hochgeladenen Video klickt, wird eine GET-Anfrage an eine neue ViewBlobHandler gesendet, die von google.appengine.ext.webapp.blobstore_handlers.BlobstoreDownloadHandler abgeleitet wird. Die Datei wird entweder gerendert, wenn es sich um ein Bild handelt (im Browser, sofern unterstützt), oder es wird zum Herunterladen aufgefordert, wenn dies nicht der Fall ist. Wenn die Datei nicht gefunden wird, wird ein HTTP-404-Fehler zurückgegeben.
  7. Zusätzlich zu den neuen Handler-Klassen und den neuen Routen, über die Traffic an sie gesendet wird, benötigt der Haupthandler eine neue POST-Methode, um die oben beschriebene 307-Weiterleitung zu empfangen.

Vor diesen Updates enthielt die App für Modul 0 nur einen Haupthandler mit der Methode GET und einer einzelnen Route:

VORHER:

class MainHandler(webapp2.RequestHandler):
    'main application (GET) handler'
    def get(self):
        store_visit(self.request.remote_addr, self.request.user_agent)
        visits = fetch_visits(10)
        tmpl = os.path.join(os.path.dirname(__file__), 'index.html')
        self.response.out.write(template.render(tmpl, {'visits': visits}))

app = webapp2.WSGIApplication([
    ('/', MainHandler),
], debug=True)

Nach diesen Aktualisierungen gibt es jetzt drei Handler: 1) den Upload-Handler mit einer POST-Methode, 2) den Download-Handler „Blob ansehen“ mit einer GET-Methode und 3) den Haupt-Handler mit GET- und POST-Methoden. Nehmen Sie diese Änderungen vor, damit der Rest Ihrer App jetzt so aussieht wie unten.

DANACH:

class UploadHandler(blobstore_handlers.BlobstoreUploadHandler):
    'Upload blob (POST) handler'
    def post(self):
        uploads = self.get_uploads()
        blob_id = uploads[0].key() if uploads else None
        store_visit(self.request.remote_addr, self.request.user_agent, blob_id)
        self.redirect('/', code=307)

class ViewBlobHandler(blobstore_handlers.BlobstoreDownloadHandler):
    'view uploaded blob (GET) handler'
    def get(self, blob_key):
        self.send_blob(blob_key) if blobstore.get(blob_key) else self.error(404)

class MainHandler(BaseHandler):
    'main application (GET/POST) handler'
    def get(self):
        self.render_response('index.html',
                upload_url=blobstore.create_upload_url('/upload'))

    def post(self):
        visits = fetch_visits(10)
        self.render_response('index.html', visits=visits)

app = webapp2.WSGIApplication([
    ('/', MainHandler),
    ('/upload', UploadHandler),
    ('/view/([^/]+)?', ViewBlobHandler),
], debug=True)

Dieser Code enthält mehrere wichtige Aufrufe:

  • In MainHandler.get gibt es einen Aufruf von blobstore.create_upload_url. Mit diesem Aufruf wird die URL generiert, an die das Formular POST wird. Dabei wird der Upload-Handler aufgerufen, um die Datei an Blobstore zu senden.
  • In UploadHandler.post gibt es einen Aufruf von blobstore_handlers.BlobstoreUploadHandler.get_uploads. Das ist der eigentliche Vorgang, bei dem die Datei in Blobstore gespeichert und eine eindeutige und dauerhafte ID für diese Datei zurückgegeben wird, die BlobKey.
  • Wenn in ViewBlobHandler.get blobstore_handlers.BlobstoreDownloadHandler.send mit dem BlobKey einer Datei aufgerufen wird, wird die Datei abgerufen und an den Browser des Endnutzers weitergeleitet.

Diese Aufrufe machen den Großteil des Zugriffs auf die Funktionen aus, die der App hinzugefügt wurden. Hier sehen Sie eine bildliche Darstellung dieser zweiten und letzten Änderungen an main.py:

da2960525ac1b90d.png

HTML-Vorlage aktualisieren

Einige der Aktualisierungen der Hauptanwendung wirken sich auf die Benutzeroberfläche der App aus. Daher sind entsprechende Änderungen an der Webvorlage erforderlich, genauer gesagt zwei:

  1. Ein Formular zum Hochladen von Dateien ist mit drei Eingabeelementen erforderlich: einer Datei und zwei Schaltflächen zum Senden für das Hochladen von Dateien bzw. zum Überspringen.
  2. Aktualisieren Sie die Ausgabe der letzten Besuche, indem Sie einen Link zum Aufrufen für Besuche mit einem entsprechenden Dateiupload hinzufügen oder „none“ (kein) angeben, falls nicht zutreffend.

VORHER:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

</body>
</html>

Nehmen Sie die oben aufgeführten Änderungen vor, um die aktualisierte Vorlage zu erstellen:

DANACH:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
{% if upload_url %}

<h3>Welcome... upload a file? (optional)</h3>
<form action="{{ upload_url }}" method="POST" enctype="multipart/form-data">
    <input type="file" name="file"><p></p>
    <input type="submit"> <input type="submit" value="Skip">
</form>

{% else %}

<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
<li>{{ visit.timestamp.ctime() }}
    <i><code>
    {% if visit.file_blob %}
        (<a href="/view/{{ visit.file_blob }}" target="_blank">view</a>)
    {% else %}
        (none)
    {% endif %}
    </code></i>
    from {{ visit.visitor }}
</li>
{% endfor %}
</ul>

{% endif %}

</body>
</html>

Dieses Bild veranschaulicht die erforderlichen Aktualisierungen von index.html:

8583e975f25aa9e7.png

Eine letzte Änderung besteht darin, dass Jinja2 seine Vorlagen in einem Ordner templates bevorzugt. Erstellen Sie diesen Ordner und verschieben Sie index.html hinein. Damit haben Sie alle erforderlichen Änderungen vorgenommen, um die Verwendung von Blobstore in die Beispiel-App aus Modul 0 aufzunehmen.

(Optional) Cloud Storage-„Optimierung“

Blobstore-Speicher wurde schließlich zu Cloud Storage weiterentwickelt. Das bedeutet, dass Blobstore-Uploads in der Cloud Console, insbesondere im Cloud Storage-Browser, sichtbar sind. Die Frage ist nur, wo. Die Antwort ist der Cloud Storage-Standard-Bucket Ihrer App Engine-Anwendung. Der Name ist der vollständige Domainname Ihrer App Engine-App, PROJECT_ID.appspot.com. Das ist so praktisch, weil alle Projekt-IDs eindeutig sind, oder?

Durch die Aktualisierungen der Beispielanwendung werden hochgeladene Dateien in diesem Bucket abgelegt. Entwickler haben jedoch die Möglichkeit, einen genaueren Speicherort auszuwählen. Auf den Standard-Bucket kann programmatisch über google.appengine.api.app_identity.get_default_gcs_bucket_name() zugegriffen werden. Wenn Sie auf diesen Wert zugreifen möchten, z. B. um ihn als Präfix zum Organisieren hochgeladener Dateien zu verwenden, ist ein neuer Import erforderlich. Beispiel: Sortieren nach Dateityp:

f61f7a23a1518705.png

Wenn Sie so etwas beispielsweise für Bilder implementieren möchten, benötigen Sie Code wie diesen sowie Code, mit dem Dateitypen geprüft werden, um den gewünschten Bucket-Namen auszuwählen:

ROOT_BUCKET = app_identity.get_default_gcs_bucket_name()
IMAGE_BUCKET = '%s/%s' % (ROOT_BUCKET, 'images')

Sie validieren die hochgeladenen Bilder auch mit einem Tool wie dem imghdr-Modul der Python-Standardbibliothek, um den Bildtyp zu bestätigen. Schließlich sollten Sie wahrscheinlich die Größe von Uploads begrenzen, um böswillige Nutzer abzuschrecken.

Nehmen wir an, das ist alles erledigt. Wie können wir unsere App aktualisieren, damit angegeben werden kann, wo die hochgeladenen Dateien gespeichert werden sollen? Der Schlüssel liegt darin, den Aufruf von blobstore.create_upload_url in MainHandler.get anzupassen, um den gewünschten Speicherort in Cloud Storage für den Upload anzugeben. Fügen Sie dazu den Parameter gs_bucket_name so hinzu:

blobstore.create_upload_url('/upload', gs_bucket_name=IMAGE_BUCKET))

Da es sich um ein optionales Update handelt, mit dem Sie festlegen können, wohin Uploads erfolgen sollen, ist es nicht Teil der Datei main.py im Repository. Stattdessen steht im Repository eine Alternative namens main-gcs.py zur Überprüfung bereit. Anstatt einen separaten Bucket-„Ordner“ zu verwenden, werden Uploads mit dem Code in main-gcs.py im „Root“-Bucket (PROJECT_ID.appspot.com) gespeichert, genau wie bei main.py. Allerdings bietet main-gcs.py die erforderliche Infrastruktur, wenn Sie das Beispiel in etwas anderes umwandeln möchten, wie in diesem Abschnitt angedeutet. Unten sehen Sie eine Abbildung der Unterschiede zwischen main.py und main-gcs.py.

256e1ea68241a501.png

6. Zusammenfassung/Bereinigung

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

Anwendung bereitstellen und überprüfen

Stellen Sie Ihre App mit gcloud app deploy noch einmal bereit und prüfen Sie, ob sie wie beworben funktioniert und sich in der Nutzererfahrung (UX) von der App aus Modul 0 unterscheidet. Ihre App hat jetzt zwei verschiedene Bildschirme. Der erste ist die Aufforderung zum Hochladen des Besuchsdateiformulars:

f5b5f9f19d8ae978.pngDort können Endnutzer entweder eine Datei hochladen und auf „Senden“ klicken oder auf „Überspringen“ klicken, um nichts hochzuladen. In beiden Fällen wird der Bildschirm des letzten Besuchs angezeigt, der jetzt zwischen den Zeitstempeln der Besuche und den Besucherinformationen mit „Ansehen“-Links oder „Keine“ ergänzt wurde:

f5ac6b98ee8a34cb.png

Herzlichen Glückwunsch! Sie haben dieses Codelab abgeschlossen und der Beispiel-App aus Modul 0 die Verwendung von App Engine Blobstore hinzugefügt. Ihr Code sollte jetzt mit dem Code im FINISH (Module 15) folder übereinstimmen. Die alternative Datei main-gcs.py ist ebenfalls in diesem Ordner vorhanden.

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:

Nächste Schritte

Die nächste logische Migration wird in Modul 16 behandelt. Dort wird Entwicklern gezeigt, wie sie vom App Engine Blobstore-Dienst zur Cloud Storage-Clientbibliothek migrieren. Zu den Vorteilen eines Upgrades gehört der Zugriff auf weitere Cloud Storage-Funktionen und die Möglichkeit, sich mit einer Clientbibliothek vertraut zu machen, die für Apps außerhalb von App Engine funktioniert, unabhängig davon, ob sie in Google Cloud, in anderen Clouds oder sogar lokal gehostet werden. Wenn Sie nicht alle Funktionen von Cloud Storage benötigen oder sich Sorgen über die Auswirkungen auf die Kosten machen, können Sie App Engine Blobstore weiterhin verwenden.

Über Modul 16 hinaus gibt es eine Vielzahl weiterer möglicher Migrationen, z. B. Cloud NDB und Cloud Datastore, Cloud Tasks oder Cloud Memorystore. Es gibt auch produktübergreifende Migrationen zu Cloud Run und Cloud Functions. Im Migrations-Repository finden Sie alle Codebeispiele und Links zu allen verfügbaren Codelabs und Videos. Außerdem wird erläutert, welche Migrationen infrage kommen und welche Reihenfolge bei der Migration zu beachten ist.

7. Zusätzliche Ressourcen

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 0 (START) und Modul 15 (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 0

code

–

Modul 15 (dieses Codelab)

code

–

Onlineressourcen

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

App Engine

Google Cloud

Python

Videos

Lizenz

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