Migracja z App Engine Memcache do Cloud Memorystore (moduł 13)

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 przeprowadzić migrację z App Engine Memcache do Cloud Memorystore (dla Redis). Istnieje również niejawna migracja z App Engine ndb do Cloud NDB, ale jest ona przede wszystkim omówiona w module ćwiczeniowym w module 2. znajdziesz w nim więcej szczegółowych informacji.

Nie używasz Memcache?

Jeśli Twoja aplikacja nie korzysta z App Engine Memcache, możesz pominąć to ćwiczenia z programowania lub wykonać je jako ćwiczenie, aby zapoznać się z migracją do Cloud Memorystore.

Dowiesz się, jak:

• Konfigurowanie instancji Cloud Memorystore (z poziomu konsoli Cloud lub narzędzia gcloud)
• Skonfiguruj oprogramowanie sprzęgające bezserwerowego dostępu do VPC w chmurze (z poziomu konsoli Cloud lub narzędzia gcloud)
• Migracja z App Engine Memcache do Cloud Memorystore
• Wdrażanie buforowania w przykładowej aplikacji za pomocą Cloud Memorystore
• Migracja z App Engine ndb do Cloud NDB

Czego potrzebujesz

• projekt Google Cloud z aktywnym kontem rozliczeniowym (nie jest to bezpłatne ćwiczenia z programowania);
• Podstawowe umiejętności w języku Python
• praktyczna znajomość typowych poleceń w Linuksie
• Podstawowa wiedza o tworzeniu i wdrażaniu aplikacji App Engine.
• działającą aplikację App Engine w module 12 (ukończ ćwiczenie z programowania dotyczące modułu 12 [zalecane]) lub skopiuj aplikację modułu 12 z repozytorium);

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

To ćwiczenie w Codelabs pokazuje, jak przenieść przykładową aplikację z App Engine Memcache (i NDB) do Cloud Memorystore (i Cloud NDB). Ten proces obejmuje zastąpienie zależności od pakietów usług App Engine w pakiecie, dzięki czemu Twoje aplikacje staną się bardziej przenośne. Możesz pozostać przy App Engine lub przejść na dowolną z alternatywnych rozwiązań opisanych wcześniej.

Ta migracja wymaga większego wysiłku w porównaniu z innymi migracjami w tej serii. Zalecanym zastępcą usługi App Engine Memcache jest Cloud Memorystore – w pełni zarządzana usługa pamięci podręcznej działająca w chmurze. Memorystore obsługuje 2 popularne silniki buforowania typu open source: Redis i Memcached. Ten moduł migracji korzysta z Cloud Memorystore for Redis. Więcej informacji znajdziesz w omówieniu Memorystore i Redis.

Memorystore wymaga działającego serwera, więc trzeba też korzystać z Cloud VPC. W szczególności należy utworzyć oprogramowanie sprzęgające bezserwerowego dostępu do VPC, aby aplikacja App Engine mogła łączyć się z instancją Memorystore przez swój prywatny adres IP. Gdy ukończysz to ćwiczenie, zaktualizujesz aplikację tak, że choć będzie ona działać tak jak wcześniej, domyślną usługą pamięci podręcznej będzie Cloud Memorystore, która zastąpi usługę Memcache App Engine.

Ten samouczek zaczyna się od przykładowej aplikacji z modułu 12 w języku Python 2, po czym następuje dodatkowe, opcjonalne, drobne uaktualnienie do Pythona 3. Jeśli wiesz już, jak uzyskać dostęp do pakietów App Engine w języku Python 3 za pomocą pakietu SDK App Engine w języku Python 3, możesz zacząć od przykładowej aplikacji z modułu 12 w języku Python 3. Wiąże się to z usunięciem użycia pakietu SDK, ponieważ Memorystore nie należy do pakietu App Engine. Nauka korzystania z pakietu SDK App Engine w języku Python 3 nie jest w tym samouczku.

W tym samouczku omawiamy kluczowe etapy:

1. Konfiguracja/praca
2. Skonfiguruj usługi buforowania
3. Aktualizowanie plików konfiguracji
4. Zaktualizuj główną aplikację

3. Konfiguracja/praca

Przygotuj projekt Cloud

Zalecamy ponowne użycie tego samego projektu, który został użyty do ukończenia modułu 12 z programowania. Możesz też utworzyć nowy projekt lub wykorzystać inny istniejący projekt. Każde ćwiczenia z programowania w tej serii mają parametr „START” (kod odniesienia) i „FINISH”, (przeniesiona aplikacja). Podany jest kod FINISH, dzięki któremu w razie problemów możesz porównać swoje rozwiązania z naszymi. Jeśli coś pójdzie nie tak, zawsze możesz wrócić do START. Te punkty kontrolne pozwalają efektywnie nauczyć się przeprowadzać migracje.

