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

1. Przegląd

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

Ten przewodnik ma na celu pokazanie deweloperom aplikacji App Engine w Pythonie 2, jak przejść z App Engine Memcache na Cloud Memorystore (w przypadku Redis). Istnieje też migracja domyślna z App Engine ndb do Cloud NDB, ale jest ona omówiona głównie w module 2. Znajdziesz tam więcej szczegółowych informacji.

Dowiesz się, jak:

  • Konfigurowanie instancji Cloud Memorystore (w konsoli Cloud lub za pomocą narzędzia gcloud)
  • Skonfiguruj oprogramowanie sprzęgające bezserwerowy dostęp do VPC w Cloud (w Cloud Console lub za pomocą narzędzia gcloud)
  • Migracja z Memcache App Engine do Cloud Memorystore
  • Implementowanie buforowania za pomocą Cloud Memorystore w przykładowej aplikacji
  • Migracja z App Engine ndb do Cloud NDB

Czego potrzebujesz

Ankieta

Jak zamierzasz korzystać z tego samouczka?

Tylko przeczytaj Przeczytaj i wykonaj ćwiczenia

Jak oceniasz swoje doświadczenie z Pythonem?

Początkujący Średnio zaawansowany Zaawansowany

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Średnio zaawansowany Zaawansowany

2. Tło

W tym laboratorium dowiesz się, jak przenieść przykładową aplikację z App Engine Memcache (i NDB) do Cloud Memorystore (i Cloud NDB). Ten proces polega na zastąpieniu zależności od pakietu usług App Engine, co zwiększa przenośność aplikacji. Możesz pozostać w App Engine lub rozważyć przejście na jedną z opisanych wcześniej alternatyw.

Ta migracja wymaga więcej wysiłku niż pozostałe w tej serii. Zalecanym zamiennikiem usługi Memcache w App Engine jest Cloud Memorystore, usługa w pełni zarządzana do buforowania w chmurze. Memorystore obsługuje 2 popularne silniki pamięci podręcznej 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, dlatego potrzebna jest też sieć VPC w Google Cloud. 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 za pomocą jej prywatnego adresu IP. Po wykonaniu tego ćwiczenia zaktualizujesz aplikację tak, aby działała jak wcześniej, ale usługa Cloud Memorystore zastąpiła usługę Memcache App Engine jako usługa buforowania.

Ten samouczek zaczyna się od przykładowej aplikacji z modułu 12 w Pythonie 2, a następnie zawiera dodatkową, opcjonalną, niewielką aktualizację do Pythona 3. Jeśli wiesz już, jak uzyskiwać dostęp do usług pakietowych App Engine z poziomu Pythona 3 za pomocą pakietu Python 3 App Engine SDK, możesz zacząć od wersji przykładowej aplikacji z modułu 12 w Pythonie 3. Wymaga to usunięcia pakietu SDK, ponieważ Memorystore nie jest usługą pakietową App Engine. Ten samouczek nie obejmuje informacji o tym, jak korzystać z pakietu App Engine SDK dla Pythona 3.

Ten samouczek obejmuje te kluczowe kroki:

  1. Konfiguracja/przygotowanie
  2. Konfigurowanie usług buforowania
  3. Aktualizowanie plików konfiguracji
  4. Aktualizowanie głównej aplikacji

3. Konfiguracja/przygotowanie

Przygotowywanie projektu w chmurze

Zalecamy ponowne użycie tego samego projektu, którego użyto do ukończenia ćwiczenia programistycznego z modułu 12. Możesz też utworzyć zupełnie nowy projekt lub ponownie wykorzystać inny istniejący projekt. Każdy codelab w tej serii ma wersję „START” (kod bazowy, od którego zaczynamy) i „FINISH” (zmigrowana aplikacja). Kod FINISH jest podany, aby w razie problemów można było porównać swoje rozwiązania z naszymi. Jeśli coś pójdzie nie tak, zawsze możesz wrócić do punktu START. Te punkty kontrolne mają pomóc Ci w nauce przeprowadzania migracji.

