Modulo 5: Migrazione da Google App Engine a Cloud Run con Cloud Buildpacks

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 Cloud Buildpacks, un'alternativa a Docker. Cloud Buildpacks inserisce le tue app in container senza gestire i file Dockerfile o senza che tu debba sapere nulla di Docker.

Questo codelab è destinato agli sviluppatori di App Engine Python 2 che hanno spostato le loro app dai servizi integrati originali e le hanno trasferite a Python 3 e che ora vogliono eseguirle in un container. Il codelab INIZIA con un'app Python 3 completata del Modulo 2 o del Modulo 3.

Imparerai come

  • Containerizza l'app utilizzando Cloud Buildpacks
  • 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, rimuovere i file di configurazione di App Engine e gestire un web server, incluso come avviare l'app.

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 funzionante del modulo 2 o 3. Se non ne hai una, ti consigliamo di completare uno dei tutorial (link sopra) prima di procedere. Altrimenti, se hai già familiarità con i contenuti, puoi iniziare prendendo una delle cartelle di codice riportate di seguito.

Che tu utilizzi il tuo o il nostro, è qui che INIZIA questo tutorial. Questo codelab ti guida nella migrazione e, al termine, il risultato dovrebbe corrispondere in gran parte a quello della cartella del repository FINISH del modulo 5.

La directory dei file START (tuoi o nostri) 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 vuoi evitare di imparare a usare Docker e vuoi containerizzare la tua app App Engine per eseguirla su Cloud Run o su qualsiasi altra piattaforma di hosting di container, sei nel posto giusto. Se ti interessa scoprire come utilizzare Docker per la containerizzazione delle app, puoi svolgere il codelab del modulo 4 dopo aver completato questo. È identico a questo, ma utilizza Docker per darti una comprensione più approfondita di come gestire le immagini container.

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 Buildpack (e, facoltativamente, Docker):

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

App Engine avvia automaticamente l'applicazione, mentre Cloud Run no. Procfile svolge un ruolo simile all'istruzione app.yaml entrypoint. Per la nostra app di esempio, Procfile eseguirà python main.py per avviare il server di sviluppo Flask. Se vuoi, puoi anche utilizzare un server web di produzione come gunicorn e, in questo caso, assicurati di aggiungerlo a requirements.txt. Scopri di più su come eseguire il deployment dal codice sorgente utilizzando Buildpacks in questa pagina della documentazione di Cloud Run.

Devi solo spostare la direttiva app.yaml entrypoint in un Procfile. Se non ne hai uno, utilizza per il momento il server di sviluppo Flask, in quanto si tratta solo di un'app di test di esempio per familiarizzare gli utenti con questa migrazione. La tua app sarà un comando di avvio specifico che conosci meglio. Sotto il cofano, il servizio Cloud Run crea un service.yaml che ha un aspetto e un comportamento più simili a un app.yaml. Puoi visualizzare i service.yaml generati automaticamente visitando un link come questo, ma per il tuo servizio SVC_NAME e REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Librerie di terze parti

Il file requirements.txt non deve essere modificato. 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

Buildpack non supporta Python 2, quindi non ne parleremo qui. Le app Python 3 in esecuzione nei container su Cloud Run sono simili alle app Python 3 di App Engine in quanto le librerie di terze parti devono essere specificate in requirements.txt.

Avvio

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 nel tuo Procfile. Riepilogo della posizione di una direttiva entrypoint tra le due piattaforme: questa si traduce direttamente in quanto segue, mostrando anche l'equivalente Docker come FYI:

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

Per i test e lo staging, è facile eseguire il server di sviluppo di Flask da Python come abbiamo fatto sopra, ma gli sviluppatori possono optare per qualcosa di più potente per la produzione, ad esempio l'esempio di guida rapida di Cloud Run che utilizza gunicorn.

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

Ora che la configurazione di App Engine è stata sostituita da Buildpack e gli aggiornamenti dei file di origine sono stati completati, puoi eseguirla 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 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

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 della cartella del repository del modulo 5. Congratulazioni per aver completato questo codelab del modulo 5.

(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. Da qui, il passaggio successivo è scoprire come fare la stessa cosa con Docker nel codelab del modulo 4 (link di seguito) o eseguire un'altra migrazione di App Engine:

  • Modulo 4: esegui la migrazione a Cloud Run con Docker
    • Containerizzare l'app per eseguirla su Cloud Run con Docker
    • Ti consente di rimanere su Python 2
  • 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 5 (FINE) sono disponibili nella tabella riportata 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 5

(n/a)

code

Risorse App Engine e Cloud Run

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