No description
5153ab113d
The 12-record DNS plan ($1 per record at the registrar but only one
public R720 IP) forces the obvious : a single HAProxy on :443 must
serve staging.veza.fr + veza.fr + www.veza.fr + talas.fr +
www.talas.fr + forgejo.talas.group all at once. Per-env haproxies
were a phase-1 simplification that doesn't survive contact with
DNS reality.
Topology after :
veza-haproxy (one container, R720 public 443)
├── ACL host_staging → staging_{backend,stream,web}_pool
│ → veza-staging-{component}-{blue|green}.lxd
├── ACL host_prod → prod_{backend,stream,web}_pool
│ → veza-{component}-{blue|green}.lxd
├── ACL host_forgejo → forgejo_backend → 10.0.20.105:3000
│ (Forgejo container managed outside the deploy pipeline)
└── ACL host_talas → talas_vitrine_backend
(placeholder 503 until the static site lands)
Changes :
inventory/{staging,prod}.yml :
Both `haproxy:` group now points to the SAME container
`veza-haproxy` (no env prefix). Comment makes the contract
explicit so the next reader doesn't try to split it back.
group_vars/all/main.yml :
NEW : haproxy_env_prefixes (per-env container prefix mapping).
NEW : haproxy_env_public_hosts (per-env Host-header mapping).
NEW : haproxy_forgejo_host + haproxy_forgejo_backend.
NEW : haproxy_talas_hosts + haproxy_talas_vitrine_backend.
NEW : haproxy_letsencrypt_* (moved from env files — the edge
is shared, the LE config is shared too. Else the env
that ran the haproxy role last would clobber the
domain set).
group_vars/{staging,prod}.yml :
Strip the haproxy_letsencrypt_* block (now in all/main.yml).
Comment points readers there.
roles/haproxy/templates/haproxy.cfg.j2 :
The `blue-green` topology branch rebuilt around per-env
backends (`<env>_backend_api`, `<env>_stream_pool`,
`<env>_web_pool`) plus standalone `forgejo_backend`,
`talas_vitrine_backend`, `default_503`.
Frontend ACLs : `host_<env>` (hdr(host) -i ...) selects
which env's backends to use ; path ACLs (`is_api`,
`is_stream_seg`, etc.) refine within the env.
Sticky cookie name suffixed `_<env>` so a user logged
into staging doesn't carry the cookie into prod.
Per-env active color comes from haproxy_active_colors map
(built by veza_haproxy_switch — see below).
Multi-instance branch (lab) untouched.
roles/veza_haproxy_switch/defaults/main.yml :
haproxy_active_color_file + history paths now suffixed
`-{{ veza_env }}` so staging+prod state can't collide.
roles/veza_haproxy_switch/tasks/main.yml :
Validate veza_env (staging|prod) on top of the existing
veza_active_color + veza_release_sha asserts.
Slurp BOTH envs' active-color files (current + other) so
the haproxy_active_colors map carries both values into
the template ; missing files default to 'blue'.
playbooks/deploy_app.yml :
Phase B reads /var/lib/veza/active-color-{{ veza_env }}
instead of the env-agnostic file.
playbooks/cleanup_failed.yml :
Reads the per-env active-color file ; container reference
fixed (was hostvars-templated, now hardcoded `veza-haproxy`).
playbooks/rollback.yml :
Fast-mode SHA lookup reads the per-env history file.
Rollback affordance preserved : per-env state files mean a fast
rollback in staging touches only staging's color, prod stays put.
The history files (`active-color-{staging,prod}.history`) keep
the last 5 deploys per env independently.
Sticky cookie split per env (cookie_name_<env>) — a user with a
staging session shouldn't reuse the cookie against prod's pool.
Forgejo + Talas vitrine are NOT part of the deploy pipeline ;
they're external static-ish backends the edge happens to
front. haproxy_forgejo_backend is "10.0.20.105:3000" today
(matches the existing Incus container at that address).
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .forgejo/workflows | ||
| .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/.