Niezależnie od tego, którego projektu w chmurze używasz, upewnij się, że ma on aktywne konto rozliczeniowe. Sprawdź też, czy usługa App Engine jest włączona. Zapoznaj się z ogólnymi konsekwencjami finansowymi korzystania z tych samouczków i upewnij się, że je rozumiesz. W przeciwieństwie do innych samouczków z tej serii ten korzysta z zasobów Google Cloud, które nie mają poziomu bezpłatnego, więc wykonanie ćwiczenia będzie wiązać się z pewnymi kosztami. Bardziej szczegółowe informacje o kosztach zostaną podane wraz z rekomendacjami dotyczącymi ograniczenia wykorzystania, w tym instrukcjami na końcu, jak zwalniać zasoby, aby zminimalizować opłaty.

Pobieranie przykładowej aplikacji podstawowej

To laboratorium przeprowadzi Cię krok po kroku przez proces migracji z kodu bazowego modułu 12. Po zakończeniu tego procesu uzyskasz działającą aplikację z modułu 13, która będzie bardzo podobna do kodu w jednym z folderów FINISH. Oto te materiały:

Folder START powinien zawierać te pliki:

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

Jeśli zaczynasz od wersji w Pythonie 2, będzie też plik appengine_config.py i prawdopodobnie folder lib, jeśli udało Ci się ukończyć moduł 12.

(Ponowne) wdrażanie aplikacji z modułu 12

Pozostałe kroki przygotowawcze:

  1. Przypomnij sobie, jak korzystać z narzędzia wiersza poleceń gcloud (w razie potrzeby).
  2. (Ponowne) wdrożenie kodu modułu 12 w App Engine (w razie potrzeby)

Użytkownicy Pythona 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 (Python 2 i 3) powinni przesłać kod do App Engine za pomocą tego polecenia:

gcloud app deploy

Po pomyślnym wdrożeniu sprawdź, czy aplikacja wygląda i działa tak samo jak aplikacja z modułu 12, czyli aplikacja internetowa, która śledzi wizyty i przechowuje je w pamięci podręcznej dla tego samego użytkownika przez godzinę:

dfe56a02ae59ddd8.png

Najnowsze wizyty są przechowywane w pamięci podręcznej, więc odświeżanie strony powinno przebiegać dość szybko.

4. Konfigurowanie usług buforowania

Cloud Memorystore nie jest usługą bezserwerową. Wymagana jest instancja, w tym przypadku uruchomiona instancja Redis. W przeciwieństwie do Memcache usługa Memorystore jest samodzielną usługą w chmurze i nie ma poziomu bezpłatnego, więc przed kontynuowaniem sprawdź informacje o cenach Memorystore for Redis. Aby zminimalizować koszty tego ćwiczenia, zalecamy użycie najmniejszej ilości zasobów potrzebnych do działania: podstawowej wersji usługi i 1 GB pojemności.

Instancja Memorystore znajduje się w innej sieci niż aplikacja App Engine (instancje), dlatego należy utworzyć oprogramowanie sprzęgające bezserwerowego dostępu do VPC, aby App Engine mogło uzyskać dostęp do zasobów Memorystore. Aby zminimalizować koszty VPC, wybierz typ instancji (f1-micro) i najmniejszą liczbę instancji do żądania (sugerujemy minimum 2, maksimum 3). Zapoznaj się też ze stroną z informacjami o cenach VPC.

Podczas tworzenia każdego wymaganego zasobu będziemy powtarzać te zalecenia dotyczące obniżania kosztów. Dodatkowo, gdy tworzysz zasoby Memorystore i VPC w konsoli Cloud, w prawym górnym rogu zobaczysz kalkulator cen dla każdego produktu, który podaje szacunkowy miesięczny koszt (patrz ilustracja poniżej). Jeśli zmienisz opcje, te wartości zostaną automatycznie dostosowane. Oto czego możesz się spodziewać:

