🥇Създаване на собствен serverless на базата на Fn

Изграждане на собствен serverless на базата на Fn

Безсървърни изчисления — една от най-забележимите тенденции в облачните изчисления. Основният принцип на работа е, че инфраструктурата е грижа не на DevOps екипите, а на доставчика на услуги. Масштабиране на ресурсите автоматично се приспособява към натоварването и притежава висока скорост на промяна.

Друга обща черта е тенденцията към минимизиране и фокусиране на кода, поради което безсървърните изчисления понякога се наричат «функция като услуга» (FaaS).

Исторически първият доставчик на облачни услуги, предложил FaaS с AWS Lambda, беше Amazon, откъдето започна и това название. Други облачни доставчици на услуги също предлагат аналози:

Cloud Functions от Google
Azure Functions от Microsoft

Всички тези компании предоставят безсървърни изчисления, автоматично масштабиране и заплащане само за фактически изразходваните ресурси, но в същото време свързват клиентите със собствения си собствен продукт. Въпреки това съществуват безплатни алтернативи с отворен код за организиране на безсървърни изчисления. Струва си да се отбележи:

Платформата Apache OpenWhisk, разработвана в инкубатор от IBM,
Spring Cloud Functions, като част от доста богата екосистема на Spring Framework, която също може да се използва като фасада за AWS Lambda, Azure Functions и OpenWhisk,
Проект Fn, поддържан от Oracle.

Всички те са напълно независими от облаците, т.е. инсталират се в било кой облак, включително вашия собствен, публичен или частен, и разбира се в Exoscale.

Как е устроен проект Fn

Fn напълно се основава на Docker и се състои от два основни компонента:

CLI програма, предназначена за управление на всички аспекти на инфраструктурата Fn, и взаимодействието с сървъра Fn,
Същинският сървър Fn, обикновено приложение, опаковано в контейнер за Docker.

Функциите, разгръщани в Fn, също така се изпълняват в отделни контейнери, което позволява поддържане на много езици за програмиране, например… Clojure!

Аргументите на функциите се предават на стандартния вход (STDIN), резултатите се записват на стандартния изход (STDOUT). Ако аргументите или връщаните стойности не са прости стойности (например JSON обект) — те могат да бъдат преобразувани чрез слоя абстракция, предоставен от самия Fn под формата на комплект за разработка на функции (FDK).

За удобство се предлагат вградени набори от шаблони, които улесняват разгръщането на FaaS на широк спектър от различни езици и техните версии (Go, различни версии Java, Python и т.н.).

Създаването на FaaS е лесно, следвайки тази схема:

Разгръщаме функцията с помощта на CLI Fn: създава се конфигурационен файл за приложението за Fn, основаващ се на избрания шаблон.
Изпълняваме собствена функция, отново с помощта на CLI Fn: контейнерният образ се поставя в определен репозиторий, след което сървърът се уведомява за съществуването и местоположението на този образ.

Изграждане на собствен serverless на базата на Fn
Принцип на доставка на функции в Fn

Локална инсталация и тестване на безсървърни функции

Нека започнем с инсталацията на Fn на локалната машина. Първо, инсталираме Docker, както изисква Fn. Предполага се, че сме на Debian/Ubuntu:

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

Или можете да използвате пакетен мениджър/инсталация на Docker съобразно вашата система. След това можем да преминем директно към инсталацията на Fn CLI. Например, с помощта на curl:

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

Ако работите на OSX с инсталиран Homebrew, можете да следвате друг път:

$ brew install fn

==> Изтегляне https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz
==> Изтегляне от https://akamai.bintray.com/b1/b1767fb00e2e69fd9da73427d0926b1d1d0003622f7ddc0dd3a899b2894781ff?__gda__=exp=1538038849~hmac=c702c9335e7785fcbacad1f29afa61244d02f2eebb
######################################################################## 100.0%
==> Изливане fn-0.5.8.high_sierra.bottle.tar.gz
  /usr/local/Cellar/fn/0.5.8: 5 файла, 16.7MB

