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 Docker, una nota piattaforma del settore per lo sviluppo, la distribuzione e l'esecuzione di applicazioni nei container. Per gli sviluppatori Python 2, questo tutorial INIZIA con l'app di esempio App Engine NDB Cloud Modulo 2, mentre gli sviluppatori Python 3 INIZIANO con l'esempio di Cloud Datastore del Modulo 3.
Imparerai a
- Containerizza la tua app con Docker
- Esegui il deployment delle immagini container in Cloud Run
Che cosa ti serve
- Un progetto Google Cloud Platform con:
- Competenze Python di base
- Conoscenza pratica dei comandi Linux più comuni
- Conoscenza di base dello sviluppo e del deployment delle app App Engine
- Consigliato: completa il codelab del Modulo 2 o il codelab del Modulo 3
- Un'app App Engine funzionante pronta per essere containerizzata
- Python 2: Esempio di Cloud NDB del Modulo 2
- Python 3: Esempio di Cloud Datastore del Modulo 3
Sondaggio
Come utilizzerai questo codelab?
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, a sostituire 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:
- Configurazione/pre-lavoro
- 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, completa uno dei tutorial (link sopra) prima di proseguire qui. Altrimenti, se ne hai già familiarità con il contenuto, puoi iniziare semplicemente recuperando il codice del modulo 2 o 3 riportato di seguito.
Sia che usi il tuo o il nostro, il codice del Modulo 2 è dove AVVIeremo la versione Python 2 di questo tutorial e, allo stesso modo, il codice del Modulo 3 per Python 3. Questo codelab del modulo 4 illustra ogni passaggio e, a seconda delle opzioni, al termine dovrebbe ricavarne un codice simile a una delle cartelle dei repository del modulo 4 (FINISH).
- Python 2 (app Cloud NDB)
- AVVIO: Codice del Modulo 2
- FINISH: Codice del Modulo 4
- Python 3 (app Cloud Datastore)
- AVVIO: Codice del Modulo 3
- FINISH: Codice del Modulo 4
- Intero repository (per clonare o scaricare il file ZIP)
La directory dei file Python 2 del Modulo 2 AVVIO (tuoi o nostri) dovrebbe avere questo aspetto:
$ ls
README.md appengine_config.py requirements.txt
app.yaml main.py templates
Se stai utilizzando il tuo codice del modulo 2 (2.x), avrai anche una cartella lib. Né lib né appengine_config.py vengono utilizzati per Python 3, dove il codice di AVVIO del modulo 3 (3.x) dovrebbe avere il seguente aspetto:
$ 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:
- Acquisisci familiarità con lo strumento a riga di comando
gcloud - Esegui di nuovo il deployment dell'app di esempio con
gcloud app deploy - 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.
Se conosci già container, Docker e vuoi saperne di più sulla containerizzazione della tua app App Engine per Cloud Run, sei nel posto giusto. Successivamente, puoi anche eseguire il codelab del Modulo 5 (identico a questo, ma con Cloud Buildpacks). La nostra app di esempio essenziale è sufficientemente leggera da evitare alcuni dei problemi di Dockerfile sopra citati.
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 Docker (e facoltativamente Buildpacks):
Descrizione | App Engine | Docker | Buildpack |
Configurazione generale |
|
| ( |
Librerie di terze parti |
|
|
|
Configurazione di terze parti |
| (n/d) | (n/d) |
Avvio | (n/d) o |
|
|
Ignora file |
|
|
|
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
La migrazione da App Engine significa sostituire app.yaml con un elemento Dockerfile che illustra come creare ed eseguire il container. App Engine avvia automaticamente l'applicazione, al contrario di Cloud Run. 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 Dockerfile che genera gunicorn.
In alternativa all'utilizzo di ENTRYPOINT o CMD in Dockerfile, puoi utilizzare Procfile. Infine, un .dockerignore consente di filtrare i file non dell'app per contenere le dimensioni del contenitore. Altre informazioni a riguardo saranno disponibili a breve.
Elimina app.yaml e crea Dockerfile
app.yaml non viene utilizzato nei container, quindi eliminalo ora. Il file di configurazione del contenitore è Dockerfile e la nostra app di esempio ne richiede solo uno minimo. Crea il tuo Dockerfile con questo contenuto, sostituendo NNN con 2 o 3, a seconda della versione Python in uso:
FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]
La maggior parte delle 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 mai utilizzato Docker, l'istruzione FROM indica l'immagine di base da cui iniziare ed è "slim" si riferisce a una distribuzione minima di Python. Scopri di più nella pagina delle immagini Docker Python.
Il set centrale di comandi crea la directory di lavoro (/app), copia i file dell'applicazione, quindi esegue pip install per inserire le librerie di terze parti nel container. WORKDIR combina i comandi Linux mkdir e cd insieme; Scopri di più nella documentazione di WORKDIR . Le istruzioni 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 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
Gli sviluppatori App Engine in Python 2 sanno che le librerie di terze parti vengono copiate nella cartella lib, a cui viene fatto riferimento in requirements.txt, riportate in dettaglio in app.yaml e supportate da appengine_config.py. I container, come le app App Engine in Python 3, utilizzano solo requirements.txt, quindi tutto il resto può essere eliminato, il che significa che se hai un'app App Engine 2.x, elimina appengine_config.py e qualsiasi cartella lib adesso.
Avvio
Gli utenti di Python 2 non avviano il server web di App Engine, ma devi eseguire questa operazione quando passano a un container. Per farlo, devi aggiungere un'istruzione CMD o ENTRYPOINT in Dockerfile che specifichi come avviare l'app. Questa operazione viene descritta di seguito come per gli utenti di Python 3.
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 in Dockerfile (o Procfile se utilizzi Buildpacks [vedi il modulo 5] per containerizzare la tua app). Riassumere il punto in cui dovrebbe essere inserita una direttiva del punto di ingresso tra le due piattaforme:
- Docker: riga in
Dockerfile:ENTRYPOINT ["python", "main.py"] - Buildpacks: riga in
Procfile:web: python main.py
L'utilizzo del server di sviluppo Flask è consentito per i test, ma se utilizzi un server di produzione come gunicorn per la tua applicazione, assicurati di puntare l'istruzione ENTRYPOINT o CMD su di esso come nell'esempio della guida rapida di Cloud Run.
Ignora file
Ti consigliamo di creare un file .dockerignore per ridurne le dimensioni e non ingombrare l'immagine container con file superflui come i seguenti:
*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__
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
Una volta completati gli aggiornamenti della configurazione Docker e del file di origine, puoi iniziare a 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 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 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:
A questo punto il codice dovrebbe corrispondere al contenuto della cartella del repository del modulo 4, che sia 2.x o 3.x. Congratulazioni per aver completato il codelab del Modulo 4.
(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 Cloud Buildpacks nel codelab del modulo 5 (link di seguito) o svolgere un'altra migrazione ad App Engine:
- Se non l'hai ancora fatto, esegui la migrazione a Python 3. L'app di esempio è già compatibile con le versioni 2.x e 3.x, quindi l'unica modifica è che gli utenti Docker aggiornino il proprio
Dockerfilein modo che utilizzi un'immagine Python 3. - Modulo 5: Esegui la migrazione a Cloud Run con Cloud Buildpacks
- Containerizza la tua app per eseguirla su Cloud Run con Cloud Buildpacks
- Non devi sapere nulla su Docker, container o
Dockerfile - Richiede che tu abbia già eseguito la migrazione della tua app a Python 3
- Modulo 7: Code di attività push di App Engine (obbligatorie se utilizzi le code di attività [push])
- Aggiunge attività push di
taskqueuedi App Engine all'app del modulo 1 - Prepara gli utenti alla migrazione a Cloud Tasks nel modulo 8
- Aggiunge attività push di
- 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:
- Tracker dei problemi per i codelab di migrazione ad App Engine
Risorse di migrazione
I collegamenti alle cartelle repository per i moduli 2 e 3 (START) e 4 (FINISH) sono disponibili 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 |
(codice) | ||
(codice) | ||
Modulo 4 |
Risorse App Engine e Cloud Run
Di seguito sono riportate ulteriori risorse relative a questa specifica migrazione:
- Container
- Generale