Esegui la migrazione di un NDB per Python 2 App Engine e App Cloud Tasks in Python 3 e Cloud Datastore (modulo 9)

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.

Lo scopo di questo codelab è eseguire il porting dell'app di esempio del modulo 8 a Python 3, nonché passare dall'utilizzo di Cloud NDB all'accesso a Datastore (Cloud Firestore in modalità Datastore) alla libreria client nativa Cloud Datastore ed eseguire l'upgrade all'ultima versione della libreria client Cloud Tasks.

Abbiamo aggiunto l'utilizzo di Task Queue per le attività push nel modulo 7, per poi eseguire la migrazione a Cloud Tasks nel modulo 8. Nel modulo 9, continuiamo con Python 3 e Cloud Datastore. Gli utenti che utilizzano le code di attività per le attività di pull eseguiranno la migrazione a Cloud Pub/Sub e dovranno fare riferimento ai moduli 18-19.

Imparerai a utilizzare

  • Porta l'app di esempio del modulo 8 a Python 3
  • Passare dall'accesso a Datastore dalle librerie client Cloud NDB a Cloud Datastore
  • Esegui l'upgrade all'ultima versione della libreria client di Cloud Tasks

Che cosa ti serve

Sondaggio

Come utilizzerai questo tutorial?

Solo lettura Lettura e completamento degli 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

Il modulo 7 mostra come utilizzare le attività push della coda di attività di App Engine nelle app App Engine Python 2 Flask. Nel modulo 8, esegui la migrazione dell'app da Task Queue a Cloud Tasks. Qui nel modulo 9, continui il tuo percorso e porti l'app su Python 3, oltre a passare dall'utilizzo di Cloud NDB all'accesso a Datastore tramite la libreria client Cloud Datastore nativa.

Poiché Cloud NDB funziona sia con Python 2 che con Python 3, è sufficiente per gli utenti di App Engine che eseguono il porting delle loro app da Python 2 a 3. Una migrazione aggiuntiva delle librerie client a Cloud Datastore è completamente facoltativa e c'è un solo motivo per prenderla in considerazione: hai app non App Engine (e/o app Python 3 App Engine) che utilizzano già la libreria client Cloud Datastore e vuoi consolidare la tua base di codice per accedere a Datastore con una sola libreria client. Cloud NDB è stato creato appositamente per gli sviluppatori di App Engine Python 2 come strumento di migrazione a Python 3, quindi se non hai già codice che utilizza la libreria client Cloud Datastore, non devi prendere in considerazione questa migrazione.

Infine, lo sviluppo della libreria client Cloud Tasks continua solo in Python 3, quindi stiamo eseguendo la "migrazione" da una delle versioni finali di Python 2 alla sua versione contemporanea di Python 3. Fortunatamente, non ci sono modifiche sostanziali rispetto a Python 2, il che significa che non devi fare altro.

Questo tutorial prevede i seguenti passaggi:

  1. Configurazione/preparazione
  2. Aggiorna configurazione
  3. Modificare il codice dell'applicazione

3. Configurazione/preparazione

Questa sezione spiega come:

  1. Configura il progetto cloud
  2. Ottieni l'app di esempio di base
  3. (R)esegui il deployment e convalida l'app di riferimento

Questi passaggi assicurano che tu stia iniziando con un codice funzionante e che sia pronto per la migrazione ai servizi cloud.

1. Configura il progetto

Se hai completato il codelab del modulo 8, riutilizza lo stesso progetto (e codice). In alternativa, crea un nuovo progetto o riutilizza un altro progetto esistente. Assicurati che il progetto abbia un account di fatturazione attivo e un'app App Engine abilitata. Trova l'ID progetto, in quanto ti servirà durante questo codelab. Utilizzalo ogni volta che incontri la variabile PROJECT_ID.

2. Ottieni l'app di esempio di base

Uno dei prerequisiti è un'app App Engine del modulo 8 funzionante: completa il codelab del modulo 8 (consigliato) o copia l'app del modulo 8 dal repository. Che tu utilizzi il tuo o il nostro, il codice del modulo 8 è il punto di partenza ("START"). Questo codelab ti guida nella migrazione e si conclude con un codice simile a quello presente nella cartella del repository del modulo 9 ("FINISH").

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

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

3. (R)esegui il deployment e convalida l'app di riferimento

Per eseguire il deployment dell'app del modulo 8:

  1. Elimina la cartella lib, se presente, ed esegui pip install -t lib -r requirements.txt per ripopolare lib. Potresti dover utilizzare pip2 se hai installato sia Python 2 che 3 sulla tua macchina di sviluppo.
  2. Assicurati di aver installato e inizializzato lo strumento a riga di comando gcloud e di averne esaminato l'utilizzo.
  3. (Facoltativo) Imposta il tuo progetto cloud con gcloud config set project PROJECT_ID se non vuoi inserire PROJECT_ID con ogni comando gcloud che emetti.
  4. Esegui il deployment dell'app di esempio con gcloud app deploy
  5. Verifica che l'app funzioni come previsto senza problemi. Se hai completato il codelab del modulo 8, l'app mostra i principali visitatori insieme alle visite più recenti (come illustrato di seguito). In basso è presente un'indicazione delle attività meno recenti che verranno eliminate.

4aa8a2cb5f527079.png

4. Aggiorna configurazione

requirements.txt

Il nuovo requirements.txt è quasi identico a quello del modulo 8, con una sola grande differenza: sostituisci google-cloud-ndb con google-cloud-datastore. Apporta questa modifica in modo che il file requirements.txt abbia il seguente aspetto:

flask
google-cloud-datastore
google-cloud-tasks

Questo file requirements.txt non include numeri di versione, il che significa che sono selezionate le versioni più recenti. In caso di incompatibilità, l'utilizzo dei numeri di versione per bloccare le versioni funzionanti di un'app è una pratica standard.

app.yaml

Il runtime App Engine di seconda generazione non supporta le librerie di terze parti integrate come nella versione 2.x né la copia di librerie non integrate. L'unico requisito per i pacchetti di terze parti è elencarli in requirements.txt. Di conseguenza, l'intera sezione libraries di app.yaml può essere eliminata.

Un altro aggiornamento è che il runtime Python 3 richiede l'utilizzo di framework web che eseguono il proprio routing. Di conseguenza, tutti i gestori di script devono essere modificati in auto. Tuttavia, poiché tutte le route devono essere modificate in auto e non vengono pubblicati file statici da questa app di esempio, non è rilevante avere gestori, quindi rimuovi anche l'intera sezione handlers.

L'unica cosa necessaria in app.yaml è impostare il runtime su una versione supportata di Python 3, ad esempio 3.10. Apporta questa modifica in modo che la nuova app.yaml abbreviata sia costituita da una sola riga:

runtime: python310

Elimina appengine_config.py e lib

I runtime App Engine di nuova generazione rinnovano l'utilizzo dei pacchetti di terze parti:

  • Le librerie integrate sono quelle verificate da Google e rese disponibili sui server App Engine, probabilmente perché contengono codice C/C++ che gli sviluppatori non sono autorizzati a eseguire il deployment nel cloud. Queste librerie non sono più disponibili nei runtime di seconda generazione.
  • La copia delle librerie non integrate (a volte chiamata "vendoring" o "self-bundling") non è più necessaria nei runtime di seconda generazione. Devono invece essere elencate in requirements.txt, dove il sistema di compilazione le installa automaticamente per tuo conto al momento del deployment.

A seguito di queste modifiche alla gestione dei pacchetti di terze parti, non sono necessari né il file appengine_config.py né la cartella lib, quindi eliminali. Nei runtime di seconda generazione, App Engine installa automaticamente i pacchetti di terze parti elencati in requirements.txt. Riepilogo in corso:

  1. Nessuna libreria di terze parti inclusa o copiata; elencale in requirements.txt
  2. Nessun pip install in una cartella lib, il che significa nessuna cartella lib
  3. Nessuna libreria di terze parti integrata nell'elenco (quindi nessuna sezione libraries) in app.yaml; elencale in requirements.txt
  4. Nessuna libreria di terze parti a cui fare riferimento dalla tua app significa nessun file appengine_config.py

L'unico requisito per gli sviluppatori è elencare tutte le librerie di terze parti desiderate in requirements.txt.

5. Aggiorna i file dell'applicazione

Esiste un solo file dell'applicazione, main.py, quindi tutte le modifiche in questa sezione interessano solo questo file. Di seguito è riportata un'illustrazione delle differenze relative alle modifiche complessive da apportare per eseguire il refactoring del codice esistente nella nuova app. Non è necessario leggere il codice riga per riga, in quanto il suo scopo è semplicemente quello di fornire una panoramica illustrativa di ciò che è richiesto in questo refactoring (ma se vuoi, puoi aprirlo in una nuova scheda o scaricarlo e ingrandirlo).

5d043768ba7be742.png

Aggiornare le importazioni e l'inizializzazione

La sezione di importazione in main.py per il modulo 8 utilizza Cloud NDB e Cloud Tasks e dovrebbe avere il seguente aspetto:

PRIMA:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

Il logging è semplificato e migliorato nei runtime di seconda generazione come Python 3:

  • Per un'esperienza di logging completa, utilizza Cloud Logging.
  • Per una registrazione semplice, invia un messaggio a stdout (o stderr) tramite print()
  • Non è necessario utilizzare il modulo Python logging (quindi rimuovilo)

Pertanto, elimina l'importazione di logging e scambia google.cloud.ndb con google.cloud.datastore. Allo stesso modo, modifica ds_client in modo che punti a un client Datastore anziché a un client NDB. Dopo queste modifiche, la parte superiore della nuova app ora appare così:

DOPO:

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

app = Flask(__name__)
ds_client = datastore.Client()
ts_client = tasks.CloudTasksClient()

Esegui la migrazione a Cloud Datastore

Ora è il momento di sostituire l'utilizzo della libreria client NDB con Datastore. Sia App Engine NDB che Cloud NDB richiedono un modello di dati (classe). Per questa app, è Visit. La funzione store_visit() funziona allo stesso modo in tutti gli altri moduli di migrazione: registra una visita creando un nuovo record Visit, salvando l'indirizzo IP e lo user agent (tipo di browser) di un client in visita.

PRIMA:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

Tuttavia, Cloud Datastore non utilizza una classe di modello di dati, quindi elimina la classe. Inoltre, Cloud Datastore non crea automaticamente un timestamp quando vengono creati i record, pertanto devi farlo manualmente con la chiamata datetime.now().

Senza la classe di dati, il store_visit() modificato dovrebbe essere simile al seguente:

DOPO:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

La funzione chiave è fetch_visits(). Non solo esegue la query originale per gli ultimi Visit, ma recupera anche il timestamp dell'ultimo Visit visualizzato e crea l'attività push che chiama /trim (quindi trim()) per eliminare in blocco i Visit precedenti. Ecco come viene utilizzato Cloud NDB:

PRIMA:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return (v.to_dict() for v in data), oldest_str

Le modifiche principali:

  1. Sostituisci la query Cloud NDB con l'equivalente Cloud Datastore. Gli stili di query differiscono leggermente.
  2. Datastore non richiede l'utilizzo di un gestore di contesto né l'estrazione dei dati (con to_dict()) come Cloud NDB.
  3. Sostituisci le chiamate di registrazione con print()

Dopo queste modifiche, fetch_visits() dovrebbe avere il seguente aspetto:

DOPO:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

In genere, questo è tutto ciò che è necessario. Purtroppo, c'è un problema principale.

(Facoltativo) Crea una nuova coda (push)

Nel modulo 7 abbiamo aggiunto l'utilizzo di App Engine taskqueue all'app del modulo 1 esistente. Uno dei principali vantaggi di avere attività push come funzionalità legacy di App Engine è che viene creata automaticamente una coda "predefinita". Quando l'app è stata migrata a Cloud Tasks nel modulo 8, la coda predefinita era già presente, quindi ancora non dovevamo preoccuparci. Questo cambia nel modulo 9.

Un aspetto fondamentale da considerare è che la nuova applicazione App Engine non utilizza più i servizi App Engine e, pertanto, non puoi più dare per scontato che App Engine crei automaticamente una coda di attività in un altro prodotto (Cloud Tasks). Come scritto, la creazione di un'attività in fetch_visits() (per una coda inesistente) non andrà a buon fine. È necessaria una nuova funzione per verificare se esiste la coda ("default") e, in caso contrario, crearne una.

Chiama questa funzione _create_queue_if() e aggiungila alla tua applicazione appena sopra fetch_visits(), perché è lì che viene chiamata. Il corpo della funzione da aggiungere:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

La funzione create_queue() di Cloud Tasks richiede il percorso completo della coda tranne il nome della coda. Per semplicità, crea un'altra variabile PATH_PREFIX che rappresenti QUEUE_PATH meno il nome della coda (QUEUE_PATH.rsplit('/', 2)[0]). Aggiungi la sua definizione nella parte superiore in modo che il blocco di codice con tutte le assegnazioni costanti sia simile a questo:

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

Ora modifica l'ultima riga in fetch_visits() per utilizzare _create_queue_if(), creando prima la coda, se necessario, e poi creando l'attività:

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Ora sia _create_queue_if() che fetch_visits() dovrebbero avere il seguente aspetto aggregato:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

A parte l'aggiunta di questo codice aggiuntivo, il resto del codice di Cloud Tasks è rimasto per lo più invariato rispetto al Modulo 8. L'ultimo pezzo di codice da esaminare è il gestore di attività.

Aggiorna (push) il gestore delle attività

Nel gestore delle attività, trim(), il codice Cloud NDB esegue query per le visite più vecchie di quelle visualizzate. Utilizza una query solo con le chiavi per velocizzare le operazioni. Perché recuperare tutti i dati se hai bisogno solo degli ID visita? Una volta ottenuti tutti gli ID visita, eliminali in batch con la funzione delete_multi() di Cloud NDB.

PRIMA:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Come fetch_visits(), la maggior parte delle modifiche riguarda la sostituzione del codice Cloud NDB con Cloud Datastore, la modifica degli stili di query, la rimozione dell'utilizzo del gestore di contesto e la modifica delle chiamate di logging in print().

DOPO:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    query = ds_client.query(kind='Visit')
    query.add_filter('timestamp', '<', datetime.fromtimestamp(oldest))
    query.keys_only()
    keys = list(visit.key for visit in query.fetch())
    nkeys = len(keys)
    if nkeys:
        print('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id) for k in keys)))
        ds_client.delete_multi(keys)
    else:
        print('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Non sono state apportate modifiche al gestore principale dell'applicazione root().

Porta a Python 3

Questa app di esempio è stata progettata per essere eseguita sia su Python 2 che su Python 3. Eventuali modifiche specifiche per Python 3 sono state trattate in precedenza nelle sezioni pertinenti di questo tutorial. Non sono necessari passaggi aggiuntivi né librerie di compatibilità.

Aggiornamento di Cloud Tasks

L'ultima versione della libreria client di Cloud Tasks che supporta Python 2 è la 1.5.0. Al momento della stesura di questo articolo, l'ultima versione della libreria client per Python 3 è completamente compatibile con questa versione, pertanto non sono necessari ulteriori aggiornamenti.

Aggiornamento del modello HTML

Non sono necessarie modifiche nemmeno nel file modello HTML, templates/index.html, quindi abbiamo completato tutte le modifiche necessarie per arrivare all'app del modulo 9.

6. Riepilogo/Pulizia

Esegui il deployment e verifica l'applicazione

Una volta completati gli aggiornamenti del codice, principalmente il porting a Python 3, esegui il deployment dell'app con gcloud app deploy. L'output deve essere identico alle app dei moduli 7 e 8, tranne per il fatto che hai spostato l'accesso al database nella libreria client Cloud Datastore e hai eseguito l'upgrade a Python 3:

Modulo 7: app visitme

Questo passaggio completa il codelab. Ti invitiamo a confrontare il tuo codice con quello contenuto nella cartella del modulo 9. Complimenti!

Esegui la pulizia

Generale

Se hai finito per il momento, ti consigliamo di disattivare l'app App Engine per evitare addebiti. Tuttavia, se vuoi fare altri test o esperimenti, la piattaforma App Engine ha una quota senza costi e, finché non superi questo livello di utilizzo, non ti verranno addebitati costi. Questo vale per il calcolo, ma potrebbero essere addebitati anche costi per i servizi App Engine pertinenti, quindi consulta la pagina dei prezzi per ulteriori informazioni. Se questa migrazione coinvolge altri servizi cloud, questi vengono fatturati separatamente. In entrambi i casi, se applicabile, consulta la sezione "Specifiche per questo codelab" di seguito.

Per una divulgazione completa, il deployment su una piattaforma di calcolo serverless di Google Cloud come App Engine comporta costi di build e archiviazione minimi. Cloud Build ha una propria quota senza costi, così come Cloud Storage. L'archiviazione di questa immagine utilizza parte della quota. Tuttavia, potresti vivere in una regione che non dispone di un livello senza costi, quindi tieni sotto controllo l'utilizzo dello spazio di archiviazione per ridurre al minimo i potenziali costi. Le "cartelle" Cloud Storage specifiche che devi 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 di archiviazione riportati sopra dipendono dalla tua PROJECT_ID e dalla tua *LOC*, ad esempio "us" se la tua app è ospitata negli Stati Uniti.

D'altra parte, se non intendi continuare con questa applicazione o con altri codelab di migrazione correlati e vuoi eliminare tutto completamente, chiudi il progetto.

Specifico per questo codelab

I servizi elencati di seguito sono univoci per questo codelab. Per saperne di più, consulta la documentazione di ogni prodotto:

Passaggi successivi

Con questo si conclude la migrazione dalle attività push di App Engine Task Queue a Cloud Tasks. La migrazione facoltativa da Cloud NDB a Cloud Datastore è trattata anche separatamente (senza Task Queue o Cloud Tasks) nel Modulo 3. Oltre al modulo 3, esistono altri moduli di migrazione incentrati sull'abbandono dei servizi in bundle legacy di App Engine da prendere in considerazione, tra cui:

  • Modulo 2: esegui la migrazione da App Engine NDB a Cloud NDB
  • Modulo 3: esegui la migrazione da Cloud NDB a Cloud Datastore
  • 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: coda di attività App Engine (attività pull) a Cloud Pub/Sub

App Engine non è più l'unica piattaforma serverless in Google Cloud. Se hai una piccola app App Engine o una con funzionalità limitate e vuoi trasformarla in un microservizio autonomo oppure vuoi suddividere un'app monolitica in più componenti riutilizzabili, questi sono buoni motivi per prendere in considerazione il passaggio a Cloud Functions. Se la containerizzazione è diventata parte del 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. Questi scenari sono trattati nei seguenti moduli:

  • Esegui 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 inserire la tua app in un container con Docker o il modulo 5 per farlo senza container, conoscenze di Docker o Dockerfiles

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.

7. Risorse aggiuntive

Problemi/feedback relativi a Codelab

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 2

Python 3

Modulo 8

code

(n/a)

Modulo 9

(n/a)

code

Risorse online

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

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Altre informazioni sul cloud

Licenza

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