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

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.

Celem tego ćwiczenia w Codelabs jest pokazanie deweloperom aplikacji w języku Python 2 App Engine, jak przejść z kolejki zadań App Engine (zadania push) do Cloud Tasks. Dostępna jest też migracja z App Engine NDB do Cloud NDB w celu uzyskania dostępu do Datastore (omówione głównie w module 2).

Użycie zadań push dodaliśmy w module 7. W module 8 przenieśliśmy je do Cloud Tasks. Następnie w module 9 przenieśliśmy je do Pythona 3 i Cloud Datastore. Osoby korzystające z kolejek zadań do zadań pull zostaną przeniesione do Cloud Pub/Sub i powinny skorzystać z modułów 18–19.

Dowiesz się, jak:

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

Kolejka zadań App Engine obsługuje zarówno zadania push, jak i pobieranie. Aby zwiększyć przenośność aplikacji, zespół Google Cloud zaleca migrację ze starszych pakietów usług, takich jak Task Queue, do innych samodzielnych usług Cloud lub ich odpowiedników innych firm.

Migracja zadań pull jest uwzględniona w modułach migracji 18–19, a moduły 7–9 dotyczą migracji zadań push. Aby przeprowadzić migrację z zadań push kolejki zadań App Engine, dodaliśmy te dane do istniejącej przykładowej aplikacji App Engine w języku Python 2, która rejestruje nowe wizyty na stronie i wyświetla najnowsze wizyty. Ćwiczenie w programie w module 7 dodaje zadanie push polegające na usunięciu najstarszych wizyt. Nie zostaną one już nigdy wyświetlone. Dlaczego więc miałyby zajmować więcej miejsca na dane w Datastore? W tym ćwiczeniu w programowaniu w module 8 zachowana została ta sama funkcja, ale przeniosła bazowy mechanizm kolejkowania z zadań push kolejki zadań do Cloud Tasks, a także powtarza migrację modułu 2 z App Engine NDB do Cloud NDB, aby uzyskać dostęp do Datastore.

W tym samouczku omawiamy następujące kroki:

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

3. Konfiguracja/praca

W tej sekcji dowiesz się, jak:

  1. Konfigurowanie projektu Cloud
  2. Pobierz przykładową aplikację bazową
  3. (Ponowne) wdrażanie i weryfikowanie aplikacji bazowej
  4. Włącz nowe usługi i interfejsy API Google Cloud

Dzięki tym krokom masz pewność, że zaczynasz od działającego kodu i że przykładowa aplikacja jest gotowa do migracji do usług Cloud.

1. Konfigurowanie projektu

Jeśli masz już za sobą ćwiczenie z programowania w module 7, wykorzystaj ponownie ten sam projekt (i kod). Możesz też utworzyć nowy projekt lub wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe i włączoną aplikację App Engine. Znajdź identyfikator projektu, który będzie Ci potrzebny podczas tego ćwiczenia z programowania. Użyj go, gdy natrafisz na zmienną PROJECT_ID.

2. Pobierz przykładową aplikację bazową

Jednym z warunków wstępnych jest działająca aplikacja z modułu 7 App Engine. Wykonaj ćwiczenie z programowania w module 7 (zalecane) lub skopiuj aplikację z Repozytorium. Zacznijmy od kodu modułu 7 („START”) niezależnie od tego, czy używasz swojego czy naszego. To ćwiczenie w Codelabs przeprowadzi Cię przez proces migracji, zakończy się kodem podobnym do tego, który znajduje się w folderze repozytorium modułu 8 („FINISH”).

Niezależnie od tego, której aplikacji w module 7 używasz, folder powinien wyglądać tak jak poniżej (może być też zawierający folder lib):

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

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

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

  1. Usuń folder lib (jeśli istnieje), a następnie uruchom polecenie pip install -t lib -r requirements.txt, aby ponownie uzupełnić dane lib. Jeśli na komputerze, na którym tworzysz aplikacje, masz zainstalowany język Python 2 i 3, może być konieczne użycie interfejsu pip2.
  2. Upewnij się, że masz zainstalowane i zainicjowane narzędzie wiersza poleceń gcloud, a także sprawdź, jak używasz tego narzędzia.
  3. (Opcjonalnie) Jeśli nie chcesz wpisywać PROJECT_ID przy każdym uruchamianym poleceniu gcloud, ustaw w swoim projekcie Cloud wartość gcloud config set project PROJECT_ID.
  4. Wdróż przykładową aplikację za pomocą: gcloud app deploy
  5. Sprawdź, czy aplikacja działa prawidłowo, bez problemów. Jeśli udało Ci się ukończyć Moduł 7 w Codelabs, aplikacja wyświetli najczęstszych użytkowników wraz z najnowszymi wizytami (poniżej). U dołu widać starsze zadania, które zostaną usunięte.