Niezależnie od tego, którego projektu Cloud używasz, upewnij się, że ma on aktywne konto rozliczeniowe. Sprawdź też, czy funkcja App Engine jest włączona. Zapoznaj się z tymi samouczkami i upewnij się, że znasz ogólne konsekwencje kosztów. Jednak w przeciwieństwie do innych treści z tej serii to ćwiczenie w Codelabs korzysta z zasobów Google Cloud, które nie mają poziomu bezpłatnego, więc jego ukończenie wiąże się z pewnymi kosztami. Zapewniamy bardziej szczegółowe informacje o kosztach wraz z zaleceniami dotyczącymi zmniejszania wykorzystania, w tym instrukcje zwalniania zasobów w celu zminimalizowania opłat.

Pobierz przykładową aplikację bazową

To ćwiczenie z programowania przedstawia krok po kroku migrację na podstawie kodu modułu podstawowego 12, od którego zaczynamy. Po zakończeniu zobaczysz działającą aplikację modułu 13, która bardzo przypomina kod z jednego z folderów FINISH. Oto materiały:

• START: aplikacja moduł 12 Python 2 (mod12) lub Python 3 (mod12b)
• ZAKOŃCZ: aplikacja Moduł 13 Python 2 (mod13a) lub Python 3 (mod13b)
• Całe repozytorium migracji (klonuj lub pobierz plik ZIP)

Folder START powinien zawierać następujące pliki:

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

Jeśli zaczynasz od wersji Pythona 2, dostępny będzie też plik appengine_config.py i być może folder lib (jeśli ukończysz Moduł 12 z programu).

Wdróż ponownie aplikację Moduł 12

Pozostałe kroki:

1. Ponownie zapoznaj się z narzędziem wiersza poleceń gcloud (w razie potrzeby)
2. (w razie potrzeby ponowne wdrożenie kodu modułu 12 w App Engine);

Użytkownicy języka Python 2 powinni usunąć i ponownie zainstalować folder lib za pomocą tych poleceń:

rm -rf ./lib; pip install -t lib -r requirements.txt                

Teraz wszyscy (użytkownicy Pythona 2 i 3) powinni przesłać kod do App Engine za pomocą tego polecenia:

gcloud app deploy                

Po wdrożeniu sprawdź, czy aplikacja wygląda i działa tak samo jak aplikacja w module 12. Jest to aplikacja internetowa, która śledzi wizyty i buforuje je dla tego samego użytkownika przez godzinę:

Ponieważ ostatnie wizyty są zapisywane w pamięci podręcznej, odświeżanie strony powinno ładować się dość szybko.

4. Skonfiguruj usługi buforowania

Cloud Memorystore nie jest bezserwerowa. Instancja jest wymagana. w tym przypadku z uruchomionym Redis. W przeciwieństwie do Memcache Memorystore to samodzielna usługa Cloud i nie ma poziomu bezpłatnego, więc zanim przejdziesz dalej, sprawdź informacje o cenach Memorystore for Redis. Aby zminimalizować koszty tego ćwiczenia, zalecamy jak najmniejszą ilość zasobów do działania: typ usługi Podstawowy i pojemność 1 GB.

Instancja Memorystore znajduje się w innej sieci niż Twoja aplikacja (instancje) App Engine, dlatego musisz utworzyć oprogramowanie sprzęgające bezserwerowego dostępu do VPC, aby usługa App Engine miała dostęp do zasobów Memorystore. Aby zminimalizować koszty VPC, wybierz typ instancji (f1-micro) i jak najmniejszą liczbę instancji, o które prosisz (zalecamy co najmniej 2, maksymalnie 3). Zajrzyj też na stronę z informacjami o cenach VPC.

Koszt: ten samouczek NIE jest bezpłatny

Większość kursów z tej serii dotyczących migracji można ukończyć bezpłatnie, ale ten wyjątek jest wyjątkiem. Ani Cloud Memorystore ani Cloud VPC nie mają poziomu bezpłatnego, więc nie można kontynuować bez naliczania opłat. Zdecydowanie zalecamy, aby przed kontynuowaniem sprawdzić informacje o cenach obu usług. Jeśli zależy Ci na ograniczeniu kosztów, ale chcesz kontynuować ten proces, zalecamy wybranie najtańszych opcji. Aby ograniczyć koszty do minimum, niezwłocznie zwolnij te zasoby po ukończeniu ćwiczeń z programowania.

Powtarzamy te rekomendacje dotyczące obniżania kosztów, prowadząc Cię przez proces tworzenia każdego wymaganego zasobu. Ponadto podczas tworzenia zasobów Memorystore i VPC w konsoli Cloud w prawym górnym rogu wyświetla się kalkulator cen każdej usługi, który podaje szacunkowe miesięczne koszty (zobacz ilustrację poniżej). Wartości te dostosowują się automatycznie, gdy zmienisz opcje. Mniej więcej to otrzymasz:

Oba zasoby są wymagane, nie ma znaczenia, które z nich utworzysz. Jeśli najpierw utworzysz instancję Memorystore, aplikacja App Engine nie będzie mogła uzyskać do niej dostępu bez oprogramowania sprzęgającego VPC. Podobnie, jeśli najpierw utworzysz oprogramowanie sprzęgające VPC, w tej sieci VPC nie będzie niczego, z czym aplikacja App Engine mogłaby rozmawiać. W tym samouczku najpierw tworzysz instancję Memorystore, a następnie oprogramowanie sprzęgające VPC.

