arcodangeandClaude Opus 5
aabedb0f3f
Trois questions indépendantes, tranchées lors du branchement de Kadans sur MinIO (2026-07-26) : qui déclare les buckets d'une app, qui détient les identifiants capables de les créer, et comment l'app lit les siens. La décision de fond est du fondateur : CHACUN SON PÉRIMÈTRE. Une application déclare ses buckets depuis son propre dépôt ; `tools` fournit le serveur, un module de standardisation et un compte de provisionnement — pas la liste. Une première version faisait tout porter par l'infra partagée : à ce rythme, chaque bucket de chaque app devenait une PR sur le dépôt commun. L'ADR consigne aussi les trois identités et leurs portées (root / provisionneur / compte de service), pourquoi la lecture des identifiants est une propriété inconditionnelle de la plateforme plutôt qu'une déclaration par app, et pourquoi les octets ne transitent pas par l'API — avec les conséquences que ça impose (endpoint public, CORS aux origines exactes, pas de basic-auth sur l'ingress S3). Les alternatives écartées sont listées avec leur motif, dont deux que j'avais moi-même proposées et qui étaient plus faibles. Deux limites assumées y figurent : le provisionneur est un secret PARTAGÉ entre rôles CI (sa compromission permet de créer des buckets, pas de lire des objets), et les noms d'actions d'administration MinIO n'ont pas été éprouvés contre le serveur au moment d'écrire. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Arcodange Factory
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'rough':true } }%%
flowchart
prepare_hd>HD setup]
prepare_pg>PG Setup]
prepare_gitea>Gitea Setup]
origin_repo[[original repositories]]
github_repo_m[[gitea mirrors]]
gitlab_repo_m[[gitea mirrors]]
origin_repo -. mirrored .->gitlab_repo_m
origin_repo -. mirrored .->github_repo_m
tofu.state -. manages providers/go-gitea .- origin_repo
tofu.state -. manages providers/gitlabhq/gitlab .- gitlab_repo_m
tofu.state -. manages providers/integrations/github .- github_repo_m
subgraph Home
subgraph pi1
runner[/gitea runners\]
subgraph small HD
backup_data
end
end
subgraph pi2
PG[(Postgres)]
subgraph Gitea
origin_repo
end
subgraph HD
PG_data
Gitea_data
end
end
subgraph pi3
subgraph ai
ollama
end
end
subgraph "master (macbook pro)"
ansible{{ansible control-node}}
tofu{{opentofu control-node}}
subgraph ansible_scripts
direction TB
prepare_hd --> prepare_pg --> prepare_gitea
end
end
end
subgraph Internet
subgraph Gitlab
subgraph Group Arcodange
gitlab_repo_m
end
end
subgraph Github
subgraph Organization Arcodange
github_repo_m
end
end
subgraph GCP
subgraph project arcodange
subgraph gs://arcodange-tf
tofu.state
end
end
end
end
tofu == plan/apply ==> tofu.state
ansible == deploy ==> HD
ansible == deploy ==> PG
ansible == deploy ==> Gitea
ansible --- ansible_scripts
classDef done fill:gold,stroke:indigo,stroke-width:4px,color:blue;
class prepare_hd,nodeId2 done;
Documentation
- 📚
doc/— ADR (décisions d'architecture) + runbooks. - 🚀 Runbook : mettre en service une nouvelle application web — dépôt Gitea, base de données, Vault, chart Helm, Terraform, CI, ArgoCD.
🏹💻🪽