— una delle tendenze più evidenti nel cloud computing. Il principio fondamentale è che l'infrastruttura è una preoccupazione non degli sviluppatori DevOps, ma del fornitore del servizio. Il dimensionamento delle risorse si adatta automaticamente al carico e ha un'elevata velocità di cambiamento.
Un'altra caratteristica comune è la tendenza a minimizzare e concentrare il codice, motivo per cui il calcolo serverless è talvolta definito "funzione come servizio" (FaaS).
Storicamente, il primo fornitore di servizi cloud a offrire FaaS con AWS Lambda è stato Amazon, da cui deriva questo nome. Altri fornitori di servizi cloud offrono anche analoghi:
- Cloud Functions di Google
- Azure Functions di Microsoft
Tutte queste aziende forniscono calcolo senza server, ridimensionamento automatico e pagamento solo per le risorse effettivamente utilizzate, ma vincolano i clienti al loro prodotto proprietario. Tuttavia, esistono alternative gratuite open source per organizzare il calcolo senza server. Vale la pena notare:
- La piattaforma , sviluppata nell'incubatore di IBM,
- , come parte di un ecosistema piuttosto ricco di Spring Framework, che può anche essere utilizzato come facciata per AWS Lambda, Azure Functions e OpenWhisk,
- , supportato da Oracle.
Tutti sono completamente indipendenti dai cloud, ovvero possono essere installati in qualsiasi cloud, incluso il proprio, pubblico o privato, e naturalmente in Exoscale.
Come è strutturato il progetto Fn
Fn è completamente basato su Docker, composto da due componenti principali:
- CLI del programma, progettata per gestire tutti gli aspetti dell'infrastruttura Fn, che interagisce con il server Fn,
- Il vero e proprio server Fn, un'applicazione ordinaria confezionata in un contenitore per Docker.
Le funzioni distribuite in Fn vengono eseguite in contenitori separati, il che consente di supportare un numero considerevole di linguaggi di programmazione, ad esempio... Clojure!
Gli argomenti delle funzioni vengono passati tramite standard input (STDIN), i risultati vengono scritti su standard output (STDOUT). Se gli argomenti o i valori restituiti non sono valori semplici (ad esempio, oggetto JSON), possono essere trasformati tramite il livello di astrazione fornito dallo stesso Fn sotto forma di kit di sviluppo delle funzioni (FDK).
Per comodità, vengono offerti set di modelli integrati che semplificano il deployment di FaaS su un ampio elenco di diversi linguaggi e le loro versioni (Go, varie versioni di Java, Python, ecc.).
Creare FaaS è semplice, seguendo questo schema:
- Procediamo al deployment della funzione utilizzando la CLI Fn: viene creato un file di configurazione dell'applicazione per Fn, basato sul modello scelto.
- Distribuiamo la nostra funzione, ancora una volta utilizzando la CLI Fn: l'immagine del contenitore viene caricata in un repository, dopo di che il server viene avvisato dell'esistenza e del posizionamento di questa immagine.
Principio di fornitura delle funzioni in Fn
Installazione locale e test delle funzioni serverless
Iniziamo a installare Fn sulla macchina locale. Prima si deve installare Docker, come richiesto da Fn. Si presume che utilizziamo Debian/Ubuntu:
$ sudo apt-get update
$ sudo apt-get install docker.ioOppure usa il gestore pacchetti/compila Docker in base al tuo sistema. Poi, puoi passare direttamente all'installazione della CLI Fn. Ad esempio, utilizzando curl:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | shSe stai lavorando su OSX con Homebrew installato, puoi andare per 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.7MBAdesso tutto è pronto per il primo deployment della nostra funzione usando la CLI. Per semplicità, utilizzeremo l'ambiente integrato per l'esecuzione, ad esempio Node:
$ fn init --runtime node --trigger http hellonode
Creating function at: /hellonode
Function boilerplate generated.
func.yaml created.Verrà creato un nuovo catalogo hellonode per ulteriori sviluppi della nostra funzione Fn con alcuni file di configurazione di base. All'interno del catalogo appena creato puoi sviluppare 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 impostazioni necessarie per Fn, e stabilisce il 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}
})Adesso testeremo rapidamente la nostra funzione localmente per vedere come funziona tutto.
Per cominciare, avvieremo il server Fn. Come già detto, il server Fn è un container Docker, quindi dopo l'avvio si connetterà e scaricherà l'immagine dal registro Docker.
$ fn start -d # avviamo il server locale in background
Impossibile trovare l'immagine 'fnproject/fnserver:latest' localmente
latest: Recupero da fnproject/fnserver
ff3a5c916c92: Download completato
1a649ea86bca: Download completato
ce35f4d5f86a: Download completato
...
Status: Immagine più recente scaricata per fnproject/fnserver:latest
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5Per avviare la nostra funzione, deve essere "rilasciata". Per questo ci vuole il nome dell'applicazione: in Fn tutte le applicazioni devono essere definite come spazi dei nomi per funzioni correlate.
Fn CLI cercherà il file func.yaml nella directory corrente, che verrà utilizzato per configurare la funzione. Quindi, prima di tutto, dobbiamo passare alla nostra directory hellonode.
$ cd hellonode
$ fn deploy --app fnexo --local # rilasciamo la funzione localmente, nome dell'applicazione - fnexo.
# il parametro local non carica l'immagine nel registro remoto,
# eseguendola direttamente
Rilascio hellonode nell'app: fnexo
Aggiornato alla versione 0.0.2
Creazione dell'immagine nfrankel/hellonode:0.0.3 .
Aggiornamento della funzione hellonode utilizzando l'immagine nfrankel/hellonode:0.0.3...
App creato con successo: fnexo
Funzione creata con successo: hellonode con nfrankel/hellonode:0.0.3
Trigger creato con successo: hellonode-triggerCome si può vedere dall'output del comando, viene creata una nuova immagine del container per Docker contenente la nostra funzione. La funzione è pronta per essere chiamata, e ci sono due modi per farlo:
- utilizzando il comando Fn
invoke - richiamandola direttamente attraverso
http
Chiamata invoke Fn semplicemente emula l'operazione tramite HTTP per i test, il che è comodo per una rapida verifica:
$ fn invoke fnexo hellonode # chiamiamo la funzione hellonode dell'app fnexo
{"message":"Hello World"}Per poter 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, a quanto pare, l'URL della funzione corrisponde allo schema t/app/function, ma non completamente. Tramite HTTP, la funzione non viene chiamata direttamente, ma attraverso un cosiddetto trigger, che, come indica il termine, "attiva" la chiamata della funzione. I trigger sono definiti in `func.yml 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, semplificando tutto:
triggers:
- name: hellonode-trigger
type: http
source: /hellonode # corrisponde al nome della funzionePoi avviamo di nuovo la distribuzione della funzione e la chiamiamo dal nuovo trigger:
$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode
{"message":"Ciao Mondo"}Tutto funziona! È il momento di passare agli esperimenti pratici e pubblicare il nostro FaaS sul server!
Installazione dei servizi delle funzioni serverless sulla propria infrastruttura
Installiamo rapidamente una macchina virtuale utilizzando CLI Exoscale. Se non l'hai ancora configurata, puoi usare . È 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 ad 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 via ssh alla macchina virtuale 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.
La chiave ECDSA è SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q.
Sei sicuro di voler continuare a connetterti (sì/no)? sì
Attenzione: '185.19.30.175' (ECDSA) è stato aggiunto in modo permanente all'elenco degli host noti.
Benvenuto in Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)Poi installiamo Docker e il server Fn come già 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 per ricevere funzioni! Per la distribuzione delle funzioni sul server remoto utilizzeremo il comando deploy dal computer locale, escludendo il flag --local.
Inoltre, Fn richiede di specificare la posizione del server Fn e del registro Docker. Questi parametri possono essere impostati tramite le variabili di ambiente FN_API_URL e FN_REGISTRY rispettivamente, ma è offerto anche un modo più comodo per gestire facilmente la creazione e la gestione delle configurazioni per il deployment.
In termini di Fn, la configurazione per il deployment è chiamata context. Il seguente comando 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 passare al contesto appena creato in questo modo:
$ fn use context exoscale
Ora si sta utilizzando il contesto: exoscaleA partire da questo punto, la funzione di distribuzione 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) sulla posizione e sulla versione dell'ultima immagine contenente la tua funzione.
$ fn deploy --app fnexo . # eseguito sulla macchina locale dalla directory hellonode
Distribuzione della funzione in: \
Distribuzione di hellonode all'app: fnexo
Aggiornato alla versione 0.0.5
Creazione dell'immagine nfrankel\/hellonode:0.0.5 .Infine:
$ curl http:\/\/185.19.30.175:8080\/t\/fnexo\/hellonode
{"message":"Hello World"}
Ciclo di vita della funzione nel calcolo serverless basato su Fn
Vantaggi del calcolo serverless sulle proprie risorse
Il calcolo serverless è una soluzione comoda per l'implementazione rapida di parti indipendenti dell'applicazione che interagiscono con applicazioni o microservizi più complessi.
Questo è spesso associato al costo nascosto di vincolarsi a un fornitore scelto, il che, a seconda del caso d'uso specifico e del volume, può portare a costi più elevati e a una riduzione della flessibilità in futuro.
Le architetture multi-cloud e ibride risentono anche di questo, infatti ci si può facilmente trovare in una situazione in cui si desidera utilizzare il calcolo serverless, ma a causa delle politiche aziendali potrebbe non essere possibile.
Fn è abbastanza semplice da utilizzare, può fornire un'interfaccia FaaS quasi identica, con costi minimi. Eliminando qualsiasi vincolo di fornitore, può essere installato localmente o su qualsiasi fornitore di servizi cloud a tua scelta. Inoltre, c'è libertà nella scelta del linguaggio di programmazione.
Questo articolo presenta solo le basi di Fn, ma creare un proprio ambiente di esecuzione è abbastanza semplice, e l'architettura generale può essere ampliata utilizzando un bilanciatore di carico Fn, o posizionando Fn dietro un proxy per la protezione.
Fonte: habr.com