7eb35ebf7248c010.png

Oba zasoby są wymagane i nie ma znaczenia, który z nich utworzysz jako pierwszy. Jeśli najpierw utworzysz instancję Memorystore, aplikacja App Engine nie będzie mogła się z nią połączyć 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 się komunikować. W tym samouczku najpierw utworzysz instancję Memorystore, a potem oprogramowanie sprzęgające VPC.

Gdy oba zasoby będą dostępne online, dodaj odpowiednie informacje do app.yaml, aby aplikacja mogła uzyskać dostęp do pamięci podręcznej. W oficjalnej dokumentacji znajdziesz też przewodniki dotyczące Pythona 2 i Pythona 3. Warto też zapoznać się z przewodnikiem po buforowaniu danych na stronie migracji Cloud NDB ( Python 2 lub Python 3).

Tworzenie instancji Cloud Memorystore

Usługa Cloud Memorystore nie ma poziomu bezpłatnego, dlatego zalecamy przydzielenie jak najmniejszej ilości zasobów, aby ukończyć ćwiczenie. Aby zminimalizować koszty, możesz użyć tych ustawień:

  • Wybierz najniższy poziom usług: Podstawowy (domyślny w konsoli: „Standard”, domyślny w gcloud: „Podstawowy”).
  • Wybierz najmniejszą ilość miejsca na dane: 1 GB (domyślnie na konsoli: 16 GB, domyślnie na gcloud: 1 GB).
  • Zazwyczaj najnowsze wersje każdego oprogramowania wymagają największej ilości zasobów, ale wybór najstarszej wersji też nie jest zalecany. Druga najnowsza wersja to obecnie Redis 5.0 (domyślna w konsoli: 6.x).

Mając na uwadze te ustawienia, w następnej sekcji przeprowadzimy Cię przez proces tworzenia instancji w konsoli Cloud. Jeśli wolisz to zrobić z wiersza poleceń, przejdź dalej.

W konsoli Cloud

Otwórz stronę Cloud Memorystore w konsoli Cloud (może pojawić się prośba o podanie informacji rozliczeniowych). Jeśli nie masz jeszcze włączonej usługi Memorystore, pojawi się prośba o jej włączenie:

68318997e3105db6.png

Po włączeniu usługi (i ewentualnie po skonfigurowaniu płatności) zobaczysz panel Memorystore. Tutaj znajdziesz wszystkie instancje utworzone w projekcie. W projekcie widocznym poniżej nie ma żadnych wierszy, dlatego widzisz komunikat „No rows to display” (Brak wierszy do wyświetlenia). Aby utworzyć instancję Memorystore, kliknij u góry Utwórz instancję:

63547aa575838a36.png

Na tej stronie znajduje się formularz, w którym możesz wpisać wybrane ustawienia, aby utworzyć instancję Memorystore:

b77d927287fdf4c7.png

Aby obniżyć koszty tego samouczka i przykładowej aplikacji, postępuj zgodnie z rekomendacjami podanymi wcześniej. Po dokonaniu wyboru kliknij Utwórz. Proces tworzenia trwa kilka minut. Gdy proces się zakończy, skopiuj adres IP instancji i numer portu, aby dodać je do app.yaml.

W wierszu poleceń

Tworzenie instancji Memorystore w konsoli Cloud jest bardzo wygodne, ale niektórzy wolą wiersz poleceń. Zanim przejdziesz dalej, upewnij się, że pakiet gcloud został zainstalowany i zainicjowany.

