doc: add handoff summary and postgres function-job plan
This commit is contained in:
@@ -4,6 +4,103 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-28 — Handoff: функции-джобы для установки ПО в ВМ (курс на PostgreSQL)
|
||||
|
||||
### Контекст и цель
|
||||
|
||||
- Пример [examples/VM](examples/VM) рассматривается как пользовательский Terraform-шаблон.
|
||||
- Пользовательский сценарий: скачать шаблон, подставить токены/ключи, выбрать нужные пакеты, выполнить `terraform apply`.
|
||||
- Целевое поведение: один apply поднимает `vApp + VM` и запускает автоматическую установку ПО в VM.
|
||||
- Vault в облаке пока недоступен, но архитектура должна быть ready для последующего перехода на Vault без переписывания логики функций.
|
||||
|
||||
### Что выяснили по текущей платформе (sless)
|
||||
|
||||
- Для one-shot действий в sless уже есть подходящая сущность: `sless_job`.
|
||||
- Модель запуска:
|
||||
1. Создаётся job-ресурс.
|
||||
2. Загружается исходник функции (`/upload`).
|
||||
3. Оператор собирает образ (kaniko).
|
||||
4. Job запускается в k8s, статус виден как `Pending/Building/Running/Succeeded/Failed`.
|
||||
- Передача входных параметров:
|
||||
1. `event_json` -> payload в `handle(event)`.
|
||||
2. `env_vars` -> переменные окружения внутри контейнера.
|
||||
- Ошибки установки отслеживаются на нескольких уровнях:
|
||||
1. Terraform apply (resource fail).
|
||||
2. Статус job (`Phase`, `Message`).
|
||||
3. Логи пода/контейнера (детали SSH/apt/команд).
|
||||
|
||||
### Архитектурное решение на сейчас
|
||||
|
||||
- Не делать отдельный новый Terraform resource под установку пакетов на текущем этапе.
|
||||
- Использовать `sless_job` как основной механизм выполнения.
|
||||
- Причина: установка ПО по SSH в VM - это execution-задача (one-shot), а не устойчивый ресурс со сложной моделью state/drift.
|
||||
- Отдельный resource рассматривать позже, когда стабилизируется контракт (semantics ensure-present/absent/version + read/drift).
|
||||
|
||||
### Принятый целевой дизайн (этап 1)
|
||||
|
||||
1. Универсальная функция-джоб `install-packages`.
|
||||
2. Отдельные специализированные функции-джобы: `install-docker`, `install-git`, далее по необходимости.
|
||||
3. В Terraform-шаблоне флаги/переменные включают нужные джобы.
|
||||
4. Общая схема параметров:
|
||||
: `event_json` для бизнес-параметров (список пакетов, режимы).
|
||||
: `env_vars` для подключения к VM (`VM_IP`, `SSH_USER`, `SSH_KEY`).
|
||||
|
||||
### План по PostgreSQL-направлению (что делать дальше)
|
||||
|
||||
#### Этап A: Базовый VM bootstrap
|
||||
|
||||
1. Реализовать `install-packages` (apt update/install, идемпотентность, явные коды ошибок).
|
||||
2. Реализовать `install-git` как отдельный job-шаблон.
|
||||
3. Реализовать `install-docker` как отдельный job-шаблон (репозиторий/GPG, проверка `docker --version`).
|
||||
|
||||
#### Этап B: PostgreSQL-specific функции
|
||||
|
||||
1. Добавить `install-postgres` job:
|
||||
: установка `postgresql`, `postgresql-contrib`, `postgresql-client`.
|
||||
: проверка статуса `systemctl is-active postgresql`.
|
||||
2. Добавить `configure-postgres` job:
|
||||
: создание БД/пользователя.
|
||||
: настройка доступа (минимально безопасная, через параметры).
|
||||
: проверка подключения `psql`.
|
||||
3. Добавить `seed-postgres` job (опционально):
|
||||
: создание таблиц/базовых данных для демо.
|
||||
|
||||
#### Этап C: Terraform UX для пользователя шаблона
|
||||
|
||||
1. Вынести управляемые параметры в `terraform.tfvars`:
|
||||
: `install_packages`, `install_docker`, `install_git`, `install_postgres`.
|
||||
: `postgres_db`, `postgres_user` и др. параметры.
|
||||
2. Обеспечить зависимости:
|
||||
: VM должна быть готова до старта job.
|
||||
: Postgres-конфиг запускается после установки postgres.
|
||||
3. Добавить outputs с итоговым статусом job-ов для быстрого контроля.
|
||||
|
||||
#### Этап D: Переход на Vault (когда сервис появится)
|
||||
|
||||
1. Не менять код функций.
|
||||
2. Заменить только источник секретов в Terraform (`env_vars` заполняются из Vault data source).
|
||||
3. Сохранить обратную совместимость с текущим режимом (секрет в tfvars) для dev/demo.
|
||||
|
||||
### Риски и ограничения, зафиксированные заранее
|
||||
|
||||
1. SSH/apt операции подвержены временным сетевым сбоям и lock-файлам apt -> нужны retries и читаемые сообщения об ошибках.
|
||||
2. Job-модель не равна полноценному stateful resource: drift пакетов в VM не отслеживается автоматически Terraform-ом.
|
||||
3. Для production-пути позже потребуется отдельный контракт безопасности по секретам и ротации ключей.
|
||||
|
||||
### Что уже сделано в этой ветке перед handoff
|
||||
|
||||
1. Обновлён пример VM по nubes provider `5.0.49`.
|
||||
2. Переименованы имена VM/vApp ресурсов в более короткий формат (`vm-sless`, `vapp-sless`).
|
||||
3. Изменения закоммичены и отправлены в ветку `examples/dev-from-ground`.
|
||||
|
||||
### Рекомендация для нового чата
|
||||
|
||||
1. Стартовать реализацию с `install-packages` + Terraform wiring в [examples/VM](examples/VM).
|
||||
2. После успешного E2E добавить `install-postgres` и `configure-postgres`.
|
||||
3. Держать код максимально идемпотентным, чтобы повторный apply не ломал VM.
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-23 — Сессия 11: Баги cache-тест, fix оператора v0.1.62, fix провайдера
|
||||
|
||||
### Что сделано
|
||||
|
||||
Reference in New Issue
Block a user