Moduł 5. Migracja z Google App Engine do Cloud Run z użyciem pakietów Cloud Buildpack

1. Przegląd

Ta seria ćwiczeń z programowania (samodzielnych samouczków praktycznych) ma pomóc deweloperom Google App Engine (Standard) w modernizacji aplikacji poprzez przeprowadzenie ich przez serię migracji. Gdy to zrobisz, użytkownicy mogą zwiększyć przenośność aplikacji, jawnie konteneryzując je na potrzeby Cloud Run, czyli usługi hostowania kontenerów Google Cloud, która jest podobna do App Engine, oraz innych usług hostowania kontenerów.

Z tego samouczka dowiesz się, jak umieścić aplikacje App Engine w kontenerach, aby wdrożyć je w w pełni zarządzanej usłudze Cloud Run za pomocą Cloud Buildpacks, która jest alternatywą dla Dockera. Cloud Buildpacks konteneryzuje aplikacje bez zarządzania plikami Dockerfile i bez konieczności znajomości Dockera.

Te warsztaty są przeznaczone dla deweloperów aplikacji App Engine w Pythonie 2, którzy przenieśli swoje aplikacje z oryginalnych wbudowanych usług do Pythona 3 i chcą teraz uruchamiać je w kontenerze. Codelab ROZPOCZYNA się od ukończonej aplikacji w Pythonie 3 z modułu 2 lub modułu 3.

Dowiesz się, jak:

  • Konteneryzowanie aplikacji za pomocą pakietów kompilacji Cloud
  • wdrażać obrazy kontenerów w Cloud Run,

Czego potrzebujesz

Ankieta

Jak zamierzasz wykorzystać to ćwiczenie?

Tylko przeczytaj Przeczytaj i wykonaj ćwiczenia

2. Tło

Systemy PaaS, takie jak App Engine i Cloud Functions, zapewniają wiele udogodnień dla Twojego zespołu i aplikacji. Na przykład te platformy bezserwerowe umożliwiają administratorom systemów i zespołom DevOps skupienie się na tworzeniu rozwiązań. Aplikacja może automatycznie skalować się w górę w miarę potrzeb, skalować w dół do zera, a płatności za użycie pomagają kontrolować koszty. Korzysta ona z różnych popularnych języków programowania.

Elastyczność kontenerów jest jednak również atrakcyjna, ponieważ umożliwia wybór dowolnego języka, biblioteki lub pliku binarnego. Google Cloud Run łączy wygodę technologii bezserwerowych z elastycznością kontenerów, zapewniając użytkownikom to, co najlepsze w obu tych rozwiązaniach.

Ten przewodnik nie obejmuje nauki korzystania z Cloud Run. Znajdziesz ją w dokumentacji Cloud Run. Chcemy, abyś dowiedział się, jak umieścić aplikację App Engine w kontenerze na potrzeby Cloud Run (lub innych usług). Zanim przejdziesz dalej, musisz wiedzieć kilka rzeczy. Przede wszystkim to, że wrażenia użytkowników będą nieco inne, a także nieco mniej zaawansowane, ponieważ nie będziesz już pobierać kodu aplikacji i go wdrażać.

Zamiast tego musisz dowiedzieć się czegoś o kontenerach, np. jak je tworzyć i wdrażać. Możesz też zdecydować, co chcesz umieścić w obrazie kontenera, w tym serwer WWW, ponieważ nie będziesz już używać serwera WWW App Engine. Jeśli nie chcesz podążać tą ścieżką, pozostawienie aplikacji w App Engine nie jest złym rozwiązaniem.

Z tego samouczka dowiesz się, jak umieścić aplikację w kontenerze, usunąć pliki konfiguracyjne App Engine i zarządzać serwerem WWW, w tym jak uruchomić aplikację.

Migracja obejmuje te kroki:

  1. Konfiguracja/przygotowanie
  2. Konteneryzacja aplikacji
    • Zastępowanie plików konfiguracji
    • Modyfikowanie plików aplikacji

3. Konfiguracja/przygotowanie

Zanim przejdziemy do głównej części samouczka, skonfigurujmy projekt, pobierzmy kod i wdrożymy aplikację podstawową, aby mieć pewność, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz już za sobą ćwiczenia z modułu 2 lub modułu 3, zalecamy ponowne użycie tego samego projektu (i kodu). Możesz też utworzyć zupełnie nowy projekt lub ponownie wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe i czy usługa App Engine (aplikacja) jest włączona.

