Представляя функции как сервис — OpenFaaS

Прим перев.: OpenFaaS — serverless-фреймворк, формально представленный в августе, но появившийся около года назад и быстро укрепившийся на самой вершине проектов GitHub по тегу Kubernetes. Опубликованный ниже текст — перевод технической части официального анонса проекта от его автора Alex Ellis, который хорошо известен в сообществе своим энтузиазмом в области Docker (имеет статус Docker Captain).

Functions as a Service или OpenFaaS — фреймворк для создания serverless-функций поверх контейнеров. Я начал проект как proof of concept в октябре прошлого года, когда хотел понять, можно ли запускать Alexa skills или функции AWS Lambda в Docker Swarm. Начальные успехи привели меня к публикации в декабре того же года первой версии кода на Golang в GitHub.

Эта публикация предлагает быстрое введение в бессерверные (serverless) вычисления и рассказывает о трёх главных возможностях, появившихся в FaaS за последние 500 коммитов.



С момента первого коммита FaaS набирал популярность: получил более 4000 звёздочек на GitHub (уже более 7000 на сегодняшний день — прим. перев.) и небольшое сообщество разработчиков и хакеров, которые рассказывали о нём на различных встречах, писали свои функции и вносили изменения в код. Значимым событием для меня стало получение места среди главных сессий Moby Cool Hacks на Dockercon в Остине в апреле. Стоявшая перед этими выступлениями задача звучала как расширение границ того, для чего был создан Docker.

Что такое serverless?

Архитектура эволюционирует

Serverless («бессерверный») — неудачное название. Мы говорим о новом архитектурном паттерне для управляемых событиями (event-driven) систем. Serverless-функции часто используются как связующее звено между другими сервисами или в архитектуре, управляемой событиями. Раньше мы называли подобное сервисной шиной (service bus).


Serverless — это эволюция

Serverless-функции

Бессерверная функция — это небольшая, отдельная и ориентированная на повторное использование часть кода, которая:

• недолго живёт,
• не является демоном (запускаемым на долгое время),
• не запускает TCP-сервисы,
• не является stateful,
• использует существующие у вас сервисы или сторонние ресурсы,
• выполняется за несколько секунд (по умолчанию в AWS Lambda).

Также важно различать serverless-продукты от IaaS-провайдеров и проекты программного обеспечения с открытым кодом (Open Source).

С одной стороны, у нас есть такие serverless-реализации от IaaS-провайдеров, как Lambda, Google Cloud Functions и функции Azure, а с другой — фреймворки вроде OpenFaaS, позволяющие выполнять тяжёлую работу платформам оркестровки вроде Docker Swarm или Kubernetes.


Cloud native: используй свой любимый кластер.

Serverless-продукт от IaaS-вендора является полностью управляемым, поэтому предлагает высокий уровень удобства использования и оплату по секундам/минутам. Обратная сторона медали — вы очень привязаны к их циклу релизов и поддержки. FaaS с открытым кодом существуют для обеспечения разнообразия и возможности выбора.

В чём особенность OpenFaaS?

OpenFaaS построен на основе технологий, являющихся индустриальным стандартом в мире cloud native:


Стек OpenFaaS

Особенность проекта OpenFaaS заключается в том, что каждый процесс может стать serverless-функцией с помощью компонента watchdog и контейнера Docker. Это означает три вещи:

• вы можете запускать код на любом языке программирования;
• на любое время, какое требуется;
• где угодно.

Переход на serverless не должен подразумевать необходимость переписывать код на другой язык программирования. Просто воспользуйтесь тем, что нужно вашему бизнесу и команде.

Например:

Команда cat или sha512sum может быть функцией, не требующей каких-либо изменений, поскольку функции взаимодействуют через stdin/stdout. Windows-функции также поддерживаются в Docker CE.

В этом и есть основное отличие FaaS от других serverless-фреймворков с открытым кодом, которые зависят от специальных исполняемых сред для каждого поддерживаемого языка.

Посмотрим на 3 самые значимые фичи, которые появились с момента DockerCon (т.е. с апреля по август 2017 года — прим. перев.): CLI и шаблоны для функций, поддержка Kubernetes и асинхронная обработка.

1. Новый CLI

Простое развёртывание

Консольный интерфейс (CLI) был добавлен в проект FaaS, чтобы упростить функции деплоя и добавить им поддержку скриптования. До сих пор для этих целей можно было использовать пользовательский интерфейс (UI) к API Gateway или curl. Появившийся CLI позволяет определять функции в YAML-файле и деплоить их в тот же API Gateway.

Finnian Anderson написал замечательное введение в FaaS CLI на Practical Dev / dev.to.

Скрипт утилиты и brew

Для установки CLI есть специальный скрипт, а John McCabe помог с рецептом для brew:

$ brew install faas-cli

или:

$ curl -sL https://cli.get-faas.com/ | sudo sh

Шаблоны

С помощью шаблонов в CLI достаточно написать обработчика на любимом языке программирования, после чего CLI воспользуется шаблоном для сборки этого обработчика в Docker-контейнер со всей магией FaaS.

Подготовлены два шаблона: для Python и Node.js, — но легко создать и свой собственный.

CLI поддерживает три действия:

