Vi bygger vår egen serverless basert på Fn

Serverløse beregninger — en av de mest bemerkelsesverdige trendene innen skyberegninger. Hovedprinsippet er at infrastrukturen ikke er et ansvar for DevOps, men for tjenesteleverandøren. Ressursene skaleres automatisk til belastningen og har en høy grad av endringshastighet.

En annen vanlig egenskap er trenden mot minimalisering og fokusering av koden, derfor blir serverløse beregninger noen ganger kalt «funksjon som tjeneste» (FaaS).

Historisk sett var Amazon den første leverandøren av skybaserte tjenester som tilbød FaaS med AWS Lambda, og det er her navnet stammer fra. Andre skybaserte tjenesteleverandører tilbyr også sine egne varianter:

• Cloud Functions fra Google
• Azure Functions fra Microsoft

Alle disse selskapene tilbyr serverløse beregninger, automatisk skalering og betaling for faktisk brukte ressurser, men de binder også kundene til sitt proprietære produkt. Det finnes imidlertid gratis alternativer med åpen kildekode for å organisere serverløse beregninger. Det er verdt å merke seg:

• Plattformen Apache OpenWhisk, utviklet av IBM i et inkubatorprogram,
• Spring Cloud Functions, som en del av det ganske rike økosystemet til Spring Framework, som også kan brukes som et fasade på AWS Lambda, Azure Functions og OpenWhisk,
• Prosjekt Fn, støttet av Oracle.

Alle disse er helt uavhengige av skyer, det vil si at de kan installeres i hvilken som helst sky, inkludert din egen, offentlig eller privat, og selvfølgelig i Exoscale.

Hvordan Fn prosjektet fungerer

Fn er helt basert på Docker og består av to hovedkomponenter:

• CLI-programmet, som er ment å administrere alle aspekter av Fn-infrastrukturen, og som interagerer med Fn-serveren,
• Selve Fn-serveren, et vanlig program pakket i en Docker-kontainer.

Funksjoner som distribueres i Fn kjøres også i separate beholdere, noe som gjør det mulig å støtte en rekke programmeringsspråk, for eksempel… Clojure!

Funksjonsargumenter blir sendt til standard input (STDIN), resultatene skrives til standard output (STDOUT). Hvis argumentene eller returverdiene ikke er enkle verdier (for eksempel JSON-objekter) — kan de bli konvertert ved hjelp av et abstraksjonslag som tilbys av Fn i form av et funksjonsutviklingssett (FDK).

For brukervennlighet tilbys innebygde malsett som forenkler distribusjonen av FaaS på en omfattende liste over forskjellige språk og deres versjoner (Go, forskjellige versjoner av Java, Python osv.).

Å opprette FaaS er enkelt, følg denne planen:

• Distribuer funksjonen ved hjelp av CLI Fn: En konfigurasjonsfil for applikasjonen opprettes for Fn, basert på den valgte malen.
• Distribuerer egen funksjon, igjen ved hjelp av CLI Fn: Docker-imaget plasseres i et lager, hvoretter serveren blir informert om eksistensen og plasseringen av dette imaget.

Prinsipp for distribusjon av funksjoner i Fn

Lokal installasjon og testing av serverløse funksjoner

La oss begynne å installere Fn på den lokale maskinen. Først installeres Docker, slik det kreves av Fn. Vi antar at vi bruker Debian/Ubuntu:

$ sudo apt-get update
$ sudo apt-get install docker.io

Eller bruk pakkeadministratoren/byggingen av Docker i henhold til systemet ditt. Deretter kan vi gå rett til installasjonen av Fn CLI. For eksempel, med curl:

$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh

Hvis du jobber på OSX med installert Homebrew, kan du ta en annen rute:

$ brew install fn

==> Downloader https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz
==> Downloader fra https://akamai.bintray.com/b1/b1767fb00e2e69fd9da73427d0926b1d1d0003622f7ddc0dd3a899b2894781ff?__gda__=exp=1538038849~hmac=c702c9335e7785fcbacad1f29afa61244d02f2eebb
######################################################################## 100.0%
==> Hellende fn-0.5.8.high_sierra.bottle.tar.gz
  /usr/local/Cellar/fn/0.5.8: 5 filer, 16.7MB

