Moduł 4. Migracja z Google App Engine do Cloud Run przy użyciu Dockera

1. Omówienie

Ta seria ćwiczeń z programowania (do samodzielnego ukończenia, praktycznych samouczków) ma pomóc deweloperom w modernizacji aplikacji korzystających z Google App Engine (wersja standardowa) przez przeprowadzenie serii migracji. Dzięki temu użytkownicy mogą zwiększyć przenośność swoich aplikacji, jawnie skonteneryzując je w Cloud Run, siostrzanej usłudze Google Cloud hostującej kontenery w App Engine i innych usługach hostowania kontenerów.

Z tego samouczka dowiesz się, jak konteneryzować aplikacje App Engine na potrzeby wdrażania w usłudze w pełni zarządzanej Cloud Run za pomocą Dockera – dobrze znanej w branży platformy do tworzenia, przesyłania i uruchamiania aplikacji w kontenerach. Dla deweloperów korzystających z języka Python 2 ten samouczek rozpoczyna się od przykładowej aplikacji Cloud NDB App Engine w module, a programiści Pythona 3 – od przykładu w module Cloud Datastore.

Dowiesz się,

  • Konteneryzowanie aplikacji za pomocą Dockera
  • Wdrażanie obrazów kontenerów w Cloud Run

Czego potrzebujesz

Ankieta

Jak będziesz używać tego ćwiczenia z programowania?

tylko do przeczytania. Przeczytaj go i wykonaj ćwiczenia .

2. Tło

Systemy PaaS, takie jak App Engine i Cloud Functions, zapewniają wiele udogodnień dla zespołów i aplikacji. Na przykład te bezserwerowe platformy umożliwiają SysAdmin/Devopsa skupienie się na tworzeniu rozwiązań. Aplikację można autoskalować w górę w razie potrzeby, a rozliczać w dół do zera dzięki płatnościom na podstawie płatności za wykorzystanie, co ułatwia kontrolowanie kosztów. Aplikacje te są tworzone w różnych popularnych językach programowania.

Jednak elastyczność kontenerów także jest przekonująca – można wybrać dowolny język, dowolną bibliotekę, dowolny plik binarny. Google Cloud Run zapewnia użytkownikom to, co najlepsze w obu rozwiązaniach – wygodę korzystania z technologii bezserwerowych i elastyczność kontenerów.

W ramach tego ćwiczenia z programowania dowiesz się, jak korzystać z Cloud Run. które znajdziesz w dokumentacji Cloud Run. Dzięki temu dowiesz się, jak skonteneryzować aplikację App Engine na potrzeby Cloud Run (lub innych usług). Jest kilka rzeczy, o których należy wiedzieć przed przejściem. Przede wszystkim sposób korzystania z usługi będzie nieco inny, nieco niższy, ponieważ nie będzie już trzeba pobierać kodu aplikacji ani go wdrażać.

Zamiast tego musisz dowiedzieć się o kontenerach, na przykład jak je tworzyć i wdrażać. Musisz też zdecydować, co umieścić w obrazie kontenera, w tym także na serwerze WWW, ponieważ nie będzie już używany serwer 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 skonteneryzować aplikację, zastąpić pliki konfiguracyjne App Engine konfiguracją kontenera, określić, co ma się znaleźć w kontenerze, a także określić sposób uruchamiania aplikacji. Wiele z tych czynności jest obsługiwanych automatycznie przez App Engine.

Ta migracja obejmuje te kroki:

  1. Konfiguracja/praca
  2. Konteneryzowanie aplikacji
    • Zastąp pliki konfiguracji
    • Modyfikowanie plików aplikacji

3. Konfiguracja/praca

Zanim przejdziemy do głównej części samouczka, skonfigurujmy projekt, pobierz kod, a potem wdróż aplikację bazową. Dzięki temu będziemy wiedzieć, że zaczynamy od działającego kodu.

1. Konfigurowanie projektu

