Migracja z kolejki zadań App Engine dotyczące przekazywania zadań do Cloud Tasks (moduł 8)

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.

Celem tego laboratorium jest pokazanie deweloperom aplikacji App Engine w Pythonie 2, jak przeprowadzić migrację z kolejki zadań App Engine (zadań push) do Cloud Tasks. Istnieje też niejawna migracja z App Engine NDB do Cloud NDB w przypadku dostępu do Datastore (omówiona głównie w module 2).

W module 7 dodaliśmy wykorzystanie zadań push, a w module 8 przenosimy to wykorzystanie do Cloud Tasks, a następnie w module 9 przechodzimy do Pythona 3 i Cloud Datastore. Użytkownicy korzystający z kolejek zadań do zadań typu pull przejdą na Cloud Pub/Sub i powinni zapoznać się z modułami 18–19.

Dowiesz się, jak:

Czego potrzebujesz

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

Kolejka zadań App Engine obsługuje zadania push i pull. Aby zwiększyć przenośność aplikacji, zespół Google Cloud zaleca migrację z starszych usług pakietowych, takich jak kolejka zadań, na inne samodzielne usługi w chmurze lub równoważne usługi innych firm.

Migracja zadań typu pull jest omówiona w modułach 18–19, a migracja zadań typu push w modułach 7–9. Aby przeprowadzić migrację z zadań typu push w kolejce zadań App Engine, dodaliśmy ich użycie do istniejącej przykładowej aplikacji App Engine w Pythonie 2, która rejestruje nowe wizyty na stronie i wyświetla ostatnie wizyty. W module 7 dodaliśmy zadanie push, które usuwa najstarsze wizyty. Nie będą one już nigdy wyświetlane, więc po co mają zajmować dodatkowe miejsce w Datastore? W tym module 8 zachowujemy tę samą funkcjonalność, ale przenosimy podstawowy mechanizm kolejkowania z zadań push w kolejce zadań do Cloud Tasks. Powtarzamy też migrację z modułu 2 z App Engine NDB do Cloud NDB w celu uzyskania dostępu do Datastore.

Ten samouczek obejmuje te kroki:

  1. Konfiguracja/przygotowanie
  2. Aktualizacja konfiguracji
  3. Modyfikowanie kodu aplikacji

3. Konfiguracja/przygotowanie

Z tej sekcji dowiesz się, jak:

  1. Konfigurowanie projektu w chmurze
  2. Pobieranie przykładowej aplikacji podstawowej
  3. (Ponowne) wdrażanie i weryfikowanie aplikacji podstawowej
  4. Włączanie nowych usług i interfejsów API Google Cloud

Dzięki tym czynnościom będziesz mieć pewność, że zaczynasz od działającego kodu, a przykładowa aplikacja jest gotowa do migracji do usług w chmurze.

1. Konfigurowanie projektu

Jeśli masz za sobą ćwiczenie z programowania w module 7, użyj tego samego projektu (i kodu). Możesz też utworzyć zupełnie nowy projekt lub użyć innego istniejącego projektu. Upewnij się, że projekt ma aktywne konto rozliczeniowe i włączoną aplikację App Engine. Znajdź identyfikator projektu, ponieważ będzie Ci potrzebny podczas tego szkolenia. Używaj go zawsze, gdy napotkasz zmienną PROJECT_ID.

2. Pobieranie przykładowej aplikacji podstawowej

Jednym z wymagań wstępnych jest działająca aplikacja App Engine z modułu 7: wykonaj ćwiczenie z programowania z modułu 7 (zalecane) lub skopiuj aplikację z modułu 7 z repozytorium. Niezależnie od tego, czy używasz własnego kodu, czy naszego, zaczniemy od kodu modułu 7 („START”). W tym ćwiczeniu Codelab przeprowadzimy Cię przez proces migracji, który zakończy się kodem podobnym do tego w folderze repozytorium modułu 8 („FINISH”).

Niezależnie od tego, której aplikacji z modułu 7 używasz, folder powinien wyglądać jak poniżej. Może też zawierać folder lib:

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. (Ponowne) wdrażanie i weryfikowanie aplikacji podstawowej

