Skip to main content

Funktionsweise

Auf hoher Ebene funktioniert ein Template-Build wie folgt:
  1. Die Template-Quelle auflösen, z. B. ein Standard-Basis-Image, ein vorhandenes Image, ein Dockerfile oder ein anderes Template.
  2. Template-Anweisungen anwenden, z. B. runCmd, copy, makeDir, setEnvs und Hilfsfunktionen zur Paketinstallation.
  3. Falls konfiguriert, den Startbefehl des Templates starten.
  4. Warten, bis der Ready-Befehl erfolgreich ist.
  5. Die vorbereitete Umgebung als wiederverwendbares Template speichern.
Der Build erzeugt eine templateId / template_id und eine buildId / build_id. Verwende die Template-ID später mit Sandbox.create(...).

Benutzer und Arbeitsverzeichnis

Templates können den standardmäßigen Linux-Benutzer und das Arbeitsverzeichnis festlegen, die von späteren Build-Schritten und von der finalen Umgebung verwendet werden. Verwende setUser(...) / set_user(...), wenn Build-Befehle als bestimmter Benutzer ausgeführt werden müssen. Verwende setWorkdir(...) / set_workdir(...), wenn spätere Befehle und kopierte Dateien relativ zu einem bestimmten Verzeichnis aufgelöst werden sollen.
Wenn du diese Werte nicht festlegst, verwendet die Sandbox die Standardwerte des ausgewählten Basis-Images.

Caching

Template-Builds cachen zuvor abgeschlossene Layer, sodass wiederholte Builds nicht jede Anweisung erneut ausführen müssen. Das ist normalerweise das gewünschte Verhalten für schnelle Iterationen. Wenn du einen vollständig frischen Build benötigst, deaktiviere den Cache für den gesamten Build mit skipCache: true / skip_cache=True, oder markiere die Template-Kette mit skipCache() / skip_cache().
Setze Cache-Busting bewusst ein. Es verlangsamt Builds und sollte normalerweise für das Aktualisieren von Abhängigkeiten, Debugging oder Änderungen an Eingaben reserviert werden, die nicht allein aus der Template-Definition ersichtlich sind.
Zuletzt geändert am 10. August 2026