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

1. Przegląd

Seria codelabów Serverless Migration Station (samodzielne, praktyczne samouczki) i powiązane z nimi filmy mają na celu pomóc deweloperom usług bezserwerowych Google Cloud w modernizacji aplikacji poprzez przeprowadzenie ich przez co najmniej jedną migrację, głównie z usług starszego typu. Dzięki temu Twoje aplikacje będą bardziej przenośne, a Ty zyskasz więcej opcji i elastyczności, co umożliwi Ci integrację z szerszą gamą usług w chmurze i łatwiejsze przechodzenie na nowsze wersje języka. Chociaż początkowo skupialiśmy się na pierwszych użytkownikach usług w chmurze, głównie na deweloperach App Engine (środowisko standardowe), ta seria jest wystarczająco szeroka, aby obejmować inne platformy bezserwerowe, takie jak Cloud Functions i Cloud Run, lub inne, jeśli ma to zastosowanie.

W ramach tych ćwiczeń z programowania (moduł 15) dowiesz się, jak dodać do przykładowej aplikacji z modułu 0 informacje o użyciu App Engineblobstore. Następnie w module 16 możesz przenieść to wykorzystanie do Cloud Storage.

Nie używasz Blobstore?

Jeśli Twoja aplikacja nie korzysta z usługi Blobstore App Engine, pomiń moduły 15–16 lub wykonaj te ćwiczenia z programowania, aby zapoznać się z migracją Blobstore.

Korzystasz z niestandardowej biblioteki klienta App Engine Cloud Storage?

Jeśli Twoja aplikacja korzysta z niestandardowej biblioteki klienta App Engine dla Cloud Storage (GoogleAppEngineCloudStorageClient lub cloudstorage), zalecamy też przejście na biblioteki klienta Cloud Storage. Taka migracja wykracza poza zakres tego samouczka i nie jest w nim omawiana. Ogólne instrukcje znajdziesz na stronie migracji Cloud Storage.

Dowiesz się, jak:

• Dodawanie korzystania z interfejsu API/biblioteki Blobstore App Engine
• Przechowywanie plików przesyłanych przez użytkowników w usłudze blobstore
• Przygotowanie do następnego kroku migracji do Cloud Storage

Czego potrzebujesz

• projekt Google Cloud Platform z aktywnym kontem rozliczeniowym GCP;
• podstawowe umiejętności w zakresie Pythona,
• Praktyczna znajomość typowych poleceń systemu Linux
• Podstawowa wiedza na temat tworzenia i wdrażania aplikacji App Engine.
• Działająca aplikacja App Engine z modułu 0 (pobierz z repozytorium)

Ankieta

Jak zamierzasz korzystać z tego samouczka?

Tylko przeczytaj Przeczytaj i wykonaj ćwiczenia

Jak oceniasz swoje doświadczenie z Pythonem?

Początkujący Średnio zaawansowany Zaawansowany

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Średnio zaawansowany Zaawansowany

2. Tło

Aby przeprowadzić migrację z interfejsu App Engine Blobstore API, dodaj jego użycie do istniejącej podstawowej aplikacji App Engine ndb z modułu 0. Przykładowa aplikacja wyświetla 10 ostatnich wizyt użytkownika. Modyfikujemy aplikację, aby wyświetlać użytkownikowi prośbę o przesłanie artefaktu (pliku) odpowiadającego jego „wizycie”. Jeśli użytkownik nie chce tego robić, może skorzystać z opcji „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). Po zaimplementowaniu tej integracji App Engineblobstore możemy przenieść ją do Cloud Storage w kolejnych ćwiczeniach (moduł 16).

App Engine zapewnia dostęp do systemów szablonów Django i Jinja2. Ten przykład różni się od poprzednich (oprócz dodania dostępu do Blobstore) tym, że w module 15 przechodzi z Django w module 0 na Jinja2. Kluczowym krokiem w modernizacji aplikacji App Engine jest przeniesienie platform internetowych z webapp2 na Flask. Ten drugi używa Jinja2 jako domyślnego systemu szablonów, więc zaczynamy iść w tym kierunku, wdrażając Jinja2, ale pozostając na webapp2 w przypadku dostępu do Blobstore. Flask domyślnie używa Jinja2, więc w module 16 nie trzeba będzie wprowadzać żadnych zmian w szablonie.

