Estensione del supporto per i servizi in bundle di App Engine: parte 1 (Modulo 17)

1. Panoramica

La serie di codelab Serverless Migration Station (tutorial pratici e self-service) e i video correlati mirano ad aiutare gli sviluppatori Google Cloud serverless a modernizzare le applicazioni guidandoli attraverso una o più migrazioni, principalmente abbandonando i servizi legacy. In questo modo le tue app saranno più portabili e avrai più opzioni e flessibilità, consentendoti di integrare e accedere a una gamma più ampia di prodotti Cloud e di eseguire più facilmente l'upgrade a release delle lingue più recenti. Pur concentrandosi inizialmente sui primi utenti di Cloud, principalmente sviluppatori di App Engine (ambiente standard), questa serie è sufficientemente ampia da includere altre piattaforme serverless come Cloud Functions e Cloud Run, o altrove, se applicabile.

In precedenza, gli sviluppatori dovevano eseguire la migrazione dai "servizi in bundle" legacy di App Engine come Datastore e Memcache prima che potessero eseguire l'upgrade delle versioni nelle lingue, due attività potenzialmente impegnative in sequenza. Rendendo disponibili molti dei servizi in bundle di chiavi nel servizio App Engine di seconda generazione, gli sviluppatori possono ora portare le loro app ai runtime più recenti continuando a utilizzare (la maggior parte dei) servizi in bundle. Questo codelab ti guida attraverso l'upgrade di un'app di esempio da Python 2 a 3 mantenendo l'utilizzo del servizio in bundle Datastore (tramite la libreria NDB di App Engine). L'utilizzo della maggior parte dei servizi in bundle richiede solo un piccolo aggiornamento del codice, come verrà illustrato in questo tutorial, ma ci sono altri che richiedono modifiche più estese. verranno trattati nella "Parte 2", un modulo di follow-up e un codelab.

Imparerai a utilizzare

  • Porta l'app App Engine di esempio da Python 2 a 3
  • Aggiorna la configurazione dell'app in modo da includere l'SDK di App Engine
  • Aggiungi il codice SDK all'app che supporta i servizi in bundle in runtime di seconda generazione come Python 3

Che cosa ti serve

Sondaggio

Come utilizzerai questo tutorial?

Solo lettura Leggilo e completa gli esercizi

Come valuteresti la tua esperienza con Python?

Principiante Livello intermedio Eccellente

Come giudichi la tua esperienza di utilizzo dei servizi Google Cloud?

Principiante Livello intermedio Eccellente

2. Sfondo

Il servizio originale App Engine lanciato nel 2008 includeva una serie di API legacy (ora note come servizi in bundle) per consentire agli sviluppatori di creare ed eseguire il deployment di applicazioni a livello globale in modo pratico. Questi servizi includono Datastore, Memcache e la coda di attività. Per quanto conveniente, gli utenti si preoccupavano della portabilità delle loro app quando utilizzano API proprietarie che le collegavano ad App Engine e volevano che le loro app fossero più portabili. Questo, insieme al fatto che molti di questi servizi in bundle che stanno maturando per diventare prodotti Cloud autonomi, hanno portato il team di App Engine a lanciare la piattaforma di nuova generazione nel 2018 senza questi servizi.

Andiamo avanti velocemente con gli sviluppatori Python 2 impazienti di eseguire l'upgrade a Python 3. Un'app 2.x che utilizzava servizi in bundle richiedeva la migrazione da questi servizi prima che le relative app potessero essere trasferite a 3.x, il che rappresenta una coppia di migrazioni forzate consecutive, anche potenzialmente complesse. Per facilitare questa transizione, il team di App Engine ha introdotto nell'autunno 2021 un "wormhole" al passato, consentendo alle app in esecuzione su runtime di nuova generazione di accedere a molti di questi servizi in bundle. Anche se questa release non include tutti i servizi disponibili nei runtime originali, sono disponibili i principali player, come Datastore, Task Queue e Memcache.

Questo codelab mostra le modifiche necessarie per eseguire l'upgrade dell'app a Python 3 senza compromettere l'uso dei servizi in bundle. L'obiettivo è far funzionare le tue app sugli ultimi runtime, in modo da poter eseguire la migrazione dai servizi in bundle agli equivalenti autonomi di Cloud o ad alternative di terze parti secondo le tue tempistiche, anziché dover bloccare un upgrade 3.x. Sebbene la migrazione dai servizi in bundle non sia più richiesta, ciò offre maggiore portabilità e flessibilità in termini di dove possono essere ospitate le tue app, incluso il passaggio a piattaforme che potrebbero soddisfare meglio i tuoi carichi di lavoro o semplicemente rimanere su App Engine durante l'upgrade a una release in un linguaggio più moderno, come appena descritto.