Aby wdrożyć aplikację z modułu 7, wykonaj te czynności:

  1. Usuń folder lib, jeśli istnieje, i uruchom polecenie pip install -t lib -r requirements.txt, aby ponownie wypełnić folder lib. Jeśli na komputerze używanym do programowania masz zainstalowane zarówno Pythona 2, jak i 3, może być konieczne użycie polecenia pip2.
  2. Sprawdź, czy narzędzie wiersza poleceń gcloud zostało zainstalowane i zainicjowane oraz czy zapoznano się z jego użyciem.
  3. (opcjonalnie) Ustaw projekt w chmurze za pomocą polecenia gcloud config set project PROJECT_ID, jeśli nie chcesz wpisywać PROJECT_ID przy każdym poleceniu gcloud.
  4. Wdrażanie przykładowej aplikacji za pomocą gcloud app deploy
  5. Sprawdź, czy aplikacja działa zgodnie z oczekiwaniami i nie sprawia problemów. Jeśli udało Ci się ukończyć ćwiczenie z programowania w module 7, aplikacja wyświetli najpopularniejszych użytkowników wraz z najnowszymi wizytami (jak na ilustracji poniżej). U dołu znajduje się informacja o starszych zadaniach, które zostaną usunięte.

4aa8a2cb5f527079.png

4. Włączanie nowych usług i interfejsów API Google Cloud

Stara aplikacja korzystała z usług pakietowych App Engine, które nie wymagają dodatkowej konfiguracji. Jednak samodzielne usługi Cloud wymagają konfiguracji, a zaktualizowana aplikacja będzie korzystać zarówno z Cloud Tasks, jak i z Cloud Datastore (za pomocą biblioteki klienta Cloud NDB). Wiele usług w Google Cloud ma limity poziomu „Zawsze bezpłatnie”, w tym App Engine, Cloud Datastore i Cloud Tasks. Jeśli nie przekroczysz tych limitów, ukończenie tego samouczka nie powinno wiązać się z żadnymi opłatami. Interfejsy API Cloud możesz włączyć w konsoli Cloud lub w wierszu poleceń, w zależności od preferencji.

W konsoli Cloud

Otwórz stronę Biblioteka menedżera interfejsów API (w odpowiednim projekcie) w konsoli Cloud i wyszukaj interfejsy Cloud Datastore API i Cloud Tasks API za pomocą paska wyszukiwania na środku strony:

c7a740304e9d35b.png

Kliknij przycisk Włącz przy każdym interfejsie API z osobna. Możesz zostać poproszony(-a) o podanie informacji rozliczeniowych. To przykład strony biblioteki Cloud Pub/Sub API (w tym laboratorium Codelabs nie włączaj interfejsu Pub/Sub API, tylko Cloud Tasks i Datastore):

1b6c0a2a73124f6b.jpeg

W wierszu poleceń

Włączanie interfejsów API w konsoli jest bardzo wygodne, ale niektórzy wolą wiersz poleceń. Wydaj polecenie gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com, aby włączyć oba interfejsy API jednocześnie:

$ gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Może pojawić się prośba o podanie informacji rozliczeniowych. Jeśli chcesz włączyć inne interfejsy Cloud API i poznać ich „URI”, znajdziesz je u dołu strony biblioteki każdego interfejsu API. Na przykład na dole strony Pub/Sub powyżej widać pubsub.googleapis.com jako „Nazwę usługi”.

Po wykonaniu tych czynności projekt będzie miał dostęp do interfejsów API. Teraz możesz zaktualizować aplikację, aby korzystała z tych interfejsów API.

4. Aktualizacja konfiguracji

Zmiany w konfiguracji wynikają bezpośrednio z dodania bibliotek klienta Cloud. Niezależnie od tego, których z nich używasz, w aplikacjach, które nie korzystają z żadnych bibliotek klienta Cloud, musisz wprowadzić te same zmiany.

requirements.txt

W module 8 użycie App Engine NDB i kolejki zadań z modułu 1 zostało zastąpione przez Cloud NDB i Cloud Tasks. Dołącz oba elementy google-cloud-ndb i google-cloud-tasks do requirements.txt, aby dołączyć do flask z modułu 7:

flask
google-cloud-ndb
google-cloud-tasks

Ten plik requirements.txt nie zawiera numerów wersji, co oznacza, że wybrane są najnowsze wersje. Jeśli wystąpią jakiekolwiek niezgodności, podaj numer wersji, aby zablokować działające wersje aplikacji.

app.yaml

