Разработка и деплой серверless‑функций в Termux с OpenFaaS: локальное тестирование, автоскейлинг и интеграция с API‑шлюзом Kong

Termux давно перестал быть «только терминалом»: в сочетании с container‑подходом и локальными runtime‑платформами он позволяет собирать и проверять серверless‑функции практически в полевых условиях. В этой статье мы разберём, как разработать серверless‑функции на базе OpenFaaS, запустить их для локального тестирования прямо в вашей рабочей среде, настроить автоскейлинг и интегрировать сервисы с API‑шлюзом Kong.

Материал рассчитан на инженеров и DevOps‑практиков: мы будем идти от структуры проекта к деплою, тестам, масштабированию и публикации HTTP‑эндпоинтов.

Архитектура решения

Рассмотрим типовую схему компонентов:

Termux — место разработки: сборка артефактов, подготовка Dockerfile/шаблонов, вызовы CLI.
OpenFaaS — управление функциями, очередями, проксированием и рантаймом (фаундером будет OpenFaaS‑кластер/стек).
OpenFaaS gateway — входная точка для вызовов функций (обычно HTTP/REST).
Autoscaler (OpenFaaS autoscaler) — реакция на метрики (например, входящий трафик/загрузка).
Kong — API‑шлюз, который принимает запросы от клиентов и проксирует их к OpenFaaS gateway или напрямую к сервисам.

На практике вы можете развернуть OpenFaaS и Kong локально (например, на вашем ноутбуке/мини‑сервере) и использовать Termux как рабочее окружение для итераций.

Подготовка окружения в Termux

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

1) Обновление индексов пакетов

pkg update

2) Установка базовых утилит

pkg install -y curl wget git ca-certificates

3) Установка утилит для работы с Docker‑образами (если вы используете внешний Docker‑демон)

В Termux часто используют удалённый Docker‑демон (например, на ПК через TCP) или Podman в зависимости от инфраструктуры. Если у вас Docker‑демон доступен удалённо, настройте доступ к нему корректно (без лишнего «открытия» портов в интернет).

На стороне Termux полезно убедиться, что вы можете собирать/пушить/использовать образы в нужном репозитории. Далее это будет зависеть от выбранной модели деплоя OpenFaaS (локально и/или в registry).

Создание функции в стиле OpenFaaS

OpenFaaS в большинстве сценариев использует «шаблоны» функций и фиксированный формат файлов. Для примера возьмём простой handler, который принимает входной текст и возвращает подтверждение.

Рекомендуемая практика — хранить функции в отдельной директории и версионировать их в git.

1) Инициализация проекта

mkdir -p ~/openfaas-demo/functions/echo
cd ~/openfaas-demo/functions/echo

2) Создание файла handler

Пример на Python. Аналогично можно использовать Node.js/Go/другие поддерживаемые рантаймы — под вашу инфраструктуру OpenFaaS.

cat > function.py <<'EOF'
import sys
from flask import Flask, request

app = Flask(name)

@app.route("/", methods=["POST"])
def main():
    data = request.get_data(as_text=True) or ""
    return data, 200

if name == "main":
    app.run(host="0.0.0.0", port=int(sys.argv[1]) if len(sys.argv) > 1 else 8080)
EOF

3) Dockerfile для функции

Набор базовых образов OpenFaaS зависит от выбранного шаблона/рантайма. Ниже показана концепция: вы подставляете подходящий base image (OpenFaaS template/stack) и копируете код.

cat > Dockerfile <<'EOF'
FROM python:3.11-slim

WORKDIR /app
RUN pip install --no-cache-dir flask

COPY function.py /app/function.py

ENV fprocess="python function.py"

EXPOSE 8080
CMD ["python", "function.py"]
EOF

4) Обязательные метаданные (conceptual)

OpenFaaS требует описания функции (часто через faas-cli шаблоны и YAML‑файл service). В этой статье мы фокусируемся на логике деплоя и интеграции, поэтому конкретные поля YAML зависят от вашей версии OpenFaaS и схемы (фаас‑cli/stack file).

Локальное тестирование функций

Перед деплоем в OpenFaaS стоит прогнать функцию локально, чтобы не тратить время на циклы «сборка → деплой → тест».

Вариант A: локальный запуск контейнера

Если вы уже собрали Docker‑образ, проверьте его локально:

docker build -t echo-fn:local .
docker run --rm -p 18080:8080 echo-fn:local

Проверьте endpoint:

curl -s -X POST --data "hello" http://127.0.0.1:18080/

Вариант B: тестирование через OpenFaaS gateway (после деплоя в dev‑стек)

Когда вы деплоите функцию в локальный OpenFaaS‑стек, gateway выступает как единая точка входа. Вызов обычно делается через URL вида:

http://<openfaas-gateway-host>:8080/function/<function-name>

Например:

curl -s -X POST http://<gateway>:8080/function/echo -d "hello"

Если вам требуется подключение с устройства (Termux) к сервисам в одной локальной сети, корректно настройте локальную сеть (например, VPN для создания локальной сети) и доступ к портам внутри вашей сети — это стандартный подход для разработки.

Деплой в OpenFaaS

Для деплоя обычно используют faas-cli и stack‑файлы. Ниже — практический сценарий: вы собираете образ, пушите в registry (если требуется), затем деплоите сервис через faas-cli или YAML‑стек.

