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

1. Panoramica

Questa serie di codelab (tutorial pratici e self-service) mira ad aiutare gli sviluppatori di Google App Engine (standard) a modernizzare le loro app, guidandoli attraverso una serie di migrazioni. Dopodiché, gli utenti possono rendere le loro app più portabili containerizzandole esplicitamente per Cloud Run, il servizio gemello di hosting dei container di Google Cloud per App Engine e altri servizi di hosting dei container.

Questo tutorial insegna a containerizzare le app di App Engine per eseguirne il deployment nel servizio completamente gestito Cloud Run utilizzando Cloud Buildpacks, un'alternativa a Docker. I Cloud Buildpacks containerizzano le tue app senza gestire i file Dockerfile né sapere nulla su Docker.

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

Imparerai a

  • Containerizza la tua app con Cloud Buildpacks
  • Esegui il deployment delle immagini container in Cloud Run

Che cosa ti serve

Sondaggio

Come utilizzerai questo codelab?

Da leggere solo Leggilo e completa gli esercizi

2. Sfondo

I sistemi PaaS come App Engine e Cloud Functions offrono molte comodità 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ò fare lo scale up automatico in base alle esigenze e lo scale down a zero con la fatturazione pay-per-use per controllare i costi. Inoltre, utilizza una serie di linguaggi di sviluppo comuni.

Tuttavia, anche la flessibilità dei container è convincente, in quanto permette di scegliere qualsiasi linguaggio, libreria o programma binario. Google Cloud Run offre agli utenti il meglio di entrambi i mondi, la comodità del serverless e la flessibilità dei container.

Imparare a utilizzare Cloud Run non rientra nell'ambito di questo codelab; a cui si applica la documentazione di Cloud Run. L'obiettivo qui è sapere come containerizzare la tua app App Engine per Cloud Run (o altri servizi). Prima di procedere, ci sono alcune cose che dovresti sapere, principalmente che l'esperienza utente sarà leggermente diversa e un po' più bassa poiché non prenderai più il codice dell'applicazione e non ne eseguirai più il deployment.

Dovrai invece apprendere qualcosa sui container, ad esempio come crearli ed eseguirne il deployment. Puoi anche decidere cosa inserire nell'immagine container, incluso un server web, in quanto non utilizzerai più il server web di App Engine. Se preferisci non seguire questo percorso, mantenere le tue app su App Engine non è un errore.

In questo tutorial imparerai a containerizzare la tua app, rimuovere i file di configurazione di App Engine e gestire un server web, nonché come avviare l'app.

Questa migrazione prevede i seguenti passaggi:

  1. Configurazione/pre-lavoro
  2. Containerizza applicazione
    • Sostituisci i file di configurazione
    • Modifica i file delle applicazioni

3. Configurazione/pre-lavoro

Prima di proseguire con la parte principale del tutorial, impostiamo il progetto, recuperiamo il codice ed eseguiamo il deployment dell'app di base in modo da sapere di aver iniziato con il codice funzionante.

1. Configura il progetto

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

2. Ottieni app di esempio di riferimento

Uno dei prerequisiti di questo codelab è avere un'app di esempio del Modulo 2 o 3 funzionante. Se non ne hai uno, ti consigliamo di completare uno dei tutorial (link sopra) prima di procedere. Altrimenti, se conosci già i loro contenuti, puoi iniziare cercando una delle cartelle di codice qui sotto.

Che tu usi il tuo o il nostro, è da qui che nasce questo tutorial. Questo codelab ti guida nella migrazione e, al termine, dovrebbe corrispondere per lo più al contenuto della cartella di repository FINISH del Modulo 5.

La directory dei file START (tuoi o nostri) dovrebbe essere simile a questa:

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

3. (Ri)Esegui il deployment dell'app di riferimento

I passaggi preliminari rimanenti da eseguire ora:

  1. Acquisisci 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 questi passaggi, puoi containerizzarla.

4. Containerizza applicazione

