Schnellere Image-Pulls und strengere Isolation für STACKIT Runner
Abschnitt betitelt „Schnellere Image-Pulls und strengere Isolation für STACKIT Runner“Am 12. November 2026 aktualisieren wir die STACKIT Runner von STACKIT Git Pipelines. Runner-Jobs laden die von uns angebotenen Basis-Images aus einem internen Cache, und Docker-Operationen, die privilegierten Zugriff auf den Runner-Host benötigen, sind nicht mehr erlaubt. Dadurch werden Image-Pulls schneller und konsistenter, und Jobs sind stärker voneinander getrennt.
Basis-Images werden aus einem internen Cache geladen
Abschnitt betitelt „Basis-Images werden aus einem internen Cache geladen“Die Runner laden die von STACKIT angebotenen Basis-Container-Images aus einem Cache in einer internen Registry. Dadurch wartet ein Job kürzer auf sein Image. Die STACKIT Container Registry ist die Upstream-Quelle des Caches. Kann der Cache ein Image nicht bereitstellen, lädt der Runner es aus der STACKIT Container Registry, sodass Pulls auch bei hohem Datenverkehr weiterlaufen.
Da die Basis-Images als geprüfte Kopien aus unserer eigenen Registry stammen, sind Ihre Jobs nicht von den Rate Limits externer Registries betroffen, und Ihre Builds laufen in einer konsistenten Umgebung.
Docker-Operationen mit Zugriff auf den Runner-Host werden abgelehnt
Abschnitt betitelt „Docker-Operationen mit Zugriff auf den Runner-Host werden abgelehnt“Um Jobs auf gemeinsam genutzten Runnern stärker voneinander zu trennen, lehnen die Runner Docker-Befehle ab, die einem Container privilegierten Zugriff auf den Runner-Host geben würden. Ein Job, der einen solchen Befehl ausführt, schlägt mit einer Fehlermeldung fehl, die mit Command denied by Stackit Classic runner security policy beginnt.
Folgende Operationen sind nicht mehr erlaubt:
- Privilegierte Container ausführen, zum Beispiel mit
docker run --privileged. - Linux Capabilities hinzufügen, zum Beispiel mit
docker run --cap-add=NET_ADMIN. - Den Prozess- oder IPC-Namespace des Hosts mit
--pid=hostoder--ipc=hostteilen. - Pfade des Runner-Hosts wie
/,/etc,/proc,/sys,/dev,/varoder/runoder darunterliegende Pfade einbinden. Dazu gehört auch das Einbinden des Docker-Sockets mit-v /var/run/docker.sock:/var/run/docker.sock.
Images mit docker build und docker buildx build bauen, Images pullen und pushen sowie unprivilegierte Container ausführen, die den Workspace, /tmp oder benannte Docker Volumes einbinden, funktioniert weiterhin wie bisher.
Wenn Ihre Pipeline auf eine der oben genannten Operationen angewiesen ist, wenden Sie sich an unser STACKIT Help Center.
Behebung der Checkout-Race-Condition
Abschnitt betitelt „Behebung der Checkout-Race-Condition“Wir haben ein intermittierendes Problem behoben, bei dem gleichzeitige Git-Operationen beim Klonen von Actions Fehler verursachten, durch die der Job abbrach. Workflows sollten bei Checkout-Schritten nun nicht mehr unerwartet fehlschlagen.
Basis-Image für den Cache anfragen
Abschnitt betitelt „Basis-Image für den Cache anfragen“Wir nehmen weitere Basis-Images in den Cache auf. Wenn Ihre Workflows ein Standard-Basis-Image benötigen, fragen Sie es über unser STACKIT Help Center an und geben Sie Folgendes an:
- Den Namen des Images. Wir nehmen nur Anfragen für offizielle Images an.
- Die genauen Tags, die Sie benötigen, zum Beispiel
ubuntu:22.04odernode:20-alpine.
Wenn Sie Fragen haben, steht Ihnen unser STACKIT Help Center jederzeit zur Verfügung.
Einbindung des Action-Caches
Abschnitt betitelt „Einbindung des Action-Caches“Wir befüllen unseren vorab aufgewärmten Action-Cache aktiv, um die Laufzeiten von Schritten so kurz wie möglich zu halten. Wenn Ihre Workflows auf benutzerdefinierte, interne oder nicht standardmäßige Actions angewiesen sind, die auf unseren Runner-Images vorab im Cache gespeichert werden sollen, antworten Sie hier bitte mit dem Action-Repository und dem Versions-Tag (z. B. owner/action-name@vX). Wir werden häufig angefragte Actions evaluieren und in den Pool für den vorgewärmten Cache aufnehmen.