2. Pobieranie przykładowej aplikacji podstawowej

Jednym z wymagań wstępnych do tych ćwiczeń z programowania jest działająca aplikacja przykładowa z modułu 2 lub 3. Jeśli jej nie masz, przed przejściem do dalszej części zalecamy ukończenie jednego z tych samouczków (linki powyżej). Jeśli znasz już ich zawartość, możesz po prostu pobrać jeden z folderów z kodem poniżej.

Niezależnie od tego, czy używasz własnego, czy naszego, od tego zaczyna się ten samouczek. W tym laboratorium dowiesz się, jak przeprowadzić migrację. Po jej zakończeniu kod powinien być w większości zgodny z kodem w folderze FINISH w repozytorium modułu 5.

Katalog plików START (Twój lub nasz) powinien wyglądać tak:

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

3. (Ponowne) wdrażanie aplikacji bazowej

Pozostałe czynności przygotowawcze, które musisz teraz wykonać:

  1. Przypomnij sobie, jak działa narzędzie wiersza poleceń gcloud.
  2. Ponowne wdrażanie przykładowej aplikacji za pomocą gcloud app deploy
  3. Sprawdź, czy aplikacja działa w App Engine bez problemów.

Po wykonaniu tych czynności możesz umieścić aplikację w kontenerze.

4. Konteneryzacja aplikacji

Docker to obecnie standardowa platforma konteneryzacji w branży. Jak już wspomnieliśmy, jednym z wyzwań związanych z jego używaniem jest to, że wymaga on starannego przygotowania wydajnego pliku Dockerfile, czyli pliku konfiguracji, który określa sposób tworzenia obrazów kontenerów. Z kolei pakiety kompilacji wymagają niewielkiego nakładu pracy, ponieważ wykorzystują introspekcję do określania zależności aplikacji, dzięki czemu kontener pakietów kompilacji jest jak najbardziej wydajny.

Jeśli nie chcesz uczyć się Dockera i chcesz konteneryzować aplikację App Engine, aby uruchamiać ją w Cloud Run lub na innej platformie hostującej kontenery, to dobrze trafiłeś(-aś). Jeśli chcesz dowiedzieć się, jak używać Dockera do konteneryzacji aplikacji, po ukończeniu tego modułu możesz przejść do ćwiczenia z modułu 4. Jest on identyczny z tym, ale używa Dockera, aby lepiej zrozumieć, jak zarządzać obrazami kontenerów.

Kroki migracji obejmują zastąpienie plików konfiguracyjnych App Engine i określenie sposobu uruchamiania aplikacji. Poniżej znajdziesz tabelę z podsumowaniem plików konfiguracyjnych, których możesz się spodziewać w przypadku poszczególnych typów platform. Porównaj kolumnę App Engine z kolumną Buildpacks (i opcjonalnie Docker):

Opis

App Engine

Docker

Buildpacki

Konfiguracja ogólna

app.yaml

Dockerfile

(service.yaml)

Biblioteki innych firm

requirements.txt

requirements.txt

requirements.txt

Konfiguracja innej firmy

app.yaml (plus appengine_config.py i lib [tylko w wersji 2.x])

(n/a)

(n/a)

Uruchomienie

(nie dotyczy) lub app.yaml (jeśli użyto entrypoint)

Dockerfile

Procfile

Ignorowanie plików

.gcloudignore i .gitignore

.gcloudignore, .gitignore i .dockerignore

.gcloudignore i .gitignore

Po umieszczeniu aplikacji w kontenerze można ją wdrożyć w Cloud Run. Inne opcje platformy kontenerów Google Cloud to Compute Engine, GKE i Anthos.

Konfiguracja ogólna

App Engine automatycznie uruchamia aplikację, ale Cloud Run tego nie robi. Dyrektywa Procfile pełni podobną rolę jak dyrektywa app.yaml entrypoint. W przypadku naszej przykładowej aplikacji Procfile wykona python main.py, aby uruchomić serwer deweloperski Flask. W razie potrzeby możesz też użyć serwera WWW w wersji produkcyjnej, np. gunicorn. Jeśli to zrobisz, dodaj go do requirements.txt. Więcej informacji o wdrażaniu z kodu źródłowego za pomocą pakietów Buildpack znajdziesz na tej stronie dokumentacji Cloud Run.