Gdy oba zasoby będą online, dodaj odpowiednie informacje do elementu app.yaml, aby aplikacja mogła uzyskać dostęp do pamięci podręcznej. Możesz też skorzystać z przewodników dotyczących Pythona 2 lub Pythona 3 w oficjalnej dokumentacji. Warto też zapoznać się z przewodnikiem dotyczącym buforowania danych na stronie migracji Cloud NDB ( Python 2 lub Python 3).

Utwórz wszystkie zasoby w regionie App Engine

Poniżej utworzysz wszystkie dodatkowe zasoby Cloud niezbędne do używania Cloud Memorystore jako usługi buforowania aplikacji App Engine. Zanim to zrobisz, musisz utworzyć instancję Memorystore i oprogramowanie sprzęgające bezserwerowego dostępu do VPC w tym samym regionie co aplikacja App Engine.

Tworzenie instancji Cloud Memorystore

Cloud Memorystore nie ma poziomu bezpłatnego, więc zalecamy przydzielenie jak najmniejszej ilości zasobów do wykonania ćwiczenia w Codelabs. Możesz ograniczyć koszty do minimum, korzystając z tych ustawień:

• Wybierz najniższy typ usługi: Podstawowy (domyślnie konsoli: „Standard”, gcloud domyślnie: „Podstawowy”).
• Wybierz najmniejszą ilość miejsca na dane: 1 GB (domyślnie w konsoli: 16 GB, domyślnie: gcloud: 1 GB).
• Najnowsze wersje dowolnego oprogramowania wymagają zwykle dużej ilości zasobów, ale wybieranie najstarszej wersji też prawdopodobnie nie jest zalecane. Druga najnowsza wersja to obecnie wersja Redis 5.0 (domyślnie w konsoli: 6.x)

Mając to na uwadze, w następnej sekcji przeprowadzimy Cię przez proces tworzenia instancji w konsoli Cloud. Jeśli wolisz zrobić to z poziomu wiersza poleceń, pomiń ten krok.

W konsoli Google Cloud

Otwórz stronę Cloud Memorystore w konsoli Cloud (może pojawić się prośba o podanie informacji rozliczeniowych). Jeśli usługa Memorystore nie została jeszcze włączona, pojawi się prośba o włączenie tej funkcji:

Po jej włączeniu (prawdopodobnie razem z płatnościami) pojawi się panel Memorystore. Tutaj znajdziesz wszystkie instancje utworzone w projekcie. W projekcie poniżej nie ma żadnych wierszy, dlatego widzisz komunikat „Brak wierszy do wyświetlenia”. Aby utworzyć instancję Memorystore, u góry kliknij Utwórz instancję:

Aktualizacje Cloud Console

Pamiętaj, że interfejs Cloud Console od czasu do czasu się zmienia, więc jego wygląd może nie wyglądać dokładnie tak, jak na zrzutach ekranu.

Na tej stronie znajduje się formularz, w którym wpisz odpowiednie ustawienia, aby utworzyć instancję Memorystore:

Aby ograniczyć koszty tego samouczka i jego przykładowej aplikacji, postępuj zgodnie z zaleceniami omówionymi wcześniej. Po wybraniu odpowiednich opcji kliknij Utwórz. Proces tworzenia trwa kilka minut. Po zakończeniu skopiuj adres IP instancji i numer portu, aby dodać go do sieci app.yaml.

Wiersz poleceń

Tworzenie instancji Memorystore z poziomu konsoli Cloud jest bardzo pomocne, ale niektórzy wolą używać wiersza poleceń. Zanim przejdziesz dalej, upewnij się, że usługa gcloud została zainstalowana i zainicjowana.

Podobnie jak w przypadku konsoli Cloud, musi być włączona usługa Cloud Memorystore for Redis. Uruchom polecenie gcloud services enable redis.googleapis.com i poczekaj na jego zakończenie, jak w tym przykładzie:

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

Jeśli usługa jest już włączona, uruchomienie polecenia (ponownie) nie ma żadnych (negatywnych) efektów ubocznych. Gdy usługa zostanie włączona, utwórzmy instancję Memorystore. Polecenie wygląda tak:

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

Wybierz nazwę swojej instancji Memorystore. ten moduł używa „demo-ms” jako nazwę wraz z identyfikatorem projektu „my-project”. Region tej przykładowej aplikacji to us-central1 (taki sam jak us-central), ale jeśli obawiasz się o opóźnienia, możesz użyć takiego regionu bliżej Ciebie. Musisz wybrać ten sam region co aplikacja App Engine. Możesz wybrać dowolną preferowaną wersję Redis, ale używamy wersji 5 zgodnie z zaleceniami podanymi wcześniej. Z uwzględnieniem tych ustawień uruchom polecenie (wraz z powiązanymi danymi wyjściowymi):

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

