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 ресурс)
This commit is contained in:
Repinoid
@@ -4,6 +4,18 @@
|
|||||||
|
|
||||||
**НЕ "СОВЕРШЕНСТВОВАТЬ" РАБОЧИЙ КОД БЕЗ ЯВНОГО УКАЗАНИЯ.**
|
**НЕ "СОВЕРШЕНСТВОВАТЬ" РАБОЧИЙ КОД БЕЗ ЯВНОГО УКАЗАНИЯ.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ЗАПРЕТ НА ВЫДУМКИ
|
||||||
|
|
||||||
|
**КАТЕГОРИЧЕСКИ ЗАПРЕЩАЕТСЯ придумывать, догадываться или предполагать:**
|
||||||
|
- значения параметров, которые не видны в коде или документации
|
||||||
|
- допустимые значения enum/ролей/типов — если не взяты из реального источника
|
||||||
|
- поведение API, провайдеров, библиотек — если не подтверждено кодом или документацией
|
||||||
|
- любые факты о системе, которые агент "знает" из общих соображений
|
||||||
|
|
||||||
|
**Если информации нет — спросить у пользователя. Не угадывать.**
|
||||||
|
|
||||||
Если код работает — не трогать. Никаких:
|
Если код работает — не трогать. Никаких:
|
||||||
- рефакторингов "попутно"
|
- рефакторингов "попутно"
|
||||||
- улучшений стиля
|
- улучшений стиля
|
||||||
@@ -60,6 +72,20 @@
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## Лог мышления (обязательно)
|
||||||
|
|
||||||
|
Каждый агент в каждом чате **обязан** вести лог своих рассуждений:
|
||||||
|
- Папка: `doc/thinking/`
|
||||||
|
- Файл: `ГГГГ-ММ-ДД.md` (по дате сессии)
|
||||||
|
- В начале файла указать имя агента и модель
|
||||||
|
- Если файл на текущую дату уже существует — дописывать в конец, добавив разделитель `---` и имя агента
|
||||||
|
- Записывать **полный** ход мыслей: что анализирую, какие гипотезы, что нашёл, что отбросил, к чему пришёл, почему
|
||||||
|
- Записывать **до** начала действий (план) и **после** (результат)
|
||||||
|
|
||||||
|
Цель: пользователь должен видеть весь процесс рассуждений в читаемом виде.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Git
|
## Git
|
||||||
|
|
||||||
Коммитить и пушить после каждого завершённого этапа.
|
Коммитить и пушить после каждого завершённого этапа.
|
||||||
|
|||||||
@@ -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
|
||||||
@@ -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
|
||||||
@@ -2,6 +2,74 @@
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## 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)
|
## 2026-03-30 — Переход на READ-ONLY подход в тестах (v2)
|
||||||
|
|
||||||
### Решение
|
### Решение
|
||||||
|
|||||||
@@ -248,6 +248,113 @@ Error: Ошибка клиента
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## 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 (30–60 сек) или 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
|
## 2026-03-29 — SSH timeout после destroy VM example
|
||||||
|
|
||||||
### Симптом
|
### Симптом
|
||||||
|
|||||||
@@ -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` | ~50–75 секунд |
|
||||||
|
| Удаление `nubes_postgres_user` | ~56–76 секунд |
|
||||||
|
| Создание `nubes_postgres_database` | ~47–70 секунд |
|
||||||
|
| Удаление `nubes_postgres_database` | ~46–92 секунды |
|
||||||
|
| Обновление `nubes_postgres` in-place | мгновенно (~0s) |
|
||||||
|
|
||||||
|
Полный `apply` с 6 новыми ресурсами занимает **~8–12 минут**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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"`
|
||||||
@@ -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/ и проверить формат конфигурации**
|
||||||
@@ -221,6 +221,56 @@ Error: Ошибка клиента
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## 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. Последовательность зависимостей (обязательная)
|
## 4. Последовательность зависимостей (обязательная)
|
||||||
|
|
||||||
Нарушение любого из `depends_on` в цепочке вызывает ошибки API.
|
Нарушение любого из `depends_on` в цепочке вызывает ошибки API.
|
||||||
@@ -284,12 +334,13 @@ ssh user@vm "tmux attach -t tf"
|
|||||||
| Создание `nubes_postgres_user` с `ddl_user` | ✅ | ~60–90 сек | — |
|
| Создание `nubes_postgres_user` с `ddl_user` | ✅ | ~60–90 сек | — |
|
||||||
| Создание `nubes_postgres_user` с `app_user` | ❌ | Секрет не создан (~3 мин) | Только `ddl_user` |
|
| Создание `nubes_postgres_user` с `app_user` | ❌ | Секрет не создан (~3 мин) | Только `ddl_user` |
|
||||||
| Параллельное создание нескольких users | ❌ | Race condition в Vault | `depends_on` chain |
|
| Параллельное создание нескольких users | ❌ | Race condition в Vault | `depends_on` chain |
|
||||||
| Создание 2-го пользователя (любого) | ❌ | Vault: Секрет не создан (~3–4 мин) | Ограничение тест-окружения |
|
| Создание 2–3-го пользователя (любого) | ✅ | ~60–90 сек каждый | `depends_on` chain обязателен |
|
||||||
| Удаление `nubes_postgres_user` | ✅ | ~56–81 сек | — |
|
| Удаление `nubes_postgres_user` | ✅ | ~56–81 сек | — |
|
||||||
| Принятие существующего user (`adopt`) | ✅ | не работает при "зависшей" операции | Новое имя |
|
| Принятие существующего user (`adopt`) | ✅ | не работает при "зависшей" операции | Новое имя |
|
||||||
| Создание `nubes_postgres_database` | ✅ | ~47–66 сек | — |
|
| Создание `nubes_postgres_database` | ⚠️ | Может блокироваться ERR-PG-08 | См. раздел 3.5 |
|
||||||
| Удаление `nubes_postgres_database` | ✅ | ~46–92 сек | — |
|
| Удаление `nubes_postgres_database` | ✅ | ~46–92 сек | — |
|
||||||
| Повторный apply (idempotent) | ❌ частично | `vault_secrets` → destroy+recreate user/db | Открытая проблема |
|
| 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` |
|
| apply через SSH (долгий) | ❌ | SSH timeout убивает процесс | `nohup` или `tmux` |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|||||||
@@ -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` — отметить дату исправления
|
||||||
|
|
||||||
@@ -0,0 +1,386 @@
|
|||||||
|
# Лог мышления — 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Задача: Решения по архитектуре 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
@@ -1,5 +1,5 @@
|
|||||||
# Created: 2026-03-11
|
# Created: 2026-03-11 / Updated: 2026-03-30
|
||||||
# Purpose: ignore generated artifacts for the `examples` repository
|
# Purpose: ignore generated artifacts and internal files for the `examples` repository
|
||||||
|
|
||||||
# Terraform
|
# Terraform
|
||||||
.terraform/
|
.terraform/
|
||||||
@@ -16,6 +16,7 @@ crash.log
|
|||||||
# Provider plugins / caches
|
# Provider plugins / caches
|
||||||
.terraform.d/
|
.terraform.d/
|
||||||
|
|
||||||
|
# tfvars содержат секреты (токены, ключи) — пользователь создаёт из .template
|
||||||
*.tfvars
|
*.tfvars
|
||||||
|
|
||||||
# Archives and build artifacts
|
# Archives and build artifacts
|
||||||
@@ -39,3 +40,34 @@ venv/
|
|||||||
.env
|
.env
|
||||||
*.local
|
*.local
|
||||||
*.log
|
*.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/
|
||||||
|
|||||||
@@ -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"
|
||||||
|
}
|
||||||
@@ -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
|
||||||
|
}
|
||||||
@@ -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]
|
||||||
|
}
|
||||||
@@ -0,0 +1,94 @@
|
|||||||
|
// 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
|
||||||
|
}
|
||||||
@@ -0,0 +1,56 @@
|
|||||||
|
// 2026-04-01 — postgres_extra.tf: дополнительные пользователи и базы данных для lifecycle-тестов.
|
||||||
|
//
|
||||||
|
// ВАЖНО: ресурсы создаются строго последовательно через depends_on.
|
||||||
|
// Параллельное создание нескольких пользователей в одном инстансе вызывает
|
||||||
|
// ошибки API ("Секрет не был создан", "key doesn't exist") — race condition на стороне Nubes.
|
||||||
|
//
|
||||||
|
// ИЗВЕСТНОЕ ОГРАНИЧЕНИЕ: если apply упал в середине создания пользователя —
|
||||||
|
// этот пользователь может "зависнуть" в промежуточном состоянии в Nubes API.
|
||||||
|
// adopt_existing_on_create не спасает. Решение: использовать имена без истории,
|
||||||
|
// либо ждать очистки на стороне Nubes.
|
||||||
|
|
||||||
|
// ── Пользователь 1 ───────────────────────────────────────────────────────────
|
||||||
|
// Первый в extra-цепочке. Ждёт pg_test_db (postgres.tf).
|
||||||
|
|
||||||
|
resource "nubes_postgres_user" "test_extra_user1" {
|
||||||
|
postgres_id = nubes_postgres.pg_test_instance.id
|
||||||
|
username = "test_eu1"
|
||||||
|
role = "ddl_user"
|
||||||
|
adopt_existing_on_create = true
|
||||||
|
|
||||||
|
# Ждём pg_test_db — иначе параллельный старт с созданием БД ломает API.
|
||||||
|
depends_on = [nubes_postgres_database.pg_test_db]
|
||||||
|
}
|
||||||
|
|
||||||
|
// ── Пользователь 2 ───────────────────────────────────────────────────────────
|
||||||
|
|
||||||
|
resource "nubes_postgres_user" "test_extra_user2" {
|
||||||
|
postgres_id = nubes_postgres.pg_test_instance.id
|
||||||
|
username = "test_eu2"
|
||||||
|
role = "ddl_user"
|
||||||
|
adopt_existing_on_create = true
|
||||||
|
|
||||||
|
depends_on = [nubes_postgres_user.test_extra_user1]
|
||||||
|
}
|
||||||
|
|
||||||
|
// ── База данных 1 (owner = test_eu1) ─────────────────────────────────────────
|
||||||
|
|
||||||
|
resource "nubes_postgres_database" "test_extra_db1" {
|
||||||
|
postgres_id = nubes_postgres.pg_test_instance.id
|
||||||
|
db_name = "test_edb1"
|
||||||
|
db_owner = nubes_postgres_user.test_extra_user1.username
|
||||||
|
adopt_existing_on_create = true
|
||||||
|
|
||||||
|
depends_on = [nubes_postgres_user.test_extra_user2]
|
||||||
|
}
|
||||||
|
|
||||||
|
// ── База данных 2 (owner = test_eu2) ─────────────────────────────────────────
|
||||||
|
|
||||||
|
resource "nubes_postgres_database" "test_extra_db2" {
|
||||||
|
postgres_id = nubes_postgres.pg_test_instance.id
|
||||||
|
db_name = "test_edb2"
|
||||||
|
db_owner = nubes_postgres_user.test_extra_user2.username
|
||||||
|
adopt_existing_on_create = true
|
||||||
|
|
||||||
|
depends_on = [nubes_postgres_database.test_extra_db1]
|
||||||
|
}
|
||||||
@@ -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"
|
||||||
@@ -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 ==="
|
||||||
@@ -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}"
|
||||||
@@ -4,7 +4,7 @@ terraform {
|
|||||||
required_providers {
|
required_providers {
|
||||||
nubes = {
|
nubes = {
|
||||||
source = "terra.k8c.ru/nubes/nubes"
|
source = "terra.k8c.ru/nubes/nubes"
|
||||||
version = "5.0.31"
|
version = "5.0.51"
|
||||||
}
|
}
|
||||||
sless = {
|
sless = {
|
||||||
source = "terra.k8c.ru/naeel/sless"
|
source = "terra.k8c.ru/naeel/sless"
|
||||||
@@ -52,6 +52,7 @@ variable "pg_password" {
|
|||||||
|
|
||||||
provider "nubes" {
|
provider "nubes" {
|
||||||
api_token = var.api_token
|
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"
|
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
+21
-40
@@ -1,75 +1,56 @@
|
|||||||
# Примеры использования sless
|
# sless — примеры
|
||||||
|
|
||||||
## Обзор платформы
|
> ⚠️ **Тестовое окружение.** Все примеры работают с тестовым API Nubes и тестовым кластером sless. Не используйте в продакшне без предварительного согласования.
|
||||||
|
|
||||||
**sless** — система управления serverless-функциями на базе Kubernetes. Разработчик загружает код функции, платформа собирает из него Docker-образ, разворачивает его в кластере и предоставляет HTTP-эндпоинт для вызова. Всё описывается декларативно через Terraform.
|
**sless** — платформа для запуска serverless-функций на базе Kubernetes.
|
||||||
|
Разработчик загружает код, платформа собирает Docker-образ и разворачивает его в кластере.
|
||||||
### Основные ресурсы провайдера
|
Всё описывается декларативно через Terraform.
|
||||||
|
|
||||||
| Ресурс | Назначение |
|
|
||||||
|---|---|
|
|
||||||
| `sless_service` | Long-running HTTP-сервис: всегда активен, отвечает на запросы. Имеет свой URL после деплоя. |
|
|
||||||
| `sless_job` | Одноразовый запуск функции: собирает образ, выполняет код, завершается. Используется для миграций БД, batch-обработки и т.д. |
|
|
||||||
|
|
||||||
Namespace функций вычисляется автоматически из JWT-токена: `sless-{sha256[:8]}`.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Требования
|
## Ресурсы Terraform-провайдера
|
||||||
|
|
||||||
- Terraform >= 1.3
|
| Ресурс | Что делает |
|
||||||
- JWT-токен для аутентификации в sless API
|
|---|---|
|
||||||
- JWT-токен для Nubes Cloud API (если используются managed-ресурсы: PostgreSQL и т.д.)
|
| `sless_job` | Разовый запуск: выполняет код один раз и завершается (установка ПО, миграции и т.д.) |
|
||||||
- Доступ к `https://sless.kube5s.ru`
|
| `sless_service` | HTTP-сервис: всегда запущен, отвечает на запросы, имеет постоянный URL — _примеры появятся позднее_ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Конфигурация провайдера
|
## Конфигурация провайдера
|
||||||
|
|
||||||
```hcl
|
```hcl
|
||||||
provider "sless" {
|
provider "sless" {
|
||||||
endpoint = "https://sless.kube5s.ru"
|
endpoint = "https://sless.kube5s.ru"
|
||||||
token = var.sless_token
|
token = var.api_token
|
||||||
}
|
|
||||||
|
|
||||||
provider "nubes_cloud" {
|
|
||||||
base_url = "https://deck-api-test.ngcloud.ru/api/v1"
|
|
||||||
token = var.nubes_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
|
**→ [Начать здесь](VM/README.md)**
|
||||||
cd POSTGRES
|
|
||||||
terraform init
|
|
||||||
terraform apply
|
|
||||||
```
|
|
||||||
|
|
||||||
Подробности: [POSTGRES/README.md](POSTGRES/README.md)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Полезные команды
|
## Полезные команды
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Посмотреть состояние задеплоенных ресурсов:
|
# Посмотреть состояние ресурсов:
|
||||||
terraform show
|
terraform show
|
||||||
|
|
||||||
# Принудительно пересобрать сервис (после изменения кода):
|
# Повторно запустить установку ПО: увеличить install_run_id в terraform.tfvars, затем:
|
||||||
terraform apply -replace=sless_service.<имя>
|
|
||||||
|
|
||||||
# Повторно запустить job: увеличить run_id в .tf-файле, затем:
|
|
||||||
terraform apply
|
terraform apply
|
||||||
|
|
||||||
# Удалить все ресурсы примера:
|
# Удалить все ресурсы:
|
||||||
terraform destroy
|
terraform destroy
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -1,5 +1,9 @@
|
|||||||
# Пример: Виртуальная машина (vApp + VM) в Nubes vDC
|
# Пример: Виртуальная машина (vApp + VM) в Nubes vDC
|
||||||
|
|
||||||
|
> ⚠️ **Тестовое окружение.** Пример работает с тестовым API Nubes и тестовым кластером sless. Не использовать в продакшне без предварительного согласования.
|
||||||
|
|
||||||
|
> В этом примере используются только **разовые джобы** (`sless_job`) — для установки ПО на ВМ. Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
|
||||||
|
|
||||||
Создаёт:
|
Создаёт:
|
||||||
- **vApp** — виртуальный каталог (контейнер для ВМ в VMware vDC)
|
- **vApp** — виртуальный каталог (контейнер для ВМ в VMware vDC)
|
||||||
- **ВМ** — Ubuntu 22.04, 2 CPU / 2 GB RAM / 20 GB disk
|
- **ВМ** — Ubuntu 22.04, 2 CPU / 2 GB RAM / 20 GB disk
|
||||||
@@ -200,5 +204,5 @@ terraform destroy
|
|||||||
| `vm.tf` | Ресурс ВМ (Ubuntu 22.04) |
|
| `vm.tf` | Ресурс ВМ (Ubuntu 22.04) |
|
||||||
| `sless.tf` | Serverless-джобы для установки ПО |
|
| `sless.tf` | Serverless-джобы для установки ПО |
|
||||||
| `outputs.tf` | Вывод IP-адреса и ID ресурсов |
|
| `outputs.tf` | Вывод IP-адреса и ID ресурсов |
|
||||||
| `vm_key` / `vm_key.pub` | SSH-ключ для доступа к ВМ |
|
| `vm_key` / `vm_key.pub` | SSH-ключ — **создаётся вами на Шаге 2**, в git не хранится |
|
||||||
| `functions/` | Код Python-функций для install-джобов |
|
| `functions/` | Код Python-функций для install-джобов |
|
||||||
|
|||||||
@@ -39,4 +39,5 @@ variable "api_token" {
|
|||||||
provider "nubes" {
|
provider "nubes" {
|
||||||
api_token = var.api_token
|
api_token = var.api_token
|
||||||
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
|
api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
|
||||||
|
log_level = "debug" # none | info | debug, default = "none"
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -24,15 +24,12 @@ provider "sless" {
|
|||||||
# ---------------------------------------------------------------------------
|
# ---------------------------------------------------------------------------
|
||||||
|
|
||||||
locals {
|
locals {
|
||||||
# TODO: заменить externalConnect → internalConnect когда DevOps настроят
|
|
||||||
# сеть между k8s кластером и Nubes vDC (сейчас только внешний IP доступен).
|
|
||||||
vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
|
vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
|
||||||
|
|
||||||
ssh_env = {
|
ssh_env = {
|
||||||
VM_IP = local.vm_ip
|
VM_IP = local.vm_ip
|
||||||
SSH_USER = "ubuntu"
|
SSH_USER = "ubuntu"
|
||||||
# TODO(vault): заменить на чтение из Vault когда сервис заработает; пока тестовый стенд — прямой файл.
|
SSH_KEY = file("${path.module}/vm_key") # приватный ключ, созданный на шаге 2 (не хранится в git)
|
||||||
SSH_KEY = file("${path.module}/vm_key")
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user