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

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 pełni zarządzanej usłudze Cloud Run za pomocą Dockera, czyli znanej w branży platformy do tworzenia, dostarczania i uruchamiania aplikacji w kontenerach. Dla programistów korzystających z Pythona 2 ten samouczek ROZPOCZYNA się od przykładowej aplikacji Cloud NDB App Engine z modułu 2, a dla programistów korzystających z Pythona 3 ROZPOCZYNA się od przykładowej aplikacji Cloud Datastore z modułu 3.

Dowiesz się, jak:

  • Konteneryzowanie aplikacji za pomocą Dockera
  • 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, zastępując pliki konfiguracyjne App Engine konfiguracją kontenera, określić, co ma się w nim znajdować, a następnie określić, jak uruchomić aplikację. Wiele z tych czynności jest automatycznie obsługiwanych przez App Engine.

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 przykładowa aplikacja z modułu 2 lub 3. Jeśli jej nie masz, przed przejściem dalej wykonaj jeden z tych samouczków (linki powyżej). Jeśli znasz już jego zawartość, możesz po prostu pobrać kod modułu 2 lub 3 poniżej.

Niezależnie od tego, czy użyjesz swojego kodu, czy naszego, w przypadku wersji tego samouczka w języku Python 2 ZACZNIEMY od kodu modułu 2, a w przypadku wersji w języku Python 3 – od kodu modułu 3. W tym module 4 znajdziesz instrukcje krok po kroku. Po jego ukończeniu kod powinien przypominać jeden z folderów repozytorium modułu 4 (FINISH).

Katalog plików STARTowych modułu 2 Pythona 2 (Twój lub nasz) 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), będziesz mieć też folder lib. W przypadku języka Python 3 nie używa się ani lib, ani appengine_config.py. Kod STARTowy modułu 3 (3.x) 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 znasz już kontenery i Dockera i chcesz dowiedzieć się więcej o kontenerowaniu aplikacji App Engine na potrzeby Cloud Run, to dobrze trafiłeś. Możesz też wykonać ćwiczenie programistyczne z modułu 5 (identyczne z tym, ale z użyciem Cloud Buildpacks). Nasza podstawowa aplikacja przykładowa jest wystarczająco lekka, aby uniknąć niektórych z wymienionych wyżej problemów Dockerfile.

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ą Docker (i opcjonalnie Buildpacks):

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

Migracja z App Engine oznacza zastąpienie app.yaml plikiem Dockerfile, który zawiera informacje o tym, jak utworzyć i uruchomić kontener. App Engine automatycznie uruchamia aplikację, ale Cloud Run tego nie robi. Do tego służą polecenia Dockerfile ENTRYPOINT i CMD. Więcej informacji o Dockerfile znajdziesz na tej stronie dokumentacji Cloud Run. Możesz też zobaczyć przykład Dockerfile, który tworzy gunicorn.

Alternatywą dla używania atrybutów ENTRYPOINT lub CMD w atrybucie Dockerfile jest użycie atrybutu Procfile. Na koniec .dockerignore pomaga odfiltrować pliki inne niż pliki aplikacji, aby zmniejszyć rozmiar kontenera. Wkrótce więcej informacji na ten temat.

Usuń app.yaml i utwórz Dockerfile

Atrybut 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 minimalnej konfiguracji. Utwórz Dockerfile z tymi treściami, 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ść kodu Dockerfile określa sposób tworzenia kontenera z wyjątkiemENTRYPOINT, który określa sposób uruchamiania kontenera. W tym przypadku wywołuje python main.py, aby uruchomić serwer deweloperski Flask. Jeśli dopiero zaczynasz korzystać z Dockera, dyrektywa FROM wskazuje obraz bazowy, od którego należy zacząć, a „slim” odnosi się do minimalnej dystrybucji Pythona. Więcej informacji znajdziesz na stronie obrazów Pythona Dockera.

Środkowy zestaw poleceń tworzy katalog roboczy (/app), kopiuje pliki aplikacji, a następnie uruchamia pip install, aby przenieść biblioteki innych firm do kontenera. WORKDIR łączy ze sobą polecenia Linuxa mkdir i cd. Więcej informacji znajdziesz w WORKDIR dokumentacji . Dyrektywy COPY i RUN nie wymagają wyjaśnień.

Biblioteki innych firm

Plik requirements.txt może pozostać bez zmian. Flask powinien znajdować się 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

Deweloperzy aplikacji App Engine w języku Python 2 wiedzą, że biblioteki innych firm są kopiowane do folderu lib, dołączane do pliku requirements.txt, wymieniane w pliku app.yaml i obsługiwane przez appengine_config.py. Kontenery, podobnie jak aplikacje App Engine w Pythonie 3, używają tylko requirements.txt, więc całą resztę można usunąć. Oznacza to, że jeśli masz aplikację App Engine w wersji 2.x, usuń appengine_config.py i dowolny folder lib.

Uruchomienie

Użytkownicy Pythona 2 nie uruchamiają serwera WWW App Engine, ale podczas przenoszenia do kontenera trzeba to zrobić. W tym celu dodaj dyrektywę CMD lub ENTRYPOINT w pliku Dockerfile, określając sposób uruchamiania aplikacji. Opisano to poniżej w taki sam sposób jak w przypadku użytkowników Pythona 3.

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 Dockerfile (lub Procfile, jeśli do konteneryzacji aplikacji używasz pakietów Buildpack [patrz moduł 5]). Podsumowanie, gdzie dyrektywa punktu wejścia powinna się znajdować na obu platformach:

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

Korzystanie z serwera deweloperskiego Flask jest w porządku w przypadku testowania, ale jeśli używasz serwera produkcyjnego, np. gunicorn, w swojej aplikacji, pamiętaj, aby skierować do niego dyrektywę ENTRYPOINT lub CMD, tak jak w przykładowym krótkim wprowadzeniu do Cloud Run.

Ignorowanie plików

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

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

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 wprowadzeniu zmian w konfiguracji Dockera i pliku źródłowym możesz uruchomić go 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 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

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

Twój kod powinien teraz odpowiadać temu, co znajduje się w folderze repozytorium modułu 4, niezależnie od tego, czy jest to wersja 2.x czy 3.x. Gratulujemy ukończenia ćwiczenia z modułu 4.

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ą Cloud Buildpacks w ćwiczeniu z programowania w module 5 (link poniżej) lub przeprowadzenie innej migracji App Engine:

  • Przejdź na Pythona 3, jeśli jeszcze tego nie zrobiono. Przykładowa aplikacja jest już zgodna z wersjami 2.x i 3.x, więc jedyną zmianą dla użytkowników Dockera jest zaktualizowanie Dockerfile, aby używać obrazu Pythona 3.
  • Moduł 5. Migracja do Cloud Run za pomocą Cloud Buildpacks
    • Konteneryzowanie aplikacji do uruchamiania w Cloud Run za pomocą pakietów kompilacji Cloud Build
    • Nie musisz nic wiedzieć o Dockerze, kontenerach ani Dockerfiles.
    • Wymaga przeniesienia aplikacji do Pythona 3.
  • 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 4 (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ł 4

kod

kod

Zasoby App Engine i Cloud Run

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