Esegui la migrazione dalle attività di push della coda di attività di App Engine a Cloud Tasks (modulo 8)

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 è mostrare agli sviluppatori di app Python 2 App Engine come eseguire la migrazione dalla coda di attività App Engine (attività push) a Cloud Tasks. Esiste anche una migrazione implicita da App Engine NDB a Cloud NDB per l'accesso a Datastore (principalmente trattata nel modulo 2).

Abbiamo aggiunto l'utilizzo delle attività push nel modulo 7 e la migrazione di questo utilizzo a Cloud Tasks nel modulo 8, per poi continuare con Python 3 e Cloud Datastore nel modulo 9. 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

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

App Engine Task Queue supporta le attività push e pull. Per migliorare la portabilità delle applicazioni, il team di Google Cloud consiglia di eseguire la migrazione dai servizi integrati legacy come Task Queue ad altri servizi equivalenti autonomi o di terze parti di Cloud.

La migrazione delle attività di pull è trattata nei moduli 18-19, mentre i moduli 7-9 si concentrano sulla migrazione delle attività di push. Per eseguire la migrazione dalle attività push di App Engine Task Queue, abbiamo aggiunto il suo utilizzo all'app di esempio App Engine Python 2 esistente che registra le nuove visite di pagine e mostra le visite più recenti. Il codelab del modulo 7 aggiunge un'attività push per eliminare le visite meno recenti, che non verranno mai più mostrate, quindi perché dovrebbero occupare spazio di archiviazione aggiuntivo in Datastore? Questo codelab del modulo 8 mantiene la stessa funzionalità, ma esegue la migrazione del meccanismo di gestione delle code sottostante dalle attività push di Task Queues a Cloud Tasks, oltre a ripetere la migrazione del modulo 2 da App Engine NDB a Cloud NDB per l'accesso a Datastore.

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
  4. Abilitare nuovi servizi/API Google Cloud

Questi passaggi ti assicurano di iniziare con un codice funzionante e che l'app di esempio sia pronta per la migrazione ai servizi cloud.

1. Configura il progetto

Se hai completato il codelab del modulo 7, 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 7 funzionante: completa il codelab del modulo 7 (consigliato) o copia l'app del modulo 7 dal repository. Che tu utilizzi il tuo o il nostro, il codice del modulo 7 è 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 8 ("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 7:

  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 7, l'app mostra i visitatori principali insieme alle visite più recenti (come illustrato di seguito). In basso è presente un'indicazione delle attività meno recenti che verranno eliminate.

4aa8a2cb5f527079.png

4. Abilitare nuovi servizi/API Google Cloud

La vecchia app utilizzava i servizi in bundle di App Engine, che non richiedono configurazione aggiuntiva, ma i servizi cloud autonomi sì, e l'app aggiornata utilizzerà sia Cloud Tasks sia Cloud Datastore (tramite la libreria client Cloud NDB). Diversi prodotti cloud hanno quote di "livello senza costi", tra cui App Engine, Cloud Datastore e Cloud Tasks. Se rimani entro questi limiti, non dovresti incorrere in addebiti al termine di questo tutorial. Le API Cloud possono essere abilitate dalla console Cloud o dalla riga di comando, a seconda delle tue preferenze.

Dalla console Cloud

Vai alla pagina della libreria di API Manager (per il progetto corretto) in Cloud Console e cerca le API Cloud Datastore e Cloud Tasks utilizzando la barra di ricerca al centro della pagina:

c7a740304e9d35b.png

Fai clic sul pulsante Attiva per ogni API separatamente. Potrebbe esserti chiesto di fornire i dati di fatturazione. Questo è un esempio che mostra la pagina della libreria dell'API Cloud Pub/Sub (non abilitare l'API Pub/Sub per questo codelab, solo Cloud Tasks e Datastore):

1b6c0a2a73124f6b.jpeg

Dalla riga di comando

