Przeprowadź migrację do Cloud NDB App Engine w języku Python 2 & Aplikacja Cloud Tasks do Pythona 3 i Cloud Datastore (moduł 9)

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 przeniesienie przykładowej aplikacji modułu 8 na język Python 3 oraz przełączenie dostępu do Datastore (Cloud Firestore w trybie Datastore) z używania Cloud NDB do natywnej biblioteki klienta Cloud Datastore i uaktualnienie biblioteki klienta Cloud Tasks do najnowszej wersji.

W części 7 dodaliśmy użycie kolejki zadań do zadań push, a następnie w części 8 przenieśliśmy to wykorzystanie do Cloud Tasks. W module 9 przejdziemy 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:

  • Przenoszenie przykładowej aplikacji modułu 8 do Pythona 3
  • Przełączanie dostępu do Datastore z bibliotek klienta Cloud NDB na biblioteki klienta Cloud Datastore
  • Uaktualnij bibliotekę klienta Cloud Tasks do najnowszej wersji

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

Moduł 7 pokazuje, jak korzystać z zadań push kolejki zadań App Engine w aplikacjach App Engine w języku Python 2 Flask. W module 8 przenosisz tę aplikację z kolejki zadań do Cloud Tasks. W module 9 możesz kontynuować tę podróż i przenieść tę aplikację do języka Python 3, a także przełączyć dostęp do Datastore z Cloud NDB na natywny bibliotekę klienta Cloud Datastore.

Cloud NDB działa zarówno w języku Python 2, jak i w wersji 3, więc jest to wystarczające dla użytkowników App Engine przenoszących swoje aplikacje z Pythona 2 do 3. Dodatkowa migracja bibliotek klienta do Cloud Datastore jest całkowicie opcjonalna. Warto rozważyć tylko jeden powód: masz już aplikacje inne niż App Engine (lub aplikacje w języku Python 3 App Engine), które korzystają już z biblioteki klienta Cloud Datastore i chcesz skonsolidować bazę kodu, aby umożliwić dostęp do Datastore za pomocą tylko jednej biblioteki klienta. Usługa Cloud NDB została utworzona specjalnie dla programistów App Engine w języku Python 2 jako narzędzie do migracji w języku Python 3, więc jeśli nie masz jeszcze kodu korzystającego z biblioteki klienta Cloud Datastore, nie musisz rozważać tej migracji.

Na koniec prace nad biblioteką klienta Cloud Tasks są kontynuowane tylko w języku Python 3, więc przeprowadzamy migrację. od jednej z ostatecznych wersji Pythona 2 po jego współczesną wersję. Na szczęście w Pythonie 2 nie ma żadnych zmian powodujących niezgodność, co oznacza, że nie musisz nic więcej robić.

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

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

1. Konfigurowanie projektu

