Google AppEngine Python3 runtime


Python 2 wkrótce straci oficjalne wsparcie, więc przy okazji kolejnego projektu pomyślałem, że najwyższa pora zaprzyjaźnic się z drugą generacją AppEngine, w ramach której jest wspierany Python 3, Java 11, NodeJs i inne. Druga generacja wnosi sporo zmian w stosunku do pierwszej. Niektóre z nich mogą znacząco usprawnić korzystanie z usługi (na przykład nie ma ograniczeń w instalowaniu zależności dla aplikacji zaimplementowanych w Pythonie), z drugiej strony dostęp do innych usług, takich jak DataStore jest mniej intuicyjny niż w pierwszej generacji. W dalszej części będę odnosił się wyłącznie do środowiska Python 3.

Trudne początki

W pierwszej generacji do rozpoczęcia nowego projektu było konieczne zainstalowanie odpowiedniego pakietu, który zawiera wszystkie narzędzia i biblioteki niezbędne do stworzenia aplikacji i przetestowania jej na stacji roboczej. Dostęp do poszczególnych usług, takich jak Datastore, Memcase, Image API, etc. realizuje się za pośrednictem wysokopoziomowego API dostarczanego w pakiecie google. Po uruchomieniu aplikacji ze skryptem dev_appserver.py automatycznie startuje emulator standardowych serwisów. W drugiej generacji zmiana jest dość drastyczna - zaczynamy od zainstalowania aplikacji gcloud która jest standardowym narzędziem do zarządzania wszystkimi usługami udostępnianymi w ramach Google Cloud Platform. Przy użyciu odpowiednich poleceń inicjujemy projekt i aplikację. Jeżeli zamierzamy korzystać z DataStore jako bazy danych, musimy zainstalować emulator przy pomocy gcloud. Aby wykorzystać emulator startujemy go poleceniem gcloud beta emulators datastore start a następnie inicjujemy zmienne środowiskowe, na przykład

export DATASTORE_DATASET=nazwa_projektu
export DATASTORE_EMULATOR_HOST=localhost:8081
export DATASTORE_EMULATOR_HOST_PATH=localhost:8081/datastore
export DATASTORE_HOST=http://localhost:8081
export DATASTORE_PROJECT_ID=nawa_projektu

Odpowiednie wartości poznamy wykonując polecenie gcloud beta emulators datastore env-init. Oczywiście w którymś momencie dochodzimy do etapu, w którym te czynności są zautomatyzowane, ale początki były dla mnie zniechęcające. Szczególnie dlatego, że dokumentacja jest rozproszona między różnymi serwisami.

Integracja z GCP

W przeciwieństwie do pierwszej generacji, gdzie dostęp do róznych usług, takich jak datastore, cache, czy autoryzacji był niejawny i odbywał się za pośrednictwem wysokopoziomowego API, w drugiej generacji mamy dostęp do wszystkich usług w ramach Google Cloud Platform, ale o integrację musimy zadbać we własnym zakresie. To znaczy chcąc skorzystać z Cloud Datastore możemy użyć protokołu REST/HTTP, zainstalować bibliotekę google. W każdym przypadku dostępne API jest znacząco mniej przyjazne od NDB, które było dostępne w pierwszej generacji. Zamiast stosować Image API, w drugiej możemy po prostu zainstalować bibliotekę PIL. Bezpłatny memcache w drugiej generacji jest wogóle niedostępny, jako zamiennik w dokumentacji Google sugeruje się wykorzystanie usługi od innego dostawcy, co samo w sobie stanowi pewne kuriozum, albo dość drogiego Memstore. W pierwszej generacji do autoryzacji i uwierzytelnienia można było użyć dostarczonego API, które było stosunkowo łatwe do skonfigurowania. W drugiej w implementacji logowania jesteśmy zdani na siebie i zewnętrznych dostawców usług OAuth.

Tworzenie aplikacji

W drugiej generacji zaleca się używanie bibliotek, które wspierają routing, takie jak Flask, Django i inne. Instalacja jest prosta - na stacji roboczej używamy narzędzia pip, w momencie deploymentu nowej wersji biblioteki są instalowane na podstawie zawartości pliku requirements.txt. Ponieważ nie endpointów i odpowiadających metod nie definiuje się już w pliku app.yaml zabezpieczenie dostępuj do aplikacji musimy zaimplementować własnoręcznie. Wraz z rozpoczęciem korzystania z drugiej generacji będzie konieczne włączenie billingu, gdyż do instalacji nowej wersji jest używana płatna usługa Cloud Build. Serwis dość duży bezpłatny limit, więc bezpłatne korzystanie z AppEngine jest nadal możliwe.

Podsumowanie

Mój największy zarzut jest do dokumentacji udostępnionej przez Google. Ona zawsze odstawała swoim poziomem od dostarczanej przez AWS, ale w przypadku drugiej generacji jest bardzo pobieżna, a co gorsza rozproszona między różnymi usługami GCP. Wszystko to utrudnia start z nowym modelem, ale obawiam się że nie ma odwrotu. Google deklaruje, że użytkownicy pierwszej generacji nie muszą jeszcze dokonywać migracji, ale można się spodziewać że już wkrótce będą do tego zachęcani. Trudno się spodziewać, że wsparcie dla przestarzałych mechanizmów będzie utrzymywane bezterminowo. W celu usprawnienia przejścia na nową wersję udostępniono odpowiedni przewodnik.

Zobacz też