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 (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 è mostrare agli sviluppatori di App Engine Python 2 come eseguire la migrazione dalla coda di attività di App Engine (attività push) a Cloud Tasks. È prevista anche una migrazione implicita dall'NDB di App Engine a Cloud NDB per l'accesso al datastore (trattata principalmente nel Modulo 2).

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

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

La coda di attività di App Engine supporta sia le attività push che pull. Per migliorare la portabilità delle applicazioni, il team di Google Cloud consiglia di eseguire la migrazione da servizi in bundle legacy, come Task Queue, di altri servizi Cloud autonomi o equivalenti di terze parti.

La migrazione delle attività pull è trattata nei moduli 18-19, mentre i moduli 7-9 sono incentrati sulla migrazione delle attività push. Per eseguire la migrazione dalle attività push della coda di attività di App Engine, ne abbiamo aggiunto l'utilizzo all'app di esempio esistente di App Engine per Python 2, che registra le nuove visite alle pagine e mostra le visite più recenti. Il codelab del Modulo 7 aggiunge un'attività di push per eliminare le visite meno recenti: non verranno mai più mostrate. Perché dovrebbe occupare spazio di archiviazione aggiuntivo in Datastore? Questo codelab del modulo 8 conserva la stessa funzionalità, ma esegue la migrazione del meccanismo di accodamento sottostante dalle attività push della coda di attività a Cloud Tasks, oltre a ripetere la migrazione del Modulo 2 dall'NDB di App Engine a Cloud NDB per l'accesso a Datastore.

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

Questi passaggi assicurano di iniziare con il codice funzionante e che la tua 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 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 7 funzionante: completa il codelab del Modulo 7 (consigliato) o copia l'app del modulo 7 dal repository. Indipendentemente dal fatto che tu utilizzi il tuo o il nostro, il codice del Modulo 7 è 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 8 ("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 7:

  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 7, 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. Abilita nuovi servizi/API Google Cloud

L'app precedente utilizzava servizi in bundle con App Engine che non richiedono una configurazione aggiuntiva, a differenza dei servizi Cloud autonomi. L'app aggiornata impiegherà sia Cloud Tasks sia Cloud Datastore (tramite la libreria client Cloud NDB). Alcuni prodotti Cloud dispongono di un'opzione " Always Free" , tra cui App Engine, Cloud Datastore e Cloud Tasks. Se rimani entro questi limiti, non ti verrà addebitato alcun costo per completare il tutorial. Le API Cloud possono essere abilitate dalla console Cloud o dalla riga di comando, a seconda delle preferenze.

Dalla console Cloud

Vai alla pagina Libreria del gestore API (del progetto corretto) nella console Cloud e cerca le API Cloud Datastore e Cloud Tasks utilizzando la barra di ricerca al centro della pagina:

c7a740304e9d35b.png

Fai clic sul pulsante Abilita per ciascuna API separatamente. Ti potrebbero essere richiesti i dati di fatturazione. Questo è un esempio con la pagina della libreria API Cloud Pub/Sub (non abilitare l'API Pub/Sub per questo codelab, ma solo per 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.

Ti potrebbero essere richiesti i dati di fatturazione. Se desideri abilitare altre API Cloud e vuoi sapere i relativi "URI" puoi trovarli nella parte inferiore della pagina della libreria di ciascuna API. Ad esempio, osserva pubsub.googleapis.com come "Nome servizio". in fondo alla pagina Pub/Sub appena sopra.

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

4. Aggiorna configurazione

Gli aggiornamenti della configurazione sono dovuti esplicitamente all'utilizzo aggiuntivo delle librerie client di Cloud. Indipendentemente dalla versione che utilizzi, devi apportare le stesse modifiche alle app che non utilizzano nessuna libreria client di Cloud.

requirements.txt

Il modulo 8 scambia l'uso dell'NDB e della coda di attività di App Engine del modulo 1 con Cloud NDB e Cloud Tasks. Aggiungi sia google-cloud-ndb che google-cloud-tasks a requirements.txt in modo da partecipare a flask dal modulo 7:

flask
google-cloud-ndb
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à, specifica un numero di versione per bloccare le versioni funzionanti dell'app.

app.yaml

Quando utilizzi le librerie client di Cloud, il runtime di App Engine per Python 2 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 "più recente" 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

Durante la migrazione della tua app, l'app potrebbe già avere una sezione libraries. In caso affermativo, e mancano grpcio e setuptools, aggiungili alla sezione libraries esistente. L'elemento 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 a google.appengine.ext.vendor.add() in appengine_config.py collega le librerie di terze parti copiate (a volte chiamate "vendoring" o "auto-raggruppamento") in lib alla tua app. Sopra app.yaml, abbiamo aggiunto librerie integrate di terze parti, che necessitano di setuptools.pkg_resources.working_set.add_entry() per collegare la tua app a questi pacchetti integrati in lib. Di seguito è riportato il Modulo 1 appengine_config.py originale e dopo 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. Modifica il codice dell'applicazione

Questa sezione presenta gli aggiornamenti del file dell'applicazione principale, main.py, che sostituiscono l'uso delle code in modalità push delle code di attività di App Engine con Cloud Tasks. Il modello web templates/index.html non viene modificato: entrambe le app devono funzionare allo stesso modo e mostrare gli stessi dati. Le modifiche all'applicazione principale sono suddivise in queste quattro "da fare":

  1. Aggiorna importazioni e inizializzazione
  2. Aggiornamento della funzionalità del modello dei dati (Cloud NDB)
  3. Esegui la migrazione a Cloud Tasks (e Cloud NDB)
  4. Aggiorna gestore attività (push)

1. Aggiorna importazioni e inizializzazione

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

Gli aggiornamenti descritti nel terzo e quarto punto sopra riportati costituiscono la maggior parte delle costanti aggiuntive e dell'inizializzazione richieste. Vedi nel "prima" e "dopo" 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 dei dati (Cloud NDB)

NDB di App Engine e Cloud NDB funzionano quasi allo stesso modo. Il modello dei dati e la funzione store_visit() non hanno subito modifiche sostanziali. L'unica differenza evidente è che la creazione dell'entità Visit in store_visit() è ora incapsulata all'interno di un blocco with Python. Cloud NDB richiede che tutti gli accessi a Datastore siano controllati all'interno del proprio gestore di contesto, da cui deriva l'istruzione with. Gli snippet di codice riportati di seguito mostrano 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. Esegui la migrazione a Cloud Tasks (e Cloud NDB)

Il cambiamento più critico in questa migrazione cambia l'infrastruttura di accodamento sottostante. Questo avviene nella funzione fetch_visits(), in cui viene creata un'attività (push) per eliminare le visite precedenti che viene accodata per l'esecuzione. Tuttavia, le funzionalità originali del Modulo 7 rimangono invariate:

  1. Query per le visite più recenti.
  2. Anziché restituire immediatamente queste visite, salva il timestamp dell'ultimo Visit, la meno recente visualizzata: puoi eliminare in sicurezza tutte le visite precedenti a questa data.
  3. Visualizza in anteprima il timestamp come un numero in virgola mobile e una stringa utilizzando le utilità Python standard e utilizza entrambi in varie capacità, ad esempio visualizzazione all'utente, aggiunta ai log, passaggio al gestore e così via.
  4. Crea un'attività push con questo timestamp come payload e /trim come URL.
  5. Infine, il gestore delle attività viene chiamato tramite un POST HTTP a quell'URL.

Questo flusso di lavoro è illustrato dal modello snippet di codice:

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

Sebbene la funzionalità sia la stessa, Cloud Tasks diventa la piattaforma di esecuzione. Gli aggiornamenti per apportare questa modifica includono:

  1. Aggrega la query Visit all'interno di un blocco Python with (ripetendo la migrazione del Modulo 2 a Cloud NDB)
  2. Crea metadati di Cloud Tasks, inclusi gli attributi previsti, come payload e URL, ma aggiungi anche il tipo MIME e la codifica JSON per il payload.
  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. Aggiorna gestore attività (push)

La funzione di gestore delle attività (push) non richiede aggiornamenti significativi. richiede solo l'esecuzione. Questo vale per la coda di attività o le attività cloud. "Il codice è il codice", così si dice. Tuttavia, sono state apportate alcune modifiche di minore entità:

  1. Il payload del timestamp è stato passato testualmente alla coda di attività, ma era codificato in formato JSON per Cloud Tasks e quindi deve essere analizzato in formato JSON all'arrivo.
  2. La chiamata HTTP POST a /trim con coda di attività aveva un MIMEtype implicito di application/x-www-form-urlencoded, ma con Cloud Tasks viene designato esplicitamente come application/json, quindi esiste un modo leggermente diverso per estrarre il payload.
  3. Utilizzare il gestore del contesto del client API Cloud NDB (migrazione del Modulo 2 a Cloud NDB).

Di seguito sono riportati gli snippet di codice prima e dopo le modifiche al gestore di 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 delle applicazioni principale root() né al modello web templates/index.html.

6. Riepilogo/Pulizia

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

Esegui il deployment e verifica l'applicazione

Esegui il deployment della tua app con gcloud app deploy. L'output dovrebbe essere identico a quello dell'app del Modulo 7, ma ti rendi conto che sei passato a un prodotto di coda push completamente diverso, rendendo la tua app più portabile di prima.

4aa8a2cb5f527079.png

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. Se vuoi continuare a portare questa app in Python 3 ed eseguire ulteriormente la migrazione da Cloud NDB a Cloud Datastore, 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 realizzata per utenti non di App Engine o 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 quelle non App Engine, che utilizzano Cloud Datastore e desideri standardizzare su un'unica libreria client Datastore. Questa migrazione facoltativa da Cloud NDB a Cloud Datastore è trattata autonomamente (senza coda di attività o Cloud Tasks) nel Modulo 3.

Oltre ai Moduli 3, 8 e 9, altri moduli di migrazione incentrati sull'abbandono dei servizi in bundle legacy di App Engine da prendere in considerazione includono:

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

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

Problemi/feedback 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 7 (START) e il modulo 8 (FINISH) sono disponibili nella tabella seguente.

Codelab

Python 2

Python 3

Modulo 7

codice

code (non presente in questo tutorial)

Modulo 8 (questo codelab)

codice

(n/d)

Risorse online

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

Coda di attività di App Engine e attività cloud

NDB di App Engine 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.