Wystarczy, że przeniesiesz dyrektywę app.yaml entrypoint do Procfile. Jeśli nie masz takiego serwera, użyj na razie serwera deweloperskiego Flask, ponieważ jest to tylko przykładowa aplikacja testowa, która ma pomóc użytkownikom w zapoznaniu się z tą migracją. Aplikacja będzie konkretnym poleceniem uruchamiania, które znasz najlepiej. Usługa Cloud Run tworzy service.yaml, który wygląda i działa bardziej jak app.yaml. Automatycznie wygenerowane service.yaml możesz zobaczyć, klikając link podobny do tego, ale dotyczący Twojej usługi SVC_NAME i REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Biblioteki innych firm

Plik requirements.txt nie musi się zmieniać. Flask powinien być w nim razem z biblioteką klienta Datastore (Cloud Datastore lub Cloud NDB). Jeśli chcesz użyć innego serwera HTTP zgodnego z WSGI, np. Gunicorn (wersja w momencie pisania tego artykułu to 20.0.4), dodaj gunicorn==20.0.4 do requirements.txt.

Konfiguracja innej firmy

Buildpacki nie obsługują języka Python 2, więc nie będziemy go tutaj omawiać. Aplikacje w Pythonie 3 działające w kontenerach w Cloud Run są podobne do aplikacji w Pythonie 3 w App Engine, ponieważ biblioteki innych firm muszą być określone w requirements.txt.

Uruchomienie

Użytkownicy Pythona 3 mogą przekonwertować pliki app.yaml, aby w sekcji handlers zamiast dyrektyw script: auto miały dyrektywy entrypoint. Jeśli w Pythonie 3 używasz entrypoint app.yaml, będzie to wyglądać mniej więcej tak:

runtime: python38
entrypoint: python main.py

Dyrektywa entrypoint informuje App Engine, jak uruchomić serwer. Możesz przenieść go niemal bezpośrednio do Procfile. Podsumowując, gdzie dyrektywa punktu wejścia powinna się znajdować na obu platformach: przekłada się to bezpośrednio na poniższe informacje. Dla Twojej wiadomości podajemy też odpowiednik w Dockerze:

  • Buildpacks: wiersz w Procfile: web: python main.py
  • Docker: wiersz w Dockerfile: ENTRYPOINT ["python", "main.py"]

Do testowania i wdrażania można łatwo uruchomić serwer deweloperski Flask z Pythona, jak pokazano powyżej, ale deweloperzy mogą wybrać coś bardziej zaawansowanego na potrzeby produkcji, np. przykładową aplikację Cloud Run Quickstart, która korzysta z gunicorn.

Pliki aplikacji

Wszystkie aplikacje z modułu 2 lub 3 są w pełni zgodne z językami Python 2 i 3, co oznacza, że nie wprowadzamy żadnych zmian w podstawowych komponentach main.py. Dodamy tylko kilka wierszy kodu startowego. Dodaj na dole pliku main.py parę wierszy, aby uruchomić serwer programistyczny. Cloud Run wymaga otwartego portu 8080, aby móc wywoływać Twoją aplikację:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. Tworzenie i wdrażanie

Po zastąpieniu konfiguracji App Engine pakietami Buildpack i zaktualizowaniu plików źródłowych możesz uruchomić aplikację w Cloud Run. Zanim to zrobimy, omówmy pokrótce usługi.

Usługi a aplikacje

App Engine została stworzona głównie do hostowania aplikacji, ale jest też platformą do hostowania usług sieciowych lub aplikacji składających się z kolekcji mikroserwisów. W Cloud Run wszystko jest usługą, niezależnie od tego, czy jest to rzeczywista usługa, czy aplikacja z interfejsem internetowym, więc traktuj jej użycie jako wdrożenie usługi, a nie aplikacji.

Jeśli aplikacja App Engine nie składała się z wielu usług, podczas wdrażania aplikacji nie trzeba było nadawać żadnych nazw. W przypadku Cloud Run musisz podać nazwę usługi. Domena appspot.com App Engine zawiera identyfikator projektu, np. https://PROJECT_ID.appspot.com, a także skrót identyfikatora regionu, np. http://PROJECT_ID.REGION_ID.r.appspot.com.

Domena usługi Cloud Run zawiera jednak nazwę usługi, skrót identyfikatora regionu i hash, ale nie identyfikator projektu, np. https://SVC_NAME-HASH-REG_ABBR.a.run.app. Podsumowując, zacznij myśleć o nazwie usługi.

Wdrażanie usługi

