1. Introduzione
Per iniziare a scrivere funzioni Cloud Run, puoi utilizzare i seguenti codelab:
In caso contrario, questo codelab illustra la procedura per creare Cloud Functions (2ª gen.).
Panoramica
Cloud Functions (2ª gen.) è la versione successiva di Google Cloud Functions, l'offerta Functions as a Service di Google Cloud. Questa nuova versione è dotata di un set di funzionalità avanzate ed è ora basata su Cloud Run ed Eventarc, per offrirti un controllo più avanzato su prestazioni e scalabilità, nonché sul runtime delle funzioni e sugli trigger da oltre 90 origini evento.
Questo codelab illustra la procedura per creare funzioni Cloud che rispondono alle chiamate HTTP e vengono attivate dai messaggi Pub/Sub e dai log di controllo di Cloud.
Novità
Questa nuova versione di Cloud Functions offre un'esperienza FaaS migliorata basata su Cloud Run, Cloud Build, Artifact Registry ed Eventarc.
Infrastruttura migliorata
- Elaborazione delle richieste più lunga: esegui le funzioni Cloud per un periodo di tempo superiore al valore predefinito di 5 minuti, in modo da eseguire più facilmente carichi di lavoro delle richieste più lunghi, come l'elaborazione di grandi stream di dati da Cloud Storage o BigQuery. Per le funzioni HTTP, il tempo massimo è 60 minuti. Per le funzioni basate su eventi, al momento il valore massimo è 10 minuti.
- Istanze più grandi:sfrutta fino a 16 GB di RAM e 4 vCPU su Cloud Functions per consentire carichi di lavoro in-memory più grandi, ad alta intensità di calcolo e più paralleli.
- Contemporaneità: elabora fino a 1000 richieste in parallelo con una singola istanza di funzione, riducendo al minimo gli avvii a freddo e migliorando la latenza durante la scalabilità.
- Istanze minime: fornisci istanze preriscaldate per ridurre gli avvii a freddo e assicurarti che il tempo di bootstrap dell'applicazione non influisca sul rendimento dell'applicazione.
- Suddivisione del traffico:supporta più versioni delle funzioni, suddividi il traffico tra versioni diverse ed esegui il rollback della funzione a una versione precedente.
Copertura più ampia degli eventi e supporto di CloudEvents
- Integrazione Eventarc: Cloud Functions ora include il supporto nativo per Eventarc, che include oltre 90 origini di eventi tramite gli audit log di Cloud (BigQuery, Cloud SQL, Cloud Storage...) e, ovviamente, Cloud Functions supporta ancora gli eventi provenienti da origini personalizzate pubblicando direttamente in Cloud Pub/Sub.
- Formato CloudEvent: tutte le funzioni basate su eventi rispettano lo standard di settore CloudEvents ( cloudevents.io), indipendentemente dalla sorgente, per garantire un'esperienza omogenea per gli sviluppatori. I payload vengono inviati tramite un CloudEvent strutturato con un payload cloudevent.data e implementano lo standard CloudEvent.
Obiettivi didattici
- Panoramica di Cloud Functions (2a gen.).
- Come scrivere una funzione che risponda alle chiamate HTTP.
- Come scrivere una funzione che risponda ai messaggi Pub/Sub.
- Come scrivere una funzione che risponda agli eventi Cloud Storage.
- Come scrivere una funzione che risponda a Cloud Audit Logs.
- Come suddividere il traffico tra due revisioni.
- Come eliminare gli avvii a freddo con il numero minimo di istanze.
- Come impostare la contemporaneità.
2. Configurazione e requisiti
Configurazione dell'ambiente da seguire in modo autonomo
- Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.
- Il Nome progetto è il nome visualizzato dei partecipanti del progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarlo in qualsiasi momento.
- L'ID progetto deve essere univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca. In genere non è importante sapere quale sia. Nella maggior parte dei codelab, è necessario fare riferimento all'ID progetto (in genere è identificato come
PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare il tuo e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà invariato per tutta la durata del progetto. - Per tua informazione, esiste un terzo valore, un Numero progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare le API/risorse Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non del tutto. Per arrestare le risorse in modo da non dover pagare dopo questo tutorial, puoi eliminare le risorse che hai creato o l'intero progetto. I nuovi utenti di Google Cloud possono partecipare al programma Prova senza costi di 300$.
Avvia Cloud Shell
Sebbene Google Cloud possa essere utilizzato da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Dalla console Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:
Dovrebbe richiedere solo pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere qualcosa di simile a questo:
Questa macchina virtuale viene caricata con tutti gli strumenti di sviluppo necessari. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione di rete. Tutto il lavoro in questo codelab può essere svolto all'interno di un browser. Non devi installare nulla.
Configura gcloud
In Cloud Shell, assicurati che l'ID progetto sia impostato e salvato in una variabile PROJECT_ID e che REGION sia impostato su us-west1:
gcloud config set project [YOUR-PROJECT-ID] PROJECT_ID=$(gcloud config get-value project) REGION=us-west1
Abilita API
Attiva tutti i servizi necessari:
gcloud services enable \ artifactregistry.googleapis.com \ cloudfunctions.googleapis.com \ cloudbuild.googleapis.com \ eventarc.googleapis.com \ run.googleapis.com \ logging.googleapis.com \ pubsub.googleapis.com
3. Funzione HTTP
Per la prima funzione, creiamo una funzione Node.js autenticata che risponda alle richieste HTTP. Utilizziamo anche un timeout di 10 minuti per mostrare come una funzione può avere più tempo per rispondere alle richieste HTTP.
Crea
Crea una cartella per l'app e vai a questa cartella:
mkdir ~/hello-http && cd $_
Crea un file index.js che risponda semplicemente alle richieste HTTP:
const functions = require('@google-cloud/functions-framework');
functions.http('helloWorld', (req, res) => {
res.status(200).send('HTTP with Node.js in GCF 2nd gen!');
});
Crea un file package.json per specificare le dipendenze:
{
"name": "nodejs-functions-gen2-codelab",
"version": "0.0.1",
"main": "index.js",
"dependencies": {
"@google-cloud/functions-framework": "^2.0.0"
}
}
Esegui il deployment
Esegui il deployment della funzione:
gcloud functions deploy nodejs-http-function \ --gen2 \ --runtime nodejs16 \ --entry-point helloWorld \ --source . \ --region $REGION \ --trigger-http \ --timeout 600s
Sebbene non sia strettamente necessario per questo passaggio, tieni presente il timeout di 600 secondi. In questo modo, la funzione può avere un timeout più lungo per rispondere alle richieste HTTP.
Una volta eseguito il deployment della funzione, puoi vederla nella sezione Cloud Functions della console Cloud:
Test
Testa la funzione con il seguente comando:
gcloud functions call nodejs-http-function \ --gen2 --region $REGION
Dovresti visualizzare il messaggio HTTP with Node.js in GCF 2nd gen! come risposta.
4. Funzione Pub/Sub
Per la seconda funzione, creiamo una funzione Python attivata da un messaggio Pub/Sub pubblicato in un argomento specifico.
Configura i token di autenticazione Pub/Sub
Se hai attivato l'account di servizio Pub/Sub il giorno 8 aprile 2021 o in una data precedente, concedi il ruolo iam.serviceAccountTokenCreator all'account di servizio Pub/Sub:
PROJECT_NUMBER=$(gcloud projects list --filter="project_id:$PROJECT_ID" --format='value(project_number)') gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com \ --role roles/iam.serviceAccountTokenCreator
Crea
Crea un argomento Pub/Sub da utilizzare per il sample:
TOPIC=cloud-functions-gen2-topic gcloud pubsub topics create $TOPIC
Crea una cartella per l'app e vai a questa cartella:
mkdir ~/hello-pubsub && cd $_
Crea un file main.py che registri semplicemente un messaggio contenente l'ID CloudEvent:
import functions_framework
@functions_framework.cloud_event
def hello_pubsub(cloud_event):
print('Pub/Sub with Python in GCF 2nd gen! Id: ' + cloud_event['id'])
Crea un file requirements.txt con i seguenti contenuti per specificare le dipendenze:
functions-framework==3.*
Esegui il deployment
Esegui il deployment della funzione:
gcloud functions deploy python-pubsub-function \ --gen2 \ --runtime python39 \ --entry-point hello_pubsub \ --source . \ --region $REGION \ --trigger-topic $TOPIC
Una volta eseguita la distribuzione della funzione, puoi visualizzarla nella sezione Cloud Functions della console Cloud:
Test
Testa la funzione inviando un messaggio all'argomento:
gcloud pubsub topics publish $TOPIC --message="Hello World"
Nei log dovresti vedere l'evento CloudEvent ricevuto:
gcloud functions logs read python-pubsub-function \ --region $REGION --gen2 --format "value(log)"
5. Funzione Cloud Storage
Per la prossima funzione, creiamo una funzione Node.js che risponda agli eventi di un bucket Cloud Storage.
Configura
Per utilizzare le funzioni Cloud Storage, concedi il ruolo IAM pubsub.publisher all'account di servizio Cloud Storage:
SERVICE_ACCOUNT=$(gsutil kms serviceaccount -p $PROJECT_NUMBER) gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$SERVICE_ACCOUNT \ --role roles/pubsub.publisher
Crea
Crea una cartella per l'app e vai a questa cartella:
mkdir ~/hello-storage && cd $_
Crea un file index.js che risponda semplicemente agli eventi di Cloud Storage:
const functions = require('@google-cloud/functions-framework');
functions.cloudEvent('helloStorage', (cloudevent) => {
console.log('Cloud Storage event with Node.js in GCF 2nd gen!');
console.log(cloudevent);
});
Crea un file package.json per specificare le dipendenze:
{
"name": "nodejs-functions-gen2-codelab",
"version": "0.0.1",
"main": "index.js",
"dependencies": {
"@google-cloud/functions-framework": "^2.0.0"
}
}
Esegui il deployment
Innanzitutto, crea un bucket Cloud Storage (o utilizzane uno esistente):
export BUCKET="gs://gcf-gen2-storage-$PROJECT_ID" gsutil mb -l $REGION $BUCKET
Esegui il deployment della funzione:
gcloud functions deploy nodejs-storage-function \ --gen2 \ --runtime nodejs16 \ --entry-point helloStorage \ --source . \ --region $REGION \ --trigger-bucket $BUCKET \ --trigger-location $REGION
Una volta eseguita il deployment della funzione, puoi visualizzarla nella sezione Cloud Functions della console Cloud.
Test
Testa la funzione caricando un file nel bucket:
echo "Hello World" > random.txt gsutil cp random.txt $BUCKET/random.txt
Nei log dovresti vedere l'evento CloudEvent ricevuto:
gcloud functions logs read nodejs-storage-function \ --region $REGION --gen2 --limit=100 --format "value(log)"
6. Funzione Audit log di Cloud
Per la funzione successiva, creiamo una funzione Node.js che riceve un evento Log di controllo cloud quando viene creata un'istanza VM Compute Engine. In risposta, aggiunge un'etichetta alla VM appena creata, specificando il creator della VM.
Determinare le VM Compute Engine appena create
Compute Engine emette due log di controllo quando viene creata una VM.
Il primo viene emesso all'inizio della creazione della VM e ha il seguente aspetto:
Il secondo viene emesso dopo la creazione della VM e ha il seguente aspetto:
Tieni presente il campo dell'operazione con i valori first: true e last: true. Il secondo audit log contiene tutte le informazioni necessarie per etichettare un'istanza, pertanto utilizzeremo il flag last: true per rilevarlo in Cloud Functions.
Configura
Per utilizzare le funzioni degli audit log di Cloud, devi attivare gli audit log per Eventarc. Devi anche utilizzare un account di servizio con il ruolo eventarc.eventReceiver.
- Attiva i tipi di log di controllo di Cloud Lettura amministrazione, Lettura dati e Scrittura dati per l'API Compute Engine:
- Concedi all'account di servizio Compute Engine predefinito il ruolo IAM
eventarc.eventReceiver:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role roles/eventarc.eventReceiver
Ottieni il codice
Clona il repository che contiene l'applicazione:
git clone https://github.com/GoogleCloudPlatform/eventarc-samples.git
Vai alla directory dell'app:
cd eventarc-samples/gce-vm-labeler/gcf/nodejs
Il file index.js contiene il codice dell'applicazione che riceve il log di controllo inserito in un CloudEvent. Estrae quindi i dettagli dell'istanza VM Compute Engine e imposta un'etichetta sull'istanza VM. Non esitare a studiare index.js in modo più dettagliato.
Esegui il deployment
Puoi eseguire il deployment della funzione con gcloud come prima. Tieni presente che la funzione filtra i log di controllo per le inserzioni di Compute Engine con il flag --trigger-event-filters:
gcloud functions deploy gce-vm-labeler \ --gen2 \ --runtime nodejs16 \ --entry-point labelVmCreation \ --source . \ --region $REGION \ --trigger-event-filters="type=google.cloud.audit.log.v1.written,serviceName=compute.googleapis.com,methodName=beta.compute.instances.insert" \ --trigger-location us-central1
Puoi anche eseguire il deployment della funzione e aggiungere un trigger Eventarc dalla console Google Cloud.
Innanzitutto, vai alla sezione Cloud Functions e crea una funzione con un ambiente di 2ª generazione:
Fai clic sul pulsante Add Eventarc Trigger:
Viene visualizzato un riquadro laterale a destra in cui puoi scegliere diversi fornitori di eventi ed eventi per l'attivatore Eventarc.
Scegli il fornitore e l'evento giusti, quindi fai clic su Save Trigger:
Infine, nella pagina successiva, puoi aggiornare i file index.js e package.json con i file index.js e package.json su GitHub e fare clic sul pulsante Deploy:
Test
Per testare la funzione di log di controllo, devi creare una VM Compute Engine nella console Cloud (puoi anche creare VM con gcloud, ma non sembra che generi log di controllo).
Vai alla sezione Compute Engine > Istanze VM della console Cloud e crea una nuova VM. Al termine della creazione della VM, dovresti vedere l'etichetta creator aggiunta alla VM nella sezione Informazioni di base della console Cloud o utilizzando il seguente comando:
gcloud compute instances describe YOUR_VM_NAME
L'etichetta nell'output dovrebbe essere simile all'esempio seguente:
... labelFingerprint: ULU6pAy2C7s= labels: creator: atameldev ...
7. Suddivisione del traffico
Cloud Functions (2ª gen.) supporta più revisioni delle funzioni, suddividendo il traffico tra revisioni diverse ed eseguendo il rollback della funzione a una versione precedente. Questo è possibile perché le funzioni di 2ª gen. sono servizi Cloud Run sottostanti.
In questo passaggio, eseguirai il deployment di due revisioni di una funzione e poi suddividerai il traffico tra le due in modo uniforme.
Crea
Crea una cartella per l'app e vai a questa cartella:
mkdir ~/traffic-splitting && cd $_
Crea un file main.py con una funzione Python che legga una variabile di ambiente di colore e risponda con Hello World in quel colore di sfondo:
import os
color = os.environ.get('COLOR')
def hello_world(request):
return f'<body style="background-color:{color}"><h1>Hello World!</h1></body>'
Esegui il deployment
Esegui il deployment della prima revisione della funzione con uno sfondo arancione:
COLOR=orange gcloud functions deploy hello-world-colored \ --gen2 \ --runtime python39 \ --entry-point hello_world \ --source . \ --region $REGION \ --trigger-http \ --allow-unauthenticated \ --update-env-vars COLOR=$COLOR
A questo punto, se testi la funzione visualizzando l'attivatore HTTP (l'output URI del comando di deployment riportato sopra) nel browser, dovresti vedere Hello World con uno sfondo arancione:
Esegui il deployment della seconda revisione con uno sfondo giallo:
COLOR=yellow gcloud functions deploy hello-world-colored \ --gen2 \ --runtime python39 \ --entry-point hello_world \ --source . \ --region $REGION \ --trigger-http \ --allow-unauthenticated \ --update-env-vars COLOR=$COLOR
Poiché si tratta dell'ultima revisione, se testi la funzione dovresti vedere Hello World con uno sfondo giallo:
Suddividere il traffico 50-50
Per suddividere il traffico tra le revisioni arancione e gialla, devi trovare gli ID revisione dei servizi Cloud Run sottostanti. Questo è il comando per visualizzare gli ID revisione:
gcloud run revisions list --service hello-world-colored \ --region $REGION --format 'value(REVISION)'
L'output dovrebbe essere simile al seguente:
hello-world-colored-00001-man hello-world-colored-00002-wok
Ora, suddividi il traffico tra queste due revisioni come segue (aggiorna X-XXX in base ai nomi delle revisioni):
gcloud run services update-traffic hello-world-colored \ --region $REGION \ --to-revisions hello-world-colored-0000X-XXX=50,hello-world-colored-0000X-XXX=50
Test
Testa la funzione visitando il relativo URL pubblico. La metà delle volte dovresti vedere la revisione arancione e l'altra metà la revisione gialla:
Per ulteriori informazioni, consulta Rollback, implementazioni graduali e migrazione del traffico.
8. Numero minimo di istanze
In Cloud Functions (2ª gen.), è possibile specificare un numero minimo di istanze di funzione da mantenere disponibili e pronte per gestire le richieste. Questo è utile per limitare il numero di avvii a freddo.
In questo passaggio, eseguirai il deployment di una funzione con un'inizializzazione lenta. Noterai il problema di avvio a freddo. Poi, esegui il deployment della funzione con il valore dell'istanza minima impostato su 1 per eliminare l'avvio a freddo.
Crea
Crea una cartella per l'app e vai a questa cartella:
mkdir ~/min-instances && cd $_
Crea un file main.go. Questo servizio Go ha una funzione init che dorme per 10 secondi per simulare un'inizializzazione di lunga durata. Dispone inoltre di una funzione HelloWorld che risponde alle chiamate HTTP:
package p
import (
"fmt"
"net/http"
"time"
)
func init() {
time.Sleep(10 * time.Second)
}
func HelloWorld(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Slow HTTP Go in GCF 2nd gen!")
}
Esegui il deployment
Esegui il deployment della prima revisione della funzione con il valore predefinito dell'istanza minima pari a zero:
gcloud functions deploy slow-function \ --gen2 \ --runtime go116 \ --entry-point HelloWorld \ --source . \ --region $REGION \ --trigger-http \ --allow-unauthenticated
Testa la funzione con questo comando:
gcloud functions call slow-function \ --gen2 --region $REGION
Noterai un ritardo di 10 secondi (avvio a freddo) alla prima chiamata, dopodiché vedrai il messaggio. Le chiamate successive dovrebbero essere restituite immediatamente.
Impostare il numero minimo di istanze
Per eliminare l'avvio a freddo alla prima richiesta, esegui nuovamente il deployment della funzione con il flag --min-instances impostato su 1 come segue:
gcloud functions deploy slow-function \ --gen2 \ --runtime go116 \ --entry-point HelloWorld \ --source . \ --region $REGION \ --trigger-http \ --allow-unauthenticated \ --min-instances 1
Test
Testa di nuovo la funzione:
gcloud functions call slow-function \ --gen2 --region $REGION
Non dovresti più vedere il ritardo di 10 secondi nella prima richiesta. Il problema dell'avvio a freddo per la prima chiamata (dopo molto tempo senza) non si verifica più, grazie al numero minimo di istanze.
Per ulteriori informazioni, consulta la sezione Utilizzare istanze minime.
9. Contemporaneità
In Cloud Functions (2a gen), un'istanza di funzione gestisce 1 richiesta in parallelo per impostazione predefinita, ma è possibile specificare il numero di richieste in parallelo che possono essere elaborate contemporaneamente da un'istanza. Questo può essere utile anche per evitare gli avvii a freddo, dato che non è necessario creare una nuova istanza di funzione per ogni richiesta parallela.
In questo passaggio, utilizzerai la funzione con l'inizializzazione lenta del passaggio precedente. Invierà 10 richieste e osserverà di nuovo il problema di avvio a freddo, poiché è necessario creare nuove istanze di funzione per gestire le richieste.
Per risolvere il problema di avvio a freddo, esegui il deployment di un'altra funzione con un valore di concorrenza pari a 100. Noterai che le 10 richieste ora non causano il problema di avvio a freddo e una singola istanza di funzione può gestire tutte le richieste.
Test senza concorrenza
Recupera l'URL della funzione:
SLOW_URL=$(gcloud functions describe slow-function --region $REGION --gen2 --format="value(serviceConfig.uri)")
Utilizza uno strumento di benchmarking open source chiamato hey per inviare 10 richieste simultanee alla funzione lenta. hey è già installato in Cloud Shell:
hey -n 10 -c 10 $SLOW_URL
Nell'output di hey dovresti vedere che alcune richieste richiedono molto tempo:
Summary: Total: 10.9053 secs Slowest: 10.9048 secs Fastest: 0.4439 secs Average: 9.7930 secs Requests/sec: 0.9170 Total data: 310 bytes Size/request: 31 bytes Response time histogram: 0.444 [1] |■■■■ 1.490 [0] | 2.536 [0] | 3.582 [0] | 4.628 [0] | 5.674 [0] | 6.720 [0] | 7.767 [0] | 8.813 [0] | 9.859 [0] | 10.905 [9] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Questo perché vengono create più istanze di funzione per gestire le richieste. Se controlli il numero di istanze attive per la funzione, dovresti anche vedere che è stata creata più di un'istanza come punto di accesso e che causano il problema dell'avvio a freddo:
Eseguire il deployment
Esegui il deployment di una nuova funzione identica a quella precedente. Una volta eseguito il deployment, ne aumenterà la contemporaneità:
gcloud functions deploy slow-concurrent-function \ --gen2 \ --runtime go116 \ --entry-point HelloWorld \ --source . \ --region $REGION \ --trigger-http \ --allow-unauthenticated \ --min-instances 1
Impostare la contemporaneità
Imposta la concorrenza del servizio Cloud Run sottostante per la funzione su 100 (può essere massimo 1000). Ciò garantisce che almeno 100 richieste possano essere gestite da una singola istanza di funzione:
gcloud run services update slow-concurrent-function \ --concurrency 100 \ --cpu 1 \ --region $REGION
Eseguire test con la concorrenza
Recupera l'URL della funzione:
SLOW_CONCURRENT_URL=$(gcloud functions describe slow-concurrent-function --region $REGION --gen2 --format="value(serviceConfig.uri)")
Quindi, utilizza hey per inviare 10 richieste in parallelo:
hey -n 10 -c 10 $SLOW_CONCURRENT_URL
Nell'output di hey dovresti vedere che tutte le richieste vengono elaborate rapidamente:
Summary: Total: 0.2164 secs Slowest: 0.2163 secs Fastest: 0.0921 secs Average: 0.2033 secs Requests/sec: 46.2028 Total data: 310 bytes Size/request: 31 bytes Response time histogram: 0.092 [1] |■■■■ 0.105 [0] | 0.117 [0] | 0.129 [0] | 0.142 [0] | 0.154 [0] | 0.167 [0] | 0.179 [0] | 0.191 [0] | 0.204 [0] | 0.216 [9] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Una singola istanza di funzione è stata in grado di gestire tutte le richieste e il problema dell'avvio a freddo è scomparso, grazie all'aumento della concorrenza.
Per ulteriori informazioni, consulta la sezione Contemporaneità.
10. Complimenti!
Complimenti per aver completato il codelab.
Argomenti trattati
- Panoramica di Cloud Functions (2a gen.).
- Come scrivere una funzione che risponda alle chiamate HTTP.
- Come scrivere una funzione che risponda ai messaggi Pub/Sub.
- Come scrivere una funzione che risponda agli eventi Cloud Storage.
- Come scrivere una funzione che risponda a Cloud Audit Logs.
- Come suddividere il traffico tra due revisioni.
- Come eliminare gli avvii a freddo con il numero minimo di istanze.
- Come impostare la contemporaneità.