— en af de mest markante tendenser inden for cloud computing. Den grundlæggende arbejdsprincip er, at infrastrukturen er et anliggende for tjenesteudbyderen, ikke DevOps. Ressourcestørrelsen justeres automatisk til belastningen og har en høj ændringshastighed.
En anden fælles karakteristika er tendensen til at minimere og fokusere koden, hvorfor serverless computing nogle gange kaldes "funktion som en tjeneste" (FaaS).
Historisk set var Amazon den første udbyder af cloud-tjenester, der tilbød FaaS med AWS Lambda, hvor navnet kommer fra. Andre cloud-tjenesteudbydere tilbyder også svarende alternativer:
- Cloud Functions fra Google
- Azure Functions fra Microsoft
Alle disse virksomheder tilbyder serverless computing, automatisk skalering og betaling kun for de faktisk anvendte ressourcer, men de binder samtidig kunderne til deres proprietære produkter. Der findes dog gratis open source-alternativer til at organisere serverless computing. Det er værd at bemærke:
- Platformen , der udvikles i et incubatorprojekt hos IBM,
- , som en del af det relativt rige økosystem i Spring Framework, der også kan bruges som et facad til AWS Lambda, Azure Functions og OpenWhisk,
- , støttet af Oracle.
Alle disse er helt uafhængige af cloud-løsninger, hvilket betyder, at de kan installeres i enhver cloud, herunder din egen, offentlige eller private, og selvfølgelig på Exoscale.
Hvordan Projekt Fn fungerer
Fn er helt baseret på Docker og består af to hovedkomponenter:
- En CLI-program, der er designet til at administrere alle aspekter af Fn-infrastrukturen og interagere med Fn-serveren,
- Selve Fn-serveren, en almindelig applikation pakket i en container til Docker.
Funktioner, der implementeres i Fn, køres også i separate containere, hvilket gør det muligt at understøtte mange programmeringssprog, eksempelvis… Clojure!
Argumenter til funktioner sendes til standard input (STDIN), og resultater skrives til standard output (STDOUT). Hvis argumenter eller returnerede værdier ikke er simple værdier (f.eks. JSON-objekt), kan de konverteres ved hjælp af det abstraheringslag, som Fn selv tilbyder i form af et funktion udviklingssæt (FDK).
For convenience, there are built-in template sets that facilitate the deployment of FaaS across a wide range of different languages and their versions (Go, various versions of Java, Python, etc.).
Creating FaaS is simple by following this scheme:
- Deploy the function using the Fn CLI: a configuration file for the application is created based on the chosen template.
- We release our function, again using the Fn CLI: the container image is placed in a repository, after which the server is notified of the existence and location of this image.
The principle of deploying functions in Fn
Local installation and testing of serverless functions
Let’s start by installing Fn on the local machine. First, install Docker as required by Fn. We assume we are on Debian/Ubuntu:
$ sudo apt-get update
$ sudo apt-get install docker.ioOr use the package manager/build of Docker according to your system. Then you can go straight to installing the Fn CLI. For example, using curl:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | shIf you are working on OSX with Homebrew installed, you can take a different route:
$ 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.7MBNow everything is ready for the initial deployment of our function using the CLI. For simplicity, we will use the built-in runtime environment, for example, Node:
$ fn init --runtime node --trigger http hellonode
Creating function at: /hellonode
Function boilerplate generated.
func.yaml created.A new directory will be created hellonode for further development of our Fn function with some basic configuration files. Inside the newly created directory, you can create your application following the standards of your chosen language or runtime environment:
# Каталог с 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 creates the initial project structure, generates the file func.yaml, containing the necessary settings for Fn, and sets the template for the code in the language you have chosen.
In the case of the Node runtime, this means:
$ 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}
})Now we will quickly test our function locally to see how everything works.
For starters, we will launch the Fn server. As mentioned, the Fn server is a Docker container, so after starting it will fetch the image from the Docker registry.
$ fn start -d # start the local server in the background
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
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5To deploy our function, it needs to be "rolled out". For that, it requires the application name: in Fn, all applications must be defined as namespaces for related functions.
The Fn CLI will search for a file func.yaml in the current directory, which will be used for function configuration. So first we need to navigate to our directory hellonode.
$ cd hellonode
$ fn deploy --app fnexo --local # deploy the function locally, application name - fnexo.
# the local parameter does not push the image to the remote registry,
# running it directly
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-triggerAs can be seen from the command output, a new Docker container image is being created that contains our function. The function is ready to be invoked, and we have two ways to do this:
- using the Fn command
invoke - invoking directly via
http
Kald invoke Fn simply emulates HTTP functionality for tests, which is convenient for quick checks:
$ fn invoke fnexo hellonode # invoke the hellonode function of the fnexo application
{"message":"Hello World"}To invoke the function directly, you need to know the full URL:
$ curl http://localhost:8080/t/fnexo/hellonode-trigger
{"message":"Hello World"}The Fn server provides its functions through port 8080, and it seems that the function URL follows the pattern t/app/function, but not entirely. Through HTTP, the function is not invoked directly, but through the so-called trigger, which as its name implies "triggers" the function call. Triggers are defined in `func.yml projektet:
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 # Trigger URLWe can change the trigger name to match the function name, which will simplify it all:
triggers:
- name: hellonode-trigger
type: http
source: /hellonode # matches the function nameThen we run the deployment of the function once again and invoke it from the new trigger:
$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode
{"message":"Hello World"}Det hele fungerer! Det er det rette tidspunkt at gå videre til praktiske eksperimenter og offentliggøre vores FaaS på serveren!
Installation af serverløse funktioner på egen infrastruktur
Lad os hurtigt installere en virtuel maskine ved hjælp af Exoscale CLI. Hvis du endnu ikke har konfigureret den, kan du benytte . Det er et fantastisk værktøj, der vil øge din produktivitet endnu mere. Husk, at du skal konfigurere en regel for at åbne port 8080 i Security Group! Følgende kommandoer vil starte en ren virtuel maskine, der er klar til at hoste vores funktioner:
$ 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-securitygroupHerefter kan du SSH ind på den virtuelle maskine og installere Fn fjernserveren:
$ 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)Installer derefter Docker og Fn-serveren ligesom før på den lokale maskine, og start 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.643Fn er klar til at modtage funktioner! For at sende funktioner til den fjernserver skal vi bruge kommandoen deploy fra den lokale computer, uden flaget --local.
Derudover kræver Fn, at der angives placeringen af Fn-serveren og Docker-registret. Disse indstillinger kan fastsættes via miljøvariabler FN_API_URL og FN_REGISTRY henholdsvis, men der tilbydes også en mere komfortabel metode til nem administration af oprettelse og styring af konfigurationer til udrulning.
I Fn-termer kaldes konfigurationen til udrulning context. Følgende kommando vil oprette en kontekst:
$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankelDu kan se de tilgængelige kontekster på følgende måde:
$ fn list contexts
CURRENT NAME PROVIDER API URL REGISTRY
default default http://localhost:8080/
exoscale default http://185.19.30.175:8080 nfrankel
Og skifte til den nyligt oprettede kontekst således:
$ fn use context exoscale
Now using context: exoscaleFra dette punkt vil Fn-funktioner begynde at indlæse Docker-billeder ved hjælp af den valgte konto på DockerHub (i mit tilfælde — nfrankel), hvorefter en meddelelse sendes til den fjerne server (i dette eksempel — http://185.19.30.175:8080) om placeringen og versionen af det nyeste billede, der indeholder din funktion.
$ fn deploy --app fnexo . # kører lokalt fra mappen hellonode
Udrulning af funktion på: \/.
Udrulning af hellonode til app: fnexo
Opgraderet til version 0.0.5
Bygger billede nfrankel\/hellonode:0.0.5 .Endelig:
$ curl http:\/\/185.19.30.175:8080\/t\/fnexo\/hellonode
{"message":"Hello World"}
Livscyklussen for en funktion i serverless computing baseret på Fn
Fordele ved serverless computing på dine egne ressourcer
Serverless computing er en praktisk løsning til hurtig implementering af uafhængige dele af applikationen, der interagerer med mere komplekse applikationer eller mikrotjenester.
Det er ofte forbundet med skjulte omkostninger ved at binde sig til en valgt udbyder, hvilket, afhængigt af den specifikke brugssituation og volumen, kan føre til højere udgifter og mindre fleksibilitet i fremtiden.
Multicloud- og hybridcloud-arkitekturer lider også under sådanne forhold, da man hurtigt kan finde sig selv i en situation, hvor man gerne vil bruge serverless computing, men på grund af virksomhedspolitik kan det være umuligt.
Fn er ganske nemt at arbejde med, kan give næsten samme FaaS-grænseflade med minimale omkostninger. Den fjerner enhver binding til udbyderen, kan installeres lokalt eller hos enhver ønsket cloud-løsning. Der er også frihed til at vælge programmeringssprog.
Artiklen præsenterer kun grundlaget for Fn, men det er ret let at oprette sit eget runtime-miljø, og den samlede arkitektur kan udvides ved at bruge Fn-loadbalancer eller ved at placere Fn bag en proxy for sikkerhed.
Kilde: habr.com
