Прим перев.: 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.
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 как доступная услуга».
Автор: shurup