W przypadku korzystania z bibliotek klienta Cloud środowisko wykonawcze App Engine w Pythonie 2 wymaga określonych pakietów innych firm, a mianowicie grpcio i setuptools. Użytkownicy Pythona 2 muszą podać w app.yaml wbudowane biblioteki, takie jak te, wraz z dostępną wersją lub „najnowszą”. Jeśli nie masz jeszcze sekcji libraries, utwórz ją i dodaj obie biblioteki w ten sposób:

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

Podczas migracji Twojej aplikacji może ona już mieć sekcję libraries. Jeśli tak jest, a brakuje grpcio i setuptools, dodaj je do istniejącej sekcji libraries. Zaktualizowany app.yaml powinien teraz wyglądać tak:

runtime: python27
threadsafe: yes
api_version: 1

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

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

appengine_config.py

Wywołanie google.appengine.ext.vendor.add() w appengine_config.py łączy skopiowane (czasami nazywane „dostarczanymi” lub „samodzielnie dołączanymi”) biblioteki innych firm w lib z aplikacją. Powyżej w app.yaml dodaliśmy wbudowane biblioteki innych firm, które wymagają setuptools.pkg_resources.working_set.add_entry(), aby powiązać aplikację z tymi wbudowanymi pakietami w lib. Poniżej znajdziesz oryginalny moduł 1 appengine_config.py oraz moduł 1 po wprowadzeniu zmian z modułu 8:

PRZED:

from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)

PO:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

Podobny opis znajdziesz też w dokumentacji migracji App Engine.

5. Modyfikowanie kodu aplikacji

W tej sekcji znajdziesz aktualizacje głównego pliku aplikacji main.py, które zastępują kolejki push App Engine Task Queue kolejkami Cloud Tasks. Szablon internetowy nie ulegnie zmianie templates/index.html– obie aplikacje powinny działać identycznie i wyświetlać te same dane. Modyfikacje głównej aplikacji dzielą się na te 4 „czynności do wykonania”:

  1. Aktualizowanie importów i inicjowanie
  2. Aktualizowanie funkcji modelu danych (Cloud NDB)
  3. Migracja do Cloud Tasks (i Cloud NDB)
  4. Aktualizacja (push) modułu obsługi zadań

1. Aktualizowanie importów i inicjowanie

  1. Zastąp App Engine NDB (google.appengine.ext.ndb) i Task Queue (google.appengine.api.taskqueue) odpowiednio Cloud NDB (google.cloud.ndb) i Cloud Tasks (google.cloud.tasks).
  2. Biblioteki klienta Cloud wymagają inicjowania i tworzenia „klientów interfejsu API”. Przypisz je odpowiednio do zmiennych ds_client i ts_client.
  3. W dokumentacji kolejki zadań czytamy: „App Engine udostępnia domyślną kolejkę push o nazwie default, która jest skonfigurowana i gotowa do użycia z ustawieniami domyślnymi”. Cloud Tasks nie udostępnia kolejki default (ponieważ jest to samodzielna usługa w chmurze niezależna od App Engine), dlatego do utworzenia kolejki Cloud Tasks o nazwie default wymagany jest nowy kod.
  4. Kolejka zadań App Engine nie wymaga podania regionu, ponieważ korzysta z regionu, w którym działa aplikacja. Ponieważ usługa Cloud Tasks jest teraz niezależnym produktem, wymaga regionu, który musi być zgodny z regionem, w którym działa Twoja aplikacja. Aby utworzyć „w pełni kwalifikowaną ścieżkę” jako unikalny identyfikator kolejki, musisz podać nazwę regionu i identyfikator projektu w chmurze.

Aktualizacje opisane w trzecim i czwartym punkcie powyżej stanowią większość dodatkowych stałych i wymaganej inicjalizacji. Zobacz poniżej sekcje „Przed” i „Po” i wprowadź te zmiany u góry main.py.

PRZED:

from datetime import datetime
import logging
import time
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb

app = Flask(__name__)

PO:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)

2. Aktualizowanie funkcji modelu danych (Cloud NDB)

App Engine NDB i Cloud NDB działają niemal identycznie. Nie wprowadzamy żadnych większych zmian w modelu danych ani w funkcji store_visit(). Jedyna zauważalna różnica polega na tym, że tworzenie obiektu Visit w store_visit() jest teraz zamknięte w bloku with w Pythonie. Cloud NDB wymaga, aby cały dostęp do Datastore był kontrolowany w ramach menedżera kontekstu, stąd instrukcja with. Poniższe fragmenty kodu ilustrują tę niewielką różnicę podczas migracji do Cloud NDB. Wprowadź tę zmianę.

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