3. Konfiguracja/przygotowanie

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

1. Konfigurowanie projektu

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

2. Pobieranie przykładowej aplikacji podstawowej

Jednym z wymagań wstępnych tego laboratorium jest działająca przykładowa aplikacja z modułu 0. Jeśli jej nie masz, możesz ją pobrać z folderu „START” modułu 0 (link poniżej). W tym Codelabs znajdziesz instrukcje krok po kroku, a na końcu kod podobny do tego, który znajduje się w folderze „FINISH” w module 15.

• START: Folder modułu 0 (Python 2)
• ZAKOŃCZ: Folder Module 15 (Python 2)
• Całe repozytorium (do sklonowania lub pobrania pliku ZIP)

Katalog plików początkowych modułu 0 powinien wyglądać tak:

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

3. (Ponowne) wdrażanie aplikacji bazowej

Pozostałe czynności przygotowawcze, które musisz teraz wykonać:

1. Przypomnij sobie, jak działa narzędzie wiersza poleceń gcloud.
2. Ponowne wdrażanie przykładowej aplikacji za pomocą gcloud app deploy
3. Sprawdź, czy aplikacja działa w App Engine bez problemów.

Gdy wykonasz te czynności i zobaczysz, że aplikacja internetowa działa (z danymi wyjściowymi podobnymi do poniższych), możesz dodać do niej korzystanie z pamięci podręcznej.

4. Aktualizowanie plików konfiguracji

app.yaml

Nie wprowadzamy istotnych zmian w konfiguracji aplikacji, ale jak wspomnieliśmy wcześniej, przechodzimy z szablonów Django (domyślnych) na Jinja2. Aby dokonać zmiany, użytkownicy powinni określić najnowszą wersję Jinja2 dostępną na serwerach App Engine. Można to zrobić, dodając ją do sekcji wbudowanych bibliotek 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, jak w tym przykładzie:

PO:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: jinja2
  version: latest

Potrzebujesz nowszej wersji biblioteki innej firmy?

Zmiana na app.yaml powyżej wydaje się określać „najnowszą” wersję Jinja2. Wskazuje to jednak tylko najnowszą wersję Pythona 2 dostępną na serwerach App Engine, a nie najnowszą wersję samej biblioteki. Jeśli potrzebujesz wersji nowszej niż te wymienione na stronie obsługiwanych bibliotek innych firm, nie dodawaj jej do app.yaml zgodnie z powyższymi instrukcjami. Zamiast tego umieść ją w requirements.txt i uruchom pip install -t lib -r requirements.txt, aby dołączyć/sprzedać najnowszą wersję Jinja2 (lub dowolnej dozwolonej biblioteki innej firmy) dla Pythona 2. Wbudowane biblioteki zapewniają wygodę, ponieważ nie musisz ich samodzielnie pakować, ale w zamian zawsze musisz udostępniać najnowszą wersję.

Nie musisz aktualizować żadnych innych plików konfiguracyjnych, więc przejdźmy do plików aplikacji.

5. Modyfikowanie plików aplikacji

Importy i obsługa Jinja2

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

1. Moduł os służy do tworzenia ścieżki do pliku szablonu Django. Przechodzimy na Jinja2, w którym ta kwestia jest obsługiwana, więc nie musimy już używać os ani renderera szablonów Django google.appengine.ext.webapp.template. Dlatego je usuwamy.
2. Zaimportuj interfejs Blobstore API: google.appengine.ext.blobstore
3. Zaimportuj moduły obsługi Blobstore znalezione w oryginalnej platformie webapp – nie są one dostępne w webapp2: google.appengine.ext.webapp.blobstore_handlers
4. Importowanie obsługi 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ę importu w pliku main.py fragmentem kodu poniżej.

PO:

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

Po importach dodaj powtarzalny kod, aby obsługiwać Jinja2 zgodnie z opisem w webapp2_extrasdokumentacji. Ten fragment kodu otacza standardową klasę obsługi żądań webapp2 funkcjami Jinja2, więc dodaj ten blok kodu do pliku main.py tuż po importach:

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

Alternatywna obsługa Jinja2