Podobnie jak w przypadku konsoli Cloud, usługa Cloud Memorystore for Redis musi być włączona. Wydaj polecenie gcloud services enable redis.googleapis.com i poczekaj na jego wykonanie, 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, ponowne uruchomienie polecenia nie ma żadnych negatywnych skutków ubocznych. Po włączeniu usługi 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. W tym module używamy nazwy „demo-ms” i identyfikatora projektu „my-project”. Region tej przykładowej aplikacji to us-central1 (taki sam jak us-central), ale jeśli zależy Ci na małych opóźnieniach, możesz użyć regionu położonego bliżej Ciebie. Musisz wybrać ten sam region co w przypadku aplikacji App Engine. Możesz wybrać dowolną wersję Redis, ale zalecamy użycie wersji 5, jak wspomnieliśmy wcześniej. Przy takich ustawieniach polecenie (wraz z powiązanymi danymi wyjściowymi) wyglądałoby tak:

$ 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ń konsoli Cloud, gcloud domyślnie używa minimalnej liczby zasobów. W rezultacie w tym poleceniu nie były wymagane ani poziom usługi, ani ilość miejsca na dane. Utworzenie instancji Memorystore zajmuje kilka minut. Po zakończeniu tego procesu zanotuj adres IP i numer portu instancji, ponieważ wkrótce zostaną one dodane do app.yaml.

Potwierdź utworzenie instancji

W konsoli Cloud lub wierszu poleceń

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

Oto polecenie sprawdzania instancji w regionie us-central1 wraz z oczekiwanymi danymi wyjściowymi, które pokazują utworzoną przez nas 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 skonfigurowanie aplikacji, użyj znaków HOST i PORT (nie RESERVED_IP). W panelu Cloud Memorystore w Cloud Console powinna być teraz widoczna ta instancja:

c5a6948ec1c056ed.png

Z maszyny wirtualnej Compute Engine

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

Tworzenie oprogramowania sprzęgającego bezserwerowego dostępu do VPC

Podobnie jak w przypadku Cloud Memorystore, bezserwerowe oprogramowanie sprzęgające VPC możesz utworzyć w konsoli Cloud lub w wierszu poleceń. Podobnie Cloud VPC nie ma bezpłatnej wersji, dlatego zalecamy przydzielenie jak najmniejszej ilości zasobów, aby ukończyć ćwiczenie i zminimalizować koszty. Można to osiągnąć za pomocą tych ustawień:

  • Wybierz najniższą maksymalną liczbę instancji: 3 (konsola i gcloud domyślnie: 10).
  • Wybierz najtańszy typ maszyny: f1-micro (domyślnie w konsoli: e2-micro, bez domyślnego gcloud)

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

W konsoli Cloud

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

e3b9c0651de25e97.png

Po włączeniu interfejsu API (i ewentualnie po skonfigurowaniu płatności) przejdziesz do panelu, w którym będą wyświetlane wszystkie utworzone oprogramowania sprzęgające VPC. Projekt użyty na zrzucie ekranu poniżej nie ma żadnych wierszy, dlatego wyświetla się komunikat „Brak wierszy do wyświetlenia”. U góry konsoli kliknij Utwórz łącznik:

b74b49b9d73b7dcf.png

Wypełnij formularz, wpisując odpowiednie ustawienia:

6b26b2aafa719f73.png

Wybierz odpowiednie ustawienia dla swoich aplikacji. W przypadku tego samouczka i przykładowej aplikacji o minimalnych potrzebach warto zminimalizować koszty, więc postępuj zgodnie z zaleceniami podanymi wcześniej. Po dokonaniu wyboru kliknij Utwórz. Wymaganie oprogramowania sprzęgającego VPC może potrwać kilka minut.

Z poziomu wiersza poleceń

Zanim utworzysz oprogramowanie sprzęgające VPC, włącz najpierw interfejs API bezserwerowego dostępu do VPC. Po wydaniu tego polecenia powinny pojawić się podobne dane wyjściowe:

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

Po włączeniu interfejsu API 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 adres IP początkowy bloku CIDR /28. W tym samouczku przyjęto następujące założenia:

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