Sebbene l'abilitazione delle API dalla console sia visivamente informativa, alcuni preferiscono la riga di comando. Esegui il comando gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com per abilitare entrambe le API contemporaneamente:

$ gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Potrebbe esserti richiesto di inserire i dati di fatturazione. Se vuoi abilitare altre API Cloud e vuoi sapere quali sono i loro "URI", puoi trovarli in fondo alla pagina della libreria di ogni API. Ad esempio, osserva pubsub.googleapis.com come "Nome servizio" nella parte inferiore della pagina Pub/Sub appena sopra.

Una volta completati i passaggi, il tuo progetto potrà accedere alle API. Ora è il momento di aggiornare l'app per utilizzare queste API.

4. Aggiorna configurazione

Gli aggiornamenti alla configurazione sono dovuti esplicitamente all'utilizzo delle librerie client Cloud. Indipendentemente da quali utilizzi, le stesse modifiche devono essere apportate alle app che non utilizzano nessuna libreria client di Cloud.

requirements.txt

Il modulo 8 sostituisce l'utilizzo di App Engine NDB e della coda di attività del modulo 1 con Cloud NDB e Cloud Tasks. Aggiungi sia google-cloud-ndb che google-cloud-tasks a requirements.txt per partecipare a flask dal Modulo 7:

flask
google-cloud-ndb
google-cloud-tasks

Questo file requirements.txt non include numeri di versione, il che significa che sono selezionate le versioni più recenti. Se si verificano incompatibilità, specifica un numero di versione per bloccare le versioni funzionanti dell'app.

app.yaml

Quando utilizzi le librerie client Cloud, il runtime Python 2 di App Engine richiede pacchetti di terze parti specifici, ovvero grpcio e setuptools. Gli utenti di Python 2 devono elencare le librerie integrate come queste insieme a una versione disponibile o "latest" in app.yaml. Se non hai ancora una sezione libraries, creane una e aggiungi entrambe le librerie in questo modo:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

Quando esegui la migrazione della tua app, potrebbe avere già una sezione libraries. Se è così e mancano sia grpcio che setuptools, aggiungili alla sezione libraries esistente. L'app.yaml aggiornato ora dovrebbe avere il seguente aspetto:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

appengine_config.py

La chiamata google.appengine.ext.vendor.add() in appengine_config.py collega alla tua app le librerie di terze parti copiate (a volte chiamate "vendoring" o "self-bundling") in lib. In app.yaml abbiamo aggiunto librerie di terze parti integrate, che richiedono setuptools.pkg_resources.working_set.add_entry() per collegare la tua app a questi pacchetti integrati in lib. Di seguito sono riportati il Modulo 1 originale appengine_config.py e dopo aver apportato gli aggiornamenti del Modulo 8:

PRIMA:

from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)

DOPO:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

Una descrizione simile è disponibile anche nella documentazione sulla migrazione di App Engine.

5. Modificare il codice dell'applicazione

Questa sezione include aggiornamenti al file dell'applicazione principale, main.py, che sostituiscono l'utilizzo delle code push di App Engine Task Queue con Cloud Tasks. Non sono state apportate modifiche al modello web, templates/index.html: entrambe le app devono funzionare in modo identico, visualizzando gli stessi dati. Le modifiche all'applicazione principale sono suddivise in queste quattro attività:

  1. Aggiornare le importazioni e l'inizializzazione
  2. Aggiornamento della funzionalità del modello di dati (Cloud NDB)
  3. Eseguire la migrazione a Cloud Tasks (e Cloud NDB)
  4. Aggiorna (push) il gestore delle attività

