Modulo 11: Migrazione da Google App Engine a Cloud Functions

1. Panoramica

La serie di codelab Serverless Migration Station (esercitazioni pratiche e autonome) e i video correlati hanno lo scopo di aiutare gli sviluppatori serverless di Google Cloud a modernizzare le loro applicazioni guidandoli attraverso una o più migrazioni, principalmente abbandonando i servizi legacy. In questo modo, le tue app sono più portatili e hai più opzioni e flessibilità, il che ti consente di integrarti e accedere a una gamma più ampia di prodotti cloud e di eseguire più facilmente l'upgrade alle versioni più recenti del linguaggio. Sebbene inizialmente si concentri sui primi utenti di Cloud, principalmente gli sviluppatori di App Engine (ambiente standard), questa serie è abbastanza ampia da includere altre piattaforme serverless come Cloud Functions e Cloud Run o altrove, se applicabile.

Esistono situazioni in cui non hai un'"intera app" che richieda le risorse di App Engine o Cloud Run. Se il tuo codice è costituito solo da un microservizio o da una semplice funzione, Cloud Functions è probabilmente la soluzione migliore. Questo codelab ti insegna a eseguire la migrazione di semplici app App Engine (o a suddividere app più grandi in più microservizi) e a eseguirne il deployment in Cloud Functions, un'altra piattaforma serverless creata appositamente per casi d'uso come questo.

Imparerai a utilizzare

  • Utilizzo di Cloud Shell
  • Abilita l'API Google Cloud Translation
  • Autenticare le richieste API
  • Convertire una piccola app App Engine per l'esecuzione su Cloud Functions
  • Esegui il deployment del codice in Cloud Functions

Che cosa ti serve

Sondaggio

Come utilizzerai questo tutorial?

Leggilo e basta Leggilo e completa gli esercizi

Come valuteresti la tua esperienza con Python?

Principiante Intermedio Avanzato

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

Principiante Intermedio Avanzato

2. Sfondo

I sistemi PaaS come Google App Engine e Cloud Functions offrono molti vantaggi agli utenti. Queste piattaforme serverless consentono al tuo team tecnico di concentrarsi sulla creazione di soluzioni aziendali anziché dedicare tempo a esaminare le piattaforme da utilizzare e determinare la quantità di hardware necessaria. Le applicazioni possono scalare automaticamente in base alle esigenze, ridursi a zero con la fatturazione pay-per-use per controllare i costi e supportano una serie di linguaggi di sviluppo comuni oggi.

Tuttavia, mentre lo sviluppo di applicazioni web full-stack o di backend complessi per app mobile è ideale per App Engine, spesso gli sviluppatori cercano principalmente di mettere online alcune funzionalità, ad esempio l'aggiornamento di un feed di notizie o il recupero dell'ultimo risultato della partita di playoff della squadra di casa. Sebbene esista una logica di codifica per entrambi gli scenari, nessuno dei due sembra essere un'"applicazione" completa che richieda la potenza di App Engine. È qui che entra in gioco Cloud Functions.

Cloud Functions serve per il deployment del piccolo frammento di codice che:

  • Non fa parte di un'intera applicazione
  • Non è necessario in un intero stack di sviluppo
  • Si trova in un'applicazione o in un backend di app mobile singolo che si concentra su un'unica cosa

Puoi anche utilizzare Cloud Functions per suddividere un'applicazione monolitica di grandi dimensioni in più microservizi, ognuno dei quali utilizza un database comune condiviso come Cloud Firestore o Cloud SQL. Se vuoi che la tua funzione o il tuo microservizio venga containerizzato ed eseguito in modalità serverless su Cloud Run, puoi farlo.

La nostra app di esempio App Engine, presente in quasi tutti i tutorial sulla migrazione, è una breve app con funzionalità di base che funziona altrettanto bene in Cloud Functions. In questo tutorial imparerai a modificare l'app per eseguirla su Cloud Functions. Dal punto di vista di App Engine, poiché le funzioni sono più semplici delle app complete, l'esperienza iniziale dovrebbe essere più facile (e veloce) e con meno "overhead" in generale. Questa migrazione prevede i seguenti passaggi:

  • Configurazione/preparazione
  • Rimuovere i file di configurazione
  • Modificare i file dell'applicazione

3. Configurazione/preparazione

Questo codelab inizia con la versione Python 3 dell'app di esempio di App Engine Cloud NDB del modulo 2 perché Cloud Functions non supporta Python 2. Innanzitutto, configuriamo il progetto, recuperiamo il codice e poi implementiamo l'app di base per verificare che stiamo iniziando con un codice funzionante.

1. Configura il progetto

