Jak korzystać z biblioteki blobstore w App Engine (moduł 15)

1. Omówienie

Seria ćwiczeń z programowania dla bezserwerowych stacji migracji (samouczek, samouczków) i podobnych filmów ma pomóc deweloperom bezserwerowych Google Cloud w modernizacji aplikacji przez przeprowadzenie co najmniej 1 migracji, w wyniku rezygnacji ze starszych usług. W ten sposób Twoje aplikacje stają się bardziej przenośne, mają więcej opcji i elastyczność, co pozwala na integrację z szerszą gamą usług Cloud i uzyskiwanie do nich dostępu, a także łatwiejsze przejście na nowsze wersje językowe. Choć początkowo koncentrowaliśmy się na pierwszych użytkownikach Cloud, głównie deweloperów korzystających ze środowiska App Engine (środowisko standardowe), ta seria jest na tyle szeroka, aby uwzględnić inne platformy bezserwerowe, takie jak Cloud Functions i Cloud Run, oraz inne, w stosownych przypadkach.

W tym ćwiczeniu z programowania w części 15 wyjaśniamy, jak dodać wykorzystanie App Engine blobstore do przykładowej aplikacji z modułu 0. Gdy to zrobisz, w module 16 możesz przejść do migracji tych danych do Cloud Storage.

Dowiesz się, jak:

  • Dodaj sposób korzystania z interfejsu API/biblioteki App Engine Blobstore
  • Przechowuj w usłudze blobstore przesłane przez użytkowników pliki
  • Przygotowanie do następnego kroku migracji do Cloud Storage

Czego potrzebujesz

Ankieta

Jak wykorzystasz ten samouczek?

Tylko do przeczytania Przeczytaj go i wykonaj ćwiczenia

Jak oceniasz swoje doświadczenia z językiem Python?

Początkujący Poziom średnio zaawansowany Biegły

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Poziom średnio zaawansowany Biegły .

2. Tło

Aby przeprowadzić migrację z interfejsu App Engine Blobstore API, dodaj dane o korzystaniu z tej funkcji do dotychczasowej bazowej aplikacji App Engine ndb z modułu 0. Przykładowa aplikacja wyświetla 10 ostatnich wizyt użytkownika. Modyfikujemy aplikację, aby poprosić użytkownika o przesłanie artefaktu (pliku) powiązanego z jego „wizytą”. Jeśli użytkownik nie chce tego robić, dostępny jest przycisk „pomiń”. . Niezależnie od decyzji użytkownika następna strona renderuje te same dane wyjściowe co aplikacja z Modułu 0 (i wielu innych modułów z tej serii). Dzięki wdrożeniu integracji z App Engine blobstore możemy przenieść tę usługę do Cloud Storage w ramach kolejnego ćwiczenia z programowania (Moduł 16).

App Engine zapewnia dostęp do systemów szablonów Django i Jinja2. Różnica polega na tym, że ten przykład (oprócz dostępu do Blobstore) przełącza się z Django w module 0 na Jinja2 w module 15. Kluczowym krokiem w modernizacji aplikacji App Engine jest przeniesienie platform internetowych z webapp2 do Flask. W tym drugim przypadku używany jest Jinja2 jako domyślny system szablonów, więc zaczynamy pójść w tym kierunku, implementując Jinja2, zachowując dostęp do Blobstore na poziomie webapp2. Ponieważ Flask domyślnie korzysta z Jinja2, w części 16 nie będą wymagane żadne zmiany w szablonie.

3. Konfiguracja/praca

Zanim przejdziemy do głównej części samouczka, skonfiguruj projekt, pobierz kod i wdróż aplikację bazową, aby zacząć od działającego kodu.

1. Konfigurowanie projektu

Jeśli aplikacja modułu 0 została już wdrożona, zalecamy ponowne użycie tego samego projektu (i kodu). Możesz też utworzyć nowy projekt lub wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe i jest włączona usługa App Engine.

