— è una delle tendenze più significative nel cloud computing. Il principio fondamentale è che l'infrastruttura è responsabilità del fornitore di servizi, non degli sviluppatori DevOps. La scalabilità delle risorse si adatta automaticamente al carico e offre un'elevata velocità di cambiamento.
Un'altra caratteristica comune è la tendenza a minimizzare e focalizzare il codice, motivo per cui il calcolo serverless è talvolta definito come "funzione come servizio" (FaaS).
Il primo fornitore di servizi cloud ad offrire FaaS con AWS Lambda è stato Amazon, da cui è derivato questo nome. Anche altri fornitori di servizi cloud offrono analoghi:
- Cloud Functions di Google
- Azure Functions di Microsoft
Tutte queste aziende offrono calcolo serverless, scalabilità automatica e pagamento solo per le risorse effettivamente utilizzate, ma legano i clienti al loro prodotto proprietario. Tuttavia, esistono alternative gratuite open source per implementare il calcolo serverless. È importante notare:
- La piattaforma , sviluppata in incubazione da IBM,
- , come parte di un ecosistema piuttosto ricco chiamato Spring Framework, che può anche funzionare come facciata per AWS Lambda, Azure Functions e OpenWhisk,
- , supportato da Oracle.
Tutti sono completamente indipendenti dai fornitori di cloud, il che significa che possono essere installati in qualsiasi cloud, compresi i vostri, pubblici o privati, e naturalmente in Exoscale.
Come è strutturato il progetto Fn
Fn si basa completamente su Docker e consiste in due componenti principali:
- un programma CLI destinato a gestire tutti gli aspetti dell'infrastruttura Fn e interagire con il server Fn,
- Il server Fn stesso, una normale applicazione confezionata in un contenitore Docker.
Le funzioni distribuite in Fn vengono eseguite anch'esse in contenitori separati, il che consente il supporto di molti linguaggi di programmazione, come ad esempio... Clojure!
Gli argomenti delle funzioni vengono passati all'input standard (STDIN), mentre i risultati vengono scritti sull'output standard (STDOUT). Se gli argomenti o i valori restituiti non sono semplici valori (ad esempio, oggetti JSON), possono essere convertiti attraverso uno strato di astrazione fornito dallo stesso Fn sotto forma di Function Development Kit (FDK).
Per facilitare, sono disponibili set di modelli integrati che semplificano il deployment di FaaS su un'ampia lista di linguaggi e relative versioni (Go, diverse versioni di Java, Python, ecc.).
Creare un FaaS è semplice seguendo questo schema:
- Deployiamo la funzione utilizzando il CLI di Fn: viene creato un file di configurazione dell'applicazione per Fn, basato sul modello selezionato.
- Distribuiamo la nostra funzione, sempre utilizzando il CLI di Fn: l'immagine del contenitore viene inviata a un repository, dopodiché il server viene informato dell'esistenza e della posizione di questa immagine.
Il principio di fornitura delle funzioni in Fn
Installazione locale e testing delle funzioni serverless
Iniziamo a installare Fn sulla macchina locale. Prima di tutto, installiamo Docker, come richiesto da Fn. Si presume che siamo su Debian/Ubuntu:
$ sudo apt-get update
$ sudo apt-get install docker.ioOppure utilizza il gestore di pacchetti/compilazione di Docker secondo il tuo sistema. Successivamente, possiamo passare direttamente all'installazione del CLI di Fn. Ad esempio, usando curl:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | shSe stai lavorando su OSX con Homebrew installato, puoi seguire un'altra strada:
$ brew install fn
==> Downloading https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/b1/b1767fb00e2e69fd9da73427d0926b1d1d0003622f7ddc0dd3a899b2894781ff?__gda__=exp=1538038849~hmac=c702c9335e7785fcbacad1f29afa61244d02f2eebb
######################################################################## 100.0%
==> Pouring fn-0.5.8.high_sierra.bottle.tar.gz
/usr/local/Cellar/fn/0.5.8: 5 files, 16.7MBOra tutto è pronto per il primo dispiegamento della nostra funzione utilizzando la CLI. Per semplicità, utilizzeremo l'ambiente integrato per l'esecuzione, come Node:
$ fn init --runtime node --trigger http hellonode
Creando la funzione in: /hellonode
Boilerplate della funzione generato.
func.yaml creato.Verrà creato un nuovo catalogo hellonode per lo sviluppo successivo della nostra funzione Fn con alcuni file di configurazione di base. All'interno della cartella appena creata, puoi creare la tua applicazione seguendo gli standard del linguaggio o dell'ambiente di esecuzione scelto:
# Каталог с node выглядит так:
hellonode
├── func.js
├── func.yaml
└── package.json
# Свежеустановленное окружение Java11 такое:
hellojava11
├── func.yaml
├── pom.xml
└── src
├── main
│ └── java
│ └── com
│ └── example
│ └── fn
│ └── HelloFunction.java
└── test
└── java
└── com
└── example
└── fn
└── HelloFunctionTest.javaFn crea la struttura iniziale del progetto, genera il file func.yaml, contenente le configurazioni necessarie per Fn, e imposta un modello per il codice nel linguaggio che hai scelto.
Nel caso dell'ambiente di esecuzione Node, questo significa:
$ cat hellonode/func.js
const fdk=require('@fnproject/fdk');
fdk.handle(function(input){
let name = 'World';
if (input.name) {
name = input.name;
}
return {'message': 'Hello ' + name}
})Ora daremo un rapido sguardo alla nostra funzione localmente per vedere come funziona tutto.
Per iniziare, avviamo il server Fn. Come già detto, il server Fn è un contenitore Docker, quindi dopo l'avvio andrà a prendere l'immagine dal registro Docker.
$ fn start -d # avviamo il server locale in background
Impossibile trovare l'immagine 'fnproject/fnserver:latest' localmente
latest: Scaricamento da fnproject/fnserver
ff3a5c916c92: Download completo
1a649ea86bca: Download completo
ce35f4d5f86a: Download completo
...
Stato: Immagine più recente scaricata per fnproject/fnserver:latest
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5Per eseguire la nostra funzione, è necessario "deployarla". A questo scopo serve il nome dell'applicazione: in Fn tutte le applicazioni devono essere definite come spazi dei nomi per le funzioni correlate.
Fn CLI cercherà un file func.yaml nella directory corrente che sarà utilizzato per configurare la funzione. Quindi prima dobbiamo andare nella nostra directory. hellonode.
$ cd hellonode
$ fn deploy --app fnexo --local # distribuiamo la funzione localmente, il nome dell'app è fnexo.
# il parametro local non carica l'immagine su un registro remoto,
# avviandola direttamente
Distribuendo hellonode all'app: fnexo
Aggiornato alla versione 0.0.2
Costruendo l'immagine nfrankel/hellonode:0.0.3 .
Aggiornando la funzione hellonode utilizzando l'immagine nfrankel/hellonode:0.0.3...
App creata con successo: fnexo
Funzione creata con successo: hellonode con nfrankel/hellonode:0.0.3
Attivatore creato con successo: hellonode-triggerCome puoi vedere dall'output del comando, viene creata una nuova immagine del contenitore Docker contenente la nostra funzione. La funzione è pronta per essere chiamata, e abbiamo due modi per farlo:
- utilizzando il comando Fn
invoke - chiamandola direttamente attraverso
http
La chiamata invoke Fn emula semplicemente il lavoro HTTP per i test, che è comodo per un rapido controllo:
$ fn invoke fnexo hellonode # chiamiamo la funzione hellonode dell'app fnexo
{"message":"Hello World"}Per chiamare la funzione direttamente, è necessario conoscere l'URL completo:
$ curl http://localhost:8080/t/fnexo/hellonode-trigger
{"message":"Hello World"}Il server Fn fornisce le sue funzioni tramite la porta 8080, e sembra che l'URL della funzione corrisponda allo schema t/app/function, ma non completamente. Attraverso HTTP, la funzione non viene chiamata direttamente, ma tramite quello che viene definito come un trigger, che secondo il suo nome «avvia» la chiamata della funzione. I trigger sono definiti in `func.yml del progetto:
schema_version: 20180708
name: hellonode
version: 0.0.3
runtime: node
entrypoint: node func.js
format: json
triggers:
- name: hellonode-trigger
type: http
source: /hellonode-trigger # URL del triggerPossiamo cambiare il nome del trigger affinché corrisponda al nome della funzione, rendendo tutto più semplice:
triggers:
- name: hellonode-trigger
type: http
source: /hellonode # coincide con il nome della funzionePoi rilanciamo la distribuzione della funzione e la chiamiamo dal nuovo trigger:
$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode
{"message":"Hello World"}Tutto funziona! È tempo di passare a esperimenti pratici e pubblicare il nostro FaaS sul server!
Installazione di servizi per funzioni serverless sulla propria infrastruttura
Facciamo rapidamente impostare una macchina virtuale utilizzando la CLI di Exoscale. Se non l'hai ancora configurata, puoi seguire . È uno strumento fantastico che aumenterà ulteriormente la tua produttività. Non dimenticare di configurare la regola per aprire la porta 8080 nel Security Group! I seguenti comandi avvieranno una macchina virtuale pulita, pronta per ospitare le nostre funzioni:
$ exo firewall create fn-securitygroup
$ exo firewall add fn-securitygroup ssh --my-ip
$ exo firewall add fn-securitygroup -p tcp -P 8080-8080 -c 0.0.0.0/0
$ exo vm create fn-server -s fn-securitygroupPoi puoi accedere alla macchina virtuale tramite ssh e installare il server Fn:
$ exo ssh fn-server
L'autenticità dell'host '185.19.30.175 (185.19.30.175)' non può essere stabilita.
L'impronta della chiave ECDSA è SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q.
Sei sicuro di voler continuare la connessione (sì/no)? sì
Attenzione: '185.19.30.175' (ECDSA) è stato aggiunto permanentemente all'elenco degli host conosciuti.
Benvenuto in Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)Successivamente, installiamo Docker e il server Fn proprio come fatto sulla macchina locale, avviando il server:
$ sudo apt-get update
$ sudo apt-get install docker.io
$ sudo systemctl start docker
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
$ sudo fn start
...
______
/ ____/___
/ _/ /__/
/_/ / / /
/_/ /_/_/
v0.3.643Fn è pronto a ricevere funzioni! Per inviare funzioni al server remoto utilizzeremo il comando deploy dal computer locale, tralasciando il flag --local.
Inoltre, Fn richiede di specificare la posizione del server Fn e del registro Docker. Questi parametri possono essere impostati tramite variabili di ambiente FN_API_URL e FN_REGISTRY di conseguenza, ma è disponibile anche un modo più semplice per gestire la creazione e la gestione delle configurazioni per il deployment.
In termini di Fn, la configurazione per il deployment è chiamata context. Il comando seguente creerà un contesto:
$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankelPuoi visualizzare i contesti disponibili in questo modo:
$ fn list contexts
CURRENT NAME PROVIDER API URL REGISTRY
default default http://localhost:8080/
exoscale default http://185.19.30.175:8080 nfrankel
E per passare al contesto appena creato, usa:
$ fn use context exoscale
Now using context: exoscaleDa questo momento in poi, il deployment delle funzioni Fn caricherà le immagini Docker utilizzando l'account selezionato su DockerHub (nel mio caso — nfrankel), dopo di che notificherà il server remoto (in questo esempio — http://185.19.30.175:8080) riguardo la posizione e la versione dell'ultima immagine contenente la tua funzione.
$ fn deploy --app fnexo . # eseguito sulla macchina locale dalla cartella hellonode
Deploying function at: /.
Deploying hellonode to app: fnexo
Bumped to version 0.0.5
Building image nfrankel/hellonode:0.0.5 .Infine:
$ curl http://185.19.30.175:8080/t/fnexo/hellonode
{"message":"Hello World"}
Il ciclo di vita di una funzione nel computing serverless basato su Fn
Vantaggi del calcolo serverless sulla propria infrastruttura
Il calcolo serverless è una soluzione conveniente per l'implementazione rapida di parti indipendenti di un'applicazione che interagiscono con applicazioni più complesse o microservizi.
Spesso ciò è legato ai costi nascosti dell'impegno verso un fornitore specifico, il che, a seconda dello specifico caso d'uso e della scala, può portare a spese più elevate e a una riduzione della flessibilità in futuro.
Anche le architetture cloud multi-cloud e ibride ne risentono, poiché ci si può facilmente trovare nella situazione in cui si vorrebbe utilizzare il calcolo serverless, ma a causa delle politiche aziendali potrebbe non essere possibile farlo.
Fn è abbastanza semplice da usare e può fornire un'interfaccia quasi identica a quella del FaaS, con costi contenuti. Esso elimina qualsiasi vincolo con il fornitore, e può essere installato localmente o presso qualsiasi fornitore di servizi cloud a scelta. Inoltre, c'è libertà nella scelta del linguaggio di programmazione.
L'articolo presenta solo le basi di Fn, ma creare un ambiente di esecuzione personale è piuttosto semplice, e l'architettura generale può essere ampliata utilizzando un bilanciatore di carico Fn, oppure posizionando Fn dietro un proxy per protezione.
Fonte: habr.com