Aby utworzyć obraz kontenera i wdrożyć go w Cloud Run, wykonaj to polecenie. Gdy pojawi się odpowiedni komunikat, wybierz region i zezwalaj na nieuwierzytelnione połączenia, aby ułatwić testowanie. Wybierz odpowiedni region, w którym SVC_NAME to nazwa wdrażanej usługi.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Otwórz podany adres URL w przeglądarce, aby sprawdzić, czy wdrożenie się udało.

Jak wskazuje polecenie gcloud, użytkownicy mogą ustawić różne ustawienia domyślne, aby ograniczyć dane wyjściowe i interaktywność, jak pokazano powyżej. Aby na przykład uniknąć interakcji, możesz użyć tego polecenia wdrażania:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Jeśli używasz tego narzędzia, wybierz tę samą nazwę usługi SVC_NAME i odpowiednią REGION nazwę, a nie indeksowaną opcję menu, jak w przypadku interaktywnego przykładu powyżej.

6. Podsumowanie i czyszczenie

Sprawdź, czy aplikacja działa w Cloud Run tak samo jak w App Engine. Jeśli zaczniesz od tego artykułu, nie wykonując żadnych poprzednich ćwiczeń z programowania, aplikacja się nie zmieni. Będzie rejestrować wszystkie wizyty na głównej stronie internetowej (/) i po wystarczającej liczbie wizyt będzie wyglądać tak:

aplikacja visitme

Kod powinien teraz być zgodny z tym w folderze repozytorium modułu 5. Gratulujemy ukończenia ćwiczenia z modułu 5.

Opcjonalnie: zwalnianie miejsca

A co z wyczyszczeniem danych, aby uniknąć opłat do czasu, aż będziesz gotowy(-a) na kolejny etap migracji? Teraz, gdy korzystasz z innej usługi, zapoznaj się z cennikiem Cloud Run.

Opcjonalnie: wyłączanie usługi

Jeśli nie chcesz jeszcze przechodzić do następnego samouczka, wyłącz usługę, aby uniknąć dodatkowych opłat. Gdy zechcesz przejść do kolejnych ćwiczeń, możesz ponownie włączyć tę funkcję. Gdy aplikacja jest wyłączona, nie generuje ruchu, a tym samym nie powoduje naliczania opłat. Możesz jednak ponosić koszty związane z korzystaniem z Datastore, jeśli przekroczysz bezpłatny limit. W takim przypadku usuń wystarczającą ilość danych, aby zmieścić się w limicie.

Jeśli jednak nie chcesz kontynuować migracji i chcesz wszystko całkowicie usunąć, możesz usunąć usługę lub całkowicie zamknąć projekt.

Dalsze kroki

Gratulacje! Aplikacja została umieszczona w kontenerze. To koniec tego samouczka. Następnym krokiem jest dowiedzenie się, jak zrobić to samo za pomocą Dockera w ćwiczeniu praktycznym z modułu 4 (link poniżej) lub przeprowadzenie innej migracji App Engine:

  • Moduł 4. Migracja do Cloud Run za pomocą Dockera
    • Konteneryzowanie aplikacji do uruchamiania w Cloud Run za pomocą Dockera
    • Umożliwia pozostanie przy Pythonie 2
  • Moduł 7: kolejki zadań push App Engine (wymagane, jeśli używasz kolejek zadań [push])
    • Dodaje zadania push App Engine taskqueue do aplikacji Moduł 1
    • Przygotowuje użytkowników do migracji do Cloud Tasks w module 8.
  • Moduł 3:
    • Modernizacja dostępu do Datastore z Cloud NDB do Cloud Datastore
    • Jest to biblioteka używana w przypadku aplikacji App Engine w Pythonie 3 i aplikacji spoza App Engine.
  • Moduł 6. Migracja do Cloud Firestore
    • Migracja do Cloud Firestore w celu uzyskania dostępu do funkcji Firebase
    • Cloud Firestore obsługuje Pythona 2, ale te ćwiczenia są dostępne tylko w Pythonie 3.

7. Dodatkowe materiały

Problemy i opinie dotyczące ćwiczeń z programowania modułu migracji App Engine

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łów 2 i 3 (START) oraz modułu 5 (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ł 2

kod

(kod)

Moduł 3

(kod)

kod

Moduł 5

(n/a)

kod

Zasoby App Engine i Cloud Run

Poniżej znajdziesz dodatkowe materiały dotyczące tej konkretnej migracji: