No description
257ea4b159
First-half of every deploy: ZFS snapshot, then ensure data
containers exist + their services are configured + ready.
Per requirement: data containers are NEVER destroyed across
deploys, only created if absent.
Sequence:
Pre-flight (incus_hosts)
Validate veza_env (staging|prod) + veza_release_sha (40-char SHA).
Compute the list of managed data containers from
veza_container_prefix.
ZFS snapshot (incus_hosts)
Resolve each container's dataset via `zfs list | grep`. Skip if
no ZFS dataset (non-ZFS storage backend) or if the container
doesn't exist yet (first-ever deploy).
Snapshot name: <dataset>@pre-deploy-<sha>. Idempotent — re-runs
no-op once the snapshot exists.
Prune step keeps the {{ veza_release_retention }} most recent
pre-deploy snapshots per dataset, drops the rest.
Provision (incus_hosts)
For each {postgres, redis, rabbitmq, minio} container : `incus
info` to detect existence, `incus launch ... --profile veza-data
--profile veza-net` if absent, then poll `incus exec -- /bin/true`
until ready.
refresh_inventory after launch so subsequent plays can use
community.general.incus to reach the new containers.
Configure (per-container plays, ansible_connection=community.general.incus)
postgres : apt install postgresql-16, ensure veza role +
veza database (no_log on password).
redis : apt install redis-server, render redis.conf with
vault_redis_password + appendonly + sane LRU.
rabbitmq : apt install rabbitmq-server, ensure /veza vhost +
veza user with vault_rabbitmq_password (.* perms).
minio : direct-download minio + mc binaries (no apt
package), render systemd unit + EnvironmentFile,
start, then `mc mb --ignore-existing
veza-<env>` to create the application bucket.
Why no `roles/postgres_ha` etc.?
The existing HA roles (postgres_ha, redis_sentinel,
minio_distributed) target multi-host topology and pg_auto_failover.
Phase-1 staging on a single R720 doesn't justify HA orchestration ;
the simpler inline tasks are what the user gets out of the box.
When prod splits onto multiple hosts (post v1.1), the inline
blocks lift into the existing HA roles unchanged.
Idempotency guarantees:
* Container exist : `incus info >/dev/null` short-circuit.
* Snapshot : zfs list -t snapshot guard.
* Postgres role/db : community.postgresql idempotent.
* Redis config : copy with notify-restart only on diff.
* RabbitMQ vhost/user : community.rabbitmq idempotent.
* MinIO bucket : mc mb --ignore-existing.
Failure mode: any task that fails, fails the playbook hard. The
ZFS snapshot is the recovery story — `zfs rollback
<dataset>@pre-deploy-<sha>` restores prior state if we corrupt
something on a partial run.
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .github | ||
| .husky | ||
| .zap | ||
| apps/web | ||
| chat_exports | ||
| config | ||
| dev-environment | ||
| docker/haproxy | ||
| docs | ||
| docs-assets/mermaid | ||
| fixtures | ||
| full_veza_audit_data | ||
| home/senke/git/talas/veza/apps/web/src | ||
| infra | ||
| k8s | ||
| loadtests | ||
| make | ||
| packages/design-system | ||
| prompts | ||
| proto | ||
| scripts | ||
| sub_task_agents | ||
| test-reports/20251226-132633 | ||
| tests | ||
| tmt | ||
| tools | ||
| veza-backend-api | ||
| veza-common | ||
| veza-docs | ||
| veza-stream-server | ||
| .commitlintrc.json | ||
| .cursorrules | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitleaks.toml | ||
| .lighthouserc.js | ||
| .lintstagedrc.json | ||
| .nvmrc | ||
| .pa11yci.json | ||
| .semgrepignore | ||
| AUDIT_REPORT.md | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| docker-compose.dev.yml | ||
| docker-compose.env.example | ||
| docker-compose.override.yml.example | ||
| docker-compose.prod.yml | ||
| docker-compose.staging.yml | ||
| docker-compose.test.yml | ||
| docker-compose.yml | ||
| env.remote-r720.example | ||
| FUNCTIONAL_AUDIT.md | ||
| go.work | ||
| go.work.sum | ||
| help | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| RELEASE_NOTES_V1.md | ||
| run-audit.sh | ||
| rust-toolchain.toml | ||
| status.sh | ||
| turbo.json | ||
| Untitled | ||
| VERSION | ||
| VEZA_VERSIONS_ROADMAP.md | ||
Veza Monorepo
Version courante : v1.0.4 (cleanup + consolidation post-audit). Voir CHANGELOG.md et docs/PROJECT_STATE.md.
Project Structure
apps/web— Frontend React 18 + Vite 5 + TypeScript strict (source of truth for the UI)veza-backend-api— Main Go 1.25 API service (Gin, GORM, Postgres, Redis, RabbitMQ, Elasticsearch). Handles REST, WebSocket, and chat (chat server was merged into this service in v0.502).veza-stream-server— Rust streaming server (Axum 0.8, Tokio 1.35, Symphonia) — HLS, HTTP Range, WebSocket, gRPCveza-common— Shared Rust types and loggingpackages/design-system— Shared design tokens
See CLAUDE.md for the full architecture map.
Development Setup
Prerequisites: Node 20 (see .nvmrc), Go, Rust, Docker. Configure .env from .env.example.
# Verify environment
make doctor
./scripts/validate-env.sh development
# Install dependencies
make install-deps
# Option A — Backend in Docker + Web local
make dev
# Option B — All apps local with hot reload (infra from docker-compose.dev.yml)
make dev-full
# Option C — Infra only, then run services manually
docker compose -f docker-compose.dev.yml up -d
make dev-web # or make dev-backend-api, make dev-stream-server
See docs/ENV_VARIABLES.md for required variables. make build builds all services.
Quick Start
Frontend only
cd apps/web
npm install
npm run dev
Docker Production
Canonical production compose file: docker-compose.prod.yml
docker compose -f docker-compose.prod.yml up -d
See make/config.mk for COMPOSE_PROD and deployment docs.
CI/CD
- Badge : CI status above. Set
SLACK_WEBHOOK_URL(Incoming Webhook) in repo secrets to receive Slack notifications on failure.
Disabled workflows
- Storybook (
chromatic.yml.disabled,storybook-audit.yml.disabled,visual-regression.yml.disabled): deferred until MSW is wired up for/api/v1/auth/meand/api/v1/logs/frontend, which currently causes ~1 400 network errors in the Storybook build. The npm scripts (storybook,build-storybook) still work locally for one-off component inspection. To reactivate in CI, fix the MSW handlers and rename the three files back to.yml.
Documentation
- Developer Onboarding — Setup, architecture, conventions, troubleshooting
- Documentation index — Index complet de la documentation
- See
docs/for detailed architecture and development guides. Older audits and reports are archived indocs/archive/.