L'app di esempio Python 2 del Modulo 1 utilizza il servizio in bundle Datastore tramite App Engine NDB. L'app ha già eseguito la migrazione dei framework da webapp2 a Flask, completata nel codelab del Modulo 1, ma l'utilizzo di Datastore è rimasto invariato.

Questo tutorial illustra i seguenti passaggi:

  1. Configurazione/pre-lavoro
  2. Aggiorna configurazione
  3. Modifica il codice dell'applicazione

3. Configurazione/pre-lavoro

In questa sezione viene spiegato come:

  1. Configura il progetto Cloud
  2. Ottieni app di esempio di riferimento
  3. (Ri)Esegui il deployment e convalida l'app di riferimento

Questi passaggi assicurano di iniziare con un codice funzionante.

1. Configura il progetto

Se hai completato il codelab del Modulo 1, ti consigliamo di riutilizzare lo stesso progetto (e lo stesso codice). In alternativa, crea un nuovo progetto Cloud o riutilizza un altro progetto esistente. Assicurati che il progetto abbia un account di fatturazione attivo in cui è stato abilitato il servizio App Engine.

2. Ottieni app di esempio di riferimento

Uno dei prerequisiti di questo codelab è avere un'app App Engine del Modulo 1 funzionante: completa il codelab del Modulo 1 (consigliato) oppure copia l'app Modulo 1 dal repository. Che tu utilizzi il tuo o il nostro, il codice del Modulo 1 è il punto in cui "INIZIAMO". Questo codelab ti guiderà in ogni passaggio, concludendo con un codice simile a quello presente nella cartella del repository del modulo 7 "FINISH".

Indipendentemente dall'app del Modulo 1 che utilizzi, la cartella dovrebbe avere l'aspetto seguente, possibilmente con una cartella lib:

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

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

Esegui questi passaggi per (ri)eseguire il deployment dell'app del Modulo 1:

  1. Elimina la cartella lib, se presente, ed esegui: pip install -t lib -r requirements.txt per ricompilare lib. Potresti dover utilizzare il comando pip2 se hai installato sia Python 2 sia Python 3.
  2. Assicurati di aver installato e iniziato lo strumento a riga di comando gcloud e di averne controllato l'utilizzo.
  3. Imposta il tuo progetto Cloud su gcloud config set project PROJECT_ID se non vuoi inserire il valore PROJECT_ID con ogni comando gcloud emesso.
  4. Esegui il deployment dell'app di esempio con gcloud app deploy
  5. Verifica che l'app del Modulo 1 funzioni come previsto senza problemi nella visualizzazione delle visite più recenti (illustrate di seguito)

a7a9d2b80d706a2b.png

4. Aggiorna configurazione

Dopo aver eseguito correttamente questi passaggi e aver verificato che la tua app web funziona, puoi trasferire questa app a Python 3, iniziando con config.

Aggiungi l'SDK al file requirements.txt

Il runtime Python 3 di App Engine riduce notevolmente l'overhead associato all'utilizzo di librerie di terze parti. Tutto ciò che serve è elencarli in requirements.txt. Per utilizzare i servizi in bundle in Python 3, aggiungi il pacchetto dell'SDK di App Engine, appengine-python-standard. Il pacchetto SDK unisce Flask dal modulo 1:

flask
appengine-python-standard

Aggiorna app.yaml

Segui questi passaggi per applicare le modifiche alla configurazione al tuo file app.yaml:

  1. Sostituisci l'istruzione runtime con la release Python 3 supportata. ad esempio, specifica python310 per Python 3.10.
  2. Elimina entrambe le istruzioni threadsafe e api_version poiché nessuna delle due viene utilizzata in Python 3.
  3. Elimina completamente la sezione handlers poiché questa app ha solo gestori di script. Se la tua app ha gestori di file statici, lasciali invariati in handlers.
  4. Il runtime Python 3 non supporta le librerie di terze parti integrate come fa il runtime Python 2. Se la tua app ha una sezione libraries in app.yaml, elimina l'intera sezione. I pacchetti obbligatori devono essere elencati solo in requirements.txt come le librerie non integrate.) La nostra app di esempio non ha una sezione libraries, quindi vai al passaggio successivo.
  5. Crea un'istruzione app_engine_apis impostata su true per utilizzarla. Ciò corrisponde all'aggiunta del pacchetto SDK di App Engine a requirements.txt sopra.