2. Pobierz przykładową aplikację bazową

Jednym z warunków wstępnych tego ćwiczenia z programowania jest posiadanie działającej przykładowej aplikacji w module 0. Jeśli go nie masz, możesz go pobrać w module 0 „START” (link poniżej). To ćwiczenie w Codelabs przeprowadzi Cię przez poszczególne kroki, kończąc kodem przypominającym to, co znajduje się w module 15 „FINISH”. folderu Dysku.

Katalog plików START z modułem 0 powinien wyglądać tak:

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

3. (Ponowne) wdrażanie aplikacji podstawowej

Pozostałe kroki do wykonania:

  1. Ponownie zapoznaj się z narzędziem wiersza poleceń gcloud
  2. Wdróż ponownie przykładową aplikację za pomocą gcloud app deploy
  3. Sprawdź, czy aplikacja działa w App Engine bez problemów

Po wykonaniu tych czynności i sprawdzeniu, że aplikacja internetowa działa (z danymi wyjściowymi podobnymi do widocznych poniżej), możesz dodać do niej funkcję zapisywania w pamięci podręcznej.

a7a9d2b80d706a2b.png

4. Aktualizowanie plików konfiguracji

app.yaml

Nie wprowadziliśmy istotnych zmian w konfiguracji aplikacji, ale jak już wspomnieliśmy, przechodzimy z szablonów Django (domyślnego) na Jinja2. Aby przejść na nową wersję, użytkownicy powinni wybrać najnowszą wersję Jinja2 dostępną na serwerach App Engine. W tym celu dodaj ją do sekcji z wbudowanymi bibliotekami innych firm w app.yaml.

PRZED:

runtime: python27
threadsafe: yes
api_version: 1

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

Edytuj plik app.yaml, dodając nową sekcję libraries taką jak tutaj:

PO:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: jinja2
  version: latest

Żadne inne pliki konfiguracji nie wymagają aktualizacji, więc przejdźmy do plików aplikacji.

5. Modyfikowanie plików aplikacji

Importy i obsługa Jinja2

Pierwszy zestaw zmian w interfejsie main.py obejmuje dodanie interfejsu Blobstore API i zastąpienie szablonów Django przez Jinja2. Co się zmienia:

  1. Moduł os służy do utworzenia nazwy ścieżki pliku do szablonu Django. Przechodzimy na Jinja2, gdzie ten proces jest obsługiwany, więc korzystanie z interfejsu os oraz mechanizmu renderowania szablonu Django (google.appengine.ext.webapp.template) nie są już potrzebne, dlatego je usuniemy.
  2. Zaimportuj interfejs Blobstore API: google.appengine.ext.blobstore
  3. Zaimportuj moduły obsługi Blobstore znalezione w pierwotnej platformie webapp – są one niedostępne w webapp2: google.appengine.ext.webapp.blobstore_handlers
  4. Importuj obsługę Jinja2 z pakietu webapp2_extras

PRZED:

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

Wprowadź zmiany z powyższej listy, zastępując bieżącą sekcję importowania w interfejsie main.py poniższym fragmentem kodu.

PO:

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

Po zaimportowaniu dodaj stały kod, aby obsługiwać użycie Jinja2 zgodnie z definicją w dokumentacji webapp2_extras. Poniższy fragment kodu opakowuje standardową klasę obsługi żądań Webapp2 z funkcją Jinja2, więc dodaj ten blok kodu do main.py zaraz po zaimportowaniu:

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

Dodawanie obsługi Blobstore