Jeśli nie rozpoznajesz powyższego kodu Jinja2 i oczekujesz czegoś bardziej podobnego do przykładu w dokumentacji App Engine z użyciem jinja2.Environment(), wybraliśmy rozwiązanie webapp2extras, ponieważ zapewnia ono lepszą obsługę (wielowątkowość I18N).

Dodawanie obsługi Blobstore

W przeciwieństwie do innych migracji z tej serii, w których zachowujemy funkcjonalność lub dane wyjściowe aplikacji przykładowej w identycznej (lub prawie identycznej) postaci bez (większych) zmian w UX, w tym przykładzie odchodzimy od normy w bardziej radykalny sposób. Zamiast od razu rejestrować nową wizytę, a potem wyświetlać 10 najnowszych, aktualizujemy aplikację, aby prosić użytkownika o plik, który pozwoli zarejestrować wizytę. Użytkownicy mogą wtedy przesłać odpowiedni plik lub kliknąć „Pomiń”, aby niczego nie przesyłać. Po wykonaniu tego kroku wyświetli się strona „Najnowsze wizyty”.

Ta zmiana umożliwia naszej aplikacji korzystanie z usługi Blobstore do przechowywania (i ewentualnego późniejszego renderowania) tego obrazu lub innego typu pliku na stronie ostatnich wizyt.

Aktualizowanie modelu danych i wdrażanie jego użycia

Przechowujemy więcej danych, a konkretnie aktualizujemy model danych, aby przechowywać identyfikator (nazywany „BlobKey”) pliku przesłanego do Blobstore, i dodajemy odwołanie, aby zapisać go w store_visit(). Te dodatkowe dane są zwracane wraz z pozostałymi informacjami w odpowiedzi na zapytanie, więc wartość fetch_visits() pozostaje bez zmian.

Oto porównanie przed i po wprowadzeniu tych zmian. Na ilustracjach widać 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 graficzne przedstawienie wprowadzonych do tej pory zmian:

Obsługa przesyłania plików

Najważniejszą zmianą w funkcjonalności jest obsługa przesyłania plików, w tym wyświetlanie użytkownikowi prośby o przesłanie pliku, obsługa funkcji „Pomiń” i renderowanie pliku odpowiadającego wizycie. Wszystko to jest częścią obrazu. Aby obsługiwać przesyłanie plików, musisz wprowadzić te zmiany:

1. Główny moduł obsługi GET nie pobiera już najnowszych wizyt do wyświetlania. Zamiast tego wyświetla prośbę o przesłanie.
2. Gdy użytkownik przesyła plik do przesłania lub pomija ten proces, token POST z formularza przekazuje kontrolę do nowego tokena UploadHandler, który pochodzi z tokena google.appengine.ext.webapp.blobstore_handlers.BlobstoreUploadHandler.
3. Metoda UploadHandler w POST przesyła plik, wywołuje store_visit(), aby zarejestrować wizytę, i wywołuje przekierowanie HTTP 307, aby odesłać użytkownika z powrotem do „/”, gdzie…
4. Główna funkcja obsługi POST wysyła zapytanie (za pomocą fetch_visits()) o najnowsze wizyty i wyświetla je. Jeśli użytkownik wybierze „Pomiń”, żaden plik nie zostanie przesłany, ale wizyta zostanie zarejestrowana, a następnie nastąpi to samo przekierowanie.
5. W sekcji „Ostatnie wizyty” wyświetlane jest nowe pole, które zawiera hiperlink „Wyświetl” (jeśli dostępny jest przesłany plik) lub „Brak” (w przeciwnym razie). Zmiany te zostaną wprowadzone w szablonie HTML wraz z dodaniem formularza przesyłania (więcej informacji wkrótce).
6. Jeśli użytkownik kliknie link „Wyświetl” w przypadku dowolnej wizyty z przesłanym filmem, wysyła GET żądanie do nowego ViewBlobHandler, pochodzącego z google.appengine.ext.webapp.blobstore_handlers.BlobstoreDownloadHandler . Plik jest renderowany, jeśli jest obrazem (w obsługiwanej przeglądarce), lub wyświetla się prośba o pobranie, jeśli nie jest obrazem. Jeśli plik nie zostanie znaleziony, zwracany jest błąd HTTP 404.
7. Oprócz nowej pary klas obsługi i nowej pary tras do przesyłania do nich ruchu główny moduł obsługi potrzebuje nowej metody POST do odbierania opisanego powyżej przekierowania 307.