Riepilogo delle modifiche necessarie da apportare a app.yaml:

PRIMA:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

DOPO:

runtime: python310
app_engine_apis: true

Altri file di configurazione

Poiché tutti i pacchetti di terze parti devono essere elencati solo in requirements.txt, a meno che tu non abbia qualcosa di speciale in appengine_config.py, questo non è necessario, quindi eliminalo. Allo stesso modo, poiché tutte le librerie di terze parti vengono installate automaticamente durante il processo di compilazione, non è necessario copiarle o fornirle, il che significa che non ci sono più comandi pip install né cartelle lib, quindi eliminali. Riassunto:

  • Elimina file appengine_config.py
  • Elimina cartella lib

Tutte le modifiche necessarie alla configurazione sono terminate.

5. Modifica il codice dell'applicazione

L'accesso alla maggior parte dei servizi in bundle disponibili nell'ambiente di runtime Python 3 richiede una breve porzione di codice che aggrega l'oggetto dell'applicazione Web Server Gateway Interface (WSGI) in main.py. La funzione wrapper è google.appengine.api.wrap_wsgi_app() e la utilizzi importandola e racchiudendo al suo interno il tuo oggetto WSGI. Apporta le modifiche riportate di seguito per riflettere l'aggiornamento richiesto per Flask in main.py:

PRIMA:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

DOPO:

from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)

Consulta la documentazione per esempi di wrapping di WSGI per altri framework Python.

Sebbene questo esempio funzioni per dare alla tua app l'accesso alla maggior parte dei servizi in bundle in Python 3, altri, come Blobstore e Mail, richiedono codice aggiuntivo. Tratteremo questi esempi in un altro modulo di migrazione.

Con questo si concluderanno tutte le modifiche necessarie per aggiungere l'utilizzo dei servizi in bundle di App Engine all'app di esempio del Modulo 1. L'applicazione è già compatibile con Python 2 e 3, quindi non ci sono ulteriori modifiche alla porta in Python 3 a parte ciò che hai già fatto nella configurazione. Il passaggio finale: esegui il deployment di questa app modificata nel runtime Python 3 di App Engine di nuova generazione e conferma che gli aggiornamenti sono stati eseguiti correttamente.

6. Riepilogo/Pulizia

In questa sezione si conclude questo codelab eseguendo il deployment dell'app e verificando che funzioni come previsto e in qualsiasi output riportato. Dopo la convalida dell'app, esegui la pulizia e valuta i passaggi successivi.

Esegui il deployment e verifica l'applicazione

Esegui il deployment dell'app Python 3 con gcloud app deploy e verifica che l'app funzioni come in Python 2. Nessuna delle funzionalità cambia, quindi l'output dovrebbe essere identico a quello dell'app Modulo 1:

a7a9d2b80d706a2b.png

Note finali

Congratulazioni per aver fatto il primo passo per la porta delle tue app App Engine in Python 2 in Python 3 mantenendo l'utilizzo dei servizi in bundle per il momento.

Esegui la pulizia

Generale

Se per il momento hai finito, ti consigliamo di disabilitare l'app App Engine per evitare di incorrere in fatturazione. Tuttavia, se desideri eseguire altri test o sperimentarli, la piattaforma App Engine ha una quota senza costi, pertanto, se non superi il livello di utilizzo, non ti verrà addebitato alcun costo. Questo riguarda il computing, ma potrebbero essere addebitati costi anche per i servizi App Engine pertinenti, quindi consulta la pagina dei prezzi per ulteriori informazioni. Se la migrazione coinvolge altri servizi Cloud, questi vengono fatturati separatamente. In entrambi i casi, se applicabile, consulta la sezione "Specifici di questo codelab" di seguito.