PO:

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'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

3. Migracja do Cloud Tasks (i Cloud NDB)

Najważniejsza zmiana w tej migracji polega na przełączeniu bazowej infrastruktury kolejkowania. Odbywa się to w funkcji fetch_visits(), w której tworzone jest zadanie (push) usuwania starych wizyt i umieszczane w kolejce do wykonania. Jednak oryginalna funkcjonalność z modułu 7 pozostaje nienaruszona:

  1. Wykonywanie zapytań o najnowsze wizyty.
  2. Zamiast od razu zwracać te wizyty, zapisz sygnaturę czasową ostatniej z nich, czyli najstarszej wyświetlanej. Możesz bezpiecznie usunąć wszystkie wizyty starsze od tej.Visit
  3. Wyodrębnij sygnaturę czasową jako liczbę zmiennoprzecinkową i ciąg znaków za pomocą standardowych narzędzi Pythona i używaj obu tych wartości w różnych celach, np. wyświetlaj je użytkownikowi, dodawaj do logów, przekazuj do modułu obsługi itp.
  4. Utwórz zadanie push z tym sygnaturą czasową jako ładunkiem wraz z adresem URL /trim.
  5. Obsługa zadania jest ostatecznie wywoływana za pomocą żądania HTTP POST do tego adresu URL.

Ten przepływ pracy ilustruje fragment kodu „przed”:

PRZED:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    taskqueue.add(url='/trim', params={'oldest': oldest})
    return data, oldest_str

Funkcje pozostają bez zmian, ale platformą wykonawczą staje się Cloud Tasks. Zmiany, które wprowadziliśmy, aby to osiągnąć:

  1. Umieść zapytanie Visit w bloku with w Pythonie (powtórz migrację z modułu 2 do Cloud NDB).
  2. Utwórz metadane Cloud Tasks, w tym oczekiwane atrybuty, takie jak ładunek znacznika czasu i adres URL, ale dodaj też typ MIME i zakoduj ładunek w formacie JSON.
  3. Użyj klienta Cloud Tasks API, aby utworzyć zadanie z metadanymi i pełną ścieżką do kolejki.

Te zmiany w fetch_visits() ilustruje poniższy diagram:

PO:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return data, oldest_str

4. Aktualizacja (push) modułu obsługi zadań

Funkcja obsługi zadań (push) nie wymaga większych aktualizacji, a jedynie wykonania. Dotyczy to kolejek zadań lub Cloud Tasks. „Kod to kod” – mówią. Wprowadziliśmy jednak pewne drobne zmiany:

  1. Ładunek sygnatury czasowej został przekazany do kolejki zadań w formie dosłownej, ale w przypadku Cloud Tasks został zakodowany w formacie JSON, dlatego po dotarciu musi zostać przeanalizowany.
  2. Wywołanie HTTP POST do /trim z kolejką zadań miało domyślny typ MIME application/x-www-form-urlencoded, ale w przypadku Cloud Tasks jest on określony jako application/json, więc istnieje nieco inny sposób wyodrębniania ładunku.
  3. Użyj menedżera kontekstu klienta interfejsu Cloud NDB API (migracja modułu 2 do Cloud NDB).

Poniżej znajdziesz fragmenty kodu przed wprowadzeniem tych zmian w funkcji obsługi zadań trim() i po ich wprowadzeniu:

