« On déploie MinIO dans le repo tools du homelab non ? » — oui, et les faits le confirment : tools/ porte les briques partagées (pgbouncer, clickhouse, grafana, prometheus…) et le namespace tools fait tourner exactement ces composants. Les charts applicatifs, eux, vivent dans le repo de leur app.
Décidé de longue date côté produit, jamais déployé — vérifié avant d'écrire : aucun pod ni service MinIO dans le cluster.
ADR-012 « MinIO local d'abord » (bascule R2 aux seuils : 100+ utilisateurs, > 10 To/mois)
ADR-013 le gratuit reste local-first ; MinIO sert les paliers payants
ADR-018 ce qui transite est dérivé (aperçu 240p ~50 Ko · travail 360p ~3,4 Mo/min) — c'est ce qui dimensionne le volume
Le chart suit la recette du repo
Dépendance à la library tool + chart amont en SubChart, les deux gardes dans templates/, l'app déclarée dans chart/values.yaml pour qu'ArgoCD la crée.
Choix
Pourquoi
standalone, 1 réplique
la donnée est dérivée (le master d'une vidéo reste sur l'appareil de son propriétaire) 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 ». ⚠ Longhorn réplique : compter ×3 sur la capacité (mesuré : ~260 Go libres sur le nœud le plus juste)
requests 512 Mi/100 m · limit 2 Gi
la limite protège les voisins de tools, pas MinIO
s3.arcodange.lab + minio.arcodange.lab
API et console, via Traefik
bucket kadans-videosprivé
l'accès passera par des URL signées (ADR-0002 du dossier)
identifiants jamais au dépôt
iac/ les génère dans Vault (kvv2/minio/config) → Vault Secrets Operator → secret minio-config → existingSecret. Le SA du pod est nommé minio (et non le minio-sa amont) car le module app_roles borne l'authentification au SA portant le nom de l'app
Un piège évité, et un signalement
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). Or plausible.yaml, crowdsec.yaml et vault.yaml en utilisent encore : c'est probablement pourquoi ils ne partent qu'à la main (workflow_dispatch). À vérifier séparément — je ne les ai pas touchés dans cette PR.
« On déploie MinIO dans le repo tools du homelab non ? » — **oui**, et les faits le confirment : `tools/` porte les briques **partagées** (pgbouncer, clickhouse, grafana, prometheus…) et le namespace `tools` fait tourner exactement ces composants. Les charts applicatifs, eux, vivent dans le repo de leur app.
Décidé de longue date côté produit, **jamais déployé** — vérifié avant d'écrire : aucun pod ni service MinIO dans le cluster.
- [ADR-012](https://gitea.arcodange.lab/arcodange/kadans/src/branch/main/docs/adr/012-video-storage-minio-first.md) « MinIO local d'abord » (bascule R2 aux seuils : 100+ utilisateurs, > 10 To/mois)
- [ADR-013](https://gitea.arcodange.lab/arcodange/kadans/src/branch/main/docs/adr/013-video-storage-opfs-local-first.md) le gratuit reste local-first ; MinIO sert les paliers payants
- [ADR-018](https://gitea.arcodange.lab/arcodange/kadans/src/branch/main/docs/adr/018-qualite-video-au-transfert.md) ce qui transite est **dérivé** (aperçu 240p ~50 Ko · travail 360p ~3,4 Mo/min) — c'est ce qui dimensionne le volume
## Le chart suit la recette du repo
Dépendance à la library `tool` + chart amont en `SubChart`, les deux gardes dans `templates/`, l'app déclarée dans `chart/values.yaml` pour qu'ArgoCD la crée.
| Choix | Pourquoi |
|---|---|
| **standalone**, 1 réplique | la donnée est **dérivée** (le master d'une vidéo reste sur l'appareil de son propriétaire) 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 ». ⚠ Longhorn réplique : compter **×3** sur la capacité (mesuré : ~260 Go libres sur le nœud le plus juste) |
| requests 512 Mi/100 m · limit 2 Gi | la limite protège les **voisins** de `tools`, pas MinIO |
| `s3.arcodange.lab` + `minio.arcodange.lab` | API et console, via Traefik |
| bucket `kadans-videos` **privé** | l'accès passera par des **URL signées** (ADR-0002 du dossier) |
| identifiants **jamais au dépôt** | `iac/` les génère dans Vault (`kvv2/minio/config`) → Vault Secrets Operator → secret `minio-config` → `existingSecret`. Le SA du pod est nommé **`minio`** (et non le `minio-sa` amont) car le module `app_roles` borne l'authentification au SA portant le nom de l'app |
## Un piège évité, et un signalement
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). Or `plausible.yaml`, `crowdsec.yaml` et `vault.yaml` en utilisent encore : c'est probablement pourquoi ils ne partent qu'à la main (`workflow_dispatch`). **À vérifier séparément** — je ne les ai pas touchés dans cette PR.
## Vérifications
`helm dependency update` ✓ · `helm template` ✓ (11 ressources rendues, SA et VaultAuth cohérents) · `helm lint` ✓ (0 échec).
## Mise en service (ordre important)
1. Appliquer l'IaC (workflow **MinIO** à la main, ou `tofu apply` dans `minio/iac`) — crée le rôle Vault et **génère** le mot de passe root.
2. ArgoCD synchronise l'application.
3. `kubectl -n tools get vaultstaticsecret minio` puis `get pods -l app=minio`.
Sans le secret, le pod ne démarre pas — **c'est voulu** : mieux vaut un pod en attente qu'un MinIO ouvert avec des identifiants par défaut.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
« On déploie MinIO dans le repo tools du homelab non ? » — oui, et les faits le confirment :
tools/porte les briques partagées (pgbouncer, clickhouse, grafana, prometheus…) et le namespacetoolsfait tourner exactement ces composants. Les charts applicatifs, eux, vivent dans le repo de leur app.Décidé de longue date côté produit, jamais déployé — 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 enSubChart, les deux gardes danstemplates/, l'app déclarée danschart/values.yamlpour qu'ArgoCD la crée.longhorntools, pas MinIOs3.arcodange.lab+minio.arcodange.labkadans-videosprivéiac/les génère dans Vault (kvv2/minio/config) → Vault Secrets Operator → secretminio-config→existingSecret. Le SA du pod est nomméminio(et non leminio-saamont) car le moduleapp_rolesborne l'authentification au SA portant le nom de l'appUn piège évité, et un signalement
Le workflow
minio.yamlécrit ses triggers en toutes lettres. Une ancre YAML dans un trigger Gitea Actions fait tairepushETpull_request, en silence — vécu surarcodange/kadans(issues 113 → 117). Orplausible.yaml,crowdsec.yamletvault.yamlen utilisent encore : c'est probablement pourquoi ils ne partent qu'à la main (workflow_dispatch). À vérifier séparément — je ne les ai pas touchés dans cette PR.Vérifications
helm dependency update✓ ·helm template✓ (11 ressources rendues, SA et VaultAuth cohérents) ·helm lint✓ (0 échec).Mise en service (ordre important)
tofu applydansminio/iac) — crée le rôle Vault et génère le mot de passe root.kubectl -n tools get vaultstaticsecret miniopuisget pods -l app=minio.Sans le secret, le pod ne démarre pas — c'est voulu : mieux vaut un pod en attente qu'un MinIO ouvert avec des identifiants par défaut.
🤖 Generated with Claude Code