W przeciwieństwie do domyślnych ustawień Cloud Console w gcloud domyślnie ustawiona jest minimalna ilość zasobów. Spowoduje to, że polecenie nie wymaga typu usługi ani ilości miejsca na dane. Tworzenie instancji Memorystore może potrwać kilka minut. Po zakończeniu zanotuj adres IP i numer portu instancji, ponieważ wkrótce zostaną one dodane do app.yaml.

Potwierdź utworzenie instancji

Z konsoli Cloud lub wiersza poleceń

Niezależnie od tego, czy Twoja instancja została utworzona w konsoli Cloud czy w wierszu poleceń, możesz sprawdzić, czy jest ona dostępna i gotowa do użycia. Wystarczy, że użyjesz tego polecenia: gcloud redis instances list --region REGION

Oto polecenie służące do sprawdzania instancji w regionie us-central1 wraz z oczekiwanymi danymi wyjściowymi przedstawiającymi utworzoną właśnie instancję:

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

Gdy pojawi się prośba o podanie informacji o instancji lub o skonfigurowanie aplikacji, użyj interfejsów HOST i PORT (a nie RESERVED_IP). W panelu Cloud Memorystore w konsoli Cloud powinna pojawić się ta instancja:

Z maszyny wirtualnej Compute Engine

Jeśli masz maszynę wirtualną Compute Engine, możesz wysłać z niej bezpośrednie polecenia do instancji Memorystore, aby potwierdzić, że działa ona prawidłowo. Pamiętaj, że korzystanie z maszyny wirtualnej może wiązać się z kosztami niezależnie od zasobów, których już używasz.

Utwórz oprogramowanie sprzęgające bezserwerowego dostępu do VPC

Podobnie jak w przypadku Cloud Memorystore możesz utworzyć bezserwerowe oprogramowanie sprzęgające Cloud VPC w konsoli Cloud lub z poziomu wiersza poleceń. Podobnie środowisko Cloud VPC nie ma poziomu bezpłatnego, więc zalecamy przydzielenie jak najmniejszej ilości zasobów do wykonania ćwiczenia z programowania, aby utrzymać koszty na minimalnym poziomie. Takie ustawienia można osiągnąć dzięki tym ustawieniom:

• Wybierz najmniejszą maksymalną liczbę instancji: 3 (konsola i gcloud, domyślnie: 10)
• Wybierz najtańszy typ maszyny: f1-micro (domyślnie w konsoli: e2-micro, brak domyślnie: gcloud)

W następnej sekcji dowiesz się, jak utworzyć oprogramowanie sprzęgające z poziomu konsoli Cloud przy użyciu powyższych ustawień Cloud VPC. Jeśli wolisz zrobić to z poziomu wiersza poleceń, przejdź do następnej sekcji.

Z konsoli Cloud

Otwórz Cloud Networking „Bezserwerowy dostęp do VPC”. w Cloud Console (może pojawić się prośba o podanie informacji rozliczeniowych). Jeśli interfejs API nie został jeszcze włączony, wyświetli się prośba o jego włączenie:

Po włączeniu interfejsu API (i ewentualnie także w ramach rozliczeń) otworzy się panel, w którym zobaczysz wszystkie utworzone oprogramowanie sprzęgające VPC. W projekcie poniżej nie ma żadnego projektu, dlatego wyświetla się komunikat „Brak wierszy do wyświetlenia”. U góry konsoli kliknij Utwórz oprogramowanie sprzęgające:

W formularzu podaj odpowiednie ustawienia:

Wybierz odpowiednie ustawienia dla swoich aplikacji. W tym samouczku i jego przykładowej aplikacji o minimalnych potrzebach konieczne jest zminimalizowanie kosztów, dlatego zastosuj się do omówionych wcześniej zaleceń. Po wybraniu odpowiednich opcji kliknij Utwórz. Wymaganie oprogramowania sprzęgającego VPC może potrwać kilka minut.

Z wiersza poleceń

Zanim utworzysz oprogramowanie sprzęgające VPC, włącz najpierw interfejs API bezserwerowego dostępu do VPC. Podobne dane wyjściowe powinny pojawić się po uruchomieniu następującego polecenia:

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

Gdy interfejs API jest włączony, oprogramowanie sprzęgające VPC jest tworzone za pomocą polecenia podobnego do tego:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

Wybierz nazwę oprogramowania sprzęgającego oraz nieużywany początkowy blok CIDR /28. Przyjęto w tym samouczku te założenia:

• Identyfikator projektu: my-project
• Nazwa oprogramowania sprzęgającego VPC: demo-vpc
• Minimalna liczba instancji: 2 (domyślna) i maksymalna liczba instancji: 3
• Typ instancji: f1-micro
• Region: us-central1
• Blok CIDR IPv4: 10.8.0.0/28 (zgodnie z zaleceniem w konsoli Cloud)

Jeśli wykonasz poniższe polecenie, mając na uwadze powyższe założenia, dane wyjściowe będą podobne do tych poniżej:

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

W powyższym poleceniu brakuje określenia wartości domyślnych, np. minimalnej liczby instancji 2 i sieci o nazwie default. Tworzenie oprogramowania sprzęgającego VPC trwa kilka minut.

Potwierdź utworzenie oprogramowania sprzęgającego