1) Подготовка stack YAML

Примерную структуру можно представить так (поля могут отличаться по версии):

cat > stack.yml <<'EOF'
provider:
  name: openfaas
functions:
  echo:
    lang: python
    handler: ./echo
    image: your-registry/echo:latest
    environment:
      mode: "dev"
EOF

2) Деплой через faas-cli

Убедитесь, что faas-cli сконфигурирован под ваш gateway (OPENFAAS_URL/credentials — зависит от вашей установки).

faas-cli login -u <user> -p <password> <gateway-url>
faas-cli deploy -f stack.yml

3) Проверка статуса

faas-cli list

Далее проверьте вызов:

curl -s -X POST http://<gateway>:8080/function/echo -d "OpenFaaS OK"

Автоскейлинг в OpenFaaS

Автоскейлинг — ключевой элемент серверless‑подхода: платформа увеличивает/уменьшает число инстансов функции в ответ на нагрузку или метрики.

Обычно OpenFaaS autoscaler опирается на параметры вроде:

минимальное/максимальное число инстансов;
целевые метрики очереди или загрузки;
таймауты/пороговые значения;
конфигурация расписаний (в зависимости от реализации).

Конкретный формат зависит от вашей установки (Docker‑compose/k8s/helm). В большинстве локальных сценариев настройки задаются через конфигурацию autoscaler и параметры provider.

Пример: conceptual настройка autoscaler (только как ориентир)

# Примерная форма, адаптируйте под вашу инсталляцию OpenFaaS
# (не копируйте буквально без сверки с документацией вашей версии)

faas-autoscaler:
  enabled: true
  minReplicas: 0
  maxReplicas: 10
  scaleUpThreshold: 10
  scaleDownThreshold: 0
  pollingInterval: 5s

После настройки проверьте:

что autoscaler в сети поднимается и виден (логами);
что метрики действительно меняются при нагрузке;
что функции масштабируются без ошибок (смотрите логи gateway и функции).

Нагрузочный тест

Для грубой проверки можно сделать параллельные запросы с Termux:

for i in {1..50}; do
  curl -s -X POST http://<gateway>:8080/function/echo -d "msg $i" &
done
wait

В идеале подключите системные метрики (Prometheus/Grafana в зависимости от вашей установки OpenFaaS) и подтвердите рост инстансов.

Интеграция с API‑шлюзом Kong

Kong удобно использовать как «единое лицо» API: роуты, аутентификация, rate limiting, логирование, трансформации и единая точка интеграции с клиентами.

На практике Kong может проксировать запросы:

к OpenFaaS gateway (рекомендуется как единый вход);
либо к отдельным upstream‑сервисам (если у вас кастомная схема).

Примерная стратегия

создаём Service в Kong, указав upstream на OpenFaaS gateway;
создаём Route, который матчится по пути (например, /functions/echo);
при необходимости настраиваем strip_path и/или rewrite для соответствия URL‑формату OpenFaaS.

Ниже приведён вариант через Admin API Kong (концептуально). Замените <kong-admin> и адрес gateway на ваши реальные значения.

1) Добавление Service

curl -s -X POST http://<kong-admin>/services 
  --data "name=openfaas-gateway" 
  --data "url=http://<gateway>:8080"

2) Добавление Route

Допустим, хотим чтобы внешний API выглядел так: POST /functions/echo, а внутренний OpenFaaS требует /function/echo. Тогда нужна переадресация по пути.

curl -s -X POST http://<kong-admin>/services/openfaas-gateway/routes 
  --data "name=echo-route" 
  --data "paths[]=/functions/echo" 
  --data "strip_path=false"

Важное замечание по пути

В зависимости от версии Kong и параметров, может потребоваться rewrite (через Plugin) или настройка пути так, чтобы OpenFaaS правильно принял запрос. Для точной конфигурации используйте соответствующие возможности Kong (например, request-transformer или средствами route/url mapping в вашей сборке).

3) Тест через Kong

Проверьте внешний эндпоинт:

curl -s -X POST http://<kong-proxy>/functions/echo -d "from kong"

Если всё настроено корректно, ответ должен вернуться от функции OpenFaaS.

Безопасность и практики эксплуатации

Чтобы деплой серверless‑функций оставался управляемым и безопасным:

Не открывайте Kong/OpenFaaS в интернет без необходимости; для локальной разработки используйте доступ в локальной сети.
Применяйте rate limiting и аутентификацию на уровне Kong.
Храните секреты функции (если они есть) в механизмах, предусмотренных вашей установкой OpenFaaS/Kubernetes, а не в репозитории.
Логируйте ключевые операции: деплой, вызовы функций, ошибки рантайма.

Заключение

Мы рассмотрели полный контур: от разработки функции в Termux до деплоя в OpenFaaS, локального тестирования, подключения автоскейлинга и публикации API через Kong. Такой подход ускоряет итерации, упрощает эксплуатацию и даёт единый слой управления доступом к вашим серверless‑эндпоинтам.

Если вам нужно быстрее пройти путь от прототипа до рабочей инфраструктуры (настройка OpenFaaS, интеграция Kong, автоскейлинг, CI/CD и мониторинг), обращайтесь в РыбинскЛАБ — поможем спроектировать и внедрить решение под вашу среду.