docs(arch): align INFRASTRUCTURE + PLATFORM_ARCHITECTURE to cluster split (#7)
ci / shared (push) Successful in 11s
ci / shared (push) Successful in 11s
Same 4 VMs / flavors / SLA. 3 Orca clusters (was 1), 1 cluster per plane: breakpilot-edge (Identity + Infra), breakpilot-control (Control), breakpilot-app (App, prod + stage VMs). vm-data → vm-app-prod; stage VM → vm-app-stage. Data plane → App plane. KC co-tenant on vm-edge with JVM heap pinned. Companions: PR #6 here (impl plan) + orca-platform PR #6 (cluster manifests).
This commit was merged in pull request #7.
This commit is contained in:
+34
-20
@@ -1,10 +1,12 @@
|
||||
# Platform Architecture — B2B Customer Portal
|
||||
**Status:** Design Draft
|
||||
**Authors:** Sharang, Benjamin
|
||||
**Date:** 2026-05-11
|
||||
**Status:** Design Draft
|
||||
**Authors:** Sharang, Benjamin
|
||||
**Date:** 2026-05-11 (cluster split: 2026-06-30)
|
||||
|
||||
---
|
||||
|
||||
> **2026-06-30 cluster-split decision.** The four-plane vocabulary in this document still applies as the **SLA + ownership abstraction**. What changed is the operational shape: planes are now hosted by **three Orca clusters** (one cluster per plane, with Identity and Infra co-tenant in the same cluster on a single VM). The "Data plane" is renamed **App plane** to reflect that it carries product workloads, not just data stores. Cluster repos: `platform/breakpilot-edge` (Identity + Infra), `platform/breakpilot-control` (Control), `platform/breakpilot-app` (App, with prod + stage VMs). Multi-VM rollout is gated on the legal entity being established. See `INFRASTRUCTURE.md §1`, `IMPLEMENTATION_PLAN.md §1.1 / M1.2`, and `platform/orca-platform/clusters/README.md` for the operational details.
|
||||
|
||||
## 1. Vision
|
||||
|
||||
We sell CERTifAI and breakpilot-compliance as modular B2B building blocks. Customers buy one or both and operate them inside a unified customer portal — without needing to understand that they are separate products under the hood.
|
||||
@@ -28,24 +30,32 @@ Out of scope: breakpilot-dataroom, breakpilot-lehrer, breakpilot-pitch-deck.
|
||||
|
||||
## 3. The Four Planes
|
||||
|
||||
Four logical planes — but only **three Orca clusters**. Identity and Infra are co-tenant in the `breakpilot-edge` cluster on `vm-edge` per the 2026-06-30 cluster-split decision. The plane abstraction owns SLA and audit responsibilities; the cluster abstraction owns operational concerns (failure domain, backup policy, CI scope, IaC repo).
|
||||
|
||||
```
|
||||
╔══════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 1 — IDENTITY (logical root, all auth flows through here) ║
|
||||
╚══════════════════════════════════════════════════════════════════╝
|
||||
╔══════════════════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 1 — IDENTITY cluster: breakpilot-edge VM: vm-edge ║
|
||||
║ (logical root, all auth flows through here) ║
|
||||
╚══════════════════════════════════════════════════════════════════════════════╝
|
||||
↓ JWT
|
||||
╔══════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 2 — CONTROL (portal + ERPNext + tenant registry) ║
|
||||
╚══════════════════════════════════════════════════════════════════╝
|
||||
╔══════════════════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 2 — CONTROL cluster: breakpilot-control VM: vm-control ║
|
||||
║ (portal + ERPNext + tenant registry) ║
|
||||
╚══════════════════════════════════════════════════════════════════════════════╝
|
||||
↓ tenant-scoped API calls
|
||||
╔══════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 3 — DATA (CERTifAI + breakpilot-compliance) ║
|
||||
╚══════════════════════════════════════════════════════════════════╝
|
||||
╔══════════════════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 3 — APP (was DATA) cluster: breakpilot-app VMs: vm-app-prod ║
|
||||
║ (CERTifAI + breakpilot-compliance + data stores) + vm-app-stage║
|
||||
╚══════════════════════════════════════════════════════════════════════════════╝
|
||||
↓ everything runs on
|
||||
╔══════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 4 — INFRA (Orca + VMs + Gitea + Infisical + LiteLLM) ║
|
||||
╚══════════════════════════════════════════════════════════════════╝
|
||||
╔══════════════════════════════════════════════════════════════════════════════╗
|
||||
║ PLANE 4 — INFRA cluster: breakpilot-edge VM: vm-edge (co-tenant) ║
|
||||
║ (Orca + Gitea + Infisical + PowerDNS + Orca-Proxy) ║
|
||||
╚══════════════════════════════════════════════════════════════════════════════╝
|
||||
```
|
||||
|
||||
Stage and prod share the same App cluster on different VMs (`vm-app-stage` and `vm-app-prod`). Stage authenticates via the prod Identity plane (`auth.breakpilot.com`) and reads tenant config from the prod Control plane (`tenant-registry`) under `tenant.kind = "stage"` — Identity and Control are **not** duplicated for stage.
|
||||
|
||||
---
|
||||
|
||||
## 4. Plane 1 — Identity
|
||||
@@ -305,7 +315,9 @@ all real-tenant flows work otherwise same flows, same code paths
|
||||
|
||||
---
|
||||
|
||||
## 6. Plane 3 — Data
|
||||
## 6. Plane 3 — App (was "Data")
|
||||
|
||||
Renamed 2026-06-30. The plane carries product workloads end-to-end (dashboards, APIs, AI services) as well as the data stores those products own — "App" reflects the full surface, not just the storage tier. SLA targets are unchanged (CERTifAI ≥ 99.5%, compliance ≥ 99.5%, RPO ≤ 6h–24h per data class). Lives in the `breakpilot-app` cluster on `vm-app-prod` (prod) and `vm-app-stage` (stage).
|
||||
|
||||
### CERTifAI
|
||||
|
||||
@@ -334,10 +346,12 @@ GDPR and AI-Act compliance automation platform. After updates, tenant identity c
|
||||
|
||||
## 7. Plane 4 — Infra
|
||||
|
||||
**Orchestration:** Orca manages all containers on Hetzner VMs
|
||||
**Secrets:** Infisical — every service has a machine identity, pulls its own secrets at startup
|
||||
**CI/CD:** Gitea Actions → Docker build → push to private registry → Orca redeploy webhook
|
||||
**Routing:** Orca-Proxy handles all TLS termination and subdomain routing
|
||||
Co-tenant with the **Identity plane** in the `breakpilot-edge` cluster on `vm-edge`. Single-VM core per the 2026-06-30 cluster-split decision. Keycloak JVM heap is pinned (`-Xmx1500m`) so it cannot starve PowerDNS / Infisical. Escape hatch if the heap fight shows up post-launch: peel Keycloak onto its own VM inside the same cluster — no schema migration, just a `placement.node` flip.
|
||||
|
||||
**Orchestration:** Orca manages all containers on SysEleven VMs. Per-node ingress (every node binds 80/443 and runs its own ACME), one Orca cluster per plane (3 clusters total), one IaC repo per cluster (`platform/breakpilot-{edge,control,app}`).
|
||||
**Secrets:** Infisical — every service has a machine identity, pulls its own secrets at startup
|
||||
**CI/CD:** Gitea Actions → Docker build → push to private registry → Orca redeploy webhook (one CI/release cadence per cluster repo, plus per-product repos for the deployed services)
|
||||
**Routing:** Orca-Proxy handles TLS termination and subdomain routing on each node (no central proxy SPOF)
|
||||
|
||||
```
|
||||
Orca-Proxy routing table:
|
||||
|
||||
Reference in New Issue
Block a user