Przed wprowadzeniem tych zmian aplikacja modułu 0 zawierała tylko główny moduł obsługi z metodą GET i jedną ścieżką:

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 wprowadzeniu tych zmian są teraz 3 funkcje obsługi: 1) funkcja obsługi przesyłania z metodą POST, 2) funkcja obsługi pobierania „wyświetl blob” z metodą GET i 3) główna funkcja obsługi z metodami GET i POST. Wprowadź te zmiany, aby reszta aplikacji wyglądała jak 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 dodanym właśnie kodzie znajduje się kilka kluczowych wywołań:

• W MainHandler.get jest połączenie z numerem blobstore.create_upload_url. To wywołanie generuje adres URL, do którego formularz POST, wywołując moduł obsługi przesyłania, aby wysłać plik do Blobstore.
• W UploadHandler.post jest połączenie z numerem blobstore_handlers.BlobstoreUploadHandler.get_uploads. To prawdziwa magia, która umieszcza plik w Blobstore i zwraca unikalny i trwały identyfikator tego pliku, czyli jego BlobKey.
• W ViewBlobHandler.get wywołanie funkcji blobstore_handlers.BlobstoreDownloadHandler.send z parametrem BlobKey pliku powoduje pobranie pliku i przekazanie go do przeglądarki użytkownika.

Te wywołania stanowią większość dostępu do funkcji dodanych do aplikacji. Oto graficzne przedstawienie tego drugiego i ostatniego zestawu zmian w main.py:

Aktualizowanie szablonu HTML

Niektóre aktualizacje głównej aplikacji wpływają na interfejs użytkownika, dlatego w szablonie internetowym trzeba wprowadzić odpowiednie zmiany. W zasadzie są to 2 zmiany:

1. Wymagany jest formularz przesyłania plików z 3 elementami wejściowymi: plikiem i parą przycisków przesyłania i pomijania.
2. Zaktualizuj dane dotyczące ostatnich wizyt, dodając link „Wyświetl” w przypadku wizyt, którym odpowiada przesłany plik, lub „brak” w pozostałych przypadkach.

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>

Wprowadź zmiany z powyższej listy, aby utworzyć zaktualizowany szablon:

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>

Ilustracja przedstawiająca wymagane zmiany w index.html:

Ostatnia zmiana polega na tym, że Jinja2 preferuje szablony w folderze templates, więc utwórz ten folder i przenieś do niego plik index.html. W ten sposób zakończysz wprowadzanie wszystkich niezbędnych zmian, aby dodać korzystanie z Blobstore do przykładowej aplikacji z modułu 0.

(opcjonalnie) „ulepszenie” Cloud Storage

Pamięć Blobstore ostatecznie przekształciła się w Cloud Storage. Oznacza to, że przesyłane pliki Blobstore są widoczne w konsoli Cloud, a konkretnie w przeglądarce Cloud Storage. Pytanie brzmi: gdzie. Odpowiedzią jest domyślny zasobnik Cloud Storage aplikacji App Engine. Jej nazwa to pełna nazwa domeny aplikacji App Engine, PROJECT_ID.appspot.com. Jest to bardzo wygodne, ponieważ wszystkie identyfikatory projektów są unikalne, prawda?

Aktualizacje wprowadzone w przykładowej aplikacji powodują, że przesłane pliki są umieszczane w tym zasobniku, ale deweloperzy mogą wybrać bardziej szczegółową lokalizację. Dostęp do domyślnego zasobnika można uzyskać programowo za pomocą google.appengine.api.app_identity.get_default_gcs_bucket_name(). Jeśli chcesz uzyskać dostęp do tej wartości, np. aby użyć jej jako prefiksu do organizowania przesłanych plików, musisz wykonać nowy import. Na przykład sortowanie według typu pliku:

Aby wdrożyć coś takiego w przypadku obrazów, musisz mieć np. taki kod oraz kod, który sprawdza typy plików, aby wybrać odpowiednią nazwę zasobnika:

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