PRZED:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = request.form.get('oldest', type=float)
    keys = Visit.query(
            Visit.timestamp < datetime.fromtimestamp(oldest)
    ).fetch(keys_only=True)
    nkeys = len(keys)
    if nkeys:
        logging.info('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id()) for k in keys)))
        ndb.delete_multi(keys)
    else:
        logging.info('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

PO:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Nie ma aktualizacji głównego modułu obsługi aplikacji root() ani szablonu internetowego templates/index.html.

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 czyszczenie i rozważ kolejne kroki.

Wdrażanie i weryfikowanie aplikacji

Wdróż aplikację za pomocą gcloud app deploy. Wynik powinien być identyczny z aplikacją z modułu 7, ale pamiętaj, że zmieniasz produkt kolejki push na zupełnie inny, dzięki czemu Twoja aplikacja jest bardziej przenośna niż wcześniej.

4aa8a2cb5f527079.png

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:

Dalsze kroki

To już koniec migracji zadań push z kolejki zadań App Engine do Cloud Tasks. Jeśli chcesz kontynuować przenoszenie tej aplikacji do Pythona 3 i przejść z Cloud NDB na Cloud Datastore, zapoznaj się z modułem 9.

Usługa Cloud NDB jest przeznaczona specjalnie dla deweloperów korzystających z App Engine w Pythonie 2 i zapewnia niemal identyczne środowisko użytkownika. Usługa Cloud Datastore ma jednak własną natywną bibliotekę klienta przeznaczoną dla użytkowników, którzy nie korzystają z App Engine, lub nowych użytkowników App Engine (Python 3). Jednak Cloud NDB jest dostępny w przypadku Pythona 2 i 3, więc nie musisz przechodzić na Cloud Datastore.

Zarówno Cloud NDB, jak i Cloud Datastore mają dostęp do Datastore (choć w różny sposób), więc jedynym powodem, dla którego warto rozważyć przejście na Cloud Datastore, jest to, że masz już inne aplikacje, zwłaszcza aplikacje inne niż App Engine, które korzystają z Cloud Datastore, i chcesz ujednolicić bibliotekę klienta Datastore. Ta opcjonalna migracja z Cloud NDB do Cloud Datastore jest też omówiona osobno (bez Task Queue ani Cloud Tasks) w module 3.

Oprócz modułów 3, 8 i 9 warto rozważyć inne moduły migracji, które koncentrują się na przejściu z starszych usług pakietowych App Engine:

App Engine nie jest już jedyną platformą bezserwerową w Google Cloud. Jeśli masz małą aplikację App Engine lub aplikację o ograniczonej funkcjonalności i chcesz przekształcić ją w samodzielny mikroserwis albo podzielić aplikację monolityczną na wiele komponentów wielokrotnego użytku, warto rozważyć przejście na Cloud Functions. Jeśli konteneryzacja stała się częścią procesu tworzenia aplikacji, zwłaszcza jeśli obejmuje potok CI/CD (tryb ciągłej integracji/tryb ciągłego dostarczania lub wdrażanie), rozważ migrację do Cloud Run. Te scenariusze są omówione w tych modułach:

  • Migracja z App Engine do Cloud Functions: patrz moduł 11
  • Migracja z App Engine do Cloud Run: w module 4 dowiesz się, jak skonteneryzować aplikację za pomocą Dockera, a w module 5 – jak to zrobić bez kontenerów, wiedzy o Dockerze ani Dockerfiles

Przejście na inną platformę bezserwerową jest opcjonalne. Zanim wprowadzisz jakiekolwiek zmiany, zalecamy rozważenie najlepszych opcji dla Twoich aplikacji i przypadków użycia.

Niezależnie od tego, który moduł migracji wybierzesz, wszystkie materiały dotyczące Serverless Migration Station (ćwiczenia z programowania, filmy, kod źródłowy [jeśli jest dostępny]) znajdziesz w repozytorium open source. W repozytorium README znajdziesz też wskazówki dotyczące migracji, które warto rozważyć, oraz odpowiednią „kolejność” modułów migracji.

7. Dodatkowe materiały

Poniżej znajdziesz dodatkowe materiały dla programistów, którzy chcą dowiedzieć się więcej o tym lub powiązanym module migracji, a także o powiązanych produktach. Znajdziesz tu m.in. miejsca, w których możesz przesłać opinię o tych treściach, linki do kodu i różne dokumenty, które mogą Ci się przydać.

Problemy z Codelabs lub 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:

Materiały dotyczące migracji

Linki do folderów repozytorium dla modułu 7 (START) i modułu 8 (FINISH) znajdziesz w tabeli poniżej.

Ćwiczenia z programowania

Python 2

Python 3

Moduł 7

kod

kod (nie jest omawiany w tym samouczku)

Moduł 8 (to ćwiczenie)

kod

(n/a)

Zasoby online

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

Kolejka zadań App Engine i Cloud Tasks

App Engine NDB i Cloud NDB (Datastore)

Platforma App Engine

Inne informacje o chmurze

Filmy

Licencja

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