Сега всичко е готово за първоначалното разгръщане на нашата функция с помощта на CLI. За удобство, ще използваме вградена среда за стартиране, например Node:

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

Създаване на функция в: /hellonode
Генериран шаблон на функцията.
func.yaml е създаден.

Ще бъде създаден нов каталог hellonode за по-нататъшно разработване на нашата функция Fn с някои основни конфигурационни файлове. Вътре в новосъздадения каталог можете да създадете вашето приложение, следвайки стандартите на избрания от вас език или среда за изпълнение:

# Каталог с 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 създава начална структура на проекта, създава файл func.yaml, съдържащ необходимите настройки за Fn, и поставя шаблон за кода на езика, който сте избрали.

В случай на среда за изпълнение Node това означава:

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

Сега бързо ще проверим нашата функция локално, за да видим как всичко работи.

Първо, ще стартираме сървъра Fn. Както беше споменато, сървърът Fn представлява Docker контейнер, следователно след стартиране ще вземе образа от Docker регистъра.

$ fn start -d                    # стартираме локалния сървър на заден план

Не може да бъде намерен образ 'fnproject/fnserver:latest' локално
latest: Изтегля от fnproject/fnserver
ff3a5c916c92: Изтеглянето е завършено
1a649ea86bca: Изтеглянето е завършено
ce35f4d5f86a: Изтеглянето е завършено

...

Статус: Изтеглен е нов образ за fnproject/fnserver:latest
668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5

За да стартираме нашата функция, тя трябва да бъде "изпратена". За това е необходимo име на приложението: в Fn всички приложения трябва да бъдат зададени като пространства от имена за свързаните функции.

Fn CLI ще търси файл func.yaml в текущата директория, който ще се използва за конфигуриране на функцията. Така че първо трябва да отидем в нашата директория hellonode.

$ cd hellonode
$ fn deploy --app fnexo --local  # изпращаме функция локално, името на приложението е fnexo.
                                 # параметър local не качва образа в отдалечен регистър,
                                 # стартира го директно

Изпращане на hellonode към приложението: fnexo
Увеличено до версия 0.0.2
Създаване на образ nfrankel/hellonode:0.0.3 .
Актуализиране на функцията hellonode, използвайки образ nfrankel/hellonode:0.0.3...
Успешно създадено приложение:  fnexo
Успешно създадена функция: hellonode с nfrankel/hellonode:0.0.3
Успешно създаден тригер: hellonode-trigger

Както може да се види от изхода на командата, се създава нов образ на контейнер за Docker, съдържащ нашата функция. Функцията е готова за извикване и имаме два начина да направим това:

използвайки командата Fn invoke
извиквайки директно през http

Извикването invoke чрез Fn просто еймулира работата по HTTP за тестове, което е удобно за бърза проверка:

$ fn invoke fnexo hellonode      # извикваме функция hellonode на приложението fnexo

{"message":"Hello World"}

За да извикате функцията директно, трябва да знаете пълния URL:

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

{"message":"Hello World"}