4aa8a2cb5f527079.png

4. Włącz nowe usługi i interfejsy API Google Cloud

Stara aplikacja korzystała z pakietów App Engine, które nie wymagają dodatkowej konfiguracji, w przeciwieństwie do samodzielnych usług Cloud, które wymagają aktualizacji. Zaktualizowana aplikacja będzie wykorzystywać zarówno Cloud Tasks, jak i Cloud Datastore (za pomocą biblioteki klienta Cloud NDB). Wiele usług Cloud ma atrybut „Zawsze bezpłatne” poziomów, w tym App Engine, Cloud Datastore i Cloud Tasks. Dopóki nie przekroczysz tych limitów, nie będziemy naliczać opłat za ukończenie tego samouczka. Interfejsy Cloud APIs można włączyć w konsoli Cloud lub z poziomu wiersza poleceń – w zależności od potrzeb.

W konsoli Google Cloud

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

c7a740304e9d35b.png

Kliknij przycisk Włącz oddzielnie dla każdego interfejsu API – może pojawić się prośba o podanie informacji rozliczeniowych. Oto przykład strony biblioteki interfejsu Cloud Pub/Sub API (nie włączaj interfejsu Pub/Sub API na potrzeby tego ćwiczenia z programowania, tylko Cloud Tasks i Datastore):

1b6c0a2a73124f6b.jpeg

Wiersz poleceń

Chociaż dobrze jest korzystać z interfejsu API w konsoli, niektórzy wolą używać wiersza poleceń. Uruchom 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 identyfikatory URI można znaleźć u dołu strony Biblioteki każdego z interfejsów API. Na przykład obserwuj pubsub.googleapis.com jako „Nazwę usługi” na dole strony Pub/Sub tuż powyżej.

Po wykonaniu tych czynności Twój projekt będzie miał dostęp do interfejsów API. Teraz trzeba zaktualizować aplikację, aby używała tych interfejsów API.

4. Aktualizacja konfiguracji

Aktualizacje konfiguracji wynikają wprost z dodanego wykorzystania bibliotek klienta Cloud. Niezależnie od używanej biblioteki, musisz wprowadzić te same zmiany w aplikacjach, które nie korzystają z żadnych bibliotek klienta Cloud.

requirements.txt

Moduł 8 wymienia korzystanie z Cloud NDB i kolejki zadań w App Engine z modułu 1 z Cloud NDB i Cloud Tasks. Dołącz zarówno google-cloud-ndb, jak i google-cloud-tasks do elementu requirements.txt, tak aby złączyć flask z Modułu 7:

flask
google-cloud-ndb
google-cloud-tasks

Ten plik requirements.txt nie zawiera żadnych numerów wersji, co oznacza, że wybierane są najnowsze wersje. Jeśli wystąpią jakiekolwiek niezgodności, określ numer wersji, aby zablokować wersje robocze aplikacji.

app.yaml

Gdy korzystasz z bibliotek klienta Cloud, środowisko wykonawcze App Engine w języku Python 2 wymaga określonych pakietów innych firm, czyli grpcio i setuptools. Użytkownicy języka Python 2 muszą wyświetlić listę wbudowanych bibliotek, takich jak ta, wraz z dostępną wersją lub „najnowszą” wersją w bibliotece app.yaml. 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 aplikacji może ona już mieć sekcję libraries. Jeśli tak, a brakuje grpcio i setuptools, po prostu 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 usłudze appengine_config.py łączy skopiowane (czasami nazywane „vendoring” lub „samodzielnym grupowaniem”) zewnętrzne biblioteki w usłudze lib z Twoją aplikacją. Powyżej w aplikacji app.yaml dodaliśmy wbudowane biblioteki innych firm, które wymagają setuptools.pkg_resources.working_set.add_entry(), aby powiązać Twoją aplikację z tymi wbudowanymi pakietami w lib. Poniżej znajdziesz oryginalny Moduł 1 appengine_config.py, a po wprowadzeniu aktualizacji w module 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 w dokumentacji migracji App Engine.

5. Modyfikowanie kodu aplikacji

W tej sekcji znajdziesz aktualizacje głównego pliku aplikacji (main.py), które zastąpią użycie kolejek push kolejki zadań App Engine usługą Cloud Tasks. Nie wprowadziliśmy żadnych zmian w szablonie internetowym (templates/index.html) – obie aplikacje powinny działać i tak samo i wyświetlać te same dane. Zmiany w głównej aplikacji są podzielone na cztery zadania:

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