Nå er alt klart for den første distribusjonen av funksjonen vår ved hjelp av CLI. For enkelhets skyld vil vi bruke det innebygde miljøet for å kjøre, for eksempel Node:

$ fn init --runtime node --trigger http hellonode

Oppretter funksjon i: /hellonode
Funksjonens mal er generert.
func.yaml er opprettet.

En ny katalog vil bli opprettet hellonode for videre utvikling av Fn-funksjonen vår med noen grunnleggende konfigurasjonsfiler. Inne i den nyskapte katalogen kan du lage applikasjonen din, i henhold til standardene for det valgte språket eller kjøringsmiljøet:

# Каталог с 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.java

Fn oppretter en grunnleggende prosjektstruktur og lager filen func.yaml, som inneheld nødvendige installasjonar for Fn, og set opp mal for koden på språket du valde.

I tilfelle av Node-runtime, betyr dette:

$ 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}
})

No skal vi raskt sjekke funksjonen vår lokalt for å sjå korleis alt fungerer.

For å begynne med, skal vi starte Fn-serveren. Som tidlegare nemnt, er Fn-serveren ein Docker-container, så den vil gå og ta bildet frå Docker-registeret etter at den er starta.

$ fn start -d                    # startar lokal server i bakgrunnen

Unable to find image 'fnproject/fnserver:latest' locally
latest: Pulling from fnproject/fnserver
ff3a5c916c92: Pull complete
1a649ea86bca: Pull complete
ce35f4d5f86a: Pull complete

...

Status: Downloaded newer image for fnproject/fnserver:latest
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5

For å rulle ut funksjonen vår, må den «deployas». Dette krev namn på applikasjonen: i Fn må alle applikasjonar definerast som namnrom for tilknyttede funksjonar.

Fn CLI vil leita etter fila func.yaml i den gjeldande katalogen, som vil bli brukt til å konfigurere funksjonen. Så vi må først gå til katalogen vår hellonode.

$ cd hellonode
$ fn deploy --app fnexo --local  # ruller ut funksjonen lokalt, applikasjonsnavnet - fnexo.
                                 # parameteren local lastar ikkje opp bildet til fjernregisteret,
                                 # men køyre det direkte

Deploying hellonode to app: fnexo
Bumped to version 0.0.2
Building image nfrankel/hellonode:0.0.3 .
Updating function hellonode using image nfrankel/hellonode:0.0.3...
Successfully created app:  fnexo
Successfully created function: hellonode with nfrankel/hellonode:0.0.3
Successfully created trigger: hellonode-trigger

Som ein kan sjå frå utskrifta av komandoen, blir det laga eit nytt containerbilde for Docker som inneheld funksjonen vår. Funksjonen er klar til å bli kalla, og vi har to måtar å gjere dette på:

• ved å bruke kommandoen Fn invoke
• også ved å kalle direkte gjennom http

Kall invoke gjennom Fn simulerer eigentleg HTTP-arbeid for testing, noko som er praktisk for raske sjekkar:

$ fn invoke fnexo hellonode      # kallar funksjonen hellonode i applikasjonen fnexo

{"message":"Hello World"}

For å kalle funksjonen direkte, må ein kjenne den fullstendige URL-en:

$ curl http://localhost:8080/t/fnexo/hellonode-trigger

{"message":"Hello World"}