1. Aggiornare le importazioni e l'inizializzazione

  1. Sostituisci App Engine NDB (google.appengine.ext.ndb) e Task Queue (google.appengine.api.taskqueue) con Cloud NDB (google.cloud.ndb) e Cloud Tasks (google.cloud.tasks), rispettivamente.
  2. Le librerie client di Cloud richiedono l'inizializzazione e la creazione di "client API"; assegnale rispettivamente a ds_client e ts_client.
  3. La documentazione di Task Queue afferma: "App Engine fornisce una coda push predefinita, denominata default, configurata e pronta per l'uso con le impostazioni predefinite". Cloud Tasks non fornisce una coda default (perché è un prodotto Cloud autonomo indipendente da App Engine), quindi è necessario un nuovo codice per creare una coda Cloud Tasks denominata default.
  4. App Engine Task Queue non richiede di specificare una regione perché utilizza la regione in cui viene eseguita l'app. Tuttavia, poiché Cloud Tasks è ora un prodotto indipendente, richiede una regione e questa regione deve corrispondere a quella in cui viene eseguita l'app. Il nome della regione e l'ID progetto Cloud sono necessari per creare un"pathname completo" come identificatore univoco della coda.

Gli aggiornamenti descritti nel terzo e nel quarto punto elenco sopra costituiscono la maggior parte delle costanti e dell'inizializzazione aggiuntive richieste. Visualizza le sezioni "Prima" e "Dopo" riportate di seguito e apporta queste modifiche nella parte superiore di main.py.

PRIMA:

from datetime import datetime
import logging
import time
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb

app = Flask(__name__)

DOPO:

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

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

_, 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)

2. Aggiornamento della funzionalità del modello di dati (Cloud NDB)

App Engine NDB e Cloud NDB funzionano in modo quasi identico. Non sono state apportate modifiche significative al modello di dati né alla funzione store_visit(). L'unica differenza notevole è che la creazione dell'entità Visit in store_visit() è ora incapsulata all'interno di un blocco with di Python. Cloud NDB richiede che tutto l'accesso a Datastore sia controllato all'interno del suo gestore di contesto, da cui deriva l'istruzione with. Gli snippet di codice riportati di seguito illustrano questa piccola differenza durante la migrazione a Cloud NDB. Implementa questa modifica.

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'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

DOPO:

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

3. Eseguire la migrazione a Cloud Tasks (e Cloud NDB)

La modifica più critica di questa migrazione riguarda l'infrastruttura di gestione delle code sottostante. Ciò avviene nella funzione fetch_visits(), in cui viene creato e messo in coda per l'esecuzione un'attività (push) per eliminare le visite precedenti. Tuttavia, la funzionalità originale del modulo 7 rimane intatta:

  1. Esegui una query per le visite più recenti.
  2. Anziché restituire immediatamente queste visite, salva il timestamp dell'ultima Visit, la più vecchia visualizzata. È sicuro eliminare tutte le visite precedenti a questa data.
  3. Estrai il timestamp come numero in virgola mobile e come stringa utilizzando le utilità Python standard e utilizzali entrambi in varie capacità, ad esempio per la visualizzazione per l'utente, l'aggiunta ai log, il passaggio al gestore e così via.
  4. Crea un'attività push con questo timestamp come payload insieme a /trim come URL.
  5. Il gestore delle attività viene infine chiamato tramite un POST HTTP a quell'URL.

Questo flusso di lavoro è illustrato dallo snippet di codice "prima":

PRIMA:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    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)
    taskqueue.add(url='/trim', params={'oldest': oldest})
    return data, oldest_str

Anche se la funzionalità rimane invariata, Cloud Tasks diventa la piattaforma di esecuzione. Gli aggiornamenti per implementare questa modifica includono:

  1. Inserisci la query Visit all'interno di un blocco with Python (ripetendo la migrazione del modulo 2 a Cloud NDB)
  2. Crea metadati Cloud Tasks, inclusi gli attributi previsti come payload e URL del timestamp, ma aggiungi anche il tipo MIME e codifica il payload in formato JSON.
  3. Utilizza il client API Cloud Tasks per creare l'attività con i metadati e il percorso completo della coda.