Po zakończeniu procesu uruchom to polecenie gcloud (przy założeniu, że jest to region us-central1), aby potwierdzić, że kod został utworzony i gotowy do użycia:

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

Podobnie na pulpicie nawigacyjnym powinno zostać wyświetlone właśnie utworzone oprogramowanie sprzęgające:

Zapisz identyfikator projektu Cloud, nazwę oprogramowania sprzęgającego VPC i region.

Po utworzeniu dodatkowych niezbędnych zasobów Cloud (zarówno za pomocą wiersza poleceń, jak i konsoli) czas zaktualizować konfigurację aplikacji, aby spełniała te wymagania.

5. Aktualizowanie plików konfiguracji

Najpierw musisz wprowadzić wszystkie niezbędne zmiany w plikach konfiguracji. Głównym celem tego ćwiczenia z programowania jest ułatwienie użytkownikom języka Python 2 w migracji, jednak w każdej z poniższych sekcji podsumowujemy informacje o dalszym przenoszeniu do Pythona 3.

requirements.txt

W tej sekcji dodajemy pakiety, które będą obsługiwać zarówno Cloud Memorystore, jak i Cloud NDB. W przypadku Cloud Memorystore for Redis wystarczy użyć standardowego klienta Redis na potrzeby Pythona (redis), ponieważ nie ma takiej biblioteki klienta. Dołącz redis i google-cloud-ndb do requirements.txt, łącząc flask z modułu 12:

flask
redis
google-cloud-ndb

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 numery wersji, które zostaną zablokowane w wersjach roboczych.

app.yaml

Nowe sekcje do dodania

Środowisko wykonawcze App Engine w języku Python 2 wymaga określonych pakietów zewnętrznych firm, gdy używane są interfejsy Cloud APIs, takie jak Cloud NDB (grpcio i setuptools). Użytkownicy języka Python 2 muszą wyświetlić listę wbudowanych bibliotek, takich jak te, wraz z wersją dostępną w języku 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 swojej aplikacji może już ona zawierać sekcję libraries. Jeśli tak, a brakuje grpcio i setuptools, po prostu dodaj je do istniejącej sekcji libraries.

Nasza przykładowa aplikacja wymaga instancji Cloud Memorystore i informacji o oprogramowaniu sprzęgającym VPC, dlatego dodaj do app.yaml te 2 nowe sekcje niezależnie od używanego środowiska wykonawczego Pythona:

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

To wszystko na dziś. Twój zaktualizowany app.yaml powinien teraz wyglądać tak:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Poniżej znajdziesz podsumowanie działań typu „przed i po” zmiany, które należy zastosować w aplikacji app.yaml:

*Różnice w Pythonie 3

Ta sekcja jest opcjonalna i tylko w przypadku przenoszenia do Pythona 3. Aby to zrobić, musisz wprowadzić kilka zmian w konfiguracji Pythona 2. Pomiń tę sekcję, jeśli w tej chwili nie przechodzisz na wyższą wersję.

Ani threadsafe, ani api_version nie są używane w środowisku wykonawczym Pythona 3, więc usuń oba te ustawienia. Najnowsze środowisko wykonawcze App Engine nie obsługuje wbudowanych bibliotek innych firm ani kopiowania niewbudowanych bibliotek. W przypadku pakietów innych firm jedynym wymaganiem jest ich dodanie w polu requirements.txt. Dlatego można usunąć całą sekcję libraries w app.yaml.

Następnie środowisko wykonawcze Pythona 3 wymaga użycia platform internetowych, które wykonują własne routing, dlatego pokazaliśmy deweloperom, jak przejść z Webp2 do Flask w module 1. W związku z tym należy zmienić wszystkie moduły obsługi skryptów na auto. Ta aplikacja nie obsługuje żadnych plików statycznych, dlatego jest „bezcelowa” .autohandlers W związku z tym nowy, skrócony app.yaml, dopracowany pod kątem języka Python 3, powinien zostać skrócony do poniższego formatu:

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Podsumowanie różnic w app.yaml podczas przenoszenia do Pythona 3:

• Usuń ustawienia threadsafe i api_version
• Usuń sekcję libraries
• Usuń sekcję handlers (lub tylko script modułów obsługi, jeśli aplikacja udostępnia pliki statyczne)

Zastąp wartości

Wartości w nowych sekcjach dotyczące Memorystore i oprogramowania sprzęgającego VPC to tylko symbole zastępcze. Zastąp wartości pisane wielką literą (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) wartościami zapisanymi podczas tworzenia tych zasobów wcześniej. Jeśli chodzi o instancję Memorystore, upewnij się, że używasz HOST (nie RESERVED_IP) oraz PORT. Oto szybki sposób wiersza poleceń, aby uzyskać HOST i PORT przy założeniu, że nazwa instancji to demo-ms, a REGION to us-central1:

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

Jeśli nasz przykładowy adres IP instancji Redis to 10.10.10.10, w projekcie my-project znajduje się port 6379, który znajduje się w regionie us-central1 (o nazwie oprogramowania sprzęgającego VPC demo-vpc), te sekcje w regionie app.yaml będą wyglądać tak:

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