W odróżnieniu od innych migracji w tej serii, w których funkcje lub dane wyjściowe przykładowej aplikacji są identyczne (bądź prawie takie same) bez (znacznych) zmian w interfejsie użytkownika, w tym przykładzie mamy do czynienia z bardziej radykalnym odejściem od normy. Zamiast natychmiast rejestrować nową wizytę i wyświetlać ostatnie 10 z nich, aktualizujemy aplikację, więc prosimy użytkownika o podanie artefaktu pliku, w którym będzie on mógł zarejestrować wizytę. Użytkownicy mogą przesłać odpowiedni plik lub wybrać „Pomiń” aby wcale nie przesyłać niczego. Po zakończeniu tego kroku sekcja „Ostatnie wizyty”

Ta zmiana umożliwi naszej aplikacji wykorzystanie usługi Blobstore do przechowywania (i ewentualnego renderowania) tego obrazu lub innego typu plików na stronie ostatniej wizyty.

Zaktualizuj model danych i wdróż jego zastosowanie

Przechowujemy więcej danych, a w szczególności aktualizujemy model danych, aby przechowywał identyfikator (nazywany „BlobKey”) pliku przesłanego do Blobstore i dodaliśmy odwołanie pozwalające zapisać ten identyfikator w store_visit(). Te dodatkowe dane są zwracane wraz ze wszystkimi pozostałymi danymi w odpowiedzi na zapytanie, więc parametr fetch_visits() pozostaje bez zmian.

Oto wydarzenia przed i po, które pochodzą z najnowszych źródeł, takich jak file_blob (ndb.BlobKeyProperty):

PRZED:

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)

PO:

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)

Oto obrazowe przedstawienie wprowadzonych do tej pory zmian:

2270783776759f7f.png

Obsługa przesyłania plików

Największą zmianą w funkcjonalności jest obsługa przesyłania plików, niezależnie od tego, czy użytkownik prosi o jej pobranie, czy „pominąć”. lub renderowanie pliku odpowiadającego wizycie. To wszystko jest częścią obrazu. Oto zmiany wymagane do obsługi przesyłania plików:

  1. Żądanie głównego modułu obsługi GET nie pobiera już do wyświetlenia ostatnich wizyt. Zamiast tego wyświetla użytkownikowi prośbę o przesłanie pliku.
  2. Gdy użytkownik prześle plik do przesłania lub pominie ten proces, pole POST z formularza przekazuje kontrolę do nowego elementu UploadHandler utworzonego na podstawie google.appengine.ext.webapp.blobstore_handlers.BlobstoreUploadHandler.
  3. Metoda POST w UploadHandler przeprowadza przesyłanie, wywołuje metodę store_visit() w celu zarejestrowania wizyty i wywołuje przekierowanie HTTP 307, które kieruje użytkownika z powrotem do strony „/”, gdzie...
  4. Metoda POST głównego modułu obsługi zapytania (za pomocą fetch_visits()) i wyświetla ostatnie wizyty. Jeśli użytkownik wybierze „pomiń”, nie został przesłany żaden plik, ale wizyta zostaje zarejestrowana, po czym następuje to samo przekierowanie.
  5. Widok ostatnich wizyt zawiera nowe pole wyświetlane użytkownikowi: hiperlink do listy „widoku” jeśli przesyłany plik jest dostępny lub wartość „brak” w przeciwnym razie. Te zmiany są wprowadzane w szablonie HTML wraz z formularzem przesyłania (więcej informacji na ten temat wkrótce).
  6. Jeśli użytkownik kliknie przycisk „Wyświetl” w przypadku każdej wizyty z przesłanym filmem, wysyła żądanie GET do nowego elementu ViewBlobHandler utworzonego na podstawie google.appengine.ext.webapp.blobstore_handlers.BlobstoreDownloadHandler. W przeciwnym razie plik jest renderowany z obrazem (w przeglądarce, jeśli jest obsługiwany), wyświetla w razie potrzeby żądanie pobrania pliku lub zwraca błąd HTTP 404, jeśli nie znaleziono go.
  7. Oprócz nowej pary klas modułów obsługi oraz nowej pary tras do wysyłania ruchu do nich główny moduł obsługi wymaga nowej metody POST w celu otrzymania opisanego powyżej przekierowania 307.