Jeśli masz już ukończony Moduł 2 lub Moduł 3 w Codelabs, zalecamy ponowne wykorzystanie tego samego projektu (i kodu). Możesz też utworzyć nowy projekt lub wykorzystać inny istniejący projekt. Sprawdź, czy projekt ma aktywne konto rozliczeniowe i jest włączone (aplikacja) App Engine.

2. Pobierz przykładową aplikację bazową

Jednym z warunków wstępnych tego ćwiczenia w Codelabs jest posiadanie działającej aplikacji w module 2 lub przykładowej aplikacji w module 3. Jeśli nie masz jeszcze takiego samouczka, przed przejściem do tego miejsca wykonaj czynności opisane w jednym z samouczków (linki znajdziesz powyżej). Jeśli nie znasz już jej zawartości, możesz zacząć od pobrania kodu Modułu 2 lub 3 poniżej.

Niezależnie od tego, czy używasz swojego czy naszego, zaczynamy od kodu w części 2 tego samouczka w języku Python 2. Podobnie jest z kodem w module 3 dla Pythona 3. To ćwiczenie w Codelabs omawia każdy krok po kroku. W zależności od dostępnych opcji powstanie kod podobny do jednego z folderów repozytorium modułu 4 (FINISH).

Katalog z plikami START (Twoimi lub naszym) modułu 2 w języku Python 2 powinien wyglądać tak:

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

Jeśli używasz własnego kodu modułu 2 (2.x), masz też folder lib. Ani lib, ani appengine_config.py nie są używane w języku Python 3, gdzie kod START modułu 3 (3.x) powinien wyglądać tak:

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

3. (Ponowne) wdrażanie aplikacji podstawowej

Pozostałe kroki do wykonania:

  1. Ponownie zapoznaj się z narzędziem wiersza poleceń gcloud
  2. Wdróż ponownie przykładową aplikację za pomocą gcloud app deploy
  3. Sprawdź, czy aplikacja działa w App Engine bez problemów

Po wykonaniu tych czynności możesz je skonteneryzować.

4. Konteneryzowanie aplikacji

Docker to obecnie standardowa platforma konteneryzacji w branży. Korzystanie z niej, jak już wspominaliśmy, wymaga dużego nakładu pracy ze strony Dockerfile, czyli pliku konfiguracji, który określa sposób tworzenia obrazów kontenerów. Z kolei pakiety Buildpacks wymagają niewielkiego wysiłku, ponieważ do określania zależności aplikacji wykorzystują introspekcję, dzięki czemu kontener Buildpacks jest maksymalnie wydajny.

Jeśli znasz już kontenery i Dockera i chcesz dowiedzieć się więcej o konteneryzowaniu aplikacji App Engine na potrzeby Cloud Run, jesteś we właściwym miejscu. Możesz też później wykonać moduł 5 z programowania (identyczny z tym, ale z Cloud Buildpacks). Nasza przykładowa aplikacja barebone jest na tyle lekka, że pozwala uniknąć niektórych z tych wspomnianych Dockerfile problemów.

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

Opis

App Engine

Docker

Pakiety kompilacji

Konfiguracja ogólna

app.yaml

Dockerfile

(service.yaml)

Biblioteki zewnętrzne

requirements.txt

requirements.txt

requirements.txt

Konfiguracja zewnętrzna

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

(nd.)

(nd.)

Uruchamianie

(nie dotyczy) lub app.yaml (jeśli używana jest wartość entrypoint)

Dockerfile

Procfile

Ignoruj pliki

.gcloudignore i .gitignore

.gcloudignore, .gitignore i .dockerignore

.gcloudignore i .gitignore

Skonteneryzowaną aplikację możesz wdrożyć w Cloud Run. Inne opcje platform kontenerów Google Cloud to Compute Engine, GKE i Anthos.

Konfiguracja ogólna

