Provisionnement

Ce que le moteur installe à l'étape Infrastructure.

L'étape Infrastructure est celle où tout est assemblé sur l'hôte. Le moteur installe, en séquence, avec une progression transmise en direct :

• k3s — Kubernetes léger et de qualité production (s'étend au multi-nœud par la suite).
• Ingress (Traefik) + cert-manager — routage et TLS automatique via Let's Encrypt.
• PostgreSQL et Redis in-cluster — la base de données définitive et la file/pub-sub de logs.
• Le registre d'artefacts et les Runners de CI.
• Le runtime serverless du Déploiement.
• Les images définitives de api et web (déploiement + migrations + seed du super administrateur en tant que Jobs in-cluster).

Runners de CI#

Les jobs de pipeline s'exécutent comme des pods isolés sur le cluster — un pod par job, avec ses propres limites CPU/mémoire, si bien qu'un job lourd ne peut jamais affamer la plateforme ni ses voisins. La capacité est dérivée du cluster lui-même (en réservant toujours de la marge pour le control plane) : les jobs au-delà du plafond attendent dans la file, et ajouter un nœud à la fleet augmente automatiquement la capacité de CI.

Ajuster la capacité#

Le calcul est un bon défaut, pas un verdict : dans Paramètres → Plateforme → Capacité CI, vous décidez quelle part de la machine le runner peut prendre, et chaque modification montre ce qu'elle donnerait sur ce cluster avant d'être enregistrée.

Deux réglages comptent le plus. La réserve de la plateforme est la part de chaque nœud que le CI ne touche jamais : la baisser donne plus au CI au total, mais davantage de créneaux se partagent alors la mémoire, et chaque job peut finir plus petit. Et le « ne pas démarrer en dessous de » est un plancher d'admission : le plafond d'un job est figé à la création de son pod, si bien qu'une baisse passagère de mémoire libre peut imposer à un build de deux heures une limite sous laquelle il n'aboutit pas. Sous ce plancher, le nœud n'offre aucun créneau et le job attend dans la file — tard vaut mieux qu'infirme.