Wcześniej aplikacja modułu 0 zawierała tylko główny moduł obsługi z metodą GET i jedną trasą:

PRZED:

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)

Po wdrożeniu tych aktualizacji dostępne są teraz 3 moduły obsługi: 1) moduł obsługi przesyłania z metodą POST, 2) „wyświetl obiekt blob”. moduł obsługi pobierania z metodą GET oraz 3) główny moduł obsługi z metodami GET i POST. Wprowadź te zmiany, aby reszta aplikacji wyglądała tak, jak pokazano poniżej.

PO:

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)

W tym kodzie, które właśnie dodaliśmy, jest kilka kluczowych wywołań:

  • Za MainHandler.get połączenie z numerem blobstore.create_upload_url. To wywołanie generuje adres URL formularza POST, wywołując moduł obsługi przesyłania w celu wysłania pliku do Blobstore.
  • Za UploadHandler.post połączenie z numerem blobstore_handlers.BlobstoreUploadHandler.get_uploads. Na tym polega magia polegająca na umieszczeniu pliku w Blobstore i zwracaniu unikalnego, trwałego identyfikatora tego pliku – BlobKey.
  • W ViewBlobHandler.get wywołanie blobstore_handlers.BlobstoreDownloadHandler.send za pomocą funkcji BlobKey pliku powoduje pobranie pliku i przekazanie go do przeglądarki użytkownika

Połączenia te odpowiadają za większość korzystania z funkcji dodanych do aplikacji. Oto obrazowe przedstawienie tego drugiego i ostatniego zestawu zmian w elemencie main.py:

da2960525ac1b90d.png

Aktualizacja szablonu HTML

Niektóre aktualizacje głównej aplikacji wpływają na jej interfejs użytkownika, dlatego w szablonie internetowym musisz wprowadzić odpowiednie zmiany:

  1. Formularz przesyłania pliku jest wymagany z 3 elementami do wprowadzania danych: odpowiednio plikiem i 2 przyciskami przesyłania służącymi do przesyłania pliku i pomijaniu.
  2. Zaktualizuj dane wyjściowe dotyczące ostatnich wizyt, dodając „widok” link do wizyt z odpowiednim przesłaniem pliku lub „brak” w przeciwnym razie.

PRZED:

<!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>

Aby utworzyć zaktualizowany szablon, wprowadź zmiany z powyższej listy:

PO:

<!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>

Ten obraz przedstawia wymagane aktualizacje index.html:

8583e975f25aa9e7.png

Ostatnia zmiana polega na tym, że Jinja2 preferuje swoje szablony w folderze templates, więc utwórz ten folder i przenieś do niego index.html. To już koniec wszystkich zmian niezbędnych do dodania Blobstore do przykładowej aplikacji w module 0.

(Opcjonalnie) Ulepszenie Cloud Storage

Pamięć masowa Blobstore przekształciła się w samą usługę Cloud Storage. Oznacza to, że dane przesłane do Blobstore są widoczne w konsoli Cloud, a w szczególności w przeglądarce Cloud Storage. Pytanie „gdzie?”. Odpowiedź to domyślny zasobnik Cloud Storage Twojej aplikacji App Engine. Jej nazwa to pełna nazwa domeny Twojej aplikacji App Engine – PROJECT_ID.appspot.com. To takie wygodne, bo wszystkie identyfikatory projektów są unikalne.

Aktualizacje przykładowej aplikacji usuwają przesłane pliki do tego zasobnika, ale deweloperzy mają możliwość wybrania bardziej szczegółowej lokalizacji. Domyślny zasobnik można uzyskać programowo w usłudze google.appengine.api.app_identity.get_default_gcs_bucket_name(), dlatego jeśli chcesz uzyskać dostęp do tej wartości, musisz utworzyć nowy import, na przykład aby użyć go jako prefiksu do porządkowania przesłanych plików. Na przykład sortowanie według typu pliku:

