Niklas Ye
ca2cd2c645
A self-contained demo kit: a TerdutServer against a throwaway, bare Postgres (bring-your-own DSN -- simplest path to stand up from nothing, ROADMAP.md Stage 1's own note), two TerdutTeams, and each team's own TerdutEscalationRule/TerdutDeadmanSwitch/TerdutAlertSource, so every CRD this operator manages is exercised together rather than in isolation the way config/samples' one-of-each already does. fire-alerts.sh sends terdut-server's own amPayload/amAlert shape (read from internal/api/alertmanager.go in that repo, not guessed from its docs) at whichever TerdutAlertSource's generated webhook Secret it reads the key out of -- high-cpu/disk-full/pod-crash scenarios to open and resolve incidents, and a heartbeat scenario matching each team's dead man's switch matcher, so stopping it demonstrates the switch noticing silence on its own. Verified server-side (kubectl apply --dry-run=server -k examples/demo) against this operator's own dev cluster, which already has these CRDs installed: every object validates. The one warning that cluster's "restricted" PodSecurity raises (postgres:17-alpine's entrypoint needs to start as root before it drops privileges itself) is noted inline in 00-postgres.yaml rather than worked around -- not a real production pattern, and this Postgres exists only to be thrown away with the rest of the demo namespace. README.md walks through: applying, watching status, why a few early CrashLoopBackOff restarts on terdut-demo itself are expected (this operator's Deployment template has no wait-for-postgres init container yet, unlike charts/terdut-server's chart as of v0.33.2), reaching the web UI (port-forward -- spec.networking.hostname is accepted but nothing creates an HTTPRoute for it yet), turning on open signup with the operator's own generated admin token since the bootstrap-created account has no password, firing alerts, and tearing down.
45 lines
1.6 KiB
Markdown
45 lines
1.6 KiB
Markdown
# Terdut operator
|
|
|
|
Aims to expose most config as CRD's, so end users can self-service over gitops.
|
|
|
|
See [DESIGN.md](./DESIGN.md) for the full design: CRD catalog and specs,
|
|
reconciliation semantics, bootstrap/auth, Postgres integration, RBAC, and the
|
|
relationship to `charts/terdut-server`. This README stays a short pitch; the
|
|
open questions it used to carry are now resolved decisions there (§2).
|
|
|
|
## CRD's
|
|
|
|
### terdutServers
|
|
Creates a server — Deployment, Service, database wiring, bootstrap, operator
|
|
credentials, and `allowedTeams` consent for cross-namespace teams. See
|
|
DESIGN.md §4.1, §4.6.
|
|
|
|
### terdutTeams
|
|
- team name
|
|
- oidc groups
|
|
- `serverRef` — explicit reference to its `TerdutServer`, may be in a
|
|
different namespace (one team owns the server, others self-service a
|
|
team against it), gated by that `TerdutServer`'s own `allowedTeams`
|
|
field (DESIGN.md §2, §4.1, §4.2, §4.6)
|
|
|
|
### terdutEscalationrules
|
|
- rule
|
|
- `teamRef` — explicit reference to its `TerdutTeam` (DESIGN.md §2, §4.3)
|
|
|
|
### terdutDeadmansswitches
|
|
- rule
|
|
- `teamRef` (DESIGN.md §4.4)
|
|
|
|
### terdutAlertSources
|
|
- `teamRef` (DESIGN.md §4.5)
|
|
- URL/key are generated by the server at creation and surfaced only via a
|
|
generated Secret, never set explicitly
|
|
|
|
## Demo
|
|
|
|
[`examples/demo`](./examples/demo) wires one of every CRD above together
|
|
— two teams, each with an escalation rule, a dead man's switch and an
|
|
alert source — plus a script that fires synthetic Alertmanager webhooks
|
|
at it, so you can watch real incidents open, escalate and resolve without
|
|
a real Alertmanager anywhere in the picture.
|