Jeśli masz już za sobą ćwiczenie z programowania w module 8, 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 8 App Engine. Wykonaj ćwiczenie z modułu 8 (zalecane) lub skopiuj aplikację z modułu 8 z repozytorium. Zacznijmy od kodu modułu 8 („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 9 („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 8, 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ł 8 z programowania, 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. Aktualizacja konfiguracji

requirements.txt

Nowy element requirements.txt jest prawie taki sam jak moduł 8, z tylko jedną dużą zmianą: zastąp element google-cloud-ndb elementem google-cloud-datastore. Wprowadź tę zmianę, aby plik requirements.txt wyglądał tak:

flask
google-cloud-datastore
google-cloud-tasks

Ten plik requirements.txt nie zawiera żadnych numerów wersji, co oznacza, że wybierane są najnowsze wersje. W przypadku wystąpienia rozbieżności, standardem jest używanie numerów wersji do blokowania wersji roboczych aplikacji.

app.yaml

Środowisko wykonawcze App Engine drugiej generacji nie obsługuje wbudowanych bibliotek zewnętrznych (np. 2.x) ani kopiowania niewbudowanych bibliotek. Jedynym wymaganiem w przypadku pakietów innych firm jest ich lista w requirements.txt. Dlatego można usunąć całą sekcję libraries w app.yaml.

Kolejna aktualizacja polega na tym, że środowisko wykonawcze języka Python 3 wymaga użycia platform internetowych, które wykonują własne przekierowania. W związku z tym należy zmienić wszystkie moduły obsługi skryptów na auto. Ponieważ jednak wszystkie trasy muszą zostać zmienione na auto, a ta przykładowa aplikacja nie udostępnia żadnych plików statycznych, nie ma żadnych żadnych modułów obsługi, więc usuń też całą sekcję handlers.

W app.yaml musisz tylko ustawić środowisko wykonawcze na obsługiwaną wersję Pythona 3, na przykład 3.10. Wprowadź tę zmianę, aby nowy, w skrócie app.yaml, zawierał tylko ten pojedynczy wiersz:

runtime: python310

Usuń plik appengine_config.py i lib

Środowiska wykonawcze App Engine nowej generacji ulepszają wykorzystanie pakietów innych firm:

  • Biblioteki wbudowane to sprawdzone przez Google i udostępnione na serwerach App Engine, prawdopodobnie dlatego, że zawierają kod C/C++, którego programiści nie mogą wdrażać w chmurze. Nie są one już dostępne w środowiskach wykonawczych drugiej generacji.
  • W środowiskach wykonawczych drugiej generacji nie trzeba już kopiować niewbudowanych bibliotek (nazywanych czasem „vendoring” lub „samodzielnym grupowaniem”). Zamiast tego powinny znajdować się w regionie requirements.txt, gdzie system kompilacji automatycznie instaluje je w Twoim imieniu podczas wdrażania.

W wyniku tych zmian w zarządzaniu pakietami innych firm nie jest potrzebny ani plik appengine_config.py, ani folder lib. Usuń te pliki. W środowiskach wykonawczych 2 generacji App Engine automatycznie instaluje pakiety innych firm wymienione w zasadzie requirements.txt. Podsumowanie:

  1. Zakaz korzystania z pakietów samodzielnie lub skopiowanych bibliotek zewnętrznych. wymień je w folderze requirements.txt
  2. Brak elementów pip install do folderu lib, co oznacza brak okresu folderu lib
  3. Brak informacji o wbudowanych bibliotekach innych firm (czyli brak sekcji libraries) w app.yaml; wymień je w usłudze requirements.txt
  4. Brak bibliotek innych firm, do których można się odwoływać z aplikacji, oznacza brak pliku appengine_config.py

Jedynym wymaganiem programistycznym jest umieszczenie w pliku requirements.txt wszystkich bibliotek innych firm.

5. Aktualizacja plików aplikacji

Masz tylko 1 plik aplikacji (main.py), więc wszystkie zmiany w tej sekcji dotyczą tylko tego pliku. Poniżej są „różnice” ilustracja przedstawiająca ogólne zmiany, które należy wprowadzić, aby refaktoryzować istniejący kod w nowej aplikacji. Czytelnicy nie powinni czytać kodu wiersz po wierszu, ponieważ jego celem jest tylko obrazowe podsumowanie tego, co jest wymagane w tym refaktoryzacji (możesz otworzyć ją w nowej karcie lub pobrać i powiększyć, jeśli chcesz).

5d043768ba7be742.png

Aktualizowanie importów i inicjowania

Sekcja importowania w main.py modułu 8 używa Cloud NDB i Cloud Tasks. powinien wyglądać tak:

PRZED:

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

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

Logowanie jest uproszczone i ulepszone w środowiskach wykonawczych drugiej generacji, takich jak Python 3:

  • Aby uzyskać pełniejsze możliwości logowania, używaj Cloud Logging.
  • Aby proste logowanie, wyślij do stdout (lub stderr) przez print()
  • Nie musisz używać modułu Pythona logging, więc usuń go.

W związku z tym usuń importowany plik logging i zastąp google.cloud.ndb elementem google.cloud.datastore. Podobnie zmień ds_client, aby wskazać klienta Datastore zamiast klienta NDB. Po wprowadzeniu tych zmian górna część nowej aplikacji wygląda tak:

PO:

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

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

Migracja do Cloud Datastore

Nadszedł czas, aby zastąpić wykorzystanie biblioteki klienta NDB usługą Datastore. Zarówno App Engine NDB, jak i Cloud NDB wymagają modelu danych (klasa); dla tej aplikacji jest to Visit. Funkcja store_visit() działa tak samo we wszystkich pozostałych modułach migracji: rejestruje wizytę przez utworzenie nowego rekordu Visit oraz zapisuje adres IP odwiedzającego klienta i klienta użytkownika (typ przeglądarki).

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

Cloud Datastore nie używa jednak klasy modelu danych, więc ją usuń. Co więcej, Cloud Datastore nie tworzy automatycznie sygnatury czasowej podczas tworzenia rekordów – trzeba to zrobić ręcznie – służy do tego wywołanie datetime.now().

Bez klasy danych zmodyfikowany obiekt store_visit() powinien wyglądać tak:

PO:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

Kluczowa funkcja to fetch_visits(). Nie tylko wykonuje oryginalne zapytanie o najnowsze Visit, ale pobiera też sygnaturę czasową ostatnich wyświetlanych elementów Visit i tworzy zadanie push, które wywołuje /trim (w ten sposób trim()) w celu zbiorczego usunięcia starych elementów Visit. Tutaj wykorzystuje Cloud NDB:

PRZED:

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 (v.to_dict() for v in data), oldest_str

Główne zmiany:

  1. zamienić zapytanie Cloud NDB na odpowiednik Cloud Datastore; style zapytań nieco się różnią.
  2. Datastore nie wymaga używania menedżera kontekstu ani nie umożliwia wyodrębniania jego danych (za pomocą funkcji to_dict()), tak jak robi to Cloud NDB.
  3. Zastąp rejestrowanie połączeń funkcją print()

Po tych zmianach fetch_visits() będzie wyglądać tak:

PO:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('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 visits, oldest_str

Zwykle jest to wszystko, czego potrzebujesz. Niestety wystąpił jeden poważny problem.

(Ewentualnie) Utwórz nową kolejkę (push)

W module 7 dodaliśmy wykorzystanie App Engine taskqueue do istniejącej aplikacji w module 1. Jedną z głównych zalet zadań push jako starszej funkcji App Engine jest to, że „domyślna” kolejka jest tworzona automatycznie. Gdy ta aplikacja została przeniesiona do Cloud Tasks w module 8, ta domyślna kolejka już tam była, więc nadal nie musieliśmy się o to martwić. Zmienia się to w części 9.

Jednym z najważniejszych aspektów, który należy wziąć pod uwagę, jest to, że nowa aplikacja App Engine nie korzysta już z usług App Engine. W związku z tym nie można już zakładać, że App Engine automatycznie tworzy kolejkę zadań w innej usłudze (Cloud Tasks). Zgodnie z opisem utworzenie zadania w fetch_visits() (dla nieistniejącej kolejki) zakończy się niepowodzeniem. Potrzebna jest nowa funkcja, która sprawdzi, czy kolejka („domyślna”) istnieje, a jeśli nie, utwórz ją.

Wywołaj tę funkcję _create_queue_if() i dodaj ją do aplikacji tuż powyżej fetch_visits(), ponieważ tam się ona nazywa. Treść funkcji do dodania:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

Funkcja create_queue() w Cloud Tasks wymaga pełnej ścieżki kolejki oprócz nazwy kolejki. Dla uproszczenia utwórz kolejną zmienną PATH_PREFIX reprezentującą element QUEUE_PATH bez nazwy kolejki (QUEUE_PATH.rsplit('/', 2)[0]). Dodaj jego definicję u góry, aby blok kodu ze wszystkimi stałymi przypisaniami wyglądał tak:

_, 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)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

Teraz zmodyfikuj ostatni wiersz w pliku fetch_visits(), tak aby używał pola _create_queue_if(). Najpierw w razie potrzeby utwórz kolejkę, a następnie utwórz zadanie:

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Zarówno _create_queue_if(), jak i fetch_visits() powinny teraz wyglądać zbiorczo tak:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('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',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Poza koniecznością dodania tego dodatkowego kodu reszta kodu Cloud Tasks pozostaje w większości nienaruszona w module 8. Ostatnim fragmentem kodu, na który należy zwrócić uwagę, jest moduł obsługi zadania.

Zaktualizuj moduł obsługi zadań (push)

W module obsługi zadań trim() kod Cloud NDB wysyła zapytania dotyczące wizyt starszych niż najstarsze wyświetlone. Wykorzystuje zapytanie, które zawiera tylko klucze, aby przyspieszyć działanie. Po co pobierać wszystkie dane, skoro potrzebujesz tylko identyfikatorów wizyt? Gdy zbierzesz wszystkie identyfikatory wizyt, usuń je wszystkie razem, używając funkcji delete_multi() w Cloud NDB.

PRZED:

@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

Podobnie jak w przypadku fetch_visits() znaczna część zmian obejmuje zamianę kodu Cloud NDB na potrzeby Cloud Datastore, dopracowywanie stylów zapytań, wycofywanie użycia menedżera kontekstu oraz zmianę wywołań logowania na print().

PO:

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

Nie zmienił się główny moduł obsługi aplikacji root().

Port do Pythona 3

Ta przykładowa aplikacja została zaprojektowana pod kątem uruchamiania zarówno w językach Python 2, jak i 3. Wszystkie zmiany typowe dla Pythona 3 zostały omówione wcześniej w odpowiednich sekcjach tego samouczka. Nie są wymagane żadne dodatkowe czynności ani biblioteki zgodności.

Aktualizacja Cloud Tasks

Ostateczna wersja biblioteki klienta Cloud Tasks obsługująca Pythona 2 to 1.5.0. W momencie pisania tego artykułu najnowsza wersja biblioteki klienta dla języka Python 3 jest w pełni zgodna z tą wersją, więc dalsze aktualizacje nie są wymagane.

Aktualizacja szablonu HTML

Nie musisz wprowadzać żadnych zmian w pliku szablonu HTML (templates/index.html), więc zawiera to wszystkie zmiany niezbędne do opracowania aplikacji Moduł 9.

6. Podsumowanie/Czyszczenie

Wdróż i zweryfikuj aplikację

Po zaktualizowaniu kodu, głównie przez port w Pythonie 3, wdróż swoją aplikację za pomocą gcloud app deploy. Dane wyjściowe powinny być takie same jak w przypadku aplikacji z aplikacji z modułów 7 i 8, z wyjątkiem tego, że dostęp do bazy danych został przeniesiony do biblioteki klienta Cloud Datastore i uaktualniono go do Pythona 3:

Moduł 7. Strona aplikacji

Ten krok obejmuje ćwiczenia z programowania. Zachęcamy do porównania kodu z tym, co znajduje się w folderze modułu 9. Gratulacje!

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. Opcjonalną migrację z Cloud NDB do Cloud Datastore opisano również samodzielnie (bez kolejki zadań i zadań w chmurze) w module 3. Oprócz modułu 3 dostępne są też inne moduły migracji koncentrujące się na odejściu od starszych pakietów usług App Engine, które warto wziąć pod uwagę:

  • Moduł 2. Migracja z App Engine NDB do Cloud NDB
  • Moduł 3. Migracja z Cloud NDB do Cloud Datastore
  • Moduły 12–13: migracja z App Engine Memcache do Cloud Memorystore
  • Moduły 15–16: migracja z App Engine Blobstore do Cloud Storage
  • Moduły 18–19: Kolejka zadań App Engine (zadania pull) do Cloud Pub/Sub

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

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 8 (START) i modułach 9 (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ęść 8

kod

(nd.)

Moduł 9

(nd.)

kod

Zasoby online

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

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Inne informacje o Google Cloud

Licencja

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