f61f7a23a1518705.png

Aby zastosować na przykład taki kod w przypadku obrazów, potrzebujesz kodu podobnego do tego i kodu, który sprawdza typy plików w celu wybrania żądanej nazwy zasobnika:

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

Możesz też zweryfikować przesłane obrazy za pomocą narzędzia takiego jak moduł imghdr biblioteki standardowej w języku Python, aby potwierdzić typ obrazu. Warto też ograniczyć rozmiar przesyłanych plików na wypadek nieuczciwych podmiotów.

Powiedzmy, że to wszystko, co udało Ci się osiągnąć. Jak zaktualizować aplikację, aby umożliwić określenie, gdzie mają być przechowywane przesłane pliki? Kluczem jest dostosowanie wywołania funkcji blobstore.create_upload_url w obiekcie MainHandler.get, aby określić żądaną lokalizację w Cloud Storage do przesłania, dodając parametr gs_bucket_name w następujący sposób:

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

Ta aktualizacja jest opcjonalna, jeśli chcesz określić, gdzie mają zostać przesłane pliki, dlatego nie jest ona częścią pliku main.py w repozytorium. Zamiast tego w repozytorium będzie dostępna wersja alternatywna o nazwie main-gcs.py. Zamiast używać osobnego „folderu” zasobnika, kod w main-gcs.py przechowuje przesłane pliki w „katalogu głównym” (PROJECT_ID.appspot.com) tak jak main.py, ale zapewnia rusztowanie potrzebne w przypadku uzyskania z próbki czegoś, co jest bardziej sugerowane w tej sekcji. Poniżej znajduje się ilustracja „różnic” od main.py do main-gcs.py.

256e1ea68241a501.png

6. Podsumowanie/Czyszczenie

W tej sekcji znajdziesz podsumowanie tego ćwiczenia w programie przez wdrożenie aplikacji oraz sprawdzenie, czy działa ona zgodnie z oczekiwaniami i we wszystkich uwzględnionych danych wyjściowych. Po sprawdzeniu aplikacji wykonaj czynności związane z czyszczeniem i zastanów się nad dalszymi czynnościami.

Wdróż i zweryfikuj aplikację

Wdróż ponownie aplikację za pomocą narzędzia gcloud app deploy i sprawdź, czy działa zgodnie z reklamami, co zmienia się w zależności od wygody użytkowników (UX) aplikacji w porównaniu z aplikacją z modułu 0. Aplikacja zawiera teraz dwa różne ekrany. Pierwszy z nich to prompt z prośbą o przesłanie pliku z formularzem wizyty:

f5b5f9f19d8ae978.pngNastępnie użytkownicy przesyłają plik i klikają „Prześlij”. lub kliknij „Pomiń” aby niczego nie przesyłać. W obu przypadkach wynikiem jest ekran ostatniej wizyty uzupełniony o opcję „widok”. linki lub „brak” między sygnaturami czasowymi wizyt a informacjami o użytkownikach:

f5ac6b98ee8a34cb.png

Gratulujemy ukończenia tego ćwiczenia z programowania i dodania wykorzystania App Engine Blobstore do przykładowej aplikacji w module 0. Twój kod powinien być teraz zgodny z plikiem w folderze FINISH (Module 15). W tym folderze znajduje się również alternatywna wersja main-gcs.py.

Czyszczenie danych

Ogólne

Jeśli na razie wszystko jest gotowe, wyłącz aplikację App Engine, aby uniknąć naliczania opłat. Jeśli jednak chcesz jeszcze bardziej przetestować lub poeksperymentować, platforma App Engine ma bezpłatny limit. Dopóki nie przekroczysz tego limitu, nie pobierzemy żadnych opłat. Oznacza to obliczenia, ale mogą być też naliczane opłaty za odpowiednie usługi App Engine. Więcej informacji znajdziesz na stronie z cennikiem. Jeśli ta migracja obejmuje inne usługi Cloud, są one rozliczane osobno. W obu przypadkach zapoznaj się z sekcją „Zapoznaj się z tymi ćwiczeniami”. sekcji poniżej.