Per garantire la piena divulgazione, il deployment su una piattaforma di serverless computing di Google Cloud come App Engine comporta costi minori di build e archiviazione. Cloud Build e Cloud Storage hanno una quota senza costi specifica. Lo spazio di archiviazione dell'immagine esaurisce una parte della quota. Tuttavia, potresti risiedere in una regione che non ha un livello senza costi, quindi tieni presente l'utilizzo dello spazio di archiviazione per ridurre al minimo i costi potenziali. "cartelle" specifiche di Cloud Storage da esaminare includono:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • I link allo spazio di archiviazione riportati sopra dipendono dalla tua PROJECT_ID e dalla tua *LOC*azione, ad esempio "us" se la tua app è ospitata negli Stati Uniti.

Se invece non intendi continuare con questa applicazione o con altri codelab di migrazione correlati e vuoi eliminare tutto completamente, chiudi il progetto.

Specifico di questo codelab

I servizi elencati di seguito sono esclusivi per questo codelab. Per ulteriori informazioni, fai riferimento alla documentazione di ciascun prodotto:

Passaggi successivi

Ci sono diverse direzioni per andare da qui:

  1. Aggiorna il codice utilizzando servizi in bundle che richiedono più modifiche al codice
  2. Eseguire la migrazione dai servizi in bundle ai prodotti Cloud autonomi
  3. Esegui la migrazione da App Engine a un'altra piattaforma serverless Cloud

L'accesso ad altri servizi in bundle come Blobstore, Mail e Rinviato richiede ulteriori modifiche al codice. I moduli di migrazione da prendere in considerazione per l'eliminazione dei servizi in bundle legacy di App Engine includono:

  • Modulo 2: NDB di App Engine a Cloud NDB
  • Moduli 7-9: TaskQueue di App Engine (attività push) su Cloud Tasks
  • Moduli 12-13: Da App Engine a Cloud Memorystore
  • Moduli 15-16: dal Blobstore di App Engine a Cloud Storage
  • Moduli 18-19: TaskQueue di App Engine (attività pull) in Cloud Pub/Sub

App Engine non è più l'unica piattaforma serverless in Google Cloud. Se hai un'app App Engine di piccole dimensioni o con funzionalità limitate e vuoi convertirla in un microservizio autonomo oppure vuoi suddividere un'app monolitica in più componenti riutilizzabili, questi sono ottimi motivi per passare a Cloud Functions. Se la containerizzazione è diventata parte del flusso di lavoro per lo sviluppo delle applicazioni, in particolare se è costituita da una pipeline CI/CD (integrazione continua/distribuzione continua o deployment), valuta la possibilità di eseguire la migrazione a Cloud Run. Questi scenari sono trattati nei seguenti moduli:

  • Eseguire la migrazione da App Engine a Cloud Functions: consulta il Modulo 11
  • Esegui la migrazione da App Engine a Cloud Run: consulta il Modulo 4 per containerizzare la tua app con Docker oppure il Modulo 5 per eseguire questa operazione senza container, conoscenze di Docker o Dockerfile

Il passaggio a un'altra piattaforma serverless è facoltativo e prima di apportare modifiche ti consigliamo di valutare le opzioni migliori per le tue app e i tuoi casi d'uso.

Indipendentemente dal modulo di migrazione successivo, sarà possibile accedere a tutti i contenuti di Serverless Migration Station (codelab, video, codice sorgente [se disponibile]) nel relativo repository open source. L'elemento README del repository fornisce anche indicazioni sulle migrazioni da prendere in considerazione e su eventuali "ordine" pertinenti dei Moduli di migrazione.

7. Risorse aggiuntive

Di seguito sono elencate le risorse aggiuntive per gli sviluppatori che esplorano ulteriormente questo modulo di migrazione o i prodotti correlati, nonché i prodotti correlati. tra cui posizioni in cui fornire feedback su questi contenuti, link al codice e vari documenti che potrebbero esserti utili.

Problemi/feedback del codelab

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 link alle cartelle repository per il modulo 1 (START) e il modulo 1b (FINISH) sono disponibili nella tabella seguente. Sono inoltre accessibili dal repository per tutte le migrazioni del codelab di App Engine.

Codelab

Python 2

Python 3

Module 1

codice

N/A

Modulo 17 (questo codelab)

N/A

codice (mod1b-flask)

Risorse online

Di seguito sono riportate alcune risorse online che potrebbero essere pertinenti per questa esercitazione:

Servizi integrati di App Engine

Documentazione generale di App Engine

Altre informazioni sul cloud

Video

Licenza

Questo lavoro è concesso in licenza ai sensi di una licenza Creative Commons Attribution 2.0 Generic.