4 Commits

Include renames

Author	SHA1	Message	Date
arcodangeandClaude Opus 5	0e1b6e1062	refactor(minio) — lever la restriction « un seul bucket par app » ... « Pourquoi sommes-nous restreints sur les buckets ? » (fondateur, 26/07) — parce que JE l'avais décidé, pour rendre tout dérivable d'un seul nom. Rien ne l'imposait, et la restriction aurait mordu au pas suivant : l'ADR-018 de Kadans prévoit DEUX paliers de transfert (aperçu 240p régénérable, travail 360p à garder), donc deux cycles de vie, donc potentiellement deux buckets aux politiques de purge différentes. Chaque bucket déclare désormais son app (`app: kadans`). C'est toujours la SEULE déclaration, au même endroit — mais le nom du bucket redevient libre, et `kadans-videos` retrouve un nom qui dit ce qu'il contient. Le compte de service devient par APP et non par bucket : une seule clé, autorisée sur tous ses buckets et eux seuls. Ajouter un bucket à une app existante ne crée donc aucune nouvelle clé — le compte existant gagne l'accès. Le secret porte `MINIO_BUCKETS` (tous) en plus de `MINIO_BUCKET` (le premier), pour que l'app n'ait pas à les redéclarer de son côté. Un bucket sans `app:` est ignoré plutôt que de faire échouer le plan : il n'aura simplement pas de compte de service, ce qui se voit immédiatement et ne casse rien d'existant. Vérifié sur le VRAI fichier, pas en théorie : le groupement rend bien {"kadans" = ["kadans-videos"]}, et avec un second bucket de la même app, {"kadans" = ["kadans-videos", "kadans-apercus"]} — le cas ADR-018 exact. tofu fmt propre, tofu validate réussi. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA	2026-07-26 09:46:32 +02:00
arcodangeandClaude Opus 5	287e3dcf1e	refactor(minio) — le BUCKET est la seule déclaration : plus de liste à tenir ... « Je ne vois pas le mal à donner la permission de lire sur un chemin qui n'existe pas. Je préfère ne pas m'embêter avec consumers ou autre. » (fondateur, 26/07) `var.consumers` disparaît. Le plan LIT `values.yaml` du chart — le même fichier qu'Helm consomme — et provisionne un compte de service par bucket. Créer un bucket EST la déclaration : il devient impossible d'avoir un bucket sans son compte, ou un compte sans son bucket. Une liste de plus aurait été une liste à tenir synchronisée, donc une liste à oublier. La convention qui rend ça possible : UN BUCKET PAR APP, NOMMÉ COMME ELLE. Le bucket passe donc de `kadans-videos` à `kadans`. Il est VIDE aujourd'hui — le renommer maintenant ne coûte rien ; dans un mois ce serait une migration. Tout en découle sans être écrit ailleurs : le compte `<app>-app` borné à ce seul bucket, le secret `kvv2/minio/<app>`, et la lecture que `app_policy` accorde déjà à toute app sur `kvv2/data/minio/<son nom>`. Vérifié plutôt que supposé : `yamldecode` lit bien ce values.yaml, ancres YAML comprises (testé en isolation avant d'écrire le plan). tofu fmt propre, tofu validate réussi. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA	2026-07-26 09:38:24 +02:00
arcodangeandClaude Opus 5	4ca4a05370	feat(minio) — un compte de service par app consommatrice, borné à son bucket ... « On peut adopter ce pattern à toutes les apps qui pourraient avoir besoin de MinIO, et ainsi modifier les app roles / app policy générique. » (fondateur, 26/07) Bonne nouvelle : les modules centraux n'ont PAS eu à changer. `kv_read_paths` existe déjà dans `app_policy` et fait exactement ça — l'ERP s'en sert pour lire les creds GCS de Longhorn. Le motif générique était donc à moitié construit ; il manquait la moitié MinIO. CE QUI EST AJOUTÉ : `minio/iac/consumers.tf` provisionne, pour chaque app déclarée dans `var.consumers`, une politique MinIO bornée à SON bucket (GetObject/PutObject/DeleteObject sur les objets, ListBucket sur le bucket seul — ni les autres buckets, ni l'administration), un compte de service, et écrit ses clés dans `kvv2/minio/<app>`. POURQUOI LES CLÉS VIVENT CHEZ MINIO ET PAS CHEZ L'APP : seul ce pipeline possède les identifiants ROOT. Si chaque app créait son propre compte de service, il faudrait donner ce root à chaque rôle CI — c'est-à-dire à tout le monde. Ici il ne sort jamais d'ici, et l'app ne reçoit qu'une clé qui ne peut rien lire d'autre que son bucket. Un compte de service qui fuite ne donne accès qu'aux objets qu'il gérait déjà. Ajouter une app = trois lignes déclaratives, documentées au README : son bucket dans values.yaml, son entrée dans `var.consumers`, son `kv_read_paths` au tfvars central. Aucun module à toucher. Le provider parle à `s3.arcodange.fr` — l'endpoint PUBLIC, parce que le runner CI n'est pas dans le LAN et que `.lab` ne s'y résout pas. C'est l'exposition HTTPS mergée ce matin qui rend ce plan applicable. ⚠ Erreur attrapée par le validateur, et corrigée : je relisais `kvv2/minio/config` alors que `local.config` de main.tf porte déjà les identifiants root — une lecture qui aurait créé une dépendance circulaire avec l'écriture faite par ce même plan. Vérifié : `tofu fmt` propre, `tofu validate` réussi (avec TERRAFORM_VAULT_AUTH_JWT posé — sans lui, le provider Vault échoue déjà sur main, ce n'est pas mon fait). Je n'ai lancé AUCUN apply : c'est le workflow qui le fera, et la revue t'appartient. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA	2026-07-26 09:12:09 +02:00
arcodangeandClaude Opus 5	84edfc8640	feat(minio) — stockage objet S3 du homelab (brique partagée de tools) ... Le fondateur : « on déploie MinIO dans le repo tools du homelab non ? » — oui, c'est bien le pattern : le dossier tools/ porte les briques PARTAGÉES (pgbouncer, clickhouse, grafana…) et le namespace tools les fait tourner ; les charts applicatifs vivent dans le repo de leur app. Décidé de longue date côté produit, jamais déployé : ADR-012 « MinIO local d'abord » (bascule R2 à 100+ utilisateurs / 10 To par mois), ADR-013 (le gratuit reste local-first, MinIO sert les paliers payants). Vérifié avant d'écrire : aucun pod ni service MinIO dans le cluster. Le chart suit la recette du repo (dépendance à la library "tool" + chart amont en SubChart, deux gardes dans templates/) : - mode STANDALONE, 1 réplique : ce qui transite est DÉRIVÉ (le master d'une vidéo reste sur l'appareil de son propriétaire, ADR-018) et Longhorn réplique déjà le volume — l'erasure coding distribué coûterait de la RAM que des Pi 5 n'ont pas à dépenser pour ça ; - 50 Gi sur longhorn ≈ 250 h de cours au palier « travail » (360p, 3,4 Mo/min) ; ⚠ Longhorn réplique : compter ×3 sur la capacité avant d'augmenter ; - ressources bornées (512 Mi / 2 Gi) : la limite protège les voisins de tools ; - API s3.arcodange.lab + console minio.arcodange.lab (Traefik) ; - bucket kadans-videos PRIVÉ — l'accès passera par des URL signées (ADR-0002) ; - identifiants JAMAIS au dépôt : iac/ les génère dans Vault (kvv2/minio/config), le Vault Secrets Operator les matérialise, le chart les lit via existingSecret. Le SA du pod est nommé "minio" (pas le "minio-sa" amont) car le module app_roles borne l'authentification au SA portant le nom de l'app. ⚠ Le workflow minio.yaml écrit ses triggers EN TOUTES LETTRES : une ancre YAML dans un trigger Gitea Actions fait taire push ET pull_request en silence (vécu sur arcodange/kadans, issues 113→117). Les workflows plausible/crowdsec/vault de ce repo en utilisent encore — à vérifier séparément, c'est probablement pourquoi ils ne partent qu'à la main. Vérifié : helm dependency update + helm template (11 ressources rendues, SA et VaultAuth cohérents) + helm lint ✓. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA	2026-07-25 16:49:34 +02:00