Queste modifiche a fetch_visits() sono illustrate di seguito:

DOPO:

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 data, oldest_str

4. Aggiornamento (push) del gestore delle attività

La funzione di gestione delle attività (push) non richiede aggiornamenti importanti, ma solo l'esecuzione. Ciò vale per Task Queue o Cloud Tasks. "Il codice è il codice", dicono. Tuttavia, sono state apportate alcune piccole modifiche:

  1. Il payload del timestamp è stato passato letteralmente a Task Queue, ma è stato codificato in formato JSON per Cloud Tasks e pertanto deve essere analizzato in formato JSON all'arrivo.
  2. La chiamata HTTP POST a /trim con Task Queue aveva un tipo MIME implicito di application/x-www-form-urlencoded, ma con Cloud Tasks è designato esplicitamente come application/json, quindi esiste un modo leggermente diverso per estrarre il payload.
  3. Utilizza il gestore di contesto client dell'API Cloud NDB (migrazione del modulo 2 a Cloud NDB).

Di seguito sono riportati gli snippet di codice prima e dopo aver apportato queste modifiche al gestore delle attività, trim():

PRIMA:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = request.form.get('oldest', type=float)
    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

DOPO:

@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

Non sono presenti aggiornamenti al gestore dell'applicazione principale root() né al modello web templates/index.html.

6. Riepilogo/Pulizia

Questa sezione conclude il codelab eseguendo il deployment dell'app, verificando che funzioni come previsto e in qualsiasi output riflesso. 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 con gcloud app deploy. L'output deve essere identico all'app del modulo 7, ma ti accorgerai di essere passato a un prodotto di coda push completamente diverso, il che rende la tua app più portatile di prima.

4aa8a2cb5f527079.png

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. Se ti interessa continuare a eseguire il porting di questa app a Python 3 e la migrazione a Cloud Datastore da Cloud NDB, prendi in considerazione il modulo 9.

Cloud NDB esiste specificamente per gli sviluppatori di App Engine Python 2, fornendo un'esperienza utente quasi identica, ma Cloud Datastore ha una propria libreria client nativa creata per gli utenti non App Engine o per i nuovi utenti di App Engine (Python 3). Tuttavia, poiché Cloud NDB è disponibile per Python 2 e 3, non è necessario eseguire la migrazione a Cloud Datastore.

Cloud NDB e Cloud Datastore accedono entrambi a Datastore (anche se in modi diversi), quindi l'unico motivo per prendere in considerazione il passaggio a Cloud Datastore è se hai già altre app, in particolare app non App Engine, che utilizzano Cloud Datastore e vuoi standardizzare una singola libreria client Datastore. Questa migrazione facoltativa da Cloud NDB a Cloud Datastore è trattata anche separatamente (senza Task Queue o Cloud Tasks) nel modulo 3.

Oltre ai moduli 3, 8 e 9, altri moduli di migrazione da prendere in considerazione per abbandonare i servizi in bundle legacy di App Engine includono:

  • Modulo 2: esegui la migrazione da App Engine NDB a Cloud NDB
  • 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

Di seguito sono elencate risorse aggiuntive per gli sviluppatori che vogliono esplorare ulteriormente questo modulo di migrazione o quelli correlati, nonché i prodotti correlati. Sono inclusi i luoghi in cui fornire feedback su questi contenuti, i link al codice e vari documenti che potresti trovare utili.

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 7 (INIZIO) e il modulo 8 (FINE) sono riportati nella tabella seguente.

Codelab

Python 2

Python 3

Modulo 7

code

Codice (non incluso in questo tutorial)

Modulo 8 (questo codelab)

code

(n/a)

Risorse online

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

Coda delle attività di App Engine e Cloud Tasks

App Engine NDB e Cloud NDB (Datastore)

Piattaforma App Engine

Altre informazioni sul cloud

Video

Licenza

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