Docker è la piattaforma di containerizzazione standard del settore. Una delle difficoltà del suo utilizzo, come già accennato, è che richiede un impegno per selezionare un Dockerfile efficiente, il file di configurazione che determina il modo in cui vengono create le immagini container. I Buildpacks, invece, richiedono uno sforzo minimo in quanto utilizzano l'introspezione per determinare le dipendenze dell'app, rendendo il container Buildpacks il più efficiente possibile per la tua app.

Sei nel posto giusto se vuoi saltare le informazioni su Docker e vuoi containerizzare la tua app di App Engine per l'esecuzione su Cloud Run o qualsiasi altra piattaforma di hosting di container. Se vuoi imparare a utilizzare Docker per la containerizzazione delle app, puoi completare il codelab del Modulo 4 al termine di questo modulo. È identico a questo, ma utilizza Docker per offrirti 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 di come deve essere avviata l'applicazione. Di seguito è riportata una tabella che riepiloga i file di configurazione previsti per ogni tipo di piattaforma. Confronta la colonna di App Engine con la colonna Buildpacks (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 2.x])

(n/d)

(n/d)

Avvio

(n/d) o app.yaml (se utilizzato entrypoint)

Dockerfile

Procfile

Ignora file

.gcloudignore e .gitignore

.gcloudignore, .gitignore e .dockerignore

.gcloudignore e .gitignore

Una volta containerizzata l'app, puoi eseguirne il deployment in Cloud Run. Altre opzioni di piattaforma per container di Google Cloud includono Compute Engine, GKE e Anthos.

Configurazione generale

App Engine avvia automaticamente l'applicazione, al contrario di Cloud Run. L'istruzione Procfile svolge un ruolo simile all'istruzione app.yaml entrypoint. Per l'app di esempio, Procfile eseguirà python main.py per avviare il server di sviluppo di 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 l'istruzione app.yaml entrypoint in un Procfile. Se non ne hai uno, utilizza il server di sviluppo Flask per il momento, poiché 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. In questo modo, il servizio Cloud Run crea un oggetto service.yaml che assomiglia più a un app.yaml. Puoi vedere i service.yaml generati automaticamente visitando un link come questo, ma per i tuoi servizi SVC_NAME e REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Librerie di terze parti

Non è necessario modificare il file requirements.txt. Flask deve essere presente insieme alla libreria client Datastore (Cloud Datastore o Cloud NDB). Se vuoi utilizzare un altro server HTTP compatibile con WSGI come Gunicorn, la versione corrente al momento della stesura di questo documento è la 20.0.4, aggiungi gunicorn==20.0.4 a requirements.txt.

Configurazione di terze parti

Buildpacks 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 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 istruzioni entrypoint anziché script: auto nella sezione handlers. Se utilizzi entrypoint in app.yaml Python 3, l'aspetto sarà simile a questo:

runtime: python38
entrypoint: python main.py

L'istruzione entrypoint indica ad App Engine come avviare il server. Puoi spostarlo quasi direttamente nel tuo Procfile. Riassumere la posizione di una direttiva del punto di ingresso tra le due piattaforme: ciò si traduce direttamente in: mostrando anche l'equivalente Docker a titolo informativo:

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

Per il test e la gestione temporanea, è facile eseguire il server di sviluppo di Flask da Python, come abbiamo già detto, ma gli sviluppatori possono optare per qualcosa di più potente per la produzione, come l'esempio della guida rapida di Cloud Run che utilizza gunicorn.

File dell'applicazione

Tutte le app del Modulo 2 o 3 sono completamente compatibili con Python 2-3, il che significa che non sono previste modifiche ai componenti principali di main.py. aggiungeremo solo poche righe di codice di avvio. Aggiungi un paio di righe nella parte inferiore di main.py per avviare il server di sviluppo, poiché Cloud Run richiede che la porta 8080 sia aperta in modo che possa 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

Dopo aver sostituito la configurazione di App Engine con Buildpacks e gli aggiornamenti dei file di origine completati, è tutto pronto per eseguirlo su Cloud Run. Prima di questo, parliamo brevemente dei servizi.

Confronto tra servizi e app

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