Se hai completato il codelab del modulo 2 (e l'hai trasferito a Python 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 con il servizio App Engine abilitato.

2. Ottieni l'app di esempio di base

Uno dei prerequisiti di questo codelab è avere un'app di esempio del Modulo 2 funzionante. Se non ne hai una, completa uno dei tutorial collegati sopra prima di procedere. Altrimenti, se hai già familiarità con i contenuti, puoi iniziare prendendo il codice del modulo 2 di seguito.

Che tu utilizzi il tuo o il nostro, il codice Python 3 del modulo 2 è il punto di partenza. Questo codelab del modulo 11 ti guida in ogni passaggio e si conclude con un codice simile a quello presente nella cartella del repository del modulo 11 (FINISH).

La directory dei file di avvio del Modulo 2 di Python 3 (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 convertirlo in una funzione Cloud.

4. Rimuovere i file di configurazione

Il file app.yaml è un artefatto App Engine non utilizzato con Cloud Functions, quindi eliminalo ora. Se non lo fai o te ne dimentichi, non ci sono problemi perché Cloud Functions non lo utilizza. Si tratta dell'unica modifica alla configurazione, in quanto requirements.txt rimane identico a quello del modulo 2.

Se stai anche trasferendo un'app Python 2 App Engine a Python 3, elimina appengine_config.py e la cartella lib, se presente. Sono artefatti di App Engine inutilizzati nel runtime Python 3.

5. Modificare i file dell'applicazione

Esiste un solo file dell'applicazione, main.py, quindi tutte le modifiche necessarie per passare a Cloud Functions vengono apportate in questo file.

Importazioni

Poiché lavoriamo solo con le funzioni, non è necessario un framework di applicazioni web. Tuttavia, per comodità, quando vengono chiamate le funzioni Cloud Functions basate su Python, viene passato automaticamente un oggetto richiesta che il codice può utilizzare in base alle esigenze. Il team di Cloud Functions lo ha selezionato come oggetto Flask Request passato alla tua funzione.

Poiché i framework web non fanno parte del panorama di Cloud Functions, non sono presenti importazioni da Flask a meno che la tua app non utilizzi altre funzionalità di Flask. Questo è il nostro caso, in quanto il rendering dei modelli avviene ancora dopo la conversione in una funzione, il che significa che è ancora necessario chiamare flask.render_template(), quindi la sua importazione da Flask. Nessun framework web significa che non è necessario creare un'istanza di un'app Flask, quindi elimina app = Flask(__name__). Prima e dopo l'applicazione delle modifiche, il codice ha il seguente aspetto:

PRIMA:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

DOPO:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Se dipendi dall'oggetto app (app) o da qualsiasi altra infrastruttura di framework web, devi risolvere tutte queste dipendenze, trovare soluzioni alternative appropriate o rimuovere completamente il loro utilizzo o trovare proxy. Solo allora potrai convertire il codice in una funzione Cloud Functions. In caso contrario, ti conviene rimanere su App Engine o inserire la tua app in un container per Cloud Run.

Aggiorna la firma della funzione di gestione principale

Le modifiche richieste nella firma della funzione sono le seguenti:

  1. Flask non viene più utilizzato dopo la conversione dell'app in una funzione Cloud, quindi rimuovi i decoratori di route.
  2. Cloud Functions passa automaticamente l'oggetto Flask Request come parametro, quindi crea una variabile per questo. Nella nostra app di esempio, lo chiameremo request.
  3. Le funzioni Cloud Functions di cui è stato eseguito il deployment devono avere un nome. Il nostro gestore principale è stato chiamato in modo appropriato root() in App Engine per descrivere la sua funzione (il gestore dell'applicazione principale). In quanto funzione Cloud, ha meno senso utilizzare questo nome. Eseguiamo invece il deployment della Funzione Cloud con il nome visitme, quindi utilizzalo anche come nome della funzione Python. Allo stesso modo, nei moduli 4 e 5 abbiamo chiamato il servizio Cloud Run visitme.

Ecco il prima e il dopo con questi aggiornamenti:

PRIMA:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

DOPO:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Con questo si concludono tutti gli aggiornamenti necessari. Tieni presente che le modifiche apportate hanno interessato solo il codice "infrastrutturale " dell'applicazione. Non sono necessarie modifiche al codice dell'applicazione principale e nessuna funzionalità dell'app è stata alterata. Ecco una rappresentazione illustrata delle modifiche apportate per illustrare questo punto:

668f30e3865b27a9.png

Sviluppo e test locali

Mentre App Engine ha il dev_appserver.py server di sviluppo locale, Cloud Functions ha il suo framework di Functions. Con questo framework, puoi sviluppare ed eseguire test localmente. Il codice può essere sottoposto a deployment su Cloud Functions, ma anche su altre piattaforme di calcolo come Compute Engine, Cloud Run o anche su sistemi on-premise o cloud ibridi che supportano Knative. Di seguito sono riportati altri link al framework di Functions.

6. Creazione e deployment

Il deployment in Cloud Functions è leggermente diverso da App Engine. Poiché non vengono utilizzati file di configurazione al di fuori di requirements.txt, è necessario specificare ulteriori informazioni sul codice nella riga di comando. Esegui il deployment della nuova funzione Cloud Functions attivata da HTTP in esecuzione con Python 3.10 con questo comando:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

L'output dovrebbe essere simile al seguente:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Dopo il deployment della funzione, utilizza l'URL dell'output del deployment e visita la tua app. L'URL ha il formato REGION-PROJECT_ID.cloudfunctions.net/visitme. L'output dovrebbe essere identico a quello ottenuto quando hai eseguito il deployment in precedenza su App Engine:

2732ae9218f011a2.png

Come per la maggior parte degli altri codelab e video della serie, la funzionalità di base dell'app non cambia. Lo scopo è applicare una tecnica di modernizzazione e far funzionare l'app esattamente come prima, ma con un'infrastruttura più recente, ad esempio eseguendo la migrazione da un servizio legacy di App Engine precedente al prodotto autonomo Cloud sostitutivo oppure, come in questo tutorial, spostando un'app su un'altra piattaforma serverless di Google Cloud.

7. Riepilogo/Pulizia

Congratulazioni per aver convertito questa piccola app App Engine in una Cloud Function. Un altro caso d'uso appropriato è la suddivisione di una grande app monolitica App Engine in una serie di microservizi, ognuno come Cloud Function. Si tratta di una tecnica di sviluppo più moderna che produce un componente più "plug-and-play" (in stile " JAM stack"). Consente di combinare e abbinare e riutilizzare il codice, che sono due obiettivi, ma un altro vantaggio è che il debug di questi microservizi continuerà nel tempo, il che significa codice stabile e costi di manutenzione complessivi inferiori.

Esegui la pulizia

Dopo aver completato questo codelab, puoi disattivare l'app App Engine del modulo 2 (temporaneamente o definitivamente) per evitare addebiti. La piattaforma App Engine ha una quota senza costi, quindi non ti verrà addebitato alcun costo finché rimani all'interno del suo livello di utilizzo. Lo stesso vale per Datastore. Per maggiori dettagli, consulta la pagina dei prezzi di Cloud Datastore.

Il deployment su piattaforme come App Engine e Cloud Functions comporta costi di build e archiviazione minimi. In alcune regioni, Cloud Build ha una propria quota senza costi, così come Cloud Storage. Le build consumano parte di questa quota. Tieni sotto controllo l'utilizzo dello spazio di archiviazione per ridurre al minimo i costi potenziali, soprattutto se la tua regione non dispone di un livello senza costi.

Purtroppo Cloud Functions non dispone di una funzionalità "Disattiva". Esegui il backup del codice ed elimina la funzione. Puoi sempre eseguirne nuovamente il deployment con lo stesso nome in un secondo momento. Tuttavia, se non intendi continuare con altri codelab di migrazione e vuoi eliminare tutto completamente, chiudi i tuoi progetti Cloud.

Passaggi successivi

Oltre a questo tutorial, altri moduli di migrazione da esaminare includono la containerizzazione dell'app App Engine per Cloud Run. Consulta i link ai codelab del Modulo 4 e del Modulo 5:

  • Modulo 4: esegui la migrazione a Cloud Run con Docker
  • Containerizzare l'app per eseguirla su Cloud Run con Docker
  • Questa migrazione ti consente di continuare a utilizzare Python 2.
  • 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 Dockerfile.
  • Richiede che l'app sia già stata migrata a Python 3 (Buildpacks non supporta Python 2)

Molti degli altri moduli si concentrano su come mostrare agli sviluppatori come eseguire la migrazione dai servizi in bundle di App Engine alle sostituzioni autonome di Cloud:

  • Modulo 2: esegui la migrazione da App Engine ndb a Cloud NDB
  • Moduli 7-9: esegui la migrazione delle attività push di App Engine Task Queue a Cloud Tasks
  • Moduli 12-13: esegui la migrazione da Memcache App Engine a Cloud Memorystore
  • Moduli 15-16: esegui la migrazione da App Engine Blobstore a Cloud Storage
  • Moduli 18-19: esegui la migrazione dalla coda di attività App Engine (attività pull) a Cloud Pub/Sub

Se la containerizzazione è diventata parte del tuo flusso di lavoro di sviluppo delle applicazioni, in particolare se consiste in una pipeline CI/CD (integrazione continua/distribuzione continua o deployment continuo), valuta la migrazione a Cloud Run anziché a Cloud Functions. Consulta il modulo 4 per containerizzare la tua app con Docker o il modulo 5 per farlo senza container, conoscenze di Docker o Dockerfile. Che tu stia prendendo in considerazione Cloud Functions o Cloud Run, il passaggio a un'altra piattaforma serverless è facoltativo e ti consigliamo di valutare le opzioni migliori per le tue app e i tuoi casi d'uso prima di apportare modifiche.

Indipendentemente dal modulo di migrazione che prenderai in considerazione, tutti i contenuti di Serverless Migration Station (codelab, video, codice sorgente [se disponibile]) sono accessibili nel relativo repository open source. Il repository README fornisce anche indicazioni sulle migrazioni da prendere in considerazione e sull'eventuale "ordine" dei moduli di migrazione pertinenti.

8. 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 il modulo 8 (INIZIO) e il modulo 9 (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 3

Modulo 2

code

Modulo 11

code

Risorse online

Di seguito sono riportate risorse online che potrebbero essere pertinenti per questo tutorial:

App Engine

Cloud Functions

Altre informazioni sul cloud

Video

Licenza

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