Przesłane obrazy możesz też zweryfikować za pomocą narzędzia takiego jak moduł imghdr biblioteki standardowej Pythona, aby potwierdzić typ obrazu. Na koniec warto ograniczyć rozmiar przesyłanych plików, aby zapobiec nadużyciom.

Załóżmy, że wszystko to zostało zrobione. Jak możemy zaktualizować aplikację, aby obsługiwała określanie miejsca przechowywania przesyłanych plików? Kluczem jest zmiana wywołania funkcji blobstore.create_upload_url w MainHandler.get, aby określić żądaną lokalizację w Cloud Storage na potrzeby przesyłania, przez dodanie parametru gs_bucket_name w ten sposób:

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

Jest to aktualizacja opcjonalna, jeśli chcesz określić, gdzie mają trafiać przesłane pliki, więc nie jest częścią pliku main.py w repozytorium. Zamiast tego w repozytorium jest dostępna alternatywa o nazwie main-gcs.py. Zamiast używać oddzielnego „folderu” zasobnika, kod w main-gcs.py przechowuje przesłane pliki w zasobniku na „poziomie głównym” (PROJECT_ID.appspot.com), podobnie jak main.py, ale zapewnia scaffolding, którego potrzebujesz, jeśli chcesz przekształcić przykład w coś bardziej złożonego, jak wspomniano w tej sekcji. Poniżej znajduje się ilustracja różnic między main.py a main-gcs.py.

6. Podsumowanie i czyszczenie

W tej sekcji podsumowujemy te warsztaty, wdrażając aplikację i sprawdzając, czy działa zgodnie z oczekiwaniami i czy dane wyjściowe są prawidłowe. Po zweryfikowaniu aplikacji wykonaj czynności związane z czyszczeniem i zastanów się, co dalej zrobić.

Wdrażanie i weryfikowanie aplikacji

Ponownie wdróż aplikację za pomocą gcloud app deploy i sprawdź, czy działa zgodnie z opisem, a wygoda użytkownika (UX) różni się od aplikacji z modułu 0. Aplikacja ma teraz 2 różne ekrany. Pierwszy z nich to prośba o przesłanie pliku wizyty:

Użytkownicy mogą przesłać plik i kliknąć „Prześlij” lub kliknąć „Pomiń”, aby niczego nie przesyłać. W obu przypadkach wynikiem jest ekran ostatniej wizyty, wzbogacony o linki „Wyświetl” lub „Brak” między sygnaturami czasowymi wizyty a informacjami o odwiedzającym:

Gratulacje! Ukończono to ćwiczenie (w Codelabs) polegające na dodaniu do przykładowej aplikacji z modułu 0 funkcji App Engine Blobstore. Twój kod powinien teraz być zgodny z kodem w folderze FINISH (Module 15). W tym folderze znajduje się też alternatywna wersja main-gcs.py.

Czyszczenie danych

Ogólne

Jeśli na razie nie chcesz już korzystać z usługi, zalecamy wyłączenie aplikacji App Engine, aby uniknąć naliczania opłat. Jeśli jednak chcesz przeprowadzić więcej testów lub eksperymentów, platforma App Engine ma bezpłatny limit, więc dopóki nie przekroczysz tego poziomu wykorzystania, nie powinny być naliczane żadne opłaty. Dotyczy to obliczeń, ale mogą też wystąpić opłaty za odpowiednie usługi App Engine, więc więcej informacji znajdziesz na stronie z cennikiem. Jeśli migracja obejmuje inne usługi w chmurze, są one rozliczane oddzielnie. W każdym przypadku, jeśli to konieczne, zapoznaj się z sekcją „Specyficzne dla tego laboratorium” poniżej.

Wdrożenie na bezserwerowej platformie obliczeniowej Google Cloud, takiej jak App Engine, wiąże się z niewielkimi kosztami kompilacji i przechowywania. 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 bezpłatnego pakietu, więc kontroluj wykorzystanie miejsca na dane, aby zminimalizować potencjalne koszty. Sprawdź te „foldery” Cloud Storage:

• 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
• Linki do pamięci masowej powyżej zależą od PROJECT_ID i *LOC*acji, np. „us”, jeśli Twoja aplikacja jest hostowana w Stanach Zjednoczonych.