1. Aktualizowanie importów i inicjowania

  1. Zastąp NDB (google.appengine.ext.ndb) i kolejkę zadań (google.appengine.api.taskqueue) w App Engine odpowiednio usługą Cloud NDB (google.cloud.ndb) lub Cloud Tasks (google.cloud.tasks).
  2. Biblioteki klienta Cloud wymagają zainicjowania i utworzenia „klientów API”. przypisz je odpowiednio do: ds_client i ts_client.
  3. W dokumentacji kolejki zadań stwierdzono, że „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 Cloud 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 określania regionu, ponieważ korzysta z regionu, w którym działa Twoja aplikacja. Ponieważ jednak Cloud Tasks jest teraz niezależną usługą, wymaga regionu, który musi być zgodny z regionem, w którym działa aplikacja. Nazwa regionu i identyfikator projektu Cloud są wymagane do utworzenia „pełnej i jednoznacznej nazwy ścieżki” jako unikalnego identyfikatora kolejki.

Aktualizacje opisane w 3 i 4 punkcie powyżej stanowią większość dodatkowych stałych i wymaganych inicjalizacji. Zobacz w sekcji „przed” i „po” poniżej i wprowadź te zmiany u góry strony 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ą prawie tak samo. Nie wprowadziliśmy żadnych istotnych zmian w modelu danych ani w funkcji store_visit(). Jedyną zauważalną różnicą jest to, że utworzenie encji Visit w zasadzie store_visit() jest teraz zawarte w bloku with Pythona. Cloud NDB wymaga, aby dostęp do Datastore był kontrolowany w ramach menedżera kontekstu, dlatego instrukcja with. Poniższe fragmenty kodu ilustrują tę niewielką różnicę przy 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)

Najbardziej krytyczna zmiana w tej migracji powoduje zmianę bazowej infrastruktury kolejki. Ma to miejsce w funkcji fetch_visits(), w której tworzone jest zadanie usunięcia starych wizyt (push), które jest umieszczane w kolejce do wykonania. Pierwotne funkcje Modułu 7 pozostają jednak nienaruszone:

  1. Zapytanie dotyczące ostatnich wizyt.
  2. Zamiast natychmiast zwracać te wizyty, zapisz sygnaturę czasową ostatniego Visit (najstarszej wyświetlonej wizyty) – można bezpiecznie usunąć wszystkie starsze wizyty.
  3. Przygotuj zapowiedź sygnatury czasowej w postaci liczby zmiennoprzecinkowej i ciągu znaków, korzystając ze standardowych narzędzi w języku Python. Wykorzystaj oba te rodzaje funkcji, np. wyświetlanie użytkownikowi, dodawanie do logów, przekazywanie do modułu obsługi itp.
  4. Utwórz zadanie push z tą sygnaturą czasową jako ładunkiem i adresem URL /trim.
  5. Moduł obsługi zadania jest następnie wywoływany za pośrednictwem protokołu HTTP POST na ten adres URL.

Ten przepływ pracy ilustruje użycie ścieżki „przed”, fragment kodu:

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ą takie same, ale Cloud Tasks staje się platformą wykonawczej. Aktualizacje, które zostaną wprowadzone w ramach tej zmiany, to m.in.:

  1. Opakuj zapytanie Visit w blok Pythona with (powtarzająca migracja modułu 2 do Cloud NDB)
  2. Utwórz metadane Cloud Tasks, w tym oczekiwane atrybuty, takie jak ładunek sygnatury czasowej i URL, oraz dodaj typ MIME i zakoduj ładunek w formacie JSON.
  3. Utwórz zadanie z metadanymi i pełną ścieżką kolejki za pomocą klienta interfejsu Cloud Tasks API.

Poniżej przedstawiono zmiany dotyczące fetch_visits():

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. Zaktualizuj moduł obsługi zadań (push)

Funkcja obsługi zadań (push) nie wymaga dużych aktualizacji. wymaga tylko wykonania. Dotyczy to kolejki zadań lub zadań w chmurze. „Kodem jest kod”, jak to mówią. Wprowadziliśmy jednak kilka niewielkich zmian:

  1. Ładunek z sygnaturą czasową został dosłownie przekazany do kolejki zadań, ale na potrzeby Cloud Tasks został on zakodowany w formacie JSON, dlatego po dotarciu do niego należy przeanalizować go w formacie JSON.
  2. Wywołanie HTTP POST do /trim z kolejką zadań miało niejawny typ MIME application/x-www-form-urlencoded, ale w Cloud Tasks jest ono jawnie oznaczone jako application/json, więc istnieje nieco inny sposób wyodrębnienia ł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 module obsługi zadań trim() i po wprowadzeniu tych zmian:

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/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 oczyść ją i zastanów się nad dalszymi czynnościami.