Jeśli wykonasz to polecenie przy założeniach podanych powyżej, 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 pominięto określanie wartości domyślnych, takich jak minimalna liczba instancji wynosząca 2 i sieć o nazwie default. Tworzenie oprogramowania sprzęgającego VPC może potrwać kilka minut.

Potwierdź utworzenie łącznika

Po zakończeniu procesu wydaj to polecenie gcloud, zakładając, że jest to region us-central1, aby potwierdzić, że został utworzony i jest 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 w panelu powinno się teraz wyświetlać utworzone przed chwilą oprogramowanie sprzęgające:

e03db2c8140ed014.png

Zanotuj identyfikator projektu w chmurze, nazwę oprogramowania sprzęgającego VPC i region.

Po utworzeniu dodatkowych zasobów w Cloud (za pomocą wiersza poleceń lub w konsoli) czas zaktualizować konfigurację aplikacji, aby obsługiwała ich użycie.

5. Aktualizowanie plików konfiguracji

Pierwszym krokiem jest wprowadzenie wszystkich niezbędnych zmian w plikach konfiguracyjnych. Głównym celem tego samouczka jest pomoc użytkownikom języka Python 2 w przenoszeniu kodu. Jednak w każdej sekcji poniżej znajdziesz też informacje o dalszym przenoszeniu kodu do języka Python 3.

requirements.txt

W tej sekcji dodamy pakiety obsługujące Cloud Memorystore i Cloud NDB. W przypadku Cloud Memorystore for Redis wystarczy użyć standardowego klienta Redis dla Pythona (redis), ponieważ nie ma osobnej biblioteki klienta Cloud Memorystore. Dodaj do listy requirements.txt elementy redis i google-cloud-ndb, łącząc flask z modułu 12:

flask
redis
google-cloud-ndb

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

app.yaml

Nowe sekcje do dodania

Środowisko wykonawcze App Engine w Pythonie 2 wymaga określonych pakietów innych firm, gdy używasz interfejsów API Cloud, takich jak Cloud NDB, a mianowicie grpcio i setuptools. Użytkownicy Pythona 2 muszą podać w app.yaml wbudowane biblioteki, takie jak te, wraz z dostępną wersją. 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 jest, a brakuje grpcio i setuptools, dodaj je do istniejącej sekcji libraries.

Następnie nasza przykładowa aplikacja potrzebuje informacji o instancji Cloud Memorystore i oprogramowaniu sprzęgającym VPC, więc dodaj te 2 nowe sekcje do pliku app.yaml 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 wszystkie wymagane zmiany. Zaktualizowany plik 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 przykład „przed i po” ilustrujący aktualizacje, które należy zastosować w przypadku app.yaml:

ec2bb027a67debb6.png

*Różnice w Pythonie 3

Ta sekcja jest opcjonalna i dotyczy tylko przenoszenia kodu do Pythona 3. W tym celu musisz wprowadzić kilka zmian w konfiguracji Pythona 2. Jeśli nie chcesz teraz przejść na wyższą wersję, pomiń tę sekcję.

W środowisku wykonawczym Pythona 3 nie używa się ani threadsafe, ani api_version, więc usuń oba te ustawienia. Najnowsze środowisko wykonawcze App Engine nie obsługuje wbudowanych bibliotek innych firm ani kopiowania niewbudowanych bibliotek. Jedynym wymaganiem dotyczącym pakietów innych firm jest umieszczenie ich na liście w requirements.txt. W związku z tym cała sekcja libraries w app.yaml może zostać usunięta.

Środowisko wykonawcze Python 3 wymaga używania platform internetowych, które same wykonują routing. Dlatego w module 1 pokazaliśmy deweloperom, jak przejść z webp2 na Flask. W związku z tym wszystkie moduły obsługi skryptów muszą zostać zmienione na auto. Ta aplikacja nie obsługuje żadnych plików statycznych, więc umieszczanie na liście modułów obsługi jest „bezcelowe” (ponieważ wszystkie są auto), dlatego można też usunąć całą sekcję handlers. W rezultacie nowy, skrócony kod app.yaml dostosowany do Pythona 3 powinien wyglądać tak:

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:

  • Usuwanie ustawień threadsafe i api_version
  • Usuń sekcję libraries
  • Usuń sekcję handlers (lub tylko moduły obsługi script, jeśli aplikacja wyświetla pliki statyczne).

