Scrivere funzioni Cloud
Cloud Functions può essere scritto in Node.js, Python, Go, Java, .NET, Ruby e PHP e i programmi vengono eseguiti in runtime specifici per i linguaggi. L'ambiente di esecuzione di Cloud Functions varia in base al runtime di tua scelta. Le pagine della panoramica del runtime forniscono ulteriori dettagli su ogni ambiente di runtime:
- Tempo di esecuzione del nodo.js
- Tempo di esecuzione di Python
- Go Runtime
- Tempo di esecuzione Java
- Runtime .NET
- Ruby Runtime
- Tempo di esecuzione dei PHP
Provalo
Se non hai mai utilizzato Google Cloud, crea un account per valutare le prestazioni di Cloud Functions in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
Prova Cloud Functions gratuitamenteTipi di funzioni di Cloud Functions
Esistono due diversi tipi di funzioni di Cloud Functions: funzioni HTTP e funzioni basate su eventi. Le funzioni basate su eventi possono essere di tipo funzioni in background o cloudEvent, a seconda del runtime di Cloud Functions per cui sono scritte.
Funzioni HTTP
Le chiamate HTTP vengono richiamate dalle richieste HTTP standard. Queste richieste HTTP attendono la risposta e il supporto della gestione di metodi di richiesta HTTP comuni, come GET, PUT, POST, DELETE e OPTIONS. Quando utilizzi Cloud Functions, viene eseguito automaticamente il provisioning di un certificato TLS, quindi tutte le funzioni HTTP possono essere richiamate tramite una connessione sicura.
Per maggiori dettagli, consulta la sezione Scrivere funzioni HTTP.
Esempio:
Node.js
Python
Go
Java
C#
Ruby
PHP
Funzioni basate su eventi
Cloud Functions utilizza funzioni basate su eventi per gestire gli eventi provenienti dalla tua infrastruttura Cloud, come i messaggi su un argomento Pub/Sub o le modifiche apportate a un bucket Cloud Storage.
Cloud Functions supporta due sottotipi di funzioni basate su eventi:
Come spiegato di seguito, il sottotipo utilizzato sarà regolato dal runtime scelto come target dalla funzione.
Funzioni in background
Le funzioni basate su eventi scritte per i runtime Node.js, Python, Go e Java sono note come funzioni in background. Per ulteriori informazioni, consulta la sezione Scrivere funzioni in background.
Esempio:
Node.js
Python
Go
Java
Funzioni CloudEvent
Le funzioni basate su eventi scritte per i runtime .NET, Ruby e PHP sono note come funzioni CloudEvent. Per ulteriori dettagli, consulta la sezione Scrivere funzioni CloudEvent.
Esempio:
C#
Ruby
PHP
Strutturazione del codice sorgente
Affinché Cloud Functions possa trovare la definizione della tua funzione, ogni runtime ha requisiti di strutturazione per il codice sorgente. In generale, consigliamo di suddividere il codebase di grandi dimensioni e multifunzione in funzioni più piccole per ridurre la complessità del codice e il numero di dipendenze per funzione.
Node.js
Per i runtime Node.js, il codice sorgente della funzione deve essere esportato da un modulo Node.js, che Cloud Functions carica tramite una chiamata require()
.
Per determinare quale modulo caricare, Cloud Functions utilizza il campo
main
nel file package.json
. Se il campo main
non è specificato,
Cloud Functions carica il codice da index.js
.
Ad esempio, le seguenti configurazioni del codice sorgente sono valide:
Un singolo
index.js
situato nella directory radice della funzione che esporta una o più funzioni:. └── index.js
Un file
index.js
che importa il codice da un filefoo.js
e poi esporta una o più funzioni:. ├── index.js └── foo.js
Un file
app.js
che esporta una o più funzioni, con un filepackage.json
che contiene"main": "app.js"
:. ├── app.js └── package.json
Python
Per il runtime Python, il punto di ingresso della tua funzione deve essere definito in un file di origine Python denominato main.py
che si trova nella directory radice delle funzioni.
Ad esempio, le seguenti configurazioni del codice sorgente sono valide:
Un singolo file
main.py
nella directory radice della funzione che definisce una o più funzioni:. └── main.py
Un file
main.py
con un filerequirements.txt
che specifica le dipendenze:. ├── main.py └── requirements.txt
Un file
main.py
che importa il codice da una dipendenza locale:. ├── main.py └── mylocalpackage/ ├── __init__.py └── myscript.py
Go
Per il runtime Go, la funzione deve trovarsi in un pacchetto Go nella directory principale del progetto. La tua funzione non può essere in package main
. I sottopacchetti sono supportati
solo quando si utilizzano i moduli Go.
Ad esempio, le seguenti configurazioni del codice sorgente sono valide:
Un pacchetto nella directory principale del progetto che esporta una o più funzioni:
. └── function.go
Un pacchetto nella directory principale del progetto che consente di importare il codice da un sottopacchetto e di esportare una o più funzioni:
. ├── function.go ├── go.mod └── shared/ └── shared.go
Un pacchetto nella directory principale del progetto con una sottodirectory che definisce un elemento
package main
:. ├── cmd/ | └── main.go └── function.go
Java
Per il runtime Java, devi creare una directory di funzione di primo livello contenente una sottodirectory src/main/java/
e un file pom.xml
. Consigliamo di inserire i test in una sottodirectory src/test/java/
.
. ├── pom.xml └── src/ ├── main/ | └── java/ | └── MyFunction.java └── test └── java/ └── MyFunctionTest.java
Se il file .java
dichiara un pacchetto (ad esempio, functions
), la gerarchia
della directory sarà simile a questa:
. ├── pom.xml └── src/ ├── main/ | └── java/ | └── functions/ | └── MyFunction.java └── test/ └── java/ └── functions/ └── MyFunctionTest.java.
Se la tua funzione viene definita in un pacchetto specifico come la maggior parte delle funzioni Java, deve essere specificata come parte del valore di --entry-point
al
tempo di deployment.
Raggruppamento di più funzioni
Se stai pensando di raggruppare più funzioni in un singolo progetto, tieni presente che ogni funzione potrebbe finire per condividere lo stesso insieme di dipendenze. Tuttavia, alcune funzioni potrebbero non richiedere tutte le dipendenze condivise.
Consigliamo di inserire ogni funzione nella propria directory di primo livello, come mostrato
sopra, con la propria sottodirectory src/main/java
e il proprio file pom.xml
.
Questo approccio riduce al minimo il numero di dipendenze necessarie per una determinata funzione, il che a sua volta riduce la quantità di memoria necessaria alla funzione.
Inoltre, funzioni separate semplificano la specifica di una singola funzione durante l'esecuzione di funzioni localmente tramite il framework delle funzioni. Questo può essere utile per lo sviluppo e i test locali.
C#
Per il runtime .NET, puoi strutturare i progetti come faresti con qualsiasi altro codice sorgente .NET.
Quando utilizzi i modelli per creare una funzione C#, vengono creati i seguenti file allo stesso livello del file system:
- Un file di origine della funzione denominato
Function.cs
. - Un file di progetto con estensione
.csproj
.
Ad esempio:
. ├── Function.cs └── HelloHttp.csproj
Lo stesso pattern viene applicato quando utilizzi i modelli per creare le funzioni F# e Visual Basic. Per F#, il nome del file è Function.fs
e il file del progetto ha l'estensione .fsproj
. Per Visual Basic, il nome del file è CloudFunction.vb
e il file del progetto ha l'estensione .vbproj
.
Tuttavia, questi pattern sono solo convenzioni, non requisiti. Puoi strutturare il codice come faresti con qualsiasi altro progetto C#, F# o Visual Basic standard, che può contenere più file di origine, risorse e così via.
Inoltre, se implementi una sola funzione per progetto, puoi avviare l'hosting di tale funzione senza specificarne il nome, il che può semplificare lo sviluppo locale e il debug.
Ruby
Per il runtime Ruby, il punto di ingresso della tua funzione deve essere definito in un file di origine Ruby chiamato app.rb
nella directory principale della funzione.
Inoltre, le dipendenze, inclusa almeno la gemma functions_framework
, devono essere elencate in un file Gemfile
associato con Gemfile.lock
, che si trova anche nella directory principale della funzione. La tua funzione può includere ulteriori file Ruby nella directory radice o nelle sottodirectory.
Ad esempio, le seguenti configurazioni del codice sorgente sono valide:
. ├── Gemfile ├── Gemfile.lock └── app.rb . ├── Gemfile ├── Gemfile.lock ├── app.rb └── lib/ └── my_class.rb
PHP
Per il runtime PHP, devi creare una directory di funzioni di primo livello con un fileindex.php
contenente l'implementazione della funzione.
Il file composer.json
dichiara le dipendenze. Quando esegui il comando
composer require google/cloud-functions-framework
come descritto in
Specifica delle dipendenze in PHP,
viene creata una directory vendor/
nella directory del codice della funzione che contiene
le dipendenze. Il file composer.lock
blocca le dipendenze per la funzione, il che significa che la funzione conserva un record esatto delle versioni delle dipendenze che sono state installate. Se dovessi eseguire di nuovo composer install
in futuro, utilizzeresti le versioni delle dipendenze specificate nel file composer.lock
.
Consigliamo di inserire i test in una directory test/
.
. ├── index.php ├── composer.json ├── composer.lock ├── vendor/ └── test/
Specifica delle dipendenze
Puoi specificare le dipendenze della funzione in modo idiomatico in base al tempo di esecuzione in uso. Per ulteriori dettagli, consulta la pagina appropriata:
- Specifica delle dipendenze in Node.js
- Specifica delle dipendenze in Python
- Specificare le dipendenze in Go
- Indicazione delle dipendenze in Java
- Indicazione delle dipendenze in .NET
- Specificare le dipendenze in Ruby
- Specificare le dipendenze in PHP
Denominazione delle Funzioni Cloud
Cloud Functions ha una proprietà "name" che viene impostata al momento del deployment e, una volta impostata, non può essere modificata. Il nome di una funzione viene utilizzato come identificatore e deve essere univoco all'interno di un'area geografica. Per informazioni dettagliate, consulta la documentazione di implementazione.
Passaggi successivi
- Deployment di Funzioni Cloud.
- Chiamata di Funzioni HTTP.
- Chiamata delle funzioni di trigger di Cloud Storage.
- Chiamata delle funzioni di trigger Pub/Sub.
- Tutorial sulle funzioni HTTP.
- Tutorial su Cloud Functions con Cloud Storage.
- Tutorial su Cloud Functions con Pub/Sub.
Provalo
Se non hai mai utilizzato Google Cloud, crea un account per valutare le prestazioni di Cloud Functions in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
Prova Cloud Functions gratuitamente