Wdróż i zweryfikuj aplikację

Wdróż aplikację za pomocą: gcloud app deploy. Dane wyjściowe powinny być takie same jak w aplikacji Moduł 7, ale musisz zauważyć, że korzystasz z zupełnie innej usługi kolejek push, co sprawiło, że aplikacja stała się bardziej przenośna.

4aa8a2cb5f527079.png

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

Na tym kończy się migracja z zadań push kolejki zadań App Engine do Cloud Tasks. Jeśli chcesz kontynuować przenoszenie tej aplikacji do Pythona 3 i jeszcze bardziej przeprowadzić migrację z Cloud NDB do Cloud Datastore, rozważ Moduł 9.

Usługa Cloud NDB powstała specjalnie dla programistów App Engine w języku Python 2 i zapewnia użytkownikom prawie identyczną obsługę. Natomiast Cloud Datastore ma własną, natywną bibliotekę klienta stworzoną dla użytkowników nieużywających App Engine lub nowych użytkowników App Engine (Python 3). Ponieważ jednak usługa Cloud NDB jest dostępna dla Pythona 2 i 3, nie ma wymogu migracji do Cloud Datastore.

Zarówno Cloud NDB, jak i Cloud Datastore uzyskują dostęp do Datastore (ale w różny sposób), dlatego jedynym powodem, aby rozważyć przejście na Cloud Datastore, jest sytuacja, w której masz już inne aplikacje, zwłaszcza te spoza App Engine, i chcesz ustandaryzować w ramach jednej biblioteki klienta Datastore. Ta opcjonalna migracja z Cloud NDB do Cloud Datastore jest również omówiona samodzielnie (bez kolejki zadań i zadań w chmurze) w module 3.

Poza modułami 3, 8 i 9 inne moduły migracji koncentrujące się na odejściu od starszych pakietów usług App Engine to m.in.:

App Engine nie jest już jedyną bezserwerową platformą w Google Cloud. Jeśli masz małą aplikację App Engine lub taką, która ma ograniczoną funkcjonalność i chcesz przekształcić ją w samodzielny mikroserwis, albo chcesz podzielić aplikację monolityczną na kilka komponentów wielokrotnego użytku, rozważ przejście na Cloud Functions. Jeśli konteneryzacja stała się częścią przepływu pracy przy tworzeniu aplikacji, zwłaszcza jeśli składa się z potoku CI/CD (ciągła integracja/ciągłe dostarczanie lub wdrażanie), rozważ migrację do Cloud Run. Te scenariusze są opisane w tych modułach:

  • Migracja z App Engine do Cloud Functions: patrz Moduł 11.
  • Migracja z App Engine do Cloud Run: zapoznaj się z Modułem 4, aby skonteneryzować aplikację za pomocą Dockera, lub Moduł 5, aby zrobić to bez kontenerów, Dockera lub Dockerfile.

Przejście na inną bezserwerową platformę jest opcjonalne. Zalecamy, aby przed wprowadzeniem jakichkolwiek zmian wybrać najlepsze opcje dla swoich aplikacji i przypadków użycia.

Niezależnie od tego, który moduł migracji wykorzystasz w następnej kolejności, wszystkie materiały z serwerowej platformy migracji (laboratorium, filmy, kod źródłowy [jeśli jest dostępne]) są dostępne w repozytorium open source. README repozytorium zawiera też wskazówki dotyczące migracji, które warto wziąć pod uwagę, i wszelkich odpowiednich „zamówień” modułów migracji.

7. Dodatkowe materiały

Poniżej znajdziesz dodatkowe materiały dla deweloperów omawiające ten lub powiązany moduł migracji oraz powiązane usługi. Są to miejsca, w których można przesłać opinię o tych treściach, linki do kodu i różne artykuły, które mogą Ci się przydać.

Problemy/opinie dotyczące ćwiczeń z programowania

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 7 (START) i modułach 8 (FINISH) znajdziesz w tabeli poniżej.

Codelab

Python 2

Python 3

Część 7

kod

code (kod nie jest omówiony w tym samouczku)

Moduł 8 (to ćwiczenia z programowania)

kod

(nd.)

Zasoby online

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

Kolejka zadań App Engine i Zadania Cloud

App Engine NDB i Cloud NDB (Datastore)

Platforma App Engine

Inne informacje o Google Cloud

Filmy

Licencja

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