Zastąp wartości

Wartości w nowych sekcjach dotyczących Memorystore i oprogramowania sprzęgającego VPC są tylko symboliczne. Zastąp te wartości pisane wielkimi literami (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) wartościami zapisanymi podczas tworzenia tych zasobów. W przypadku instancji Memorystore używaj HOST (a nie RESERVED_IP) i PORT. Oto szybki sposób na uzyskanie wartości HOST i PORT z wiersza poleceń przy założeniu, że nazwa instancji to demo-ms, a wartość REGION to us-central1:

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

Jeśli adres IP naszej przykładowej instancji Redis to 10.10.10.10, a port to 6379 w projekcie my-project w regionie us-central1, a nazwa oprogramowania sprzęgającego VPC to demo-vpc, te sekcje w 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

Tworzenie lub aktualizowanie pliku appengine_config.py

Dodawanie obsługi wbudowanych bibliotek innych firm

Podobnie jak w przypadku app.yaml, dodaj użycie bibliotek grpcio i setuptools. Zmodyfikuj appengine_config.py, aby obsługiwać wbudowane biblioteki innych firm. Jeśli to Ci coś przypomina, to dlatego, że było to też wymagane w module 2 podczas migracji z App Engine ndb do Cloud NDB. Wymagana zmiana polega na dodaniu folderu lib do zestawu roboczego setuptools.pkg_resources:

4140b3800694f77e.png

*Różnice w Pythonie 3

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

6. Aktualizowanie plików aplikacji

Jest tylko jeden plik aplikacji, main.py, więc wszystkie zmiany w tej sekcji dotyczą tylko tego pliku. Przedstawiliśmy graficznie zmiany, które wprowadzimy, aby przenieść tę aplikację do Cloud Memorystore. Ma ona charakter wyłącznie ilustracyjny i nie jest przeznaczona do szczegółowej analizy. Cała praca polega na wprowadzaniu zmian w kodzie.

5d043768ba7be742.png

Zajmijmy się nimi po kolei, zaczynając od góry.

Aktualizowanie importów

Sekcja importu w main.py w module 12 korzysta z Cloud NDB i Cloud Tasks. Oto importy:

PRZED:

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

Przełączenie się na Memorystore wymaga odczytania zmiennych środowiskowych, co oznacza, że potrzebujemy modułu Pythona os oraz klienta Redis w języku Python redis. Redis nie może buforować obiektów Pythona, więc listę ostatnich wizyt należy przekształcić za pomocą pickle. Zaimportuj też tę bibliotekę. Jedną z zalet Memcache jest to, że serializacja obiektów odbywa się automatycznie, podczas gdy w przypadku Memorystore jest to bardziej „zrób to sam”. Na koniec przejdź z App Engine ndb na Cloud NDB, zastępując google.appengine.ext.ndb ciągiem google.cloud.ndb. Po wprowadzeniu tych zmian importy powinny wyglądać tak:

PO:

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

Aktualizacja inicjowania

Inicjowanie modułu 12 polega na utworzeniu instancji obiektu aplikacji Flask app i ustawieniu stałej dla godziny buforowania:

PRZED:

app = Flask(__name__)
HOUR = 3600