Utwórz lub zaktualizuj plik appengine_config.py

Dodanie obsługi wbudowanych bibliotek innych firm

Tak jak w przypadku app.yaml, dodaj wykorzystanie bibliotek grpcio i setuptools. Aby umożliwić obsługę wbudowanych bibliotek innych firm, zmodyfikuj appengine_config.py. Jeśli wydaje się to znajome, to jest to wymagane również w module 2 podczas migracji z App Engine ndb do Cloud NDB. Dokładną zmianą jest dodanie folderu lib do zbioru roboczego setuptools.pkg_resources:

*Różnice w Pythonie 3

Ta sekcja jest opcjonalna i tylko w przypadku przenoszenia do Pythona 3. Jedną z powitalnych zmian w App Engine drugiej generacji jest to, że kopiowanie (czasami nazywane „odsprzedażą”) (niewbudowanych) pakietów innych firm i odwoływanie się do wbudowanych pakietów innych firm w app.yaml nie jest już konieczne. Oznacza to, że można usunąć cały plik appengine_config.py.

6. Aktualizacja plików aplikacji

Masz tylko 1 plik aplikacji (main.py), więc wszystkie zmiany w tej sekcji dotyczą tylko tego pliku. Udostępniliśmy obrazkowe przedstawienie zmian, które wprowadzimy w celu migracji tej aplikacji do Cloud Memorystore. Ma jedynie charakter poglądowy, a nie wymaga dokładnej analizy. Cała praca polega na zmianach, które wprowadzamy w kodzie.

Omówmy po kolei te poszczególne sekcje, zaczynając od góry.

Aktualizowanie importów

Sekcja importowania w main.py modułu 12 używa Cloud NDB i Cloud Tasks. Oto ich operacje importu:

PRZED:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

Przejście na Memorystore wymaga odczytania zmiennych środowiskowych, co oznacza, że potrzebujemy modułu os w języku Python oraz klienta redis (Python Redis). Redis nie mogą buforować obiektów Python, więc utwórz listę ostatnich wizyt za pomocą pickle, więc ją zaimportuj. Jedną z zalet Memcache jest to, że serializacja obiektów odbywa się automatycznie, natomiast Memorystore to rozwiązanie raczej „zrób to sam”. Na koniec przejdź z App Engine ndb na Cloud NDB, zastępując google.appengine.ext.ndb elementem google.cloud.ndb. Po tych zmianach import powinien wyglądać tak:

PO:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

Inicjowanie aktualizacji

Inicjowanie modułu 12 obejmuje utworzenie wystąpienia obiektu aplikacji Flask app i ustawienie stałej wartości przechowywania buforowania przez godzinę:

PRZED:

app = Flask(__name__)
HOUR = 3600

Korzystanie z interfejsów Cloud APIs wymaga klienta, więc utwórz instancję klienta Cloud NDB zaraz po narzędziu Flask. Następnie pobierz adres IP i numer portu instancji Memorystore ze zmiennych środowiskowych ustawionych w zasadzie app.yaml. Na podstawie tych informacji utwórz instancję klienta Redis. Oto, jak wygląda Twój kod po wprowadzeniu aktualizacji:

PO:

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

*Migracja do Pythona 3

Ta sekcja jest opcjonalna, jeśli zaczynasz od aplikacji Moduł 12 w języku Python 3. Jeśli tak, jest kilka wymaganych zmian związanych z importowaniem i inicjowaniem.

Ponieważ Memcache jest usługą pakietową App Engine, jej użycie w aplikacji w języku Python 3 wymaga pakietu SDK App Engine, a w szczególności opakowania aplikacji WSGI (oraz innej niezbędnej konfiguracji):

PRZED:

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

Przechodzimy do Cloud Memorystore (a nie do pakietu App Engine, takiego jak Memcache), dlatego należy usunąć możliwość korzystania z pakietu SDK. To bardzo proste – usuniesz po prostu cały wiersz, który importuje zarówno memcache, jak i wrap_wsgi_app. Usuń też połączenie z numerem wrap_wsgi_app(). W wyniku tych aktualizacji ta część aplikacji (a dokładnie cała aplikacja) jest taka sama jak wersja Pythona 2.

PO:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

Na koniec wyłącz używanie pakietu SDK z wierszy app.yaml (usuń wiersz: app_engine_apis: true) i requirements.txt (usuń wiersz: appengine-python-standard).

Migracja do Cloud Memorystore (i Cloud NDB)

Model danych Cloud NDB ma być zgodny z ndb App Engine, co oznacza, że definicja obiektów Visit pozostaje taka sama. Naśladując migrację modułu 2 do Cloud NDB, wszystkie wywołania Datastore w store_visit() i fetch_visits() są rozszerzone i umieszczane w nowym bloku with (ponieważ wymagane jest użycie menedżera kontekstu Cloud NDB). Oto wywołania przed tą zmianą:

PRZED:

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)

Dodaj blok with ds_client.context() do obu funkcji i umieść w nim wywołania Datastore (z wcięciem). W takim przypadku w samych połączeniach nie są wymagane żadne zmiany:

PO:

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

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

Teraz przyjrzymy się zmianom dotyczącym buforowania. Oto funkcja main() z modułu 12:

PRZED:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

Redis ma polecenie „get” i „set” tak samo jak Memcache. Wystarczy zamienić odpowiednie biblioteki klienta. Zgadza się? Prawie dobrze. Jak wspomnieliśmy wcześniej, nie możemy buforować listy w Pythonie z Redis (bo najpierw musi zostać zserializowana, bo coś, co robi to automatycznie), dlatego w wywołaniu set() polecenie „pickle” odwiedziny w ciągu znaków pickle.dumps(). Podobnie przy pobieraniu wizyt z pamięci podręcznej, trzeba usunąć wybór punktu za pomocą parametru pickle.loads() tuż za get(). Oto główny moduł obsługi po wprowadzeniu tych zmian:

PO:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

    return render_template('index.html', visits=visits)

To już koniec zmian wymaganych w main.py podczas konwertowania użycia Memcache w przykładowej aplikacji do Cloud Memorystore. A co z szablonem HTML i przenoszeniem do Pythona 3?

Zaktualizować plik szablonu HTML i portować do Pythona 3?

Niespodzianka! Nie musisz nic robić, ponieważ aplikacja została zaprojektowana tak, aby działać w językach Python 2 i 3 bez żadnych zmian w kodzie ani bez bibliotek zgodności. Znajdziesz: main.py. jest identyczne w mod13a (2.x) i mod13b (3.x) „FINISH” foldery. To samo dotyczy requirements.txt , z wyjątkiem różnic w numerach wersji (jeśli są używane). Interfejs pozostaje niezmieniony, dlatego templates/index.html nie otrzymuje żadnych aktualizacji.

Wszystko, co było konieczne do uruchomienia tej aplikacji w przypadku App Engine w języku Python 3, zostało wykonane wcześniej: z pliku app.yaml usunięto niepotrzebne dyrektywy, a zarówno folder appengine_config.py, jak i folder lib zostały usunięte, ponieważ nie są używane w Pythonie 3.

Automatyczne buforowanie w App Engine NDB i Cloud NDB

Choć jawnie przeprowadzamy migrację z App Engine Memcache do Cloud Memorystore, pamiętaj, że zarówno App Engine ndb, jak i Cloud NDB zapewniają automatyczne buforowanie odpowiednio do Memcache lub Memorystore odpowiednio dla Pythona 2 lub 3. Informacje o buforowaniu pod kątem ndb w buforowaniu NDB i Cloud NDB znajdziesz w artykule Włączanie buforowania danych. Instrukcje tej drugiej funkcji dokładnie odzwierciedlają instrukcje z tego ćwiczenia z programowania. Dodatkowe funkcje znajdziesz w sekcji Kontekst i opcje transakcji.

Powodem, dla którego nie użyliśmy tego automatycznego buforowania, jest to, że nasza przykładowa aplikacja nie wysyła zapytań dotyczących poszczególnych encji Datastore (do których można łatwo uzyskać dostęp z pamięci podręcznej). Zamiast tego ta aplikacja zapisuje w pamięci podręcznej tablicę encji (ostatnie wizyty), która jest zbyt specyficzna dla konkretnego przypadku użycia i nie jest obsługiwana przez warstwę automatycznej pamięci podręcznej. Twoja aplikacja może jednak wykonywać takie zapytania i warto skorzystać z tej funkcji, aby uprościć korzystanie z urządzenia.

7. 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ę

Ostatnim etapem jest zawsze wdrożenie przykładowej aplikacji. Dla programistów Pythona 2: usuń i ponownie zainstaluj lib za pomocą poniższych poleceń. Jeśli w systemie masz zainstalowane języki Python 2 i 3, konieczne może być jawne uruchomienie polecenia pip2.

rm -rf ./lib
pip install -t lib -r requirements.txt

Deweloperzy korzystający z języka Python 2 i 3 powinni teraz wdrażać swoje aplikacje przy użyciu:

gcloud app deploy

Po prostu przerobiłeś swoje rzeczy pod maską i w celu uzyskania zupełnie innej usługi buforowania, sama aplikacja powinna działać tak samo jak aplikacja w module 12:

Ten krok obejmuje ćwiczenia z programowania. Zachęcamy do porównania zaktualizowanej przykładowej aplikacji z folderami modułu 13: mod13a (Python 2) lub mod13b (Python 3).

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:

• Cloud Memorystore wymaga instancji i nie ma poziomu bezpłatnego; więcej informacji o kosztach wykorzystania znajdziesz na stronie z cennikiem.
• Oprogramowanie sprzęgające bezserwerowego dostępu do VPC Cloud wymaga instancji i nie ma poziomu bezpłatnego. Aby dowiedzieć się więcej o kosztach wykorzystania, zobacz jego sekcję na stronie z cennikiem Cloud VPC.
• Cloud Datastore (Cloud Firestore w trybie Datastore) ma poziom bezpłatny. więcej informacji znajdziesz na tej stronie z cennikiem.

