Modulo 4: Migrazione da Google App Engine a Cloud Run con Docker

1. Panoramica

Questa serie di codelab (tutorial pratici e autogestiti) ha lo scopo di aiutare gli sviluppatori di Google App Engine (standard) a modernizzare le loro app guidandoli attraverso una serie di migrazioni. Una volta fatto ciò, gli utenti possono rendere le loro app più portatili containerizzandole esplicitamente per Cloud Run, il servizio di hosting di container di Google Cloud simile ad App Engine, e altri servizi di hosting di container.

Questo tutorial ti insegna a inserire in un container le app App Engine per il deployment nel servizio completamente gestito Cloud Run utilizzando Docker, una piattaforma ben nota nel settore per lo sviluppo, la spedizione e l'esecuzione di applicazioni in container. Per gli sviluppatori Python 2, questo tutorial INIZIA con l'app di esempio Cloud NDB App Engine del modulo 2, mentre gli sviluppatori Python 3 INIZIANO con l'esempio Cloud Datastore del modulo 3.

Imparerai come

  • Containerizza l'app utilizzando Docker
  • Eseguire il deployment delle immagini container in Cloud Run

Che cosa ti serve

Sondaggio

Come utilizzerai questo codelab?

Solo leggere Leggere e completare gli esercizi

2. Sfondo

I sistemi PaaS come App Engine e Cloud Functions offrono molti vantaggi per il tuo team e la tua applicazione. Ad esempio, queste piattaforme serverless consentono a SysAdmin/DevOps di concentrarsi sulla creazione di soluzioni. La tua app può scalare automaticamente in base alle esigenze, scalare a zero con la fatturazione pay-per-use per controllare i costi e utilizza una serie di linguaggi di sviluppo comuni.

Tuttavia, anche la flessibilità dei container è interessante, in quanto consente di scegliere qualsiasi linguaggio, libreria o programma binario. Offrire agli utenti il meglio di entrambi i mondi, la praticità del serverless e la flessibilità dei container, è l'obiettivo di Google Cloud Run.

L'apprendimento dell'utilizzo di Cloud Run non rientra nell'ambito di questo codelab, ma è trattato nella documentazione di Cloud Run. L'obiettivo è che tu sappia come inserire in un container l'app App Engine per Cloud Run (o altri servizi). Prima di procedere, devi sapere alcune cose, in particolare che la tua esperienza utente sarà leggermente diversa, un po' più di basso livello, in quanto non prenderai più il codice dell'applicazione e non lo implementerai.

Dovrai invece imparare qualcosa sui container, ad esempio come crearli e implementarli. Puoi anche decidere cosa inserire nell'immagine container, incluso un web server, poiché non utilizzerai più il web server di App Engine. Se preferisci non seguire questo percorso, mantenere le tue app su App Engine non è una cattiva opzione.

In questo tutorial imparerai a inserire la tua app in un container, sostituendo i file di configurazione di App Engine con la configurazione del container, a determinare cosa inserire nel container e a specificare come avviare l'app. Molte di queste operazioni vengono gestite automaticamente da App Engine.

Questa migrazione prevede i seguenti passaggi:

  1. Configurazione/preparazione
  2. Containerizza applicazione
    • Sostituisci i file di configurazione
    • Modificare i file dell'applicazione

3. Configurazione/preparazione

Prima di iniziare la parte principale del tutorial, configuriamo il progetto, recuperiamo il codice e poi implementiamo l'app di base per assicurarci di iniziare con un codice funzionante.

1. Configura il progetto

Se hai completato i codelab del modulo 2 o del modulo 3, ti consigliamo di riutilizzare lo stesso progetto (e codice). In alternativa, puoi creare un nuovo progetto o riutilizzarne uno esistente. Assicurati che il progetto abbia un account di fatturazione attivo e che App Engine (app) sia abilitato.

2. Ottieni l'app di esempio di base

Uno dei prerequisiti di questo codelab è avere un'app di esempio del modulo 2 o del modulo 3 funzionante. Se non ne hai una, completa uno dei tutorial (link sopra) prima di procedere. In caso contrario, se hai già familiarità con i contenuti, puoi iniziare prendendo il codice del modulo 2 o 3 riportato di seguito.

Che tu utilizzi il tuo o il nostro, il codice del Modulo 2 è il punto di partenza per la versione Python 2 di questo tutorial, mentre il codice del Modulo 3 è il punto di partenza per Python 3. Questo codelab del modulo 4 ti guida in ogni passaggio e, a seconda delle opzioni, al termine dovresti ottenere un codice simile a una delle cartelle del repository del modulo 4 (FINISH).

