9f819df4d9
Establish the design foundation for the heleosv2 multi-tenant hosting platform before any implementation code: - Monorepo skeleton: docs/, platform-infra/, site-templates/, deployments/, control-panel/ with orientation READMEs. - docs/: roadmap index, architecture + threat model, naming conventions, site profiles, provisioning workflow, backup & DR runbook, repo/GitOps layout, and the approved architecture plan. - docs/adr/: 9 ADRs recording the rationale for single-host Compose, Traefik edge, nginx+fpm split, shared MariaDB, ZFS-per-customer, decoupled backup streams, Forgejo, CLI-first, and SFTP-only. - Secrets hygiene: .gitignore (only *.enc.* committed) and .gitattributes (LF for scripts/Dockerfiles/YAML run on the Linux host). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
# ADR 0004 — Shared MariaDB instance, per-site DB + user
|
||
|
||
**Status:** Accepted
|
||
|
||
## Context
|
||
Two models: (a) a MariaDB container per customer — strong isolation, aligns with
|
||
per-customer ZFS snapshots, but ~100–300 MB idle RAM each; or (b) one shared
|
||
MariaDB instance with a separate database and least-privilege user per site —
|
||
RAM-efficient via a shared buffer pool, but the live datadir is shared.
|
||
|
||
## Decision
|
||
Run **one shared MariaDB** instance. Each site gets its **own database and its
|
||
own least-privilege user**. The instance's datadir lives on a dedicated platform
|
||
ZFS dataset, not inside any customer dataset.
|
||
|
||
## Consequences
|
||
- ✅ Efficient memory use (shared buffer pool) — favours density on one host.
|
||
- ✅ Per-site DB users mean a compromised site's credentials expose only that
|
||
site's database.
|
||
- ❌ The live datadir cannot be snapshotted per-customer atomically with their
|
||
files — addressed by decoupling DB backups (see
|
||
[ADR 0006](0006-decoupled-backup-streams.md)): per-database dumps via
|
||
automysqlbackup give per-customer restore granularity.
|
||
- ⚠️ The shared instance is a shared-fate component (a crash or bad query can
|
||
affect all sites) and a noisy-neighbour surface — mitigate with tuning and,
|
||
later, `mysqld_exporter` monitoring. Revisit per-customer DB if a tenant needs
|
||
strong isolation or a different engine/version.
|