Migracja z App Engine oznacza zastąpienie app.yaml obiektem Dockerfile, który zawiera instrukcje tworzenia i uruchamiania kontenera. App Engine automatycznie uruchamia aplikację, ale Cloud Run tego nie robi. Do tego służą polecenia Dockerfile ENTRYPOINT i CMD. Dowiedz się więcej o Dockerfile z tej strony z dokumentami w Cloud Run oraz z przykładowego elementu Dockerfile, który powoduje wywołanie gunicorn.

Alternatywą dla użycia ENTRYPOINT lub CMD w elemencie Dockerfile jest użycie Procfile. .dockerignore pomaga też odfiltrowywać pliki inne niż pliki aplikacji, aby ograniczyć rozmiar kontenera. Wkrótce udostępnimy więcej informacji na ten temat.

Usuń klaster app.yaml i utwórz Dockerfile

Komponent app.yaml nie jest używany w kontenerach, więc usuń go teraz. Plik konfiguracji kontenera to Dockerfile, a nasza przykładowa aplikacja wymaga tylko minimalnego pliku. Utwórz plik Dockerfile z tą treścią, zastępując NNN ciągiem 2 lub 3 w zależności od używanej wersji Pythona:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

Większość wartości Dockerfile określa sposób utworzenia kontenera z wyjątkiemENTRYPOINT, który określa sposób uruchomienia kontenera, w tym przypadku wywołanie python main.py w celu wykonania serwera programistycznego Flask. Jeśli nie masz doświadczenia z Dockerem, dyrektywa FROM wskazuje obraz podstawowy, od którego zaczyna się obraz, i jest to „slim” (slim) odnosi się do minimalnego rozkładu Pythona. Więcej informacji znajdziesz na stronie z obrazami Dockera w Pythonie.

Środkowy zestaw poleceń tworzy katalog roboczy (/app), kopiuje pliki aplikacji, a potem uruchamia pip install, aby umieścić w kontenerze biblioteki innych firm. WORKDIR łączy ze sobą polecenia Linuksa mkdir i cd; Więcej informacji na ten temat znajdziesz w dokumentacji usługi WORKDIR . Dyrektywy COPY i RUN są jasne i niewymagające wyjaśnień.

Biblioteki zewnętrzne

Plik requirements.txt może pozostać taki sam. Narzędzie Flask powinno być tam wraz z biblioteką klienta Datastore (Cloud Datastore lub Cloud NDB). Jeśli chcesz użyć innego serwera HTTP zgodnego z WSGI, takiego jak Gunicorn – w momencie tworzenia tego tekstu bieżąca wersja to 20.0.4 – dodaj gunicorn==20.0.4 do requirements.txt.

Konfiguracja zewnętrzna

Deweloperzy App Engine w języku Python 2 wiedzą, że biblioteki zewnętrzne są kopiowane do folderu lib, do których odwołuje się requirements.txt, wyszczególnione w zasadzie app.yaml i obsługiwane przez appengine_config.py. Kontenery, takie jak aplikacje App Engine w języku Python 3, korzystają tylko z elementu requirements.txt, więc inne rzeczy mogą zostać usunięte. Oznacza to, że jeśli masz aplikację App Engine w wersji 2.x, usuń appengine_config.py i jakikolwiek folder lib.

Uruchamianie

Użytkownicy języka Python 2 nie uruchamiają serwera WWW App Engine, ale w przypadku przenoszenia do kontenera musisz to zrobić. Aby to zrobić, dodaj w tagu Dockerfile dyrektywę CMD lub ENTRYPOINT określającą, jak uruchomić aplikację. Poniżej znajdziesz instrukcje w taki sam sposób, jak w przypadku użytkowników Pythona 3.

Użytkownicy języka Python 3 mogą przekonwertować swoje pliki app.yaml tak, aby w sekcji handlers zamiast script: auto znajdowały się dyrektywy entrypoint. Jeśli użycie polecenia entrypoint w języku app.yaml w języku Python 3 spowoduje, że będzie to wyglądać mniej więcej tak:

