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 (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.

Lo scopo di questo codelab è portare l'app di esempio del Modulo 8 su Python 3, nonché trasferire l'accesso a Datastore (Cloud Firestore in modalità Datastore) dall'utilizzo di Cloud NDB alla libreria client Cloud Datastore nativa ed eseguire l'upgrade alla versione più recente della libreria client Cloud Tasks.

Abbiamo aggiunto l'utilizzo della coda di attività per le attività push nel modulo 7, quindi abbiamo migrato questo utilizzo in Cloud Tasks nel modulo 8. Qui nel modulo 9, continuiamo con Python 3 e Cloud Datastore. Gli utenti che utilizzano le code di attività per le attività pull verranno migrati in Cloud Pub/Sub e dovranno fare riferimento ai moduli 18-19.

Imparerai a utilizzare

  • Porta l'app di esempio del Modulo 8 in Python 3
  • Cambia l'accesso a Datastore da Cloud NDB a librerie client di Cloud Datastore
  • Esegui l'upgrade alla versione più recente della libreria client di Cloud Tasks

Che cosa ti serve

Sondaggio

Come utilizzerai questo tutorial?

Da leggere solo 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 Modulo 7 mostra come utilizzare le attività di push della coda di attività di App Engine nelle app App Engine di Python 2 Flask. Nel modulo 8, eseguirai la migrazione dell'app dalla coda di attività a Cloud Tasks. Nel Modulo 9, proseguirai il percorso e porterai l'app a Python 3, oltre a trasferire l'accesso a Datastore dall'utilizzo di Cloud NDB alla libreria client nativa di Cloud Datastore.

Poiché Cloud NDB funziona sia per Python 2 che per 3, è sufficiente per gli utenti di App Engine che porteranno le loro app da Python 2 a 3. Un'ulteriore migrazione 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 di App Engine) che utilizzano già la libreria client di Cloud Datastore e vuoi consolidare il tuo codebase 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 Python 3. Di conseguenza, se non disponi già del codice che utilizza la libreria client di Cloud Datastore, non è necessario prendere in considerazione questa migrazione.

Infine, lo sviluppo della libreria client di Cloud Tasks continua solo in Python 3, quindi stiamo eseguendo la "migrazione" da una delle versioni finali di Python 2 al suo attuale Python 3. Fortunatamente, non ci sono modifiche che provocano un errore in Python 2, il che significa che non devi fare altro qui.

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 che tu stia iniziando con il 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 lo stesso 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 perché ti serve a portata di mano durante questo codelab, utilizzandolo ogni volta che incontri la variabile PROJECT_ID.

2. Ottieni app di esempio di riferimento

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. Indipendentemente dal fatto che tu utilizzi il tuo o il nostro, il codice del Modulo 8 è il punto in cui inizieremo ("START"). Questo codelab ti guiderà attraverso la migrazione, concludendo con un codice simile a quello presente nella cartella dei repository del modulo 9 ("FINISH").

Indipendentemente dall'app del Modulo 7 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 e convalida l'app di riferimento

Esegui questi passaggi 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 ricompilare lib. Potresti dover usare invece pip2 se hai installato sia Python 2 che 3 sulla macchina di sviluppo.
  2. Assicurati di aver installato e iniziato lo strumento a riga di comando gcloud e di averne controllato il utilizzo.
  3. (Facoltativo) Imposta il progetto Cloud su 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 venga eseguita come previsto senza problemi. Se hai completato il codelab del Modulo 8, l'app mostra i visitatori principali insieme alle visite più recenti (illustrate 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 uguale a quello del Modulo 8, con un solo grande cambiamento: sostituire 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 presenta numeri di versione, il che significa che sono selezionate le versioni più recenti. In caso di incompatibilità, l'uso dei numeri di versione per bloccare le versioni funzionanti di un'app è una prassi standard.

app.yaml

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

Un altro aggiornamento è che il runtime Python 3 richiede l'uso di framework web che eseguono il proprio routing. Di conseguenza, tutti i gestori di script devono essere impostati su auto. Tuttavia, poiché tutte le route devono essere modificate in auto e non vengono pubblicati file statici da questa app di esempio, non è irrilevante avere nessun gestore, 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 abbreviazione app.yaml sia solo questa:

runtime: python310

Elimina appengine_config.py e lib

I runtime App Engine di nuova generazione rinnovano l'utilizzo di 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++ di cui 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 "auto-bundling") non è più necessaria nei runtime di seconda generazione. Devono invece essere elencate in requirements.txt, dove il sistema di build 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. Riassunto:

  1. Nessuna libreria di terze parti copiata o in un unico bundle. elencali in requirements.txt
  2. Nessun pip install in una cartella lib, il che significa che nessun punto della cartella lib
  3. Nessun elenco delle librerie di terze parti integrate (quindi nessuna sezione libraries) in app.yaml; elencali in requirements.txt
  4. Se non esistono librerie di terze parti a cui fare riferimento dalla tua app, significa che nessun file appengine_config.py

Elencare tutte le librerie di terze parti desiderate in requirements.txt è l'unico requisito degli sviluppatori.

5. Aggiorna i file dell'applicazione

Esiste un solo file dell'applicazione, main.py, quindi tutte le modifiche in questa sezione interessano solo quel file. Di seguito è riportato un grafico "diffs" illustrazione delle modifiche generali da apportare per il refactoring del codice esistente nella nuova app. I lettori non sono tenuti a leggere il codice riga per riga, poiché il suo scopo è semplicemente quello di ottenere una panoramica visiva di ciò che è richiesto in questo refactoring (ma non esitare ad aprire in una nuova scheda o a scaricare e aumentare lo zoom, se lo desideri).

5d043768ba7be742.png

Aggiorna importazioni e inizializzazione

La sezione di importazione in main.py per il modulo 8 utilizza Cloud NDB e Cloud Tasks; 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 il logging semplice, invia a stdout (o stderr) tramite print()
  • Non è necessario utilizzare il modulo Python logging (quindi rimuovilo)

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. Con 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

A questo punto occorre sostituire l'utilizzo della libreria client NDB con Datastore. Sia App Engine che NDB di Cloud richiedono un modello dei dati (classe); per questa app, sono 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 visitato.

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 dei dati, quindi elimina la classe. Inoltre, Cloud Datastore non crea automaticamente un timestamp quando vengono creati i record, perciò è necessario farlo manualmente con la chiamata datetime.now().

Senza la classe di dati, l'elemento store_visit() modificato dovrebbe avere il seguente aspetto:

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 principale è fetch_visits(). Non solo esegue la query originale per gli ultimi Visit, ma acquisisce anche il timestamp dell'ultimo Visit visualizzato e crea l'attività push che chiama /trim (quindi trim()) per eliminare in blocco i vecchi Visit. In questo caso, 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. sostituire la query Cloud NDB con l'equivalente Cloud Datastore; gli stili delle query differiscono leggermente.
  2. Datastore non richiede l'utilizzo di un gestore di contesto né ti obbliga a estrarre i dati (con to_dict()) come fa Cloud NDB.
  3. Sostituisci le chiamate di logging con print()

Dopo queste modifiche, fetch_visits() avrà 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

Di solito questo è tutto ciò che è necessario. Purtroppo c'è un grave problema.

(Possibilmente) Crea una nuova coda (push)

Nel modulo 7, abbiamo aggiunto l'utilizzo di App Engine taskqueue all'app del modulo 1 esistente. Un vantaggio chiave dell'avere attività di push come funzionalità legacy di App Engine è che un viene creata automaticamente. Quando è stata eseguita la migrazione dell'app a Cloud Tasks nel modulo 8, la coda predefinita era già presente, quindi ancora non abbiamo dovuto 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 si può più presumere che App Engine crei automaticamente una coda di attività in un prodotto diverso (Cloud Tasks). Come scritto, la creazione di un'attività in fetch_visits() (per una coda che non esiste) non riuscirà. È necessaria una nuova funzione per verificare se esiste la coda ("predefinita") e, in caso contrario, crearne una.

Richiama questa funzione _create_queue_if() e aggiungila all'applicazione appena sopra fetch_visits() perché è qui 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 relativa definizione nella parte superiore, in modo che il blocco di codice con tutte le assegnazioni costanti abbia il seguente aspetto:

_, 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, poi poi creando l'attività successivamente:

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

Sia _create_queue_if() che fetch_visits() ora dovrebbero avere il seguente aspetto in forma aggregata:

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 il dover aggiungere questo ulteriore codice, il resto del codice di Cloud Tasks è per lo più intatto del modulo 8. L'ultima parte di codice da esaminare è il gestore delle attività.

Aggiorna gestore attività (push)

Nel gestore di attività trim(), il codice Cloud NDB esegue query per visite anteriori alla meno recente visualizzata. Utilizza una query basata solo su chiavi per velocizzare il processo, perché recuperare tutti i dati se sono necessari solo gli ID visita? Una volta ottenuti tutti gli ID visita, eliminali tutti in un 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 nel caso di fetch_visits(), la maggior parte delle modifiche comporta lo scambio del codice NDB di Cloud con Cloud Datastore, la modifica degli stili delle query, la rimozione dell'uso 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 di applicazioni principale root().

Porta in Python 3

Questa app di esempio è stata progettata per essere eseguita sia su Python 2 che su 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

La versione finale della libreria client di Cloud Tasks che supporta Python 2 è la 1.5.0. Al momento della stesura del presente documento, l'ultima versione della libreria client per Python 3 è completamente compatibile con quella versione, quindi non sono necessari ulteriori aggiornamenti.

Aggiornamento del modello HTML

Non sono necessarie modifiche al file del modello HTML, templates/index.html, quindi con questo messaggio vengono riassunte tutte le modifiche necessarie per arrivare all'app del Modulo 9.

6. Riepilogo/Pulizia

Esegui il deployment e verifica l'applicazione

Dopo aver completato gli aggiornamenti del codice, principalmente la porta su Python 3, esegui il deployment dell'app con gcloud app deploy. L'output dovrebbe essere identico alle app dei moduli 7 e 8, tranne per il fatto che hai spostato l'accesso al database nella libreria client di Cloud Datastore e hai eseguito l'upgrade a Python 3:

Modulo 7 - App Visitami

Questo passaggio completa il codelab. Ti invitiamo a confrontare il tuo codice con il contenuto della cartella del Modulo 9. Complimenti!

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

Questo conclude la nostra migrazione dalle attività push delle code di attività di App Engine a Cloud Tasks. Anche la migrazione facoltativa da Cloud NDB a Cloud Datastore (senza coda di attività o Cloud Tasks) viene trattata autonomamente nel Modulo 3. Oltre al Modulo 3, ci sono altri moduli di migrazione da considerare sull'abbandono dei servizi in bundle legacy di App Engine:

  • Modulo 2: migrazione da App Engine NDB a Cloud NDB
  • Modulo 3: migrazione da Cloud NDB a Cloud Datastore
  • Moduli 12-13: migrazione da App Engine Memcache a Cloud Memorystore
  • Moduli 15-16: migrazione dal Blobstore di App Engine a Cloud Storage
  • Moduli 18-19: coda di attività 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

Problemi/feedback dei 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 8 (START) e il modulo 9 (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

Modulo 8

codice

(n/d)

Modulo 9

(n/d)

codice

Risorse online

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

App Engine

NDB cloud

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.