Instalacja¶

Tenax to jeden chart Helm i jeden obraz. Obraz zawiera plik binarny tenax oraz narzędzia klienckie Postgres 15/16/17 i MySQL 8.4 uruchamiane przez movery danych; ten sam plik binarny jest też CLI.

Pobierz obraz i chart¶

Wydania są budowane wyłącznie z tagów: tag v1.2.3 publikuje obraz <registry>/tenax/tenax:v1.2.3, chart tenax:1.2.3 (OCI) oraz pliki binarne CLI dla Linux i macOS w wydaniu na GitHub. Z main nic nie jest publikowane.

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

Z lokalnej kopii repozytorium helm install tenax charts/tenax … działa tak samo.

Minimalne wartości¶

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 nie dostarcza żadnych wartości domyślnych specyficznych dla organizacji: każdy endpoint, nazwę hosta i dane uwierzytelniające ustawiasz sam (ADR 0002). Wszystkie wartości: Wartości Helm.

Uwierzytelnianie i udostępnianie¶

Oba są wymienne i domyślnie wyłączone.

Ustawienie	Wartości	Co robi
`auth.provider`	`none` · `cloudflare-access`	`none`: każde żądanie do konsoli dostaje `auth.devRole` (konsola jest dostępna tylko przez `tenax console`, czyli kubectl port-forward). `cloudflare-access`: weryfikuje JWT Cloudflare Access przy każdym żądaniu i mapuje użytkowników i grupy na role; port-forwardy dostają `auth.portForwardRole`.
`auth.roles`	`viewer` · `operator` · `restorer` · `restorer-admin`	Kto może przeglądać, wykonywać kopie zapasowe i przywracać do piaskownicy, przywracać do nowej bazy danych lub do pobrania oraz przywracać w miejscu lub przypinać.
`expose.provider`	`none` · `service` · `cloudflare`	Jak dostać się do piaskownic spoza klastra: `none`, `tenax sandbox connect` robi port-forward przez kubeconfig; `service`, Service Kubernetes dla każdej piaskownicy (load balancer, MetalLB, Tailscale, external-dns), z którym dowolny klient bazy danych łączy się przez TLS; `cloudflare`, tunel za logowaniem Access. Zobacz Piaskownice.
`expose.cloudflared.enabled`	`true` / `false`	Z `cloudflare`: uruchamia konektor `cloudflared` dla tras piaskownic (oraz konsoli, jeśli ustawiono `consoleHostname`).

Szczegóły znajdziesz w Konsola, CLI i dostęp.

Co zostaje zainstalowane¶

Obiekt	Przeznaczenie
6 CRD	`BackupStore`, `BackupPolicy`, `BackupTarget`, `Backup`, `Restore`, `Sandbox` (dokumentacja)
Deployment `tenax-controller` (2 repliki, wybór lidera)	planuje kopie zapasowe, uruchamia streamery, przywracania, piaskownice, weryfikację i odśmiecanie
Deployment `tenax-api` (2 repliki) i Service	konsola, API JSON i server-sent events
RBAC	odczyt zasobów Tenax w całym klastrze; w każdym namespace celu wyłącznie odczyt secretów `tenax-*`
PrometheusRule, ServiceMonitor, dashboard Grafana	opcjonalne, zobacz Monitorowanie

Pody działają bez roota, z głównym systemem plików tylko do odczytu, bez eskalacji uprawnień i ze wszystkimi odrzuconymi capabilities. Dane przenoszą wyłącznie Joby (movery, restorery) i Deploymenty streamerów dla poszczególnych celów; kontroler i API nigdy nie przenoszą danych kopii zapasowych.

Aktualizacje¶

helm upgrade zastępuje CRD (installCRDs: true) i wykonuje rollout kontrolera i API. Trwające kopie zapasowe kończą się lub są ponawiane: każda ścieżka danych jest crash-only, a kopia zapasowa istnieje dopiero wtedy, gdy jej manifest zostanie zapisany.