runtime: python38
entrypoint: python main.py

Dyrektywa entrypoint informuje App Engine o tym, jak uruchomić serwer. Możesz go przenieść niemal bezpośrednio do Dockerfile (lub Procfile, jeśli do skonteneryzowania aplikacji używasz pakietów Buildpack [patrz Moduł 5]). Podsumowanie miejsc, w których dyrektywa punktu wejścia występuje na obu platformach:

  • Docker: wiersz w pliku Dockerfile: ENTRYPOINT ["python", "main.py"]
  • Pakiety kompilacji: wiersz w zakresie Procfile: web: python main.py

Możesz używać serwera programistycznego Flask do testowania, ale jeśli na potrzeby aplikacji używasz serwera produkcyjnego, takiego jak gunicorn, pamiętaj, aby skierować na niego dyrektywę ENTRYPOINT lub CMD, tak jak w przykładzie krótkiego wprowadzenia do Cloud Run.

Ignoruj pliki

Zalecamy utworzenie pliku .dockerignore, aby zmniejszyć rozmiar kontenera i nie zaśmiecać jego obrazu niepotrzebnymi plikami, takimi jak:

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

Pliki aplikacji

Wszystkie aplikacje modułów 2 i 3 są w pełni zgodne z językiem Python 2–3, co oznacza, że nie wprowadzamy żadnych zmian w podstawowych komponentach main.py. dodajemy tylko kilka wierszy kodu startowego. Dodaj parę wierszy na dole strony main.py, aby uruchomić serwer programistyczny, ponieważ Cloud Run wymaga otwartego portu 8080, aby mógł wywołać 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. Kompiluj i wdróż

Po ukończeniu konfiguracji Dockera i aktualizacji pliku źródłowego możesz ją uruchomić w Cloud Run. Zanim przejdziemy dalej, porozmawiajmy o usługach.

Usługi a aplikacje

Chociaż App Engine został stworzony przede wszystkim do hostowania aplikacji, jest to również platforma do hostowania usług internetowych lub aplikacji składających się ze zbioru mikroserwisów. W Cloud Run wszystko jest usługą – może to być rzeczywista usługa lub aplikacja z interfejsem internetowym – dlatego traktuj ją jako wdrożenie usługi, a nie aplikacji.

Jeśli Twoja aplikacja App Engine składa się z wielu usług, podczas wdrażania aplikacji nie trzeba było wybierać nazw. Zmienia się to w Cloud Run, co oznacza, że trzeba wymyślić nazwę usługi. Natomiast domena appspot.com App Engine zawiera identyfikator projektu, np. https://PROJECT_ID.appspot.com i może to być 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 hasz, ale nie identyfikator projektu, np. https://SVC_NAME-HASH-REG_ABBR.a.run.app. W skrócie – zacznij myśleć o nazwie usługi.

Wdróż usługę

Wykonaj poniższe polecenie, aby utworzyć obraz kontenera i wdrożyć go w Cloud Run. Gdy pojawi się prośba, wybierz region i zezwól na nieuwierzytelnione połączenia, aby ułatwić testowanie, i odpowiednio wybierz region, gdzie SVC_NAME to nazwa wdrażanej usługi.

$ gcloud beta 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 Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

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

Polecenie gcloud wskazuje, że użytkownicy mogą skonfigurować różne ustawienia domyślne, aby zmniejszyć dane wyjściowe i interaktywność, jak pokazano powyżej. Aby na przykład uniknąć całej interakcji, możesz zamiast tego użyć tego jednowierszowego polecenia wdrożenia:

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

Jeśli chcesz użyć tej usługi, pamiętaj, aby wybrać tę samą nazwę usługi SVC_NAME i żądaną nazwę elementu REGION, a nie wybór zindeksowanego menu (jak w interaktywny sposób powyżej).

6. Podsumowanie/Czyszczenie