• -action build — локально создаёт Docker-образы из шаблонов;
• -action push — загружает (push'ит) образы в выбранный реестр или Hub;
• -action deploy — разворачивает FaaS-функции.

Если у вас кластер из 1 узла, нет необходимости push'ить образы перед их деплоем.

Вот пример конфигурационного файла CLI в формате YAML (sample.yml):

provider:
  name: faas
  gateway: http://localhost:8080

functions:
  url_ping:
    lang: python
    handler: ./sample/url_ping
    image: alexellis2/faas-urlping

А вот минимальный (пустой) обработчик для функции на Python:

def handle(req):
    print(req)

Пример, проверяющий код состояния у URL по HTTP (./sample/url_ping/handler.py):

import requests

def print_url(url):  
    try:
        r =  requests.get(url,timeout = 1)
        print(url +" => " + str(r.status_code))
    except:
        print("Timed out trying to reach URL.")

def handle(req):  
    print_url(req)

Если требуются дополнительные модули PIP, добавьте к своему обработчику (handler.py) файл requirements.txt.

$ faas-cli -action build -f ./sample.yml

После такой команды появится Docker-образ под названием alexellis2/faas-urlping, который можно загрузить в Docker Hub с помощью -action push и задеплоить с -action deploy.

CLI для FaaS доступен в этом репозитории.

2. Поддержка Kubernetes

Будучи капитаном Docker, я в основном занимаюсь изучением Docker Swarm и статьями о нём, однако меня всегда интересовал и Kubernetes. Начав изучать, как настроить Kubernetes в Linux и Mac, я уже написал три руководства об этом, и их хорошо встретили в сообществе.

Проектируя поддержку Kubernetes

Получив хорошее понимание того, как перенести концепции Docker Swarm на Kubernetes, я подготовил прототип и портировал весь код за несколько дней. Выбор пал на создание нового микросервисного демона, взаимодействующего с Kubernetes, — вместо добавления дополнительных зависимостей в основную кодовую базу FaaS.

FaaS проксирует вызовы к новому демону через стандартный RESTful-интерфейс для таких операций, как Deploy/List/Delete/Invoke и Scale.

Такой подход означает, что пользовательский интерфейс, CLI и автомасштабирование заработали из коробки без необходимости вносить изменения. Получившийся микросервис поддерживается в новом GitHub-репозитории под названием FaaS-netes и доступен в Docker Hub. Его настройка в кластере занимает около 60 секунд.

Демонстрация поддержки Kubernetes

В этом видео FaaS разворачивается на пустом кластере, после чего показывается, как работать с пользовательским интерфейсом, Prometheus и автомасштабированием.

Но подождите… ведь есть другие фреймворки, которые работают на Kubernetes?

Пожалуй, есть две категории serverless-фреймворков для Kubernetes: те, которые полагаются на очень специфическую исполняемую среду для каждого поддерживаемого языка программирования, и те, что, как и FaaS, позволяют любому контейнеру стать функцией.

У FaaS есть привязки для родного API у Docker Swarm и Kubernetes, то есть он использует объекты, с которыми вы уже работали для управления Deployments и Services. Это означает, что здесь меньше магии и нуждающегося в расшифроке кода, когда дело доходит до сути написания новых приложений.

При выборе фреймворка стоит учитывать, хотите ли вы привносить в проекты новые возможности или исправления. Например, OpenWhisk написан на Scala, а большинство других — на Golang.

• Funktion;
• Iron Functions;
• OpenWhisk;
• Kubeless;
• Fission;
• FaaS-netes.

3. Асинхронная обработка

Одна из особенностей бессерверной функции — она маленькая и быстрая, исполняется синхронно и обычно за несколько секунд. Но есть ряд причин, почему можно захотеть асинхронной обработки функции:

• это событие, и вызывающему оператору не нужен результат;
• исполнение или инициализация выполняется долго — например, TensorFlow / Machine Learning;
• принимается большое количество запросов в рамках пакетного задания;
• вы хотите ограничить скорость.

Прототип для асинхронной обработки начинался с распределённой очереди. Реализация использует NATS Streaming, но может быть расширена для работы с Kafka или любой другой абстракцией, выглядящей как очередь.


Иллюстрация из Twitter-анонса асинхронного режима в FaaS

Асинхронный вызов с NATS Streaming в качестве бэкенда включён в кодовую базу проекта. Инструкция по его использованию доступна здесь.

Приветствуются любые изменения

… и не важно, хотите вы помочь с issues, фичами в коде, релизами проекта, скриптованием, тестами, измерением производительности, документацией, обновлением примеров или даже написанием в блоге о проекте.

Для каждого всегда что-нибудь найдётся, и всё это помогает проекту двигаться вперёд.

Любую обратную связь, идеи, предложения отправляйте @alexellisuk или через один из репозиториев GitHub.

Не уверены, с чего начать?

Вдохновитесь обсуждениями и примерами функций от сообщества, которые включают в себя машинное обучение с TensorFlow, ASCII art и простые интеграции.

P.S. от переводчика

Месяц назад автором этого материала была также опубликована инструкция по началу работы с OpenFaaS  на Kubernetes 1.8 с использованием Minikube.

Если вас интересует тема serverless под Kubernetes, стоит также обратить внимание (как минимум) на проекты Kubeless и Fission, а более полный список приводит сам автор статьи выше. Вероятно, мы про них ещё напишем в нашем блоге, а пока — читайте среди прошлых материалов:

• «Kubernetes 1.9: обзор основных новшеств»;
• «Зачем нужен Kubernetes и почему он больше, чем PaaS?»;
• «Инфраструктура с Kubernetes как доступная услуга».