Provisionierung

Was die Engine im Schritt Infrastruktur installiert.

Der Schritt Infrastruktur ist der Ort, an dem alles auf dem Host aufgebaut wird. Die Engine installiert nacheinander, mit live übertragenem Fortschritt:

• k3s — leichtgewichtiges und produktionsreifes Kubernetes (skaliert später auf Multi-Node).
• Ingress (Traefik) + cert-manager — Routing und automatisches TLS via Let's Encrypt.
• PostgreSQL und Redis in-cluster — die endgültige Datenbank und die Queue/Pub-Sub für Logs.
• Registry für Artefakte und die CI-Runner.
• Serverless-Laufzeit des Deployments.
• Die endgültigen Images von api und web (Deployment + Migrationen + Seed des Super-Admins als In-Cluster-Jobs).

CI-Runner#

Pipeline-Jobs laufen als isolierte Pods im Cluster — ein Pod pro Job, mit eigenen CPU-/Speicher-Limits, sodass ein schwerer Job weder die Plattform noch seine Nachbarn aushungern kann. Die Kapazität wird aus dem Cluster selbst abgeleitet (mit stets reserviertem Spielraum für die Control Plane): Jobs jenseits der Obergrenze warten in der Queue, und ein neuer Node in der Fleet erhöht die CI-Kapazität automatisch.

Jeder Container im Pod eines Jobs ist begrenzt — der Job selbst, seine services:-Sidecars und der Docker-Daemon pro Job tragen explizite Obergrenzen, und jedes Scratch-Volume hat eine feste Größengrenze. Ein außer Kontrolle geratener Job verdrängt so sich selbst, statt den Node unter Druck zu setzen. Das timeout-minutes des Jobs wird außerdem direkt auf den Pod gestempelt: Selbst wenn der Plattform-Prozess mitten im Job stirbt, räumt der Cluster den Pod von allein ab.

Kapazität einstellen#

Die Ableitung ist ein guter Standard, kein Urteil: Unter Einstellungen → Plattform → CI-Kapazität entscheiden Sie, wie viel der Maschine der Runner nehmen darf — jede Änderung zeigt vorab, was sie auf diesem Cluster einbringt.

Zwei Regler wiegen am schwersten. Die Plattform-Reserve ist der Anteil jedes Knotens, den der CI nie anfasst: Senken gibt dem CI insgesamt mehr, doch dann teilen mehr Plätze den Speicher, und jeder Job kann kleiner ausfallen. Und „nicht starten unter" ist eine Aufnahmegrenze: Die Obergrenze eines Jobs wird beim Anlegen des Pods festgeschrieben, deshalb kann ein kurzer Einbruch des freien Speichers einem zweistündigen Build ein Limit verpassen, unter dem er nicht fertig wird. Unterhalb der Grenze bietet der Knoten keinen Platz und der Job wartet in der Warteschlange — spät ist besser als verkrüppelt.

Die Reserve hat zudem eine absolute Untergrenze — mindestens 2 Kerne und 3 GiB bleiben bei der Control Plane, egal was der Prozentsatz sagt (auf sehr kleinen Hosts senkt sie sich selbstständig ab). Ein dedizierter Runner-Node, auf dem keine Plattform läuft, kann die Untergrenze über EQS_RUNNER_MIN_PLATFORM_RESERVE_CPU / EQS_RUNNER_MIN_PLATFORM_RESERVE_MEMORY_GI auf null setzen.

Logs und Aufbewahrung#

Ein einzelner Step darf bis zu 50.000 Log-Zeilen speichern (EQS_RUNNER_MAX_LOG_LINES_PER_STEP; 0 hebt die Grenze auf). Jenseits der Grenze läuft der Step bis zu seinem echten Ende weiter — ein unübersehbarer Kürzungsmarker wird geschrieben und weitere Ausgabe verworfen, was Datenbank und Live-Stream vor einem außer Kontrolle geratenen set -x schützt.

Step-Logs verfallen nach 90 Tagen (EQS_CI_LOG_RETENTION_DAYS; 0 bewahrt sie für immer auf). Runs, Jobs, Ergebnisse und Annotationen bleiben erhalten — die Historie bleibt einsehbar, nur die rohe Mitschrift läuft ab. Auch der Blob-Garbage-Collector und der Retention-Runner der Registry sind standardmäßig aktiv (jeweils abwählbar per EQS_REGISTRY_*_ENABLED=false): Nicht mehr referenzierte Blobs werden von selbst freigegeben, und eine auf der Artefakte-Seite gespeicherte Aufbewahrungsrichtlinie läuft einfach.

Der eigene Anteil der Plattform#

Die Plattform bemisst ihre eigenen Pods am Host — Datenbank, api und web deklarieren Resource Requests, die bei der Installation abgeleitet (und von Updates nachgetragen) werden. Unter Last entscheidet der Kernel so zugunsten der Plattform, statt einen CI-Job und die Datenbank als Gleichrangige zu behandeln. Pro Komponente übersteuerbar über Variablen im Stil von EQS_PG_CPU_REQUEST, wenn Sie Ihre Maschine besser kennen als die Formel.