La directory dei file START di Python 2 Module 2 (tuoi o nostri) dovrebbe avere il seguente aspetto:

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

Se utilizzi il tuo codice del modulo 2 (2.x), avrai anche una cartella lib. lib e appengine_config.py non vengono utilizzati per Python 3, dove il codice STARTing del modulo 3 (3.x) dovrebbe avere il seguente aspetto:

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

3. (Esegui di nuovo il deployment dell'app di base

I passaggi preliminari rimanenti da eseguire ora:

  1. Acquisisci di nuovo familiarità con lo strumento a riga di comando gcloud
  2. Esegui di nuovo il deployment dell'app di esempio con gcloud app deploy
  3. Verifica che l'app venga eseguita su App Engine senza problemi

Una volta eseguiti correttamente questi passaggi, puoi creare il container.

4. Containerizza l'applicazione

Docker è la piattaforma di containerizzazione standard del settore. Come accennato in precedenza, una delle difficoltà nell'utilizzo è che richiede uno sforzo per creare un Dockerfile efficiente, ovvero il file di configurazione che determina la modalità di creazione delle immagini container. I buildpack, invece, richiedono poco impegno, in quanto utilizzano l'introspezione per determinare le dipendenze dell'app, rendendo il container buildpack il più efficiente possibile per la tua app.

Se hai già familiarità con i container e Docker e vuoi saperne di più sulla containerizzazione della tua app App Engine per Cloud Run, sei nel posto giusto. Se vuoi, puoi anche svolgere il codelab del modulo 5 (identico a questo, ma con Cloud Buildpacks) in un secondo momento. La nostra app di esempio essenziale è abbastanza leggera da evitare alcuni dei problemi Dockerfile menzionati in precedenza.

I passaggi di migrazione includono la sostituzione dei file di configurazione di App Engine e la specifica della modalità di avvio dell'app. Di seguito è riportata una tabella che riepiloga i file di configurazione previsti per ogni tipo di piattaforma. Confronta la colonna App Engine con la colonna Docker (e, facoltativamente, Buildpack):

Descrizione

App Engine

Docker

Buildpack

Configurazione generale

app.yaml

Dockerfile

(service.yaml)

Librerie di terze parti

requirements.txt

requirements.txt

requirements.txt

Configurazione di terze parti

app.yaml (più appengine_config.py e lib [solo versione 2.x])

(n/a)

(n/a)

Avvio

(n/a) o app.yaml (se viene utilizzato entrypoint)

Dockerfile

Procfile

Ignorare i file

.gcloudignore e .gitignore

.gcloudignore, .gitignore e .dockerignore

.gcloudignore e .gitignore

Una volta containerizzata, l'app può essere sottoposta a deployment in Cloud Run. Altre opzioni della piattaforma container di Google Cloud includono Compute Engine, GKE e Anthos.

Configurazione generale

La migrazione da App Engine comporta la sostituzione di app.yaml con un Dockerfile che descrive come creare ed eseguire il container. App Engine avvia automaticamente l'applicazione, mentre Cloud Run no. A questo scopo servono i comandi Dockerfile ENTRYPOINT e CMD. Scopri di più su Dockerfile in questa pagina della documentazione di Cloud Run e guarda un esempio di Dockerfile che genera gunicorn.

Un'alternativa all'utilizzo di ENTRYPOINT o CMD in un Dockerfile è l'utilizzo di un Procfile. Infine, un .dockerignore aiuta a filtrare i file non dell'app per ridurre le dimensioni del contenitore. Scopri di più su queste novità in arrivo.

Elimina app.yaml e crea Dockerfile

app.yaml non viene utilizzato nei container, quindi eliminalo ora. Il file di configurazione del container è Dockerfile e la nostra app di esempio ne richiede solo uno minimo. Crea il tuo Dockerfile con questi contenuti, sostituendo NNN con 2 o 3, a seconda della versione di Python che utilizzi:

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

La maggior parte di Dockerfile specifica come creare il container tranne ENTRYPOINT, che specifica come avviare il container, in questo caso chiamando python main.py per eseguire il server di sviluppo Flask. Se non hai familiarità con Docker, l'istruzione FROM indica l'immagine di base da cui iniziare, mentre "slim" si riferisce a una distribuzione Python minima. Scopri di più nella pagina delle immagini Docker Python.

Il set di comandi centrale crea la directory di lavoro (/app), copia i file dell'applicazione, quindi esegue pip install per importare le librerie di terze parti nel container. WORKDIR combina i comandi Linux mkdir e cd; scopri di più nella documentazione di WORKDIR . Le direttive COPY e RUN sono autoesplicative.

Librerie di terze parti

Il file requirements.txt può rimanere invariato; Flask deve essere presente insieme alla libreria client Datastore (Cloud Datastore o Cloud NDB). Se vuoi utilizzare un altro server HTTP conforme a WSGI, come Gunicorn (la versione attuale al momento della stesura di questo articolo è la 20.0.4), aggiungi gunicorn==20.0.4 a requirements.txt.

Configurazione di terze parti

Gli sviluppatori di App Engine Python 2 sanno che le librerie di terze parti vengono copiate nella cartella lib, a cui viene fatto riferimento in requirements.txt, elencate in app.yaml e supportate da appengine_config.py. I container, come le app Python 3 App Engine, utilizzano solo requirements.txt, quindi tutto il resto può essere eliminato. Ciò significa che se hai un'app App Engine 2.x, elimina appengine_config.py e qualsiasi cartella lib ora.

Avvio

Gli utenti di Python 2 non avviano il web server di App Engine, ma quando passano a un container, devono farlo. A questo scopo, aggiungi un'istruzione CMD o ENTRYPOINT nel file Dockerfile che specifica come avviare l'app. Questa procedura è descritta di seguito nello stesso modo degli utenti di Python 3.

Gli utenti di Python 3 hanno la possibilità di convertire i propri file app.yaml in modo che abbiano direttive entrypoint anziché script: auto nella sezione handlers. Se utilizzi entrypoint nel tuo app.yaml Python 3, il risultato sarà simile a questo:

runtime: python38
entrypoint: python main.py

La direttiva entrypoint indica ad App Engine come avviare il server. Puoi spostarlo quasi direttamente in Dockerfile (o Procfile se utilizzi i buildpack [vedi il modulo 5] per inserire l'app in un container). Riepilogo della posizione di un'istruzione del punto di ingresso tra le due piattaforme:

  • Docker: riga in Dockerfile: ENTRYPOINT ["python", "main.py"]
  • Buildpack: riga in Procfile: web: python main.py

L'utilizzo del server di sviluppo Flask è accettabile per i test, ma se utilizzi un server di produzione come gunicorn per la tua applicazione, assicurati di indirizzare la direttiva ENTRYPOINT o CMD come nell'esempio di avvio rapido di Cloud Run.

Ignorare i file

Ti consigliamo di creare un file .dockerignore per ridurre le dimensioni del container e non ingombrare l'immagine container con file superflui come:

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

File dell'applicazione

Tutte le app del modulo 2 o del modulo 3 sono completamente compatibili con Python 2-3, il che significa che non vengono apportate modifiche ai componenti principali di main.py; aggiungeremo solo alcune righe di codice di avvio. Aggiungi una coppia di righe nella parte inferiore di main.py per avviare il server di sviluppo, poiché Cloud Run richiede che la porta 8080 sia aperta per poter chiamare la tua app:

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

5. Creazione e deployment

Una volta completati gli aggiornamenti della configurazione Docker e del file di origine, puoi eseguirlo su Cloud Run. Prima di farlo, parliamo brevemente dei servizi.

Servizi e app

Sebbene App Engine sia stato creato principalmente per ospitare applicazioni, è anche una piattaforma per l'hosting di servizi web o applicazioni costituite da una raccolta di microservizi. In Cloud Run, tutto è un servizio, che si tratti di un servizio vero e proprio o di un'applicazione con un'interfaccia web, quindi considera il suo utilizzo come il deployment di un servizio anziché di un'applicazione.

A meno che la tua app App Engine non fosse composta da più servizi, non dovevi eseguire alcun tipo di denominazione durante il deployment delle applicazioni. Questo cambia con Cloud Run, dove devi trovare un nome del servizio. Il dominio appspot.com di App Engine include l'ID progetto, ad esempio https://PROJECT_ID.appspot.com, e forse l'abbreviazione dell'ID regione, ad esempio http://PROJECT_ID.REGION_ID.r.appspot.com.

Tuttavia, il dominio di un servizio Cloud Run include il nome del servizio, l'abbreviazione dell'ID regione e un hash, ma non l'ID progetto, ad esempio https://SVC_NAME-HASH-REG_ABBR.a.run.app. In sintesi, inizia a pensare a un nome per il servizio.

Esegui il deployment del servizio

Esegui il comando riportato di seguito per creare l'immagine container ed eseguire il deployment in Cloud Run. Quando richiesto, seleziona la tua regione e consenti le connessioni non autenticate per semplificare i test e seleziona la tua regione in modo appropriato, dove SVC_NAME è il nome del servizio che stai implementando.

$ 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

Visita l'URL specificato con il browser per verificare che il deployment sia stato eseguito correttamente.

Come indica il comando gcloud, gli utenti possono impostare varie impostazioni predefinite per ridurre l'output e l'interattività, come mostrato sopra. Ad esempio, per evitare qualsiasi interazione, puoi utilizzare il seguente comando di deployment one-liner:

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

Se utilizzi questo, assicurati di selezionare lo stesso nome del servizio SVC_NAME e il nome REGION desiderato, non la selezione del menu indicizzata come abbiamo fatto in modo interattivo sopra.

6. Riepilogo/Pulizia

Verifica che l'app funzioni su Cloud Run come su App Engine. Se hai iniziato questa serie senza aver svolto i codelab precedenti, l'app non cambia. Registra tutte le visite alla pagina web principale (/) e ha questo aspetto dopo che hai visitato il sito un numero sufficiente di volte:

app visitme

Il codice ora dovrebbe corrispondere a quello presente nella cartella del repository del modulo 4, che sia 2.x o 3.x. Congratulazioni per aver completato questo codelab del modulo 4.

(Facoltativo) Pulizia

Eseguire la pulizia per evitare addebiti fino a quando non sarai pronto per passare al codelab di migrazione successivo. Ora che utilizzi un prodotto diverso, assicurati di consultare la guida ai prezzi di Cloud Run.

(Facoltativo) Disattiva il servizio

Se non sei ancora pronto per passare al tutorial successivo, disattiva il servizio per evitare costi aggiuntivi. Quando vuoi passare al codelab successivo, puoi riattivarlo. Mentre l'app è disattivata, non riceverà traffico per generare addebiti. Tuttavia, un altro aspetto per cui potresti ricevere una fattura è l'utilizzo di Datastore se supera la quota senza costi, quindi elimina i dati sufficienti per rientrare in questo limite.

D'altra parte, se non intendi continuare con le migrazioni e vuoi eliminare tutto completamente, puoi eliminare il servizio o arrestare completamente il progetto.

Passaggi successivi

Congratulazioni, hai inserito la tua app in un container. Questo conclude il tutorial. A questo punto, il passaggio successivo consiste nell'imparare a fare la stessa cosa con Cloud Buildpacks nel codelab del modulo 5 (link di seguito) o eseguire un'altra migrazione di App Engine:

  • Esegui la migrazione a Python 3, se non l'hai ancora fatto. L'app di esempio è già compatibile con le versioni 2.x e 3.x, quindi l'unica modifica riguarda gli utenti Docker che devono aggiornare Dockerfile per utilizzare un'immagine Python 3.
  • Modulo 5: esegui la migrazione a Cloud Run con Cloud Buildpacks
    • Containerizzare l'app per eseguirla su Cloud Run con Cloud Buildpacks
    • Non devi sapere nulla di Docker, dei container o di Dockerfiles
    • Richiede che tu abbia già eseguito la migrazione dell'app a Python 3
  • Modulo 7: code di attività push di App Engine (obbligatorio se utilizzi le code di attività [push])
    • Aggiunge le attività push di App Engine taskqueue all'app del modulo 1
    • Prepara gli utenti alla migrazione a Cloud Tasks nel modulo 8
  • Modulo 3:
    • Modernizzare l'accesso a Datastore da Cloud NDB a Cloud Datastore
    • È la libreria utilizzata per le app Python 3 App Engine e non App Engine
  • Modulo 6: esegui la migrazione a Cloud Firestore
    • Esegui la migrazione a Cloud Firestore per accedere alle funzionalità di Firebase
    • Sebbene Cloud Firestore supporti Python 2, questo codelab è disponibile solo in Python 3.

7. Risorse aggiuntive

Problemi/feedback relativi ai codelab del modulo di migrazione di App Engine

Se riscontri problemi con questo codelab, cerca prima il tuo problema prima di presentare una segnalazione. Link per cercare e creare nuovi problemi:

Risorse per la migrazione

I link alle cartelle del repository per i moduli 2 e 3 (INIZIO) e il modulo 4 (FINE) sono disponibili nella tabella di seguito. Puoi accedervi anche dal repository per tutte le migrazioni dei codelab di App Engine, che puoi clonare o scaricare come file ZIP.

Codelab

Python 2

Python 3

Modulo 2

code

(codice)

Module 3

(codice)

code

Modulo 4

code

code

Risorse App Engine e Cloud Run

Di seguito sono riportate risorse aggiuntive relative a questa migrazione specifica: