View a markdown version of this page

Umgebungsvariablen mit einem Task-Prolog injizieren - Amazon SageMaker KI

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Umgebungsvariablen mit einem Task-Prolog injizieren

Sie können einen Task-Prolog verwenden, um automatisch Umgebungsvariablen in Ihre Jobs einzufügen, ohne Ihre Job-Skripte zu ändern. Ein Slurm Task-Prolog ist ein Skript, das vor dem Start einer Aufgabe ausgeführt wird. Es wird in derselben Umgebung wie die Aufgabe ausgeführt. Das Task-Prolog schreibt jede Variable in die Standardausgabe als export NAME=value und Slurm legt diese Variablen in der Umgebung der Aufgabe fest.

Slurmunterstützt nur einen einzigen TaskProlog Eintrag inslurm.conf. HyperPod AMIs werden so konfiguriertTaskProlog, dass sie auf ein Dispatcher-Skript verweisen. Dadurch bleibt der einzige Eintrag für mehrere Funktionen und Ihre eigenen Anpassungen verfügbar.

Der Dispatcher führt jedes ausführbare *.sh Skript in einem Drop-In-Verzeichnis aus. Die entsprechende HyperPod AMI-Konfiguration lautet wie folgt:

  • slurm.confSätzeTaskProlog=/opt/slurm/etc/task_prolog.sh.

  • /opt/slurm/etc/task_prolog.shist ein Dispatcher, der jedes ausführbare *.sh Skript, das er findet, in /opt/slurm/etc/task_prolog.d/ der Reihenfolge der Dateinamen ausführt. Wenn das Verzeichnis leer ist oder fehlt, unternimmt der Dispatcher nichts und wird erfolgreich beendet.

  • /opt/slurm/etc/task_prolog.d/ist das Drop-In-Verzeichnis für die Skripts, die der Dispatcher ausführt. Das AMI erstellt dieses Verzeichnis als unterstützten Speicherort für Ihre Skripts zur Injektion von Umgebungsvariablen.

Da Sie Root-Zugriff auf HyperPod Clusterknoten haben, können Sie es slurm.conf direkt bearbeiten.

Wenn Sie den TaskProlog Eintrag ändern, wird das Einfügen von Umgebungsvariablen gestoppt

Wenn Sie den TaskProlog=/opt/slurm/etc/task_prolog.sh Eintrag entfernen oder neu verweisen, wird der Dispatcher nicht mehr ausgeführt. Jedes HyperPod Feature, das darauf angewiesen ist, Umgebungsvariablen einzufügen (z. B. die Erfassung von Observability-Metriken), erhält diese Variablen nicht mehr. Damit diese Funktionen weiterhin funktionieren, fügen Sie Ihre eigenen Skripts hinzu, /opt/slurm/etc/task_prolog.d/ anstatt den Eintrag zu ändern.

Bei containerisierten Jobs wird das Task-Prolog innerhalb des Containers ausgeführt. HyperPodkonfiguriert Enroot Bind-Mounts unter /etc/enroot/mounts.d/ so, dass das Dispatcher-Skript und das task_prolog.d/ Verzeichnis in Containern verfügbar sind. Pyxis

Container-Images müssen Bash enthalten

Da der Task-Prolog-Dispatcher ein bash Skript ist, das innerhalb des Containers ausgeführt wird, müssen Container-Images für Ihre Jobs die bash Shell unter enthalten. /bin/bash Andernfalls schlägt der Task-Prolog fehl und der Job wird mit einem Fehler beendet.

Wenn Sie ein benutzerdefiniertes AMI erstellen, erbt es diese Task-Prolog-Konfiguration vom Basis-AMI. HyperPod Behalten Sie den TaskProlog Eintrag und das /opt/slurm/etc/task_prolog.d/ Verzeichnis in Ihrem benutzerdefinierten AMI bei, damit der Dispatcher verfügbar bleibt. Weitere Hinweise zu benutzerdefinierten AMIs finden Sie unterBenutzerdefinierte Amazon Machine Images (AMIs) für Cluster SageMaker HyperPod.

Fügen Sie Ihr eigenes Task-Prolog-Skript hinzu

Sie können ausführbare Skripts hinzufügen, /opt/slurm/etc/task_prolog.d/ um Umgebungsvariablen in Ihre Jobs einzufügen. Der Dispatcher führt diese Skripts in aufsteigender Reihenfolge nach Dateinamen aus. HyperPod kann seine eigenen Skripte in diesem Verzeichnis installieren. Um Ihr Skript nach ihnen auszuführen, verwenden Sie ein hohes numerisches Präfix, wie 900_ z. B. Wenn zwei Skripts dieselbe Variable exportieren, wird der Wert aus dem Skript wirksam, das später ausgeführt wird.

Gehen Sie folgendermaßen vor, um Ihr eigenes Task-Prolog-Skript hinzuzufügen:

  1. Erstellen Sie /opt/slurm/etc/task_prolog.d/ auf jedem Rechenknoten ein ausführbares Skript. Geben Sie der Datei ein numerisches Präfix, um ihre Reihenfolge festzulegen, zum Beispiel900_my_env.sh. Schreiben Sie jede Umgebungsvariable in die Standardausgabe im Formular export NAME=value und senden Sie jede andere Ausgabe an den Standardfehler.

    $ sudo tee /opt/slurm/etc/task_prolog.d/900_my_env.sh > /dev/null <<'EOF' #!/bin/bash echo "export MY_CUSTOM_VAR=my_value" EOF $ sudo chmod +x /opt/slurm/etc/task_prolog.d/900_my_env.sh
  2. Stellen Sie sicher, dass Ihre Variable in einen Job auf dem Host eingefügt wird.

    $ srun bash -c 'env | grep MY_CUSTOM_VAR' MY_CUSTOM_VAR=my_value
  3. Wenn Sie containerisierte Jobs ausführen, stellen Sie sicher, dass Ihre Variable auch in einen Pyxis Container eingefügt wird.

    $ srun --container-image=docker/image:tag bash -c 'env | grep MY_CUSTOM_VAR' MY_CUSTOM_VAR=my_value
Skripts bleiben nicht bestehen, wenn ein Knoten ersetzt wird

Skripts, die Sie direkt platzieren, /opt/slurm/etc/task_prolog.d/ sind für jeden Knoten lokal und werden nicht beibehalten, wenn ein Knoten ersetzt wird (z. B. bei der automatischen Wiederaufnahme). Damit Ihre Skripts auch bei Node-Ersetzungen nicht verloren gehen, installieren Sie sie mithilfe eines Lifecycle-Skripts, sodass sie bei der Bereitstellung eines Knotens erneut angewendet werden. Weitere Informationen zu Lifecycle-Skripten für Slurm finden Sie unter. Anpassen von SageMaker HyperPod Clustern mithilfe von Lebenszyklusskripten