— az egyik legkiemelkedőbb tendencia a felhőszámítástechnikában. A működés fő elve az, hogy az infrastruktúra nem a DevOps-ok, hanem a szolgáltató felelőssége. Az erőforrások automatikusan igazodnak a terheléshez és magas sebességgel skálázhatók.
Egy másik közös jellemző a kód minimalizálása és fókuszálása, ezért a szerver nélküli számítástechnikát néha "funkció mint szolgáltatás" (FaaS) néven is említik.
Történelmileg az első felhőszolgáltató, aki FaaS-t kínált az AWS Lambda révén, az Amazon volt, ahonnan a név is származik. Más felhőszolgáltatók is kínálnak analóg szolgáltatásokat:
- Google Cloud Functions
- Microsoft Azure Functions
Mindegyik cég szerver nélküli számítástechnikát, automatikus skálázást és csak a ténylegesen használt erőforrásokért történő fizetést kínál, de ezzel együtt ügyfeleiket saját zárt termékükhöz kötik. Ennek ellenére léteznek ingyenes, nyílt forráskódú alternatívák a szerver nélküli számítástechnika szervezésére. Érdemes megemlíteni:
- Az , amelyet az IBM inkubátorában fejlesztenek,
- , a Spring Framework gazdag ökoszisztémájának részeként, amely AWS Lambda, Azure Functions és OpenWhisk interfészeként is használható,
- , az Oracle támogatásával.
Mindannyian teljesen függetlenek a felhőktől, tehát bármely felhőbe telepíthetők, beleértve a saját felhőjét, nyilvános vagy privát, és természetesen az Exoscale-ba is.
Hogyan működik az Fn projekt
Az Fn teljes mértékben a Dockerre épül, két fő komponensből áll:
- CLI program, amely az Fn infrastruktúrájának minden aspektusának kezelésére szolgál, és kommunikál az Fn szerverrel,
- Magának az Fn-nek a szervere, egy hagyományos alkalmazás, amely Docker konténerbe van csomagolva.
Az Fn-ben telepített funkciók szintén külön konténerekben futnak, ami lehetővé teszi számos programozási nyelv támogatását, például… Clojure!
A funkciók argumentumai a szabványos bemenetre (STDIN) kerülnek, az eredmények a szabványos kimenetre (STDOUT) íródnak. Ha az argumentumok vagy a visszatérési értékek nem egyszerű értékek (például JSON objektum), akkor a Fn által biztosított funkciók fejlesztői készlete (FDK) révén alakíthatók át.
A kényelem érdekében beépített sablonsorozatok állnak rendelkezésre, amelyek megkönnyítik a FaaS telepítését különböző nyelveken és azok verzióin (Go, különböző Java verziók, Python stb.).
FaaS létrehozása egyszerű, ha követjük ezt a sémát:
- A funkció telepítése a CLI Fn használatával: egy alkalmazáskonfiguráló fájl jön létre a Fn számára, amely a választott sablonra épül.
- A saját funkciónk telepítése szintén a CLI Fn használatával: a konténer képét egy adott tárolóba helyezzük, majd a szerver értesül a kép létezéséről és elhelyezéséről.
A funkciók Fn általi szállításának elve
Helyi telepítés és tesztelés szerver nélküli funkciók esetén
Kezdjük el a Fn telepítését a helyi gépen. Először is a Dockert kell telepíteni, ahogy azt a Fn megköveteli. Feltételezzük, hogy Debian/Ubuntu-t használunk:
$ sudo apt-get update
$ sudo apt-get install docker.ioVagy használhatja a csomagkezelőt / a Docker telepítését a rendszerének megfelelően. Ezután áttérhetünk a Fn CLI telepítésére. Például curl segítségével:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | shHa OSX-en dolgozik telepített Homebrew-jal, más utat is választhat:
$ brew install fn
==> Letöltés https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz
==> Letöltés innen: 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 fájl, 16.7MBMost minden készen áll a funkciónk első telepítésére a CLI segítségével. A könnyűség kedvéért beépített futtatókörnyezetet használunk, például Node-ot:
$ fn init --runtime node --trigger http hellonode
Funkció létrehozva itt: /hellonode
Funkció alapanyag generálva.
func.yaml létrehozva.Új mappa jön létre hellonode a Fn funkciónk további fejlesztéséhez alapvető konfiguráló fájlokkal. Az újonnan létrehozott mappán belül létrehozhatja alkalmazását, követve a választott nyelv vagy futtatókörnyezet szabványait:
# Каталог с 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.javaA Fn létrehozza a projekt kezdeti struktúráját, létrehozza a fájlt func.yaml, amely a Fn számára szükséges beállításokat tartalmaz, és létrehozza a kiválasztott nyelvhez tartozó kód sablonját.
Node futtatókörnyezet esetén ez azt jelenti:
$ 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}
})Most gyorsan tesztelni fogjuk a funkciónkat helyben, hogy lássuk, hogyan működik minden.
Először elindítjuk a Fn szervert. Amint már említettük, a Fn szerver egy Docker konténer, tehát a futtatás után automatikusan letölti a képet a Docker registry-ből.
$ fn start -d # lokális szerver háttérben való indítása
Nincs 'fnproject/fnserver:latest' kép helyben
latest: Letöltés a fnproject/fnserver-ből
ff3a5c916c92: Letöltés befejezve
1a649ea86bca: Letöltés befejezve
ce35f4d5f86a: Letöltés befejezve
...
Állapot: Újabb kép letöltve a fnproject/fnserver:latest-hez
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5A funkciónk elindításához azt "ki kell vinni". Ehhez szükséges az alkalmazás neve: a Fn-ben minden alkalmazást névtérként kell megadni a kapcsolódó funkciókhoz.
A Fn CLI fájlt fog keresni func.yaml a jelenlegi mappában, amely a funkció beállításához használható. Tehát először lépjünk át a mappánkba hellonode.
$ cd hellonode
$ fn deploy --app fnexo --local # helyben indítja a funkciót, az alkalmazás neve - fnexo.
# a local paraméter nem tölti fel a képet a távoli registry-be,
# közvetlenül indítva
Hellonode telepítése az alkalmazáshoz: fnexo
Frissítve: 0.0.2 verzióra
Kép építése nfrankel/hellonode:0.0.3 .
Funkció frissítése: hellonode a nfrankel/hellonode:0.0.3 képpel...
Sikeresen létrehozva az alkalmazás: fnexo
Sikeresen létrehozva a funkció: hellonode a nfrankel/hellonode:0.0.3-al
Sikeresen létrehozva a trigger: hellonode-triggerAmint a parancs kimenetéből látható, egy új Docker konténer kép készül a funkciónk számára. A funkció készen áll a hívásra, és két módon hívhatjuk meg:
- használva a Fn parancsot
invoke - közvetlenül hívva
http
Hívás invoke A Fn egyszerűen emulálja a HTTP működést a teszteléshez, ami kényelmes a gyors ellenőrzéshez:
$ fn invoke fnexo hellonode # hívja a hellonode funkciót az fnexo alkalmazásból
{"message":"Hello World"}Ahhoz, hogy közvetlenül meghívjuk a funkciót, ismernünk kell a teljes URL-t:
$ curl http://localhost:8080/t/fnexo/hellonode-trigger
{"message":"Hello World"}A Fn szerver a funkcióit a 8080-as porton kínálja, és látszólag a funkció URL-je az alábbi séma szerint van megadva: t/app/function, de nem teljesen. HTTP-n keresztül a funkciót nem közvetlenül hívjuk, hanem egy úgynevezett triggeren keresztül, amely a nevéből adódóan "elindítja" a funkció hívását. A triggereket a következőben definiálják: `func.yml a projektre:
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 # a trigger URL-jeMegváltoztathatjuk a trigger nevét, hogy megfeleljen a funkció nevének, ezzel egyszerűsítjük a dolgokat:
triggers:
- name: hellonode-trigger
type: http
source: /hellonode # megegyezik a funkció nevévelEzután ismét elindítjuk a funkciószállítást, és meghívjuk a funkciót az új triggerből:
$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode
{"message":"Helló Világ"}Minden működik! Itt az ideje, hogy elkezdjünk a valós kísérletezéssel és közzétegyük a FaaS-t a szerveren!
A szerver nélküli funkciók beállítása a saját infrastruktúránkon
Gyorsan telepítsük a virtuális gépet az Exoscale CLI használatával. Ha még nem állítottad be, használhatod . Ez egy nagyszerű eszköz, amely még tovább növeli a termelékenységedet. Ne felejtsd el, hogy be kell állítani a szabályt a 8080-as port megnyitásához a Biztonsági Csoportban! A következő parancsok elindítanak egy tiszta virtuális gépet, amely készen áll a funkcióink elhelyezésé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-securitygroupEzután ssh-n keresztül beléphetünk a virtuális gépre, és telepíthetjük a távoli Fn szervert:
$ exo ssh fn-server
A gazdagép '185.19.30.175 (185.19.30.175)' hitelessége nem állapítható meg.
Az ECDSA kulcsujjlenyomat: SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q.
Biztos benne, hogy folytatja a csatlakozást (igen/nem)? igen
Figyelmeztetés: '185.19.30.175' (ECDSA) véglegesen hozzáadva a megismert gazdagépek listájához.
Üdvözöljük az Ubuntu 18.04 LTS-en (GNU/Linux 4.15.0-20-generic x86_64)Ezután telepítjük a Dockert és a Fn szervert is, ahogyan azt már a helyi gépen is tettük, elindítjuk a szervert:
$ 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.643A Fn készen áll a funkciók fogadására! A távoli szerverre való funkciók célzott átviteléhez a parancsot fogjuk használni after_deploy a helyi számítógépről, elhagyva a zászlót --local.
Ezen kívül a Fn megköveteli a Fn szerver és a Docker regisztráció helyének megadását. Ezeket a beállításokat környezeti változókon keresztül állíthatjuk be FN_API_URL és FN_REGISTRY illetve, de van egy kényelmesebb módja is a konfigurációk egyszerű kezelése érdekében a telepítésekhez.
A Fn kifejezéseivel a telepítési konfigurációt contextaz alábbiaként hívják.
A következő parancs létrehozza a kontextust:$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankel
Az elérhető kontextusokat így tekintheted meg:
$ fn list contextsCURRENT NAME PROVIDER API URL REGISTRY default default http://localhost:8080/ exoscale default http://185.19.30.175:8080 nfrankel
És a frissen létrehozott kontextusra a következőképpen válthatsz:
$ fn use context exoscale
Most használva a: exoscale kontextustEzt a pontot kezdve az Fn funkciók szállítása Docker képek betöltését fogja végezni, a kiválasztott DockerHub fiókot használva (az én esetemben — nfrankel), majd értesíti a távoli szervert (ebben a példában — http://185.19.30.175:8080) a legfrissebb kép helyéről és verziójáról, amely tartalmazza a funkcióját.
$ fn deploy --app fnexo . # helyben végrehajtva a hellonode könyvtárból
Funkció telepítése a következőre: \/.
A hellonode telepítése az app-ra: fnexo
Frissítve a 0.0.5 verzióra
Kép építése nfrankel\/hellonode:0.0.5 .Végül:
$ curl http:\/\/185.19.30.175:8080\/t\/fnexo\/hellonode
{"message":"Hello World"}
A funkció életciklusa az Fn alapú szerver nélküli számításokban
A szerver nélküli számítások előnyei saját infrastruktúrákon
A szerver nélküli számítás egy kényelmes megoldás az alkalmazás független részeinek gyors bevezetésére, amelyek komplexebb alkalmazásokkal vagy mikroszolgáltatásokkal működnek együtt.
Gyakran ez a kiválasztott szolgáltatóhoz való kötődés rejtett költségeivel kapcsolatos, ami a konkrét használati eset és mennyiség szerint magasabb költségeket és a jövőbeli rugalmasság csökkenését okozhatja.
A több felhős és hibrid felhőarchitektúrák is szenvednek ebben az esetben, mivel könnyen előfordulhat, hogy szeretnénk használni a szerver nélküli számítást, de a vállalati politika miatt ez lehetetlen.
Az Fn elég egyszerűen használható, szinte ugyanolyan FaaS felületet kínál, minimális költségekkel. Megszabadít a szolgáltatói kötődésektől, telepíthető helyben vagy bármely általad választott felhőszolgáltatónál. A programozási nyelv választásában is szabadságod van.
A cikk csak az Fn alapjait mutatja be, de saját futtatási környezet létrehozása elég egyszerű, és az általános architektúrát szélesebben is ki lehet terjeszteni Fn terheléselosztó használatával, vagy az Fn proxy mögé történő elhelyezésével a védelem érdekében.
Forrás: habr.com