Aby w pełni wyjaśnić wszystkie kwestie, wdrożenie na bezserwerowej platformie obliczeniowej Google Cloud, takiej jak App Engine, wiąże się z niewielkimi kosztami kompilacji i przechowywania danych. Cloud Build ma własny bezpłatny limit, podobnie jak Cloud Storage. Przechowywanie tego obrazu wykorzystuje część tego limitu. Możesz jednak mieszkać w regionie, w którym nie ma takiego poziomu bezpłatnego. Dlatego pamiętaj o wykorzystaniu miejsca na dane, aby zminimalizować potencjalne koszty. Określone „foldery” Cloud Storage należy sprawdzić m.in.:

  • 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
  • Powyższe linki do miejsca na dane zależą od Twoich danych PROJECT_ID oraz *LOC*, np. „us” jeśli aplikacja jest hostowana w Stanach Zjednoczonych.

Jeśli natomiast nie zamierzasz dalej korzystać z tej aplikacji lub innych powiązanych z nią ćwiczeń w Codelabs i chcesz całkowicie usunąć wszystko, zamknij projekt.

Powiązane z tym ćwiczeniam z programowania

Wymienione poniżej usługi są dostępne tylko w ramach tego ćwiczenia z programowania. Więcej informacji znajdziesz w dokumentacji poszczególnych usług:

Dalsze kroki

Kolejną migrację logiczną, którą należy rozważyć, omawiamy w module 16, w którym programiści mogą zobaczyć, jak przejść z usługi App Engine Blobstore na korzystanie z biblioteki klienta Cloud Storage. Korzyści z przejścia na wyższą wersję obejmują dostęp do większej liczby funkcji Cloud Storage oraz zapoznanie się z biblioteką klienta, która działa w przypadku aplikacji spoza App Engine, zarówno w Google Cloud, innych chmurach, jak i lokalnych. Jeśli uważasz, że nie potrzebujesz wszystkich funkcji dostępnych w Cloud Storage lub obawiasz się, jak wpłynie to na koszty, możesz pozostać przy App Engine Blobstore.

Poza modułem 16 jest mnóstwo innych możliwych migracji, takich jak Cloud NDB i Cloud Datastore, Cloud Tasks czy Cloud Memorystore. Dostępne są też migracje z różnych usług do Cloud Run i Cloud Functions. Repozytorium migracji zawiera wszystkie przykłady kodu oraz linki do wszystkich dostępnych ćwiczeń z programowania i filmów, a także wskazówki dotyczące migracji, które warto rozważyć, i wszelkie odpowiednie „zamówienia”. migracji danych.

7. Dodatkowe materiały

Problemy z ćwiczeniami w Codelabs/opinie

Jeśli podczas korzystania z tych ćwiczeń z programowania zauważysz jakiekolwiek problemy, najpierw je wyszukaj. Linki do wyszukiwania i tworzenia nowych problemów:

Zasoby migracji

Linki do folderów repozytorium w modułach 0 (START) i modułach 15 (FINISH) znajdziesz w tabeli poniżej. Dostęp do nich możesz też uzyskać z repozytorium wszystkich migracji z ćwiczeń z programowania App Engine, które możesz sklonować lub pobrać w postaci pliku ZIP.

Codelab

Python 2

Python 3

Część 0.

kod

Nie dotyczy

Moduł 15 (to ćwiczenie z programowania)

kod

Nie dotyczy

Zasoby online

Poniżej znajdują się zasoby online, które mogą być pomocne w przypadku tego samouczka:

App Engine

Google Cloud

Python

Filmy

Licencja

To zadanie jest licencjonowane na podstawie ogólnej licencji Creative Commons Attribution 2.0.