Fn-serveren gir funksjonane sine gjennom port 8080, og URL-en for funksjonen ser ut til å følge mønsteret t/app/function, men ikkje heilt. Gjennom HTTP blir funksjonen ikkje kalla direkte, men gjennom det såkalla triggeret, som gjennom namnet sitt «utløysar» kall av funksjonen. Triggerar blir definert i `func.yml prosjektet:

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 til triggeren

Vi kan endre navnet på triggeren for å samsvare med funksjonsnavnet, dette vil forenkle alt:

triggers:
- name: hellonode-trigger
  type: http
  source: /hellonode    # samsvar med funksjonsnavnet

Så starter vi distribusjonen av funksjonen igjen og kaller den fra den nye triggeren:

$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode

{"message":"Hello World"}

Alt fungerer! Det er på tide å gå videre med eksperimentene og publisere vår FaaS på serveren!

Installerer serverløse funksjoner på din egen infrastruktur

La oss raskt sette opp en virtuell maskin ved hjelp av Exoscale CLI. Hvis du ikke har satt det opp ennå – kan du bruke vår guide for rask oppstart. Dette er et flott verktøy som vil øke produktiviteten din ytterligere. Ikke glem å sette opp en regel for å åpne port 8080 i sikkerhetsgruppen! Følgende kommandoer vil starte en ren virtuell maskin, klar for hosting av funksjonene våre:

$ 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-securitygroup

Deretter kan du logge inn via ssh på den virtuelle maskinen og installere Fn-serveren:

$ exo ssh fn-server

The authenticity of host '185.19.30.175 (185.19.30.175)' can't be established.
ECDSA key fingerprint is SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '185.19.30.175' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)

Deretter installerer vi Docker og Fn-serveren på samme måte som vi gjorde på den lokale maskinen, og starter serveren:

$ 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.643

Fn er klart til å motta funksjoner! For å målrette funksjoner til den eksterne serveren, vil vi bruke kommandoen deploy fra den lokale datamaskinen, og hopper over flagget --local.

I tillegg krever Fn at du angir plasseringen av Fn-serveren og Docker-registeret. Disse parameterne kan settes via miljøvariabler FN_API_URL og FN_REGISTRY henholdsvis, men det tilbys også en mer praktisk måte for enkel administrasjon av konfigurasjoner for distribusjon.

I Fn-termer er konfigurasjonen for distribusjon kalt context. Den følgende kommandoen vil opprette konteksten:

$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankel

Du kan se tilgjengelige kontekster slik:

$ fn list contexts

NÅVÆRENDE NAVN      LEVERANDØR      API URL                      REGISTER
    default       default       http://localhost:8080/
    exoscale      default       http://185.19.30.175:8080    nfrankel

For å bytte til konteksten som nettopp ble opprettet, gjør du slik:

 $ fn use context exoscale

 Nå bruker vi konteksten: exoscale

Fra dette punktet vil Fn-funksjonsleveransen laste ned Docker-bilder ved å bruke den valgte kontoen på DockerHub (i mitt tilfelle — nfrankel), hvoretter den vil varsle den eksterne serveren (i dette eksemplet — http://185.19.30.175:8080) om plasseringen og versjonen av det siste bildet som inneholder funksjonen din.

$ fn deploy --app fnexo .   # kjøres på lokal maskin fra mappen hellonode

Distribuerer funksjonen til: /.
Distribuerer hellonode til app: fnexo
Oppgradert til versjon 0.0.5
Bygger bilde nfrankel/hellonode:0.0.5 .

Til slutt:

$ curl http://185.19.30.175:8080/t/fnexo/hellonode

{"message":"Hello World"}

Livssyklus for funksjoner i serverløs beregning basert på Fn

Fordeler med serverløs beregning på egne ressurser

Serverløs beregning er en praktisk løsning for rask implementering av uavhengige deler av applikasjonen, som samhandler med mer komplekse applikasjoner eller mikrotjenester.

Ofte er dette knyttet til skjulte kostnader ved å forplikte seg til en valgt leverandør, noe som, avhengig av spesifikke bruksområder og volum, kan føre til høyere kostnader og lavere fleksibilitet i fremtiden.

Multisky- og hybridcloud-arkitekturer lider også i slike tilfeller, da man gjerne kan finne seg i en situasjon der man ønsker å bruke serverløs beregning, men på grunn av bedriftspolitikk kan dette være umulig.

Fn er ganske enkelt å bruke, kan gi nesten samme FaaS-grensesnitt, med små kostnader. Det fjerner alle forpliktelser til leverandører, og kan installeres lokalt eller hos hvilken som helst ønsket leverandør av skybaserte løsninger. Det finnes også frihet til å velge programmeringsspråk.

Artikkelen presenterer bare grunnlagene for Fn, men å lage ditt eget kjøringsmiljø er ganske enkelt, og den generelle arkitekturen kan utvides med bruk av en Fn-lastbalanserer, eller ved å plassere Fn bak en proxy for beskyttelse.

Kilde: habr.com