Docker-Setup

Unsere verschiedenen Track-Tools werden als Docker-Images bereitgestellt.

Jedes Tool braucht ein Dockerfile, das festlegt, wie die Maschine gebaut wird. Es sollte im Wurzelverzeichnis deines Repositorys liegen und Dockerfile heißen.

Das Dockerfile sollte das minimale Image erstellen, das das Tool braucht, um korrekt und schnell zu funktionieren. Auf unserer Best-Practices-Seite findest du viele Tipps, die dir dabei helfen.

Ausführung

Timeouts

Der Test-Runner bekommt für jede Lösung 20 Sekunden lang 100 % CPU und 3 GB Arbeitsspeicher. Nach 20 Sekunden wird der Prozess angehalten und meldet einen Timeout mit dem Fehlercode 408.

Note

Wir empfehlen dir dringend, unser Dokument zu Performance-Best-Practices zu befolgen, um die Wahrscheinlichkeit von Timeouts zu verringern.

Stdout/stderr

Ein Durchlauf eines Tools darf höchstens ein Megabyte an stdout und stderr erzeugen. Erzeugt es mehr, wird es mit dem Fehlercode 413 abgebrochen.

Die Inhalte von stdout und stderr aus jedem Durchlauf werden in Dateien gespeichert. Du kannst eine Datei results.out in das Ausgabeverzeichnis schreiben, die Debugging-Informationen enthält.

Caution

Derzeit können Maintainer den Inhalt dieser Dateien nicht einsehen.

Ergebnisse

Die Ergebnisdatei darf nicht größer als 500 Kilobyte sein (einschließlich eventueller Stacktraces usw.). Ist die Datei größer, wird der Tool-Lauf mit dem Fehlercode 460 abgebrochen.

Konfiguration

Jede Lösung bekommt 20 Sekunden lang 100 % der Maschinenressourcen. Nach 20 Sekunden wird der Prozess angehalten und als Timeout gemeldet.

Manche Tools brauchen (kleine) Abweichungen von der Standardkonfiguration. Wenn ja, werden sie in der tools.json-Datei im Repository des Tooling Invokers konfiguriert.

Netzwerk

Tools laufen ohne Internetzugang. Du kannst zwei verschiedene Konfigurationen verwenden:

  1. none. Das deaktiviert das Netzwerkgerät im Container.
  2. internal. Das fügt ein Netzwerkgerät im Container hinzu, aber das Netzwerk hat keinen Zugriff auf irgendetwas außerhalb.

Verschiedene Sprachen laufen mit verschiedenen Konfigurationen besser oder schlechter (z. B. Ruby ist mit none zweimal so schnell. Elixir ist mit internal 12x schneller.

Du kannst lokal experimentieren, indem du beim Ausführen deines Dockers das Flag --network verwendest. --network none wird standardmäßig unterstützt. Um das interne Netzwerk zu nutzen, führe zuerst docker network create --internal internal aus, um das Netzwerk zu erstellen, und verwende dann beim Ausführen des Containers --network internal.

Arbeitsspeicher

Sprachen können den maximalen Arbeitsspeicher festlegen, den sie zum Ausführen ihrer Jobs brauchen. Wenn du ihn so niedrig wie möglich setzt, können wir mehr Jobs schneller parallel ausführen. Außerdem bedeutet es, dass Leute, die den Speicher missbrauchen wollen, damit keinen Erfolg haben. Verschiedene Sprachen brauchen ganz unterschiedlich viel maximalen Arbeitsspeicher. Es ist ratsam und willkommen, die Ausführung eines Docker-Laufs zu benchmarken, um den maximalen Speicherverbrauch zu ermitteln.

Der Arbeitsspeicher sollte angegeben werden mit der Zahl und einem Suffix aus b, k, m, g, um Bytes, Kilobytes, Megabytes oder Gigabytes anzugeben.

Docker lokal ausführen

Du kannst die obigen Einstellungen mit diesem Befehl testen:

docker container run -v /path/to/job:/mnt/exercism-iteration --network none -m 1GB exercism/ruby-test-runner lasagna /mnt/exercism-iteration/ /mnt/exercism-iteration/

Ein Dockerfile bearbeiten

Alle Änderungen an Dockerfiles erfordern ein PR-Review vom Team @exercism/maintainers-admin, um die Einführung von Sicherheitslücken zu vermeiden.