Sprawdź, czy aplikacja działa w Cloud Run tak samo jak w App Engine. Jeśli dołączysz do tej serii bez wykonania żadnego z poprzednich ćwiczeń z programowania, aplikacja się nie zmieni. rejestruje wszystkie odwiedziny głównej strony internetowej (/) i wygląda tak po tym, jak kilka razy odwiedzisz witrynę:

aplikacja visitme

Twój kod powinien być teraz zgodny z zawartością folderu repozytorium w module 4 (niezależnie od tego, czy jest to 2.x, czy 3.x). Gratulujemy ukończenia modułu 4 dotyczącego programowania.

Opcjonalnie: wyczyść

A co z czyszczeniem, aby uniknąć opłat, dopóki nie wszystko będzie gotowe do przejścia do kolejnego ćwiczenia z programowania dotyczącego migracji? Ponieważ używasz teraz innej usługi, zapoznaj się z cennikiem Cloud Run.

Opcjonalnie: wyłącz usługę

Jeśli nie chcesz na razie przejść do następnego samouczka, wyłącz usługę, aby uniknąć dodatkowych opłat. Gdy uznasz, że chcesz przejść do kolejnego ćwiczenia w programowaniu, możesz je ponownie włączyć. Gdy Twoja aplikacja jest wyłączona, nie generuje ona opłat za ruch, ale opłaty mogą być jednak naliczane za wykorzystanie magazynu danychw przypadku przekroczenia bezpłatnego limitu, więc usuń tyle miejsca, aby nie przekroczyć tego limitu.

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

Dalsze kroki

Gratulacje! Udało Ci się skonteneryzować aplikację – to już koniec samouczka. Następnie dowiedz się, jak zrobić to samo z Cloud Buildpacks w ramach ćwiczenia z programowania w module 5 (link poniżej) lub podczas innej migracji App Engine:

  • Przejdź na Pythona 3, jeśli jeszcze nie zostało to zrobione. Przykładowa aplikacja jest już zgodna z wersjami 2.x i 3.x, więc jedyną zmianą jest umożliwienie użytkownikom Dockera zaktualizowania Dockerfile tak, aby używał obrazu w języku Python 3.
  • Moduł 5. Migracja do Cloud Run za pomocą pakietów Cloud Buildpacks
    • Konteneryzowanie aplikacji na potrzeby uruchamiania jej w Cloud Run za pomocą pakietów Cloud Buildpack
    • Nie musisz wiedzieć nic o Dockerze, kontenerach ani Dockerfile.
    • Wymaga wcześniejszej migracji aplikacji do Pythona 3
  • Moduł 7. Kolejki zadań App Engine (wymagane, jeśli korzystasz z kolejek zadań [push])
    • Dodaje zadania push taskqueue w App Engine do aplikacji w module 1
    • Przygotowuje użytkowników do migracji do Cloud Tasks w module 8.
  • Część 3.
    • Modernizacja dostępu do Datastore z Cloud NDB na Cloud Datastore
    • To jest biblioteka używana na potrzeby aplikacji App Engine w Pythonie 3 i aplikacji innych niż App Engine
  • Moduł 6. Migracja do Cloud Firestore
    • Przejdź na Cloud Firestore, aby uzyskać dostęp do funkcji Firebase
    • Cloud Firestore obsługuje język Python 2, ale to ćwiczenia z programowania są dostępne tylko w Pythonie 3.

7. Dodatkowe materiały

Problemy/opinie dotyczące modułu migracji App Engine

Jeśli podczas korzystania z tych ćwiczeń z programowania zauważysz jakiekolwiek problemy, najpierw je wyszukaj. Linki do wyszukiwania i tworzenia nowych problemów:

Zasoby migracji

Linki do folderów repozytorium w modułach 2 i 3 (START) oraz modułach 4 (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ęść 2

kod

(kod).

Część 3

(kod).

kod

Część 4

kod

kod

Zasoby App Engine i Cloud Run

Poniżej znajdziesz dodatkowe materiały na temat tej migracji: