Instalação¶

O Tenax é um chart do Helm e uma imagem. A imagem contém o binário tenax mais as ferramentas cliente do Postgres 15/16/17 e do MySQL 8.4 que os movimentadores de dados executam; o mesmo binário é a CLI.

Obter a imagem e o chart¶

As releases são geradas apenas a partir de tags: uma tag v1.2.3 publica a imagem <registry>/tenax/tenax:v1.2.3, o chart tenax:1.2.3 (OCI) e os binários da CLI para Linux e macOS na release do GitHub. Nada é publicado a partir de main.

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

A partir de um checkout, helm install tenax charts/tenax … funciona da mesma forma.

Valores mínimos¶

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 }

O Tenax não traz padrões específicos de nenhuma organização: cada endpoint, hostname e credencial é você quem define (ADR 0002). Todos os valores: Valores do Helm.

Autenticação e exposição¶

Ambas são plugáveis e vêm desativadas por padrão.

Configuração	Valores	O que faz
`auth.provider`	`none` · `cloudflare-access`	`none`: toda requisição ao console recebe `auth.devRole` (o console só é acessado via `tenax console`, um kubectl port-forward). `cloudflare-access`: verifica o JWT do Cloudflare Access em cada requisição e mapeia usuários e grupos para papéis; port-forwards recebem `auth.portForwardRole`.
`auth.roles`	`viewer` · `operator` · `restorer` · `restorer-admin`	Quem pode visualizar; fazer backup e restaurar em um sandbox; restaurar em um banco novo ou em um download; e restaurar no lugar ou fixar.
`expose.provider`	`none` · `service` · `cloudflare`	Como os sandboxes são acessados de fora do cluster: `none`, `tenax sandbox connect` faz port-forward pelo kubeconfig; `service`, um Service do Kubernetes por sandbox (load balancer, MetalLB, Tailscale, external-dns) ao qual qualquer cliente de banco se conecta via TLS; `cloudflare`, um túnel atrás de um login do Access. Veja Sandboxes.
`expose.cloudflared.enabled`	`true` / `false`	Com `cloudflare`: executa o conector `cloudflared` para as rotas dos sandboxes (e do console, se `consoleHostname` estiver definido).

Veja Console, CLI e acesso para os detalhes.

O que é instalado¶

Objeto	Finalidade
6 CRDs	`BackupStore`, `BackupPolicy`, `BackupTarget`, `Backup`, `Restore`, `Sandbox` (referência)
Deployment `tenax-controller` (2 réplicas, eleição de líder)	agenda backups, executa streamers, restaurações, sandboxes, verificação e coleta de lixo
Deployment `tenax-api` (2 réplicas) e Service	o console, a API JSON e os server-sent events
RBAC	leitura dos recursos do Tenax em todo o cluster; por namespace de alvo, leitura apenas dos secrets `tenax-*`
PrometheusRule, ServiceMonitor, dashboard do Grafana	opcionais, veja Monitoramento

Os pods rodam como não root, com sistema de arquivos raiz somente leitura, sem escalonamento de privilégios e com todas as capabilities removidas. Os dados só trafegam em Jobs (movers, restorers) e em Deployments de streamer por alvo; o controlador e a API nunca carregam dados de backup.

Atualizações¶

helm upgrade substitui os CRDs (installCRDs: true) e reinicia gradualmente o controlador e a API. Backups em andamento terminam ou são repetidos: todo caminho de dados é crash-only, e um backup só existe depois que o manifesto dele é gravado.