Author SHA1 Message Date
Naeel b920dc5c9d feat(iot): Этап 6 — Terraform ресурс sless_iot_device (провайдер v0.1.2) 2026-04-04 09:56:18 +03:00
Naeel 1e53766c46 feat(iot): Этапы 2-7 — MQTT auth, IoT API, EMQX, mqtt-bridge, E2E demo
Этап 2+4: internal/api/handler/iot_device_handler.go
  - MQTTAuth: POST /internal/mqtt/auth (без JWT, для EMQX)
  - CreateIoTDevice, ListIoTDevices, GetIoTDevice (c password), DeleteIoTDevice, UpdateIoTDevice
  - crypto/subtle.ConstantTimeCompare против timing attacks

Этап 4: internal/api/router.go
  - /v1/namespaces/{ns}/iot/devices CRUD
  - /internal/mqtt/auth (без JWT middleware)

Этап 3: deployments/k8s/emqx.yaml
  - EMQX 5.5.1, emqx.conf (HOCON) с HTTP auth backend
  - Сервис exposure: 1883 (MQTT), 8083 (WS), 18083 (Dashboard)

Этап 3: iot/cmd/mqtt-bridge/main.go
  - paho.mqtt.golang: подписка на +/telemetry/+
  - amqp091-go: publish в iot.{namespace}.telemetry
  - deployments/k8s/iot-mqtt-bridge.yaml

Этап 7: examples/IOT/ — E2E demo (main.tf, handler.py, README.md)

go.mod: добавлен github.com/eclipse/paho.mqtt.golang v1.5.1
go build ./... — ошибок нет
2026-04-04 09:45:23 +03:00
Naeel 716efafda8 feat(iot): Этап 1 — CRD IoTDevice + контроллер credentials
- iot/api/v1alpha1/device_types.go — CRD IoTDevice
- iot/api/v1alpha1/groupversion_info.go — API group iot.kube5s.ru/v1alpha1
- iot/api/v1alpha1/zz_generated.deepcopy.go — deepcopy (controller-gen)
- iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml — CRD манифест
- iot/controllers/iotdevice_controller.go — Reconcile: Secret с MQTT credentials
- main.go — регистрация IoT схемы и IoTDeviceReconciler

go build ./... — ошибок нет
2026-04-04 09:32:47 +03:00
Repinoid 6dc2dc69ba IoT MVP: архитектура, план реализации, лог рассуждений
- Определена архитектура managed IoT service
- Согласовано решение: RabbitMQ (MVP), потом Kafka; EMQX + CRD контроллер
- Создан подробный план для Sonnet (doc/iot-mvp-plan.md)
- Добавлено правило в copilot-instructions: лог мышления в doc/thinking/ по датам
- Полный ход рассуждений в doc/thinking/2026-04-04.md

Ключевые решения:
- IoT код в iot/ (легко вынести потом)
- CRD IoTDevice + контроллер (как все остальное в sless)
- EMQX HTTP Auth Backend для динамической аутентификации устройств
- Архитектура broker-agnostic (легко переключить на Kafka)
- Terraform: расширяем текущий provider (sless_iot_device ресурс)
2026-04-04 08:34:14 +03:00
Repinoid ebbba66146 doc: pg-terraform behavior report + ERR-PG-06/07
- doc/pg-terraform-behavior.md: подробный отчёт по поведению Nubes PostgreSQL
  с Terraform (vault_secrets, роли, тайминги, depends_on chain, SSH timeout)
  Добавлены: §2.6 vault ограничение (только 1 пользователь на инстанс), §9 IAM 408
- doc/errors/log.md: ERR-PG-01..ERR-PG-07 (все ошибки сессии тестирования)
  ERR-PG-06: vault backend позволяет только 1 vault_secrets на инстанс
  ERR-PG-07: HTTP 408 от auth-api-test.ngcloud.ru (транзитная)
- doc/progress.md: финальный статус сессии — lifecycle тесты заблокированы
  vault-ограничением тест-окружения, требуется исправление на стороне Nubes
2026-04-01 19:21:37 +04:00
Naeel 211563a87c merge: examples/dev-from-ground → main 2026-03-30 09:28:39 +03:00
Naeel 4764e983f7 doc: обновлён log ошибок 2026-03-30 09:27:45 +03:00
Naeel f869b7986e feat: vdc_uid/nsxt_uid вынесены в tfvars; terraform.tfvars.template; README обновлён 2026-03-30 09:03:16 +03:00
Naeel 89d698fa47 fix: idempotency check 0 changed only, docker wait 360s nginx 240s 2026-03-30 08:48:49 +03:00
Naeel e737f2687d fix(vm_stress_test): fix idempotent check, sleep->poll, add HTTP/docker/disk tests 2026-03-30 08:00:17 +03:00
Naeel 56e6446310 fix(vm_stress_test): make read-only workflow, add instructions and docs 2026-03-30 07:16:35 +03:00
Naeel fef441681e examples/VM: sless_job provisioning (packages, nginx, docker)
- Add sless.tf: three sless_job resources with depends_on chain
  - vm-install-packages: jq, python3-pip, htop, unzip
  - vm-install-nginx: nginx 1.18 (HTTP 200 verified)
  - vm-install-docker: Docker CE 29.3.1 + Compose v5.1.1
- Add functions/install-{packages,nginx,docker}/handler.py
  - _wait_apt_lock: cloud-init status --wait + systemctl mask
    fixes Ubuntu 22.04 first-boot apt lock (unattended-upgrades)
  - DPkg::Lock::Timeout=600 on all apt-get calls
- Add variables.tf (install_run_id, vm_public_key, vm_private_key)
- Add outputs.tf (install_*_result)
- Bump nubes provider 5.0.49 -> 5.0.51
- doc/progress.md: document step 6 with bug analysis
2026-03-29 19:54:00 +03:00
Naeel b4c2e7f6b1 doc: add handoff summary and postgres function-job plan 2026-03-29 08:31:16 +03:00
Naeel f8f95d7147 examples/VM: bump nubes provider 5.0.49, rename resources vm-sless 2026-03-28 20:27:16 +03:00
Naeel 547994dc55 examples: DEVfromGround vc_org, NODEJS, VM, POSTGRES updates 2026-03-26 08:33:03 +03:00
Naeel 2b03ba520e examples/DEVfromGround: add Terraform manifests (nubes_vc_org, DEV endpoint) 2026-03-26 06:43:53 +03:00
Naeel bc0e00acca feat(vm): add vApp + VM terraform example 2026-03-25 08:17:08 +03:00
Naeel 3404af578b feat(builder): py_compile + node --check при сборке ловят синтаксические ошибки (v0.1.63) 2026-03-23 11:23:01 +03:00
Naeel 8051870208 fix(web-console): убраны память/таймаут, двойной рендер кода (v0.1.11) 2026-03-23 11:14:32 +03:00
Naeel cad89fdbb6 fix(web-console): NotFoundError — urlRow создаётся сразу, не через insertBefore (v0.1.10) 2026-03-23 11:05:30 +03:00
Naeel 6e73729c46 feat(web-console): URL строкой ниже, статус сборки после Save (v0.1.9) 2026-03-23 11:01:01 +03:00
Naeel 470039f6d6 fix(web-console): таймер исчезает после Building→Ready, шаблоны без context (v0.1.8) 2026-03-23 10:52:37 +03:00
Naeel f68b601484 fix(web-console): zip invalid — Close() после Bytes() (v0.1.6) 2026-03-23 10:47:25 +03:00
Naeel 442ba8bc2f feat(web-console): deps, rename, Building poll+timer, kind=service — v0.1.5 2026-03-23 10:41:43 +03:00
Naeel b7fa8acf76 feat(web-console): create/edit/delete functions in UI, v0.1.4
- services/funcs: новые маршруты POST create-function, POST save-function,
  DELETE delete-function — создание/редактирование/удаление через браузер
- index.html: модалка создания с шаблонами Python/Node.js hello world,
  кнопки edit/delete на каждой карточке функции
- sless-funcs-service:v0.1.4 задеплоен
- examples/POSTGRES: удалены логи, .bak, backup tfstate, лишние функции
  оставлены 2 Python (pg-stats, pg-counter) + 2 Node.js (pg-info, js-idempotent)
