6.1 KiB
Решения и обоснования
2026-03-06 — Отдельная репа для сервиса
Решение: Serverless service в отдельной репе, не вместе с Terraform provider.
Причина: Разные зоны ответственности, разные релизы, потенциально разные команды.
2026-03-06 — Один бинарник для v1
Решение: Один Go бинарник вместо микросервисов.
Причина: Нагрузки изначально нет. Проще деплоить, проще отлаживать. Разделим при необходимости.
2026-03-06 — Аутентификация через облачный токен
Решение: Использовать Bearer token облака, без Keycloak.
Причина: Terraform provider уже работает с токенами облака. Keycloak — лишняя зависимость для v1.
2026-03-06 — S3 облачный, остальное в кубере
Решение: S3 (Ceph) использовать облачный (ceph.tst.nubes.ru), PostgreSQL/Redis — в кластере.
Причина: S3 имеет внешний доступ и уже готов. Для PostgreSQL/Redis сетевого связывания с облаком пока нет — настраивается через devops облака.
2026-03-06 — Текущий кластер для разработки
Решение: Использовать существующий k8s кластер (namespace sless), потом перенести на новый.
Причина: Новый кластер ещё не готов. Изоляция через namespace — безопасно для существующих сервисов.
2026-03-06 — RabbitMQ откладываем
Решение: В v1 только HTTP и Cron триггеры. RabbitMQ/event triggers — в v2.
Причина: Упрощение первой итерации.
2026-03-07 — DockerHub вместо внутреннего registry
Решение: Образы функций и runtime базовые образы публикуются на DockerHub (user naeel).
Причина: Namespace registry в кластере — это Apache NiFi Registry (NOT Docker). Отдельный Docker registry не поднят. DockerHub доступен и достаточен для разработки.
2026-03-07 — Terraform провайдер sless — отдельный модуль в той же репе
Решение: terraform/provider/ — независимый Go-модуль внутри репы sless.
Причина: Удобно держать рядом. Код провайдера писался с прицелом на перенос в nubes провайдер (/home/naeel/remote_dev/terraform). Клиент (internal/client/) → internal/core/ nubes, ресурсы → internal/resources_gen/.
2026-03-07 — WaitReady в Terraform провайдере при создании функции
Решение: После UploadCode провайдер ждёт phase=Ready (polling каждые 5 сек, таймаут 5 мин).
Причина: Kaniko-сборка занимает ~1 минуту. Без ожидания terraform apply завершился бы с phase=Building в state, что неверно отображало бы реальное состояние ресурса.
2026-03-07 — code_hash для детектирования изменений кода функции
Решение: Атрибут code_hash в sless_function — пользователь задаёт через filemd5("./handler.zip"). Изменение hash → провайдер перезагружает zip и запускает пересборку.
Причина: Terraform не отслеживает содержимое файлов автоматически. Это стандартный паттерн (аналогично aws_lambda_function.source_code_hash).
2026-03-07 — Scale-to-zero откладываем до v2
Решение: В v1 функции работают как Deployment с постоянно живым подом (always-on). Scale-to-zero — в v2 через KEDA HTTP Add-on.
Причина: Scale-to-zero меняет архитектуру контроллера и routing. Для MVP это несоразмерная сложность. Пользователь может управлять ресурсами вручную через replicas = 0/1/N (планируется в v1.1).
v2 план: Заменить Deployment на HTTPScaledObject (KEDA), минимальные реплики = 0. KEDA буферизует запросы во время cold start (~1-3 сек).
2026-03-07 — replicas как ручное управление масштабом (TODO v1.1)
Решение: Добавить поле replicas *int32 в FunctionSpec. Пользователь задаёт через Terraform: replicas = 0 (выключить), replicas = 1 (включить), replicas = N (масштабировать).
Причина: Без этого функция жрёт ресурсы 24/7 даже если не нужна. Это минимальный механизм контроля потребления до реализации scale-to-zero.
2026-03-07 — PostgreSQL опционален для базового Function Hosting
Решение: Postgres нужен только для логов вызовов (invocations). Для базового деплоя функций — не нужен. Оператор работает без него (просто не пишет логи).
Минимальные зависимости для production: k8s кластер + S3 + Docker registry + Ingress.