Ten samouczek dotyczył wykorzystania 4 usług Cloud:

• App Engine
• Cloud Datastore
• Cloud Memorystore
• Cloud VPC

Poniżej znajdziesz wskazówki, jak zwolnić te zasoby oraz jak uniknąć opłat i zminimalizować ich opłaty.

Wyłącz instancję Memorystore i oprogramowanie sprzęgające VPC

Są to usługi bez poziomu bezpłatnego, więc płatność jest naliczana w tej chwili. Jeśli nie zamkniesz projektu Cloud (zobacz następną sekcję), musisz usunąć zarówno instancję Memorystore, jak i oprogramowanie sprzęgające VPC, aby zatrzymać płatności. Podobnie jak w przypadku tworzenia tych zasobów, możesz je także zwolnić z poziomu konsoli Cloud lub wiersza poleceń.

Z konsoli Cloud

Aby usunąć instancję Memorystore, wróć do panelu Memorystore i kliknij identyfikator instancji:

Na stronie szczegółów tej instancji kliknij „Usuń”. i potwierdź:

Aby usunąć oprogramowanie sprzęgające VPC, otwórz jego panel i zaznacz pole wyboru obok oprogramowania sprzęgającego, które chcesz usunąć, a następnie kliknij „Usuń”. i potwierdź:

Z wiersza poleceń

Ta para poleceń gcloud usuwa odpowiednio instancję Memorystore i oprogramowanie sprzęgające VPC:

• gcloud redis instances delete INSTANCE --region REGION
• gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

Jeśli identyfikator projektu nie został ustawiony przy użyciu parametru gcloud config set project, konieczne może być podanie identyfikatora --project PROJECT_ID. Jeśli instancja Memorystore ma nazwę demo-ms, a oprogramowanie sprzęgające VPC demo-vpc i obie znajdują się w regionie us-central1, uruchom tę parę poleceń i potwierdź:

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

Wykonanie każdego żądania zajmuje kilka minut. Te kroki są opcjonalne, jeśli zdecydujesz się zamknąć cały projekt Cloud w sposób opisany powyżej. Nadal jednak będziemy naliczać opłaty do czasu zakończenia procesu wyłączania.

Dalsze kroki

Oprócz tego samouczka dostępne są też inne moduły migracji koncentrujące się na odejściu od starszych pakietów usług, które warto rozważyć:

• Moduł 2. Migracja z App Engine ndb do Cloud NDB
• Moduły 7–9. Migracja z kolejki zadań App Engine w trybie push do Cloud Tasks
• 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: migracja z kolejki zadań App Engine (pobierania zadań) 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.

8. 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:

• Wyszukiwanie problemów
• Zgłoś nowy problem lub opinię

Zasoby migracji

Linki do folderów repozytorium w modułach 12 (START) i modułach 13 (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ęść 12	kod	kod
Moduł 13 (to ćwiczenia z programowania)	kod	kod

Dokumentacja online

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

App Engine

• Dokumentacja App Engine
• Środowisko wykonawcze App Engine (środowisko standardowe) Pythona 2
• Korzystanie z wbudowanych bibliotek App Engine w Python 2 App Engine
• Środowisko wykonawcze App Engine w Pythonie 3 (środowisko standardowe)
• Różnice między Pythonem 2 a Pythonem 2 3 środowiska wykonawcze App Engine (w środowisku standardowym)
• Przewodnik po migracji do App Engine (w środowisku standardowym) w języku Python 2 do 3
• Informacje o cenach i limitach App Engine

App Engine NDB i Cloud NDB

• Omówienie App Engine NDB
• Wykorzystanie Datastore NDB w App Engine
• Dokumentacja Google Cloud NDB
• Repozytorium Google Cloud NDB
• Informacje o cenach Cloud Datastore

Pamięć podręczna App Engine i Cloud Memorystore

• Omówienie usługi App Engine Memcache
• Dokumentacja memcache App Engine w Pythonie 2
• Dokumentacja memcache w Pythonie 3 App Engine
• Przewodnik po migracji z App Engine memcache do Cloud Memorystore
• Dokumentacja Cloud Memorystore
• Dokumentacja Cloud Memorystore for Redis
• Informacje o cenach Cloud Memorystore for Redis
• Wersje Redis obsługiwane przez Cloud Memorystore
• Strona główna Cloud Memorystore
• Utwórz nową instancję Memorystore w konsoli Cloud
• Strona główna klienta Python Redis
• Dokumentacja biblioteki klienta Python Redis

Cloud VPC

• Dokumentacja VPC Google Cloud
• Strona główna VPC Google Cloud
• Informacje o cenach Cloud VPC
• Utwórz nowe oprogramowanie sprzęgające bezserwerowego dostępu do VPC w konsoli Cloud

Inne informacje o Google Cloud

• Python w Google Cloud Platform
• Biblioteki klienta Google Cloud Python
• Zawsze bezpłatne usługi Google Cloud typ
• Google Cloud SDK (narzędzie wiersza poleceń gcloud)
• Cała dokumentacja Google Cloud

Licencja

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