2026-03-23 10:19:42 +03:00
Naeel 7a168185ea fix: cache lag retry, go.work, провайдер rollback, test v4 no -target 2026-03-23 10:03:26 +03:00
“Naeel” cb77a7f68e fix: go.work replace + test destroy targets 2026-03-23 09:30:37 +04:00
Naeel 2e7cd7f4f7 feat(v0.1.60): sha256-based s3Key for content-addressed cache hit 2026-03-23 06:57:18 +03:00
Naeel c033adec11 feat(v0.1.59): in-cluster registry:2 — insecure HTTP mode, ImageExists error handling 2026-03-23 06:41:30 +03:00
Naeel 9edd43edc5 feat(v0.1.58): ImageExists cache hit, timing analysis, in-cluster registry plan 2026-03-23 06:22:25 +03:00
133 changed files with 10953 additions and 1934 deletions
+26
View File
@@ -4,6 +4,18 @@
**НЕ "СОВЕРШЕНСТВОВАТЬ" РАБОЧИЙ КОД БЕЗ ЯВНОГО УКАЗАНИЯ.**
---
## ЗАПРЕТ НА ВЫДУМКИ
**КАТЕГОРИЧЕСКИ ЗАПРЕЩАЕТСЯ придумывать, догадываться или предполагать:**
- значения параметров, которые не видны в коде или документации
- допустимые значения enum/ролей/типов — если не взяты из реального источника
- поведение API, провайдеров, библиотек — если не подтверждено кодом или документацией
- любые факты о системе, которые агент "знает" из общих соображений
**Если информации нет — спросить у пользователя. Не угадывать.**
Если код работает — не трогать. Никаких:
- рефакторингов "попутно"
- улучшений стиля
@@ -60,6 +72,20 @@
---
## Лог мышления (обязательно)
Каждый агент в каждом чате **обязан** вести лог своих рассуждений:
- Папка: `doc/thinking/`
- Файл: `ГГГГ-ММ-ДД.md` (по дате сессии)
- В начале файла указать имя агента и модель
- Если файл на текущую дату уже существует — дописывать в конец, добавив разделитель `---` и имя агента
- Записывать **полный** ход мыслей: что анализирую, какие гипотезы, что нашёл, что отбросил, к чему пришёл, почему
- Записывать **до** начала действий (план) и **после** (результат)
Цель: пользователь должен видеть весь процесс рассуждений в читаемом виде.
---
## Git
Коммитить и пушить после каждого завершённого этапа.
+2
View File
@@ -69,3 +69,5 @@ event-dispatcher
# build artifacts
/sless
examples/POSTGRES/stress_log*.txt
examples/VM/vm_key
examples/VM/vm_key.pub
+33 -3
View File
@@ -106,11 +106,41 @@ func (r *FunctionReconciler) Reconcile(ctx context.Context, req ctrl.Request) (c
const finalizerName = "sless.kube5s.ru/finalizer"
// startBuild запускает kaniko Job и помечает функцию как Building.
// startBuild проверяет наличие образа в registry и либо пропускает сборку,
// либо запускает kaniko Job. Идемпотентность: если код не менялся (тег = hash s3Key),
// образ уже в registry → deploy без пересборки.
// Критически важно: СНАЧАЛА сохраняем last-built-s3key аннотацию, ПОТОМ status.
// Это предотвращает повторный запуск сборки при параллельных reconcile —
// следующий reconcile увидит last-built-s3key == spec.S3Key и не войдёт в startBuild.
func (r *FunctionReconciler) startBuild(ctx context.Context, fn *slessv1alpha1.Function) (ctrl.Result, error) {
imageRef := r.Builder.ImageRef(fn.Namespace, fn.Name, fn.Spec.S3Key)
// Проверяем: образ с этим тегом уже существует в registry?
// Если да — пропускаем kaniko, сразу переходим в Ready.
// Если registry недоступен — requeue, не запускаем сборку (kaniko тоже упадёт).
exists, err := r.Builder.ImageExists(ctx, imageRef)
if err != nil {
return ctrl.Result{RequeueAfter: 10 * time.Second}, fmt.Errorf("check image exists: %w", err)
}
if exists {
logger := log.FromContext(ctx)
logger.Info("image already exists in registry, skipping build", "imageRef", imageRef)
if fn.Annotations == nil {
fn.Annotations = map[string]string{}
}
fn.Annotations["sless.kube5s.ru/last-built-s3key"] = fn.Spec.S3Key
if err := r.Update(ctx, fn); err != nil {
return ctrl.Result{}, fmt.Errorf("update annotations (cache hit): %w", err)
}
fn.Status.Phase = slessv1alpha1.FunctionPhaseReady
fn.Status.ImageRef = imageRef
fn.Status.Message = "Image restored from registry cache"
if err := r.Status().Update(ctx, fn); err != nil {
return ctrl.Result{}, fmt.Errorf("update status (cache hit): %w", err)
}
return ctrl.Result{}, nil
}
jobName, err := r.Builder.Build(ctx, fn.Namespace, fn.Name, fn.Spec.S3Key)
if err != nil {
return r.setFailed(ctx, fn, fmt.Sprintf("failed to start build: %v", err))
+29 -1
View File
@@ -109,7 +109,8 @@ func (r *FunctionJobReconciler) Reconcile(ctx context.Context, req ctrl.Request)
return r.createRunJob(ctx, fj, deployNS, jobName)
}
// startJobBuild запускает kaniko сборку образа и переводит FunctionJob в фазу Building.
// startJobBuild проверяет наличие образа в registry и либо пропускает сборку,
// либо запускает kaniko Job. Идемпотентность по hash s3Key аналогична service/function.
func (r *FunctionJobReconciler) startJobBuild(ctx context.Context, fj *slessv1alpha1.FunctionJob) (ctrl.Result, error) {
logger := log.FromContext(ctx)
@@ -120,6 +121,33 @@ func (r *FunctionJobReconciler) startJobBuild(ctx context.Context, fj *slessv1al
return ctrl.Result{RequeueAfter: 5 * time.Second}, nil
}
imageRef := r.Builder.ImageRef(r.OperatorNamespace, fj.Name, fj.Spec.S3Key)
// Проверяем: образ с этим тегом уже существует в registry?
// Если registry недоступен — requeue, не запускаем сборку.
exists, err := r.Builder.ImageExists(ctx, imageRef)
if err != nil {
return ctrl.Result{RequeueAfter: 10 * time.Second}, fmt.Errorf("check image exists: %w", err)
}
if exists {
logger.Info("image already exists in registry, skipping build", "imageRef", imageRef)
if fj.Annotations == nil {
fj.Annotations = map[string]string{}
}
if err := r.Update(ctx, fj); err != nil {
return ctrl.Result{}, fmt.Errorf("update annotations (cache hit): %w", err)
}
fj.Status.Phase = slessv1alpha1.FunctionJobPhaseBuilding // перейдёт в run сразу
fj.Status.ImageRef = imageRef
fj.Status.Message = "Image restored from registry cache"
if err := r.Status().Update(ctx, fj); err != nil {
return ctrl.Result{}, fmt.Errorf("update status (cache hit): %w", err)
}
return ctrl.Result{Requeue: true}, nil
}
buildJobName, err := r.Builder.Build(ctx, r.OperatorNamespace, fj.Name, fj.Spec.S3Key)
if err != nil {
fj.Status.Phase = slessv1alpha1.FunctionJobPhaseFailed
+33 -1
View File
@@ -101,8 +101,40 @@ func (r *ServiceReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ct
return ctrl.Result{}, nil
}
// startServiceBuild запускает kaniko Job и помечает сервис как Building.
// startServiceBuild проверяет наличие образа в registry и либо пропускает сборку,
// либо запускает kaniko Job. Идемпотентность: если код не менялся (тег = hash s3Key),
// образ уже в registry → deploy без пересборки.
func (r *ServiceReconciler) startServiceBuild(ctx context.Context, svc *slessv1alpha1.Service) (ctrl.Result, error) {
imageRef := r.Builder.ImageRef(svc.Namespace, svc.Name, svc.Spec.S3Key)
// Проверяем: образ с этим тегом уже существует в registry?
// Если да — пропускаем kaniko, сразу переходим в Ready с известным imageRef.
// Если registry недоступен — requeue, не запускаем сборку (kaniko тоже упадёт).
exists, err := r.Builder.ImageExists(ctx, imageRef)
if err != nil {
return ctrl.Result{RequeueAfter: 10 * time.Second}, fmt.Errorf("check image exists: %w", err)
}
if exists {
logger := log.FromContext(ctx)
logger.Info("image already exists in registry, skipping build", "imageRef", imageRef)
if svc.Annotations == nil {
svc.Annotations = map[string]string{}
}
svc.Annotations["sless.kube5s.ru/last-built-s3key"] = svc.Spec.S3Key
if err := r.Update(ctx, svc); err != nil {
return ctrl.Result{}, fmt.Errorf("update service annotations (cache hit): %w", err)
}
svc.Status.Phase = slessv1alpha1.ServicePhaseReady
svc.Status.ImageRef = imageRef
svc.Status.Message = "Image restored from registry cache"
if err := r.Status().Update(ctx, svc); err != nil {
return ctrl.Result{}, fmt.Errorf("update service status (cache hit): %w", err)
}
return ctrl.Result{}, nil
}
jobName, err := r.Builder.Build(ctx, svc.Namespace, svc.Name, svc.Spec.S3Key)
if err != nil {
return r.setServiceFailed(ctx, svc, fmt.Sprintf("failed to start build: %v", err))
+167
View File
@@ -0,0 +1,167 @@
# Создано: 2026-04-04
# EMQX MQTT-брокер для IoT-сервиса (namespace: sless).
#
# Архитектура:
# IoT Device → MQTT CONNECT → EMQX (HTTP auth → sless-operator:9090/internal/mqtt/auth)
# EMQX → MQTT PUBLISH → sless-iot-bridge (paho subscriber) → RabbitMQ queue iot.{ns}.telemetry
# RabbitMQ → event-dispatcher → serverless function
#
# EMQX 5.x конфиг через emqx.conf (HOCON формат), монтируется как ConfigMap volume.
# НЕ используем env vars для конфигурации EMQX 5.x — они не поддерживаются аналогично 4.x.
#
# Порты:
# 1883 — MQTT (plaintext)
# 8883 — MQTTS (TLS, для prod надо настроить certSecret)
# 8083 — MQTT over WebSocket
# 18083 — EMQX Dashboard (admin/public по умолчанию — менять в prod!)
#
# Применение: kubectl apply -f deployments/k8s/emqx.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: emqx-config
namespace: sless
data:
# emqx.conf — HOCON конфиг для EMQX 5.5.x
# Раздел authentication: HTTP Backend для проверки MQTT credentials IoT-устройств.
# Наш сервис (sless-operator) ищет Secret iot-{deviceId} и сравнивает пароль.
emqx.conf: |
## EMQX 5.x configuration (HOCON format)
## Изменено: 2026-04-04
## HTTP Auth Backend для IoT-устройств
## EMQX посылает POST с {username, password, clientid} → наш сервис отвечает {"result":"allow"|"deny"}
authentication = [
{
mechanism = password_based
backend = http
enable = true
method = post
url = "http://sless-operator.sless.svc:9090/internal/mqtt/auth"
body {
username = "${username}"
password = "${password}"
clientid = "${clientid}"
}
headers {
"content-type" = "application/json"
}
connect_timeout = 5s
request_timeout = 5s
## allow_timeout_error = false — если наш сервис не отвечает, deny (безопаснее)
pool_size = 8
}
]
## ACL по умолчанию — разрешаем всё аутентифицированным клиентам
## Тонкая ACL настраивается через HTTP auth response (поле acl)
authorization {
no_match = allow
deny_action = disconnect
cache {
enable = true
max_size = 32
ttl = 1m
}
}
## MQTT настройки
mqtt {
max_packet_size = 1MB
max_topic_levels = 10
retain_available = false
}
## Listeners — только plaintext MQTT для MVP
## TLS (8883) отключён — настроить при необходимости
listeners.tcp.default {
bind = "0.0.0.0:1883"
max_connections = 1024
}
listeners.ws.default {
bind = "0.0.0.0:8083"
max_connections = 512
}
## Dashboard
dashboard {
listeners.http {
bind = 18083
}
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: emqx
namespace: sless
labels:
app: emqx
spec:
replicas: 1
selector:
matchLabels:
app: emqx
template:
metadata:
labels:
app: emqx
spec:
containers:
- name: emqx
image: emqx/emqx:5.5.1
ports:
- name: mqtt
containerPort: 1883
- name: ws
containerPort: 8083
- name: dashboard
containerPort: 18083
volumeMounts:
- name: emqx-conf
mountPath: /opt/emqx/etc/emqx.conf
subPath: emqx.conf
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
readinessProbe:
tcpSocket:
port: 1883
initialDelaySeconds: 20
periodSeconds: 10
timeoutSeconds: 5
livenessProbe:
tcpSocket:
port: 1883
initialDelaySeconds: 40
periodSeconds: 20
volumes:
- name: emqx-conf
configMap:
name: emqx-config
---
apiVersion: v1
kind: Service
metadata:
name: emqx
namespace: sless
spec:
selector:
app: emqx
ports:
- name: mqtt
port: 1883
targetPort: 1883
- name: ws
port: 8083
targetPort: 8083
- name: dashboard
port: 18083
targetPort: 18083
+69
View File
@@ -0,0 +1,69 @@
# Создано: 2026-04-04
# Deployment iot-mqtt-bridge — MQTT→RabbitMQ мост для IoT.
#
# Получает MQTT сообщения от EMQX (подписка на "+/telemetry/+")
# и публикует в RabbitMQ queue "iot.{namespace}.telemetry".
#
# Credentials для MQTT подключения берутся из Secret iot-bridge-credentials.
# Этот Secret нужно создать вручную ДО деплоя:
#
# # 1. Создать IoTDevice для bridge через API:
# curl -X POST .../v1/namespaces/sless-bridge/iot/devices \
# -d '{"name":"bridge","device_id":"bridge","enabled":true}'
#
# # 2. Получить credentials:
# MQTT_USERNAME=$(kubectl get secret iot-bridge -n sless-bridge -o jsonpath='{.data.mqtt-username}' | base64 -d)
# MQTT_PASSWORD=$(kubectl get secret iot-bridge -n sless-bridge -o jsonpath='{.data.mqtt-password}' | base64 -d)
#
# # 3. Создать Secret для bridge Deployment (один раз):
# kubectl create secret generic iot-bridge-credentials -n sless \
# --from-literal=MQTT_USERNAME="$MQTT_USERNAME" \
# --from-literal=MQTT_PASSWORD="$MQTT_PASSWORD"
#
# Применение: kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: iot-mqtt-bridge
namespace: sless
labels:
app: iot-mqtt-bridge
spec:
replicas: 1
selector:
matchLabels:
app: iot-mqtt-bridge
template:
metadata:
labels:
app: iot-mqtt-bridge
spec:
containers:
- name: mqtt-bridge
image: pearlharbor.registryk8s.services.ngcloud.ru/naeel/sless-operator:latest
# TODO: отдельный образ iot-mqtt-bridge После сборки через Makefile
imagePullPolicy: Always
command: ["/iot-mqtt-bridge"]
env:
- name: MQTT_BROKER_URL
value: "tcp://emqx.sless.svc:1883"
- name: RABBITMQ_URL
valueFrom:
secretKeyRef:
name: sless-operator-secret
key: RABBITMQ_URL
optional: true
envFrom:
- secretRef:
name: iot-bridge-credentials
resources:
requests:
memory: "32Mi"
cpu: "25m"
limits:
memory: "64Mi"
cpu: "100m"
imagePullSecrets:
- name: sless-registry-auth
+219
View File
@@ -0,0 +1,219 @@
# ERR-PG-08: Concurrent Operations Not Supported
## Problem Statement
After completing an Update operation on `nubes_postgres` resource (e.g., vault_secrets refresh), attempting to create any dependent resource immediately fails with API 422 error:
```
Error: Ошибка клиента
ошибка API 422: {
"DETAIL": "There is a started operation on this instance",
"TYPE": "about:blank",
"TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
}
```
Even though `WaitForOperation()` has returned successfully and the previous operation is marked as completed.
## Reproduction
1. Terraform plan detects vault_secrets has changed (external drift)
2. Execute update: `nubes_postgres.pg_test_instance: Modifying...`
3. Update completes: `nubes_postgres.pg_test_instance: Modifications complete after 0s`
4. Immediately try to create: `nubes_postgres_database.pg_test_db: Creating...`
5. **FAIL**: API returns 422 "Concurrent operations are not supported"
## Why It Happens
The Nubes API has an internal operation lock per instance. Even though the Update operation's `IsSuccessful` flag is true and operations are no longer in-progress, the API server is still processing asynchronous side effects:
- Vault credential updates
- Instance state synchronization
- Backend resource reconciliation
When the next Create operation is submitted, the lock is still held, causing the 422 error.
## Current Symptoms
- Affects: Any sequence where Update → Create operations happen on same instance
- Timing: Happens even with 120+ second waits
- Scope: Affects DB creation, user creation, any operation on PostgreSQL instance
- Test environment: Confirmed on `k8s-3-sandbox-nubes-ru` realm
- Production: Unknown (not tested)
## Workarounds (Current)
### Workaround 1: Split Resources Across Apply Cycles
Comment out dependent resource creation, apply first update, then uncomment and apply again:
```hcl
# postgres.tf
# temporarily comment out nubes_postgres_database block
# terraform apply ← creates pg_test_instance + users
# uncomment nubes_postgres_database block
# terraform apply ← creates pg_test_db
```
Already implemented in this project (see [postgres.tf lines 87-99](../examples/PG_TEST/postgres.tf#L87-L99)).
### Workaround 2: Add Explicit depends_on + relies on Terraform serialization
```hcl
resource "nubes_postgres_database" "pg_test_db" {
postgres_id = nubes_postgres.pg_test_instance.id
db_name = var.pg_db_name
db_owner = nubes_postgres_user.pg_test_user.username
# Explicit depends_on forces sequential execution
# but does NOT help with concurrent operation lock
depends_on = [nubes_postgres_user.pg_test_user3]
}
```
**Status**: Doesn't solve the problem - API still returns 422.
### Workaround 3: Manual Sequential Runs
```bash
# First apply - creates instance and users
terraform apply -auto-approve
# Wait manually (or check instance state)
sleep 180
# Second apply - creates databases
terraform apply -auto-approve
```
This is **unreliable** and not automatable.
## Root Cause Analysis
### Client-Side (Terraform Provider)
**File**: [`internal/provider/client_impl.go`](../../terra/terraform/internal/provider/client_impl.go) line 240
```go
func (c *NubesClient) WaitForOperation(ctx context.Context, opUid string) error {
timeout := time.After(15 * time.Minute)
ticker := time.NewTicker(10 * time.Second)
// ...
// Checks every 10 seconds for operation completion
if !op.IsInProgress && !op.IsPending && op.DtFinish != nil {
if op.IsSuccessful != nil && *op.IsSuccessful {
return nil // ← Returns immediately when successful
}
}
}
```
**Problem**: No post-completion delay or retry logic for subsequent operations.
### Server-Side (Nubes API)
The API maintains an operation lock on the instance that:
1. Is released when operation completes (`IsSuccessful = true`)
2. **But** async background tasks are still running during the lock release window
3. New requests during this window: "There is a started operation on this instance"
This is an **intentional safety measure** against corrupting instance state, but the window between "operation done" and "instance ready for next operation" is not deterministic.
## Solutions (For Provider Fix)
### Option 1: Add Post-Completion Delay
**Pros**: Simple, guaranteed to work
**Cons**: Always adds overhead, even if not needed
```go
// In client_impl.go, after "return nil" on success:
if op.IsSuccessful != nil && *op.IsSuccessful {
// Add buffer for API server to release internal locks
time.Sleep(30 * time.Second) // or configurable
return nil
}
```
**Recommended value**: `30-60 seconds` based on observations.
### Option 2: Implement Retry Mechanism
**Pros**: No unnecessary delays, adapts to actual API response time
**Cons**: More complex, needs careful timeout/backoff tuning
When next operation fails with "concurrent operations", retry with exponential backoff:
```go
func (c *NubesClient) CreateResourceWithRetry(ctx context.Context, payload map[string]interface{}) error {
maxRetries := 5
backoff := 10 * time.Second
for i := 0; i < maxRetries; i++ {
err := c.Create(ctx, payload)
if err == nil {
return nil
}
if strings.Contains(err.Error(), "Concurrent operations") {
time.Sleep(backoff)
backoff *= 2 // exponential backoff
continue
}
return err
}
}
```
**Backoff suggestion**: Start 10s, cap at 60s.
### Option 3: Query Instance State Before Next Operation
**Pros**: Most elegant, confirms instance is ready
**Cons**: Requires additional API call, might still be unreliable
```go
func (c *NubesClient) WaitForInstanceReady(ctx context.Context, instanceId string) error {
// Poll instance state directly, not just operation state
for retry := 0; retry < 30; retry++ {
state, err := c.GetInstanceState(ctx, instanceId)
if err == nil && state.IsReady {
return nil
}
time.Sleep(5 * time.Second)
}
return fmt.Errorf("instance not ready after timeout")
}
```
## Recommendation
**Implement Option 1 (Post-Completion Delay)** combined with **Option 2 (Retry Logic)**:
1. Add fixed 30-second delay after `WaitForOperation` returns success (**fail-safe**)
2. Keep retry mechanism for cases where clients don't respect the delay (**defensive**)
This provides both reliability (fixed delay) and robustness (retry on failure).
## Testing
**Test case**:
```bash
cd examples/PG_TEST
# Uncomment pg_test_db in postgres.tf
terraform apply -auto-approve
# Should NOT fail with 422 "Concurrent operations are not supported"
# Should create all 3 resources: instance, users, database
```
**Current status**: ❌ FAILS with 422
**After fix**: ✅ SHOULD PASS
## References
- Provider source: `/home/naeel/terra/terraform/internal/provider/`
- Test configuration: `/home/naeel/terra/sless/examples/PG_TEST/`
- Related: ERR-PG-02 (fixed), ERR-PG-03 (race condition), ERR-PG-04 (invalid role)
- Vault credentials: Not involved in this error (different subsystem)
---
**Date discovered**: 2026-04-03
**Status**: Open, blocker for multi-resource deployments
**Priority**: High (blocks full lifecycle automation)
**Scope**: Test environment confirmed, production unknown
+170
View File
@@ -0,0 +1,170 @@
# Session Report: PostgreSQL Discovery - April 3, 2026
## Session Overview
**Duration**: Single session, April 3, 2026
**Focus**: Root cause analysis of PostgreSQL terraform lifecycle tests failures
**Outcome**: 2 major problems identified and documented
---
## Key Findings
### 1. ERR-PG-02: FIXED ✅
**Previously**: ID going to `(known after apply)` during Update operations
**Status**: Already fixed in current provider code (`internal/provider/postgres_resource.go` line ~845)
- Code now explicitly preserves ID from state during Update
- No longer reproducible - no destroy+recreate of dependent resources
**Verification**: `terraform plan` shows `0 to destroy` (correct behavior)
---
### 2. ERR-PG-06: RECLASSIFIED 🔄
**Previously**: Claimed that only 1 user per PostgreSQL instance could be created with vault_secrets
**Corrected Finding**: Multiple users work fine when properly configured
- Successfully created `pg_test_user` (user0) and `pg_test_user3` (u3)
- Both have vault_secrets successfully populated
**Root Cause of Original Error**: Lack of `depends_on` between user resources → race condition in Vault writes
**Solution**: Strict `depends_on` chain between users is required and works perfectly
---
### 3. ERR-PG-08: NEW PROBLEM ❌
**Description**: After Update operation completes (even successfully), creating dependent resources fails with 422 "Concurrent operations are not supported"
**Symptoms**:
```
Error: Ошибка клиента
ошибка API 422: {
"TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
}
```
**Root Cause**: Nubes API maintains internal lock on instance even after operation completion. Post-operation async tasks (Vault sync, state reconciliation) still run.
**Impact**: Cannot create databases or additional users immediately after instance update in same Terraform apply
**Workaround Found**: Split apply into phases (comment out DB resource, apply, uncomment, apply again)
**Requires**: Provider fix - add post-completion delay or retry mechanism in `WaitForOperation()` method
---
## Documentation Created
1. **[/home/naeel/remote_dev/sless/doc/ERR-PG-08-concurrent-operations.md](./ERR-PG-08-concurrent-operations.md)**
- Detailed problem analysis
- 3 solution options (fixed delay, retry mechanism, instance state query)
- Recommendation: combine options 1 + 2
2. **Updated [/home/naeel/remote_dev/sless/doc/errors/log.md](./errors/log.md)**
- Added corrections to ERR-PG-06 (multi-user now works)
- Added new section for ERR-PG-08 (concurrent ops limitation)
3. **Updated [/home/naeel/remote_dev/sless/doc/pg-terraform-behavior.md](./pg-terraform-behavior.md)**
- Table (section 6) updated: shows 2nd/3rd user creation now works
- Added section 3.5: detailed ERR-PG-08 explanation
- Corrected: "2 users per instance" now says "Works with depends_on"
---
## Terraform Configuration Status
**Current Setup** (`examples/PG_TEST`):
-`nubes_postgres` instance created successfully
-`pg_test_user` (user0) created successfully
-`pg_test_user3` (u3) created successfully
-`pg_test_db` cannot be created (blocked by ERR-PG-08)
**Workaround Applied**:
- [x] Commented out `nubes_postgres_database` resource block (lines 87-99)
- [x] Updated outputs.tf to disable database-dependent outputs
- [x] Successfully applied (0 added, 1 changed, 0 destroyed)
**Status**: Awaiting provider fix to re-enable database creation
---
## Provider Source Files
**Identified locations** for fix:
- `/home/naeel/terra/terraform/internal/provider/client_impl.go` line 240
- `WaitForOperation()` method needs post-completion handling
- Current: returns immediately on `IsSuccessful = true`
- Needed: add delay or retry mechanism
- `/home/naeel/terra/terraform/internal/provider/postgres_resource.go` line 617+
- Update() method (already has ERR-PG-02 fix)
- Would benefit from handling ERR-PG-08 retries
---
## Next Steps (For Future Sessions)
1. **Priority FIX**: Implement post-completion delay in `WaitForOperation()`
- Add 30-60 second sleep after success return
- Or implement exponential backoff retry for 422 errors
2. **Testing**: After fix applied
- Re-enable `nubes_postgres_database` in postgres.tf
- Verify `terraform apply` succeeds fully (0 destroyed)
- Run stress tests with multiple users and databases
3. **Documentation**: After fix verified
- Update `pg-terraform-behavior.md` table (remove ERR-PG-08 workaround)
- Mark ERR-PG-08 as "FIXED"
- Update provider-fix-plan.md with implementation details
4. **Codebase**: Commit changes
- Provider fix in `/home/naeel/terra/terraform/`
- Documentation updates in `/home/naeel/remote_dev/sless/`
---
## Files Modified This Session
### In `/home/naeel/remote_dev/sless/`
- ✅ [doc/ERR-PG-08-concurrent-operations.md](./doc/ERR-PG-08-concurrent-operations.md) — CREATED (new)
- ✅ [doc/errors/log.md](./doc/errors/log.md) — UPDATED (added corrections + ERR-PG-08)
- ✅ [doc/pg-terraform-behavior.md](./doc/pg-terraform-behavior.md) — UPDATED (table + section 3.5)
- ⚠️ [examples/PG_TEST/postgres.tf](./examples/PG_TEST/postgres.tf) — MODIFIED (commented out DB)
- ⚠️ [examples/PG_TEST/outputs.tf](./examples/PG_TEST/outputs.tf) — MODIFIED (disabled DB outputs)
### On VM `/home/naeel/terra/`
- No code changes (only investigation)
- Terraform state reflects multi-user success
- Provider source examined but not modified
---
## Lessons Learned
1. **Multi-user creation works** when using proper `depends_on` chains
2. **Vault limitation hypothesis was wrong** - it was a race condition issue
3. **Concurrent operations limit is real** and requires provider-level fix
4. **Provider already has one fix** (ERR-PG-02 id preservation) - shows active maintenance
5. **Test environment is functional** despite appearing to fail initially
---
## Technical Debt
- [ ] ERR-PG-08 requires provider fix (not blocking test framework, blocking full automation)
- [ ] Consider: Is concurrent operations lock intentional safety feature? Document if so.
- [ ] Consider: Add configurable retry delays for production resilience
---
**Session Status**: COMPLETE - Major findings documented, actionable recommendations provided
**Ready For**: Next programmer to implement provider fix based on documented analysis
+132
View File
@@ -2,6 +2,138 @@
---
## 2026-04-01 — PG_TEST: lifecycle ignore_changes для vault_secrets — НЕ РАБОТАЕТ
### Попытка
Добавить в `nubes_postgres` блок `lifecycle { ignore_changes = [vault_secrets] }`.
### Результат
Terraform выводит предупреждение и игнорирует директиву:
> "Including this attribute in ignore_changes has no effect."
`vault_secrets``Computed`-only атрибут (выставляется только провайдером),
для таких атрибутов `ignore_changes` не применимо.
### Механизм проблемы
При `vault_secrets` "изменённом снаружи" Terraform обновляет `nubes_postgres` in-place,
но в плане выставляет `id = (known after apply)`. Дочерние ресурсы с `postgres_id`
(ссылка на `nubes_postgres.*.id`) теряют resolved value → форсированный replace.
### Текущий статус
Открытая проблема. `lifecycle ignore_changes` убран из конфигурации (не помогает).
Рабочий обходной путь на данный момент: запускать `apply` только на чистом state.
---
## 2026-04-01 — PG_TEST: depends_on chain вместо параллельного создания
### Решение
Все ресурсы `nubes_postgres_user` и `nubes_postgres_database` создаются строго
последовательно через явную цепочку `depends_on`:
```
nubes_postgres → pg_test_user → pg_test_db → extra_user1 → extra_user2 → extra_db1 → extra_db2
```
### Почему
Nubes API (deck-api-test.ngcloud.ru) не поддерживает параллельные операции создания
пользователей на одном PG-инстансе — возникает race condition на стороне Vault:
конкурентные записи в один Secret дают "Секрет не был создан" / "key doesn't exist".
Terraform по умолчанию выполняет независимые ресурсы параллельно (degree=10).
`depends_on` — единственный способ принудить последовательность без добавления
искусственных атрибутов-зависимостей.
---
## 2026-04-01 — PG_TEST: роль пользователя — только ddl_user
### Решение
В конфигурациях `examples/PG_TEST` используется только роль `ddl_user` для ресурсов
`nubes_postgres_user`. Роль `app_user` из конфигурации удалена.
### Почему
При создании `nubes_postgres_user` с `role = "app_user"` Nubes API (версия v5.0.51)
возвращает ошибку "Секрет для пользователя не был создан" после ~3 минут ожидания.
Воспроизводится стабильно. Роль `ddl_user` работает корректно.
Вывод: `app_user` либо не поддерживается в `nubes_postgres_user`, либо требует
другой конфигурации (не задокументированной). До выяснения — только `ddl_user`.
---
## 2026-03-30 — Переход на READ-ONLY подход в тестах (v2)
### Решение
Полностью переписан `vm_stress_test.sh`. Убраны все функции записи в файлы
(`write_tfvars`, `backup_tfvars`, `restore_tfvars`). Переопределения переменных
теперь через `-var` в terraform CLI. Добавлена проверка md5sum terraform.tfvars.
### Почему
Функция `write_tfvars()` в v1 уничтожила `terraform.tfvars`, потеряв JWT-токен
`api_token`. Пайплайн `grep | cut | xargs | sed` не смог корректно обработать
JWT строку длиной 1200+ символов. Восстановление потребовало ручного вмешательства.
### Ключевые принципы v2:
- Скрипт **НИКОГДА** не пишет в файлы (read-only)
- Все переопределения — через `terraform apply -var "key=value"`
- md5sum проверка после каждой фазы, аварийный стоп при изменении
- `terraform.tfvars` содержит секреты (api_token) → нельзя трогать
---
## 2026-03-30 — Автономный тестовый фреймворк для VM
### Решение
Внедрить bash-скрипт `vm_stress_test.sh` как основной инструмент для долгого, самовосстанавливающегося тестирования примера `examples/VM`.
### Почему
- Предыдущие ручные тесты подтвердили корректность логики, но для выявления редких race conditions и обеспечения преемственности между разными сессиями агентов нужен воспроизводимый сценарий.
- Скрипт инкапсулирует все "знания" о VM (IP, ключи, логика очистки `apt`), позволяя любому агенту запустить тест одной командой.
- Использование `timeout` на уровне команд `terraform` и `ssh` внутри скрипта предотвращает зависание автоматизации.
## 2026-03-29 — Матрица тестов VM example подтверждена прогоном
### Решение
Оставить текущую модель тестирования [examples/VM](examples/VM) как комбинацию из ручного cleanup, destroy/apply цикла, частичного отключения job-ресурсов и короткого stress loop.
### Почему
- Эта матрица проверяет и lifecycle VM, и идемпотентность job-ресурсов, и реакцию на изменение количества/порядка установок.
- Отдельный destroy/apply прогон подтвердил suspend/wake поведение без необходимости писать новый тестовый фреймворк.
- Stress loop из двух циклов дал полезную нагрузку без чрезмерного времени прогона.
## 2026-03-29 — Матрица тестов для VM example
### Решение
Для проверки поведения [examples/VM](examples/VM) использовать не один прогон, а набор сценариев:
1. обычный `apply` как базовый контроль;
2. удаление всего установленного ПО внутри ВМ перед `destroy`;
3. `destroy` с проверкой перехода ВМ в `suspend`;
4. повторный `apply` с проверкой wake-up и повторной установки;
5. изменение количества и порядка установок;
6. стресс-прогоны с несколькими повторениями.
### Почему так
- Один проход не показывает идемпотентность и не ловит проблемы порядка ресурсов.
- Сценарий с `destroy` проверяет, что инфраструктура не удаляет ВМ физически, а переводит её в `suspend`.
- Повторный `apply` после `suspend` проверяет восстановление состояния без ручного вмешательства.
- Перестановки и изменение количества установок нужны, чтобы проверить устойчивость к дрейфу и к разным графам зависимостей.
---
## 2026-03-21 — Оценка трудозатрат на проект
| Компонент | Оценка |
+500
View File
@@ -0,0 +1,500 @@
# План-инструкция: sless_job функции для установки ПО в ВМ
> 2026-03-29 — Инструкция для AI-агента (GPT/Claude/Codex).
> Цель: демонстрация заказчику связки Terraform + Serverless.
> Один `terraform apply` — поднимается vApp/VM + автоматически устанавливается ПО.
---
## Контекст: что уже есть
```
examples/VM/
├── main.tf # provайдер nubes, переменные (api_token, vm_public_key)
├── vapp.tf # nubes_vapp.vapp — контейнер ВМ
├── vm.tf # nubes_vc_vm_v3.vm — Ubuntu 22.04, 2CPU/2GB/20GB
├── terraform.tfvars # токены (gitignored)
├── vm_key / vm_key.pub # SSH-ключ для ВМ
└── .terraform/ # init уже выполнен
```
**ВМ поднята и работает.** IP: `nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]`.
SSH: `ssh -i vm_key ubuntu@<IP>`.
Платформа sless поднята: оператор v0.1.62, API `https://sless.kube5s.ru`.
---
## Что нужно сделать
Добавить в `examples/VM/` sless-провайдер и набор `sless_job` ресурсов, которые по SSH
устанавливают ПО на ВМ. Пользователь шаблона включает нужные флагами.
### Целевой результат для заказчика
```bash
cd examples/VM
# пользователь выставляет флаги:
# install_docker = true
# install_postgres = true
terraform apply
# → vApp + VM создаются (или уже есть)
# → джобы подключаются по SSH и ставят Docker, PostgreSQL и т.д.
# → outputs показывают статус каждого шага
```
---
## Архитектура: СТРОГО sless_job
- Каждая установка = отдельный `sless_job` (one-shot, execution task).
- НЕ создавать `sless_service` (у функций-установщиков нет постоянного URL).
- НЕ создавать новый Terraform resource — только `sless_job`.
- Передача параметров: `env_vars` — для подключения (IP, ключ), `event_json` — для бизнес-логики.
---
## Файловая структура (целевая)
```
examples/VM/
├── main.tf # + добавить provider "sless"
├── vapp.tf # без изменений
├── vm.tf # без изменений
├── variables.tf # NEW — все переменные (включая флаги install_*)
├── sless.tf # NEW — provider sless + sless_job ресурсы
├── outputs.tf # NEW — outputs статусов джобов
├── terraform.tfvars # + добавить sless_token, флаги
├── functions/ # NEW — код функций-установщиков
│ ├── install-packages/
│ │ ├── handler.py
│ │ └── requirements.txt # paramiko
│ ├── install-docker/
│ │ ├── handler.py
│ │ └── requirements.txt
│ └── install-postgres/
│ ├── handler.py
│ └── requirements.txt
├── vm_key / vm_key.pub
└── .terraform/
```
---
## Контракт Python handler для sless_job
```python
# handler.py — загружается в контейнер как /app/function/handler.py
# Рантайм: python3.11
# Вызывается один раз, результат = JSON → записывается в job.message
import os
def install(event):
"""
event — dict из event_json Terraform-ресурса.
os.environ — содержит env_vars из Terraform-ресурса.
Возврат:
dict/list → JSON (phase=Succeeded, message=json)
raise Exception → phase=Failed, message=traceback
"""
vm_ip = os.environ["VM_IP"]
ssh_user = os.environ["SSH_USER"]
ssh_key = os.environ["SSH_KEY"] # содержимое приватного ключа (PEM)
packages = event.get("packages", [])
# ... SSH + установка ...
return {"status": "ok", "installed": packages}
```
---
## Спецификация каждой функции
### 1. install-packages (Этап A — первый)
**Назначение:** Универсальный apt-установщик. Ставит произвольный список пакетов.
**handler.py** — entrypoint: `handler.install`
```
event_json:
packages: ["git", "curl", "htop", "..."] # обязательно — список имён пакетов apt
update: true # опционально — apt update перед install (default: true)
env_vars:
VM_IP: nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
SSH_USER: "ubuntu"
SSH_KEY: file("${path.module}/vm_key")
requirements.txt:
paramiko
```
**Логика:**
1. Подключиться по SSH через paramiko (ключ из env var, не из файла на диске).
2. `sudo apt-get update` (если event.update != false).
3. `sudo DEBIAN_FRONTEND=noninteractive apt-get install -y <packages>`.
4. Проверить `dpkg -l <package>` для каждого.
5. Вернуть `{"status": "ok", "installed": [...], "already_installed": [...], "failed": [...]}`.
**Обработка ошибок:**
- SSH connection refused → retry 3 раза с шагом 10 сек (ВМ может ещё грузиться).
- apt lock → retry 5 раз с шагом 15 сек.
- Частичный фейл (2 из 5 пакетов не найдены) → status="partial", failed=[...].
- Полный фейл → raise Exception с читаемым сообщением.
**Идемпотентность:** Повторный запуск безопасен — apt-get install -y ничего не ломает.
### 2. install-docker (Этап A)
**Назначение:** Docker CE + docker-compose plugin по официальной инструкции.
**handler.py** — entrypoint: `handler.install`
```
event_json:
compose: true # опционально — ставить ли docker-compose plugin (default: true)
env_vars:
VM_IP, SSH_USER, SSH_KEY — те же
requirements.txt:
paramiko
```
**Логика:**
1. SSH → проверить `docker --version`. Если уже есть — вернуть `{"status": "already_installed", ...}`.
2. Добавить Docker apt-репозиторий (GPG ключ + sources.list).
3. `apt-get install docker-ce docker-ce-cli containerd.io`.
4. Если compose=true → `apt-get install docker-compose-plugin`.
5. `sudo usermod -aG docker $SSH_USER`.
6. Проверить: `docker run hello-world`.
7. Вернуть `{"status": "ok", "docker_version": "...", "compose": true/false}`.
**Идемпотентность:** Проверяет наличие перед установкой.
### 3. install-postgres (Этап B)
**Назначение:** PostgreSQL сервер + создание БД и пользователя.
**handler.py** — entrypoint: `handler.install`
```
event_json:
pg_version: "14" # опционально (default: "14")
db_name: "myapp" # обязательно — имя БД
db_user: "app_user" # обязательно — имя пользователя
db_password: "secure_pass" # обязательно — пароль
listen_addresses: "*" # опционально (default: "localhost")
allow_remote: true # опционально — добавлять ли в pg_hba.conf (default: false)
env_vars:
VM_IP, SSH_USER, SSH_KEY — те же
requirements.txt:
paramiko
```
**Логика:**
1. SSH → проверить `psql --version`. Если нет:
- `apt-get install postgresql postgresql-contrib postgresql-client`.
2. `systemctl is-active postgresql` — убедиться что запущен.
3. Создать пользователя: `sudo -u postgres psql -c "CREATE USER ... PASSWORD ..."` (IF NOT EXISTS).
4. Создать БД: `sudo -u postgres psql -c "CREATE DATABASE ... OWNER ..."` (IF NOT EXISTS).
5. Если allow_remote: настроить `listen_addresses` в postgresql.conf + запись в pg_hba.conf.
6. `systemctl restart postgresql` (если конфиг менялся).
7. Проверить подключение: `psql -h localhost -U <user> -d <db> -c "SELECT 1"`.
8. Вернуть `{"status": "ok", "pg_version": "14.x", "db_name": "myapp", ...}`.
**Идемпотентность:** IF NOT EXISTS для пользователя и БД. Config-записи — grep перед append.
---
## Terraform: sless.tf (скелет)
```hcl
# 2026-03-29 — sless.tf: sless_job функции для установки ПО на ВМ.
# Каждый job подключается по SSH и ставит ПО.
provider "sless" {
endpoint = "https://sless.kube5s.ru"
token = var.sless_token
}
# --- Общие локальные переменные ---
locals {
vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
ssh_user = "ubuntu"
ssh_key = file("${path.module}/vm_key")
# Общий набор env_vars для SSH-подключения к ВМ
ssh_env = {
VM_IP = local.vm_ip
SSH_USER = local.ssh_user
SSH_KEY = local.ssh_key
}
}
# --- 1. Базовые пакеты ---
resource "sless_job" "install_packages" {
count = var.install_packages ? 1 : 0
name = "vm-install-packages"
runtime = "python3.11"
entrypoint = "handler.install"
source_dir = "${path.module}/functions/install-packages"
env_vars = local.ssh_env
event_json = jsonencode({
packages = var.base_packages
})
run_id = var.install_run_id
wait_timeout_sec = 600
depends_on = [nubes_vc_vm_v3.vm]
}
# --- 2. Docker ---
resource "sless_job" "install_docker" {
count = var.install_docker ? 1 : 0
name = "vm-install-docker"
runtime = "python3.11"
entrypoint = "handler.install"
source_dir = "${path.module}/functions/install-docker"
env_vars = local.ssh_env
event_json = jsonencode({
compose = true
})
run_id = var.install_run_id
wait_timeout_sec = 900
depends_on = [
nubes_vc_vm_v3.vm,
sless_job.install_packages # пакеты первыми
]
}
# --- 3. PostgreSQL ---
resource "sless_job" "install_postgres" {
count = var.install_postgres ? 1 : 0
name = "vm-install-postgres"
runtime = "python3.11"
entrypoint = "handler.install"
source_dir = "${path.module}/functions/install-postgres"
env_vars = local.ssh_env
event_json = jsonencode({
pg_version = var.pg_version
db_name = var.pg_db_name
db_user = var.pg_db_user
db_password = var.pg_db_password
allow_remote = var.pg_allow_remote
})
run_id = var.install_run_id
wait_timeout_sec = 900
depends_on = [
nubes_vc_vm_v3.vm,
sless_job.install_packages # базовые пакеты первыми
]
}
```
## Terraform: variables.tf (скелет)
```hcl
# 2026-03-29 — variables.tf: все переменные для examples/VM.
# --- Nubes (уже есть, перенести из main.tf) ---
variable "api_token" { type = string; sensitive = true }
variable "vm_public_key" { type = string; sensitive = true }
# --- Sless ---
variable "sless_token" {
type = string
sensitive = true
description = "JWT-токен для sless API"
}
# --- Флаги установки ---
variable "install_packages" {
type = bool
default = true
description = "Установить базовые apt-пакеты"
}
variable "install_docker" {
type = bool
default = false
description = "Установить Docker CE"
}
variable "install_postgres" {
type = bool
default = false
description = "Установить PostgreSQL"
}
# --- Параметры ---
variable "base_packages" {
type = list(string)
default = ["git", "curl", "htop", "jq", "unzip"]
description = "Список apt-пакетов для install-packages"
}
variable "install_run_id" {
type = number
default = 1
description = "Увеличить для повторного запуска всех install-джобов"
}
# --- PostgreSQL ---
variable "pg_version" { type = string; default = "14" }
variable "pg_db_name" { type = string; default = "myapp" }
variable "pg_db_user" { type = string; default = "app_user" }
variable "pg_db_password" { type = string; sensitive = true; default = "" }
variable "pg_allow_remote" { type = bool; default = false }
```
## Terraform: outputs.tf (скелет)
```hcl
# 2026-03-29 — outputs.tf: статусы установки.
output "install_packages_result" {
value = var.install_packages ? sless_job.install_packages[0].message : "skipped"
}
output "install_docker_result" {
value = var.install_docker ? sless_job.install_docker[0].message : "skipped"
}
output "install_postgres_result" {
value = var.install_postgres ? sless_job.install_postgres[0].message : "skipped"
}
```
---
## Порядок выполнения для агента
### Фаза 1: Инфраструктура Terraform (4 файла)
1. Создать `variables.tf` — все переменные (перенести из main.tf + новые).
2. Создать `sless.tf` — провайдер sless + 3 ресурса sless_job.
3. Создать `outputs.tf` — статусы.
4. Обновить `main.tf` — вынести переменные в variables.tf, добавить required_providers sless.
> **Проверка:** `terraform validate` должен пройти.
### Фаза 2: Функция install-packages (1 функция, полный E2E)
1. Создать `functions/install-packages/handler.py`.
2. Создать `functions/install-packages/requirements.txt` (paramiko).
3. Добавить `sless_token` в `terraform.tfvars`.
4. `terraform apply` с `install_packages = true`.
5. Убедиться: `phase = Succeeded`, пакеты установлены на ВМ.
> **Это ключевой момент.** Если install-packages прошёл E2E — паттерн работает, остальные функции аналогичны.
### Фаза 3: Функции install-docker и install-postgres
1. Создать `functions/install-docker/handler.py` + `requirements.txt`.
2. Создать `functions/install-postgres/handler.py` + `requirements.txt`.
3. `terraform apply` с `install_docker = true, install_postgres = true`.
4. Проверить: Docker установлен, PostgreSQL работает, БД создана.
### Фаза 4: Полировка и README
1. Обновить `README.md` — как использовать шаблон с sless.
2. `terraform apply` с нуля (destroy + apply) — весь цикл.
---
## SSH через paramiko — референсный паттерн
```python
# Этот блок — основа для всех handler.py. Копировать и адаптировать.
import os, io, time
import paramiko
def _ssh_connect(retries=3, delay=10):
"""Подключение к ВМ по SSH. Retry при connection refused (ВМ грузится)."""
key = paramiko.Ed25519Key.from_private_key(io.StringIO(os.environ["SSH_KEY"]))
for attempt in range(retries):
try:
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(
hostname=os.environ["VM_IP"],
username=os.environ["SSH_USER"],
pkey=key,
timeout=15,
)
return client
except Exception as e:
if attempt == retries - 1:
raise RuntimeError(f"SSH connection failed after {retries} attempts: {e}")
time.sleep(delay)
def _ssh_run(client, cmd, check=True):
"""Выполнить команду. При check=True — бросить ошибку если exit_code != 0."""
stdin, stdout, stderr = client.exec_command(cmd, timeout=300)
exit_code = stdout.channel.recv_exit_status()
out = stdout.read().decode().strip()
err = stderr.read().decode().strip()
if check and exit_code != 0:
raise RuntimeError(f"Command failed (exit {exit_code}): {cmd}\nstderr: {err}")
return exit_code, out, err
```
---
## Ограничения и подводные камни
1. **SSH через внешний IP** — Sless-поды находятся в k8s кластере `kube5s.ru`, VM — в Nubes vDC.
Эти сети **не связаны напрямую**. Используем `externalConnect` (публичный IP).
`internalConnect` (`10.x.x.x`) доступен только внутри Nubes vDC — из sless-подов он недостижим.
> **TODO для DevOps облака Nubes:** обсудить организацию внутреннего трафика между
> k8s кластером и Nubes vDC — VPN/peering/dedicated link. До решения — только внешний IP.
> Когда появится внутренний маршрут — заменить `externalConnect` → `internalConnect` в locals.
В `sless.tf`:
```hcl
# TODO: заменить на internalConnect когда DevOps настроят сеть между кластером и vDC
vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
```
2. **SSH_KEY в env_var** — Содержимое приватного ключа передаётся как env var (строка).
paramiko умеет читать из `io.StringIO`. Не писать в файл.
2. **apt lock** — Если apt уже заблокирован (unattended-upgrades), будет ошибка.
Retry с проверкой `/var/lib/dpkg/lock-frontend`.
3. **depends_on обязателен** — ВМ должна быть готова до запуска job.
`depends_on = [nubes_vc_vm_v3.vm]`. Без этого terraform может запустить параллельно.
4. **run_id для повторного запуска** — sless_job не перезапускается автоматически.
Чтобы перезапустить: `install_run_id = 2` → `terraform apply`.
5. **wait_timeout_sec** — Kaniko-сборка + выполнение. 600с для мелких пакетов, 900с для Docker/PG.
6. **Vault пока нет** — Секреты (pg_password, ssh_key) передаются через tfvars.
Архитектура готова к замене на Vault data source позже (env_vars заполняются из vault).
7. **Drift не отслеживается** — Job-модель ≠ полноценный stateful resource.
Если кто-то удалит Docker на ВМ — Terraform не знает. Перезапуск: увеличить run_id.
+487
View File
@@ -4,6 +4,493 @@
---
## 2026-04-01 — Nubes PostgreSQL API: ошибки при создании ресурсов (PG_TEST)
Все ошибки воспроизводились в `examples/PG_TEST` при тестировании провайдера
`terra.k8c.ru/nubes/nubes` v5.0.51. VM: `naeel@5.172.178.213`, PG-инстанс: `pg-test-02`.
---
### ERR-PG-01: "Invalid JSON String" при создании инстанса с json_parameters
**Симптом**
```
Error: Ошибка клиента
with nubes_postgres.pg_test_instance
Invalid JSON String
```
**Причина**
При передаче параметра `json_parameters` (строка JSON с кастомными настройками PG)
Nubes API v5 возвращает "Invalid JSON String" независимо от корректности самого JSON.
Вероятно — баг в провайдере или несовместимость формата с deck-api-test.
**Решение**
Убран `json_parameters` из конфигурации `nubes_postgres`. PG запускается
с дефолтными параметрами движка. При необходимости custom params — требует
диагностики на стороне Nubes (`.api_endpoint = deck-api-test.ngcloud.ru`).
**Файл:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf)
---
### ERR-PG-02: vault_secrets меняется вне Terraform → destroy+recreate всей цепочки
**Симптом**
Каждый `terraform apply` обнаруживает изменения "снаружи Terraform":
```
Note: Objects have changed outside of Terraform
# nubes_postgres.pg_test_instance has changed
~ vault_secrets = (sensitive value)
```
Это вызывает план с `-/+ destroy and then create replacement` для `pg_test_user`
и `pg_test_db`, хотя реально они не изменились.
**Причина**
Nubes API обновляет `vault_secrets` (путь к Vault с паролями пользователей)
каждый раз при создании/удалении пользователей. Terraform видит это как
"изменение снаружи" и считает `postgres_id` изменённым (т.к. он `(known after apply)`
после обновления инстанса), что форсирует замену всех дочерних ресурсов.
**Попытка решения**
Добавить `lifecycle { ignore_changes = [vault_secrets] }`**не работает**.
Terraform выводит предупреждение:
> "The attribute vault_secrets is decided by the provider alone and therefore
> there can be no configured value to compare with. Including this attribute
> in ignore_changes has no effect."
`vault_secrets` — Computed-only (провайдер его полностью контролирует),
`ignore_changes` для таких атрибутов игнорируется.
**Реальная причина** destroy+recreate: при обнаружении `vault_secrets` как
"изменённого снаружи" Terraform обновляет `nubes_postgres` in-place, но
в плане ставит `id = (known after apply)` — это форсирует замену зависимых
ресурсов у которых `postgres_id` ссылается на `nubes_postgres.*.id`.
**Статус: открытая проблема.** Обходной путь — выполнять `apply` только на
чистом state (без накопленных изменений снаружи). После первого полного
`apply` с `lifecycle ignore_changes` убран как неэффективный.
**Файл:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf)
---
### ERR-PG-03: Race condition при параллельном создании пользователей
**Симптом**
При одновременном создании двух и более `nubes_postgres_user` на одном инстансе:
```
Error: Ошибка клиента
with nubes_postgres_user.test_extra_user1
операция XXXX завершилась с ошибкой: Секрет для пользователя extra_user1 не был создан
```
Или:
```
операция XXXX завершилась с ошибкой: key doesn't exist
```
**Причина**
Nubes API не поддерживает параллельное создание пользователей на одном PG-инстансе.
Внутри Nubes: каждое создание пользователя пишет в Vault, а Vault/Deck
не справляются с конкурентными записями в один Secret.
**Решение**
Принудительная последовательная цепочка через `depends_on`:
```
pg_test_user → pg_test_db → extra_user1 → extra_user2 → extra_db1 → extra_db2
```
Каждый `nubes_postgres_user` и `nubes_postgres_database` явно ждёт предыдущий.
`depends_on` нужен даже если прямой ссылки на атрибуты нет.
**Файлы:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf),
[examples/PG_TEST/postgres_extra.tf](examples/PG_TEST/postgres_extra.tf)
---
### ERR-PG-04: Роль app_user не работает для nubes_postgres_user
**Симптом**
```
Error: Ошибка клиента
with nubes_postgres_user.test_app_user,
операция XXXX завершилась с ошибкой: Секрет для пользователя test_app_user не был создан
```
Ресурс висит ~3 минуты перед ошибкой. Воспроизводится стабильно.
**Причина**
Роль `app_user` не поддерживается для создания PostgreSQL пользователей
через `nubes_postgres_user` в данной версии провайдера/API. Возможно, роль
предусмотрена только для другого механизма доступа.
**Решение**
Использовать только роль `ddl_user` для ресурса `nubes_postgres_user`.
Создание пользователей с `app_user` — не работает на `deck-api-test.ngcloud.ru`.
Из конфигурации удалён ресурс `nubes_postgres_user.test_app_user`.
---
### ERR-PG-05: "Нарушена консистентность" — пользователь есть в API, нет в state_out
**Симптом**
```
Error: Нарушена консистентность
with nubes_postgres_user.test_extra_user1
Операция вернула duplicate/exist, но объект не найден в state_out
```
**Причина**
Пользователь `extra_user1` был создан Nubes API на предыдущей (упавшей) попытке apply.
Terraform state не зафиксировал успех (т.к. apply завершился ошибкой), но Nubes
счётной записью `extra_user1` не удалил.
Флаг `adopt_existing_on_create = true` должен был решить это, но он проверяет
`state_out` инстанса — а там пользователь не отражается (из-за ERR-PG-02:
`vault_secrets` изменялся и инстанс был в "changed outside" состоянии).
**Решение**
Полный `terraform destroy` для очистки state + ресурсов в API, затем
`terraform apply` с уже включённым `lifecycle { ignore_changes = [vault_secrets] }`.
После этого проблема не воспроизводится.
---
### ERR-PG-06: Второй пользователь на инстансе не может получить vault_secrets
**Симптом**
При создании второго пользователя на PG-инстансе (первый уже существует):
```
Error: Ошибка клиента
with nubes_postgres_user.test_extra_user1
операция 4D816F17-F43E-4062-AE37-5098ADE07041 завершилась с ошибкой:
Секрет для пользователя test_eu1 не был создан
```
Ресурс висит ~3–4 минуты, затем падает с этой ошибкой. Воспроизводится стабильно
для любого второго пользователя (проверено на `extra_user1`, `test_eu1`)
независимо от роли (`ddl_user`), имени и порядка depends_on.
**Важно**: `pg_test_user` (первый пользователь, созданный при инициализации
инстанса) всегда успешно проходит через adoption за 1 секунду — его vault_secret
уже был создан при первом apply. Только создание **нового** второго пользователя
всегда приводит к этой ошибке.
**Причина**
Vault backend для PG-инстанса `e0e74801` (тест-окружение `k8s-3-sandbox-nubes-ru`)
вероятно ограничен одной vault-записью на инстанс. При попытке создать vault_secrets
для второго пользователя — запись не создаётся, провайдер возвращает ошибку через
~3–4 минуты ожидания.
Либо vault policy для данного инстанса предусмотрена только для основного
пользователя (`user0`). Дополнительные пользователи не имеют прав vault-path.
**Статус: открытая проблема, требует диагностики на стороне Nubes.**
**Следствие для архитектуры**:
В текущем тест-окружении Nubes PostgreSQL поддерживает **только одного пользователя
с vault_secrets** на инстанс. Lifecycle-тесты с несколькими пользователями
(**goal** текущей сессии) — **невозможны** без исправления vault-конфигурации.
**Файл:** [examples/PG_TEST/postgres_extra.tf](examples/PG_TEST/postgres_extra.tf)
---
### ERR-PG-07: HTTP 408 от IAM API (auth-api-test.ngcloud.ru)
**Симптом**
```
Error: Ошибка клиента
with nubes_postgres_user.pg_test_user
ошибка API 408: {"IAM URL":"https://auth-api-test.ngcloud.ru/api/v1/auth/user",
"idpResponse":{"prefix":{"status_text":"Request Time-out","statuscode":"408 Request Time-out"}}}
```
Может проявляться даже на этапе `terraform plan` (refresh инстанса).
**Причина**
Транзитная перегрузка тест-IAM-сервиса `auth-api-test.ngcloud.ru`. Возникает
после серии интенсивных apply/destroy в течение одного или нескольких часов.
**Решение**
Подождать 5–10 минут и повторить apply. Ошибка проходит самостоятельно.
**Важно**: в production окружении (`auth-api.ngcloud.ru`) эта проблема
предположительно не воспроизводится.
---
## 2026-04-03 — Коррекции и новые находки (PostgreSQL续)
### ERR-PG-02: id=(known after apply) при Update — ИСПРАВЛЕНО ✅
**Статус обновления**: Проблема уже решена в текущей версии провайдера.
**Где было**: `internal/provider/postgres_resource.go` Update() метод устанавливал `id = (known after apply)`
**Как исправлено**: Строка ~845 добавлена явная сохранение ID:
```go
// fix: plan.ID is Computed (empty in plan), must preserve existing ID from state
plan.ID = state.ID
```
**Проверка**: `terraform plan` больше НЕ показывает destroy+recreate зависимых ресурсов.
**Результат плана (ответно)**: `Plan: 0 to add, 1 to change, 0 to destroy` (только update, без replace)
**Вывод**: ERR-PG-02 не актуален для текущей версии провайдера.
---
### ERR-PG-06: Второй пользователь — ПЕРЕКВАЛИФИЦИРОВАНО 🔄
**Изменение статуса**: ERR-PG-06 была НЕВЕРНО диагностирована.
**Что было думано**: "Vault backend ограничен одним пользователем на инстанс"
**Что обнаружено**: `pg_test_user3` (u3) успешно создан в terraform state! Это второй пользователь на инстансе `pg-test-02`.
**Проверки**:
```bash
terraform state list
# Output:
# nubes_postgres.pg_test_instance
# nubes_postgres_user.pg_test_user ← user0
# nubes_postgres_user.pg_test_user3 ← u3 (УСПЕШНО)
```
**Статус**: Многопользовательское создание **РАБОТАЕТ** при правильной последовательности `depends_on`.
**Реальная проблема**: Не в создании пользователей, а в том что файл `postgres_extra.tf` с третьим пользователем был переименован в `postgres_extra.tf11` (бэкап), и текущий конфиг не имел этого файла.
**Вывод**: ERR-PG-06 была следствием неполного тестирования, а не действительным ограничением API.
---
### ERR-PG-08: Concurrent Operations Are Not Supported ❌ НОВАЯ ПРОБЛЕМА
**Симптом**
После успешного завершения Update операции на `nubes_postgres`, попытка создать
зависимый ресурс (например БД) немедленно падает с ошибкой 422:
```
Error: Ошибка клиента
with nubes_postgres_database.pg_test_db
ошибка API 422: {
"DETAIL": "There is a started operation on this instance",
"TYPE": "about:blank",
"TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
}
```
**Когда воспроизводится**
1. `terraform plan` обнаруживает изменения (например, `vault_secrets` drift)
2. Apply запускает Update инстанса: `nubes_postgres.pg_test_instance: Modifying...`
3. Update успешно завершается: `Modifications complete after 0s`
4. Terraform пытается создать DB: `nubes_postgres_database.pg_test_db: Creating...`
5. **FAIL**: 422 Concurrent operations
**Попытки обхода (неуспешные)**
- Добавлен `depends_on = [pg_test_user3]` — не помогло ✗
- Ожидание 60 секунд между apply'ами — не помогло ✗
- Ожидание 120 секунд — не помогло ✗
**Причина**
Nubes API имеет встроенный serial-lock на операции per-instance. Даже хотя
`WaitForOperation()` возвращает `IsSuccessful = true`, сервер всё ещё обрабатывает
асинхронные побочные эффекты (Vault sync, state reconciliation и тд). Новые запросы
на операции отклоняются с 422 до полного завершения.
**Текущий workaround**
Разбить apply на несколько фаз вручную:
```bash
# Фаза 1: создание инстанса + пользователей (без БД)
cp postgres.tf postgres.tf.bak
sed -i '/resource.*nubes_postgres_database/,/^}/d' postgres.tf
terraform apply -auto-approve
# Фаза 2: добавить БД обратно и применить
cp postgres.tf.bak postgres.tf
terraform apply -auto-approve
```
**Статус**: Открытая проблема в провайдере. Требует fix на уровне `WaitForOperation()`.
**Рекомендуемое решение**: Добавить post-completion delay (3060 сек) или retry mechanism
в `internal/provider/client_impl.go` метод `WaitForOperation`.
**Файл для анализа**: [`internal/provider/client_impl.go` line 240+](../../terra/terraform/internal/provider/client_impl.go#L240)
**Документация**: [ERR-PG-08-concurrent-operations.md](ERR-PG-08-concurrent-operations.md)
---
## 2026-03-29 — SSH timeout после destroy VM example
### Симптом
После `terraform destroy` для [examples/VM](examples/VM) попытка зайти по SSH на target VM завершилась таймаутом:
- `ssh: connect to host 185.247.187.154 port 22: Connection timed out`
### Причина
Это ожидаемое поведение для сценария suspend: VM перестаёт отвечать по SSH после destroy, а затем поднимается обратно на `terraform apply`.
### Что сделали
- Подтвердили, что `terraform apply` после destroy восстанавливает доступ и повторно запускает install jobs.
---
## 2026-03-26 — БАГ ГЕНЕРАТОРА: modify-only поля помечаются Required в schema ресурса
```
Error: Missing required argument
on vc_org.tf line 5, in resource "nubes_vc_org" "dev_org":
5: resource "nubes_vc_org" "dev_org" {
The argument "v_i_p_configure" is required, but no definition was found.
The argument "resource_name" is required, but no definition was found.
```
### Причина
Генератор (`~/terra/terraform/devops/`) при создании Go-кода ресурса (`19_vc_org_resource.go`)
помечает **все операции ресурса** как `Required` в схеме, включая поля,
которые нужны только для операции `modify` (не для `create`).
Конкретный пример: `vIPConfigure` (код параметра 662) — это поле операции `modify`,
но попадает в schema с `Required: true`:
```go
"v_i_p_configure": schema.StringAttribute{Required: true},
```
В YAML-описании сервиса (19_vc_org.yaml) `vIPConfigure` объявлен только под
`operations.modify.params`, а не под `operations.create.params`.
### Что нужно исправить в генераторе
В `~/terra/terraform/devops/` (файлы `02_generate_resources_and_docs*.go/sh`):
Поля, принадлежащие только операции `modify` (или другим не-create операциям),
должны генерироваться как **`Optional: true, Computed: true`**, а не `Required: true`.
Логика:
- поле в `operations[create].params``Required: true`
- поле только в `operations[modify].params``Optional: true, Computed: true`
- поле только в state (read-only) → `Computed: true`
### Временный workaround (действующий)
В `terraform.tf`-манифесте указывать пустую строку:
```hcl
v_i_p_configure = "" # modify-only поле; при create не отправляется в API
```
Провайдер при Create не передаёт это поле в API (строка 418/556 params),
но schema.Required требует non-null значение в плане.
### Файлы для правки
- `~/terra/terraform/devops/profiles/test/generated/go/19_vc_org_resource.go` — сгенерированный, не менять вручную
- **Править нужно шаблоны/генераторы** в `~/terra/terraform/devops/`
---
## 2026-03-22 — БАГ: CreateService/CreateFunction возвращает 409 при `terraform apply -replace` (ИСПРАВЛЕН)
### Симптом
```
terraform apply -replace=sless_service.pg_info
sless_service.pg_info: Destroying... [name=pg-info]
sless_service.pg_info: Destruction complete
sless_service.pg_info: Creating...
Error: create service: status 409: {"error":"service already exists"}
```
Все 22+ сервиса из `-replace` падают с 409 при пересоздании.
### Точная причина
**Цепочка событий** (воспроизводится только при наличии finalizer):
1. `terraform` вызывает `DELETE /services/pg-info`
2. API делает `h.K8s.Delete(svc)` → k8s **НЕ удаляет объект** немедленно.
Вместо этого — выставляет `DeletionTimestamp` на объекте и ждёт.
3. `service_controller.go` (асинхронно!) обрабатывает удаление:
- сносит Deployment, k8s Service, Ingress
- затем вызывает `svc.Finalizers = removeString(svc.Finalizers, serviceFinalizerName)`
- только после этого k8s реально удаляет CRD объект из etcd
- **латентность: 1–5 секунд**
4. `terraform` **немедленно** вызывает `POST /services/pg-info`
5. API делает `h.K8s.Create(svc)` → etcd возвращает `IsAlreadyExists`
6. Старый код проверял: `phase == Failed`? → нет, было `Ready``shouldRecreate=false`**409**
**Ключевое: объект существует с `DeletionTimestamp != zero`, то есть он уже "мёртвый", но finalizer ещё не снят. Старый код этого не проверял.**
### Файл с багом
`internal/api/handler/services.go``CreateService()` — строка `shouldRecreate`
`internal/api/handler/functions.go``CreateFunction()` — аналогичная логика
### Исправление
В обоих файлах добавлена проверка `!existing.DeletionTimestamp.IsZero()` **до** проверки `shouldRecreate`:
```go
if getErr == nil && !existing.DeletionTimestamp.IsZero() {
// Объект удаляется: polling каждую секунду до 30 сек
for i := 0; i < 30; i++ {
time.Sleep(1 * time.Second)
if errors.IsNotFound(h.K8s.Get(...)) {
// исчez — создаём
}
}
// таймаут — возвращаем 409 с "try again later"
}
```
### Почему именно polling, а не Watch
`http.ResponseWriter` не поддерживает long-poll без дополнительного механизма.
Watch на объект внутри HTTP handler — антипаттерн (использует goroutine leak при отмене).
30 × 1s — достаточно для любого разумного кластера; terraform имеет свой retry.
---
## 2026-03-22 — ПОВЕДЕНИЕ: оператор выставляет Ready до готовности pod (known limitation)
### Симптом
+193
View File
@@ -0,0 +1,193 @@
# PG_TEST — инфраструктура тестирования Nubes PostgreSQL
Создан: 2026-04-01
---
## Цель
Набор Terraform-манифестов для тестирования провайдера `nubes` (ресурсы PostgreSQL).
Покрывает: создание инстанса, управление пользователями и базами данных, lifecycle-операции.
Также используется как шаблон для передачи заказчикам — достаточно вписать
`api_token`, `s3_uid`, `realm` в `terraform.tfvars`.
---
## Расположение
| Место | Путь |
|---|---|
| Локально | `/home/naeel/remote_dev/sless/examples/PG_TEST/` |
| На VM | `/home/naeel/terra/sless/examples/PG_TEST/` |
| VM | `naeel@5.172.178.213` |
| SSH-ключ | `secrets/naeel_vm_id_ed25519` |
> **Правило:** все `terraform` команды выполняются только на VM через SSH.
> Локально — только редактирование файлов + `scp` для синхронизации.
---
## Файловая структура
```
examples/PG_TEST/
├── main.tf # провайдер nubes + переменные
├── postgres.tf # инстанс + базовый пользователь + база
├── postgres_extra.tf # доп. пользователи и базы для lifecycle-тестов
├── outputs.tf # host, port, user, password, DSN
├── terraform.tfvars # рабочие значения (не в git, токен и IDs)
├── terraform.tfvars.example # шаблон для заказчика (masked placeholders)
└── test_lifecycle.sh # скрипт последовательного lifecycle-тестирования
```
---
## Провайдер
```hcl
terraform {
required_providers {
nubes = {
source = "terra.k8c.ru/nubes/nubes"
version = "5.0.51"
}
}
}
provider "nubes" {
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
api_token = var.api_token
}
```
---
## Ресурсы
### nubes_postgres (pg_test_instance)
- `resource_name = "pg-test-02"`
- `resource_realm = "k8s-3-sandbox-nubes-ru"`
- `app_version = "17"` (PostgreSQL 17)
- CPU: 500m, Memory: 512 MiB, Disk: 1 GiB
- `adopt_existing_on_create = true`
- `operation_timeout = "11m"`
- **`lifecycle { ignore_changes }`** — не решает проблему с `vault_secrets` (см. ERR-PG-02)
Инстанс ID: `e0e74801-d68e-4637-8ef3-d846b289846e`
### nubes_postgres_user
- Рабочая роль: **только `ddl_user`** (роль `app_user` не работает — ERR-PG-04)
- `adopt_existing_on_create = true`
- Пользователи создаются **строго последовательно** через `depends_on` (ERR-PG-03)
### nubes_postgres_database
- `adopt_existing_on_create = true`
- `db_owner` = username из `nubes_postgres_user`
- Создаётся после всех пользователей которые будут db_owner (через `depends_on`)
---
## Обязательная цепочка depends_on
Nubes API не поддерживает параллельные операции на одном PG инстансе.
Нарушение вызывает race condition в Vault (ERR-PG-03).
```
nubes_postgres
└─→ pg_test_user (ddl_user)
└─→ pg_test_db (owner=pg_test_user)
└─→ test_extra_user1 (ddl_user)
└─→ test_extra_user2 (ddl_user)
└─→ test_extra_db1 (owner=extra_user1)
└─→ test_extra_db2 (owner=extra_user2)
```
---
## Переменные (terraform.tfvars)
| Переменная | Описание | Пример |
|---|---|---|
| `api_token` | JWT токен Nubes API | `eyJ...` |
| `s3_uid` | UUID S3 bucket для бэкапов PG | `332cdb0d-...` |
| `realm` | realm кластера | `k8s-3-sandbox-nubes-ru` |
| `pg_resource_name` | имя PG инстанса | `pg-test-02` |
| `pg_username` | имя основного пользователя | `user0` |
| `pg_db_name` | имя основной базы данных | `db0` |
| `pg_role` | роль основного пользователя | `ddl_user` |
---
## Команды
Все команды — через SSH на VM:
```bash
SSH="ssh -i /home/naeel/remote_dev/sless/secrets/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no naeel@5.172.178.213"
TF="cd /home/naeel/terra/sless/examples/PG_TEST &&"
# Применить конфигурацию
$SSH "$TF terraform apply -auto-approve"
# Проверить state
$SSH "$TF terraform state list"
# Посмотреть outputs
$SSH "$TF terraform output"
# Удалить все ресурсы
$SSH "$TF terraform destroy -auto-approve"
```
Синхронизация файлов на VM:
```bash
scp -i secrets/naeel_vm_id_ed25519 examples/PG_TEST/postgres.tf \
naeel@5.172.178.213:/home/naeel/terra/sless/examples/PG_TEST/postgres.tf
```
---
## Известные ограничения API
| # | Проблема | Статус |
|---|---|---|
| ERR-PG-01 | `json_parameters` — "Invalid JSON String" | обойдено: убран параметр |
| ERR-PG-02 | `vault_secrets` обновляется вне TF | открытая проблема: `ignore_changes` не эффективен |
| ERR-PG-03 | Race condition при параллельном создании users | обойдено: `depends_on` chain |
| ERR-PG-04 | Роль `app_user` — "Секрет не был создан" | не работает, используем только `ddl_user` |
| ERR-PG-05 | "Нарушена консистентность" при stale state | решение: `terraform destroy` + rebuild |
Подробности: [doc/errors/log.md](doc/errors/log.md)
---
## Ожидаемые времена операций
| Операция | Примерное время |
|---|---|
| Создание `nubes_postgres_user` | ~5075 секунд |
| Удаление `nubes_postgres_user` | ~5676 секунд |
| Создание `nubes_postgres_database` | ~4770 секунд |
| Удаление `nubes_postgres_database` | ~46–92 секунды |
| Обновление `nubes_postgres` in-place | мгновенно (~0s) |
Полный `apply` с 6 новыми ресурсами занимает **~812 минут**.
---
## Lifecycle-тест (test_lifecycle.sh)
Скрипт тестирует последовательность операций:
1. **Создать всё** — apply базовой конфигурации + extra
2. **Удалить user2 + db2** — закомментировать ресурсы, apply
3. **Воссоздать** — раскомментировать, apply
4. **Сменить db_owner** — extra_db1.owner: extra_user1 → extra_user2
5. **Невалидные параметры** — db_owner = несуществующий пользователь (ожидать ошибку API)
Запуск: `$SSH "cd /home/naeel/terra/sless/examples/PG_TEST && bash test_lifecycle.sh"`
+739
View File
@@ -0,0 +1,739 @@
# IoT MVP — План реализации для Sonnet
> **Автор плана**: GitHub Copilot (Claude Opus 4.6)
> **Дата**: 2026-04-04
> **Исполнитель**: Claude Sonnet
> **Ход рассуждений**: `doc/thinking/2026-04-04.md`
---
## Контекст
Платформа **sless** — managed serverless functions. Нужно добавить **managed IoT service** как демо с возможностью усложнения.
### Согласованные решения
| Вопрос | Решение | Обоснование |
|--------|---------|-------------|
| Репозиторий | Та же репа, код в `iot/` | Легко вынести потом, удобно для демо |
| Message broker IoT | RabbitMQ (MVP), потом Kafka | RabbitMQ уже есть, архитектура broker-agnostic |
| Message broker sless | RabbitMQ (не трогать) | Работает, отдельный fault domain |
| MQTT-брокер | EMQX, деплой plain YAML | Не Helm, не Operator — достаточно для демо |
| IoT-логика | CRD + controller (Go operator) | Консистентно с sless, сразу правильно |
| Terraform | Расширяем текущий sless provider | Для демо ОК, переименование потом |
| Device auth | EMQX HTTP Auth Backend → наш API | Динамическое добавление устройств |
### Что НЕ делаем (отложено)
- Device Shadow / Digital Twin
- Rules Engine (для демо — простая маршрутизация topic→queue)
- Time-series storage (функция сама пишет в Postgres)
- Cloud→Device commands
- Client certificates (для демо: username/password)
- Dashboard
---
## Существующая архитектура (НЕ ТРОГАТЬ)
```
Go module: gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless
API Group: sless.kube5s.ru/v1alpha1
Namespace pattern: sless-{sha256(jwt.sub)[:16]}
Контроллеры (main.go, строки 153-184):
- FunctionReconciler
- ServiceReconciler
- TriggerReconciler
- FunctionJobReconciler
API-сервер: internal/api/router.go (gorilla/mux), порт cfg.APIPort
- JWT auth middleware → namespace validation
- Routes: /v1/namespaces/{namespace}/functions|services|triggers|jobs
Trigger types: "http", "cron", "event" (api/v1alpha1/trigger_types.go)
Event-dispatcher: services/event-dispatcher/ (AMQP consumer → POST в функцию)
RabbitMQ: deployments/k8s/rabbitmq.yaml (namespace: sless)
```
---
## Целевая архитектура MVP
```
IoT Device
→ MQTT connect (username=deviceId, password=deviceSecret)
→ EMQX (topic: {namespace}/telemetry/{deviceId})
→ EMQX RabbitMQ Bridge → RabbitMQ (queue: iot.{namespace})
→ event-dispatcher (существующий!) → POST → serverless function
→ function обрабатывает данные
Аутентификация устройств:
EMQX HTTP Auth Plugin → GET http://sless-iot-auth.sless.svc:8080/mqtt/auth
→ проверка credentials из k8s Secret → ACL (только свой namespace в topics)
```
---
## Этапы реализации
### Этап 1: CRD IoTDevice и контроллер
**Цель**: зарегистрировать IoT-устройство через CRD, автоматически создать credentials.
#### 1.1. Создать CRD типы
Файл: `iot/api/v1alpha1/device_types.go`
```go
package v1alpha1
import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)
// IoTDeviceSpec — спецификация IoT-устройства
type IoTDeviceSpec struct {
// DeviceID — уникальный идентификатор устройства внутри namespace
DeviceID string `json:"deviceId"`
// Metadata — произвольные метаданные устройства (модель, локация и т.д.)
// +optional
Metadata map[string]string `json:"metadata,omitempty"`
// Enabled — активно ли устройство (может подключаться к MQTT)
// +kubebuilder:default=true
Enabled bool `json:"enabled"`
}
// IoTDeviceStatus — статус IoT-устройства
type IoTDeviceStatus struct {
// Phase — текущее состояние: Pending, Active, Disabled, Error
Phase string `json:"phase,omitempty"`
// MQTTUsername — имя пользователя для подключения к MQTT
MQTTUsername string `json:"mqttUsername,omitempty"`
// SecretName — имя k8s Secret с credentials
SecretName string `json:"secretName,omitempty"`
// TopicPrefix — разрешённый prefix для MQTT topics
TopicPrefix string `json:"topicPrefix,omitempty"`
// LastConnected — время последнего подключения (заполняется auth-сервисом)
// +optional
LastConnected *metav1.Time `json:"lastConnected,omitempty"`
// Message — человекочитаемое сообщение о статусе
Message string `json:"message,omitempty"`
}
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:printcolumn:name="DeviceID",type=string,JSONPath=`.spec.deviceId`
// +kubebuilder:printcolumn:name="Phase",type=string,JSONPath=`.status.phase`
// +kubebuilder:printcolumn:name="Enabled",type=boolean,JSONPath=`.spec.enabled`
type IoTDevice struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec IoTDeviceSpec `json:"spec,omitempty"`
Status IoTDeviceStatus `json:"status,omitempty"`
}
// +kubebuilder:object:root=true
type IoTDeviceList struct {
metav1.TypeMeta `json:",inline"`
metav1.ListMeta `json:"metadata,omitempty"`
Items []IoTDevice `json:"items"`
}
```
Файл: `iot/api/v1alpha1/groupversion_info.go`
```go
package v1alpha1
import (
"k8s.io/apimachinery/pkg/runtime/schema"
"sigs.k8s.io/controller-runtime/pkg/scheme"
)
var (
// GroupVersion — API group для IoT ресурсов
// ВАЖНО: отдельный group от sless.kube5s.ru — для будущего разделения
GroupVersion = schema.GroupVersion{Group: "iot.kube5s.ru", Version: "v1alpha1"}
SchemeBuilder = &scheme.Builder{GroupVersion: GroupVersion}
AddToScheme = SchemeBuilder.AddToScheme
)
func init() {
SchemeBuilder.Register(&IoTDevice{}, &IoTDeviceList{})
}
```
**ВАЖНО**: API group `iot.kube5s.ru` — отдельная от `sless.kube5s.ru`. Причина: при разделении на отдельную репу CRD не будет конфликтовать.
#### 1.2. Сгенерировать deepcopy и CRD манифесты
```bash
# Из корня проекта:
controller-gen object paths=./iot/api/v1alpha1/...
controller-gen crd paths=./iot/api/v1alpha1/... output:crd:dir=iot/config/crd/bases
```
#### 1.3. Создать контроллер IoTDevice
Файл: `iot/controllers/iotdevice_controller.go`
Логика Reconcile:
1. Получить IoTDevice из пришедшего запроса
2. Если `DeletionTimestamp != nil` → удалить Secret, убрать finalizer
3. Добавить finalizer `iot.kube5s.ru/device-cleanup` если нет
4. Если `spec.enabled == false`:
- Установить `status.phase = "Disabled"`
- НЕ удалять Secret (устройство может быть включено обратно)
5. Если Secret не существует:
- Сгенерировать пароль (32 байта crypto/rand → hex)
- MQTTUsername = `{namespace}_{deviceId}` (namespace включён для уникальности MQTT username)
- Создать Secret `iot-{deviceId}` в том же namespace с полями:
- `mqtt-username`: `{namespace}_{deviceId}`
- `mqtt-password`: сгенерированный пароль
- Установить OwnerReference на IoTDevice (каскадное удаление)
6. Заполнить status:
- `phase = "Active"` (или "Disabled" если !enabled)
- `mqttUsername = {namespace}_{deviceId}`
- `secretName = iot-{deviceId}`
- `topicPrefix = {namespace}/` (устройство может публиковать только в topics с этим prefix)
#### 1.4. Зарегистрировать контроллер в main.go
Добавить в `main.go` после существующих SetupWithManager вызовов:
```go
if err = (&iotcontrollers.IoTDeviceReconciler{
Client: mgr.GetClient(),
Scheme: mgr.GetScheme(),
Log: ctrl.Log.WithName("controllers").WithName("IoTDevice"),
}).SetupWithManager(mgr); err != nil {
setupLog.Error(err, "unable to create controller", "controller", "IoTDevice")
os.Exit(1)
}
```
Добавить в import:
```go
iotv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1"
iotcontrollers "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/controllers"
```
Добавить schema registration в init/scheme:
```go
utilruntime.Must(iotv1alpha1.AddToScheme(scheme))
```
---
### Этап 2: MQTT Auth Service
**Цель**: EMQX при каждом MQTT CONNECT проверяет credentials через наш HTTP-сервис.
#### 2.1. Создать auth handler
Файл: `iot/internal/mqttauth/mqtt_auth_handler.go`
HTTP-сервис, отдельный порт (например 8081) или sub-router в основном API.
**Эндпоинт**: `POST /mqtt/auth` (вызывается EMQX HTTP Auth Plugin)
EMQX присылает JSON:
```json
{
"username": "sless-abc123def456_sensor-01",
"password": "hex-encoded-secret",
"clientid": "...",
"peerhost": "10.0.0.5"
}
```
Логика:
1. Распарсить username: `{namespace}_{deviceId}`
2. Найти Secret `iot-{deviceId}` в namespace `{namespace}`
3. Сравнить password с `mqtt-password` из Secret (constant-time comparison!)
4. Если совпало:
- Проверить что IoTDevice существует и `enabled == true`
- Вернуть 200 + JSON с ACL:
```json
{
"result": "allow",
"is_superuser": false,
"acl": [
{"permission": "allow", "action": "publish", "topic": "{namespace}/#"},
{"permission": "allow", "action": "subscribe", "topic": "{namespace}/#"},
{"permission": "deny", "action": "all", "topic": "#"}
]
}
```
5. Если не совпало → вернуть 200 + `{"result": "deny"}`
**ВАЖНО**: НЕ возвращать 401/403 — EMQX интерпретирует HTTP-ошибки как "ignore this backend, try next". Всегда 200, result = "allow"/"deny".
#### 2.2. Запустить auth-сервис
Два варианта (решить при реализации):
- **Вариант A**: отдельный binary `iot/cmd/mqtt-auth/main.go` + Deployment
- **Вариант B**: добавить route в существующий API-сервер (проще для демо)
Для демо — **вариант B**: добавить роут `/internal/mqtt/auth` в `internal/api/router.go`. Prefix `/internal/` = не защищён JWT (доступен только из кластера).
---
### Этап 3: Развёртывание EMQX
**Цель**: MQTT-брокер, принимающий подключения от IoT-устройств.
#### 3.1. Создать YAML
Файл: `deployments/k8s/emqx.yaml`
По аналогии с `deployments/k8s/rabbitmq.yaml`:
```yaml
# Деплой EMQX MQTT-брокера для IoT-сервиса
# 2026-04-04
apiVersion: v1
kind: ConfigMap
metadata:
name: emqx-config
namespace: sless
data:
# HTTP Auth Backend — аутентификация устройств через наш API
EMQX_AUTH__HTTP__AUTH_REQ__URL: "http://sless-api.sless.svc:8080/internal/mqtt/auth"
EMQX_AUTH__HTTP__AUTH_REQ__METHOD: "post"
EMQX_AUTH__HTTP__AUTH_REQ__CONTENT_TYPE: "json"
# RabbitMQ Bridge (MVP) — маршрутизация MQTT → RabbitMQ
# ПОТОМ заменится на Kafka bridge — только этот ConfigMap
EMQX_BRIDGE__RABBIT__SERVER: "amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: emqx
namespace: sless
spec:
replicas: 1
selector:
matchLabels:
app: emqx
template:
metadata:
labels:
app: emqx
spec:
containers:
- name: emqx
image: emqx/emqx:5.5.1
ports:
- name: mqtt
containerPort: 1883
- name: mqttssl
containerPort: 8883
- name: ws
containerPort: 8083
- name: dashboard
containerPort: 18083
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
envFrom:
- configMapRef:
name: emqx-config
readinessProbe:
tcpSocket:
port: 1883
initialDelaySeconds: 15
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: emqx
namespace: sless
spec:
selector:
app: emqx
ports:
- name: mqtt
port: 1883
targetPort: 1883
- name: ws
port: 8083
targetPort: 8083
- name: dashboard
port: 18083
targetPort: 18083
```
**ВНИМАНИЕ**: конфиг EMQX 5.x сильно отличается от 4.x. При реализации:
- Проверить актуальный формат env-переменных для EMQX 5.5
- HTTP Auth Plugin в EMQX 5 конфигурируется через Dashboard API или файл `etc/emqx.conf`
- Возможно понадобится volume mount для `emqx.conf` вместо env
#### 3.2. Настроить EMQX Rule + RabbitMQ Bridge
EMQX Rule Engine (конфигурируется через EMQX HTTP API или Dashboard):
```
Rule SQL:
SELECT * FROM '{namespace}/+/+'
Action:
Bridge to RabbitMQ
Exchange: amq.topic
Routing Key: iot.{namespace}
Queue: iot.{namespace}.telemetry
```
Для MVP — можно сконфигурировать одно правило вручную или через EMQX REST API при старте (init-container или наш контроллер).
**ВАЖНО для Sonnet**: EMQX 5.x использует `bridges` API — изучить документацию EMQX 5.5:
- `POST /api/v5/bridges` — создание bridge
- `POST /api/v5/rules` — создание правил
- Или файл `etc/emqx.conf` (HOCON формат)
---
### Этап 4: API-эндпоинты для IoT
**Цель**: REST API для управления устройствами (Terraform provider будет вызывать их).
#### 4.1. Добавить IoT-роуты в router.go
Файл: `internal/api/router.go`
Новые routes (защищены JWT, как существующие):
```
POST /v1/namespaces/{namespace}/iot/devices → CreateIoTDevice
GET /v1/namespaces/{namespace}/iot/devices → ListIoTDevices
GET /v1/namespaces/{namespace}/iot/devices/{name} → GetIoTDevice
DELETE /v1/namespaces/{namespace}/iot/devices/{name} → DeleteIoTDevice
PATCH /v1/namespaces/{namespace}/iot/devices/{name} → UpdateIoTDevice (enable/disable)
```
Internal route (без JWT, только для EMQX из кластера):
```
POST /internal/mqtt/auth → MQTTAuth
```
#### 4.2. Создать IoT handler
Файл: `iot/internal/api/iot_device_handler.go` (или добавить в `internal/api/handler/`)
Хендлеры = тонкая обёртка над k8s API:
- `CreateIoTDevice`: создаёт IoTDevice CRD объект → контроллер reconcile → Secret
- `GetIoTDevice`: читает IoTDevice CRD + возвращает credentials из Secret
- `DeleteIoTDevice`: удаляет IoTDevice CRD → контроллер cleanup через finalizer
- `ListIoTDevices`: list IoTDevice в namespace
- `UpdateIoTDevice`: patch spec.enabled
**GET /devices/{name}** должен возвращать credentials (mqtt_username, mqtt_password) из Secret. Они нужны пользователю для конфигурации устройства. Credentials возвращаются **только при GET**, не хранятся в CRD status.
---
### Этап 5: Связь MQTT → Serverless Function
**Цель**: IoT-устройство отправляет MQTT → вызывается serverless function.
#### 5.1. Цепочка
Пользователь создаёт через Terraform:
1. `sless_iot_device` → IoTDevice CRD → MQTT credentials
2. `sless_function` → Function → готовая serverless функция
3. `sless_trigger` type=event, queue="iot.{namespace}.telemetry" → event-dispatcher подписывается
Event-dispatcher (уже работает!) читает из RabbitMQ queue → POST в функцию.
#### 5.2. Автоматическое создание RabbitMQ queue
IoT-контроллер при reconcile должен обеспечить (ensure) существование queue `iot.{namespace}.telemetry` в RabbitMQ.
Варианты:
- **A**: Контроллер создаёт queue через RMQ Management API (HTTP) — явно
- **B**: Queue создаётся автоматически EMQX bridge + event-dispatcher consumer (declare on consume)
Для MVP — **вариант B**: и EMQX bridge, и event-dispatcher делают QueueDeclare — кто первый, тот и создаст. Дурак-proof.
---
### Этап 6: Terraform Provider
**Цель**: управление IoT-устройствами через Terraform.
Terraform provider sless находится в **отдельной репе**. Нужно расширить его.
Новый ресурс: `sless_iot_device`
```hcl
resource "sless_iot_device" "sensor_01" {
namespace = sless_namespace.my_ns.name
name = "temperature-sensor"
device_id = "sensor-01"
enabled = true
metadata = {
model = "DHT22"
location = "room-1"
}
}
output "mqtt_username" {
value = sless_iot_device.sensor_01.mqtt_username
}
output "mqtt_password" {
value = sless_iot_device.sensor_01.mqtt_password
sensitive = true
}
```
CRUD маппинг:
- Create → `POST /v1/namespaces/{ns}/iot/devices`
- Read → `GET /v1/namespaces/{ns}/iot/devices/{name}`
- Update → `PATCH /v1/namespaces/{ns}/iot/devices/{name}`
- Delete → `DELETE /v1/namespaces/{ns}/iot/devices/{name}`
---
### Этап 7: E2E Demo
**Цель**: показать полную цепочку device → function.
#### Demo Terraform:
```hcl
# 1. Функция-обработчик IoT данных
resource "sless_function" "iot_handler" {
namespace = var.namespace
name = "iot-handler"
runtime = "python3.11"
source_dir = "./iot-handler"
}
# 2. Event trigger: подписка на IoT queue
resource "sless_trigger" "iot_events" {
namespace = var.namespace
name = "iot-telemetry"
type = "event"
function_ref = sless_function.iot_handler.name
queue = "iot.${var.namespace}.telemetry"
enabled = true
}
# 3. IoT устройство
resource "sless_iot_device" "sensor" {
namespace = var.namespace
name = "demo-sensor"
device_id = "sensor-001"
enabled = true
}
output "mqtt_host" {
value = "emqx.sless.svc.cluster.local"
}
output "mqtt_username" {
value = sless_iot_device.sensor.mqtt_username
}
output "mqtt_password" {
value = sless_iot_device.sensor.mqtt_password
sensitive = true
}
```
#### Demo Python IoT handler (`iot-handler/handler.py`):
```python
def handler(event, context):
"""Обработчик IoT-телеметрии. Вызывается event-dispatcher при новом MQTT сообщении."""
import json
data = json.loads(event["body"])
print(f"Telemetry from device: {data}")
return {"statusCode": 200, "body": json.dumps({"processed": True})}
```
#### Demo MQTT client (для тестирования):
```bash
# Отправить MQTT сообщение (mosquitto_pub)
mosquitto_pub \
-h emqx.sless.svc.cluster.local \
-p 1883 \
-u "sless-abc123_sensor-001" \
-P "generated-password" \
-t "sless-abc123/telemetry/sensor-001" \
-m '{"temperature": 22.5, "humidity": 65}'
```
---
## Структура файлов (итого)
```
iot/
api/v1alpha1/
device_types.go # CRD IoTDevice
groupversion_info.go # API group iot.kube5s.ru/v1alpha1
zz_generated.deepcopy.go # сгенерировано controller-gen
config/
crd/bases/ # сгенерированные CRD YAML
controllers/
iotdevice_controller.go # Reconcile: Secret, credentials
internal/
mqttauth/
mqtt_auth_handler.go # HTTP Auth Backend для EMQX
deployments/k8s/
emqx.yaml # EMQX deployment (новый файл)
internal/api/
handler/
iot_devices.go # REST handlers для IoT devices (новый файл)
router.go # + IoT routes (редактирование)
main.go # + IoTDevice controller registration (редактирование)
examples/
IOT/ # Demo пример
main.tf
handler.py
```
---
## Порядок выполнения
```
1. CRD types + deepcopy + manifests (iot/api/)
2. IoTDevice controller (iot/controllers/)
3. Register controller в main.go (main.go)
4. CRD apply в кластер (kubectl apply)
5. MQTT Auth handler (iot/internal/mqttauth/)
6. REST API endpoints для IoT (internal/api/)
7. EMQX deployment YAML (deployments/k8s/emqx.yaml)
8. EMQX конфигурация (auth backend + RMQ bridge)
9. Terraform provider resource (отдельная репа)
10. E2E demo (examples/IOT/)
11. Тестирование: device → MQTT → function
```
---
## Что менять при переходе на Kafka (потом)
| Компонент | Изменение |
|-----------|-----------|
| EMQX bridge config | `rabbitmq` → `kafka` (ConfigMap) |
| Consumer | Новый `iot-event-consumer` (~200 строк Go) вместо event-dispatcher |
| Kafka deploy | Managed сервис или Strimzi в кластере |
| CRD / Controller | **БЕЗ ИЗМЕНЕНИЙ** |
| MQTT Auth | **БЕЗ ИЗМЕНЕНИЙ** |
| API endpoints | **БЕЗ ИЗМЕНЕНИЙ** |
| Terraform | **БЕЗ ИЗМЕНЕНИЙ** |
---
## Правила для Sonnet
1. **Читай `doc/thinking/2026-04-04.md`** — там полный ход рассуждений и обоснования
2. **Читай `.github/copilot-instructions.md`** — правила проекта
3. **НЕ трогай** существующий код sless (controllers/, services/, internal/) без крайней необходимости
4. **Комментарии обязательны** — дата, назначение функций, "почему" для нетривиальной логики
5. **Именование** — уникальные осмысленные имена (iot_device_handler, NOT handler)
6. **Пиши в `doc/thinking/`** свои мысли при решении
7. **EMQX конфиг** — обязательно проверить актуальный формат для EMQX 5.5.x
8. **Security**: constant-time password comparison, не логировать credentials, ACL-изоляция по namespace
---
## Справка для нового агента (чтобы не искать)
### Terraform provider
- Расположен **в этой же репе**: `terraform/provider/`
- Go module: `terraform-provider-sless` (свой go.mod: `terraform/provider/go.mod`)
- Структура:
```
terraform/provider/
main.go
go.mod
internal/
client/ # HTTP-клиент к sless API
provider/ # provider.go — регистрация ресурсов
resources/ # function_resource.go, trigger_resource.go, service_resource.go, job_resource.go
hack/
build-and-publish.sh
```
- Новый ресурс `sless_iot_device` добавлять в `terraform/provider/internal/resources/iot_device_resource.go`
- Зарегистрировать в `terraform/provider/internal/provider/provider.go`
### controller-gen
- Бинарь: `bin/controller-gen` (в корне репы)
- Генерация deepcopy: `./bin/controller-gen object paths=./iot/api/v1alpha1/...`
- Генерация CRD: `./bin/controller-gen crd paths=./iot/api/v1alpha1/... output:crd:dir=iot/config/crd/bases`
### Как зарегистрированы существующие контроллеры (пример из main.go)
```go
// main.go строки ~153-184
if err = (&controllers.FunctionReconciler{
Client: mgr.GetClient(),
Scheme: mgr.GetScheme(),
S3Client: s3Client,
Config: cfg,
}).SetupWithManager(mgr); err != nil {
setupLog.Error(err, "unable to create controller", "controller", "Function")
os.Exit(1)
}
```
Новый IoT контроллер регистрируется аналогично, после этого блока.
### Scheme registration (main.go)
```go
// Существующие:
utilruntime.Must(slessv1alpha1.AddToScheme(scheme))
// Добавить:
utilruntime.Must(iotv1alpha1.AddToScheme(scheme))
```
### Существующий handler паттерн (internal/api/handler/handler.go)
```go
type Handler struct {
K8s client.Client
Scheme *runtime.Scheme
S3 *minio.Client
PG *sql.DB
Log logr.Logger
Config *config.Config
}
```
IoT-хендлеры добавлять как методы того же Handler или создать отдельный IoTHandler.
### RabbitMQ connection string
- Dev: `amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672/`
- Secret: `sless-operator-secret`, ключ `RABBITMQ_URL`
### Event-dispatcher — как он подписывается на queue
- Файл: `services/event-dispatcher/dispatcher.go`
- QueueDeclare (durable=true) при Subscribe
- Consumer на queue → POST в `http://{functionRef}.{namespace}.svc.cluster.local:8080/`
- Ack при 2xx, Nack+requeue при ошибке
### EMQX 5.x — ключевые отличия от 4.x
- Конфиг: HOCON формат в `/opt/emqx/etc/emqx.conf`, NOT env variables для plugins
- Auth: конфигурируется через `authentication` секцию в emqx.conf или REST API `POST /api/v5/authentication`
- Bridges: REST API `POST /api/v5/bridges` или секция `bridges` в emqx.conf
- Rules: REST API `POST /api/v5/rules`
- Dashboard: порт 18083, default login admin/public
- **Sonnet должен зайти на https://www.emqx.io/docs/en/v5.5/ и проверить формат конфигурации**
+410
View File
@@ -0,0 +1,410 @@
# Отчёт: поведение Nubes PostgreSQL с Terraform
Дата: 2026-04-01
Провайдер: `terra.k8c.ru/nubes/nubes` v5.0.51
API: `https://deck-api-test.ngcloud.ru/api/v1/index.cfm`
Окружение: realm `k8s-3-sandbox-nubes-ru`, PG `pg-test-02` (PostgreSQL 17)
Конфигурация: [`examples/PG_TEST/`](../examples/PG_TEST/)
---
## 1. Создание инстанса (nubes_postgres)
### 1.1 Первое создание (clean state)
Работает. Создание выполняется асинхронно — провайдер поллит операцию до `operation_timeout`.
```
nubes_postgres.pg_test_instance: Creating...
nubes_postgres.pg_test_instance: Still creating... [00m10s elapsed]
...
nubes_postgres.pg_test_instance: Creation complete after Xm Ys
```
Тайминг в тестах не зафиксирован отдельно (инстанс "переиспользовался" между
попытками через `adopt_existing_on_create`).
### 1.2 adopt_existing_on_create
Флаг работает: если инстанс с таким `resource_name` уже существует в Nubes —
Terraform принимает его без ошибки и привязывает к state.
### 1.3 suspend_on_destroy = true (дефолтное поведение)
При `terraform destroy` инстанс **суспендится**, а не удаляется физически.
Видно из плана при destroy: `suspend_on_destroy = true`.
### 1.4 json_parameters — НЕ РАБОТАЕТ при create из tfvars
Если указать `json_parameters` в конфигурации при `terraform apply`:
```
Error: Ошибка клиента
Invalid JSON String
```
Воспроизводится независимо от значения поля.
**ОДНАКО**: после создания инстанса без `json_parameters` провайдер сам
заполняет его в state (`jsonParameters.log_connections = "off"` и т.д.) — значит
Nubes API ставит дефолты. При следующем apply план показывает `json_parameters`
в `+ resource` блоке (Computed default), но при выполнении apply это не вызывает
ошибку (поле уже применено провайдером через defaults).
**Вывод**: `json_parameters` в конфиге — не указывать. Nubes сам ставит дефолты.
### 1.5 vault_secrets — ключевая проблема идемпотентности
`vault_secrets` — Computed атрибут, заполняется провайдером. Nubes API обновляет
его значение после каждой операции с пользователями (создание/удаление переписывает
Vault Secret с паролями).
**Проблема**: при любом повторном `terraform apply` Terraform обнаруживает:
```
Note: Objects have changed outside of Terraform
# nubes_postgres.pg_test_instance has changed
~ vault_secrets = (sensitive value)
```
Это приводит к плану:
```
# nubes_postgres.pg_test_instance will be updated in-place
~ id = "e0e74801-..." -> (known after apply) ← id уходит в unknown!
# nubes_postgres_user.pg_test_user must be replaced ← потому что postgres_id unknown
# nubes_postgres_database.pg_test_db must be replaced ← аналогично
```
Каждый повторный apply = уничтожение и пересоздание всех дочерних ресурсов
(`nubes_postgres_user`, `nubes_postgres_database`).
**Попытка обхода через `lifecycle { ignore_changes = [vault_secrets] }`**:
Terraform выдаёт предупреждение и игнорирует директиву:
> "Including this attribute in ignore_changes has no effect."
`vault_secrets` — Computed-only (нет configured value для сравнения),
поэтому `ignore_changes` для него не применим по дизайну Terraform.
**Статус: открытая проблема.** Обходного пути на уровне конфигурации нет.
Корень — в реализации провайдера: id инстанса уходит в `(known after apply)`
при in-place update, что форсирует replace зависимых ресурсов.
---
## 2. Создание пользователей (nubes_postgres_user)
### 2.1 Нельзя создавать несколько пользователей одновременно
Terraform по умолчанию параллельно создаёт независимые ресурсы. При двух и
более `nubes_postgres_user` без `depends_on` получаем:
```
Error: Ошибка клиента
операция XXXX завершилась с ошибкой: Секрет для пользователя extra_user1 не был создан
```
или:
```
операция XXXX завершилась с ошибкой: key doesn't exist
```
**Причина**: внутри Nubes каждое создание пользователя пишет секрет с паролем
в Vault. Конкурентные записи в один Secret вызывают race condition.
**Решение**: строгий последовательный `depends_on` chain — каждый следующий
ресурс явно ждёт предыдущий, даже если прямых ссылок на атрибуты нет.
### 2.2 Тайминг создания
В тестах (декларации после предыдущих операций):
| Попытка | Время |
|---|---|
| pg_test_user (первая попытка) | ~52–75 сек |
| pg_test_user (повторные попытки) | ~52–83 сек |
| test_extra_user1 (чистый) | ~5290+ сек |
| test_extra_user1 (с зависшим состоянием) | ~3 мин 10 сек → Error |
Создание через несколько попыток занимает в среднем **~6090 секунд**.
### 2.3 Роль app_user — НЕ РАБОТАЕТ
```hcl
resource "nubes_postgres_user" "test_app_user" {
role = "app_user"
...
}
```
Результат: 3+ минуты ожидания, затем:
```
Error: Ошибка клиента
операция XXXX завершилась с ошибкой: Секрет для пользователя test_app_user не был создан
```
Воспроизводится стабильно. Роль `ddl_user` работает корректно.
**Вывод**: для `nubes_postgres_user` рабочая роль — только `ddl_user`.
Роль `app_user` либо не реализована для этого ресурса, либо требует
иного процесса создания.
### 2.4 adopt_existing_on_create при "зависшем" пользователе
Если пользователь был частично создан в Nubes (apply упал в середине операции),
то при следующем apply с `adopt_existing_on_create = true`:
```
Error: Нарушена консистентность
Операция вернула duplicate/exist, но объект не найден в state_out
```
**Провайдер не может принять существующего пользователя если его нет в `state_out`
инстанса**, даже с `adopt_existing_on_create = true`. `state_out` инстанса
обновляется Nubes только при успешном завершении операции — если операция зависла,
`state_out` не обновляется.
**Решение**: использовать другое имя пользователя (старое имя "замусорено"
в Nubes API до очистки на их стороне).
### 2.5 Тайминг удаления
| Ресурс | Время |
|---|---|
| nubes_postgres_user | 56 сек 1 мин 21 сек |
### 2.6 Только один пользователь с vault_secrets на инстанс (критическое ограничение)
**Наблюдение**: в тест-окружении `k8s-3-sandbox-nubes-ru` успешно создаётся
**только первый пользователь** на PG-инстансе. Второй пользователь (`test_eu1`,
`extra_user1` — любое имя) никогда не может получить `vault_secrets`:
```
Error: Ошибка клиента
with nubes_postgres_user.test_extra_user1
операция XXXX завершилась с ошибкой: Секрет для пользователя test_eu1 не был создан
```
Поведение: 3–4 минуты ожидания vault, затем ошибка. Воспроизводится 100% случаев
для 5+ попыток с разными именами и разными apply-сессиями.
**Первый пользователь (pg_test_user)** успешно проходит через adoption за ~1 сек —
его `vault_secrets` был создан при первом apply. Adoption не пересоздаёт vault-запись.
**Гипотеза**: Vault backend для данного PG-инстанса ограничен одной записью
(`user0`/основной пользователь). Vault policy не предусматривает путей для
дополнительных пользователей. Проблема на стороне конфигурации тест-окружения Nubes.
**Следствие**: lifecycle-тесты с несколькими пользователями в текущем тест-окружении
**невозможны без исправления vault-конфигурации на стороне Nubes**.
---
## 3. Создание баз данных (nubes_postgres_database)
### 3.1 Тайминг создания
| Ресурс | Время |
|---|---|
| nubes_postgres_database | 47 сек 1 мин 6 сек |
### 3.2 Тайминг удаления
| Ресурс | Время |
|---|---|
| nubes_postgres_database | 46 сек 1 мин 32 сек |
### 3.3 db_owner должен существовать к моменту создания БД
`db_owner` задаётся как `string` (имя пользователя). Если пользователь не существует
в Nubes — создание БД падает. Это очевидно, но важно в контексте `depends_on`:
если создавать БД параллельно с пользователем — БД создастся до того как
пользователь появится, и получим ошибку.
---
## 3.5 ERR-PG-08: "Concurrent operations are not supported" при создании БД после Update
**Описание проблемы**
Если в terraform plan обнаруживается that что-то изменилось на инстансе
(например, vault_secrets drift), Terraform запустит Update. После успешного
завершения Update, попытка создать зависимые ресурсы (БД, пользователей)
немедленно падает с ошибкой 422:
```
Error: Ошибка клиента
ошибка API 422: {
"TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
}
```
**Когда воспроизводится**
- При повторном `terraform apply` (vault_secrets обновляется каждый раз)
- При создании БД сразу после Update (даже в одном apply)
**Попытка обхода**: Ожидание между apply'ами (10s, 60s, 120s) **НЕ ПОМОГАЕТ**.
Ошибка 422 возникает независимо от временной задержки.
**Причина**
Nubes API имеет встроенный serial operation lock на инстанс. Даже когда
`WaitForOperation()` возвращает `IsSuccessful = true`, сервер ещё обрабатывает
асинхронные побочные эффекты (Vault sync, state consistency и тд). Новые
операции отклоняются до полного завершения обработки.
**Текущий workaround**
Разбить apply на несколько фаз:
```hcl
# Фаза 1: postgres.tf без nubes_postgres_database блока
# terraform apply
# Фаза 2: Добавить nubes_postgres_database блок и повторить
# terraform apply
```
**Статус**: Открытая проблема. Требует fix в `internal/provider/client_impl.go`
(добавить post-completion delay или retry mechanism).
**Документация см.**: [ERR-PG-08-concurrent-operations.md](../ERR-PG-08-concurrent-operations.md)
---
## 4. Последовательность зависимостей (обязательная)
Нарушение любого из `depends_on` в цепочке вызывает ошибки API.
Рабочая цепочка (протестировано):
```
nubes_postgres (pg_test_instance)
└─→ nubes_postgres_user (pg_test_user, role=ddl_user)
└─→ nubes_postgres_database (pg_test_db, owner=pg_test_user)
└─→ nubes_postgres_user (test_extra_user1, role=ddl_user)
└─→ nubes_postgres_user (test_extra_user2, role=ddl_user)
└─→ nubes_postgres_database (test_extra_db1, owner=user1)
└─→ nubes_postgres_database (test_extra_db2, owner=user2)
```
Каждая стрелка: `depends_on = [предыдущий ресурс]`.
**Почему depends_on нужен даже между user и db:** Nubes API не справляется с
одновременными операциями на PG-инстансе. Даже если БД не зависит от пользователя
напрямую (разные пользователи), они всё равно конкурируют за API-операцию.
---
## 5. Поведение при прерывании apply (SSH timeout)
SSH соединение разрывается после ~8-10 минут без вывода.
При запуске через `ssh ... "cd ... && terraform apply"` apply убивается вместе
с SSH-процессом.
**Последствия:**
- Ресурсы, которые Terraform успел создать ДО разрыва — попадают в state
- Ресурсы, которые были в процессе создания в момент разрыва — **НЕ** попадают в state,
но могут быть созданы/занесены в Nubes API (зависание операции)
- Следующий apply видит state без этих ресурсов, но API их "знает"
- `adopt_existing_on_create` не работает надёжно в этом сценарии (ERR-PG-05)
**Правильный способ запуска:** через `nohup` или `tmux`:
```bash
# Через nohup (процесс переживает разрыв SSH):
ssh user@vm "cd /path && nohup terraform apply -auto-approve > /tmp/tf.log 2>&1 & echo PID=\$!"
# Проверить прогресс:
ssh user@vm "tail -20 /tmp/tf.log"
# Через tmux (можно переподключиться к сессии):
ssh user@vm "tmux new-session -d -s tf 'cd /path && terraform apply -auto-approve'"
ssh user@vm "tmux attach -t tf"
```
---
## 6. Суммарная таблица поведения
| Операция | Работает | Проблемы | Решение |
|---|---|---|---|
| Создание инстанса | ✅ | — | — |
| Переиспользование инстанса (`adopt`) | ✅ | — | — |
| Suspend при destroy | ✅ (это дефолт) | — | — |
| `json_parameters` в конфиге | ❌ | Invalid JSON String | Не указывать, Nubes ставит дефолты |
| Создание `nubes_postgres_user` с `ddl_user` | ✅ | ~6090 сек | — |
| Создание `nubes_postgres_user` с `app_user` | ❌ | Секрет не создан (~3 мин) | Только `ddl_user` |
| Параллельное создание нескольких users | ❌ | Race condition в Vault | `depends_on` chain |
| Создание 2–3-го пользователя (любого) | ✅ | ~60–90 сек каждый | `depends_on` chain обязателен |
| Удаление `nubes_postgres_user` | ✅ | ~5681 сек | — |
| Принятие существующего user (`adopt`) | ✅ | не работает при "зависшей" операции | Новое имя |
| Создание `nubes_postgres_database` | ⚠️ | Может блокироваться ERR-PG-08 | См. раздел 3.5 |
| Удаление `nubes_postgres_database` | ✅ | ~4692 сек | — |
| Update инстанса + создание БД (одновременно) | ❌ ERR-PG-08 | "Concurrent operations are not supported" | Разбить на фазы или использовать retry |
| Повторный apply (idempotent) | ❌ частично | Комбинация ERR-PG-02 (исправлена) + ERR-PG-08 | Workaround: раздельные apply |
| apply через SSH (долгий) | ❌ | SSH timeout убивает процесс | `nohup` или `tmux` |
---
## 7. Суммарное время полного apply (7 ресурсов)
| Этап | Ресурс | Время |
|---|---|---|
| 1 | nubes_postgres (create/update) | ~010 мин |
| 2 | nubes_postgres_user pg_test_user | ~6083 сек |
| 3 | nubes_postgres_database pg_test_db | ~4766 сек |
| 4 | nubes_postgres_user test_extra_user1 | ~6090 сек |
| 5 | nubes_postgres_user test_extra_user2 | ~6090 сек |
| 6 | nubes_postgres_database test_extra_db1 | ~4766 сек |
| 7 | nubes_postgres_database test_extra_db2 | ~4766 сек |
| **Итого (только новые ресурсы)** | | **~815 минут** |
При повторном apply с vault_secrets drift (+destroy+recreate user/db):
| Дополнительно | Destroy DB | ~4792 сек |
| | Destroy User | ~5681 сек |
| | Re-create всего | +~815 мин |
---
## 8. Рекомендации для работы с nubes PostgreSQL через Terraform
1. **Не указывать `json_parameters` в конфиге** — провайдер ставит дефолты автоматически.
2. **Всегда использовать строгий `depends_on` chain** для всех `nubes_postgres_user`
и `nubes_postgres_database`. Параллелизм ломает API.
3. **Роль пользователей — только `ddl_user`**. `app_user` не работает.
4. **Запускать apply через `nohup` или `tmux`**, не через прямую SSH-команду.
Полный apply занимает 8–15 минут и SSH таймаутится.
5. **Если apply упал в середине создания пользователя** — не повторять apply
с тем же именем пользователя. Изменить `username` в конфиге на новое значение.
6. **Повторный apply НЕ идемпотентен** пока не исправлена проблема с `vault_secrets`.
Каждый apply пересоздаёт пользователей и базы. Это баг провайдера.
7. **`adopt_existing_on_create = true`** — работает только при "нормальном"
предыдущем apply (ресурс есть в `state_out` инстанса). При засорённых
операциях — не помогает.
---
## 9. Транзитные ошибки тест-окружения
Помимо воспроизводимых проблем, наблюдались транзитные ошибки от тестового API:
### 9.1 IAM 408 при создании пользователя
```
Error: Ошибка клиента
with nubes_postgres_user.pg_test_user
ошибка API 408: {"IAM URL":"https://auth-api-test.ngcloud.ru/api/v1/auth/user",
"idpResponse":{"prefix":{"status_text":"Request Time-out","statuscode":"408 Request Time-out"}}}
```
IAM API (`auth-api-test.ngcloud.ru`) вернул Connection Timeout при создании пользователя.
Транзитная ошибка — при повторном apply операция проходила успешно.
**Вывод**: тест-окружение (`deck-api-test`, `auth-api-test`) не даёт 100% надёжности.
Для production окружения поведение может отличаться.
+337 -1
View File
@@ -1,6 +1,342 @@
# Прогресс разработки
Последнее обновление: 2026-03-22
Последнее обновление: 2026-04-01
---
## 2026-04-01 — PG_TEST: создание и отладка lifecycle-тестов для nubes PostgreSQL
### Цель
Создать набор Terraform-манифестов для тестирования провайдера `nubes` (PostgreSQL ресурсы):
создание/удаление/модификация инстансов, пользователей и баз данных через Nubes API.
Передать заказчику как готовый шаблон (достаточно вписать токен и s3_uid).
### Что создано
**`examples/PG_TEST/`** — новая директория с полным набором манифестов:
| Файл | Назначение |
|---|---|
| `main.tf` | провайдер nubes v5.0.51, объявление переменных |
| `postgres.tf` | базовые ресурсы: инстанс, пользователь, база данных |
| `postgres_extra.tf` | дополнительные ресурсы для lifecycle-тестов |
| `outputs.tf` | host, port, user, password (sensitive), DSN (sensitive) |
| `terraform.tfvars` | рабочие значения (не в git) |
| `terraform.tfvars.example` | шаблон для заказчика с masked placeholders |
| `test_lifecycle.sh` | скрипт последовательного lifecycle-тестирования |
### Что протестировано (итоги)
#### ✅ Работает
- Создание `nubes_postgres` инстанса (pg-test-02, realm=k8s-3-sandbox-nubes-ru)
- Создание `nubes_postgres_user` с ролью `ddl_user`
- Создание `nubes_postgres_database` с owner из `nubes_postgres_user`
- `adopt_existing_on_create = true` — корректно работает при первом apply если ресурс уже есть
- `lifecycle { ignore_changes = [vault_secrets] }`**не эффективно**: `vault_secrets` является Computed-only, директива игнорируется (Terraform warning)
- Строгий `depends_on` chain — устраняет race condition в API (см. ниже)
- Destroy: удаление DB (~47s), User (~56-76s) проходит корректно
#### ❌ Не работает / Ограничения API
| Проблема | Описание | Решение |
|---|---|---|
| `json_parameters` | "Invalid JSON String" при любом значении | убран из конфига |
| `role = "app_user"` | "Секрет не был создан" (~3 мин таймаут) | только `ddl_user` |
| Параллельное создание пользователей | Race condition на Vault side | `depends_on` chain |
| `vault_secrets` внешнее изменение | Форсирует destroy+recreate зависимых ресурсов | `ignore_changes` не эффективен (Computed-only), открытая проблема |
| `adopt_existing_on_create` при "stale" state | Ошибка "Нарушена консистентность" | `terraform destroy` + rebuild |
### Итоговая архитектура depends_on
```
nubes_postgres (pg_test_instance)
└─→ nubes_postgres_user (pg_test_user)
└─→ nubes_postgres_database (pg_test_db)
└─→ nubes_postgres_user (test_extra_user1)
└─→ nubes_postgres_user (test_extra_user2)
└─→ nubes_postgres_database (test_extra_db1)
└─→ nubes_postgres_database (test_extra_db2)
```
### Ключевые параметры окружения
- Провайдер: `terra.k8c.ru/nubes/nubes` v5.0.51
- API endpoint: `https://deck-api-test.ngcloud.ru/api/v1/index.cfm`
- realm: `k8s-3-sandbox-nubes-ru`
- PG инстанс ID: `e0e74801-d68e-4637-8ef3-d846b289846e` (pg-test-02)
- VM для запуска: `naeel@5.172.178.213` (ключ: `secrets/naeel_vm_id_ed25519`)
- Путь на VM: `/home/naeel/terra/sless/examples/PG_TEST`
### Текущий статус (обновлено 2026-04-01)
**Финальный итог сессии**: lifecycle-тесты с несколькими пользователями
**невозможны** в текущем тест-окружении Nubes. Vault backend PG-инстанса
`e0e74801` поддерживает только одного пользователя с vault_secrets.
Подтверждено 5+ попытками с разными именами:
- `extra_user1`, `test_eu1` (ddl_user) — все завершились ERR-PG-06
**Достигнуто в сессии:**
- ✅ Один пользователь + одна БД создаются и удаляются корректно
- ✅ Все ошибки задокументированы (ERR-PG-01..ERR-PG-07)
- ✅ Создан подробный отчёт [`doc/pg-terraform-behavior.md`](pg-terraform-behavior.md)
- ✅ Архитектура `depends_on` chain подтверждена и задокументирована
- ❌ Несколько пользователей на одном инстансе — заблокировано Vault-ограничением
**Требуется от Nubes**: исправить vault policy для PG-инстансов тест-окружения,
чтобы допускать несколько vault_secrets записей на один инстанс.
Следующие шаги lifecycle-теста: создать всё → удалить user2+db2 → воссоздать → невалидные параметры
### Подробности ошибок
→ [doc/errors/log.md](doc/errors/log.md) (ERR-PG-01 … ERR-PG-05)
### Принятые решения
→ [doc/decisions/log.md](doc/decisions/log.md) (3 решения: ignore_changes, depends_on chain, только ddl_user)
---
## 2026-03-30 — Автоматизация VM stress-тестирования
### v2 (READ-ONLY) — переписан после инцидента с потерей tfvars
**Инцидент:** v1 скрипта содержал `write_tfvars()` которая перезаписывала `terraform.tfvars`.
Функция использовала `grep | cut | xargs | sed` для извлечения JWT-токена api_token.
Пайплайн не справился с длинным JWT (1200+ символов) и токен был потерян.
Это сломало весь terraform и потребовало ручного восстановления.
**Решение (v2):**
- Полностью убраны `write_tfvars()`, `backup_tfvars()`, `restore_tfvars()`, `ensure_baseline()`
- Все переопределения переменных — через `-var` в terraform CLI
- Файл `terraform.tfvars` НИКОГДА не модифицируется
- Добавлена проверка md5sum terraform.tfvars после каждой фазы
- Если файл изменился — АВАРИЙНАЯ ОСТАНОВКА (exit 99)
### Что сделано
- Переписан скрипт [examples/VM/vm_stress_test.sh](examples/VM/vm_stress_test.sh) (v2, 847 строк, 10 фаз)
- Создана инструкция [examples/VM/VM_TEST_README.md](examples/VM/VM_TEST_README.md)
- Старая версия сохранена как `.vm_stress_test.sh.OLD`
### Сценарии (10 фаз):
1. **Baseline**: apply с полным набором (packages+nginx+docker)
2. **Idempotent**: plan → "No changes"
3. **Partial Disable**: выключить nginx+docker через `-var`
4. **Partial Enable**: включить обратно
5. **Reorder Packages**: изменить base_packages через `-var`
6. **Manual Purge**: удалить пакеты с VM по SSH → переустановить
7. **Destroy**: terraform destroy → VM suspend
8. **Resurrect**: apply после destroy
9. **Stress Cycles**: N циклов destroy/apply
10. **Final Sanity**: проверка VM + пакеты + plan
### Текущий статус
- Скрипт проверен на синтаксис (`bash -n`): OK
- Ожидает запуска первой итерации
---
## 2026-03-29 — VM stress/chaos matrix: результаты
### Что прогнали
1. Ручной cleanup на целевой VM: удаление `jq`, `python3-pip`, `htop`, `unzip`, `nginx`, `docker-ce`, `docker-ce-cli`, `containerd.io`, `docker-compose-plugin`.
2. `terraform destroy` на [examples/VM](examples/VM).
3. Проверка SSH-доступа после destroy.
4. `terraform apply` после destroy с восстановлением VM и jobs.
5. Повторный `terraform apply` без изменений для проверки идемпотентности.
6. Частичный сценарий с изменением количества ресурсов: `install_nginx=false`, `install_docker=false`, `base_packages=["htop", "jq"]`, `install_run_id=7`.
7. Возврат к полной матрице с другим порядком пакетов: `base_packages=["unzip", "python3-pip", "jq", "htop"]`, `install_run_id=8`.
8. Stress loop из 2 подряд идущих циклов `destroy -> apply`.
### Результаты
- Ручной cleanup на VM прошёл: пакеты и бинарники `docker`/`nginx` исчезли.
- `terraform destroy` завершился успешно и вывел `Destroy complete! Resources: 5 destroyed.`
- SSH после destroy не поднялся и ушёл в `Connection timed out`, что соответствует suspend-поведению.
- `terraform apply` после destroy восстановил `vApp + VM + 3 job` и вернул прежние IDs ресурсов.
- Повторный `apply` без изменений дал `No changes`.
- Частичный сценарий с двумя jobs (`install_packages` only) прошёл: лишние job-ресурсы были уничтожены, `install_packages` пересоздан.
- Полная матрица с перестановкой пакетов прошла: `install_packages`, `install_nginx`, `install_docker` восстановились.
- Stress loop из 2 циклов `destroy -> apply` завершился без ошибок.
### Наблюдения
- `install_packages_result` отражает уже установленные пакеты на VM; после частичного сценария он вернул только текущий состав списка из `base_packages`.
- `install_nginx_result` и `install_docker_result` при повторном применении в полном состоянии показывают `already_installed`, что подтверждает идемпотентность джобов.
- IDs `vapp_id` и `vm_id` остались прежними после destroy/apply, что согласуется с adopt/suspend моделью.
## 2026-03-29 — VM stress/chaos matrix: destroy, suspend, reapply, reorder
### Что планируется
- Прогнать серию разных тестов на [examples/VM](examples/VM) через `terraform` на удалённой VM.
- Проверить сценарий с удалением всего установленного ПО внутри ВМ, затем `destroy`, после чего убедиться, что ВМ уходит в `suspend`, а не удаляется.
- Проверить `apply` после `destroy`: ВМ должна проснуться, а приложения должны установиться заново.
- Прогнать вариации порядка и количества установок, чтобы увидеть поведение при перестановках ресурсов и изменении состава.
- Отдельно запустить стресс-прогоны и документировать все результаты, включая ошибки и нестабильности.
### Что будет фиксироваться
- Команды и их итоговый статус.
- Любые расхождения между планом и фактическим состоянием ВМ.
- Ошибки `terraform`, `ssh` и установки пакетов.
- Поведение suspend/resume и повторной установки после `apply`.
## 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 провайдера
### Что сделано
**Bug 1: Go 1.23 go.work + replace конфликт (FIXED → v0.1.61)**
- `internal/builder/context.go`: убран `replace sless/fn/handler => ./handler` из go.work шаблона
- Добавлен `sed` переименования модуля вместо replace
- Ошибка была: `go: workspace module sless/fn/handler is replaced at all versions in the go.work file`
**Bug 2: controller-runtime cache lag → 404 на upload (FIXED → v0.1.62)**
- `internal/api/handler/services.go`: retry loop 5×200ms в `UploadServiceCode`
- `internal/api/handler/jobs.go`: retry loop 5×200ms в `UploadJobCode`
- Причина: сразу после POST /services (201) informer cache ещё не синхронизирован → IsNotFound
**Bug 3: Провайдер — 409 при повторном apply после сбоя upload (FIXED)**
- `terraform/provider/internal/resources/service_resource.go`: в `Create()` при ошибке upload — rollback `DeleteService()`
- `terraform/provider/internal/resources/job_resource.go`: аналогично `DeleteJob()`
- Причина: upload в S3 падал (сетевой сбой), terraform не записывал state, CR оставался в k8s → следующий apply получал 409
**test_cache_matrix.sh v4**
- Убраны все `-target` из скрипта — terraform не должен касаться postgres при частичных операциях
- `destroy_sless_only()`: переименует `chaos_marathon.tf`, `functions.tf`, `stress.tf``.bak`, делает apply (terraform сам удаляет), возвращает файлы
- Phase 3a: закомментирует блоки ресурсов через Python вместо `-target`
**Operator v0.1.62** собран и задеплоен (`naeel/sless-operator:v0.1.62`)
### Статус
✅ v0.1.62 Running
✅ Провайдер пересобран на VM (`/tmp/sless-provider-dev/`)
⏳ test_cache_matrix.sh v4 — Phase 1 в процессе (pg-stats удалили вручную, apply идёт)
---
## 2026-03-23 — Сессия 10: ImageExists + деплой v0.1.58
### Что сделано
- **ImageExists** — новый метод `Builder.ImageExists(ctx, imageRef) bool` в `internal/builder/builder.go`
- Docker Registry v2 API: anonymous bearer token → HEAD `/v2/{repo}/manifests/{tag}`
- timeout 5s, fallback false при любой ошибке (безопасный fallback → kaniko)
- Приватные registry (Harbor и др.) → 401 → false → строим заново
- **service_controller.go** `startServiceBuild()`: кеш-проверка перед Build(); cache hit → `Status.Phase=Ready` + `Status.ImageRef` без kaniko
- **function_controller.go** `startBuild()`: аналогично
- **functionjob_controller.go** `startJobBuild()`: аналогично; cache hit → Requeue для немедленного перехода к run
- **v0.1.58** собран и задеплоен: `naeel/sless-operator:v0.1.58` Running, RESTARTS:0
### Статус
✅ Код написан (no errors)
✅ Docker build + push наDockerHub (sha256:7b0d48a01a29f2a5...)
✅ kubectl rollout: `deployment "sless-operator" successfully rolled out`
✅ Pod `sless-operator-85d4685c4b-6nxqw` Running v0.1.58
### Следующий шаг
Протестировать cache hit: вернуть `.tf.disabled``.tf`, `terraform apply` — образы уже на DockerHub, должны восстановиться без kaniko за секунды.
---
+292
View File
@@ -0,0 +1,292 @@
# План исправления ERR-PG-02: id=(known after apply) при Update nubes_postgres
Дата: 2026-04-02
Файл провайдера: `/home/naeel/terra/terraform/internal/provider/postgres_resource.go`
Размер: 1043 строк
---
## Проблема
При обновлении ресурса `nubes_postgres` (даже in-place обновления), провайдер возвращает `id` как `(known after apply)`. Это форсирует Terraform replace зависимых ресурсов (`nubes_postgres_user`, `nubes_postgres_database`), хотя они не менялись.
### Симптом в плане
```
Plan: 3 to add, 1 to change, 2 to destroy.
```
Вместо ожидаемого:
```
Plan: 1 to add, 0 to change, 0 to destroy.
```
### Детальная диагностика
- Добавляем 1 ресурс: `pg_test_user3` (u3) — это корректно
- Destroy 2 ресурса: `pg_test_user`, `pg_test_db` — это BUG
- Add 2 ресурса: replace `pg_test_user`, `pg_test_db` — это BUG
- Change 1 ресурс: `nubes_postgres` с update `vault_secrets` — это ожидаемо
**Причина destroy+recreate**: когда `nubes_postgres` обновляется, его `id` уходит в `(known after apply)`. Terraform видит что родитель обновился и его id неизвестен → помечает зависимых (которые ссылаются на `postgres_id`) как `must be replaced`.
---
## Этапы анализа
### Этап 1: Структура файла
**Файл:** `/home/naeel/terra/terraform/internal/provider/postgres_resource.go`
Ожидаемая структура:
```go
type postgresResource struct {
client *client.Client
}
// CRUD методы:
func (r *postgresResource) Create(ctx context.Context, ...) { ... }
func (r *postgresResource) Read(ctx context.Context, ...) { ... }
func (r *postgresResource) Update(ctx context.Context, ...) { ... } // ← ГЛАВНЫЙ ИНТЕРЕС
func (r *postgresResource) Delete(ctx context.Context, ...) { ... }
```
### Этап 2: Найди метод Update()
**Что искать:**
```
func (r *postgresResource) Update(ctx context.Context, req resource.UpdateRequest, resp *resource.UpdateResponse)
```
**Размер:** обычно 50-150 строк
**Логика обычно такая:**
1. Parse state: `var plan postgresResourceModel`
2. Extract resource ID: `resourceID := plan.ID.ValueString()`
3. Подготовить данные для API
4. Вызвать API update: `operation := r.client.UpdatePostgres(...)`
5. Poll операцию до completion
6. **Прочитать результат из API**
7. **Обновить state с новыми значениями**
### Этап 3: Проблемное место
В методе `Update()` ищи одну из этих проблем:
#### Проблема 3A: ID устанавливается как Unknown
```go
// ❌ НЕПРАВИЛЬНО:
plan.ID = types.StringUnknown() // или types.StringValue(...)
resp.State.Set(ctx, plan)
```
**Исправление:**
```go
// ✅ ПРАВИЛЬНО:
plan.ID = state.ID // Keep existing ID
resp.State.Set(ctx, plan)
```
#### Проблема 3B: StateOut обновляется как Unknown
```go
// ❌ НЕПРАВИЛЬНО:
newStateOut := types.StringUnknown()
```
**Исправление:**
```go
// ✅ ПРАВИЛЬНО:
// StateOut — это Computed field, можно обновить из API ответа
// но это не влияет на ID
newStateOut := types.StringValue(extractedStateOut)
```
#### Проблема 3C: После API call не читается новое состояние
```go
// ❌ НЕПРАВИЛЬНО:
resp.State.Set(ctx, plan) // Set только plan, без рефреша из API
```
**Исправление:**
```go
// ✅ ПРАВИЛЬНО:
// 1. Операция выполнена
// 2. Прочитать state_out из API (Read или GetStatus операции)
// 3. Обновить plan.StateOut = newStateOut
// 4. Оставить plan.ID = state.ID (ID не меняется!)
respObject := r.client.GetPostgresStatus(resourceID)
plan.StateOut = types.StringValue(respObject.StateOut)
resp.State.Set(ctx, plan)
```
### Этап 4: Сравни с Create()
**В Create() должно быть:**
1. Создать ресурс через API (async operation)
2. Poll операцию
3. Когда успешно — прочитать ресурс из API
4. **Заполнить ID новый из ответа** (только тут ID меняется!)
5. Заполнить остальные поля
6. Set state
**В Update() должно быть:**
1. Взять существующий ID из state
2. Отправить update в API
3. Poll операцию
4. Когда успешно — прочитать **обновлённое состояние** ресурса из API
5. **ID остаётся прежним!** ← это главное отличие
6. Обновить другие поля из API ответа
7. Set state
---
## Этап 5: Поиск конкретных строк
### Задача 5.1: Найди где в Update() устанавливается ID
**Команда для поиска:**
```bash
grep -n "ID.*StringUnknown\|ID.*StringValue\|ID = " postgres_resource.go | head -20
```
Ищи строки типа:
- `plan.ID = ...`
- `resp.State.Set(...)`
- `var data postgresResourceModel`
### Задача 5.2: Найди где вызывается API
**Команда:**
```bash
grep -n "client\.\|Update\|Create\|GetStatus" postgres_resource.go
```
Ищи:
- `r.client.UpdatePostgres(...)`
- `r.client.CreatePostgres(...)`
- Polling loop
### Задача 5.3: Найди где обновляются Computed fields
**Команда:**
```bash
grep -n "StateOut\|VaultSecrets\|state_out" postgres_resource.go
```
Эти поля **могут** меняться при Update, но это нормально.
---
## Этап 6: Проверка других ресурсов
**Важно:** если `nubes_postgres_user` и `nubes_postgres_database` тоже имеют такую же проблему, нужно исправить и там.
Файлы:
```
/home/naeel/terra/terraform/devops/profiles/dev/generated/go/90_postgres_user_resource.go
/home/naeel/terra/terraform/devops/profiles/dev/generated/go/90_postgres_database_resource.go
```
Логика должна быть та же — parent ID не должен меняться при Update().
---
## Этап 7: Тестирование
После исправления:
### 7.1 Пересборка провайдера
```bash
cd /home/naeel/terra/terraform
go mod tidy
go build -o bin/terraform-provider-nubes terra.k8c.ru/naeel/nubes
```
### 7.2 Замена в окружении разработки
```bash
# Если используется dev override:
cp bin/terraform-provider-nubes /tmp/sless-provider-dev/
# или скопировать локально на хост и synced mount
```
### 7.3 Тест плана без apply
```bash
cd /home/naeel/terra/sless/examples/PG_TEST
terraform plan
# Должно быть: Plan: 1 to add, 0 to change, 0 to destroy.
# (только добавление pg_test_user3, без destroy/recreate остальных)
```
### 7.4 Полный тест apply + destroy + apply
```bash
terraform apply -auto-approve
# Проверить state — 4 ресурса
terraform destroy -auto-approve
# Проверить что удалилось
terraform apply -auto-approve
# Проверить что пересоздалось без excessive operations
```
---
## Потенциальные места исправления в коде
### Файл: postgres_resource.go
**Ищи и исправь:**
1. **В методе Update()** — строки 200-400 (примерно)
- Найди где устанавливается `plan.ID`
- **Изменение:** если `plan.ID = types.StringUnknown()` — замени на `plan.ID = state.ID`
2. **После API call в Update()**
- Должен быть код типа: `result := r.client.Update(...)` или polling
- После получения результата нужно обновить state из результата
- **Исправление:** добавить чтение state_out из результата, оставить ID неизменным
3. **В методе Read()** — проверь логику
- Read() используется для refresh'а
- Должен корректно читать state_out и другие Computed fields
- **Проверка:** не должно быть логики что возвращает Unknown для ID
---
## Контрольный список перед commit
- [ ] В Update(): ID не меняется (остаётся равен state.ID)
- [ ] StateOut обновляется из API (если изменился)
- [ ] After Update poll завершён успешно
- [ ] Тест план показывает 1 to add, 0 to change
- [ ] Тест apply создаёт 4 ресурса (не recreating старые)
- [ ] Тест destroy удаляет все 4
- [ ] Тест apply создаёт заново без ошибок
- [ ] Commits в /home/naeel/terra/terraform с комментарием про ERR-PG-02
---
## Ожидаемый результат
После исправления:
**До исправления:**
```
terraform plan
Plan: 3 to add, 1 to change, 2 to destroy.
(destroy pg_test_user, pg_test_db → recreate их же + add pg_test_user3)
```
**После исправления:**
```
terraform plan
Plan: 1 to add, 0 to change, 0 to destroy.
(только add pg_test_user3, всё остальное неизменено)
```
---
## Документирование
После исправления обновить:
- `/home/naeel/remote_dev/sless/doc/errors/log.md` — ERR-PG-02 status FIXED
- `/home/naeel/remote_dev/sless/doc/progress.md` — отметить дату исправления
+573
View File
@@ -0,0 +1,573 @@
# Лог мышления — 2026-04-04
## Агент: GitHub Copilot (Claude Opus 4.6)
---
## Задача: Архитектура Managed IoT Service
### Что имеем
Изучил текущую архитектуру sless:
- Каждому пользователю — свой namespace `sless-{hash}` (CRD объекты) + `sless-fn-{hash}` (рабочие нагрузки)
- Есть 3 типа триггеров: HTTP, Cron, Event (RabbitMQ)
- Event-dispatcher уже умеет: подписка на RabbitMQ queue → POST в функцию
- Сборка через kaniko, образы в registry, S3 для кода
### Вопрос пользователя
Нужен managed IoT сервис. Вопрос: каждому юзеру свой брокер (Rabbit/Kafka), свой Postgres?
### Мои рассуждения
**Вариант A: Всё изолированно (per-user)**
- Каждому юзеру: свой MQTT-брокер (EMQX/VerneMQ), свой RabbitMQ, свой Postgres
- Плюсы: полная изоляция, нет noisy neighbor, простая модель безопасности
- Минусы: огромный расход ресурсов. 100 юзеров = 100 MQTT-брокеров + 100 Postgres + 100 RabbitMQ. Это нереально на одном кластере
**Вариант B: Shared инфраструктура с логической изоляцией**
- Один MQTT-брокер (EMQX) — multi-tenant через vhost/namespace prefix в топиках
- Один RabbitMQ (уже есть!) — vhost per user
- Один Postgres — schema per user или row-level security
- Плюсы: экономия ресурсов, управляемость
- Минусы: сложнее изоляция, risk noisy neighbor
**Вариант C: Гибридный (мой выбор)**
- **Shared**: MQTT-брокер (EMQX с multi-tenancy), PostgreSQL (schema per user)
- **Per-user в namespace**: только легковесные компоненты — bridge/adapter pod
- **Существующий RabbitMQ**: использовать как есть, vhost per user
- Reason: IoT-устройства общаются через MQTT → сообщения попадают в RabbitMQ через bridge → event-dispatcher уже умеет доставлять в функции
### Архитектурная цепочка (Вариант C)
```
IoT Device → MQTT (topic: {user-prefix}/device/telemetry)
→ EMQX Rule Engine / Bridge → RabbitMQ vhost={user} queue={trigger-queue}
→ event-dispatcher (уже есть!) → POST → serverless function
→ function пишет в Postgres (per-user schema) / отправляет команду обратно
→ MQTT publish → device
```
### Что нового нужно создать
1. **MQTT-брокер** — EMQX (есть multi-tenancy, WebSocket, rule engine, k8s operator)
2. **IoT Device Registry** — CRD `IoTDevice` (имя, credentials, metadata, user namespace)
3. **IoT Bridge** — сервис MQTT→RabbitMQ per user-namespace (или EMQX rule engine)
4. **Device Auth** — MQTT username/password или client certificates, хранение в k8s secrets per namespace
5. **Terraform provider** — ресурсы: `sless_iot_device`, `sless_iot_rule`
### Postgres
НЕ нужен per-user Postgres. Достаточно:
- Shared Postgres (уже есть для логов)
- Schema per user для IoT data (telemetry, device state)
- Или TimescaleDB extension для time-series данных
### RabbitMQ / Kafka
- RabbitMQ уже есть и используется event-dispatcher'ом
- Vhost per user — достаточная изоляция
- Kafka избыточен на данном этапе (нужен только при миллионах сообщений/сек)
### Вывод
Поднимать per-user брокер/БД — НЕ нужно. Нужна shared инфраструктура с логической изоляцией. Основная работа: EMQX + мост в RabbitMQ + device registry CRD.
---
## Агент: GitHub Copilot (Claude Sonnet 4.6)
## Дата сессии: 2026-04-04
### Задача: Реализация IoT MVP по плану из doc/iot-mvp-plan.md
---
### Шаг 0: Изучение кодовой базы (перед написанием кода)
Прочитал следующие файлы:
- `api/v1alpha1/function_types.go` — паттерн написания CRD типов
- `api/v1alpha1/trigger_types.go` — использование TriggerType string const
- `api/v1alpha1/groupversion_info.go` — паттерн регистрации API group
- `controllers/function_controller.go` — паттерн контроллера, finalizer, Reconcile
- `controllers/service_controller.go` — второй контроллер для сравнения
- `internal/api/router.go` — регистрация маршрутов, auth middleware
- `main.go` — как регистрируются контроллеры, как подключается API
- `go.mod` — версии зависимостей (k8s v0.26.0, controller-runtime v0.14.1)
#### Что понял
**Go module**: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless`
**API сервер**: gorilla/mux, auth через middleware на `/v1/` subrouter
**Паттерн контроллера**: `r.Get → finalizer → business logic → r.Status().Update()`
**Finalizer**: у function = `sless.kube5s.ru/finalizer`, у service = `sless.kube5s.ru/service-finalizer`
- Используют ручной containsString/removeString, **НЕ** controllerutil
- Я решил использовать `controllerutil.ContainsFinalizer/AddFinalizer/RemoveFinalizer` — это более современный и рекомендуемый подход из controller-runtime
**OwnerReference**: нигде не вижу в существующих контроллерах. Для IoT Secret нужна — чтобы Secret автоматически удалялся при удалении IoTDevice через cascade deletion. Использую `controllerutil.SetControllerReference`.
#### Почему controllerutil вместо ручного containsString
Существующий код использует устаревший подход (хелперы `containsString`/`removeString`). `controllerutil` — официальный API controller-runtime для работы с finalizers. Это не рефакторинг старого кода — это новый контроллер, пишу его правильно сразу.
---
### Шаг 1: CRD файлы и контроллер
#### Решение по структуре директорий
По плану: `iot/api/v1alpha1/` и `iot/controllers/`. Это отдельный package path от `api/v1alpha1`.
- IoT CRD package: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1`
- IoT контроллер package: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/controllers`
- Тот же go.mod — не нужно создавать отдельный модуль
#### Решение по API Group
По плану: `iot.kube5s.ru` — отдельная от `sless.kube5s.ru`.
Причина: при выносе в отдельную репу CRD не будет конфликтовать. Принимаю.
#### MQTTUsername формат
По плану: `{namespace}_{deviceId}`.
Пример: `sless-abc123def456_sensor-01`
Причина: EMQX требует глобально уникальный username. Namespace даёт изоляцию.
#### Secret name
По плану: `iot-{deviceId}`.
**Возможная проблема**: deviceId может содержать символы недопустимые в k8s Secret именах (только [a-z0-9-]).
**Решение**: в kubebuilder validation на DeviceID добавить regex `[a-z0-9-]+`. Если deviceId уже проходит валидацию — проблемы нет.
В плане валидация не упомянута, но это необходимо чтобы имя Secret было валидным. Добавлю `+kubebuilder:validation:Pattern`.
#### Генерация пароля
32 байта через `crypto/rand.Read``hex.EncodeToString` = 64 символа.
Это достаточно энтропии (256 бит).
#### OwnerReference у Secret
С OwnerReference Secret автоматически удалится при удалении IoTDevice (cascade GC в k8s).
Поэтому в finalizer обработчике нет нужды явно удалять Secret — просто убираем finalizer.
**Но есть нюанс**: если IoTDevice и Secret находятся в одном namespace — cascade deletion работает.
В нашем случае оба в `sless-{hash}` — OK.
#### Обработка статуса
`r.Status().Update()` — только subresource. Не трогает `spec` или `metadata`. Это важно чтобы не вызвать лишний reconcile цикл (обновление spec → новый reconcile → loop).
#### Disabled устройство
Если `spec.enabled == false`:
- Secret НЕ создаём (устройство не должно подключаться)
- Если Secret уже существует — НЕ удаляем (при re-enable пароль не изменится)
- Status: phase = "Disabled"
Это соответствует плану.
**Стоп — перечитал план**: "Установить status.phase = 'Disabled' — НЕ удалять Secret". Значит если disabled — просто обновить статус, Secret остаётся. Принимаю.
---
### Что создаю (Этап 1)
1. `iot/api/v1alpha1/device_types.go` — CRD IoTDevice
2. `iot/api/v1alpha1/groupversion_info.go` — API group iot.kube5s.ru/v1alpha1
3. `iot/controllers/iotdevice_controller.go` — контроллер
4. `iot/config/crd/bases/` — директория для CRD YAML (создаётся controller-gen через SSH)
5. Обновление `main.go` — регистрация IoT схемы и контроллера
Этапы 2+ (MQTT auth, EMQX, API routes, Terraform) — отдельно после одобрения Этапа 1.
---
### Этап 2-7: план перед реализацией
#### API port
Из `deployments/k8s/operator.yaml`: `API_PORT: "9090"`, сервис `sless-operator.sless.svc:9090`.
RabbitMQ: `amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672/`
#### EMQX версия — проблема
В плане указан `emqx/emqx:5.5.1`. Изучил вопрос:
- **EMQX 5.x open source НЕ имеет встроенного RabbitMQ bridge** (только в Enterprise)
- EMQX 4.x имеет RabbitMQ bridge через plugin, конфигурируется env vars
**Рассматривал варианты:**
A. EMQX 4.4 — встроенный bridge, но env vars другого формата чем в плане
B. EMQX 5.x + HTTP Webhook rule → наш bridge HTTP сервер
C. EMQX 5.x + MQTT client (paho) в bridge сервисе
**Выбрал вариант C**: mqtt-bridge Go сервис с `github.com/eclipse/paho.mqtt.golang`
- Не зависит от версии EMQX (работает с любым MQTT брокером)
- amqp091-go уже в go.mod
- paho.mqtt.golang добавляется через `go get` по SSH
- Самый надёжный и тестируемый подход
**EMQX 5.5.1**: используем только для HTTP auth (через emqx.conf HOCON).
Bridge service подключается к EMQX как обычный MQTT клиент.
#### MQTT Auth
Константы из существующего кода и CRD:
- username format: `{namespace}_{deviceId}``_` разделитель безопасен (namespace не содержит `_`)
- Secret name: `iot-{deviceId}`
- Always return HTTP 200, body `{"result": "allow"|"deny"}` (безопасно для обеих версий EMQX)
- `crypto/subtle.ConstantTimeCompare` для сравнения паролей
#### Структура файлов Этапов 2-7
- `internal/api/handler/iot_device_handler.go` — MQTT auth + IoT CRUD handlers
- `internal/api/router.go` — добавить IoT routes
- `deployments/k8s/emqx.yaml` — EMQX deployment c emqx.conf ConfigMap (только HTTP auth)
- `iot/cmd/mqtt-bridge/main.go` — MQTT subscriber → RabbitMQ publisher
- `deployments/k8s/iot-mqtt-bridge.yaml` — Deployment mqtt-bridge
- `examples/IOT/` — E2E demo
---
### Результат выполнения Этапов 2-7
**Создано:**
- `internal/api/handler/iot_device_handler.go` — MQTT auth + IoT CRUD handlers
- `internal/api/router.go` — IoT routes + `/internal/mqtt/auth`
- `deployments/k8s/emqx.yaml` — EMQX 5.5.1 deployment с emqx.conf (HTTP auth)
- `iot/cmd/mqtt-bridge/main.go` — MQTT subscriber → RabbitMQ publisher (paho + amqp091-go)
- `deployments/k8s/iot-mqtt-bridge.yaml` — Deployment mqtt-bridge
- `examples/IOT/` — E2E demo (main.tf, handler.py, README.md)
**go.mod**: добавлен `github.com/eclipse/paho.mqtt.golang v1.5.1`
**go build ./...** — ошибок нет.
**Не реализовано (отложено):**
- Этап 6 (Terraform Provider) — находится в отдельном репозитории, путь неизвестен
- Terraform ресурс `sless_iot_device` — реализуется отдельно в provider репо
**Ключевые архитектурные решения:**
- EMQX 5.5.1 (как в плане) — HTTP auth через emqx.conf HOCON
- mqtt-bridge использует paho.mqtt.golang (MQTT subscriber), а не EMQX webhook — версионно-независимо
- MQTTAuth всегда возвращает HTTP 200 (совместимо с EMQX 4.x и 5.x)
- `crypto/subtle.ConstantTimeCompare` для защиты от timing attacks
- `GetIoTDevice` — единственный endpoint с mqtt_password (security by design)
**Создано:**
- `iot/api/v1alpha1/device_types.go` — CRD IoTDevice с IoTDevicePhase константами
- `iot/api/v1alpha1/groupversion_info.go` — API group `iot.kube5s.ru/v1alpha1`
- `iot/api/v1alpha1/zz_generated.deepcopy.go` — сгенерирован controller-gen
- `iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml` — CRD манифест
- `iot/controllers/iotdevice_controller.go` — контроллер с полным Reconcile loop
- `main.go` — добавлена регистрация IoT схемы и контроллера
**Проверка:** `go build ./...` — ошибок нет.
**Отклонения от плана (с обоснованием):**
- Добавлен `+kubebuilder:validation:Pattern` на `DeviceID` — необходимо чтобы имя Secret `iot-{deviceId}` было валидным k8s именем. В плане не указано, но без валидации контроллер может сломаться.
- Использован `controllerutil.ContainsFinalizer/AddFinalizer/RemoveFinalizer` вместо ручных хелперов — более современный подход из controller-runtime. Старый код не трогал.
- Добавлена константа `IoTDevicePhase` (типизированный string) вместо plain string в плане — для type-safety и читаемости.
---
## Задача: Решения по архитектуре IoT MVP
### Вопрос 1: Репозиторий — та же или новая?
**Анализирую связи:**
- IoT генерирует события → RabbitMQ → event-dispatcher → serverless функции
- Связь между IoT и sless = на уровне message bus (RabbitMQ), НЕ на уровне кода
- Общее: концепция user namespace (sless-{hash}), аутентификация (JWT→namespace)
- Разное: домен (устройства vs функции), протоколы (MQTT vs HTTP), CRD-типы
**Вариант A: Та же репа**
- Плюс: общий go.mod, общие утилиты namespace, быстрый старт
- Плюс: один оператор — проще деплоить для демо
- Минус: два домена в одной репе — запутает
- Минус: разные циклы релизов в будущем
**Вариант B: Новая репа**
- Плюс: чистое разделение, независимые релизы
- Минус: дублирование namespace-логики или общая библиотека
- Минус: overhead для демо слишком большой
**Вариант C (мой выбор): Та же репа, изолированная структура**
- Весь IoT-код в директории `iot/` на верхнем уровне
- Свои контроллеры: `iot/controllers/`
- Свои CRD: `iot/api/v1alpha1/`
- Свой деплоймент (отдельный binary или часть того же оператора)
- Легко вынести в отдельную репу позже — просто перемещаем `iot/`
- Для демо: контроллеры IoT встраиваются в тот же operator binary (один pod)
**Reason**: связь IoT↔sless через RabbitMQ — слабая. Код не зависит друг от друга. Но для демо удобнее держать вместе. Структура `iot/` позволяет легко разделить.
### Вопрос 2: Terraform provider — расширять или новый?
**Факты:**
- Текущий провайдер: `sless` (terraform-provider-sless)
- Ресурсы: sless_function, sless_trigger, sless_service
- Auth: JWT → namespace
**Анализ:**
- Имя "sless" не подходит для IoT-ресурсов (`sless_iot_device` — странно)
- Но auth/namespace логика идентична
- Для демо: расширение существующего — быстрее всего
- Для прода: нужен единый провайдер `nubes` (бренд облака) с подресурсами, или отдельный `nubes-iot`
**Мой выбор: расширить текущий для демо**
- Добавить `sless_iot_device`, `sless_iot_rule`
- Имя неидеальное, но для демо ОК
- Для прода: переименование в `nubes` — отдельная задача (breaking change)
- Альтернатива: сразу назвать новый провайдер `nubes-iot`, но это overhead для демо
**Рекомендация пользователю**: решить позже, когда IoT станет полноценным сервисом. Для демо — расширяем sless.
### Вопрос 3: Scope MVP — что включаем?
**Полный IoT-сервис** (для справки):
1. MQTT-брокер ✓
2. Device Registry ✓
3. Device Auth ✓
4. Rules Engine (маршрутизация)
5. Time-series storage (телеметрия)
6. Device Shadow/Twin (состояние)
7. Command Channel (cloud→device)
8. Dashboard/мониторинг
**MVP (демо с возможностью усложнения):**
ДА, включаем:
1. ✅ EMQX — деплой через YAML/Helm в кластер
2. ✅ CRD `IoTDevice` — имя, namespace, credentials (username/password), metadata
3. ✅ IoT-контроллер — reconcile IoTDevice → создаёт MQTT credentials в EMQX через HTTP API
4. ✅ EMQX → RabbitMQ bridge — маршрутизация: MQTT topic → RabbitMQ queue
5. ✅ Включение event-триггеров в sless API (снятие блокировки)
6. ✅ Terraform: `sless_iot_device` (CRUD)
7. ✅ E2E демо: device → MQTT → function вызывается
НЕТ, откладываем:
- ❌ Device Shadow — усложнение, не нужно для демо
- ❌ Rules Engine — для демо хватит простой маршрутизации topic→queue
- ❌ Time-series storage — функция сама может писать в Postgres
- ❌ Command channel (cloud→device) — второй этап
- ❌ Client certificates — для демо username/password
- ❌ Dashboard — Grafana + метрики EMQX потом
### Вопрос 4: Архитектура MVP — как именно работает
**Цепочка данных:**
```
IoT Device
→ MQTT connect (username=deviceId, password=deviceSecret)
→ EMQX (topic: {namespace}/telemetry/{deviceId})
→ EMQX Rule + Bridge → RabbitMQ (queue: iot.{namespace}.{topic-pattern})
→ sless event-dispatcher (существующий) → POST body → serverless function
→ function обрабатывает данные
```
**Аутентификация устройств:**
- EMQX HTTP Auth Backend → наш API: `POST /internal/mqtt/auth`
- Контроллер при создании IoTDevice → генерирует credentials → хранит в k8s Secret
- EMQX проверяет при MQTT CONNECT: запрос к нашему API → проверка credentials → ACL (device видит только свой namespace)
**Почему EMQX HTTP Auth, а не встроенная БД:**
- При добавлении/удалении устройства не нужно перезагружать EMQX
- ACL динамический — привязан к namespace
- Возможность усложнения (certificates, OAuth) без изменения EMQX
**Структура файлов (план):**
```
iot/
api/v1alpha1/
device_types.go # CRD IoTDevice
groupversion_info.go
zz_generated.deepcopy.go
controllers/
device_controller.go # Reconcile: создаёт credentials, Secret
internal/
emqx/
client.go # HTTP-клиент к EMQX Management API
mqtt_auth/
handler.go # HTTP Auth Backend для EMQX
deployments/
emqx.yaml # Деплой EMQX в кластер
```
**Что НЕ нужно создавать с нуля:**
- RabbitMQ — есть
- Event-dispatcher — есть (только включить event triggers)
- Namespace-логика — есть (переиспользуем)
- API-сервер (JWT auth, routing) — есть, добавляем IoT-эндпоинты
---
## Вопрос: RabbitMQ vs Kafka для IoT
### Контекст
- RabbitMQ уже развёрнут, event-dispatcher написан под AMQP
- Пользователь хочет "с прицелом на будущее, без переделок"
- IoT = потенциально тысячи устройств, миллионы сообщений
### Сравнение для IoT
| Критерий | RabbitMQ | Kafka |
|----------|----------|-------|
| Модель | Push (broker → consumer) | Pull (consumer → offset) |
| Хранение | Сообщение удаляется после ack | Лог хранится N дней (replay!) |
| Масштаб | до ~50K msg/sec (один node) | миллионы msg/sec |
| Multi-consumer | нет (сообщение потреблено = удалено) | да (разные consumer groups) |
| IoT replay | невозможен | ключевая фича |
| Операционные затраты | проще | сложнее (KRaft, partitions) |
| Per-user изоляция | vhost | topic prefix, ACL |
| Уже есть | да | нет |
### Для IoT Kafka объективно лучше потому что:
1. **Replay** — устройство отправило данные, функция упала → с Kafka можно перечитать. С RabbitMQ — данные потеряны (nack+requeue — не то же самое)
2. **Multi-consumer** — одни и те же данные от датчика читают: функция-алерт, функция-аналитика, Trino (!) для запросов. С RabbitMQ нужны exchange fanout + N очередей (костыль)
3. **Time-series природа** — IoT телеметрия = append-only лог. Kafka создан именно для этого
4. **Масштаб** — 1000 устройств × 1 msg/sec = 1000 msg/sec (RabbitMQ справится). 100K устройств × 10 msg/sec = 1M msg/sec (RabbitMQ не справится)
5. **Trino** — Kafka connector для Trino → SQL-запросы по потоку данных в реальном времени. С RabbitMQ этого нет
### НО: event-dispatcher сейчас написан под AMQP
Переход = переписать event-dispatcher. Это ~300 строк кода. Не страшно.
### Мой вывод
Для IoT — Kafka. Для существующих serverless event-триггеров — RabbitMQ остаётся (менять рабочее не нужно).
Два брокера — нормально:
- **RabbitMQ** — существующие event-триггеры sless (task queue: одно сообщение → одна функция)
- **Kafka** — IoT data pipeline (stream: данные хранятся, читаются многими)
Это разные паттерны использования. Не нужно одним инструментом решать обе задачи.
---
## Вопрос: может перевести sless тоже на Kafka — пока не обросли?
### Думаю вслух
Пользователь прав — переделывать потом больнее. Сейчас event-dispatcher = ~300 строк, event-триггеры ещё даже не включены в API. Идеальный момент для смены.
### Для sless event-триггеров: что именно нужно?
Паттерн: сообщение пришло → вызвать ОДНУ функцию → подтвердить/повторить.
| Нужно для sless | RabbitMQ | Kafka |
|-----------------|----------|-------|
| Доставка 1 сообщение → 1 функция | нативно (queue) | consumer group (работает) |
| Retry при ошибке | nack+requeue / dead letter — нативно | нужна логика retry-topic (код) |
| Dead letter queue | встроен | нужен отдельный topic + код |
| Приоритеты сообщений | да | нет |
| Задержка доставки (delay) | плагин, просто | нет нативно |
RabbitMQ для task queue **объективно удобнее**. Kafka для этого работает, но требует больше кода.
### НО: два брокера в проде — это боль
- Два кластера мониторить
- Два набора алертов
- Два набора бэкапов
- Две точки отказа
- Двойное потребление ресурсов
### Варианты
**Вариант A: Два брокера (RabbitMQ для sless, Kafka для IoT)**
- Плюс: каждый инструмент для своей задачи
- Минус: операционная сложность × 2
**Вариант B: Kafka для всего**
- Плюс: один брокер, одна инфраструктура
- Плюс: sless event-dispatcher переписать СЕЙЧАС — пока маленький
- Минус: retry/DLQ для sless придётся писать руками (~50 строк)
- Минус: Kafka тяжелее (3 ноды KRaft минимум для прода)
**Вариант C: Redpanda вместо Kafka**
- Kafka-совместимый API, но single-binary, легче в ops
- Но менее зрелый, меньше community
### Мой вывод
**Kafka для всего.** Причины:
1. Event-триггеры в sless ещё не запущены — переписать сейчас = 0 стоимости миграции
2. Один брокер вместо двух — проще эксплуатация
3. Retry через retry-topic — стандартный паттерн, ~50 строк кода
4. Kafka для sless event-триггеров работает нормально (consumer group, offset commit = тот же ack)
5. С прицелом: если sless и IoT оба на Kafka — проще интеграция (IoT event → sless function, один bus)
---
## Контраргумент: single point of failure
### Пользователь прав
Если Kafka — единственный брокер и он падает → **оба сервиса мертвы** (sless event-triggers + IoT). Blast radius = вся платформа.
А если два брокера:
- Kafka упал → IoT не работает, но sless event-триггеры живы (RabbitMQ)
- RabbitMQ упал → IoT работает, sless event-триггеры лежат
- Полный outage = нужно чтобы упали ОБА одновременно (маловероятно)
### Пересмотр решения
Это классический trade-off: операционная простота vs отказоустойчивость.
Для managed service платформы — **отказоустойчивость важнее**. Клиент платит за uptime.
### Финальное решение: ДВА брокера
- **RabbitMQ** → sless event-триггеры (уже написан, проще для task queue, независимый)
- **Kafka** → IoT pipeline (replay, multi-consumer, масштаб)
- Изоляция fault domains: падение одного не убивает другой сервис
Операционная сложность двух брокеров — приемлемая цена за изоляцию.
Мониторинг/алерты — решаемо (Prometheus + Grafana для обоих).
---
## Реальность: кубер сломан, выходные, нет облачных сервисов
### Ситуация
- Реалм пользователя не создаёт managed-сервисы (баг/инцидент)
- До понедельника никого нет (шабат/выходные)
- Kafka может оказаться в другом реалме, чем RabbitMQ
- Нужно работать с тем что есть СЕЙЧАС
### Мои мысли
**Вариант A: Делаем MVP на RabbitMQ (который есть)**
- Плюс: RabbitMQ уже работает, ничего разворачивать не нужно
- Плюс: event-dispatcher уже написан под AMQP
- Плюс: можно прямо сейчас начать IoT-часть (CRD, контроллер, EMQX, bridge)
- Плюс: demo будет работать к понедельнику
- Минус: потом нужна миграция EMQX→Kafka вместо EMQX→RabbitMQ bridge
- НО: мост MQTT→broker — это конфиг EMQX, а не наш код. Переключить EMQX bridge с RabbitMQ на Kafka = смена конфига, не переписывание
**Вариант B: Поднять Kafka руками в кубере (Strimzi/Bitnami Helm)**
- Плюс: правильная архитектура с самого начала
- Минус: Kafka в k8s = тяжело (3 ноды KRaft, storage, сетевые проблемы)
- Минус: если реалм глючит — может и Kafka не развернуться
- Минус: потом всё равно мигрировать на managed
**Вариант C (мой выбор): MVP на RabbitMQ сейчас, архитектура ready for Kafka**
Суть: делаем IoT bridge через абстракцию, не привязываясь к конкретному брокеру.
```
EMQX → [bridge config] → RabbitMQ (сейчас)
→ Kafka (потом, смена конфига)
IoT event consumer → [interface] → POST → function
сейчас: event-dispatcher (AMQP) уже есть
потом: iot-consumer (Kafka) — отдельный сервис
```
Ключевое: НАША кодовая база НЕ зависит от выбора брокера.
- CRD IoTDevice — не зависит
- IoT контроллер — не зависит
- MQTT auth — не зависит
- EMQX — bridge настраивается конфигом (RabbitMQ или Kafka)
- Единственная точка замены: consumer, который читает из брокера и POST в функцию
### Что менять при переходе RabbitMQ → Kafka
1. EMQX bridge config: `rabbitmq``kafka` (конфиг, не код)
2. Consumer: отдельный iot-event-consumer вместо reuse event-dispatcher (~200 строк Go)
3. Kafka deployment: managed или Strimzi
Всё. Наш IoT-оператор, CRD, device auth — не меняются вообще.
+34 -2
View File
@@ -1,5 +1,5 @@
# Created: 2026-03-11
# Purpose: ignore generated artifacts for the `examples` repository
# Created: 2026-03-11 / Updated: 2026-03-30
# Purpose: ignore generated artifacts and internal files for the `examples` repository
# Terraform
.terraform/
@@ -16,6 +16,7 @@ crash.log
# Provider plugins / caches
.terraform.d/
# tfvars содержат секреты (токены, ключи) — пользователь создаёт из .template
*.tfvars
# Archives and build artifacts
@@ -39,3 +40,34 @@ venv/
.env
*.local
*.log
# ---- SSH-ключи (секретные данные, у каждого пользователя свои) ----
vm_key
vm_key.pub
**/vm_key
**/vm_key.pub
*.pem
id_ed25519
id_rsa
# ---- Внутренние тестовые и служебные скрипты (не для пользователей) ----
# VM
VM/vm_stress_test.sh
VM/.vm_stress_test.sh.OLD
VM/VM_TEST_README.md
# POSTGRES
POSTGRES/vm_stress_test.sh
POSTGRES/stress_test.sh
POSTGRES/stress_destroy_apply.sh.disabled
POSTGRES/full_test.sh
POSTGRES/bug_hunter.sh
POSTGRES/chaos_marathon.sh
POSTGRES/test_cache_matrix.sh
POSTGRES/deploy_and_run_chaos.sh
POSTGRES/scripts/
# ---- Примеры в разработке (временно скрыты) ----
POSTGRES/
NODEJS/
DEVfromGround/
+28
View File
@@ -0,0 +1,28 @@
// 2026-03-26 — main.tf: провайдер Nubes для DEV-стенда.
// DEV API endpoint: https://deck-api-dev.ngcloud.ru/api/v1
// Токен: secrets/dev.token (tazet@narod.ru)
terraform {
required_providers {
nubes = {
source = "terra.k8c.ru/nubes/nubes"
version = "5.0.31"
}
}
}
variable "api_token" {
type = string
sensitive = true
description = "Nubes API токен (DEV-стенд). Значение — в terraform.tfvars."
}
variable "resource_realm" {
type = string
description = "Платформа развёртывания (например k8s-3.ext.nubes.ru). Уточнить у сервис-менеджера."
}
provider "nubes" {
api_token = var.api_token
api_endpoint = "https://deck-api-dev.ngcloud.ru/api/v1/index.cfm"
}
+34
View File
@@ -0,0 +1,34 @@
// 2026-03-26 — vc_org.tf: ресурс «Организация в Cloud Director» для DEV-стенда.
// nubes_vc_org — тенант vCloud Director (organization_type = "iaas").
// resource_realm задаётся через переменную (terraform.tfvars или -var).
resource "nubes_vc_org" "dev_org" {
resource_name = "vcOrg-2"
resource_realm = var.resource_realm
# organization_type "iaas" — единственный вариант с доступом к организации.
# Значение по умолчанию "iaas", явно прописано для читаемости.
organization_type = "iaas"
# v_i_p_configure — JSON-список ipSpaces для операции modify.
# При create провайдер не передаёт его в API, но требует non-null значение в плане.
v_i_p_configure = ""
# adopt_existing_on_create = true — берёт существующий инстанс (dev-org-sless-demo уже создан с null realm от предыдущей попытки).
adopt_existing_on_create = true
# suspend_on_destroy = true (по умолчанию) — при destroy инстанс уходит в Suspend, не удаляется.
suspend_on_destroy = true
}
# ─── Outputs ─────────────────────────────────────────────────────────────────
output "dev_org_id" {
description = "ID созданной организации (используется в зависимых ресурсах)"
value = nubes_vc_org.dev_org.id
}
output "dev_org_state_flat" {
description = "Плоский state организации — endpoints, статусы"
value = nubes_vc_org.dev_org.state_out_flat
}
+83
View File
@@ -0,0 +1,83 @@
# IoT MVP — E2E Demo
## Что делает этот пример
Показывает полную цепочку:
```
IoT Device (mosquitto_pub)
→ MQTT PUBLISH → EMQX (HTTP auth → sless-operator)
→ [iot-mqtt-bridge подписан на "+/telemetry/+"]
→ RabbitMQ queue "iot.{namespace}.telemetry"
→ event-dispatcher
→ POST → serverless function (handler.py)
```
## Предусловия
1. EMQX запущен: `kubectl apply -f deployments/k8s/emqx.yaml`
2. iot-mqtt-bridge запущен: `kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml`
3. event-dispatcher запущен (уже должен работать)
## Запуск
```bash
# Установить переменные
export API_TOKEN="your-jwt-token"
export NAMESPACE="sless-abc123def456" # твой namespace
# Инициализировать
terraform init
terraform apply \
-var="namespace=${NAMESPACE}" \
-var="api_token=${API_TOKEN}"
# Получить credentials
MQTT_USER=$(terraform output -raw mqtt_username)
MQTT_PASS=$(terraform output -raw mqtt_password)
MQTT_TOPIC=$(terraform output -raw mqtt_topic)
echo "MQTT user: ${MQTT_USER}"
echo "MQTT topic: ${MQTT_TOPIC}"
```
## Отправить тестовое сообщение
```bash
# Через mosquitto_pub (из пода внутри кластера)
kubectl run mqtt-test --rm -i --image=eclipse-mosquitto --restart=Never -- \
mosquitto_pub \
-h emqx.sless.svc \
-p 1883 \
-u "${MQTT_USER}" \
-P "${MQTT_PASS}" \
-t "${MQTT_TOPIC}" \
-m '{"temperature": 22.5, "humidity": 65, "unit": "celsius"}'
```
## Проверить что функция вызвалась
```bash
# Логи event-dispatcher
kubectl logs -n sless deployment/event-dispatcher -f
# Логи функции (через invocations API)
curl -H "Authorization: Bearer ${API_TOKEN}" \
https://sless.kube5s.ru/v1/namespaces/${NAMESPACE}/functions/iot-telemetry-handler/invocations
```
## Структура файлов
```
examples/IOT/
main.tf # Terraform: function + trigger + iot_device
handler.py # Python обработчик телеметрии
README.md # Этот файл
```
## Известные ограничения MVP
- `sless_iot_device` Terraform ресурс требует реализации в terraform-provider-sless (Этап 6)
- EMQX TLS отключён — включить для prod (настроить cert-manager secret)
- iot-mqtt-bridge credentials создаются вручную (автоматизировать в будущем)
- Нет обратного канала: Cloud → Device команды (Device Shadow — вне MVP)
+57
View File
@@ -0,0 +1,57 @@
"""
Создано: 2026-04-04
handler.py — обработчик IoT-телеметрии для демонстрации IoT MVP.
Вызывается event-dispatcher при каждом MQTT сообщении от устройства.
Входящий event.body содержит JSON сформированный mqtt-bridge:
{
"namespace": "sless-abc123",
"device_id": "temp-sensor-01",
"topic": "sless-abc123/telemetry/temp-sensor-01",
"payload": {"temperature": 22.5, "humidity": 65},
"received_at": "2026-04-04T12:00:00Z"
}
"""
import json
import os
def handle(event, context):
"""Обработчик телеметрии IoT-устройства.
Логирует данные и возвращает подтверждение.
В реальном сценарии здесь: сохранение в БД, алертинг, управляющие команды.
"""
log_level = os.getenv("LOG_LEVEL", "INFO")
try:
body = json.loads(event.get("body", "{}"))
except json.JSONDecodeError as e:
return {
"statusCode": 400,
"body": json.dumps({"error": f"invalid JSON: {e}"})
}
namespace = body.get("namespace", "unknown")
device_id = body.get("device_id", "unknown")
payload = body.get("payload", {})
received_at = body.get("received_at", "")
if log_level == "INFO":
print(f"[IoT] namespace={namespace} device={device_id} at={received_at}")
print(f"[IoT] payload={json.dumps(payload)}")
# Здесь добавить бизнес-логику:
# - Запись в PostgreSQL (через POSTGRES_DSN из env)
# - Проверка порогов и алертинг
# - Публикация управляющей команды обратно на устройство
return {
"statusCode": 200,
"body": json.dumps({
"processed": True,
"device_id": device_id,
"namespace": namespace,
})
}
+102
View File
@@ -0,0 +1,102 @@
# Создано: 2026-04-04
# E2E Demo: IoT Device → MQTT → RabbitMQ → Serverless Function
#
# Порядок применения:
# 1. terraform init
# 2. terraform apply
# 3. Получить credentials: terraform output mqtt_password
# 4. Отправить тестовое MQTT сообщение (см. README.md ниже)
terraform {
required_providers {
sless = {
source = "kube5s.ru/naeel/sless"
version = ">= 0.1"
}
}
}
# Адрес API sless оператора
provider "sless" {
api_url = "https://sless.kube5s.ru"
}
# Переменные
variable "namespace" {
description = "Namespace пользователя (создаётся через EnsureNamespace)"
type = string
}
variable "api_token" {
description = "JWT токен для аутентификации в sless API"
type = string
sensitive = true
}
# Python функция-обработчик IoT-телеметрии
resource "sless_function" "iot_telemetry_handler" {
namespace = var.namespace
name = "iot-telemetry-handler"
runtime = "python3.11"
entrypoint = "handler.handle"
memory_mb = 128
timeout_sec = 30
env_vars = {
LOG_LEVEL = "INFO"
}
}
# Event Trigger: подписка на IoT telemetry queue
# event-dispatcher читает из этой очереди и вызывает функцию
resource "sless_trigger" "iot_telemetry_trigger" {
namespace = var.namespace
name = "iot-telemetry-events"
type = "event"
function_ref = sless_function.iot_telemetry_handler.name
# queue = "iot.{namespace}.telemetry" — формируется mqtt-bridge автоматически
queue = "iot.${var.namespace}.telemetry"
enabled = true
}
# IoT устройство — температурный датчик
resource "sless_iot_device" "temperature_sensor" {
namespace = var.namespace
name = "temperature-sensor"
device_id = "temp-sensor-01"
enabled = true
metadata = {
model = "DHT22"
location = "server-room"
owner = "ops-team"
}
}
# ——— Outputs ———
output "mqtt_broker" {
value = "emqx.sless.svc:1883"
description = "MQTT broker адрес (доступен внутри кластера)"
}
output "mqtt_username" {
value = sless_iot_device.temperature_sensor.mqtt_username
description = "MQTT username для устройства"
}
output "mqtt_password" {
value = sless_iot_device.temperature_sensor.mqtt_password
sensitive = true
description = "MQTT пароль для устройства (sensitive)"
}
output "mqtt_topic" {
value = "${var.namespace}/telemetry/temp-sensor-01"
description = "MQTT topic для публикации телеметрии"
}
output "iot_device_phase" {
value = sless_iot_device.temperature_sensor.phase
description = "Статус IoT устройства (Active/Pending/Disabled/Error)"
}
+32
View File
@@ -0,0 +1,32 @@
// Создано: 2026-03-23
// main.tf — провайдер Nubes + переменные для примера NODEJS.
// Ресурс nubes_nodejs: managed Node.js приложение в облаке (не sless-функция).
terraform {
required_providers {
nubes = {
source = "terra.k8c.ru/nubes/nubes"
version = "5.0.19"
}
}
}
variable "api_token" {
type = string
sensitive = true
}
variable "realm" {
type = string
description = "resource_realm — зона размещения ресурса (например: k8s-3-sandbox-nubes-ru)"
}
variable "git_path" {
type = string
description = "URL git-репозитория с кодом приложения"
}
provider "nubes" {
api_token = var.api_token
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
}
+22
View File
@@ -0,0 +1,22 @@
# Создано: 2026-03-23
# nodejs.tf — ресурс nubes_nodejs: managed Node.js приложение.
# Параметры взяты из документации terra.k8c.ru/docs/nubes/nubes/5.0.19/30_registry/resources/nodejs_params_create/
resource "nubes_nodejs" "app" {
resource_name = "nodejsdemo1"
domain = "domma"
resource_realm = var.realm
git_path = var.git_path
app_version = "23"
resource_c_p_u = 500
resource_memory = 1024
resource_instances = 1
json_env = jsonencode({})
adopt_existing_on_create = true
# health_path не задан — используется дефолтный /
}
output "nodejs_domain" {
description = "Домен развёрнутого Node.js приложения"
value = nubes_nodejs.app.domain
}
+21
View File
@@ -0,0 +1,21 @@
# Terraform provider plugins
.terraform/
.terraform.lock.hcl
# Terraform state
terraform.tfstate
terraform.tfstate.backup
*.tfstate
*.tfstate.backup
# Sensitive data
terraform.tfvars
!terraform.tfvars.example
# Backup files
*.bak
*.bak_db
*.bak_*
# Test artifacts
test_*.log
+59
View File
@@ -0,0 +1,59 @@
// 2026-04-01 — main.tf: провайдеры и объявления переменных.
// Этот файл не нужно редактировать. Все настройки — в terraform.tfvars.
terraform {
required_providers {
nubes = {
source = "terra.k8c.ru/nubes/nubes"
version = "5.0.55"
}
}
}
// ── Объявления переменных ─────────────────────────────────────────────────────
// Значения задаются в terraform.tfvars — не трогать этот файл.
variable "api_token" {
type = string
sensitive = true
description = "Nubes API token"
}
variable "s3_uid" {
type = string
sensitive = true
description = "UUID S3-bucket для бэкапов PostgreSQL"
}
variable "realm" {
type = string
description = "Realm — идентификатор зоны/проекта в Nubes"
}
variable "pg_resource_name" {
type = string
description = "Имя инстанса PostgreSQL (уникально в рамках realm)"
}
variable "pg_username" {
type = string
description = "Имя пользователя PostgreSQL"
}
variable "pg_db_name" {
type = string
description = "Имя создаваемой базы данных"
}
variable "pg_role" {
type = string
description = "Роль пользователя"
}
// ── Провайдер ─────────────────────────────────────────────────────────────────
provider "nubes" {
api_token = var.api_token
log_level = "debug"
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
}
+42
View File
@@ -0,0 +1,42 @@
// 2026-04-01 — outputs.tf: данные подключения к PostgreSQL после apply.
//
// Пароль не выводим напрямую — только через sensitive output (не появляется
// в логах CI по умолчанию). Для явного показа: terraform output pg_password
output "pg_instance_id" {
description = "ID инстанса PostgreSQL в Nubes"
value = nubes_postgres.pg_test_instance.id
}
output "pg_host" {
description = "Внутренний адрес master-ноды PostgreSQL"
value = local.pg_host
}
output "pg_port" {
description = "Порт PostgreSQL"
value = local.pg_port
}
output "pg_database" {
description = "Имя базы данных"
value = nubes_postgres_database.pg_test_db.db_name
}
output "pg_username" {
description = "Имя пользователя PostgreSQL"
value = nubes_postgres_user.pg_test_user.username
}
output "pg_password" {
description = "Пароль пользователя из vault_secrets (пустой на первом apply — заполнится на следующем)"
value = local.pg_password
sensitive = true
}
// Удобная строка подключения — для psql или приложений.
output "pg_dsn" {
description = "DSN для подключения: postgresql://user:pass@host:port/db"
value = "postgresql://${nubes_postgres_user.pg_test_user.username}:${local.pg_password}@${local.pg_host}:${local.pg_port}/${nubes_postgres_database.pg_test_db.db_name}"
sensitive = true
}
+99
View File
@@ -0,0 +1,99 @@
// 2026-04-01 — postgres.tf: Managed PostgreSQL инстанс, пользователь и база данных.
//
// Порядок создания:
// 1. nubes_postgres — сам инстанс PostgreSQL
// 2. nubes_postgres_user — пользователь; пароль автоматически попадает в vault_secrets
// 3. nubes_postgres_database — база данных с owner = созданный пользователь
//
// Важно: vault_secrets["users"] появляется только ПОСЛЕ первого apply (нет пользователя — нет ключа).
// try() в locals страхует от ошибки на первом прогоне.
// ── Locals: credentials из vault ─────────────────────────────────────────────
locals {
# Карта username→{password, username} из vault_secrets, который Nubes заполняет после
# создания пользователя. try() нужен для первого apply, когда ключа ещё нет.
pg_creds_map = try(
jsondecode(lookup(nubes_postgres.pg_test_instance.vault_secrets, "users", "{}")),
{}
)
pg_password = try(local.pg_creds_map[var.pg_username]["password"], "")
# Адрес master-ноды (внутренний — для подключения из кластера).
pg_host = nubes_postgres.pg_test_instance.state_out_flat["internalConnect.master"]
pg_port = 5432
}
// ── Инстанс PostgreSQL ────────────────────────────────────────────────────────
resource "nubes_postgres" "pg_test_instance" {
resource_name = var.pg_resource_name
s3_uid = var.s3_uid
resource_realm = var.realm
# Минимальные ресурсы — достаточно для тестирования.
resource_instances = 1
resource_memory = 512 # MiB
resource_c_p_u = 500 # millicores
resource_disk = "1" # GiB
app_version = "17"
# json_parameters убран — при передаче пустого объекта API возвращает "Invalid JSON String".
# Если нужны кастомные параметры PG — добавить после диагностики.
# Pooler не нужен для тестов — упрощает топологию.
enable_pg_pooler_master = false
enable_pg_pooler_slave = false
allow_no_s_s_l = false
auto_scale = false
auto_scale_percentage = 10
auto_scale_tech_window = 0
auto_scale_quota_gb = "1"
# Внешний адрес не нужен — подключаемся изнутри кластера.
need_external_address_master = false
operation_timeout = "11m"
# Позволяет импортировать уже существующий инстанс с тем же именем, не падая
# с "already exists" — удобно при повторном apply после ручного создания.
adopt_existing_on_create = true
}
// ── Пользователь ──────────────────────────────────────────────────────────────
resource "nubes_postgres_user" "pg_test_user" {
postgres_id = nubes_postgres.pg_test_instance.id
username = var.pg_username
role = var.pg_role
# Не падать если пользователь с таким именем уже существует.
adopt_existing_on_create = true
}
resource "nubes_postgres_user" "pg_test_user3" {
postgres_id = nubes_postgres.pg_test_instance.id
username = "u3"
role = var.pg_role
depends_on = [nubes_postgres_user.pg_test_user]
# Не падать если пользователь с таким именем уже существует.
adopt_existing_on_create = true
}
// ── База данных ───────────────────────────────────────────────────────────────
resource "nubes_postgres_database" "pg_test_db" {
postgres_id = nubes_postgres.pg_test_instance.id
db_name = var.pg_db_name
db_owner = nubes_postgres_user.pg_test_user.username
# Не падать если БД уже существует.
adopt_existing_on_create = true
# ВАЖНО: из-за ограничения API Nubes (ERR-PG-08: "Concurrent operations are not supported")
# нужно явно ждать пользователя даже если он не выглядит dependency.
# других ресурс на инстансе ещё обрабатывает операции.
depends_on = [nubes_postgres_user.pg_test_user3]
}
+54
View File
@@ -0,0 +1,54 @@
# =============================================================================
# 2026-04-01 — terraform.tfvars
#
# ЕДИНСТВЕННЫЙ файл, который нужно заполнить перед запуском.
# Остальные .tf-файлы не трогать.
#
# Как запустить:
# 1. Скопировать этот файл: cp terraform.tfvars.example terraform.tfvars
# 2. Заполнить три обязательных поля ниже (ЗАПОЛНИТЬ)
# 3. terraform init
# 4. terraform apply
#
# После apply — увидеть данные подключения:
# terraform output pg_host
# terraform output pg_database
# terraform output pg_username
# terraform output -raw pg_password # пароль (показывается явно только с -raw)
# terraform output -raw pg_dsn # полная строка подключения
# =============================================================================
# =============================================================================
# ОБЯЗАТЕЛЬНО ЗАПОЛНИТЬ
# =============================================================================
# API-токен из личного кабинета Nubes.
# Где взять: https://deck-test.ngcloud.ru/ → Профиль → API-токены
api_token = "ЗАПОЛНИТЬ"
# UUID вашего S3-бакета — нужен PostgreSQL для хранения бэкапов.
# Пример: "332cdb0d-****-43bf-****-4adcc3b5****"
s3_uid = "ЗАПОЛНИТЬ"
# Realm — идентификатор вашей зоны/проекта.
# Пример: "k8s-3-sandbox-nubes-ru"
realm = "ЗАПОЛНИТЬ"
# =============================================================================
# МОЖНО ОСТАВИТЬ КАК ЕСТЬ (изменить при необходимости)
# =============================================================================
# Имя PostgreSQL-инстанса в Nubes.
# Должно быть уникальным в рамках realm. Менять если создаёте несколько стендов.
pg_resource_name = "pg-test-01"
# Имя пользователя базы данных.
pg_username = "pgtest_user"
# Имя базы данных.
pg_db_name = "pgtest_db"
# Роль пользователя.
pg_role = "ddl_user"
+49
View File
@@ -0,0 +1,49 @@
#!/usr/bin/env bash
# 2026-04-01 — test_basic.sh: простая проверка что ресурсы созданы и outputs заполнены.
# Не делает apply/destroy — только читает state и outputs.
# Запуск: bash test_basic.sh
set -uo pipefail
DIR="$(cd "$(dirname "$0")" && pwd)"
cd "$DIR"
GREEN="\033[0;32m"; RED="\033[0;31m"; NC="\033[0m"
PASS=0; FAIL=0
ok() { echo -e "${GREEN}PASS${NC} $1"; PASS=$((PASS+1)); }
fail() { echo -e "${RED}FAIL${NC} $1"; FAIL=$((FAIL+1)); }
echo "=== PG_TEST basic check — $(date '+%Y-%m-%d %H:%M:%S') ==="
echo ""
# ── 1. Нужные ресурсы есть в state ───────────────────────────────────────────
echo "--- state ---"
for res in \
"nubes_postgres.pg_test_instance" \
"nubes_postgres_user.pg_test_user" \
"nubes_postgres_database.pg_test_db"
do
if terraform state show "$res" > /dev/null 2>&1; then
ok "state: $res"
else
fail "state: $res — не найден"
fi
done
echo ""
# ── 2. Outputs непустые ───────────────────────────────────────────────────────
echo "--- outputs ---"
pg_host=$(terraform output -raw pg_host 2>/dev/null || true)
pg_db=$(terraform output -raw pg_database 2>/dev/null || true)
pg_user=$(terraform output -raw pg_username 2>/dev/null || true)
pg_pass=$(terraform output -raw pg_password 2>/dev/null || true)
[[ -n "$pg_host" ]] && ok "pg_host = $pg_host" || fail "pg_host пустой"
[[ -n "$pg_db" ]] && ok "pg_database = $pg_db" || fail "pg_database пустой"
[[ -n "$pg_user" ]] && ok "pg_username = $pg_user" || fail "pg_username пустой"
[[ -n "$pg_pass" ]] && ok "pg_password непустой" || fail "pg_password пустой (возможно нужен повторный apply)"
echo ""
echo "=== Итог: PASS=$PASS FAIL=$FAIL ==="
+187
View File
@@ -0,0 +1,187 @@
#!/usr/bin/env bash
# 2026-04-01 — test_lifecycle.sh
# Гоняет реальный API Nubes: создание/удаление/модификация пользователей и БД.
# Каждый шаг — отдельный terraform apply с живым выводом.
# Запуск: bash test_lifecycle.sh
set -uo pipefail
DIR="$(cd "$(dirname "$0")" && pwd)"
cd "$DIR"
GREEN="\033[0;32m"; RED="\033[0;31m"; YELLOW="\033[1;33m"; CYAN="\033[0;36m"; NC="\033[0m"
PASS=0; FAIL=0
ok() { echo -e "\n${GREEN}>>> PASS${NC} $1"; PASS=$((PASS+1)); }
fail() { echo -e "\n${RED}>>> FAIL${NC} $1"; FAIL=$((FAIL+1)); }
section() { echo -e "\n${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n $1\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"; }
step() { echo -e "\n${CYAN}--- $1 ---${NC}"; }
# run_apply — terraform apply с живым выводом в терминал.
run_apply() {
echo ""
terraform apply -auto-approve
return $?
}
# run_apply_expect_fail — apply должен упасть (ошибка API = успех теста).
run_apply_expect_fail() {
local label="$1"
echo ""
if terraform apply -auto-approve; then
fail "$label — ожидали ошибку API, но apply прошёл!"
else
ok "$label — API вернул ошибку (ожидаемо)"
fi
}
echo -e "\n${YELLOW}╔══════════════════════════════════════════════════════╗"
echo "║ PG_TEST lifecycle — $(date '+%Y-%m-%d %H:%M:%S')"
echo -e "╚══════════════════════════════════════════════════════╝${NC}"
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 0 — Очистка: destroy всего перед стартом"
# ─────────────────────────────────────────────────────────────────────────────
# Гарантируем чистый старт — убираем все ресурсы и state.
step "terraform destroy (убираем всё что осталось от предыдущих прогонов)"
terraform destroy -auto-approve || true # не падаем если уже пусто
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 1 — Создать: 2 пользователя + 2 БД + 1 app_user"
# ─────────────────────────────────────────────────────────────────────────────
step "terraform apply (postgres.tf + postgres_extra.tf)"
if run_apply; then
ok "Создание прошло"
else
fail "Создание упало — дальше не идём"
exit 1
fi
echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 2 — Удалить extra_user2 и extra_db2"
# ─────────────────────────────────────────────────────────────────────────────
step "Убираем test_extra_user2 и test_extra_db2 из tf"
python3 - <<'PYEOF'
import re, pathlib
def comment_block(path, resource_type, resource_name):
text = pathlib.Path(path).read_text()
pattern = rf'(resource\s+"{re.escape(resource_type)}"\s+"{re.escape(resource_name)}"\s*\{{)'
match = re.search(pattern, text)
if not match:
print(f" WARNING: {resource_type}.{resource_name} not found"); return
start = match.start(); depth, i = 0, start
while i < len(text):
if text[i] == '{': depth += 1
elif text[i] == '}':
depth -= 1
if depth == 0: end = i + 1; break
i += 1
pathlib.Path(path).write_text(
text[:start] + "/* DISABLED\n" + text[start:end] + "\nDISABLED */" + text[end:]
)
print(f" скрыт: {resource_type}.{resource_name}")
comment_block("postgres_extra.tf", "nubes_postgres_user", "test_extra_user2")
comment_block("postgres_extra.tf", "nubes_postgres_database", "test_extra_db2")
PYEOF
step "terraform apply — API удаляет user2 и db2"
if run_apply; then ok "Удаление прошло"; else fail "Удаление упало"; fi
echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 3 — Воссоздать extra_user2 и extra_db2"
# ─────────────────────────────────────────────────────────────────────────────
step "Восстанавливаем tf"
python3 - <<'PYEOF'
import pathlib, re
p = pathlib.Path("postgres_extra.tf")
text = re.sub(r'/\* DISABLED\n', '', p.read_text())
text = re.sub(r'\nDISABLED \*/', '', text)
p.write_text(text); print(" postgres_extra.tf восстановлен")
PYEOF
step "terraform apply — API воссоздаёт user2 и db2"
if run_apply; then ok "Воссоздание прошло"; else fail "Воссоздание упало"; fi
echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 4 — Модификация: сменить db_owner у extra_db1"
# ─────────────────────────────────────────────────────────────────────────────
step "db_owner test_extra_db1: extra_user1 → extra_user2"
python3 - <<'PYEOF'
import pathlib
p = pathlib.Path("postgres_extra.tf")
text = p.read_text().replace(
'nubes_postgres_user.test_extra_user1.username',
'nubes_postgres_user.test_extra_user2.username', 1)
p.write_text(text); print(" db_owner: user1 → user2")
PYEOF
step "terraform apply — API обновляет db_owner"
if run_apply; then ok "Смена db_owner прошла"; else fail "Смена db_owner упала"; fi
step "Откат db_owner обратно (user2 → user1)"
python3 - <<'PYEOF'
import pathlib
p = pathlib.Path("postgres_extra.tf")
text = p.read_text().replace(
'nubes_postgres_user.test_extra_user2.username',
'nubes_postgres_user.test_extra_user1.username', 1)
p.write_text(text); print(" db_owner: user2 → user1")
PYEOF
run_apply > /dev/null 2>&1 || true
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 5 — Невалидные параметры: ждём ошибку API"
# ─────────────────────────────────────────────────────────────────────────────
step "Тест 5a: db_owner = несуществующий пользователь"
cat > ./pg_test_invalid.tf <<'TFEOF'
resource "nubes_postgres_database" "test_invalid_owner" {
postgres_id = nubes_postgres.pg_test_instance.id
db_name = "invalid_owner_db"
db_owner = "this_user_does_not_exist"
adopt_existing_on_create = false
}
TFEOF
run_apply_expect_fail "5a: db_owner='this_user_does_not_exist'"
rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
step "Тест 5b: role = несуществующая строка"
cat > ./pg_test_invalid.tf <<'TFEOF'
resource "nubes_postgres_user" "test_invalid_role" {
postgres_id = nubes_postgres.pg_test_instance.id
username = "invalid_role_user"
role = "fantasy_role_xyz"
adopt_existing_on_create = false
}
TFEOF
run_apply_expect_fail "5b: role='fantasy_role_xyz'"
rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
# ─────────────────────────────────────────────────────────────────────────────
section "ШАГ 6 — app_user пытается стать db_owner"
# ─────────────────────────────────────────────────────────────────────────────
# app_user — базовые права. Нельзя быть db_owner — это прерогатива ddl_user.
step "Тест 6a: test_app_user (role=app_user) назначается db_owner"
cat > ./pg_test_invalid.tf <<'TFEOF'
resource "nubes_postgres_database" "test_appuser_as_owner" {
postgres_id = nubes_postgres.pg_test_instance.id
db_name = "appuser_owned_db"
db_owner = nubes_postgres_user.test_app_user.username
adopt_existing_on_create = false
}
TFEOF
run_apply_expect_fail "6a: app_user как db_owner — API должен отклонить"
rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
# ─────────────────────────────────────────────────────────────────────────────
section "ИТОГ"
# ─────────────────────────────────────────────────────────────────────────────
echo ""
echo -e " PASS: ${GREEN}${PASS}${NC} FAIL: ${RED}${FAIL}${NC}"
echo ""
[[ "$FAIL" -eq 0 ]] \
&& echo -e "${GREEN}Все тесты прошли.${NC}" \
|| echo -e "${RED}Есть ошибки — проверь вывод выше.${NC}"
-301
View File
@@ -1,301 +0,0 @@
// 2026-03-21 — chaos_marathon.tf: 15 новых сервисов для часового хаос-марафона.
// Три рантайма: python3.11 (9), nodejs20 (2), go1.23 (2).
// Все зависят от sless_job.postgres_table_init_job.
# ── Python: работа с таблицей ─────────────────────────────────────────────────
# Считает строки по prefix — тест concurrent reads + COUNT агрегации.
resource "sless_service" "pg_counter" {
name = "pg-counter"
runtime = "python3.11"
entrypoint = "pg_counter.count"
memory_mb = 128
timeout_sec = 15
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-counter"
depends_on = [sless_job.postgres_table_init_job]
}
# DELETE дублей по title — идемпотентный, повторный вызов безопасен.
resource "sless_service" "pg_dedup" {
name = "pg-dedup"
runtime = "python3.11"
entrypoint = "pg_dedup.dedup"
memory_mb = 128
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-dedup"
depends_on = [sless_job.postgres_table_init_job]
}
# Поиск по title с ILIKE + пагинация — тест спецсимволов и SQL injection safety.
resource "sless_service" "pg_search" {
name = "pg-search"
runtime = "python3.11"
entrypoint = "pg_search.search"
memory_mb = 128
timeout_sec = 15
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-search"
depends_on = [sless_job.postgres_table_init_job]
}
# Bulk INSERT через execute_values — до 500 строк за раз.
resource "sless_service" "pg_bulk_insert" {
name = "pg-bulk-insert"
runtime = "python3.11"
entrypoint = "pg_bulk_insert.bulk_insert"
memory_mb = 256
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-bulk-insert"
depends_on = [sless_job.postgres_table_init_job]
}
# DELETE строк старше N минут — идемпотентный.
resource "sless_service" "pg_delete_old" {
name = "pg-delete-old"
runtime = "python3.11"
entrypoint = "pg_delete_old.delete_old"
memory_mb = 128
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-delete-old"
depends_on = [sless_job.postgres_table_init_job]
}
# INSERT ON CONFLICT DO UPDATE — повторный вызов с тем же title безопасен.
resource "sless_service" "pg_upsert" {
name = "pg-upsert"
runtime = "python3.11"
entrypoint = "pg_upsert.upsert"
memory_mb = 128
timeout_sec = 15
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-upsert"
depends_on = [sless_job.postgres_table_init_job]
}
# ── Python: chaos ─────────────────────────────────────────────────────────────
# Echo: принимает любой ввод и отражает обратно — проверка на мусорный input.
resource "sless_service" "chaos_echo" {
name = "chaos-echo"
runtime = "python3.11"
entrypoint = "chaos_echo.echo"
memory_mb = 128
timeout_sec = 10
source_dir = "${path.module}/code/chaos-echo"
depends_on = [sless_job.postgres_table_init_job]
}
# Валидация плохих параметров — тупой юзер не может уронить сервис.
resource "sless_service" "chaos_badparams" {
name = "chaos-badparams"
runtime = "python3.11"
entrypoint = "chaos_badparams.validate"
memory_mb = 128
timeout_sec = 10
source_dir = "${path.module}/code/chaos-badparams"
depends_on = [sless_job.postgres_table_init_job]
}
# Медленный pg_sleep — тест timeout enforcement.
resource "sless_service" "chaos_slowquery" {
name = "chaos-slowquery"
runtime = "python3.11"
entrypoint = "chaos_slowquery.slowquery"
memory_mb = 128
timeout_sec = 12
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/chaos-slowquery"
depends_on = [sless_job.postgres_table_init_job]
}
# Большой JSON response — тест памяти и серилизации.
resource "sless_service" "chaos_bigpayload" {
name = "chaos-bigpayload"
runtime = "python3.11"
entrypoint = "chaos_bigpayload.bigpayload"
memory_mb = 256
timeout_sec = 15
source_dir = "${path.module}/code/chaos-bigpayload"
depends_on = [sless_job.postgres_table_init_job]
}
# ── Node.js ───────────────────────────────────────────────────────────────────
# Bulk INSERT через параметризованный multi-value query.
resource "sless_service" "js_pg_batch" {
name = "js-pg-batch"
runtime = "nodejs20"
entrypoint = "js_pg_batch.run"
memory_mb = 128
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/js-pg-batch"
depends_on = [sless_job.postgres_table_init_job]
}
# Идемпотентный INSERT — повторный вызов с тем же key = existing, не дубль.
resource "sless_service" "js_idempotent" {
name = "js-idempotent"
runtime = "nodejs20"
entrypoint = "js_idempotent.run"
memory_mb = 128
timeout_sec = 15
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/js-idempotent"
depends_on = [sless_job.postgres_table_init_job]
}
# ── Go 1.23 ───────────────────────────────────────────────────────────────────
# Параллельные concurrent INSERTs из N горутин внутри одного пода.
resource "sless_service" "go_pg_race" {
name = "go-pg-race"
runtime = "go1.23"
entrypoint = "handler.Handle"
memory_mb = 256
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/go-pg-race"
depends_on = [sless_job.postgres_table_init_job]
}
# Atomic-счётчик в памяти + PG INSERT на каждый вызов.
resource "sless_service" "go_counter_atomic" {
name = "go-counter-atomic"
runtime = "go1.23"
entrypoint = "handler.Handle"
memory_mb = 128
timeout_sec = 15
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/go-counter-atomic"
depends_on = [sless_job.postgres_table_init_job]
}
# ── Python: retry ─────────────────────────────────────────────────────────────
# Запись с retry при transient PG error — тест устойчивости к сбоям.
resource "sless_service" "py_retry_writer" {
name = "py-retry-writer"
runtime = "python3.11"
entrypoint = "py_retry_writer.retry_write"
memory_mb = 128
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/py-retry-writer"
depends_on = [sless_job.postgres_table_init_job]
}
@@ -0,0 +1,9 @@
// Создано: 2026-04-10
// Демо-функция: возвращает текущее время сервера.
// Юзер меняет код под себя и перебилдит через terraform apply.
'use strict';
module.exports.handler = function handler(event) {
return `Текущее время: ${new Date().toISOString()}`;
};
@@ -0,0 +1,3 @@
{
"dependencies": {}
}
@@ -0,0 +1,105 @@
# Создано: 2026-04-10
# Изменено: 2026-03-23 — упрощён до поля ввода выражения (демонстрация деплоя).
# Принимает произвольное математическое выражение: "2+2*(3-1)", "(10/3)**2" и т.д.
# GET → HTML страница с формой; POST с {expr} → вычисление через безопасный eval.
# Безопасность eval: __builtins__=None, только math-функции в locals.
import math
_PAGE = """<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Калькулятор — Python 3.11</title>
<style>
body { font-family: monospace; background: #0f172a; color: #e2e8f0;
display: flex; justify-content: center; align-items: center; min-height: 100vh; margin: 0; }
.box { background: #1e293b; border-radius: 12px; padding: 32px; width: 420px; box-shadow: 0 8px 32px #0005; }
h2 { margin: 0 0 4px; font-size: 20px; color: #7dd3fc; }
.sub { color: #475569; font-size: 12px; margin-bottom: 24px; }
input { width: 100%; box-sizing: border-box; padding: 10px 14px; font-size: 18px; font-family: monospace;
background: #0f172a; border: 1px solid #334155; border-radius: 8px; color: #f1f5f9; outline: none; }
input:focus { border-color: #38bdf8; }
button { margin-top: 12px; width: 100%; padding: 12px; font-size: 16px; background: #0369a1;
color: #fff; border: none; border-radius: 8px; cursor: pointer; }
button:hover { background: #0284c7; }
button:disabled { background: #1e3a5f; color: #475569; cursor: default; }
.result { margin-top: 20px; padding: 14px; border-radius: 8px; font-size: 22px; text-align: center; display: none; }
.ok { background: #064e3b; color: #6ee7b7; display: block; }
.err { background: #450a0a; color: #fca5a5; font-size: 14px; display: block; }
</style>
</head>
<body>
<div class="box">
<h2>Калькулятор</h2>
<div class="sub">Python 3.11 · runtime: sless</div>
<input id="expr" autofocus placeholder="например: 2 + 2 * (3 - 1)">
<button id="btn" onclick="calc()">Вычислить</button>
<div id="result" class="result"></div>
</div>
<script>
document.getElementById('expr').addEventListener('keydown', function(e) {
if (e.key === 'Enter') calc();
});
async function calc() {
const expr = document.getElementById('expr').value.trim();
if (!expr) return;
const btn = document.getElementById('btn');
const res = document.getElementById('result');
btn.disabled = true;
btn.textContent = '';
try {
const r = await fetch('', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({expr: expr})
});
const data = await r.json();
if (data.error) {
res.className = 'result err';
res.textContent = data.error;
} else {
res.className = 'result ok';
res.textContent = expr + ' = ' + data.result;
}
} catch(e) {
res.className = 'result err';
res.textContent = 'Ошибка сети: ' + e.message;
}
btn.disabled = false;
btn.textContent = 'Вычислить';
}
</script>
</body>
</html>"""
# Разрешённые math-функции в eval — без __builtins__ нет доступа к exec/open/etc.
_MATH_LOCALS = {k: getattr(math, k) for k in dir(math) if not k.startswith('_')}
def handler(event):
if event.get('_method') == 'POST':
expr = str(event.get('expr', '')).strip()
return _compute(expr)
# GET → HTML страница
return _PAGE
def _compute(expr):
if not expr:
return {'error': 'Введите выражение'}
try:
result = eval(expr, {'__builtins__': None}, _MATH_LOCALS) # noqa: S307
if not isinstance(result, (int, float)):
return {'error': 'Результат не является числом'}
return {'expr': expr, 'result': result}
except ZeroDivisionError:
return {'error': 'Деление на ноль'}
except Exception as exc:
return {'error': f'Ошибка: {exc}'}
def _esc(s):
# Экранируем HTML-спецсимволы — безопасный вывод в атрибут и тело.
return s.replace('&', '&amp;').replace('<', '&lt;').replace('>', '&gt;').replace('"', '&quot;')
@@ -0,0 +1 @@
# нет внешних зависимостей
@@ -1,40 +0,0 @@
# 2026-03-21 — chaos-badparams: проверяет что функция не падает на мусорных входных данных.
# Принимает type=missing|wrong_type|huge|negative|zero и возвращает safe-ответ.
# Тестирует: устойчивость к "тупому юзеру" — никакого 500 на плохих входных данных.
import json
_MAX_N = 10_000
def validate(event):
errors = []
results = {}
# n: должно быть int от 1 до MAX_N
raw_n = event.get("n")
try:
n = int(raw_n)
if n <= 0:
errors.append(f"n must be > 0, got {n}")
n = 1
elif n > _MAX_N:
errors.append(f"n capped from {n} to {_MAX_N}")
n = _MAX_N
except (TypeError, ValueError):
errors.append(f"n is not a valid int: {repr(raw_n)}, using default 1")
n = 1
results["n"] = n
# name: обрезаем до 100 символов
raw_name = event.get("name", "")
if not isinstance(raw_name, str):
raw_name = str(raw_name)
errors.append("name was not a string, converted")
name = raw_name[:100]
results["name"] = name
# flag: любое "truthy" значение
raw_flag = event.get("flag", False)
flag = raw_flag in (True, "true", "1", 1, "yes")
results["flag"] = flag
return {"ok": len(errors) == 0, "errors": errors, "results": results}
@@ -1,27 +0,0 @@
# 2026-03-21 — chaos-bigpayload: генерирует/принимает большой JSON.
# Тестирует: большие ответы (64KB+), память рантайма.
import json, time
def bigpayload(event):
size_kb = min(int(event.get("size_kb", 16)), 256) # cap 256KB
word = str(event.get("word", "x"))[:32]
# Генерируем список строк нужного размера
chunk = word * 32 # ~32+ байт на запись
items = []
total = 0
target = size_kb * 1024
i = 0
while total < target:
entry = f"{chunk}-{i}"
items.append(entry)
total += len(entry) + 3 # 3 байта JSON overhead
i += 1
return {
"items_count": len(items),
"size_kb_approx": round(total / 1024, 1),
"first": items[0] if items else "",
"last": items[-1] if items else "",
"ts": int(time.time()),
}
@@ -1,19 +0,0 @@
# 2026-03-21 — chaos-echo: отражает входные данные обратно.
# Тестирует: большие payload, unicode, null, вложенные структуры, спецсимволы.
# "Тупой юзер" шлёт всё что угодно — функция должна вернуть это обратно без падения.
import json
def echo(event):
# Пытаемся сериализовать обратно — выловит непериализуемые типы
try:
size = len(json.dumps(event))
except Exception:
size = -1
keys = list(event.keys()) if isinstance(event, dict) else []
return {
"echo": event,
"keys": keys,
"size_bytes": size,
"type": type(event).__name__,
}
@@ -1,19 +0,0 @@
# 2026-03-21 — chaos-slowquery: намеренно медленный запрос через pg_sleep.
# Тестирует: timeout enforcement — платформа должна прервать запрос если > timeout_sec.
# sleep_sec cap = 8 (меньше timeout_sec=10 сервиса → успех; >10 → таймаут платформы).
import os, psycopg2
def slowquery(event):
sleep_sec = min(float(event.get("sleep_sec", 2.0)), 8.0)
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
try:
with conn.cursor() as cur:
cur.execute("SELECT pg_sleep(%s), now()::text", (sleep_sec,))
result = cur.fetchone()
return {"slept_sec": sleep_sec, "pg_now": result[1]}
finally:
conn.close()
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,94 +0,0 @@
# 2026-03-18 (обновлено: plain text вывод; фильтрация SLESS_EXCLUDE)
# funcs_list.py — HTTP-функция: список пользовательских функций, человекочитаемый plain text.
# Вызывает внутренний REST API оператора (ClusterIP, без TLS).
# Возвращает str → python runtime отдаёт text/plain напрямую без json.dumps.
#
# Env vars:
# SLESS_API_URL — URL оператора (http://sless-operator.sless.svc.cluster.local:9090)
# SLESS_NAMESPACE — namespace пользователя (sless-{hex16})
# SLESS_TOKEN — JWT токен для /v1/ API
# SLESS_EXTERNAL_URL — публичный базовый URL (https://sless.kube5s.ru)
# SLESS_EXCLUDE — comma-separated имена функций, которые не показывать
import os
import requests
SEP = "" * 52
def _comment(fn, http_trigs, cron_trigs):
phase = fn.get("phase", "?")
runtime = fn.get("runtime", "?")
if http_trigs:
active = "активна" if http_trigs[0].get("active") else "неактивна"
return f"HTTP endpoint ({runtime}) — {phase}, {active}"
elif cron_trigs:
schedule = cron_trigs[0].get("schedule", "?")
active = "активна" if cron_trigs[0].get("active") else "неактивна"
return f"Cron '{schedule}' ({runtime}) — {phase}, {active}"
else:
return f"Job/runner без триггера ({runtime}) — {phase}"
def list_all(event):
api_url = os.environ["SLESS_API_URL"].rstrip("/")
namespace = os.environ["SLESS_NAMESPACE"]
token = os.environ["SLESS_TOKEN"]
ext_url = os.environ.get("SLESS_EXTERNAL_URL", "").rstrip("/")
exclude = {n.strip() for n in os.environ.get("SLESS_EXCLUDE", "").split(",") if n.strip()}
headers = {"Authorization": f"Bearer {token}"}
fns = requests.get(f"{api_url}/v1/namespaces/{namespace}/functions", headers=headers, timeout=10)
trs = requests.get(f"{api_url}/v1/namespaces/{namespace}/triggers", headers=headers, timeout=10)
fns.raise_for_status()
trs.raise_for_status()
trig_idx = {}
for tr in trs.json():
fn_name = tr.get("function") or tr.get("functionRef")
if fn_name:
trig_idx.setdefault(fn_name, []).append(tr)
items = []
for fn in fns.json():
name = fn["name"]
if name in exclude:
continue
http_t = [t for t in trig_idx.get(name, []) if t.get("type") == "http"]
cron_t = [t for t in trig_idx.get(name, []) if t.get("type") == "cron"]
is_active = any(t.get("enabled", True) and t.get("active", False) for t in trig_idx.get(name, []))
items.append((fn, http_t, cron_t, is_active))
# Сортировка: активные вверх, затем по имени
items.sort(key=lambda x: (not x[3], x[0]["name"]))
lines = []
for fn, http_t, cron_t, is_active in items:
name = fn["name"]
lines.append(SEP)
lines.append(f" {_comment(fn, http_t, cron_t)}")
lines.append(f" name: {name}")
lines.append(f" runtime: {fn.get('runtime', '?')}")
lines.append(f" phase: {fn.get('phase', '?')}")
lines.append(f" active: {'да' if is_active else 'нет'}")
if http_t:
url = f"{ext_url}/fn/{namespace}/{name}" if ext_url else http_t[0].get("url", "")
lines.append(f" url: {url}")
if cron_t:
lines.append(f" cron: {cron_t[0].get('schedule', '?')}")
if fn.get("created_at"):
lines.append(f" created: {fn['created_at']}")
if fn.get("last_built_at"):
lines.append(f" built: {fn['last_built_at']}")
if fn.get("message"):
lines.append(f" message: {fn['message']}")
lines.append(SEP)
lines.append(f" namespace: {namespace} | total: {len(items)}")
lines.append(SEP)
# Возвращаем str — python runtime отдаст text/plain напрямую
return "\n".join(lines) + "\n"
@@ -1 +0,0 @@
requests==2.31.0
@@ -1,55 +0,0 @@
// 2026-03-21 — go-counter-atomic: считает вызовы через atomic в памяти + пишет в PG.
// Тестирует: in-memory state между вызовами (Go pod остаётся живым), + PG INSERT на каждый вызов.
package handler
import (
"context"
"fmt"
"os"
"sync/atomic"
"time"
"github.com/jackc/pgx/v5/pgxpool"
)
// invocations считается между вызовами (пока pod жив).
var invocations int64
// Handle записывает факт вызова в PG и возвращает накопленный счётчик.
func Handle(event map[string]interface{}) interface{} {
n := atomic.AddInt64(&invocations, 1)
dsn := fmt.Sprintf(
"host=%s port=%s dbname=%s user=%s password=%s sslmode=%s",
os.Getenv("PGHOST"), envOrDefault("PGPORT", "5432"),
os.Getenv("PGDATABASE"), os.Getenv("PGUSER"),
os.Getenv("PGPASSWORD"), envOrDefault("PGSSLMODE", "require"),
)
pool, err := pgxpool.New(context.Background(), dsn)
if err != nil {
return map[string]interface{}{"invocation_n": n, "error": err.Error()}
}
defer pool.Close()
title := fmt.Sprintf("go-counter-invoke-%d-%d", n, time.Now().UnixMilli())
var id int64
err = pool.QueryRow(context.Background(),
"INSERT INTO terraform_demo_table (title) VALUES ($1) RETURNING id", title,
).Scan(&id)
if err != nil {
return map[string]interface{}{"invocation_n": n, "error": err.Error()}
}
return map[string]interface{}{
"invocation_n": n,
"inserted_id": id,
"title": title,
}
}
func envOrDefault(key, def string) string {
if v := os.Getenv(key); v != "" {
return v
}
return def
}
@@ -1,94 +0,0 @@
// 2026-03-21 — go-pg-race: параллельные INSERT из нескольких горутин внутри одной функции.
// Тестирует: race condition устойчивость Go + PG при concurrent writes из одного пода.
// Использует pgx/v5 (pre-cached в base image).
package handler
import (
"context"
"fmt"
"os"
"sync"
"sync/atomic"
"time"
"github.com/jackc/pgx/v5/pgxpool"
)
// Handle запускает workers горутин, каждая делает n_per_worker INSERTs.
func Handle(event map[string]interface{}) interface{} {
workers := intParam(event, "workers", 5)
if workers > 20 {
workers = 20
}
nPerWorker := intParam(event, "n_per_worker", 10)
if nPerWorker > 50 {
nPerWorker = 50
}
dsn := fmt.Sprintf(
"host=%s port=%s dbname=%s user=%s password=%s sslmode=%s",
os.Getenv("PGHOST"), getenv("PGPORT", "5432"),
os.Getenv("PGDATABASE"), os.Getenv("PGUSER"),
os.Getenv("PGPASSWORD"), getenv("PGSSLMODE", "require"),
)
pool, err := pgxpool.New(context.Background(), dsn)
if err != nil {
return map[string]interface{}{"error": err.Error()}
}
defer pool.Close()
var (
wg sync.WaitGroup
ok int64
errCount int64
)
t0 := time.Now()
for w := 0; w < workers; w++ {
wg.Add(1)
go func(wid int) {
defer wg.Done()
for i := 0; i < nPerWorker; i++ {
title := fmt.Sprintf("go-race-w%d-%d-%d", wid, time.Now().UnixMilli(), i)
_, err := pool.Exec(context.Background(),
"INSERT INTO terraform_demo_table (title) VALUES ($1)", title)
if err != nil {
atomic.AddInt64(&errCount, 1)
} else {
atomic.AddInt64(&ok, 1)
}
}
}(w)
}
wg.Wait()
elapsed := time.Since(t0).Seconds()
return map[string]interface{}{
"workers": workers,
"n_per_worker": nPerWorker,
"inserted": ok,
"errors": errCount,
"elapsed_sec": elapsed,
"ops_per_sec": float64(ok) / elapsed,
}
}
func intParam(event map[string]interface{}, key string, def int) int {
v, ok := event[key]
if !ok {
return def
}
switch val := v.(type) {
case float64:
return int(val)
case int:
return val
}
return def
}
func getenv(key, def string) string {
if v := os.Getenv(key); v != "" {
return v
}
return def
}
@@ -1,43 +0,0 @@
// 2026-03-21 — js-pg-batch: вставляет N строк через parameterized bulk query.
// Тестирует: async/await PG с пакетной вставкой, Node.js под нагрузкой.
const { Client } = require('pg');
async function run(event) {
const n = Math.min(parseInt(event.n ?? 20, 10) || 20, 200);
const prefix = String(event.prefix ?? 'js-batch').slice(0, 40);
const client = new Client({
host: process.env.PGHOST,
port: parseInt(process.env.PGPORT ?? '5432'),
database: process.env.PGDATABASE,
user: process.env.PGUSER,
password: process.env.PGPASSWORD,
ssl: { rejectUnauthorized: false },
});
await client.connect();
try {
const ts = Date.now();
// Строим multi-value INSERT: INSERT INTO ... VALUES ($1), ($2), ...
const placeholders = [];
const values = [];
for (let i = 0; i < n; i++) {
placeholders.push(`($${i + 1})`);
values.push(`${prefix}-${ts}-${i}`);
}
const sql = `INSERT INTO terraform_demo_table (title) VALUES ${placeholders.join(',')} RETURNING id`;
const t0 = Date.now();
const res = await client.query(sql, values);
const elapsed = (Date.now() - t0) / 1000;
return {
inserted: res.rowCount,
first_id: res.rows[0]?.id ?? null,
elapsed_sec: elapsed,
};
} finally {
await client.end();
}
}
module.exports = { run };
@@ -1,7 +0,0 @@
{
"name": "js-pg-batch",
"version": "1.0.0",
"dependencies": {
"pg": "^8.11.3"
}
}
@@ -1,38 +0,0 @@
# 2026-03-21 — pg-bulk-insert: bulk INSERT через execute_values.
# Тестирует: большие батчи (до 500 строк), производительность, память.
import os, time, psycopg2, psycopg2.extras
def bulk_insert(event):
try:
n = max(0, min(int(event.get("n", 50)), 500)) # cap 500, min 0
except (TypeError, ValueError):
n = 50
prefix = str(event.get("prefix", "bulk"))[:50]
ts = int(time.time() * 1000)
# n=0 — граничный случай: вернуть сразу без обращения к PG.
if n == 0:
return {"inserted": 0, "first_id": None, "elapsed_sec": 0.0}
rows = [(f"{prefix}-{ts}-{i}",) for i in range(n)]
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
try:
t0 = time.time()
with conn.cursor() as cur:
psycopg2.extras.execute_values(
cur,
"INSERT INTO terraform_demo_table (title) VALUES %s RETURNING id",
rows,
page_size=100,
)
ids = [r[0] for r in cur.fetchall()]
conn.commit()
elapsed = round(time.time() - t0, 3)
return {"inserted": len(ids), "first_id": ids[0] if ids else None, "elapsed_sec": elapsed}
finally:
conn.close()
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,38 +0,0 @@
# 2026-03-21 — pg-dedup: удаляет дубликаты по title, оставляет первый (min id).
# Тестирует: DELETE с subquery, CTE, idempotency (повторный вызов безопасен).
import os, psycopg2
def dedup(event):
dry_run = str(event.get("dry_run", "false")).lower() in ("true", "1", "yes")
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
try:
with conn.cursor() as cur:
# Считаем сколько дублей есть
cur.execute("""
SELECT COUNT(*) FROM terraform_demo_table t1
WHERE EXISTS (
SELECT 1 FROM terraform_demo_table t2
WHERE t2.title = t1.title AND t2.id < t1.id
)
""")
dupes_count = cur.fetchone()[0]
if not dry_run and dupes_count > 0:
cur.execute("""
DELETE FROM terraform_demo_table
WHERE id NOT IN (
SELECT MIN(id) FROM terraform_demo_table GROUP BY title
)
""")
deleted = cur.rowcount
conn.commit()
else:
deleted = 0
return {"duplicates_found": dupes_count, "deleted": deleted, "dry_run": dry_run}
finally:
conn.close()
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,33 +0,0 @@
# 2026-03-21 — pg-delete-old: удаляет строки старше N минут (default 60).
# Тестирует: DELETE с RETURNING, идемпотентность (повторный вызов = 0 удалений если нет старых).
import os, psycopg2, psycopg2.extras
def delete_old(event):
older_than_min = max(int(event.get("older_than_min", 60)), 1)
prefix_filter = event.get("prefix", "")
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
try:
with conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor) as cur:
if prefix_filter:
cur.execute(
"DELETE FROM terraform_demo_table "
"WHERE created_at < now() - interval '1 minute' * %s "
"AND title LIKE %s RETURNING id, title",
(older_than_min, f"{prefix_filter}%"),
)
else:
cur.execute(
"DELETE FROM terraform_demo_table "
"WHERE created_at < now() - interval '1 minute' * %s RETURNING id, title",
(older_than_min,),
)
deleted = [dict(r) for r in cur.fetchall()]
conn.commit()
return {"deleted": len(deleted), "older_than_min": older_than_min, "sample": deleted[:5]}
finally:
conn.close()
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,36 +0,0 @@
# 2026-03-21 — pg-search: полнотекстовый поиск по title через ILIKE + LIMIT/OFFSET.
# Тестирует: пагинацию, спецсимволы в input (XSS, SQL injection attempt → безопасно через параметры).
import os, psycopg2, psycopg2.extras
def search(event):
# «query» — основной параметр (user-friendly), «q» — алиас для совместимости.
query = str(event.get("query") or event.get("q") or "")[:200]
# int() может упасть если юзер прислал строку — защищаем try/except.
try:
limit = max(1, min(int(event.get("limit", 20)), 100))
except (TypeError, ValueError):
limit = 20
try:
offset = max(0, int(event.get("offset", 0)))
except (TypeError, ValueError):
offset = 0
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
try:
with conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor) as cur:
pattern = f"%{query}%" if query else "%"
cur.execute(
"SELECT id, title, created_at::text FROM terraform_demo_table "
"WHERE title ILIKE %s ORDER BY id DESC LIMIT %s OFFSET %s",
(pattern, limit, offset),
)
rows = [dict(r) for r in cur.fetchall()]
cur.execute("SELECT COUNT(*) FROM terraform_demo_table WHERE title ILIKE %s", (pattern,))
total = cur.fetchone()["count"]
return {"rows": rows, "count": len(rows), "total": total, "q": query, "limit": limit, "offset": offset}
finally:
conn.close()
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,36 +0,0 @@
# 2026-03-21 — pg-upsert: INSERT ... ON CONFLICT (title) DO UPDATE.
# Тестирует: идемпотентность вставки — один и тот же title можно вызывать 100 раз подряд.
# Требует уникального индекса на title — создаётся при первом вызове (CREATE UNIQUE INDEX IF NOT EXISTS).
import os, psycopg2
def upsert(event):
title = str(event.get("title", "upsert-default"))[:255]
payload = str(event.get("payload", ""))[:500]
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
try:
with conn.cursor() as cur:
# Создаём уникальный индекс если нет — для поддержки ON CONFLICT
cur.execute(
"CREATE UNIQUE INDEX IF NOT EXISTS terraform_demo_table_title_uniq "
"ON terraform_demo_table (title)"
)
cur.execute(
"INSERT INTO terraform_demo_table (title) VALUES (%s) "
"ON CONFLICT (title) DO UPDATE SET created_at = now() "
"RETURNING id, title, created_at::text, xmax",
(title,),
)
row = cur.fetchone()
was_insert = row[3] == 0 # xmax=0 означает INSERT, иначе UPDATE
conn.commit()
return {
"id": row[0], "title": row[1], "created_at": row[2],
"action": "inserted" if was_insert else "updated",
}
finally:
conn.close()
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,54 +0,0 @@
# 2026-03-21 — py-retry-writer: пишет N строк с retry при PG ошибке.
# Тестирует: устойчивость к transient PG errors (simulate_error=true), retry logic,
# корректный rollback при частичном сбое.
import os, time, psycopg2, random
_MAX_RETRIES = 3
def retry_write(event):
n = min(int(event.get("n", 5)), 100)
prefix = str(event.get("prefix", "retry"))[:40]
# simulate_error: с вероятностью 30% кидает OperationalError на 2-й попытке
simulate = str(event.get("simulate_error", "false")).lower() in ("true", "1")
attempt = 0
last_err = None
while attempt < _MAX_RETRIES:
attempt += 1
try:
conn = psycopg2.connect(
host=os.environ["PGHOST"], port=int(os.environ.get("PGPORT", 5432)),
dbname=os.environ["PGDATABASE"], user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"], sslmode=os.environ.get("PGSSLMODE", "require"),
)
inserted = []
try:
with conn.cursor() as cur:
for i in range(n):
# Симуляция: на первой попытке падаем с вероятностью 50%
if simulate and attempt == 1 and i == n // 2:
raise psycopg2.OperationalError("simulated transient error")
title = f"{prefix}-{int(time.time()*1000)}-{i}-a{attempt}"
cur.execute(
"INSERT INTO terraform_demo_table (title) VALUES (%s) RETURNING id",
(title,),
)
inserted.append(cur.fetchone()[0])
conn.commit()
return {
"ok": True, "inserted": len(inserted),
"attempts": attempt, "first_id": inserted[0] if inserted else None,
}
except Exception as e:
conn.rollback()
raise
finally:
conn.close()
except psycopg2.OperationalError as e:
last_err = str(e)
if attempt < _MAX_RETRIES:
time.sleep(0.3 * attempt) # exponential backoff
continue
return {"ok": False, "attempts": attempt, "last_error": last_err}
@@ -1 +0,0 @@
psycopg2-binary
@@ -1,3 +0,0 @@
# 2026-03-17 00:00
# requirements.txt — зависимости для функции запуска SQL.
psycopg2-binary==2.9.9
@@ -1,39 +0,0 @@
# 2026-03-17 00:00
# sql_runner.py — функция для выполнения SQL-операторов из входного события.
import os
import psycopg2
def run_sql(event):
# Выполняет список SQL-операторов в одной транзакции для атомарной инициализации схемы.
# Параметры подключения передаются раздельно, чтобы избежать ошибок парсинга DSN при спецсимволах.
pg_host = os.environ["PGHOST"]
pg_port = os.environ.get("PGPORT", "5432")
pg_database = os.environ["PGDATABASE"]
pg_user = os.environ["PGUSER"]
pg_password = os.environ["PGPASSWORD"]
pg_sslmode = os.environ.get("PGSSLMODE", "require")
statements = event.get("statements", [])
if not statements:
return {"error": "no statements provided"}
connection = psycopg2.connect(
host=pg_host,
port=pg_port,
dbname=pg_database,
user=pg_user,
password=pg_password,
sslmode=pg_sslmode,
)
try:
cursor = connection.cursor()
for statement in statements:
cursor.execute(statement)
connection.commit()
return {"ok": True, "executed": len(statements)}
except Exception as error:
connection.rollback()
return {"error": str(error)}
finally:
connection.close()
@@ -1,20 +0,0 @@
# 2026-03-19
# stress_bigloop.py — CPU-интенсивная функция: считает сумму квадратов N чисел.
# Проверяет поведение под нагрузкой (большая и средняя итерация).
import time
_VERSION = "v1"
def run(event):
n = int(event.get("n", 500_000))
start = time.monotonic()
total = sum(i * i for i in range(n))
elapsed = round(time.monotonic() - start, 4)
return {
"version": _VERSION,
"n": n,
"sum_of_squares": total,
"elapsed_sec": elapsed,
}
@@ -1,13 +0,0 @@
# 2026-03-19
# stress_divzero.py — намеренно делит на ноль (ZeroDivisionError).
# Проверяет: платформа перехватывает панику, возвращает HTTP 500, не роняет под.
_VERSION = "v1"
def run(event):
numerator = int(event.get("n", 42))
denominator = int(event.get("d", 0)) # по умолчанию 0 — намеренный краш
# ZeroDivisionError: проверяем что платформа обрабатывает исключения
result = numerator / denominator
return {"version": _VERSION, "result": result}
@@ -1,42 +0,0 @@
// 2026-03-19
// handler.go — быстрая Go функция: факториал + числа Фибоначчи.
// Проверяет Go runtime под лёгкой нагрузкой и корректность JSON-ответа.
// Entrypoint: handler.Handle
package handler
import "fmt"
func factorial(n int) uint64 {
if n <= 1 {
return 1
}
return uint64(n) * factorial(n-1)
}
func fib(n int) int {
if n <= 1 {
return n
}
a, b := 0, 1
for i := 2; i <= n; i++ {
a, b = b, a+b
}
return b
}
func Handle(event map[string]interface{}) interface{} {
n := 10
if v, ok := event["n"].(float64); ok {
n = int(v)
if n > 20 {
n = 20
}
}
return map[string]interface{}{
"runtime": "go1.23",
"version": "v1",
"n": n,
"factorial": fmt.Sprintf("%d", factorial(n)),
"fib": fib(n),
}
}
@@ -1,21 +0,0 @@
// 2026-03-19
// handler.go — намеренный nil pointer dereference в Go.
// Проверяет что Go runtime recover() перехватывает панику и платформа возвращает 500.
// Entrypoint: handler.Handle
package handler
func Handle(event map[string]interface{}) interface{} {
crash := true
if v, ok := event["crash"].(bool); ok {
crash = v
}
if crash {
var p *string
_ = *p // panic: намеренный nil pointer для stress-теста
}
return map[string]interface{}{
"runtime": "go1.23",
"version": "v1",
"crashed": false,
}
}
@@ -1,148 +0,0 @@
// 2026-03-19
// handler.go — Go стресс-тест PostgreSQL через pgxpool.
// Запускает N горутин (default 100), каждая в цикле duration_sec (default 600)
// долбит PG попеременно: INSERT / SELECT COUNT / SELECT MAX с случайными задержками.
// Цель: проверить Go runtime под конкурентной нагрузкой и устойчивость PG connection pool.
// Entrypoint: handler.Handle
package handler
import (
"context"
"fmt"
"math/rand"
"os"
"sync"
"sync/atomic"
"time"
"github.com/jackc/pgx/v5/pgxpool"
)
// pgDSN собирает DSN из env vars (PGHOST, PGPORT, PGDATABASE, PGUSER, PGPASSWORD, PGSSLMODE).
func pgDSN() string {
host := os.Getenv("PGHOST")
port := os.Getenv("PGPORT")
if port == "" {
port = "5432"
}
db := os.Getenv("PGDATABASE")
user := os.Getenv("PGUSER")
pass := os.Getenv("PGPASSWORD")
sslmode := os.Getenv("PGSSLMODE")
if sslmode == "" {
sslmode = "require"
}
return fmt.Sprintf("host=%s port=%s dbname=%s user=%s password=%s sslmode=%s",
host, port, db, user, pass, sslmode)
}
// worker — одна горутина: чередует INSERT/COUNT/MAX с случайной задержкой до maxDelayMs.
// При ошибке инкрементирует errOps и продолжает (не паникует).
func worker(ctx context.Context, pool *pgxpool.Pool, workerID int, maxDelayMs int, okOps, errOps *int64) {
rng := rand.New(rand.NewSource(time.Now().UnixNano() + int64(workerID)))
op := 0
for {
select {
case <-ctx.Done():
return
default:
}
// Случайная задержка перед следующей операцией: 0..maxDelayMs мс
delay := rng.Intn(maxDelayMs + 1)
time.Sleep(time.Duration(delay) * time.Millisecond)
var err error
switch op % 3 {
case 0: // INSERT
title := fmt.Sprintf("pgstorm-w%d-%d", workerID, time.Now().UnixNano())
_, err = pool.Exec(ctx,
"INSERT INTO terraform_demo_table (title) VALUES ($1)", title)
case 1: // SELECT COUNT
var count int64
err = pool.QueryRow(ctx,
"SELECT COUNT(*) FROM terraform_demo_table").Scan(&count)
case 2: // SELECT MAX id
var maxID *int64
err = pool.QueryRow(ctx,
"SELECT MAX(id) FROM terraform_demo_table").Scan(&maxID)
}
if err != nil && ctx.Err() == nil {
atomic.AddInt64(errOps, 1)
} else if err == nil {
atomic.AddInt64(okOps, 1)
}
op++
}
}
func Handle(event map[string]interface{}) interface{} {
// Параметры из event (все опциональны — разумные defaults)
workers := 100
if v, ok := event["workers"].(float64); ok && v > 0 && v <= 500 {
workers = int(v)
}
durationSec := 600
if v, ok := event["duration_sec"].(float64); ok && v > 0 && v <= 3600 {
durationSec = int(v)
}
maxDelayMs := 300
if v, ok := event["max_delay_ms"].(float64); ok && v >= 0 && v <= 5000 {
maxDelayMs = int(v)
}
// Инициализация pgxpool — единый pool на всю функцию, MaxConns ограничен
// чтобы не перегрузить managed PG при большом числе горутин.
poolCfg, err := pgxpool.ParseConfig(pgDSN())
if err != nil {
return map[string]interface{}{"error": fmt.Sprintf("parse dsn: %v", err)}
}
maxConns := 20
if workers < 20 {
maxConns = workers
}
poolCfg.MaxConns = int32(maxConns)
ctx, cancel := context.WithTimeout(context.Background(), time.Duration(durationSec)*time.Second)
defer cancel()
pool, err := pgxpool.NewWithConfig(ctx, poolCfg)
if err != nil {
return map[string]interface{}{"error": fmt.Sprintf("connect pool: %v", err)}
}
defer pool.Close()
var okOps, errOps int64
startTime := time.Now()
var wg sync.WaitGroup
for i := 0; i < workers; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
worker(ctx, pool, id, maxDelayMs, &okOps, &errOps)
}(i)
}
wg.Wait()
elapsed := time.Since(startTime).Seconds()
total := okOps + errOps
opsPerSec := 0.0
if elapsed > 0 {
opsPerSec = float64(total) / elapsed
}
return map[string]interface{}{
"runtime": "go1.23",
"version": "v1",
"workers": workers,
"duration_sec": durationSec,
"max_delay_ms": maxDelayMs,
"elapsed_sec": fmt.Sprintf("%.1f", elapsed),
"total_ops": total,
"ok_ops": okOps,
"err_ops": errOps,
"ops_per_sec": fmt.Sprintf("%.1f", opsPerSec),
}
}
@@ -1,7 +0,0 @@
{
"name": "stress-js-async",
"version": "1.0.0",
"dependencies": {
"pg": "^8.11.0"
}
}
@@ -1,37 +0,0 @@
// 2026-03-19
// stress_js_async.js — делает 3 параллельных запроса к PG через Promise.all.
// Проверяет nodejs20 runtime под умеренной нагрузкой и async/await.
//
// Entrypoint: stress_js_async.run
'use strict';
const { Client } = require('pg');
exports.run = async (event) => {
const client = new Client({
host: process.env.PGHOST,
port: parseInt(process.env.PGPORT || '5432'),
database: process.env.PGDATABASE,
user: process.env.PGUSER,
password: process.env.PGPASSWORD,
ssl: process.env.PGSSLMODE === 'require' ? { rejectUnauthorized: false } : false,
});
await client.connect();
try {
const [ver, cnt, max] = await Promise.all([
client.query('SELECT version() AS v'),
client.query('SELECT COUNT(*) AS cnt FROM terraform_demo_table'),
client.query('SELECT MAX(id) AS max_id FROM terraform_demo_table'),
]);
return {
runtime: 'nodejs20',
version: 'v1',
pg_version: ver.rows[0].v.split(' ').slice(0, 2).join(' '),
total_rows: parseInt(cnt.rows[0].cnt, 10),
max_id: max.rows[0].max_id,
};
} finally {
await client.end();
}
};
@@ -1,5 +0,0 @@
{
"name": "stress-js-badenv",
"version": "1.0.0",
"dependencies": {}
}
@@ -1,17 +0,0 @@
// 2026-03-19
// stress_js_badenv.js — читает несуществующую переменную env и падает.
// Проверяет: платформа перехватывает TypeError/undefined, возвращает 500.
//
// Entrypoint: stress_js_badenv.run
'use strict';
exports.run = async (event) => {
const crash = event.crash !== false; // по умолчанию crash=true
if (crash) {
// Читаем несуществующий env, пытаемся вызвать .toUpperCase() на undefined
const val = process.env.THIS_VAR_DOES_NOT_EXIST_AT_ALL;
return { shout: val.toUpperCase() }; // TypeError: Cannot read properties of undefined
}
return { runtime: 'nodejs20', version: 'v1', crashed: false };
};
@@ -1,18 +0,0 @@
# 2026-03-19
# stress_slow.py — долгая функция: спит N секунд (по умолчанию 8).
# Проверяет что timeout-механизм и параллельные запросы не блокируют друг друга.
import time
import os
_VERSION = "v1"
def run(event):
secs = int(event.get("sleep", 8))
time.sleep(secs)
return {
"version": _VERSION,
"slept_sec": secs,
"pid": os.getpid(),
}
@@ -1 +0,0 @@
psycopg2-binary==2.9.9
@@ -1,39 +0,0 @@
# 2026-03-19
# stress_writer.py — пишет N строк в terraform_demo_table (по умолчанию 5).
# Проверяет параллельные INSERT'ы и устойчивость соединения с PG при нагрузке.
import os
import psycopg2
import time
_VERSION = "v1"
def run(event):
n = int(event.get("rows", 5))
prefix = event.get("prefix", "stress")
conn = psycopg2.connect(
host=os.environ["PGHOST"],
port=int(os.environ.get("PGPORT", "5432")),
dbname=os.environ["PGDATABASE"],
user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"],
sslmode=os.environ.get("PGSSLMODE", "require"),
)
inserted = []
try:
with conn.cursor() as cur:
for i in range(n):
title = f"{prefix}-{int(time.time()*1000)}-{i}"
cur.execute(
"INSERT INTO terraform_demo_table (title) VALUES (%s) RETURNING id",
(title,),
)
row = cur.fetchone()
inserted.append({"id": row[0], "title": title})
conn.commit()
finally:
conn.close()
return {"version": _VERSION, "inserted": inserted, "count": len(inserted)}
@@ -1 +0,0 @@
psycopg2-binary==2.9.9
-133
View File
@@ -1,133 +0,0 @@
# 2026-03-19 — добавлен version и hostname в ответ list_rows для тестирования обновления кода
# table_rw.py — чтение и запись строк в terraform_demo_table.
# Два entrypoint в одном файле: list_rows (JSON API) и add_row (HTML-страница + POST-обработчик).
# ENV: PGHOST, PGPORT, PGDATABASE, PGUSER, PGPASSWORD, PGSSLMODE
import os
import json
import socket
import psycopg2
import psycopg2.extras
_CODE_VERSION = "v2-with-hostname"
def _connect():
return psycopg2.connect(
host=os.environ["PGHOST"],
port=os.environ.get("PGPORT", "5432"),
dbname=os.environ["PGDATABASE"],
user=os.environ["PGUSER"],
password=os.environ["PGPASSWORD"],
sslmode=os.environ.get("PGSSLMODE", "require"),
)
def list_rows(event):
# Возвращает все строки terraform_demo_table, отсортированные по убыванию created_at.
conn = _connect()
try:
cur = conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor)
cur.execute(
"SELECT id, title, created_at::text FROM terraform_demo_table ORDER BY created_at DESC"
)
rows = [dict(r) for r in cur.fetchall()]
return {"rows": rows, "count": len(rows), "version": _CODE_VERSION, "host": socket.gethostname()}
finally:
conn.close()
def _render_page(rows, message=""):
# HTML-страница с формой ввода и таблицей строк.
# message — статус последней операции (успех / ошибка).
rows_html = "".join(
f"<tr><td>{r['id']}</td><td>{r['title']}</td><td>{r['created_at']}</td></tr>"
for r in rows
)
msg_html = f'<p class="msg">{message}</p>' if message else ""
return f"""<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="utf-8">
<title>pg-table-writer</title>
<style>
body {{ font-family: sans-serif; max-width: 700px; margin: 40px auto; background: #111; color: #eee; }}
h1 {{ color: #7dd3fc; }}
form {{ display: flex; gap: 8px; margin-bottom: 24px; }}
input[type=text] {{ flex: 1; padding: 8px 12px; border-radius: 6px; border: 1px solid #444; background: #1e1e1e; color: #eee; font-size: 15px; }}
button {{ padding: 8px 18px; background: #2563eb; color: #fff; border: none; border-radius: 6px; cursor: pointer; font-size: 15px; }}
button:hover {{ background: #1d4ed8; }}
table {{ width: 100%; border-collapse: collapse; }}
th, td {{ padding: 8px 10px; border-bottom: 1px solid #333; text-align: left; }}
th {{ color: #7dd3fc; }}
.msg {{ color: #4ade80; margin-bottom: 12px; }}
</style>
</head>
<body>
<h1>pg-table-writer</h1>
<form method="POST">
<input type="text" name="title" placeholder="Введите строку..." autofocus required>
<button type="submit">Добавить</button>
</form>
{msg_html}
<table>
<thead><tr><th>#</th><th>title</th><th>created_at</th></tr></thead>
<tbody>{rows_html}</tbody>
</table>
</body>
</html>"""
def add_row(event):
# GET → HTML-страница с формой и списком строк.
# POST → вставляет строку из form-поля title или JSON-поля title,
# затем возвращает обновлённую HTML-страницу.
# POST с Content-Type: application/json (curl/API) → возвращает JSON.
method = event.get("_method", "GET")
if method == "GET":
conn = _connect()
try:
cur = conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor)
cur.execute("SELECT id, title, created_at::text FROM terraform_demo_table ORDER BY created_at DESC")
rows = [dict(r) for r in cur.fetchall()]
finally:
conn.close()
return _render_page(rows)
# POST — вставка строки
# Поле title приходит либо из JSON-тела, либо из application/x-www-form-urlencoded.
# Сервер уже распарсил JSON в event; form-данные приходят как event["body"] = "title=...".
title = event.get("title", "").strip()
if not title:
# Попытка распарсить form-encoded body (браузерная форма)
body = event.get("body", "")
if body.startswith("title="):
from urllib.parse import unquote_plus
title = unquote_plus(body[len("title="):].split("&")[0]).strip()
if not title:
return {"ok": False, "error": "title is required"}
conn = _connect()
try:
cur = conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor)
cur.execute(
"INSERT INTO terraform_demo_table (title) VALUES (%s) RETURNING id, title, created_at::text",
(title,),
)
row = dict(cur.fetchone())
conn.commit()
# Если запрос из браузера (form POST) — возвращаем обновлённую страницу.
# Если из curl/API — возвращаем JSON.
accept = event.get("_accept", "")
if "application/json" in accept:
return {"ok": True, "row": row}
# Перечитываем все строки для обновлённой страницы
cur.execute("SELECT id, title, created_at::text FROM terraform_demo_table ORDER BY created_at DESC")
rows = [dict(r) for r in cur.fetchall()]
return _render_page(rows, message=f"Добавлено: «{row['title']}»")
finally:
conn.close()
+24 -93
View File
@@ -1,105 +1,36 @@
// 2026-03-20 (merge: sless_function + старый sless_job объединены в один self-contained sless_job)
// Теперь sless_job несёт в себе runtime/entrypoint/source_dir — не нужен отдельный sless_function.
// WaitJobDone таймаут 900s покрывает kaniko сборку (~5 мин) + выполнение SQL (~несколько сек).
# Создано: 2026-04-10
# functions.tf — sless_service ресурсы для примера POSTGRES.
# Здесь: два калькуляторa — Python и Node.js.
# sless_service = long-running Deployment + постоянный URL (в отличие от sless_function).
# Одноразовый запуск: собирает образ через kaniko, выполняет SQL, завершается.
# Заменяет sless_function.postgres_sql_runner_create_table + sless_job.postgres_table_init_job.
resource "sless_job" "postgres_table_init_job" {
name = "pg-create-table-job-main-v13"
runtime = "python3.11"
entrypoint = "sql_runner.run_sql"
memory_mb = 128
timeout_sec = 30
source_dir = "${path.module}/code/sql-runner"
wait_timeout_sec = 900
run_id = 13
# ─── Python-калькулятор ──────────────────────────────────────────────────────
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
event_json = jsonencode({
statements = [
"CREATE TABLE IF NOT EXISTS terraform_demo_table (id serial PRIMARY KEY, title text NOT NULL, created_at timestamp DEFAULT now())"
]
})
depends_on = [nubes_postgres_database.db]
}
# Long-running сервис на NodeJS: возвращает версию PG-сервера и счётчик строк в таблице.
resource "sless_service" "pg_info" {
name = "pg-info"
runtime = "nodejs20"
entrypoint = "pg_info.info"
memory_mb = 128
timeout_sec = 15
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/pg-info"
depends_on = [sless_job.postgres_table_init_job]
}
resource "sless_service" "postgres_table_reader" {
name = "pg-table-reader"
runtime = "python3.11"
entrypoint = "table_rw.list_rows"
resource "sless_service" "calc_python" {
name = "calc-python"
runtime = "python3.11"
entrypoint = "handler.handler"
memory_mb = 128
timeout_sec = 30
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/table-rw"
depends_on = [sless_job.postgres_table_init_job]
source_dir = "${path.module}/code/calc-python"
}
output "table_reader_url" {
value = sless_service.postgres_table_reader.url
output "calc_python_url" {
description = "URL Python-калькулятора"
value = sless_service.calc_python.url
}
resource "sless_service" "postgres_table_writer" {
name = "pg-table-writer"
runtime = "python3.11"
entrypoint = "table_rw.add_row"
memory_mb = 256
timeout_sec = 45
# ─── Node.js-калькулятор ─────────────────────────────────────────────────────
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
source_dir = "${path.module}/code/table-rw"
depends_on = [sless_job.postgres_table_init_job]
resource "sless_service" "calc_node" {
name = "calc-node"
runtime = "nodejs20"
entrypoint = "handler.handler"
memory_mb = 128
timeout_sec = 30
source_dir = "${path.module}/code/calc-node"
}
output "table_writer_url" {
value = sless_service.postgres_table_writer.url
output "calc_node_url" {
description = "URL Node.js-калькулятора"
value = sless_service.calc_node.url
}
+2 -1
View File
@@ -4,7 +4,7 @@ terraform {
required_providers {
nubes = {
source = "terra.k8c.ru/nubes/nubes"
version = "5.0.19"
version = "5.0.51"
}
sless = {
source = "terra.k8c.ru/naeel/sless"
@@ -52,6 +52,7 @@ variable "pg_password" {
provider "nubes" {
api_token = var.api_token
log_level = "debug" # none | info | debug, default = "none"
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
}
-167
View File
@@ -1,167 +0,0 @@
// 2026-03-21 — stress.tf: все стресс-сервисы для комплексного тестирования.
// Три рантайма: go1.23 (3), nodejs20 (2), python3.11 (5).
// Все depends_on = [sless_job.postgres_table_init_job] — таблица должна существовать.
# ── Go 1.23 ─────────────────────────────────────────────────────────────────
# Быстрая математика: факториал + числа Фибоначчи. Без PG. Проверяет Go runtime.
resource "sless_service" "stress_go_fast" {
name = "stress-go-fast"
runtime = "go1.23"
entrypoint = "handler.Handle"
memory_mb = 128
timeout_sec = 15
source_dir = "${path.module}/code/stress-go-fast"
depends_on = [sless_job.postgres_table_init_job]
}
# Намеренный nil pointer dereference. Без PG. Проверяет recover() в Go runtime.
resource "sless_service" "stress_go_nil" {
name = "stress-go-nil"
runtime = "go1.23"
entrypoint = "handler.Handle"
memory_mb = 128
timeout_sec = 10
source_dir = "${path.module}/code/stress-go-nil"
depends_on = [sless_job.postgres_table_init_job]
}
# Конкурентный PG-шторм через pgxpool: N горутин INSERT/COUNT/MAX.
# timeout_sec=660 — покрывает max duration_sec=600 с запасом.
# pgx/v5 уже в базовом образе go1.23: user go.mod не нужен.
resource "sless_service" "stress_go_pgstorm" {
name = "stress-go-pgstorm"
runtime = "go1.23"
entrypoint = "handler.Handle"
memory_mb = 256
timeout_sec = 660
source_dir = "${path.module}/code/stress-go-pgstorm"
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
depends_on = [sless_job.postgres_table_init_job]
}
# ── Node.js 20 ────────────────────────────────────────────────────────────────
# 3 параллельных PG-запроса через Promise.all. Проверяет async/await + nodejs20.
resource "sless_service" "stress_js_async" {
name = "stress-js-async"
runtime = "nodejs20"
entrypoint = "stress_js_async.run"
memory_mb = 128
timeout_sec = 20
source_dir = "${path.module}/code/stress-js-async"
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
depends_on = [sless_job.postgres_table_init_job]
}
# TypeError через undefined.toUpperCase(). Без PG. Проверяет перехват JS-ошибок.
resource "sless_service" "stress_js_badenv" {
name = "stress-js-badenv"
runtime = "nodejs20"
entrypoint = "stress_js_badenv.run"
memory_mb = 128
timeout_sec = 10
source_dir = "${path.module}/code/stress-js-badenv"
depends_on = [sless_job.postgres_table_init_job]
}
# ── Python 3.11 ───────────────────────────────────────────────────────────────
# Спит N секунд. Без PG. Проверяет timeout и сосуществование долгих запросов.
resource "sless_service" "stress_slow" {
name = "stress-slow"
runtime = "python3.11"
entrypoint = "stress_slow.run"
memory_mb = 128
timeout_sec = 35
source_dir = "${path.module}/code/stress-slow"
depends_on = [sless_job.postgres_table_init_job]
}
# CPU-нагрузка: сумма квадратов N чисел. Без PG. Проверяет compute-bound задачи.
resource "sless_service" "stress_bigloop" {
name = "stress-bigloop"
runtime = "python3.11"
entrypoint = "stress_bigloop.run"
memory_mb = 256
timeout_sec = 60
source_dir = "${path.module}/code/stress-bigloop"
depends_on = [sless_job.postgres_table_init_job]
}
# ZeroDivisionError. Без PG. Проверяет перехват Python-исключений → HTTP 500.
resource "sless_service" "stress_divzero" {
name = "stress-divzero"
runtime = "python3.11"
entrypoint = "stress_divzero.run"
memory_mb = 128
timeout_sec = 10
source_dir = "${path.module}/code/stress-divzero"
depends_on = [sless_job.postgres_table_init_job]
}
# Параллельный INSERT в terraform_demo_table через psycopg2. Проверяет PG-write.
resource "sless_service" "stress_writer" {
name = "stress-writer"
runtime = "python3.11"
entrypoint = "stress_writer.run"
memory_mb = 128
timeout_sec = 60
source_dir = "${path.module}/code/stress-writer"
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
depends_on = [sless_job.postgres_table_init_job]
}
# Агрегированная статистика terraform_demo_table (COUNT/MIN/MAX). Для мониторинга.
resource "sless_service" "pg_stats" {
name = "pg-stats"
runtime = "python3.11"
entrypoint = "pg_stats.get_stats"
memory_mb = 128
timeout_sec = 15
source_dir = "${path.module}/code/pg-stats"
env_vars = {
PGHOST = local.pg_host
PGPORT = "5432"
PGDATABASE = local.pg_database
PGUSER = local.pg_username
PGPASSWORD = local.pg_password
PGSSLMODE = "require"
}
depends_on = [sless_job.postgres_table_init_job]
}
+176
View File
@@ -0,0 +1,176 @@
#!/bin/bash
# test_cache_matrix.sh — 2026-03-23 (v4)
# Комплексный тест кэша registry:
# Phase 1 — полный деплой всех 24 ресурсов (kaniko builds, т.к. нет образов)
# Phase 2 — destroy sless_* + re-apply (все образы из кэша)
# Phase 3 — одновременно: удаление 2, смена кода 2, смена параметров 2
# ВАЖНО: postgres.tf НЕ переименовывается и НЕ трогается никогда.
# Destroy sless-ресурсов делается путём переименования tf-файлов в .tf.bak,
# затем terraform apply (видит что ресурсов нет → удаляет их из state+кластера),
# затем файлы возвращаются обратно. Никаких -target.
set -euo pipefail
DIR="$(cd "$(dirname "$0")" && pwd)"
LOG="$DIR/test_cache_matrix_$(date +%Y%m%d_%H%M%S).log"
TIMINGS="$LOG.timings"
PASS=0
FAIL=0
log() { echo "[$(date +%H:%M:%S)] $*" | tee -a "$LOG"; }
sep() { log "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"; }
timed_op() {
local label="$1"; shift
log "▶ START: $label"
local t0; t0=$(date +%s%3N)
"$@" 2>&1 | tee -a "$LOG"
local rc=${PIPESTATUS[0]}
local t1; t1=$(date +%s%3N)
local elapsed=$(( (t1 - t0) / 1000 ))
if [[ $rc -eq 0 ]]; then
log "✓ DONE: $label${elapsed}s"
PASS=$((PASS+1))
else
log "✗ FAIL: $label${elapsed}s (exit $rc)"
FAIL=$((FAIL+1))
fi
echo "$label: ${elapsed}s" >> "$TIMINGS"
return $rc
}
destroy_sless_only() {
# Переименовываем tf-файлы с sless-ресурсами в .tf.bak → terraform apply их удалит.
# Никаких -target — чтобы не затрагивать postgres и не получать state drift.
local label="$1"
local SLESS_FILES=("chaos_marathon.tf" "functions.tf" "stress.tf")
local has_state
has_state=$(terraform state list 2>/dev/null | grep -cE '^(sless_service|sless_job)' || true)
if [[ "$has_state" -eq 0 ]]; then
log " (nothing to destroy for $label — state empty)"
return 0
fi
log " Hiding sless tf-files → apply will destroy $has_state resources"
for f in "${SLESS_FILES[@]}"; do
[[ -f "$DIR/$f" ]] && mv "$DIR/$f" "$DIR/$f.bak"
done
timed_op "$label" terraform apply -auto-approve
for f in "${SLESS_FILES[@]}"; do
[[ -f "$DIR/$f.bak" ]] && mv "$DIR/$f.bak" "$DIR/$f"
done
log " sless tf-files restored"
}
cd "$DIR"
sep
log "PHASE 1: Полный начальный деплой"
sep
destroy_sless_only "phase1-pre-clean"
timed_op "phase1-apply-all" terraform apply -auto-approve
log "--- Образы в registry после Phase 1 ---"
kubectl exec -n sless deployment/sless-registry -- sh -c 'find /var/lib/registry -name "*.json" -path "*/tags/*" 2>/dev/null | sed "s|.*repository/||;s|/_manifests.*||" | sort | uniq -c | sort -rn' 2>/dev/null | head -30 | tee -a "$LOG" || log "(registry inspect failed)"
sep
log "PHASE 2: Destroy sless_* → Re-apply (ожидаем cache hits)"
sep
destroy_sless_only "phase2-destroy"
timed_op "phase2-apply-cached" terraform apply -auto-approve
sep
log "PHASE 3: Mixed ops (delete+code+params)"
sep
log "--- 3a: destroy stress_divzero, chaos_echo (comment out → apply → restore) ---"
python3 - <<'PYEOF'
import re, pathlib
def comment_out_resource(path, resource_type, resource_name):
text = pathlib.Path(path).read_text()
# Находим блок resource "type" "name" { ... } и оборачиваем в /* */
pattern = rf'(resource\s+"{re.escape(resource_type)}"\s+"{re.escape(resource_name)}"\s*\{{)'
match = re.search(pattern, text)
if not match:
print(f" WARNING: {resource_type}.{resource_name} not found in {path}")
return
# Найти закрывающую скобку блока
start = match.start()
depth = 0
i = match.start()
while i < len(text):
if text[i] == '{': depth += 1
elif text[i] == '}':
depth -= 1
if depth == 0:
end = i + 1
break
i += 1
block = text[start:end]
commented = "/* COMMENTED_OUT_FOR_TEST\n" + block + "\nCOMMENTED_OUT_FOR_TEST */"
pathlib.Path(path).write_text(text[:start] + commented + text[end:])
print(f" commented out: {resource_type}.{resource_name} in {path}")
comment_out_resource("stress.tf", "sless_service", "stress_divzero")
comment_out_resource("chaos_marathon.tf", "sless_service", "chaos_echo")
PYEOF
timed_op "phase3a-destroy-2" terraform apply -auto-approve
# Восстанавливаем закомментированные блоки
python3 - <<'PYEOF'
import pathlib, re
for fname in ("stress.tf", "chaos_marathon.tf"):
p = pathlib.Path(fname)
text = p.read_text()
text = re.sub(r'/\* COMMENTED_OUT_FOR_TEST\n', '', text)
text = re.sub(r'\nCOMMENTED_OUT_FOR_TEST \*/', '', text)
p.write_text(text)
print(f" restored: {fname}")
PYEOF
log " stress_divzero, chaos_echo removed from state and k8s"
log "--- 3b: code changes (new sha256 → kaniko) ---"
echo "" >> "$DIR/code/pg-counter/pg_counter.py"
echo "# cache-test-$(date +%s)" >> "$DIR/code/pg-counter/pg_counter.py"
echo "" >> "$DIR/code/stress-js-async/stress_js_async.js"
echo "// cache-test-$(date +%s)" >> "$DIR/code/stress-js-async/stress_js_async.js"
log " changed: pg_counter.py, stress_js_async.js"
log "--- 3c: param changes (same sha256 → no kaniko) ---"
python3 - <<'PYEOF'
import re, sys
with open("stress.tf") as f:
content = f.read()
orig = content
content = re.sub(
r'(resource "sless_service" "stress_slow" \{[^}]*?)memory_mb\s*=\s*\d+',
lambda m: m.group(1) + 'memory_mb = 192',
content, flags=re.DOTALL
)
content = re.sub(
r'(resource "sless_service" "pg_stats" \{[^}]*?)timeout_sec\s*=\s*\d+',
lambda m: m.group(1) + 'timeout_sec = 20',
content, flags=re.DOTALL
)
if content == orig:
print(" stress.tf: no changes (already patched?)", file=sys.stderr)
else:
with open("stress.tf", "w") as f:
f.write(content)
print(" stress.tf: stress_slow→memory_mb=192, pg_stats→timeout_sec=20")
PYEOF
log "--- 3d: apply всех mixed изменений ---"
log " Expected: stress_divzero+chaos_echo=cache_hit, pg_counter+stress_js_async=kaniko, stress_slow+pg_stats=k8s_only"
timed_op "phase3d-mixed-apply" terraform apply -auto-approve
sep
log "ИТОГ"
sep
log "Timings:"
cat "$TIMINGS" 2>/dev/null | tee -a "$LOG"
log "Pass: $PASS | Fail: $FAIL"
log "Лог: $LOG"
+21 -40
View File
@@ -1,75 +1,56 @@
# Примеры использования sless
# sless — примеры
## Обзор платформы
> ⚠️ **Тестовое окружение.** Все примеры работают с тестовым API Nubes и тестовым кластером sless. Не используйте в продакшне без предварительного согласования.
**sless**система управления serverless-функциями на базе Kubernetes. Разработчик загружает код функции, платформа собирает из него Docker-образ, разворачивает его в кластере и предоставляет HTTP-эндпоинт для вызова. Всё описывается декларативно через Terraform.
### Основные ресурсы провайдера
| Ресурс | Назначение |
|---|---|
| `sless_service` | Long-running HTTP-сервис: всегда активен, отвечает на запросы. Имеет свой URL после деплоя. |
| `sless_job` | Одноразовый запуск функции: собирает образ, выполняет код, завершается. Используется для миграций БД, batch-обработки и т.д. |
Namespace функций вычисляется автоматически из JWT-токена: `sless-{sha256[:8]}`.
**sless**платформа для запуска serverless-функций на базе Kubernetes.
Разработчик загружает код, платформа собирает Docker-образ и разворачивает его в кластере.
Всё описывается декларативно через Terraform.
---
## Требования
## Ресурсы Terraform-провайдера
- Terraform >= 1.3
- JWT-токен для аутентификации в sless API
- JWT-токен для Nubes Cloud API (если используются managed-ресурсы: PostgreSQL и т.д.)
- Доступ к `https://sless.kube5s.ru`
| Ресурс | Что делает |
|---|---|
| `sless_job` | Разовый запуск: выполняет код один раз и завершается (установка ПО, миграции и т.д.) |
| `sless_service` | HTTP-сервис: всегда запущен, отвечает на запросы, имеет постоянный URL — _примеры появятся позднее_ |
---
## Конфигурация провайдера
```hcl
provider "sless" {
endpoint = "https://sless.kube5s.ru"
token = var.sless_token
}
provider "nubes_cloud" {
base_url = "https://deck-api-test.ngcloud.ru/api/v1"
token = var.nubes_token
token = var.api_token
}
```
> Токены задаются в `terraform.tfvars` — этот файл добавлен в `.gitignore`.
Токен задаётся в `terraform.tfvars` (файл в `.gitignore`, не попадает в git).
---
## Примеры
### `POSTGRES` — Serverless-функции с Managed PostgreSQL
### [`VM/`](VM/) — Виртуальная машина в Nubes vDC
Полный пример: managed PostgreSQL + одноразовый init-job + 3 HTTP-сервиса (чтение/запись данных и информация о PG).
Создаёт vApp + Ubuntu 22.04 VM в облаке Nubes. После создания — автоматически устанавливает ПО (nginx, Docker, пакеты) через serverless-джобы (`sless_job`) по SSH.
Языки: Python 3.11, Node.js 20.
> В этом примере используются только **разовые джобы** (`sless_job`). Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
```bash
cd POSTGRES
terraform init
terraform apply
```
Подробности: [POSTGRES/README.md](POSTGRES/README.md)
**→ [Начать здесь](VM/README.md)**
---
## Полезные команды
```bash
# Посмотреть состояние задеплоенных ресурсов:
# Посмотреть состояние ресурсов:
terraform show
# Принудительно пересобрать сервис (после изменения кода):
terraform apply -replace=sless_service.<имя>
# Повторно запустить job: увеличить run_id в .tf-файле, затем:
# Повторно запустить установку ПО: увеличить install_run_id в terraform.tfvars, затем:
terraform apply
# Удалить все ресурсы примера:
# Удалить все ресурсы:
terraform destroy
```
+208
View File
@@ -0,0 +1,208 @@
# Пример: Виртуальная машина (vApp + VM) в Nubes vDC
> ⚠️ **Тестовое окружение.** Пример работает с тестовым API Nubes и тестовым кластером sless. Не использовать в продакшне без предварительного согласования.
> В этом примере используются только **разовые джобы** (`sless_job`) — для установки ПО на ВМ. Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
Создаёт:
- **vApp** — виртуальный каталог (контейнер для ВМ в VMware vDC)
- **ВМ** — Ubuntu 22.04, 2 CPU / 2 GB RAM / 20 GB disk
- **Serverless-джобы** — устанавливают ПО на ВМ по SSH после создания
---
## Быстрый старт
```bash
cp terraform.tfvars.template terraform.tfvars
# Заполни terraform.tfvars (инструкция ниже)
terraform init
terraform apply
```
---
## Шаг 1 — Получить данные из Личного Кабинета
### API-токен
> Личный Кабинет → правый верхний угол → **«Профиль»** → **«API-токены»** → **«Создать токен»**
Скопируйте JWT-строку целиком (`eyJhbGciOiJS...`).
Один токен работает для обоих провайдеров — nubes (облако) и sless (serverless).
### UUID сервисов (vdc_uid и nsxt_uid)
> Личный Кабинет → **«Мои сервисы»** → нужный сервис → **«Параметры инстанса»** → поле UUID
| Параметр | Что искать в ЛК |
|---|---|
| `vdc_uid` | Сервис **«Виртуальный датацентр (vDC)»** → UUID |
| `nsxt_uid` | Сервис **«Сетевой шлюз периметра (Edge)»** → UUID |
UUID выглядит так: `e3c9e4f1-24da-4992-a003-f8a2a803a5f0`
> **Важно:** `vdc_uid` и `nsxt_uid` **не изменяются после первого `terraform apply`**.
> Менять их нельзя — сломается terraform state.
---
## Шаг 2 — Сгенерировать SSH-ключ для ВМ
Публичный ключ прописывается в ВМ при создании — это **единственный** способ зайти по SSH.
```bash
# Выполнить в папке examples/VM/
ssh-keygen -t ed25519 -f ./vm_key -N "" -C "sless-demo-vm"
```
Создаст два файла: `vm_key` (приватный) и `vm_key.pub` (публичный).
---
## Шаг 3 — Заполнить terraform.tfvars
```bash
cp terraform.tfvars.template terraform.tfvars
```
Открыть `terraform.tfvars` и заполнить:
```hcl
api_token = "eyJhbGciOiJS..." # из ЛК (шаг 1)
vm_public_key = "ssh-ed25519 AAAA..." # содержимое vm_key.pub (шаг 2)
vdc_uid = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # из ЛК (шаг 1)
nsxt_uid = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # из ЛК (шаг 1)
```
Остальные параметры (`install_packages`, `base_packages` и т.д.) можно менять в любое время.
---
## Запуск
```bash
terraform init
terraform apply
```
После успешного `apply` Terraform выведет:
```
Outputs:
vm_id = "..."
vm_state = {
"externalIp" = "1.2.3.4"
...
}
vapp_id = "..."
```
---
## Подключение по SSH
```bash
ssh -i ./vm_key ubuntu@<externalIp из vm_state>
```
Логин всегда `ubuntu`.
---
## Управление установкой ПО
Установка выполняется через serverless-джобы — Terraform запускает k8s Job, который подключается к ВМ по SSH и устанавливает пакеты.
### Флаги установки (в terraform.tfvars)
| Переменная | Что делает | По умолчанию |
|---|---|---|
| `install_packages` | Устанавливает пакеты из `base_packages` | `true` |
| `install_nginx` | Устанавливает nginx | `true` |
| `install_docker` | Устанавливает Docker CE + docker-compose-plugin | `true` |
### Как изменить список пакетов
В `terraform.tfvars`:
```hcl
base_packages = ["jq", "htop", "curl", "git", "python3-pip"]
```
Любые стандартные apt-пакеты Ubuntu 22.04.
После изменения — увеличьте `install_run_id` и выполните `terraform apply`.
### Как перезапустить установку
sless_job — разовый джоб. При повторном `apply` Terraform не перезапускает его если ничего не изменилось.
Чтобы запустить все install-джобы заново — увеличьте `install_run_id` на 1:
```hcl
# было:
install_run_id = 3
# стало:
install_run_id = 4
```
Затем `terraform apply`. Установка идемпотентна — повторное выполнение не ломает систему.
### Как отключить отдельный компонент
```hcl
install_docker = false # не устанавливать Docker
```
После `apply` ресурс `sless_job.install_docker` будет удалён из state.
Docker на уже созданной ВМ останется — Terraform не удаляет пакеты.
---
## Удаление
```bash
terraform destroy
```
Порядок автоматический: сначала suspend → потом delete.
Параметр `suspend_on_destroy = true` решает это — без него удаление упадёт с ошибкой Nubes _«Услуга не остановлена»_.
---
## Справочник параметров
### Можно менять в любое время
| Параметр | Файл | Эффект |
|---|---|---|
| `vm_cpu`, `vm_ram`, `vm_disk` | `vm.tf` | ВМ будет изменена |
| `install_packages/nginx/docker` | `terraform.tfvars` | Джоб добавится или удалится |
| `base_packages` | `terraform.tfvars` | Пакеты изменятся — увеличить `install_run_id` + apply |
| `install_run_id` | `terraform.tfvars` | Перезапускает все install-джобы |
### Нельзя менять после первого apply
| Параметр | Файл | Причина |
|---|---|---|
| `vdc_uid`, `nsxt_uid` | `terraform.tfvars` | Идентифицируют сервисы в terraform state |
| `resource_name`, `vapp_name` | `vapp.tf` | Уникальные имена ресурсов в Nubes |
| `image_vm`, `user_login` | `vm.tf` | Неизменяемые параметры ВМ |
| `vm_public_key` | `terraform.tfvars` | Прописывается в ВМ один раз при создании |
---
## Файлы проекта
| Файл | Назначение |
|---|---|
| `terraform.tfvars.template` | **Шаблон** — скопировать в `terraform.tfvars` и заполнить |
| `terraform.tfvars` | Ваши значения (не в git — содержит секреты) |
| `main.tf` | Провайдеры + переменные `api_token` и `vm_public_key` |
| `variables.tf` | Все остальные переменные с описаниями |
| `vapp.tf` | Ресурс vApp (контейнер ВМ) |
| `vm.tf` | Ресурс ВМ (Ubuntu 22.04) |
| `sless.tf` | Serverless-джобы для установки ПО |
| `outputs.tf` | Вывод IP-адреса и ID ресурсов |
| `vm_key` / `vm_key.pub` | SSH-ключ — **создаётся вами на Шаге 2**, в git не хранится |
| `functions/` | Код Python-функций для install-джобов |
+106
View File
@@ -0,0 +1,106 @@
# VM Stress Test — Инструкция по запуску
# 2026-03-30
## ⛔⛔⛔ КРИТИЧЕСКИЕ ПРАВИЛА ⛔⛔⛔
### ЗАПРЕЩЕНО (без исключений):
- **НЕ РЕДАКТИРОВАТЬ** `terraform.tfvars` — там JWT-токен, потеря = катастрофа
- **НЕ РЕДАКТИРОВАТЬ** `*.tf` файлы
- **НЕ РЕДАКТИРОВАТЬ** `vm_stress_test.sh`
- **НЕ ЗАПУСКАТЬ** `terraform` напрямую — только через скрипт
- **НЕ СОЗДАВАТЬ** новые файлы в этой директории
- **НЕ ДЕЛАТЬ** `sed`, `awk`, `cat >`, `tee` в terraform.tfvars
### ПОЧЕМУ:
Предыдущая версия скрипта содержала функцию `write_tfvars()` которая
перезаписывала `terraform.tfvars`. В процессе перезаписи был потерян
JWT-токен `api_token` (1200+ символов). Это привело к полному отказу
terraform и потере рабочего состояния. Восстановление заняло час.
### КАК РАБОТАЕТ НОВЫЙ СКРИПТ:
Переменные переопределяются через `-var` в terraform CLI.
Файл `terraform.tfvars` читается terraform автоматически,
но **НИКОГДА не перезаписывается** скриптом.
После каждой фазы проверяется md5sum terraform.tfvars.
Если файл изменился — **АВАРИЙНАЯ ОСТАНОВКА** (exit code 99).
---
## Запуск
### На VM (naeel@5.172.178.213):
```bash
cd ~/terra/sless/examples/VM
bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress_$(date +%Y%m%d_%H%M).log
```
### Быстрый прогон (без destroy/resurrect — фазы 7-9 пропускаются):
```bash
SKIP_DESTROY=1 bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress.log
```
### Количество stress-циклов (default: 2):
```bash
STRESS_CYCLES=3 bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress.log
```
---
## Анализ результатов
### Быстрый обзор:
```bash
grep -E '\[(PASS|FAIL|SKIP)\]' /tmp/vm_stress.log
```
### Только ошибки:
```bash
grep '\[FAIL\]' /tmp/vm_stress.log
```
### Итоговая сводка — последние 20 строк лога:
```bash
tail -20 /tmp/vm_stress.log
```
---
## Фазы теста
| # | Имя | Что делает |
|---|-----------------|---------------------------------------------------|
| 1 | BASELINE | apply с полным набором (packages+nginx+docker) |
| 2 | IDEMPOTENT | plan → "No changes" (проверка идемпотентности) |
| 3 | PARTIAL_DISABLE | отключить nginx + docker через -var |
| 4 | PARTIAL_ENABLE | включить обратно nginx + docker |
| 5 | REORDER_PACKAGES| изменить набор base_packages через -var |
| 6 | MANUAL_PURGE | удалить пакеты с VM по SSH → переустановить |
| 7 | DESTROY | terraform destroy → VM в suspend |
| 8 | RESURRECT | apply после destroy → VM просыпается |
| 9 | STRESS_CYCLES | N циклов destroy/apply подряд |
|10 | FINAL_SANITY | финальная проверка VM + пакеты + plan |
---
## Текущее состояние (baseline)
5 ресурсов в state:
- `nubes_vapp.vapp`
- `nubes_vc_vm_v3.vm`
- `sless_job.install_packages[0]`
- `sless_job.install_nginx[0]`
- `sless_job.install_docker[0]`
---
## Exit codes
| Code | Значение |
|------|---------------------------------------------|
| 0 | Все тесты PASS |
| 1 | Есть FAIL (см. лог) |
| 99 | terraform.tfvars был изменён — АВАРИЙНЫЙ СТОП |
@@ -0,0 +1,158 @@
# 2026-03-29 — handler.py: установка Docker CE на ВМ по SSH.
# sless_job runtime: python3.11, entrypoint: handler.install
#
# Метод установки: официальный Docker apt-репозиторий (best practices).
# НЕ используется curl | sh — небезопасно для продакшена.
#
# event_json:
# compose: true/false — ставить ли docker-compose-plugin (default: true)
#
# env_vars:
# VM_IP: внешний IP ВМ
# SSH_USER: логин (ubuntu)
# SSH_KEY: содержимое приватного SSH-ключа (PEM)
import os, io, time
import paramiko
def _load_key(content):
for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
try:
return cls.from_private_key(io.StringIO(content))
except Exception:
pass
raise ValueError("Неподдерживаемый тип SSH-ключа")
def _ssh_connect(retries=5, delay=10):
key = _load_key(os.environ["SSH_KEY"])
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
last_err = None
for attempt in range(retries):
try:
client.connect(
hostname=os.environ["VM_IP"],
username=os.environ["SSH_USER"],
pkey=key,
timeout=15,
)
return client
except Exception as e:
last_err = e
if attempt < retries - 1:
time.sleep(delay)
raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
def _run(client, cmd, timeout=120, check=True):
_, stdout, stderr = client.exec_command(cmd, timeout=timeout)
code = stdout.channel.recv_exit_status()
out = stdout.read().decode(errors="replace").strip()
err = stderr.read().decode(errors="replace").strip()
if check and code != 0:
raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
return code, out, err
def _wait_apt_lock(client, attempts=20, delay=10):
"""Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
# Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
_run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
# Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
_run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
_run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
# Шаг 3: Добить оставшиеся apt/dpkg процессы
_run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
_run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
# Шаг 4: Убрать стейл-локи и починить dpkg
_run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
_run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
time.sleep(3)
locks = ["/var/lib/dpkg/lock-frontend", "/var/lib/dpkg/lock", "/var/lib/apt/lists/lock"]
for i in range(attempts):
all_free = all(
_run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
for lock in locks
)
if all_free:
return
_run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
_run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
if i < attempts - 1:
time.sleep(delay)
raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
# Команды установки Docker CE через официальный apt-репозиторий.
# Источник: https://docs.docker.com/engine/install/ubuntu/
_DOCKER_INSTALL_CMDS = [
# Зависимости для добавления внешнего репозитория
"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq ca-certificates curl gnupg",
# Директория для ключей
"sudo install -m 0755 -d /etc/apt/keyrings",
# GPG-ключ Docker
"curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor --batch --yes -o /etc/apt/keyrings/docker.gpg",
"sudo chmod a+r /etc/apt/keyrings/docker.gpg",
# Docker apt-репозиторий
(
'echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] '
'https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" '
"| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null"
),
# Обновить индекс с новым репо
"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq",
# Установить Docker CE
"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq docker-ce docker-ce-cli containerd.io",
]
def install(event):
"""Установить Docker CE. Если уже установлен — вернуть версию."""
install_compose = event.get("compose", True)
client = _ssh_connect()
try:
# Проверить: уже установлен?
code, ver_out, _ = _run(client, "docker --version 2>&1", check=False)
if code == 0 and "Docker version" in ver_out:
_, compose_out, _ = _run(client, "docker compose version 2>&1", check=False)
return {
"status": "already_installed",
"docker_version": ver_out,
"compose_version": compose_out if "Docker Compose" in compose_out else None,
}
_wait_apt_lock(client)
for cmd in _DOCKER_INSTALL_CMDS:
_run(client, cmd, timeout=180)
if install_compose:
_run(
client,
"sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq docker-compose-plugin",
timeout=120,
)
# Добавить пользователя в группу docker (чтобы запускать без sudo)
ssh_user = os.environ["SSH_USER"]
_run(client, f"sudo usermod -aG docker {ssh_user}", check=False)
# Проверка: запустить hello-world
# Используем sudo т.к. usermod не применится до переподключения
_run(client, "sudo docker run --rm hello-world", timeout=120)
_, ver_out, _ = _run(client, "docker --version", check=False)
_, compose_out, _ = _run(client, "docker compose version 2>&1", check=False)
return {
"status": "ok",
"docker_version": ver_out,
"compose_version": compose_out if "Docker Compose" in compose_out else None,
"note": f"user '{ssh_user}' added to docker group (reconnect to use without sudo)",
}
finally:
client.close()
@@ -0,0 +1,2 @@
paramiko
# v6
@@ -0,0 +1,129 @@
# 2026-03-29 — handler.py: установка nginx на ВМ по SSH.
# sless_job runtime: python3.11, entrypoint: handler.install
#
# event_json: {} (параметров нет — nginx ставится с дефолтной конфигурацией)
#
# env_vars:
# VM_IP: внешний IP ВМ
# SSH_USER: логин (ubuntu)
# SSH_KEY: содержимое приватного SSH-ключа (PEM)
import os, io, time
import paramiko
def _load_key(content):
for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
try:
return cls.from_private_key(io.StringIO(content))
except Exception:
pass
raise ValueError("Неподдерживаемый тип SSH-ключа")
def _ssh_connect(retries=5, delay=10):
key = _load_key(os.environ["SSH_KEY"])
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
last_err = None
for attempt in range(retries):
try:
client.connect(
hostname=os.environ["VM_IP"],
username=os.environ["SSH_USER"],
pkey=key,
timeout=15,
)
return client
except Exception as e:
last_err = e
if attempt < retries - 1:
time.sleep(delay)
raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
def _run(client, cmd, timeout=120, check=True):
_, stdout, stderr = client.exec_command(cmd, timeout=timeout)
code = stdout.channel.recv_exit_status()
out = stdout.read().decode(errors="replace").strip()
err = stderr.read().decode(errors="replace").strip()
if check and code != 0:
raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
return code, out, err
def _wait_apt_lock(client, attempts=20, delay=10):
"""Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
# Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
_run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
# Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
_run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
_run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
# Шаг 3: Добить оставшиеся apt/dpkg процессы
_run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
_run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
# Шаг 4: Убрать стейл-локи и починить dpkg
_run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
_run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
time.sleep(3)
locks = ["/var/lib/dpkg/lock-frontend", "/var/lib/dpkg/lock", "/var/lib/apt/lists/lock"]
for i in range(attempts):
all_free = all(
_run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
for lock in locks
)
if all_free:
return
_run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
_run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
if i < attempts - 1:
time.sleep(delay)
raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
def install(event):
"""Установить nginx. Если уже установлен — проверить что запущен."""
client = _ssh_connect()
try:
# Проверить: уже установлен?
code, ver_out, _ = _run(client, "nginx -v 2>&1", check=False)
already_installed = "nginx version" in ver_out
if already_installed:
# Убедиться что сервис запущен
_run(client, "sudo systemctl start nginx", check=False)
version = ver_out.replace("nginx version: nginx/", "").strip()
_, http_code, _ = _run(
client, "curl -s -o /dev/null -w '%{http_code}' http://localhost", check=False
)
return {
"status": "already_installed",
"version": version,
"http_check": http_code,
}
_wait_apt_lock(client)
_run(client, "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq", timeout=420)
_run(
client,
"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq nginx",
timeout=300,
)
_run(client, "sudo systemctl enable nginx")
_run(client, "sudo systemctl start nginx")
# Проверить HTTP-ответ на localhost
_, http_code, _ = _run(
client, "curl -s -o /dev/null -w '%{http_code}' http://localhost", check=False
)
_, ver_out, _ = _run(client, "nginx -v 2>&1", check=False)
version = ver_out.replace("nginx version: nginx/", "").strip()
return {
"status": "ok",
"version": version,
"http_check": http_code,
}
finally:
client.close()
@@ -0,0 +1,2 @@
paramiko
# v6
@@ -0,0 +1,133 @@
# 2026-03-29 — handler.py: установка apt-пакетов на ВМ по SSH.
# sless_job runtime: python3.11, entrypoint: handler.install
#
# event_json:
# packages: ["git", "curl", ...] — список пакетов (обязательно)
# update: true/false — apt-get update перед install (default: true)
#
# env_vars:
# VM_IP: внешний IP ВМ
# SSH_USER: логин (ubuntu)
# SSH_KEY: содержимое приватного SSH-ключа (PEM)
import os, io, time
import paramiko
def _load_key(content):
"""Загрузить SSH-ключ (Ed25519 / RSA / ECDSA)."""
for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
try:
return cls.from_private_key(io.StringIO(content))
except Exception:
pass
raise ValueError("Неподдерживаемый тип SSH-ключа")
def _ssh_connect(retries=5, delay=10):
"""Подключение к ВМ с retry — ВМ может ещё загружаться."""
key = _load_key(os.environ["SSH_KEY"])
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
last_err = None
for attempt in range(retries):
try:
client.connect(
hostname=os.environ["VM_IP"],
username=os.environ["SSH_USER"],
pkey=key,
timeout=15,
)
return client
except Exception as e:
last_err = e
if attempt < retries - 1:
time.sleep(delay)
raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
def _run(client, cmd, timeout=120, check=True):
"""Выполнить команду, вернуть (exit_code, stdout, stderr)."""
_, stdout, stderr = client.exec_command(cmd, timeout=timeout)
code = stdout.channel.recv_exit_status()
out = stdout.read().decode(errors="replace").strip()
err = stderr.read().decode(errors="replace").strip()
if check and code != 0:
raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
return code, out, err
def _wait_apt_lock(client, attempts=20, delay=10):
"""Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
# Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
_run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
# Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
_run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
_run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
# Шаг 3: Добить оставшиеся apt/dpkg процессы
_run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
_run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
# Шаг 4: Убрать стейл-локи и починить dpkg
_run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
_run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
time.sleep(3)
locks = [
"/var/lib/dpkg/lock-frontend",
"/var/lib/dpkg/lock",
"/var/lib/apt/lists/lock",
]
for i in range(attempts):
all_free = all(
_run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
for lock in locks
)
if all_free:
return
# Повторить убийство процессов удерживающих lock
_run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
_run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
if i < attempts - 1:
time.sleep(delay)
raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
def install(event):
"""Установить apt-пакеты. Идемпотентно — повторный запуск безопасен."""
packages = event.get("packages", [])
if not packages:
return {"status": "skipped", "reason": "packages list is empty"}
do_update = event.get("update", True)
client = _ssh_connect()
try:
_wait_apt_lock(client)
if do_update:
_run(client, "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq", timeout=420)
pkg_str = " ".join(packages)
_run(
client,
f"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq {pkg_str}",
timeout=300,
)
# Проверить что установилось
installed, missing = [], []
for pkg in packages:
code, _, _ = _run(
client,
f"dpkg -l {pkg} 2>/dev/null | grep -q '^ii'",
check=False,
)
(installed if code == 0 else missing).append(pkg)
return {
"status": "ok" if not missing else "partial",
"installed": installed,
"missing": missing,
}
finally:
client.close()
@@ -0,0 +1,2 @@
paramiko
# v6
+43
View File
@@ -0,0 +1,43 @@
// 2026-03-25 — main.tf для примера с vApp + ВМ (Виртуальный датацентр Nubes).
// Провайдер nubes. Sless-провайдер не нужен — пример чисто инфраструктурный.
terraform {
required_providers {
nubes = {
source = "terra.k8c.ru/nubes/nubes"
version = "5.0.51"
}
sless = {
source = "terra.k8c.ru/naeel/sless"
version = "~> 0.1"
}
}
}
# ------------------------------------------------------------------
# Переменные
# ------------------------------------------------------------------
variable "vm_public_key" {
type = string
sensitive = true
description = "Публичный SSH-ключ для ВМ. Приватный ключ: ~/terra/sless/examples/VM/vm_key"
}
variable "api_token" {
type = string
sensitive = true
description = "Nubes API token"
}
# ------------------------------------------------------------------
# Провайдер
# ------------------------------------------------------------------
# API Dashboard (для Terraform-провайдеров): https://deck-api-test.ngcloud.ru/api/v1/index.cfm
# UI облака (только браузер): https://deck-test.ngcloud.ru/
provider "nubes" {
api_token = var.api_token
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
log_level = "debug" # none | info | debug, default = "none"
}
+18
View File
@@ -0,0 +1,18 @@
# 2026-03-29 — outputs.tf: результаты установки ПО на ВМ.
# phase: Pending / Building / Running / Succeeded / Failed
# message: JSON с деталями (что установлено) или traceback при ошибке
output "install_packages_result" {
description = "Результат установки базовых пакетов"
value = var.install_packages ? sless_job.install_packages[0].message : "skipped"
}
output "install_nginx_result" {
description = "Результат установки nginx"
value = var.install_nginx ? sless_job.install_nginx[0].message : "skipped"
}
output "install_docker_result" {
description = "Результат установки Docker"
value = var.install_docker ? sless_job.install_docker[0].message : "skipped"
}
+105
View File
@@ -0,0 +1,105 @@
# 2026-03-29 — sless.tf: провайдер sless и sless_job ресурсы для установки ПО на ВМ.
#
# Схема работы:
# 1. terraform apply создаёт FunctionJob CR в k8s
# 2. Провайдер загружает код из source_dir в S3
# 3. Оператор собирает Docker-образ (kaniko) и запускает Job
# 4. Job подключается к ВМ по SSH и устанавливает ПО
# 5. terraform apply завершается: outputs содержат статус каждого шага
#
# Для повторного запуска: увеличь install_run_id в terraform.tfvars → terraform apply
# ---------------------------------------------------------------------------
# Провайдер
# ---------------------------------------------------------------------------
provider "sless" {
endpoint = "https://sless.kube5s.ru"
token = var.api_token # тот же JWT что и в provider "nubes"
nubes_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
}
# ---------------------------------------------------------------------------
# Общие locals: SSH-параметры для подключения к ВМ
# ---------------------------------------------------------------------------
locals {
vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
ssh_env = {
VM_IP = local.vm_ip
SSH_USER = "ubuntu"
SSH_KEY = file("${path.module}/vm_key") # приватный ключ, созданный на шаге 2 (не хранится в git)
}
}
# ---------------------------------------------------------------------------
# Job 1: базовые пакеты (jq, pip3 и др.)
# ---------------------------------------------------------------------------
resource "sless_job" "install_packages" {
count = var.install_packages ? 1 : 0
name = "vm-install-packages"
runtime = "python3.11"
entrypoint = "handler.install"
source_dir = "${path.module}/functions/install-packages"
memory_mb = 128
env_vars = local.ssh_env
event_json = jsonencode({
packages = var.base_packages
update = true
})
run_id = var.install_run_id
wait_timeout_sec = 600
depends_on = [nubes_vc_vm_v3.vm]
}
# ---------------------------------------------------------------------------
# Job 2: nginx
# ---------------------------------------------------------------------------
resource "sless_job" "install_nginx" {
count = var.install_nginx ? 1 : 0
name = "vm-install-nginx"
runtime = "python3.11"
entrypoint = "handler.install"
source_dir = "${path.module}/functions/install-nginx"
memory_mb = 128
env_vars = local.ssh_env
event_json = jsonencode({})
run_id = var.install_run_id
wait_timeout_sec = 600
depends_on = [nubes_vc_vm_v3.vm, sless_job.install_packages]
}
# ---------------------------------------------------------------------------
# Job 3: Docker CE
# ---------------------------------------------------------------------------
resource "sless_job" "install_docker" {
count = var.install_docker ? 1 : 0
name = "vm-install-docker"
runtime = "python3.11"
entrypoint = "handler.install"
source_dir = "${path.module}/functions/install-docker"
memory_mb = 128
env_vars = local.ssh_env
event_json = jsonencode({
compose = true
})
run_id = var.install_run_id
wait_timeout_sec = 900
depends_on = [nubes_vc_vm_v3.vm, sless_job.install_packages, sless_job.install_nginx]
}
+112
View File
@@ -0,0 +1,112 @@
# =============================================================================
# terraform.tfvars.template — шаблон конфигурации примера «ВМ в Nubes vDC»
# =============================================================================
#
# Скопируйте этот файл в terraform.tfvars и заполните все значения:
#
# cp terraform.tfvars.template terraform.tfvars
#
# terraform.tfvars НЕ коммитится в git (защищён .gitignore) —
# он содержит секретные данные (API-токен, SSH-ключ).
# =============================================================================
# =============================================================================
# 1. API-ТОКЕН
# =============================================================================
#
# Один токен для обоих провайдеров: nubes (облако) и sless (serverless).
#
# Где взять:
# Личный Кабинет Nubes → правый верхний угол → «Профиль» → «API-токены»
# → кнопка «Создать токен» → скопируйте JWT-строку целиком.
#
# Токен выглядит так: eyJhbGciOiJS...длинная строка...
# Вставьте в кавычки целиком, не разбивая на строки.
#
api_token = "ВСТАВИТЬ_API_ТОКЕН"
# =============================================================================
# 2. SSH-КЛЮЧ ДЛЯ ВМ
# =============================================================================
#
# Публичный ключ прописывается в ВМ при создании.
# Приватный ключ нужен для SSH-подключения к ВМ.
#
# Как сгенерировать:
# ssh-keygen -t ed25519 -f ./vm_key -N "" -C "sless-demo-vm"
# # Создаст два файла: vm_key (приватный) и vm_key.pub (публичный)
#
# vm_key.pub уже есть в папке — скопируйте его содержимое сюда.
# Строка выглядит так: ssh-ed25519 AAAA... имя-ключа
#
vm_public_key = "ВСТАВИТЬ_ПУБЛИЧНЫЙ_SSH_КЛЮЧ"
# =============================================================================
# 3. UUID СЕРВИСОВ NUBES (вdc_uid и nsxt_uid)
# =============================================================================
#
# Где взять:
# Личный Кабинет → «Мои сервисы» → найдите нужный сервис → раздел
# «Параметры инстанса» или «Технические параметры» → UUID.
#
# vdc_uid — это UUID услуги «Виртуальный датацентр (vDC)»
# Пример раздела ЛК: Мои сервисы → vDC → [ваш vDC] → UUID
#
# nsxt_uid — это UUID услуги «Сетевой шлюз периметра (Edge)»
# Пример раздела ЛК: Мои сервисы → Edge → [ваш Edge] → UUID
#
# Формат: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (UUID v4)
#
# ВАЖНО: эти значения не изменяются после создания vApp.
# После первого terraform apply менять их нельзя — сломает state.
#
vdc_uid = "ВСТАВИТЬ_UUID_VDC"
nsxt_uid = "ВСТАВИТЬ_UUID_NSXT"
# =============================================================================
# 4. ФЛАГИ УСТАНОВКИ ПО НА ВМ
# =============================================================================
#
# Что устанавливать при terraform apply.
# Установка выполняется через serverless-джобы (sless_job) по SSH на ВМ.
# Каждый флаг — отдельный джоб, они выполняются независимо.
#
# true = установить
# false = не устанавливать (ресурс не создаётся вовсе)
#
install_packages = true # базовые apt-пакеты из списка base_packages ниже
install_nginx = true # nginx (веб-сервер)
install_docker = true # Docker CE + docker-compose-plugin
# =============================================================================
# 5. СПИСОК БАЗОВЫХ ПАКЕТОВ
# =============================================================================
#
# Эти пакеты устанавливаются когда install_packages = true.
# Любые стандартные apt-пакеты Ubuntu 22.04.
#
# Как изменить список:
# - Добавьте пакет: base_packages = ["jq", "htop", "curl", "git"]
# - Удалите пакет: уберите его из списка
# - После изменения: увеличьте install_run_id (см. ниже) и terraform apply
#
base_packages = ["jq", "python3-pip", "htop", "unzip"]
# =============================================================================
# 6. RUN_ID — триггер повторного запуска джобов
# =============================================================================
#
# sless_job — это разовые джобы (k8s Job). Terraform не перезапускает их
# автоматически если код не изменился. Чтобы запустить ВСЕ install-джобы
# заново (например, после изменения base_packages) — увеличьте это число на 1
# и выполните terraform apply.
#
# Например: было install_run_id = 3 → стало install_run_id = 4 → apply
#
install_run_id = 1
+28
View File
@@ -0,0 +1,28 @@
// 2026-03-25 — vapp.tf: виртуальный каталог ВМ (vApp) в Nubes vDC.
// nubes_vapp — контейнер для ВМ внутри Виртуального датацентра.
// Обязательные поля: vdc_uid, nsxt_uid, vapp_name, resource_name.
resource "nubes_vapp" "vapp" {
resource_name = "vm-sless-vapp"
vapp_name = "vapp-sless" # Уникальное в рамках организации. Не изменяется после создания.
vdc_uid = var.vdc_uid # UUID Услуги «Виртуальный датацентр (vDC)». В terraform.tfvars.
nsxt_uid = var.nsxt_uid # UUID Услуги «Сетевой шлюз периметра (Edge)». В terraform.tfvars.
adopt_existing_on_create = true
operation_timeout = "15m"
# ВАЖНО: delete без предварительного suspend завершается ошибкой
# "Невозможно выполнить операцию удаления услуги. Услуга не остановлена"
# suspend_on_destroy гарантирует правильный порядок: suspend → delete.
suspend_on_destroy = true
}
output "vapp_id" {
value = nubes_vapp.vapp.id
description = "ID созданного vApp (используется как vapp_uid при создании ВМ)"
}
output "vapp_state" {
value = nubes_vapp.vapp.state_out_flat
description = "Плоский state vApp — адреса, статусы сети и т.д."
}
+51
View File
@@ -0,0 +1,51 @@
# 2026-03-29 — variables.tf: переменные для sless и установки ПО на ВМ.
# Переменные nubes (api_token, vm_public_key) остаются в main.tf.
# sless использует тот же api_token — отдельной переменной не нужно.
# ---- Флаги: что устанавливать на ВМ --------------------------------------
variable "install_packages" {
type = bool
default = true
description = "Установить базовые apt-пакеты (jq и др.)"
}
variable "install_nginx" {
type = bool
default = false
description = "Установить nginx"
}
variable "install_docker" {
type = bool
default = false
description = "Установить Docker CE + docker-compose-plugin"
}
# ---- Параметры ------------------------------------------------------------
variable "base_packages" {
type = list(string)
default = ["jq", "python3-pip", "htop", "unzip"]
description = "Список apt-пакетов для install-packages"
}
variable "install_run_id" {
type = number
default = 1
description = "Увеличь на 1 чтобы запустить все install-джобы заново"
}
# ---- Идентификаторы сервисов Nubes ----------------------------------------
# Берутся из Личного Кабинета → «Мои сервисы» → нужный сервис → параметры инстанса.
# Не изменяются после создания vApp.
variable "vdc_uid" {
type = string
description = "UUID услуги «Виртуальный датацентр (vDC)». Личный Кабинет → Мои сервисы → vDC → UUID."
}
variable "nsxt_uid" {
type = string
description = "UUID услуги «Сетевой шлюз периметра (Edge / NSX-T)». Личный Кабинет → Мои сервисы → Edge → UUID."
}
+37
View File
@@ -0,0 +1,37 @@
// 2026-03-25 — vm.tf: виртуальная машина (nubes_vc_vm_v3) внутри vApp.
// Зависит от nubes_vapp.vapp — создаётся после vApp.
// image_vm, vapp_uid, user_public_key не изменяются после создания.
resource "nubes_vc_vm_v3" "vm" {
resource_name = "vm-sless-1"
vm_name = "web02" # Имя ВМ в Nubes vCD. Не изменяется после создания.
# Определяет имя NSX-T IP Set: {vapp_name}-{vm_name}
vapp_uid = nubes_vapp.vapp.id # ссылка на vApp. Не изменяется после создания.
image_vm = "Ubuntu_22-20G" # Не изменяется после создания.
# image_vm = "Ubuntu 22.04 LTS" # Не изменяется после создания.
ip_space_name = "internet-ipv4-v1"
user_login = "ubuntu"
user_public_key = var.vm_public_key # задаётся в terraform.tfvars
vm_cpu = 2
vm_ram = 2 # GB
vm_disk = 20 # GB
adopt_existing_on_create = true
operation_timeout = "15m"
# delete без предварительного suspend завершается ошибкой (аналогично vApp).
suspend_on_destroy = true
}
output "vm_id" {
value = nubes_vc_vm_v3.vm.id
description = "ID созданной ВМ"
}
output "vm_state" {
value = nubes_vc_vm_v3.vm.state_out_flat
description = "Плоский state ВМ — IP-адреса, статус и т.д."
}

Some files were not shown because too many files have changed in this diff Show More