— jeden z najbardziej zauważalnych trendów w dziedzinie przetwarzania w chmurze. Podstawową zasadą działania jest to, że za infrastrukturę nie odpowiada DevOps, lecz dostawca usług. Skalowanie zasobów automatycznie dostosowuje się do obciążenia i charakteryzuje się dużą zmiennością.
Kolejną wspólną cechą jest tendencja do minimalizowania i skupiania się na kodzie, dlatego przetwarzanie bezserwerowe jest czasami nazywane „funkcją jako usługą” (FaaS).
Historycznie, pierwszym dostawcą usług w chmurze, który oferował FaaS z AWS Lambda, był Amazon, stąd nazwa. Podobne usługi oferują również inni dostawcy usług w chmurze:
- Funkcje w chmurze firmy Google
- Funkcje Azure firmy Microsoft
Wszystkie te firmy oferują przetwarzanie bezserwerowe, automatyczne skalowanie i rozliczanie według zużycia, ale zamykają klientów w swoich zastrzeżonych produktach. Istnieją jednak darmowe i otwarte alternatywy umożliwiające zorganizowanie obliczeń bezserwerowych. Warto zauważyć:
- Platforma , opracowany w inkubatorze przez IBM,
- , jako część bogatego ekosystemu Spring Framework, który może być również używany jako fasada dla AWS Lambda, Azure Functions i OpenWhisk,
- , wspierany przez Oracle.
Wszystkie z nich są całkowicie niezależne od chmury, co oznacza, że można je zainstalować w dowolnej chmurze, w tym również w Twojej własnej, publicznej lub prywatnej, a oczywiście także w Exoscale.
Jak działa projekt Fn
Fn opiera się całkowicie na Dockerze i składa się z dwóch głównych komponentów:
- Program CLI przeznaczony do zarządzania wszystkimi aspektami infrastruktury Fn i interakcji z serwerem Fn,
- Serwer Fn jest standardową aplikacją spakowaną w kontenerze Docker.
Funkcje wdrażane w Fn są również wykonywane w oddzielnych kontenerach, co pozwala nam obsługiwać całkiem sporo języków programowania, takich jak… Clojure!
Argumenty funkcji przekazywane są do standardowego wejścia (STDIN), a wyniki zapisywane są do standardowego wyjścia (STDOUT). Jeśli argumenty lub wartości zwracane nie są prostymi wartościami (np. obiektem JSON), można je przekształcić za pomocą warstwy abstrakcji dostarczanej przez samą bibliotekę Fn w formie zestawu narzędzi do tworzenia funkcji (FDK).
Dla wygody dostępne są wbudowane zestawy szablonów ułatwiające wdrażanie FaaS w szerokiej gamie różnych języków i ich wersji (Go, różne wersje Java, Python itp.).
Utworzenie FaaS jest proste, postępuj zgodnie z poniższym diagramem:
- Wdróż funkcję za pomocą interfejsu wiersza poleceń Fn: Spowoduje to utworzenie pliku konfiguracji aplikacji dla Fn na podstawie wybranego szablonu.
- Wdrażamy własną funkcję, ponownie korzystając z CLI Fn: obraz kontenera zostaje umieszczony w określonym repozytorium, po czym serwer zostaje powiadomiony o istnieniu i lokalizacji tego obrazu.
Zasada dostarczania funkcji w Fn
Instalowanie i testowanie funkcji bezserwerowych lokalnie
Zacznijmy od instalacji Fn na komputerze lokalnym. Najpierw zainstalujmy Dockera, zgodnie z wymaganiami Fn. Zakłada to, że jesteśmy na Debian/Ubuntu:
$ sudo apt-get update
$ sudo apt-get install docker.ioLub użyj menedżera pakietów/kompilacji Docker dostosowanej do Twojego systemu. Następnie możesz przejść bezpośrednio do instalacji Fn CLI. Na przykład używając curl:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | shJeśli używasz systemu OSX z zainstalowanym Homebrew, możesz obrać inną drogę:
$ 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.7MBTeraz możemy wstępnie wdrożyć naszą funkcję za pomocą interfejsu wiersza poleceń. Dla uproszczenia wykorzystamy wbudowane środowisko wykonawcze, na przykład Node:
$ fn init --runtime node --trigger http hellonode
Creating function at: /hellonode
Function boilerplate generated.
func.yaml created.Zostanie utworzony nowy katalog. hellonode aby dalej rozwijać naszą funkcję Fn przy użyciu podstawowych plików konfiguracyjnych. W nowo utworzonym katalogu możesz utworzyć swoją aplikację, stosując się do standardów wybranego języka lub środowiska wykonawczego:
# Каталог с 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 tworzy początkową strukturę projektu, tworzy plik func.yaml, który zawiera niezbędne ustawienia dla Fn i ustawia szablon kodu w wybranym języku.
W przypadku środowiska wykonawczego Node oznacza to:
$ 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}
})Teraz szybko przetestujemy naszą funkcję lokalnie, aby zobaczyć jak wszystko działa.
Najpierw uruchomimy serwer Fn. Jak już wspomniano, serwer Fn jest kontenerem Docker, więc po uruchomieniu pobierze obraz z rejestru Docker.
$ fn start -d # запускаем локальный сервер в фоне
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
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5Aby uruchomić naszą funkcję, musimy ją „wdrożyć”. To wymaga имя приложения:W Fn wszystkie aplikacje muszą być określone jako przestrzenie nazw dla powiązanych funkcji.
Fn CLI wyszuka plik func.yaml w bieżącym katalogu, który zostanie użyty do skonfigurowania funkcji. Więc najpierw musisz przejść do naszego katalogu hellonode.
$ cd hellonode
$ fn deploy --app fnexo --local # выкатываем функцию локально, имя приложения - fnexo.
# параметр local не заливает образ в удаленный реестр,
# запуская его напрямую
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-triggerJak widać z wyniku polecenia, został utworzony nowy obraz kontenera Docker zawierający naszą funkcję. Funkcja jest gotowa do wywołania. Można to zrobić na dwa sposoby:
- używając polecenia Fn
invoke - dzwoniąc bezpośrednio przez
http
Zadzwoń invoke za pomocą Fn po prostu emuluje pracę przez HTTP w przypadku testów, co jest wygodne w przypadku szybkiego sprawdzania:
$ fn invoke fnexo hellonode # вызываем функцию hellonode приложения fnexo
{"message":"Hello World"}Aby wywołać funkcję bezpośrednio, musisz znać pełny adres URL:
$ curl http://localhost:8080/t/fnexo/hellonode-trigger
{"message":"Hello World"}Serwer Fn udostępnia swoje funkcje na porcie 8080, a adres URL funkcji wydaje się być zgodny ze schematem t/app/function, ale nie całkowicie. Za pośrednictwem protokołu HTTP funkcja nie jest wywoływana bezpośrednio, ale za pośrednictwem tzw. wyzwalacza, który, jak sama nazwa wskazuje, „rozpoczyna” wywołanie funkcji. Wyzwalacze są definiowane w `func.yml projekt:
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 триггераMożemy zmienić nazwę wyzwalacza tak, aby odpowiadała nazwie funkcji, co ułatwi sprawę:
triggers:
- name: hellonode-trigger
type: http
source: /hellonode # совпадает с именем функцииNastępnie ponownie uruchamiamy dostarczanie funkcji i wywołujemy ją z nowego wyzwalacza:
$ fn deploy --app fnexo hellonode --local
$ curl http://localhost:8080/t/fnexo/hellonode
{"message":"Hello World"}Wszystko działa! Czas przejść do eksperymentów w realnym świecie i opublikować nasz FaaS na serwerze!
Instalowanie usług funkcji bezserwerowych na własnej infrastrukturze
Zainstalujmy szybko maszynę wirtualną za pomocą Exoscale CLI. Jeśli jeszcze tego nie skonfigurowałeś, możesz tego użyć . To świetne narzędzie, które jeszcze bardziej zwiększy Twoją produktywność. Nie zapomnij skonfigurować reguły otwierającej port 8080 w grupie zabezpieczeń! Poniższe polecenia uruchomią czystą maszynę wirtualną gotową do hostowania naszych funkcji:
$ 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-securitygroupNastępnie możesz zalogować się przez SSH do maszyny wirtualnej i zainstalować zdalny serwer Fn:
$ 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)Następnie instalujemy Dockera i serwer Fn w taki sam sposób, jak zrobiliśmy to na komputerze lokalnym, i uruchamiamy serwer:
$ 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 jest gotowy do odbioru funkcji! Do ukierunkowanego transferu funkcji na serwer zdalny użyjemy polecenia deploy z komputera lokalnego, pomijając flagę --local.
Ponadto Fn wymaga podania lokalizacji serwera Fn i rejestru Docker. Parametry te można ustawić za pomocą zmiennych środowiskowych. FN_API_URL и FN_REGISTRY odpowiednio, ale oferuje również wygodniejszy sposób łatwego zarządzania tworzeniem i zarządzaniem konfiguracjami wdrożeń.
W terminologii Fn konfiguracja wdrożenia jest nazywana context. Następujące polecenie utworzy kontekst:
$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankelDostępne konteksty możesz przeglądać w następujący sposób:
$ fn list contexts
CURRENT NAME PROVIDER API URL REGISTRY
default default http://localhost:8080/
exoscale default http://185.19.30.175:8080 nfrankel
Następnie przełącz się na kontekst, który właśnie został utworzony w ten sposób:
$ fn use context exoscale
Now using context: exoscaleOd tego momentu funkcja Fn będzie pobierać obrazy Dockera przy użyciu wybranego konta w DockerHub (w moim przypadku nfrankel), a następnie powiadomić serwer zdalny (w tym przykładzie, http://185.19.30.175:8080) o lokalizacji i wersji najnowszego obrazu zawierającego Twoją funkcję.
$ fn deploy --app fnexo . # выполняется на локальной машине из каталога hellonode
Deploying function at: /.
Deploying hellonode to app: fnexo
Bumped to version 0.0.5
Building image nfrankel/hellonode:0.0.5 .Wreszcie:
$ curl http://185.19.30.175:8080/t/fnexo/hellonode
{"message":"Hello World"}
Cykl życia funkcji w obliczeniach bezserwerowych na podstawie Fn
Zalety lokalnego przetwarzania bezserwerowego
Przetwarzanie bezserwerowe to wygodne rozwiązanie umożliwiające szybką implementację niezależnych części aplikacji, które współpracują z bardziej złożonymi aplikacjami lub mikrousługami.
Często wynika to z ukrytych kosztów związanych z utrzymaniem dostawcy, co w zależności od konkretnego przypadku użycia i wolumenu może skutkować wyższymi kosztami i mniejszą elastycznością w przyszłości.
W tym przypadku cierpią także architektury multi-cloud i hybrydowe, ponieważ łatwo znaleźć się w sytuacji, w której chcielibyśmy skorzystać z przetwarzania bezserwerowego, ale ze względu na politykę korporacyjną może to być niemożliwe.
Fn jest stosunkowo łatwy w użyciu i może zapewnić praktycznie taki sam interfejs FaaS, przy niewielkim narzucie. Wyeliminuje to wszelkie uzależnienie od dostawcy. Możesz zainstalować program lokalnie lub u dowolnego, wybranego przez siebie dostawcy rozwiązań w chmurze. Istnieje również swoboda w wyborze języka programowania.
W tym artykule opisano jedynie podstawy funkcji Fn, jednak utworzenie własnego środowiska wykonawczego jest stosunkowo proste, a całą architekturę można jeszcze bardziej rozbudować, stosując moduł równoważenia obciążenia Fn lub umieszczając Fn za serwerem proxy w celu zapewnienia ochrony.
Źródło: www.habr.com
