Installation¶

Tenax besteht aus einem Helm-Chart und einem Image. Das Image enthält die Binärdatei tenax sowie die Client-Werkzeuge für Postgres 15/16/17 und MySQL 8.4, die die Datenmover ausführen; dieselbe Binärdatei ist die CLI.

Image und Chart beziehen¶

Releases werden nur aus Tags gebaut: Ein Tag v1.2.3 veröffentlicht das Image <registry>/tenax/tenax:v1.2.3, das Chart tenax:1.2.3 (OCI) und CLI-Binärdateien für Linux und macOS im GitHub-Release. Aus main wird nichts veröffentlicht.

helm install tenax oci://registry.example.com/helm/tenax --version 1.2.3 -n tenax-system --create-namespace \
  -f values.yaml

Aus einem Checkout funktioniert helm install tenax charts/tenax … genauso.

Minimale Werte¶

values.yaml

image:
  repository: registry.example.com/tenax/tenax
  tag: v1.2.3
  pullSecrets: [registry-pull]        # also copied into sandbox namespaces
targetNamespaces: [team-a, team-b]    # where BackupTargets and their tenax-* secrets live
examplePolicies:                      # prod, dev and critical presets in tenax-system
  enabled: true
  store: main
metrics:
  serviceMonitor: { enabled: true }
  prometheusRule: { enabled: true }
  grafanaDashboard: { enabled: true }

Tenax bringt keine organisationsspezifischen Standardwerte mit: Jeden Endpunkt, jeden Hostnamen und alle Zugangsdaten legen Sie selbst fest (ADR 0002). Alle Werte: Helm-Werte.

Authentifizierung und Erreichbarkeit¶

Beides ist austauschbar und standardmäßig ausgeschaltet.

Einstellung	Werte	Wirkung
`auth.provider`	`none` · `cloudflare-access`	`none`: Jede Konsolenanfrage erhält `auth.devRole` (die Konsole ist nur über `tenax console` erreichbar, einen kubectl-Port-Forward). `cloudflare-access`: prüft bei jeder Anfrage das Cloudflare-Access-JWT und ordnet Benutzer und Gruppen Rollen zu; Port-Forwards erhalten `auth.portForwardRole`.
`auth.roles`	`viewer` · `operator` · `restorer` · `restorer-admin`	Wer ansehen darf, wer sichern und in eine Sandbox wiederherstellen darf, wer in eine neue Datenbank oder einen Download wiederherstellen darf und wer an Ort und Stelle wiederherstellen oder anheften darf.
`expose.provider`	`none` · `service` · `cloudflare`	Wie Sandboxes von außerhalb des Clusters erreicht werden: `none`, `tenax sandbox connect` leitet Ports über die Kubeconfig weiter; `service`, ein Kubernetes-Service pro Sandbox (Load Balancer, MetalLB, Tailscale, external-dns), mit dem sich jeder Datenbank-Client über TLS verbindet; `cloudflare`, ein Tunnel hinter einem Access-Login. Siehe Sandboxes.
`expose.cloudflared.enabled`	`true` / `false`	Mit `cloudflare`: betreibt den `cloudflared`-Connector für die Sandbox-Routen (und die Konsole, wenn `consoleHostname` gesetzt ist).

Details finden Sie unter Konsole, CLI und Zugriff.

Was installiert wird¶

Objekt	Zweck
6 CRDs	`BackupStore`, `BackupPolicy`, `BackupTarget`, `Backup`, `Restore`, `Sandbox` (Referenz)
Deployment `tenax-controller` (2 Replicas, Leader Election)	plant Backups, betreibt Streamer, Wiederherstellungen, Sandboxes, Prüfung und Garbage Collection
Deployment `tenax-api` (2 Replicas) und Service	die Konsole, die JSON-API und Server-Sent Events
RBAC	clusterweites Lesen der Tenax-Ressourcen; pro Ziel-Namespace nur Lesen von `tenax-*`-Secrets
PrometheusRule, ServiceMonitor, Grafana-Dashboard	optional, siehe Monitoring

Pods laufen ohne Root-Rechte mit schreibgeschütztem Root-Dateisystem, ohne Rechteausweitung und ohne Capabilities. Daten bewegen sich nur in Jobs (Mover, Restorer) und in Streamer-Deployments pro Ziel; Controller und API transportieren nie Backup-Daten.

Upgrades¶

helm upgrade ersetzt die CRDs (installCRDs: true) und rollt Controller und API neu aus. Laufende Backups werden fertig oder neu versucht: Jeder Datenpfad ist crash-only, und ein Backup existiert erst, wenn sein Manifest geschrieben ist.