A meno che la tua app App Engine non fosse composta da più servizi, in realtà non hai dovuto assegnare alcun tipo di denominazione quando esegui il deployment delle applicazioni. Questo cambia in Cloud Run, dove devi trovare un nome di servizio. mentre il dominio appspot.com di App Engine presenta il proprio 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 per un servizio Cloud Run presenta 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 breve, inizia a pensare al nome di un servizio.

Esegui il deployment del servizio

Esegui il comando in basso per creare la tua immagine container ed eseguirne il deployment in Cloud Run. Quando richiesto, seleziona la tua regione e consenti le connessioni non autenticate per semplificare i test, quindi seleziona la tua regione appropriata, dove SVC_NAME è il nome del servizio di cui esegui il deployment.

$ 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 riuscito.

Come indica il comando gcloud, gli utenti possono configurare varie impostazioni predefinite per ridurre l'output e l'interattività, come mostrato sopra. Ad esempio, per evitare ogni interazione, puoi utilizzare invece il seguente comando di deployment di una riga:

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

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

6. Riepilogo/Pulizia

Verifica che l'app funzioni su Cloud Run come su App Engine. Se hai seguito questa serie senza aver eseguito nessuno dei codelab precedenti, l'app in sé non cambierà: vengono registrate tutte le visite alla pagina web principale (/) e si presenta come questa una volta che hai visitato il sito un numero sufficiente di volte:

app visitme

Il codice dovrebbe corrispondere ora al contenuto della cartella di repository del Modulo 5. Congratulazioni per aver completato il codelab del Modulo 5.

(Facoltativo) Eseguire la pulizia

Che ne dici di eseguire la pulizia per evitare di ricevere addebiti finché non decidi di passare al codelab di migrazione successivo? Poiché ora stai utilizzando un prodotto diverso, assicurati di consultare la guida ai prezzi di Cloud Run.

(Facoltativo) Disattiva il servizio

Se non vuoi ancora passare al prossimo tutorial, disattiva il servizio per evitare addebiti aggiuntivi. Quando vuoi passare al codelab successivo, puoi riabilitarlo. Mentre l'app è disabilitata, non riceverà traffico che comporta addebiti, ma un'altra cosa che ti può essere fatturata è l'utilizzo di Datastore se supera la quota senza costi, quindi eliminane un numero sufficiente per rientrare nel limite.

Se invece non intendi continuare con le migrazioni e vuoi eliminare completamente tutto, puoi eliminare il servizio o arrestare il progetto completamente.

Passaggi successivi

Complimenti, hai containerizzato la tua app, quindi il tutorial è terminato. Da qui, il passaggio successivo è imparare a fare la stessa cosa con Docker nel codelab del modulo 4 (link di seguito) o eseguire un'altra migrazione ad App Engine:

  • Modulo 4: Esegui la migrazione a Cloud Run con Docker
    • Containerizza la tua app per eseguirla su Cloud Run con Docker
    • Consente di rimanere su Python 2
  • Modulo 7: Code di attività push di App Engine (obbligatorie se utilizzi le code di attività [push])
    • Aggiunge attività push di taskqueue di App Engine all'app del modulo 1
    • Prepara gli utenti alla migrazione a Cloud Tasks nel modulo 8
  • Modulo 3:
    • Modernizza l'accesso a Datastore da Cloud NDB a Cloud Datastore
    • Questa è la libreria utilizzata per le app App Engine e Python 3 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 dei codelab per i moduli di migrazione di App Engine

Se riscontri problemi con questo codelab, cercali prima di procedere con l'invio. Link per eseguire ricerche e creare nuovi problemi:

Risorse di migrazione

I collegamenti alle cartelle repository per i moduli 2 e 3 (START) e 5 (FINISH) sono riportati nella tabella seguente. Sono inoltre accessibili dal repository per tutte le migrazioni del codelab di App Engine che puoi clonare o scaricare un file ZIP.

Codelab

Python 2

Python 3

Modulo 2

codice

(codice)

Module 3

(codice)

codice

Modulo 5

(n/d)

codice

Risorse App Engine e Cloud Run

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