Jeśli nie zamierzasz kontynuować pracy z tą aplikacją ani innymi powiązanymi z nią samouczkami dotyczącymi migracji i chcesz wszystko całkowicie usunąć, wyłącz projekt.

Dotyczy tych ćwiczeń z programowania

Usługi wymienione poniżej są dostępne tylko w tym laboratorium. Więcej informacji znajdziesz w dokumentacji poszczególnych usług:

• Usługa Blobstore App Engine podlega limitom i limitom danych przechowywanych, więc zapoznaj się z nimi oraz ze stroną z cennikiem starszych usług pakietowych.
• Usługa App Engine Datastore jest udostępniana przez Cloud Datastore (Cloud Firestore w trybie Datastore), która również ma bezpłatny poziom. Więcej informacji znajdziesz na stronie z cennikiem.

Dalsze kroki

Kolejna logiczna migracja jest opisana w module 16, w którym pokazujemy programistom, jak przejść z usługi Blobstore App Engine na bibliotekę klienta Cloud Storage. Uaktualnienie daje dostęp do większej liczby funkcji Cloud Storage i pozwala zapoznać się z biblioteką klienta, która działa w przypadku aplikacji poza App Engine, niezależnie od tego, czy znajdują się one w Google Cloud, innych chmurach czy nawet lokalnie. Jeśli nie potrzebujesz wszystkich funkcji dostępnych w Cloud Storage lub martwisz się o ich wpływ na koszty, możesz nadal korzystać z App Engine Blobstore.

Poza modułem 16 istnieje wiele innych możliwych migracji, takich jak Cloud NDB i Cloud Datastore, Cloud Tasks czy Cloud Memorystore. Istnieją też migracje między usługami do Cloud Run i Cloud Functions. Repozytorium migracji zawiera wszystkie przykłady kodu, linki do wszystkich samouczków i filmów, a także wskazówki dotyczące migracji, które warto rozważyć, oraz odpowiednią „kolejność” migracji.

7. Dodatkowe materiały

Problemy z ćwiczeniami z programowania i opinie na ich temat

Jeśli zauważysz jakieś problemy z tym kursem, najpierw poszukaj rozwiązania, a dopiero potem zgłoś problem. Linki do wyszukiwania i tworzenia nowych problemów:

• Wyszukiwanie problemów
• Zgłaszanie nowego problemu lub przesyłanie opinii

Materiały dotyczące migracji

Linki do folderów repozytorium dla modułu 0 (START) i modułu 15 (FINISH) znajdziesz w tabeli poniżej. Możesz też uzyskać do nich dostęp w repozytorium wszystkich migracji codelabów App Engine, które możesz sklonować lub pobrać jako plik ZIP.

Ćwiczenia z programowania	Python 2	Python 3
Część 0.	kod	Nie dotyczy
Moduł 15 (te ćwiczenia z programowania)	kod	Nie dotyczy

Zasoby online

Poniżej znajdziesz zasoby online, które mogą być przydatne w tym samouczku:

App Engine

• Usługa Blobstore App Engine
• Limity i limity przydziału danych przechowywanych w App Engine
• Dokumentacja App Engine
• Środowisko wykonawcze App Engine (środowisko standardowe) w Pythonie 2
• Korzystanie z wbudowanych bibliotek App Engine w App Engine w Pythonie 2
• Informacje o cenach i limitach App Engine
• Uruchomienie platformy App Engine drugiej generacji (2018)
• Porównanie platform pierwszej i drugiej generacji
• Wsparcie długoterminowe dla starszych środowisk wykonawczych
• Repozytorium z przykładami migracji dokumentacji
• Repozytorium próbek migracji udostępnionych przez społeczność

Google Cloud

• Python w Google Cloud Platform
• Biblioteki klienta Google Cloud Python
• Poziom „Zawsze bezpłatny” w Google Cloud
• Google Cloud SDK (narzędzie wiersza poleceń gcloud)
• Cała dokumentacja Google Cloud

Python

• systemy szablonów Django i Jinja2,
• webapp2 framework internetowy
• webapp2 dokumentacja
• webapp2_extras linki
• webapp2_extras Dokumentacja Jinja2

Filmy

• Serverless Migration Station
• Ekspedycje bezserwerowe
• Subskrybuj Google Cloud Tech
• Subskrybuj Google Developers

Licencja

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