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.

Chaque conteneur du pod d'un job est borné — le job lui-même, ses sidecars services: et le daemon Docker propre au job portent tous des plafonds explicites, et chaque volume de scratch est plafonné en taille, de sorte qu'un job qui s'emballe s'évince lui-même au lieu de mettre le nœud sous pression. Le timeout-minutes du job est lui aussi estampillé sur le pod : même si le processus de la plateforme meurt en plein job, le cluster retire le pod de lui-même.

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.

La réserve a aussi un plancher absolu — au moins 2 cœurs et 3 Gio restent au control plane, quoi qu'en dise le pourcentage (il se réduit de lui-même sur les hôtes minuscules). Un nœud dédié aux runners, où ne tourne rien de la plateforme, peut ramener ce plancher à zéro via EQS_RUNNER_MIN_PLATFORM_RESERVE_CPU / EQS_RUNNER_MIN_PLATFORM_RESERVE_MEMORY_GI.

Logs et rétention#

Un même step peut stocker jusqu'à 50 000 lignes de log (EQS_RUNNER_MAX_LOG_LINES_PER_STEP ; 0 supprime le plafond). Au-delà du plafond, le step continue de tourner jusqu'à sa conclusion réelle — un marqueur de troncature bien visible est écrit et le reste de la sortie est ignoré, ce qui protège la base de données et le stream en direct d'un set -x qui s'emballe.

Les logs de step sont purgés au bout de 90 jours (EQS_CI_LOG_RETENTION_DAYS ; 0 les garde pour toujours). Les exécutions, les jobs, les conclusions et les annotations sont conservés — l'historique reste consultable, seule la transcription brute expire. Le garbage collector de blobs du registre et l'exécuteur de rétention sont eux aussi activés par défaut (chacun se désactive par son EQS_REGISTRY_*_ENABLED=false) : les blobs sans référence sont récupérés d'eux-mêmes, et une politique de rétention enregistrée dans l'écran Artefacts s'exécute tout simplement.

La part de la plateforme elle-même#

La plateforme dimensionne ses propres pods d'après l'hôte — base de données, api et web déclarent des resource requests dérivées à l'installation (et complétées après coup par les mises à jour), si bien que sous charge le noyau arbitre en faveur de la plateforme au lieu de mettre un job de CI et la base de données sur un pied d'égalité. Chaque composant se surcharge via des variables du style EQS_PG_CPU_REQUEST, quand vous connaissez votre machine mieux que la formule.