Korzystanie z interfejsów Cloud APIs wymaga klienta, więc od razu po Flasku utwórz instancję klienta Cloud NDB. Następnie uzyskaj adres IP i numer portu instancji Memorystore ze zmiennych środowiskowych ustawionych w app.yaml. Na podstawie tych informacji utwórz klienta Redis. Po wprowadzeniu tych zmian kod będzie wyglądać tak:

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 i dotyczy sytuacji, gdy zaczynasz od wersji aplikacji z modułu 12 w Pythonie 3. W takim przypadku musisz wprowadzić kilka wymaganych zmian związanych z importami i inicjalizacją.

Po pierwsze, Memcache jest usługą pakietową App Engine, więc korzystanie z niej w aplikacji w języku Python 3 wymaga pakietu SDK App Engine, a w szczególności opakowania aplikacji WSGI (a także 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

Ponieważ migrujemy do Cloud Memorystore (nie jest to usługa pakietowa App Engine, jak Memcache), musimy usunąć użycie pakietu SDK. To proste, wystarczy usunąć cały wiersz, który importuje zarówno memcache, jak i wrap_wsgi_app. Usuń też wiersz wywołujący wrap_wsgi_app(). Te aktualizacje sprawiają, że ta część aplikacji (a właściwie cała aplikacja) jest identyczna z wersją w Pythonie 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 usuń użycie pakietu SDK z pliku 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 modelem danych App Engine, co oznacza, że definicja obiektów Visit pozostaje taka sama.ndb Podobnie jak w przypadku migracji modułu 2 do Cloud NDB, wszystkie wywołania Datastore w plikach store_visit() i fetch_visits() są rozszerzane i osadzane w nowym bloku with (ponieważ wymagane jest użycie menedżera kontekstu Cloud NDB). Oto połączenia 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 nie musisz wprowadzać żadnych zmian w samych wywołaniach:

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)

Przyjrzyjmy się teraz zmianom w pamięci podręcznej. 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 wywołania „get” i „set”, podobnie jak Memcache. Wystarczy, że zamienimy odpowiednie biblioteki klienta, prawda? Prawie dobrze. Jak wspomnieliśmy wcześniej, nie możemy buforować listy Pythona w Redis (ponieważ najpierw musi zostać zserializowana, co Memcache robi automatycznie), więc w wywołaniu set() przekształć wizyty w ciąg znaków za pomocą pickle.dumps(). Podobnie podczas pobierania wizyt z pamięci podręcznej musisz odkodować je za pomocą funkcji pickle.loads() zaraz po funkcji 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)

W tym miejscu kończą się zmiany wymagane w main.py przekształceniu sposobu, w jaki aplikacja przykładowa korzysta z Memcache, na Cloud Memorystore. A co z szablonem HTML i przenoszeniem do Pythona 3?

Aktualizacja pliku szablonu HTML i przeniesienie go 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 konieczności wprowadzania zmian w kodzie ani korzystania z bibliotek zgodności. Znajdziesz main.py. identyczne w folderach „FINISH” w wersjach mod13a (2.x) i mod13b (3.x). To samo dotyczy elementu requirements.txt , z wyjątkiem różnic w numerach wersji (jeśli są używane). Interfejs użytkownika pozostaje bez zmian, więc nie ma też aktualizacji templates/index.html.

Wszystkie czynności niezbędne do uruchomienia tej aplikacji w App Engine w Pythonie 3 zostały wykonane wcześniej podczas konfigurowania: z pliku app.yaml usunięto niepotrzebne dyrektywy, a pliki appengine_config.py i lib zostały usunięte, ponieważ nie są używane w Pythonie 3.

7. Podsumowanie i czyszczenie

W tej sekcji podsumowujemy te warsztaty, wdrażając aplikację i sprawdzając, czy działa zgodnie z oczekiwaniami i czy dane wyjściowe są prawidłowe. Po zweryfikowaniu aplikacji wykonaj czyszczenie i rozważ kolejne kroki.

Wdrażanie i weryfikowanie aplikacji

Ostatnim krokiem jest zawsze wdrożenie przykładowej aplikacji. Deweloperzy korzystający z Pythona 2: usuń i ponownie zainstaluj lib za pomocą poniższych poleceń. (Jeśli masz zainstalowane na komputerze zarówno Pythona 2, jak i 3, może być konieczne uruchomienie pip2).

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