Сървърът Fn предоставя своите функции през порт 8080 и, както изглежда, URL адресът на функцията отговаря на схемата t/app/function, но не напълно. През HTTP функцията не се извиква директно, а чрез т.нар. тригер, който според името си "запуска" извикването на функцията. Триггерите се определят в `func.yml проекта:

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 на тригера

Можем да променим името на тригера, за да съответства на името на функцията, което ще опрости всичко:

triggers:
- name: hellonode-trigger
  type: http
  source: /hellonode    # съответства на името на функцията

След това отново стартираме внедряването на функцията и я извикваме от новия тригер:

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

{"message":"Здравейте, свят"}

Всичко работи! Най-добре е да преминем към практически експерименти и да публикуваме нашия FaaS на сървъра!

Инсталиране на безсървърни функции на собствена инфраструктура

Нека бързо настроим виртуална машина, използвайки CLI Exoscale. Ако все още не сте я настроили — можете да се възползвате от нашето ръководство за бърз старт. Това е страхотен инструмент, който ще повиши вашата продуктивност. Не забравяйте да настроите правило за отваряне на порт 8080 в Security Group! Следващите команди ще стартират чиста виртуална машина, готова за разполагане на нашите функции:

$ 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

След това можете да влезете по ssh на виртуалната машина и да инсталирате отдалечения сървър Fn:

$ exo ssh fn-server

Автентичността на хоста '185.19.30.175 (185.19.30.175)' не може да бъде установена.
ECDSA ключовият отпечатък е SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q.
Сигурни ли сте, че искате да продължите с връзката (да/не)? да
Предупреждение: Постоянно добавен '185.19.30.175' (ECDSA) в списъка на известни хостове.
Добре дошли в Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)

След това инсталираме Docker и сървър Fn по същия начин, както вече е правено на локалната машина, стартираме сървъра:

$ 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 е готов за получаване на функции! За целевата доставка на функции на отдалечения сървър ще използваме командата deploy от локалния компютър, пропускайки флага --local.

Освен това, Fn изисква да укажете разместна информация за сървър Fn и Docker регистратора. Тези параметри могат да бъдат установени чрез променливи на средата FN_API_URL и FN_REGISTRY съответно, но се предлага и по-удобен начин за лесно управление на създаването и управлението на конфигурации за разполагане.

В терминологията на Fn, конфигурацията за разполагане се нарича контекст. Следващата команда ще създаде контекст:

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

Можете да прегледате наличните контексти така:

$ fn list contexts

CURRENT NAME      PROVIDER      API URL                      REGISTRY
    default       default       http://localhost:8080/
    exoscale      default       http://185.19.30.175:8080    nfrankel

А да превключите на контекста, който току-що е създаден, така:

 $ fn use context exoscale

 Сега използвате контекст: exoscale

Започвайки от това място, доставката на функциите Fn ще зарежда Docker образи, използвайки избраната акаунт на DockerHub (в моя случай — nfrankel), след което ще уведоми отдалечения сървър (в този пример — http://185.19.30.175:8080) за местоположението и версията на последния образ, съдържащ вашата функция.

$ fn deploy --app fnexo .   # изпълнява се на локалната машина от директорията hellonode

Зареждане на функция на: \/.
Зареждане на hellonode в приложението: fnexo
Увеличена версия 0.0.5
Създаване на образ nfrankel\/hellonode:0.0.5 .

Накрая:

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

{"message":"Hello World"}

Изграждане на собствен serverless на базата на Fn
Жизненият цикъл на функцията в безсървърните изчисления на базата на Fn

Предимства на безсървърните изчисления на собствените мощности

Безсървърните изчисления са удобно решение за бързо внедряване на независими части от приложението, взаимодействващи с по-сложни приложения или микросервизи.

Често това е свързано с скрити разходи за привързаност към избрания доставчик, което, в зависимост от конкретния случай на употреба и обема, може да доведе до по-високи разходи и намаляване на гъвкавостта в бъдеще.

Многоблачни и хибридни облачни архитектури също страдат в такъв случай, тъй като лесно може да се окаже, че искате да използвате безсървърни изчисления, но заради корпоративната политика това може да бъде невъзможно.

Fn е достатъчно лесен за работа и може да предостави почти същия интерфейс FaaS, с минимални разходи. Той освобождава от всякаква привързаност към доставчика и може да се инсталира локално или при който и да е удобен доставчик на облачни решения по Ваш избор. Освен това има свобода в избора на програмен език.

В статията са представени само основите на Fn, но създаването на собствена среда за изпълнение е достатъчно просто, а общата архитектура може да бъде разширена с използване на балансировщик на натоварването Fn или разполагайки Fn зад прокси за защита.

Източник: habr.com