Deweloperzy korzystający z Pythona 2 i 3 powinni teraz wdrażać aplikacje za pomocą tego polecenia:

gcloud app deploy

Ponieważ w przypadku zupełnie innej usługi buforowania zmieniliśmy tylko wewnętrzne połączenia, aplikacja powinna działać identycznie jak aplikacja z modułu 12:

Moduł 7. Aplikacja visitme

W ten sposób zakończysz to ćwiczenie. Zachęcamy do porównania zaktualizowanej przykładowej aplikacji z jednym z folderów modułu 13: mod13a (Python 2) lub mod13b (Python 3).

Czyszczenie danych

Ogólne

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

Wdrożenie na bezserwerowej platformie obliczeniowej Google Cloud, takiej jak App Engine, wiąże się z niewielkimi kosztami kompilacji i przechowywania. Cloud Build ma własny bezpłatny limit, podobnie jak Cloud Storage. Przechowywanie tego obrazu wykorzystuje część tego limitu. Możesz jednak mieszkać w regionie, w którym nie ma takiego bezpłatnego pakietu, więc kontroluj wykorzystanie miejsca na dane, aby zminimalizować potencjalne koszty. Sprawdź te „foldery” Cloud Storage:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • Linki do pamięci masowej powyżej zależą od PROJECT_ID i *LOC*acji, np. „us”, jeśli Twoja aplikacja jest hostowana w Stanach Zjednoczonych.

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

Dotyczy tych ćwiczeń z programowania

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

W tym samouczku używane są 4 usługi w chmurze:

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

Poniżej znajdziesz instrukcje, jak zwolnić te zasoby, aby uniknąć opłat lub je zminimalizować.

Zamykanie instancji Memorystore i oprogramowania sprzęgającego VPC

Są to usługi bez poziomu bezpłatnego, więc już teraz naliczane są za nie opłaty. Jeśli nie zamkniesz projektu w chmurze (patrz następna sekcja), musisz usunąć zarówno instancję Memorystore, jak i oprogramowanie sprzęgające VPC, aby zatrzymać naliczanie opłat. Podobnie jak w przypadku tworzenia tych zasobów możesz je też zwalniać w konsoli Cloud lub wierszu poleceń.

W konsoli Cloud

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

2b09baf1aa2e0a25.png

Na stronie ze szczegółami instancji kliknij „Usuń” i potwierdź:

f9d9eb1c1d4c6107.png

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

ca5fbd9f4c7c9b60.png

Z wiersza poleceń

Poniższa 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 nie masz ustawionego identyfikatora projektu w gcloud config set project, być może musisz podać --project PROJECT_ID. Jeśli instancja Memorystore ma nazwę demo-ms, a oprogramowanie sprzęgające VPC ma nazwę demo-vpc i oba znajdują się w regionie us-central1, wydaj te 2 polecenia 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. Jeśli zdecydujesz się wyłączyć cały projekt w chmurze, jak opisano wcześniej, te czynności są opcjonalne. Jednak do czasu zakończenia procesu wyłączania nadal będziesz ponosić koszty.

Dalsze kroki

Oprócz tego samouczka możesz też zapoznać się z innymi modułami migracji, które skupiają się na przejściu z starszych usług w pakiecie:

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

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

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

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

8. Dodatkowe materiały

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

Problemy z Codelabs lub opinie na ich temat

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

Materiały dotyczące migracji

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

Ćwiczenia z programowania

Python 2

Python 3

Moduł 12

kod

kod

Moduł 13 (te ćwiczenia z programowania)

kod

kod

Odsyłacze online

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

App Engine

App Engine NDB i Cloud NDB

App Engine Memcache i Cloud Memorystore

Cloud VPC

Inne informacje o chmurze

Licencja

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