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. # Jobs erstellen, um sie an Deadline Cloud einzureichen Sie reichen Jobs mithilfe von Jobpaketen an Deadline Cloud ein. Ein Job-Bundle ist eine Sammlung von Dateien, einschließlich einer Jobvorlage mit einer [Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) und allen Asset-Dateien, die zum Rendern des Jobs benötigt werden. Die Jobvorlage beschreibt, wie Worker die Assets verarbeiten und darauf zugreifen, und stellt das Skript bereit, das der Worker ausführt. Job-Pakete ermöglichen es Künstlern, technischen Direktoren und Pipeline-Entwicklern, komplexe Jobs einfach von ihren lokalen Workstations oder der lokalen Renderfarm aus an Deadline Cloud zu senden. Jobpakete sind besonders nützlich für Teams, die an groß angelegten Projekten mit visuellen Effekten, Animationen oder anderen Medienrendering-Projekten arbeiten, die skalierbare Rechenressourcen auf Abruf benötigen. Sie können das Auftragspaket mithilfe des lokalen Dateisystems zum Speichern von Dateien und eines Texteditors zum Erstellen der Auftragsvorlage erstellen. Nachdem Sie das Paket erstellt haben, reichen Sie den Job entweder mit der Deadline Cloud-CLI oder einem Tool wie einem Deadline Cloud-Submitter an Deadline Cloud ein Sie können Ihre Ressourcen in einem Dateisystem speichern, das von Ihren Mitarbeitern gemeinsam genutzt wird, oder Sie können Deadline Cloud-Jobanhänge verwenden, um das Verschieben von Assets in S3-Buckets zu automatisieren, wo Ihre Mitarbeiter darauf zugreifen können. Jobanhänge helfen auch dabei, die Ergebnisse Ihrer Jobs zurück auf Ihre Workstations zu übertragen. Die folgenden Abschnitte enthalten detaillierte Anweisungen zum Erstellen und Einreichen von Job-Bundles an Deadline Cloud. **Topics** + [Vorlagen für offene Stellenbeschreibungen (OpenJD) für Deadline Cloud](build-job-bundle.md) + [Dateien in Ihren Jobs verwenden](using-files-in-your-jobs.md) + [Verwenden Sie Jobanhänge, um Dateien zu teilen](build-job-attachments.md) + [Ressourcenlimits für Jobs erstellen](build-job-limits.md) + [So reichen Sie einen Job bei Deadline Cloud ein](submit-jobs-how.md) + [Jobs in Deadline Cloud planen](build-jobs-scheduling.md) + [Einen Job in Deadline Cloud ändern](build-jobs-modifying.md) # Vorlagen für offene Stellenbeschreibungen (OpenJD) für Deadline Cloud Ein *Job-Bundle* ist eines der Tools, mit denen Sie Jobs für AWS Deadline Cloud definieren. Sie gruppieren eine [OpenJD-Vorlage (Open Job Description)](https://github.com/OpenJobDescription/openjd-specifications) mit zusätzlichen Informationen wie Dateien und Verzeichnissen, die Ihre Jobs mit Stellenanhängen verwenden. Sie verwenden die Deadline Cloud-Befehlszeilenschnittstelle (CLI), um ein Job-Bundle zu verwenden, um Jobs für die Ausführung in einer Warteschlange einzureichen. Ein Job-Bundle ist eine Verzeichnisstruktur, die eine OpenJD-Jobvorlage, andere Dateien, die den Job definieren, und jobspezifische Dateien enthält, die als Eingabe für Ihren Job benötigt werden. Sie können die Dateien, die Ihren Job definieren, entweder als YAML- oder JSON-Dateien angeben. Die einzige erforderliche Datei ist entweder `template.yaml` oder`template.json`. Sie können auch die folgenden Dateien einschließen: ``` /template.yaml (or template.json) /asset_references.yaml (or asset_references.json) /parameter_values.yaml (or parameter_values.json) /other job-specific files and directories ``` Verwenden Sie ein Job-Bundle für benutzerdefinierte Job-Übermittlungen mit der Deadline Cloud-CLI und einem Jobanhang, oder Sie können eine grafische Einreichungsoberfläche verwenden. Im Folgenden finden Sie beispielsweise das Blender-Beispiel von GitHub. Um das Beispiel mit dem folgenden Befehl [im Blender-Beispielverzeichnis](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles) auszuführen: ``` deadline bundle gui-submit blender_render ``` ![\[Ein Beispiel für eine benutzerdefinierte Schnittstelle zur Einreichung von Jobs für Blender.\]](http://docs.aws.amazon.com/de_de/deadline-cloud/latest/developerguide/images/blender_submit_shared_settings.png) Das Fenster mit den auftragsspezifischen Einstellungen wird aus den `userInterface` Eigenschaften der Jobparameter generiert, die in der Jobvorlage definiert sind. Um einen Job über die Befehlszeile einzureichen, können Sie einen Befehl verwenden, der dem folgenden ähnelt ``` deadline bundle submit \ --yes \ --name Demo \ -p BlenderSceneFile=location of scene file \ -p OutputDir=file pathe for job output \ blender_render/ ``` Oder Sie können die `deadline.client.api.create_job_from_job_bundle` Funktion im `deadline` Python-Paket verwenden. Alle in Deadline Cloud enthaltenen Plug-ins für Job-Einreicher, wie das Autodesk Maya-Plugin, generieren ein Job-Bundle für Ihre Einreichung und verwenden dann das Deadline Cloud-Python-Paket, um Ihren Job bei Deadline Cloud einzureichen. Sie können die eingereichten Job-Bundles im Job-Verlaufsverzeichnis Ihrer Workstation oder mithilfe eines Absenders einsehen. Sie können Ihr Job-Verlaufsverzeichnis mit dem folgenden Befehl finden: ``` deadline config get settings.job_history_dir ``` Wenn Ihr Job auf einem Deadline Cloud-Worker ausgeführt wird, hat er Zugriff auf Umgebungsvariablen, die ihm Informationen über den Job liefern. Die Umgebungsvariablen sind: | Variablenname | Available (Verfügbar) | | --- | --- | | DEADLINE\$1FARM\$1ID | Alle Aktionen | | DEADLINE\$1FLOTTENNUMMER | Alle Aktionen | | DEADLINE\$1WORKER-ID | Alle Aktionen | | DEADLINE\$1WARTESCHLANGEN-ID | Alle Aktionen | | DEADLINE\$1JOB-ID | Alle Aktionen | | DEADLINE\$1STEP-ID | Aktionen der Aufgabe | | DEADLINE\$1SESSION\$1ID | Alle Aktionen | | DEADLINE\$1TASK\$1ID | Aktionen der Aufgabe | | DEADLINE\$1SESSIONACTION\$1ID | Alle Aktionen | **Topics** + [Jobvorlagenelemente für Jobpakete](build-job-bundle-template.md) + [Aufgabenteilung für Jobvorlagen](build-job-bundle-chunking.md) + [Parameterwerte, Elemente für Job-Bundles](build-job-bundle-parameters.md) + [Asset-Referenzen, Elemente für Job-Bundles](build-job-bundle-assets.md) # Jobvorlagenelemente für Jobpakete Die Jobvorlage definiert die Laufzeitumgebung und die Prozesse, die als Teil eines Deadline Cloud-Jobs ausgeführt werden. Sie können Parameter in einer Vorlage erstellen, sodass sie verwendet werden kann, um Jobs zu erstellen, die sich nur in den Eingabewerten unterscheiden, ähnlich wie bei einer Funktion in einer Programmiersprache. Wenn Sie einen Job an Deadline Cloud senden, wird er in allen Warteschlangenumgebungen ausgeführt, die auf die Warteschlange angewendet wurden. Warteschlangenumgebungen werden mithilfe der Spezifikation für externe Umgebungen von Open Job Description (OpenJD) erstellt. Einzelheiten finden Sie in der [Environment-Vorlage](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#12-environment-template) im OpenJD-Repository GitHub . Eine Einführung in die Erstellung eines Jobs mit einer OpenJD-Jobvorlage finden Sie unter [Einführung in die Erstellung eines Jobs](https://github.com/OpenJobDescription/openjd-specifications/wiki/Introduction-to-Creating-a-Job) im GitHub OpenJD-Repository. Zusätzliche Informationen finden Sie unter [Wie Jobs ausgeführt werden](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run). Es gibt Beispiele für Jobvorlagen im `samples` Verzeichnis des GitHub OpenJD-Repositorys. Sie können die Jobvorlage entweder im YAML-Format (`template.yaml`) oder im JSON-Format (`template.json`) definieren. Die Beispiele in diesem Abschnitt werden im YAML-Format angezeigt. Die Jobvorlage für das `blender_render` Beispiel definiert beispielsweise einen Eingabeparameter `BlenderSceneFile` als Dateipfad: ``` - name: BlenderSceneFile type: PATH objectType: FILE dataFlow: IN userInterface: control: CHOOSE_INPUT_FILE label: Blender Scene File groupLabel: Render Parameters fileFilters: - label: Blender Scene Files patterns: ["*.blend"] - label: All Files patterns: ["*"] description: > Choose the Blender scene file to render. Use the 'Job Attachments' tab to add textures and other files that the job needs. ``` Die `userInterface` Eigenschaft definiert das Verhalten automatisch generierter Benutzeroberflächen sowohl in der Befehlszeile, die den Befehl verwendet, als auch in den Plug-ins für die Auftragsübermittlung für Anwendungen wie Autodesk Maya. `deadline bundle gui-submit` In diesem Beispiel ist das UI-Widget zur Eingabe eines Werts für den `BlenderSceneFile` Parameter ein Dialogfeld zur Dateiauswahl, in dem nur Dateien angezeigt werden. `.blend` ![\[Ein Benutzeroberflächen-Widget zur Eingabe des Szenendateiparameters für eine OpenJD-Jobvorlage.\]](http://docs.aws.amazon.com/de_de/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png) Weitere Beispiele für die Verwendung des `userInteface` Elements finden Sie im Beispiel [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) im Repository unter. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub Die `dataFlow` Eigenschaften `objectType` und steuern das Verhalten von Job-Anhängen, wenn Sie einen Job aus einem Job-Bundle einreichen. In diesem Fall `dataFlow:IN` bedeuten `objectType: FILE` und, dass der Wert von eine Eingabedatei für Jobanhänge `BlenderSceneFile` ist. Im Gegensatz dazu hat die Definition des `OutputDir` Parameters `objectType: DIRECTORY` und`dataFlow: OUT`: ``` - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT userInterface: control: CHOOSE_DIRECTORY label: Output Directory groupLabel: Render Parameters default: "./output" description: Choose the render output directory. ``` Der Wert des `OutputDir` Parameters wird von Job-Anhängen als Verzeichnis verwendet, in das der Job Ausgabedateien schreibt. Weitere Informationen zu den `dataFlow` Eigenschaften `objectType` und finden Sie [JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)in der [Spezifikation Open Job Description](https://github.com/OpenJobDescription/openjd-specifications) Der Rest des Beispiels für eine `blender_render` Jobvorlage definiert den Arbeitsablauf des Jobs als einen einzelnen Schritt, wobei jedes Bild in der Animation als separate Aufgabe gerendert wird: ``` steps: - name: RenderBlender parameterSpace: taskParameterDefinitions: - name: Frame type: INT range: "{{Param.Frames}}" script: actions: onRun: command: bash # Note: {{Task.File.Run}} is a variable that expands to the filename on the worker host's # disk where the contents of the 'Run' embedded file, below, is written. args: ['{{Task.File.Run}}'] embeddedFiles: - name: Run type: TEXT data: | # Configure the task to fail if any individual command fails. set -xeuo pipefail mkdir -p '{{Param.OutputDir}}' blender --background '{{Param.BlenderSceneFile}}' \ --render-output '{{Param.OutputDir}}/{{Param.OutputPattern}}' \ --render-format {{Param.Format}} \ --use-extension 1 \ --render-frame {{Task.Param.Frame}} ``` Wenn der Wert des `Frames` Parameters beispielsweise lautet`1-10`, definiert er 10 Aufgaben. Jede Aufgabe hat einen anderen Wert für den `Frame` Parameter. Um eine Aufgabe auszuführen: 1. Alle Variablenverweise in der `data` Eigenschaft der eingebetteten Datei sind beispielsweise erweitert`--render-frame 1`. 1. Der Inhalt der `data` Eigenschaft wird in eine Datei im Arbeitsverzeichnis der Sitzung auf der Festplatte geschrieben. 1. Der `onRun` Befehl der Aufgabe wird in aufgelöst `bash location of embedded file` und dann ausgeführt. Weitere Informationen zu eingebetteten Dateien, Sitzungen und Pfadzuordnungen finden Sie unter [So werden Jobs ausgeführt](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) in der [Open Job](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) Description-Spezifikation. Es gibt weitere Beispiele für Jobvorlagen im Repository [deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles) sowie die [Vorlagenbeispiele, die in der Open Job Description-Spezifikation](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples) enthalten sind. # Aufgabenteilung für Jobvorlagen Durch Aufgaben-Chunking können Sie mehrere Aufgaben zu einer einzigen Arbeitseinheit zusammenfassen, die als Chunk bezeichnet wird. In einem Renderjob bedeutet dies beispielsweise, dass Deadline Cloud mehrere Frames zusammen versenden kann, anstatt einen Frame pro Befehlsaufruf. Dies reduziert den Aufwand beim Starten von Anwendungen für jede Aufgabe und verkürzt die Gesamtlaufzeit des Jobs. Einzelheiten finden Sie unter [Mehrere Frames gleichzeitig ausführen](https://github.com/OpenJobDescription/openjd-specifications/wiki/Job-Intro-03-Creating-a-Job-Template#42-running-multiple-frames-at-a-time) im OpenJD-Wiki. OpenJD unterstützt Erweiterungen, die Jobvorlagen um optionale Funktionen erweitern. Das Aufteilen von Aufgaben wird durch Hinzufügen der Erweiterung aktiviert. `TASK_CHUNKING` Um Chunking zu verwenden, fügen Sie die Erweiterung zu Ihrer Jobvorlage hinzu und verwenden Sie den `CHUNK[INT]` Task-Parametertyp. Senden Sie Jobs in Einzelteilen mit demselben Befehl. `deadline bundle submit` Die folgende Jobvorlage rendert beispielsweise Frames in Blöcken von 10: ``` specificationVersion: 'jobtemplate-2023-09' extensions: - TASK_CHUNKING name: Blender Render with Contiguous Chunking parameterDefinitions: - name: BlenderSceneFile type: PATH objectType: FILE dataFlow: IN - name: Frames type: STRING default: "1-100" - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT default: "./output" steps: - name: RenderBlender parameterSpace: taskParameterDefinitions: - name: Frame type: CHUNK[INT] range: "{{Param.Frames}}" chunks: defaultTaskCount: 10 rangeConstraint: CONTIGUOUS script: actions: onRun: command: bash args: ["{{Task.File.Run}}"] embeddedFiles: - name: Run type: TEXT data: | set -xeuo pipefail mkdir -p '{{Param.OutputDir}}' # Parse the chunk range (e.g., "1-10") into start and end frames START_FRAME="$(echo '{{Task.Param.Frame}}' | cut -d- -f1)" END_FRAME="$(echo '{{Task.Param.Frame}}' | cut -d- -f2)" blender --background '{{Param.BlenderSceneFile}}' \ --render-output '{{Param.OutputDir}}/output_####' \ --render-format PNG \ --use-extension 1 \ -s "$START_FRAME" \ -e "$END_FRAME" \ --render-anim ``` In diesem Beispiel unterteilt Deadline Cloud die 100 Frames in Blöcke wie`1-10`, usw. `11-20` Die `{{Task.Param.Frame}}` Variable wird zu einem Bereichsausdruck wie erweitert. `1-10` Da auf gesetzt `rangeConstraint` ist`CONTIGUOUS`, ist der Bereich immer `start-end` formatiert. Das Skript analysiert diesen Bereich und übergibt die Start- und Endframes mithilfe der `-e` Optionen `-s` und mit `--render-anim` an Blender. Die `chunks` Eigenschaft unterstützt die folgenden Felder: + `defaultTaskCount`— (Erforderlich) Wie viele Aufgaben zu einem einzigen Block zusammengefasst werden sollen. Der Höchstwert ist 150. + `rangeConstraint`— (Erforderlich) Wenn`CONTIGUOUS`, ist ein Chunk immer ein zusammenhängender Bereich wie. `1-10` Wenn`NONCONTIGUOUS`, kann ein Chunk eine beliebige Menge sein wie. `1,3,7-10` + `targetRuntimeSeconds`— (Optional) Die Ziellaufzeit in Sekunden für jeden Chunk. Deadline Cloud kann die Chunk-Größe dynamisch anpassen, um sich diesem Ziel zu nähern, sobald einige Chunks abgeschlossen sind. [Weitere Beispiele für das Chunking von Aufgaben, darunter einfache Beispiele und Blender-Beispiele mit zusammenhängenden und nicht zusammenhängenden Chunks, finden Sie in den Beispielen zum Aufgaben-Chunking im Deadline Cloud-Beispiel-Repository unter.](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking) GitHub **Vom Kunden verwaltete Flottenanforderungen** Für das Aufteilen von Aufgaben ist eine kompatible Worker-Agent-Version erforderlich. Wenn Sie vom Kunden verwaltete Flotten verwenden, stellen Sie sicher, dass Ihre Worker Agents auf dem neuesten Stand sind, bevor Sie Jobs mit Chunking weiterleiten. Vom Service verwaltete Flotten verwenden immer eine kompatible Worker-Agent-Version. **Die Ausgabe für Einzelaufträge wird heruntergeladen** Wenn Sie die Ausgabe für eine einzelne Aufgabe in einem aufgeteilten Job herunterladen, lädt Deadline Cloud die Ausgabe für den gesamten Block herunter. Wenn beispielsweise die Frames 1—10 zusammen verarbeitet wurden, umfasst das Herunterladen der Ausgabe für Frame 3 alle Frames 1—10. Für diese Funktion ist `deadline-cloud` Version 0.53.3 oder höher erforderlich. # Parameterwerte, Elemente für Job-Bundles Sie können die Parameterdatei verwenden, um die Werte einiger Jobparameter in der Jobvorlage oder der [CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)Operationsanforderungsargumente im Job-Bundle festzulegen, sodass Sie beim Senden eines Jobs keine Werte festlegen müssen. Die Benutzeroberfläche für die Auftragsübermittlung ermöglicht es Ihnen, diese Werte zu ändern. Sie können die Jobvorlage entweder im YAML-Format (`parameter_values.yaml`) oder im JSON-Format (`parameter_values.json`) definieren. Die Beispiele in diesem Abschnitt werden im YAML-Format angezeigt. In YAML ist das Format der Datei: ``` parameterValues: - name: value: , , or - name: value: , , or ab ... repeating as necessary ``` Jedes Element der `parameterValues` Liste muss eines der folgenden sein: + Ein in der Jobvorlage definierter Jobparameter. + Ein in einer Warteschlangenumgebung definierter Jobparameter für die Warteschlange, an die Sie den Job senden. + Ein spezieller Parameter, der beim Erstellen eines Jobs an den `CreateJob` Vorgang übergeben wird. + `deadline:priority`— Der Wert muss eine Ganzzahl sein. Er wird als [Prioritätsparameter](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-priority) an die `CreateJob` Operation übergeben. + `deadline:targetTaskRunStatus`— Der Wert muss eine Zeichenfolge sein. Er wird als [targetTaskRunStatus-Parameter](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus) an die `CreateJob` Operation übergeben. + `deadline:maxFailedTasksCount`— Der Wert muss eine Ganzzahl sein. Er wird als [maxFailedTasksCount-Parameter](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount) an die `CreateJob` Operation übergeben. + `deadline:maxRetriesPerTask`— Der Wert muss eine Ganzzahl sein. Er wird als [maxRetriesPerTask-Parameter](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask) an die `CreateJob` Operation übergeben. + `deadline:maxWorkercount`— Der Wert muss eine Ganzzahl sein. Er wird als [maxWorkerCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask)Parameter an die `CreateJob` Operation übergeben. Bei einer Auftragsvorlage handelt es sich immer um eine Vorlage und nicht um einen bestimmten auszuführenden Job. Eine Datei mit Parameterwerten ermöglicht es einem Job-Bundle, entweder als Vorlage zu dienen, wenn für einige Parameter in dieser Datei keine Werte definiert sind, oder als spezifische Jobübermittlung, wenn alle Parameter Werte haben. Das Beispiel [blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render) hat beispielsweise keine Parameterdatei und die zugehörige Jobvorlage definiert Parameter ohne Standardwerte. Diese Vorlage muss als Vorlage für die Erstellung von Jobs verwendet werden. Nachdem Sie mit diesem Job-Bundle einen Job erstellt haben, schreibt Deadline Cloud ein neues Job-Bundle in das Job-Verlaufsverzeichnis. Zum Beispiel, wenn Sie einen Job mit dem folgenden Befehl einreichen: ``` deadline bundle gui-submit blender_render/ ``` Das neue Job-Bundle enthält eine `parameter_values.yaml` Datei, die die angegebenen Parameter enthält: ``` % cat ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/parameter_values.yaml parameterValues: - name: deadline:targetTaskRunStatus value: READY - name: deadline:maxFailedTasksCount value: 10 - name: deadline:maxRetriesPerTask value: 5 - name: deadline:priority value: 75 - name: BlenderSceneFile value: /private/tmp/bundle_demo/bmw27_cpu.blend - name: Frames value: 1-10 - name: OutputDir value: /private/tmp/bundle_demo/output - name: OutputPattern value: output_#### - name: Format value: PNG - name: CondaPackages value: blender - name: RezPackages value: blender ``` Sie können denselben Job mit dem folgenden Befehl erstellen: ``` deadline bundle submit ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/ ``` **Anmerkung** Das von Ihnen eingereichte Job-Bundle wird in Ihrem Job-Verlaufsverzeichnis gespeichert. Sie können den Speicherort dieses Verzeichnisses mit dem folgenden Befehl ermitteln: ``` deadline config get settings.job_history_dir ``` # Asset-Referenzen, Elemente für Job-Bundles Sie können Deadline [Cloud-Jobanhänge](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) verwenden, um Dateien zwischen Ihrer Workstation und Deadline Cloud hin und her zu übertragen. Die Asset-Referenzdatei listet Eingabedateien und -verzeichnisse sowie Ausgabeverzeichnisse für Ihre Anhänge auf. Wenn Sie nicht alle Dateien und Verzeichnisse in dieser Datei auflisten, können Sie sie auswählen, wenn Sie einen Job mit dem `deadline bundle gui-submit` Befehl einreichen. Diese Datei hat keine Auswirkung, wenn Sie keine Jobanhänge verwenden. Sie können die Jobvorlage entweder im YAML-Format (`asset_references.yaml`) oder im JSON-Format (`asset_references.json`) definieren. Die Beispiele in diesem Abschnitt werden im YAML-Format angezeigt. In YAML ist das Format der Datei: ``` assetReferences: inputs: # Filenames on the submitting workstation whose file contents are needed as # inputs to run the job. filenames: - list of file paths # Directories on the submitting workstation whose contents are needed as inputs # to run the job. directories: - list of directory paths outputs: # Directories on the submitting workstation where the job writes output files # if running locally. directories: - list of directory paths # Paths referenced by the job, but not necessarily input or output. # Use this if your job uses the name of a path in some way, but does not explicitly need # the contents of that path. referencedPaths: - list of directory paths ``` Bei der Auswahl der Eingabe- oder Ausgabedatei, die auf Amazon S3 hochgeladen werden soll, vergleicht Deadline Cloud den Dateipfad mit den Pfaden, die in Ihren Speicherprofilen aufgeführt sind. Jeder Dateisystemspeicherort `SHARED` vom Typ -type in einem Speicherprofil abstrahiert eine Netzwerk-Dateifreigabe, die auf Ihren Workstations und Worker-Hosts bereitgestellt wird. Deadline Cloud lädt nur Dateien hoch, die sich nicht auf einer dieser Dateifreigaben befinden. Weitere Informationen zum Erstellen und Verwenden von Speicherprofilen finden Sie unter [Gemeinsamer Speicher in Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) im *AWS Deadline Cloud-Benutzerhandbuch*. **Example - Die von der Deadline Cloud-GUI erstellte Asset-Referenzdatei** Verwenden Sie den folgenden Befehl, um einen Job mithilfe des Beispiels [blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render) einzureichen. ``` deadline bundle gui-submit blender_render/ ``` Fügen Sie dem Job auf der Registerkarte **Jobanhänge** einige zusätzliche Dateien hinzu: ![\[Der Bereich mit den Stellenanhängen in der Benutzeroberfläche für die Einreichung von Jobs in Deadline Cloud. Fügen Sie die Eingabedatei/hinzuprivate/tmp/bundle_demo/a_texture.png and the input directory /private/tmp/bundle_demo/assets.\]](http://docs.aws.amazon.com/de_de/deadline-cloud/latest/developerguide/images/blender_submit_add_job_attachments.png) Nachdem Sie den Job eingereicht haben, können Sie sich die `asset_references.yaml` Datei im Job-Bundle im Job-Verlaufsverzeichnis ansehen, um die Assets in der YAML-Datei zu sehen: ``` % cat ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/asset_references.yaml assetReferences: inputs: filenames: - /private/tmp/bundle_demo/a_texture.png directories: - /private/tmp/bundle_demo/assets outputs: directories: [] referencedPaths: [] ``` # Dateien in Ihren Jobs verwenden Viele der Jobs, die Sie an AWS Deadline Cloud einreichen, enthalten Eingabe- und Ausgabedateien. Ihre Eingabedateien und Ausgabeverzeichnisse befinden sich möglicherweise auf einer Kombination aus gemeinsam genutzten Dateisystemen und lokalen Laufwerken. Jobs müssen den Inhalt an diesen Speicherorten lokalisieren. Deadline Cloud bietet zwei Funktionen: [Jobanhänge](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) und [Speicherprofile](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html), die zusammenarbeiten, damit Ihre Jobs die benötigten Dateien finden können. Arbeitsanhänge bieten mehrere Vorteile + Dateien mithilfe von Amazon S3 zwischen Hosts verschieben + Übertragen Sie Dateien von Ihrer Workstation auf Worker-Hosts und umgekehrt + Verfügbar für Jobs in Warteschlangen, in denen Sie die Funktion aktivieren + Wird hauptsächlich für vom Service verwaltete Flotten verwendet, ist aber auch kompatibel mit vom Kunden verwalteten Flotten. Verwenden Sie Speicherprofile, um das Layout gemeinsam genutzter Dateisystemspeicherorte auf Ihrer Workstation und Ihren Worker-Hosts zuzuordnen. Diese Zuordnung hilft Ihren Jobs dabei, gemeinsam genutzte Dateien und Verzeichnisse zu finden, wenn sich deren Speicherorte auf Ihrer Workstation und Ihren Worker-Hosts unterscheiden, z. B. bei plattformübergreifenden Konfigurationen mit Windows basierten Workstations und Linux basierten Worker-Hosts. Die Zuordnung Ihrer Dateisystemkonfiguration im Speicherprofil wird auch von Job-Anhängen verwendet, um die Dateien zu identifizieren, die für den Transfer zwischen Hosts über Amazon S3 benötigt werden. Wenn Sie keine Jobanhänge verwenden und keine Datei- und Verzeichnisspeicherorte zwischen Workstations und Worker-Hosts neu zuordnen müssen, müssen Sie Ihre Fileshares nicht mit Speicherprofilen modellieren. **Topics** + [Beispiel für eine Projektinfrastruktur](sample-project-infrastructure.md) + [Speicherprofile und Pfadzuweisung](storage-profiles-and-path-mapping.md) # Beispiel für eine Projektinfrastruktur Um die Verwendung von Job-Anhängen und Speicherprofilen zu demonstrieren, richten Sie eine Testumgebung mit zwei separaten Projekten ein. Sie können die Deadline Cloud-Konsole verwenden, um die Testressourcen zu erstellen. 1. Falls Sie dies noch nicht getan haben, erstellen Sie eine Testfarm. Gehen Sie wie unter Farm erstellen beschrieben vor, [um eine Farm zu erstellen](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html). 1. Erstellen Sie in jedem der beiden Projekte zwei Warteschlangen für Jobs. Gehen Sie wie unter Warteschlange erstellen beschrieben vor, um Warteschlangen [zu erstellen](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html). 1. Erstellen Sie die erste **Q1** aufgerufene Warteschlange. Verwenden Sie die folgende Konfiguration und verwenden Sie die Standardeinstellungen für alle anderen Elemente. + Wählen Sie für Jobanhänge **Create a new Amazon S3 S3-Bucket** aus. + Wählen Sie **Zuordnung zu kundenverwalteten Flotten aktivieren** aus. + Geben Sie für „Als Benutzer ausführen“ sowohl **jobuser** für den POSIX-Benutzer als auch für die POSIX-Gruppe ein. + Erstellen Sie für die Warteschlangendienst-Rolle eine neue Rolle mit dem Namen **AssetDemoFarm-Q1-Role** + Deaktivieren Sie das Kontrollkästchen für die standardmäßige Conda-Warteschlangenumgebung. 1. Erstellen Sie die zweite **Q2** aufgerufene Warteschlange. Verwenden Sie die folgende Konfiguration und verwenden Sie die Standardeinstellungen für alle anderen Elemente. + Wählen Sie für Jobanhänge **Create a new Amazon S3 S3-Bucket** aus. + Wählen Sie **Zuordnung zu kundenverwalteten Flotten aktivieren** aus. + Geben Sie für „Als Benutzer ausführen“ sowohl **jobuser** für den POSIX-Benutzer als auch für die POSIX-Gruppe ein. + Erstellen Sie für die Warteschlangendienst-Rolle eine neue Rolle mit dem Namen **AssetDemoFarm-Q2-Role** + Deaktivieren Sie das Kontrollkästchen für die standardmäßige Conda-Warteschlangenumgebung. 1. Erstellen Sie eine einzige, vom Kunden verwaltete Flotte, die die Jobs von beiden Warteschlangen aus ausführt. Um die Flotte zu erstellen, folgen Sie dem Verfahren unter [Erstellen einer kundenverwalteten](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html) Flotte. Verwenden Sie die folgende Konfiguration: + Verwenden Sie als **Name****DemoFleet**. + Wählen Sie als **Flottenart** die Option **Vom Kunden verwaltet** + Erstellen Sie für die **Servicerolle Fleet** eine neue Rolle mit dem Namen **AssetDemoFarm-Fleet-Role**. + Ordnen Sie die Flotte keinen Warteschlangen zu. Die Testumgebung geht davon aus, dass es drei Dateisysteme gibt, die von Hosts gemeinsam genutzt werden, die Netzwerkdateifreigaben verwenden. In diesem Beispiel haben die Speicherorte die folgenden Namen: + `FSCommon`- enthält Eingabe-Job-Assets, die beiden Projekten gemeinsam sind. + `FS1`- enthält Eingabe- und Ausgabe-Auftragsressourcen für Projekt 1. + `FS2`- enthält Eingabe- und Ausgabe-Auftragsressourcen für Projekt 2. In der Testumgebung wird außerdem davon ausgegangen, dass es drei Arbeitsstationen gibt, und zwar wie folgt: + `WSAll`- Eine Linux basierte Workstation, die von Entwicklern für alle Projekte verwendet wird. Die gemeinsam genutzten Speicherorte im Dateisystem sind: + `FSCommon`: `/shared/common` + `FS1`: `/shared/projects/project1` + `FS2`: `/shared/projects/project2` + `WS1`- Eine Windows basierte Workstation, die für Projekt 1 verwendet wird. Die gemeinsam genutzten Speicherorte im Dateisystem sind: + `FSCommon`: `S:\` + `FS1`: `Z:\` + `FS2`: Nicht verfügbar + `WS1`- Eine macOS basierte Workstation, die für Projekt 2 verwendet wird. Die Speicherorte des gemeinsam genutzten Dateisystems sind: + `FSCommon`: `/Volumes/common` + `FS1`: Nicht verfügbar + `FS2`: `/Volumes/projects/project2` Definieren Sie abschließend die gemeinsam genutzten Dateisystemspeicherorte für die Mitarbeiter in Ihrer Flotte. Die folgenden Beispiele beziehen sich auf diese Konfiguration als`WorkerConfig`. Die gemeinsam genutzten Standorte sind: + `FSCommon`: `/mnt/common` + `FS1`: `/mnt/projects/project1` + `FS2`: `/mnt/projects/project2` Sie müssen keine gemeinsam genutzten Dateisysteme, Workstations oder Worker einrichten, die dieser Konfiguration entsprechen. Die gemeinsam genutzten Standorte müssen für die Demonstration nicht existieren. # Speicherprofile und Pfadzuweisung Verwenden Sie Speicherprofile, um die Dateisysteme auf Ihrer Workstation und Ihren Worker-Hosts zu modellieren. Jedes Speicherprofil beschreibt das Betriebssystem und das Dateisystem-Layout einer Ihrer Systemkonfigurationen. In diesem Thema wird beschrieben, wie Sie Speicherprofile verwenden, um die Dateisystemkonfigurationen Ihrer Hosts zu modellieren, sodass Deadline Cloud Pfadzuordnungsregeln für Ihre Jobs generieren kann, und wie diese Pfadzuordnungsregeln aus Ihren Speicherprofilen generiert werden. Wenn Sie einen Job an Deadline Cloud einreichen, können Sie eine optionale Speicherprofil-ID für den Job angeben. Dieses Speicherprofil beschreibt das Dateisystem der einreichenden Workstation. Es beschreibt die ursprüngliche Dateisystemkonfiguration, die von den Dateipfaden in der Jobvorlage verwendet wird. Sie können einer Flotte auch ein Speicherprofil zuordnen. Das Speicherprofil beschreibt die Dateisystemkonfiguration aller Worker-Hosts in der Flotte. Wenn Sie über Worker mit einer anderen Dateisystemkonfiguration verfügen, müssen diese Worker einer anderen Flotte in Ihrer Farm zugewiesen werden. Pfadzuordnungsregeln beschreiben, wie Pfade neu zugeordnet werden sollten, und zwar von der Art, wie sie im Job angegeben sind, bis zum tatsächlichen Speicherort des Pfads auf einem Worker-Host. Deadline Cloud vergleicht die im Speicherprofil eines Jobs beschriebene Dateisystemkonfiguration mit dem Speicherprofil der Flotte, die den Job ausführt, um diese Pfadzuordnungsregeln abzuleiten. **Topics** + [Modellieren Sie gemeinsam genutzte Dateisystemspeicherorte mit Speicherprofilen](modeling-your-shared-filesystem-locations-with-storage-profiles.md) + [Konfigurieren Sie Speicherprofile für Flotten](configuring-storage-profiles-for-fleets.md) + [Konfigurieren Sie Speicherprofile für Warteschlangen](storage-profiles-for-queues.md) + [Leiten Sie Pfadzuordnungsregeln aus Speicherprofilen ab](deriving-path-mapping-rules-from-storage-profiles.md) # Modellieren Sie gemeinsam genutzte Dateisystemspeicherorte mit Speicherprofilen Ein Speicherprofil modelliert die Dateisystemkonfiguration einer Ihrer Hostkonfigurationen. In der [Beispielprojektinfrastruktur]() gibt es vier verschiedene Hostkonfigurationen. In diesem Beispiel erstellen Sie für jedes ein separates Speicherprofil. Sie können ein Speicherprofil mit einer der folgenden Methoden erstellen: + [CreateStorageProfile API](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateStorageProfile.html) + [AWS::Deadline::StorageProfile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-deadline-storageprofile.html) CloudFormation Ressource + [AWS -Konsole](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html#storage-profile) Ein Speicherprofil besteht aus einer Liste von Dateisystemspeicherorten, die Deadline Cloud jeweils den Speicherort und den Typ eines Dateisystemspeicherorts mitteilen, der für Jobs relevant ist, die von einem Host eingereicht oder auf einem Host ausgeführt werden. Ein Speicherprofil sollte nur die Standorte modellieren, die für Jobs relevant sind. Der gemeinsam genutzte `FSCommon` Speicherort befindet sich beispielsweise auf der Workstation `WS1` unter`S:\`, sodass der entsprechende Speicherort im Dateisystem wie folgt lautet: ``` { "name": "FSCommon", "path": "S:\\", "type": "SHARED" } ``` Verwenden Sie die folgenden Befehle, um das Speicherprofil für Workstation-Konfigurationen `WS1` `WS3` und die Worker-Konfiguration `WorkerConfig` mithilfe von [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)in zu erstellen [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html): `WS2` ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WSAll \ --os-family LINUX \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"/shared/common"}, {"name": "FS1", "type":"SHARED", "path":"/shared/projects/project1"}, {"name": "FS2", "type":"SHARED", "path":"/shared/projects/project2"} ]' aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WS1 \ --os-family WINDOWS \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"S:\\"}, {"name": "FS1", "type":"SHARED", "path":"Z:\\"} ]' aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WS2 \ --os-family MACOS \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"/Volumes/common"}, {"name": "FS2", "type":"SHARED", "path":"/Volumes/projects/project2"} ]' aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WorkerCfg \ --os-family LINUX \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"/mnt/common"}, {"name": "FS1", "type":"SHARED", "path":"/mnt/projects/project1"}, {"name": "FS2", "type":"SHARED", "path":"/mnt/projects/project2"} ]' ``` **Anmerkung** Sie müssen auf die Dateisystemspeicherorte in Ihren Speicherprofilen verweisen und dabei dieselben Werte für die `name` Eigenschaft in allen Speicherprofilen in Ihrer Farm verwenden. Deadline Cloud vergleicht beim Generieren von Pfadzuordnungsregeln die Namen, um festzustellen, dass Dateisystemspeicherorte aus verschiedenen Speicherprofilen auf denselben Speicherort verweisen. # Konfigurieren Sie Speicherprofile für Flotten Sie können eine Flotte so konfigurieren, dass sie ein Speicherprofil enthält, das die Dateisystemstandorte aller Mitarbeiter in der Flotte modelliert. Die Host-Dateisystemkonfiguration aller Mitarbeiter in einer Flotte muss mit dem Speicherprofil ihrer Flotte übereinstimmen. Mitarbeiter mit unterschiedlichen Dateisystemkonfigurationen müssen sich in separaten Flotten befinden. Um die Konfiguration Ihrer Flotte für die Verwendung des `WorkerConfig` Speicherprofils festzulegen, verwenden Sie den folgenden Befehl [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html): [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of FLEET_ID to your fleet's identifier FLEET_ID=fleet-00112233445566778899aabbccddeeff # Change the value of WORKER_CFG_ID to your storage profile named WorkerConfig WORKER_CFG_ID=sp-00112233445566778899aabbccddeeff FLEET_WORKER_MODE=$( \ aws deadline get-fleet --farm-id $FARM_ID --fleet-id $FLEET_ID \ --query '.configuration.customerManaged.mode' \ ) FLEET_WORKER_CAPABILITIES=$( \ aws deadline get-fleet --farm-id $FARM_ID --fleet-id $FLEET_ID \ --query '.configuration.customerManaged.workerCapabilities' \ ) aws deadline update-fleet --farm-id $FARM_ID --fleet-id $FLEET_ID \ --configuration \ "{ \"customerManaged\": { \"storageProfileId\": \"$WORKER_CFG_ID\", \"mode\": $FLEET_WORKER_MODE, \"workerCapabilities\": $FLEET_WORKER_CAPABILITIES } }" ``` # Konfigurieren Sie Speicherprofile für Warteschlangen Die Konfiguration einer Warteschlange umfasst eine Liste von Namen der gemeinsam genutzten Dateisystemspeicherorte, auf die an die Warteschlange übermittelte Jobs Zugriff benötigen, wobei Groß- und Kleinschreibung beachtet werden muss. Beispielsweise erfordern an die Warteschlange übermittelte Jobs `Q1` Dateisystemspeicherorte und. `FSCommon` `FS1` Für an die Warteschlange übermittelte Jobs `Q2` sind Dateisystemspeicherorte `FSCommon` und erforderlich. `FS2` Verwenden Sie das folgende Skript, um die Konfigurationen der Warteschlange so einzustellen, dass diese Dateisystemspeicherorte erforderlich sind: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of QUEUE2_ID to queue Q2's identifier QUEUE2_ID=queue-00112233445566778899aabbccddeeff aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --required-file-system-location-names-to-add FSComm FS1 aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \ --required-file-system-location-names-to-add FSComm FS2 ``` Die Konfiguration einer Warteschlange umfasst auch eine Liste der zulässigen Speicherprofile, die für Aufträge gilt, die an diese Warteschlange weitergeleitet wurden, und für Flotten, die mit dieser Warteschlange verknüpft sind. In der Liste der zulässigen Speicherprofile der Warteschlange sind nur Speicherprofile zulässig, die Dateisystemspeicherorte für alle erforderlichen Dateisystemspeicherorte für die Warteschlange definieren. Ein Job schlägt fehl, wenn Sie ihn mit einem Speicherprofil einreichen, das nicht in der Liste der zulässigen Speicherprofile für die Warteschlange enthalten ist. Sie können einen Job ohne Speicherprofil jederzeit an eine Warteschlange senden. Die Workstation-Konfigurationen sind beschriftet `WSAll` und `WS1` beide verfügen über die erforderlichen Dateisystemspeicherorte (`FSCommon`und`FS1`) für die Warteschlange`Q1`. Sie müssen berechtigt sein, Jobs an die Warteschlange weiterzuleiten. In ähnlicher Weise werden die Workstation-Konfigurationen `WSAll` und die `WS2` Anforderungen für die Warteschlange erfüllt`Q2`. Sie müssen in der Lage sein, Jobs an diese Warteschlange weiterzuleiten. Aktualisieren Sie beide Warteschlangenkonfigurationen, sodass Jobs mit diesen Speicherprofilen mithilfe des folgenden Skripts gesendet werden können: ``` # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff # Change the value of WS1 to the identifier of the WS1 storage profile WS1_ID=sp-00112233445566778899aabbccddeeff # Change the value of WS2 to the identifier of the WS2 storage profile WS2_ID=sp-00112233445566778899aabbccddeeff aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --allowed-storage-profile-ids-to-add $WSALL_ID $WS1_ID aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \ --allowed-storage-profile-ids-to-add $WSALL_ID $WS2_ID ``` Wenn Sie das `WS2` Speicherprofil zur Liste der zulässigen Speicherprofile für die Warteschlange hinzufügen, schlägt `Q1` dies fehl: ``` $ aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --allowed-storage-profile-ids-to-add $WS2_ID An error occurred (ValidationException) when calling the UpdateQueue operation: Storage profile id: sp-00112233445566778899aabbccddeeff does not have required file system location: FS1 ``` Das liegt daran, dass das `WS2` Speicherprofil keine Definition für den Dateisystemspeicherort enthält`FS1`, den diese Warteschlange `Q1` benötigt. Das Zuordnen einer konfigurierten Flotte zu einem Speicherprofil, das nicht in der Liste der zulässigen Speicherprofile der Warteschlange enthalten ist, schlägt ebenfalls fehl. Beispiel: ``` $ aws deadline create-queue-fleet-association --farm-id $FARM_ID \ --fleet-id $FLEET_ID \ --queue-id $QUEUE1_ID An error occurred (ValidationException) when calling the CreateQueueFleetAssociation operation: Mismatch between storage profile ids. ``` Um den Fehler zu beheben, fügen Sie das angegebene Speicherprofil der Liste der zulässigen Speicherprofile sowohl für die Warteschlange als auch für die Warteschlange `Q1` hinzu. `WorkerConfig` `Q2` Ordnen Sie dann die Flotte diesen Warteschlangen zu, sodass die Mitarbeiter der Flotte Aufträge aus beiden Warteschlangen ausführen können. ``` # Change the value of FLEET_ID to your fleet's identifier FLEET_ID=fleet-00112233445566778899aabbccddeeff # Change the value of WORKER_CFG_ID to your storage profile named WorkerCfg WORKER_CFG_ID=sp-00112233445566778899aabbccddeeff aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --allowed-storage-profile-ids-to-add $WORKER_CFG_ID aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \ --allowed-storage-profile-ids-to-add $WORKER_CFG_ID aws deadline create-queue-fleet-association --farm-id $FARM_ID \ --fleet-id $FLEET_ID \ --queue-id $QUEUE1_ID aws deadline create-queue-fleet-association --farm-id $FARM_ID \ --fleet-id $FLEET_ID \ --queue-id $QUEUE2_ID ``` # Leiten Sie Pfadzuordnungsregeln aus Speicherprofilen ab Pfadzuordnungsregeln beschreiben, wie Pfade vom Job zum tatsächlichen Speicherort des Pfads auf einem Worker-Host neu zugeordnet werden sollten. Wenn eine Aufgabe auf einem Worker ausgeführt wird, wird das Speicherprofil des Jobs mit dem Speicherprofil der Worker-Flotte verglichen, um die Pfadzuordnungsregeln für die Aufgabe abzuleiten. Deadline Cloud erstellt eine Zuordnungsregel für jeden der erforderlichen Dateisystemspeicherorte in der Konfiguration der Warteschlange. Beispielsweise hat ein Job, der mit dem `WSAll` Speicherprofil an die Warteschlange gesendet `Q1` wurde, die Pfadzuordnungsregeln: + `FSComm`: `/shared/common -> /mnt/common` + `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` Deadline Cloud erstellt Regeln für die Speicherorte `FSComm` und das `FS1` Dateisystem, aber nicht für den Speicherort des `FS2` Dateisystems, obwohl `WSAll` sowohl die `WorkerConfig` Speicherprofile als auch diese definieren`FS2`. Dies liegt daran, dass die Liste `Q1` der erforderlichen Dateisystemspeicherorte in der Warteschlange lautet`["FSComm", "FS1"]`. Sie können die Pfadzuordnungsregeln überprüfen, die für Jobs verfügbar sind, die mit einem bestimmten Speicherprofil eingereicht wurden, indem Sie einen Job einreichen, der die [Datei mit den Pfadzuordnungsregeln von Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping) ausdruckt, und dann das Sitzungsprotokoll lesen, nachdem der Job abgeschlossen ist: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of WSALL_ID to the identifier of the WSALL storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff aws deadline create-job --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --priority 50 \ --storage-profile-id $WSALL_ID \ --template-type JSON --template \ '{ "specificationVersion": "jobtemplate-2023-09", "name": "DemoPathMapping", "steps": [ { "name": "ShowPathMappingRules", "script": { "actions": { "onRun": { "command": "/bin/cat", "args": [ "{{Session.PathMappingRulesFile}}" ] } } } } ] }' ``` Wenn Sie die [Deadline Cloud-CLI](https://pypi.org/project/deadline/) zum Senden von Jobs verwenden, legt deren `settings.storage_profile_id` Konfigurationseinstellung das Speicherprofil fest, das Jobs haben, die mit der CLI eingereicht werden. Um Jobs mit dem `WSAll` Speicherprofil einzureichen, legen Sie Folgendes fest: ``` deadline config set settings.storage_profile_id $WSALL_ID ``` Um einen vom Kunden verwalteten Worker so auszuführen, als ob er in der Beispielinfrastruktur ausgeführt würde, folgen Sie dem Verfahren [unter Den Worker-Agent ausführen](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/run-worker.html) im *Deadline Cloud-Benutzerhandbuch*, um einen Worker auszuführen. AWS CloudShell Wenn Sie diese Anweisungen bereits befolgt haben, löschen Sie zuerst die `~/demoenv-persist` Verzeichnisse `~/demoenv-logs` und. Legen Sie vorher auch die Werte der `DEV_CMF_ID` Umgebungsvariablen `DEV_FARM_ID` und, auf die sich die Anweisungen beziehen, wie folgt fest: ``` DEV_FARM_ID=$FARM_ID DEV_CMF_ID=$FLEET_ID ``` Nach der Ausführung des Jobs können Sie die Pfadzuordnungsregeln in der Protokolldatei des Jobs sehen: ``` cat demoenv-logs/${QUEUE1_ID}/*.log ... JJSON log results (see below) ... ``` Das Protokoll enthält Zuordnungen sowohl für das `FS1` als auch für das `FSComm` Dateisystem. Der Protokolleintrag wurde aus Gründen der Lesbarkeit neu formatiert und sieht wie folgt aus: ``` { "version": "pathmapping-1.0", "path_mapping_rules": [ { "source_path_format": "POSIX", "source_path": "/shared/projects/project1", "destination_path": "/mnt/projects/project1" }, { "source_path_format": "POSIX", "source_path": "/shared/common", "destination_path": "/mnt/common" } ] ``` Sie können Jobs mit unterschiedlichen Speicherprofilen einreichen, um zu sehen, wie sich die Pfadzuordnungsregeln ändern. # Verwenden Sie Jobanhänge, um Dateien zu teilen Verwenden Sie *Jobanhänge*, um Dateien, die sich nicht in gemeinsam genutzten Verzeichnissen befinden, für Ihre Jobs verfügbar zu machen und die Ausgabedateien zu erfassen, falls sie nicht in gemeinsam genutzte Verzeichnisse geschrieben wurden. Job Attachments verwendet Amazon S3, um Dateien zwischen Hosts zu übertragen. Dateien werden in S3-Buckets gespeichert, und Sie müssen eine Datei nicht hochladen, wenn sich ihr Inhalt nicht geändert hat. Sie müssen Auftragsanhänge verwenden, wenn Sie Jobs auf vom [Service verwalteten Flotten](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html) ausführen, da Hosts die Speicherorte im Dateisystem nicht gemeinsam nutzen. Jobanhänge sind auch für [vom Kunden verwaltete Flotten](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/manage-cmf.html) nützlich, wenn die Eingabe- oder Ausgabedateien eines Jobs in einem gemeinsam genutzten Netzwerkdateisystem gespeichert sind, z. B. wenn Ihr [Auftragspaket](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html) Shell- oder Python-Skripte enthält. Wenn Sie ein Job-Bundle entweder mit der [Deadline Cloud-CLI](https://pypi.org/project/deadline/) oder einem Deadline Cloud-Absender einreichen, verwenden Jobanhänge das Speicherprofil des Jobs und die erforderlichen Dateisystemspeicherorte der Warteschlange, um die Eingabedateien zu identifizieren, die sich nicht auf einem Worker-Host befinden und im Rahmen der Auftragsübermittlung auf Amazon S3 hochgeladen werden sollten. Diese Speicherprofile helfen Deadline Cloud auch dabei, die Ausgabedateien an Worker-Host-Standorten zu identifizieren, die auf Amazon S3 hochgeladen werden müssen, damit sie auf Ihrer Workstation verfügbar sind. Die Beispiele für Jobanhänge verwenden die Konfigurationen für Farm, Flotte, Warteschlangen und Speicherprofile von [Beispiel für eine Projektinfrastruktur](sample-project-infrastructure.md) und[Speicherprofile und Pfadzuweisung](storage-profiles-and-path-mapping.md). Sie sollten diese Abschnitte vor diesem durchgehen. In den folgenden Beispielen verwenden Sie ein Beispiel-Job-Bundle als Ausgangspunkt und ändern es dann, um die Funktionalität von Job Attachment zu untersuchen. Job-Bundles sind die beste Methode, um Job-Anhänge für Ihre Jobs zu verwenden. Sie kombinieren eine Jobvorlage „[Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki)“ in einem Verzeichnis mit zusätzlichen Dateien, in denen die Dateien und Verzeichnisse aufgeführt sind, die für Jobs benötigt werden, die das Job-Bundle verwenden. Weitere Informationen zu Jobpaketen finden Sie unter[Vorlagen für offene Stellenbeschreibungen (OpenJD) für Deadline Cloud](build-job-bundle.md). # Dateien mit einem Job einreichen Mit Deadline Cloud können Sie Job-Workflows für den Zugriff auf Eingabedateien aktivieren, die an gemeinsam genutzten Dateisystemen auf Worker-Hosts nicht verfügbar sind. Mit Auftragsanhängen können Renderaufträge auf Dateien zugreifen, die sich nur auf einem lokalen Workstation-Laufwerk oder in einer vom Service verwalteten Flottenumgebung befinden. Wenn Sie ein Auftragspaket einreichen, können Sie Listen mit Eingabedateien und Verzeichnissen hinzufügen, die für den Job erforderlich sind. Deadline Cloud identifiziert diese nicht gemeinsam genutzten Dateien, lädt sie vom lokalen Computer auf Amazon S3 hoch und lädt sie auf den Worker-Host herunter. Es optimiert den Prozess der Übertragung von Eingabe-Assets an Renderknoten und stellt sicher, dass alle erforderlichen Dateien für die verteilte Auftragsausführung zugänglich sind. Sie können die Dateien für Jobs direkt im Job-Bundle angeben, Parameter in der Jobvorlage verwenden, die Sie mithilfe von Umgebungsvariablen oder einem Skript bereitstellen, und die `assets_references` Datei des Jobs verwenden. Sie können eine dieser Methoden oder eine Kombination aus allen dreien verwenden. Sie können ein Speicherprofil für das Paket für den Job angeben, sodass nur Dateien hochgeladen werden, die sich auf der lokalen Arbeitsstation geändert haben. In diesem Abschnitt wird anhand eines Beispiel-Job-Bundles von GitHub gezeigt, wie Deadline Cloud die Dateien in Ihrem Job zum Hochladen identifiziert, wie diese Dateien in Amazon S3 organisiert sind und wie sie den Worker-Hosts zur Verfügung gestellt werden, die Ihre Jobs verarbeiten. **Topics** + [So lädt Deadline Cloud Dateien auf Amazon S3 hoch](what-job-attachments-uploads-to-amazon-s3.md) + [Wie Deadline Cloud die hochzuladenden Dateien auswählt](how-job-attachments-decides-what-to-upload-to-amazon-s3.md) + [Wie finden Jobs Eingabedateien für Jobanhänge](how-jobs-find-job-attachments-input-files.md) # So lädt Deadline Cloud Dateien auf Amazon S3 hoch Dieses Beispiel zeigt, wie Deadline Cloud Dateien von Ihrer Workstation oder Ihrem Worker-Host auf Amazon S3 hochlädt, damit sie gemeinsam genutzt werden können. Es verwendet ein Beispiel-Job-Bundle von GitHub und die Deadline Cloud-CLI, um Jobs einzureichen. Klonen Sie zunächst das [Deadline GitHub Cloud-Beispiel-Repository](https://github.com/aws-deadline/deadline-cloud-samples) in Ihre [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)Umgebung und kopieren Sie dann das `job_attachments_devguide` Job-Bundle in Ihr Home-Verzeichnis: ``` git clone https://github.com/aws-deadline/deadline-cloud-samples.git cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide ~/ ``` Installieren Sie die [Deadline Cloud-CLI](https://pypi.org/project/deadline/), um Job-Bundles einzureichen: ``` pip install deadline --upgrade ``` Das `job_attachments_devguide` Job-Bundle besteht aus einem einzigen Schritt mit einer Aufgabe, die ein Bash-Shell-Skript ausführt, dessen Dateisystemspeicherort als Jobparameter übergeben wird. Die Definition des Job-Parameters lautet: ``` ... - name: ScriptFile type: PATH default: script.sh dataFlow: IN objectType: FILE ... ``` Der `IN` Wert der `dataFlow` Eigenschaft teilt Job-Anhängen mit, dass der Wert des `ScriptFile` Parameters eine Eingabe für den Job ist. Der Wert der `default` Eigenschaft ist ein relativer Speicherort zum Verzeichnis des Job-Bundles, es kann sich aber auch um einen absoluten Pfad handeln. Diese Parameterdefinition deklariert die `script.sh` Datei im Verzeichnis des Job-Bundles als Eingabedatei, die für die Ausführung des Jobs erforderlich ist. Stellen Sie als Nächstes sicher, dass für die Deadline Cloud-CLI kein Speicherprofil konfiguriert ist, und senden Sie den Job dann in die Warteschlange`Q1`: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff deadline config set settings.storage_profile_id '' deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/ ``` Die Ausgabe der Deadline Cloud-CLI nach der Ausführung dieses Befehls sieht wie folgt aus: ``` Submitting to Queue: Q1 ... Hashing Attachments [####################################] 100% Hashing Summary: Processed 1 file totaling 39.0 B. Skipped re-processing 0 files totaling 0.0 B. Total processing time of 0.0327 seconds at 1.19 KB/s. Uploading Attachments [####################################] 100% Upload Summary: Processed 1 file totaling 39.0 B. Skipped re-processing 0 files totaling 0.0 B. Total processing time of 0.25639 seconds at 152.0 B/s. Waiting for Job to be created... Submitted job bundle: job_attachments_devguide/ Job creation completed successfully job-74148c13342e4514b63c7a7518657005 ``` Wenn Sie den Job einreichen, hascht Deadline Cloud die `script.sh` Datei zuerst und lädt sie dann auf Amazon S3 hoch. Deadline Cloud behandelt den S3-Bucket als inhaltsadressierbaren Speicher. Dateien werden in S3-Objekte hochgeladen. Der Objektname wird aus einem Hash des Dateiinhalts abgeleitet. Wenn zwei Dateien identischen Inhalt haben, haben sie unabhängig davon, wo sich die Dateien befinden oder wie sie benannt sind, denselben Hashwert. Dieser inhaltsadressierbare Speicher ermöglicht es Deadline Cloud, das Hochladen einer Datei zu vermeiden, wenn sie bereits verfügbar ist. Sie können die [AWS-CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) verwenden, um die Objekte zu sehen, die auf Amazon S3 hochgeladen wurden: ``` # The name of queue `Q1`'s job attachments S3 bucket Q1_S3_BUCKET=$( aws deadline get-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --query 'jobAttachmentSettings.s3BucketName' | tr -d '"' ) aws s3 ls s3://$Q1_S3_BUCKET --recursive ``` Zwei Objekte wurden auf S3 hochgeladen: + `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`— Der Inhalt von`script.sh`. Der Wert `87cb19095dd5d78fcaf56384ef0e6241` im Objektschlüssel ist der Hash des Dateiinhalts, und die Erweiterung `xxh128` gibt an, dass der Hashwert als [128-Bit-xxhash](https://xxhash.com/) berechnet wurde. + `DeadlineCloud/Manifests///Inputs//a1d221c7fd97b08175b3872a37428e8c_input`— Das Manifest-Objekt für die Auftragsübergabe. Die Werte ````, und `` sind Ihre Farm-ID, Ihre Warteschlangen-ID und ein zufälliger Hexadezimalwert. Der Wert `a1d221c7fd97b08175b3872a37428e8c` in diesem Beispiel ist ein Hashwert, der anhand der Zeichenfolge`/home/cloudshell-user/job_attachments_devguide`, dem Verzeichnis, in dem er sich `script.sh` befindet, berechnet wird. Das Manifest-Objekt enthält die Informationen für die Eingabedateien in einem bestimmten Stammpfad, die im Rahmen der Auftragsübermittlung auf S3 hochgeladen wurden. Laden Sie diese Manifestdatei herunter (`aws s3 cp s3://$Q1_S3_BUCKET/`). Ihr Inhalt ist ähnlich wie: ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "87cb19095dd5d78fcaf56384ef0e6241", "mtime": 1721147454416085, "path": "script.sh", "size": 39 } ], "totalSize": 39 } ``` Dies bedeutet, dass die Datei hochgeladen `script.sh` wurde, und der Hash des Inhalts dieser Datei lautet`87cb19095dd5d78fcaf56384ef0e6241`. Dieser Hashwert entspricht dem Wert im Objektnamen`DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`. Es wird von Deadline Cloud verwendet, um zu wissen, welches Objekt für den Inhalt dieser Datei heruntergeladen werden muss. Das vollständige Schema für diese Datei ist [verfügbar in GitHub](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/job_attachments/asset_manifests/v2023_03_03/validate.py). Wenn Sie den [CreateJob Vorgang](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html) verwenden, können Sie den Speicherort der Manifestobjekte festlegen. Sie können die [GetJobOperation](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) verwenden, um den Standort zu sehen: ``` { "attachments": { "file system": "COPIED", "manifests": [ { "inputManifestHash": "5b0db3d311805ea8de7787b64cbbe8b3", "inputManifestPath": "//Inputs//a1d221c7fd97b08175b3872a37428e8c_input", "rootPath": "/home/cloudshell-user/job_attachments_devguide", "rootPathFormat": "posix" } ] }, ... } ``` # Wie Deadline Cloud die hochzuladenden Dateien auswählt Die Dateien und Verzeichnisse, die Job Attachments für den Upload auf Amazon S3 als Eingaben für Ihren Job in Betracht ziehen, sind: + Die Werte aller Jobparameter `PATH` vom Typ -type, die in der Jobvorlage des Job-Bundles mit dem `dataFlow` Wert `IN` oder `INOUT` definiert sind. + Die Dateien und Verzeichnisse, die als Eingaben in der Asset-Referenzdatei des Job-Bundles aufgeführt sind. Wenn Sie einen Job ohne Speicherprofil einreichen, werden alle Dateien hochgeladen, die für den Upload in Frage kommen. Wenn Sie einen Job mit einem Speicherprofil einreichen, werden Dateien nicht auf Amazon S3 hochgeladen, wenn sie sich in den Dateisystemspeicherorten des Speicherprofils `SHARED` vom Typ -type befinden, die auch erforderliche Dateisystemspeicherorte für die Warteschlange sind. Es wird davon ausgegangen, dass diese Speicherorte auf den Worker-Hosts verfügbar sind, auf denen der Job ausgeführt wird, sodass sie nicht auf S3 hochgeladen werden müssen. In diesem Beispiel erstellen Sie `SHARED` Dateisystemspeicherorte `WSAll` in Ihrer CloudShell AWS-Umgebung und fügen dann Dateien zu diesen Dateisystemspeicherorten hinzu. Verwenden Sie den folgenden Befehl: ``` # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff sudo mkdir -p /shared/common /shared/projects/project1 /shared/projects/project2 sudo chown -R cloudshell-user:cloudshell-user /shared for d in /shared/common /shared/projects/project1 /shared/projects/project2; do echo "File contents for $d" > ${d}/file.txt done ``` Als Nächstes fügen Sie dem Job-Bundle eine Asset-Referenzdatei hinzu, die alle Dateien enthält, die Sie als Eingaben für den Job erstellt haben. Verwenden Sie den folgenden Befehl: ``` cat > ${HOME}/job_attachments_devguide/asset_references.yaml << EOF assetReferences: inputs: filenames: - /shared/common/file.txt directories: - /shared/projects/project1 - /shared/projects/project2 EOF ``` Als Nächstes konfigurieren Sie die Deadline Cloud-CLI so, dass Jobs mit dem `WSAll` Speicherprofil gesendet werden, und senden Sie dann das Job-Bundle: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff deadline config set settings.storage_profile_id $WSALL_ID deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/ ``` Deadline Cloud lädt zwei Dateien auf Amazon S3 hoch, wenn Sie den Job einreichen. Sie können die Manifestobjekte für den Job von S3 herunterladen, um die hochgeladenen Dateien zu sehen: ``` for manifest in $( \ aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID \ --query 'attachments.manifests[].inputManifestPath' \ | jq -r '.[]' ); do echo "Manifest object: $manifest" aws s3 cp --quiet s3://$Q1_S3_BUCKET/DeadlineCloud/Manifests/$manifest /dev/stdout | jq . done ``` In diesem Beispiel gibt es eine einzelne Manifestdatei mit dem folgenden Inhalt: ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "87cb19095dd5d78fcaf56384ef0e6241", "mtime": 1721147454416085, "path": "home/cloudshell-user/job_attachments_devguide/script.sh", "size": 39 }, { "hash": "af5a605a3a4e86ce7be7ac5237b51b79", "mtime": 1721163773582362, "path": "shared/projects/project2/file.txt", "size": 44 } ], "totalSize": 83 } ``` Verwenden Sie die [GetJob Operation](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) für das Manifest, um zu überprüfen, ob der „/“ `rootPath` ist. ``` aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID --query 'attachments.manifests[*]' ``` Der Stammpfad für eine Reihe von Eingabedateien ist immer der längste gemeinsame Unterpfad dieser Dateien. Wenn Ihr Job Windows stattdessen von eingereicht wurde und es Eingabedateien ohne gemeinsamen Unterpfad gibt, weil sie sich auf unterschiedlichen Laufwerken befanden, sehen Sie auf jedem Laufwerk einen eigenen Stammpfad. Die Pfade in einem Manifest beziehen sich immer auf den Stammpfad des Manifests. Es wurden also folgende Eingabedateien hochgeladen: + `/home/cloudshell-user/job_attachments_devguide/script.sh`— Die Skriptdatei im Job-Bundle. + `/shared/projects/project2/file.txt`— Die Datei an einem `SHARED` Dateisystemspeicherort im `WSAll` Speicherprofil, der **nicht** in der Liste der erforderlichen Dateisystemspeicherorte für die Warteschlange enthalten ist`Q1`. Die Dateien an den Dateisystemspeicherorten `FSCommon` (`/shared/common/file.txt`) und `FS1` (`/shared/projects/project1/file.txt`) sind nicht in der Liste enthalten. Dies liegt daran, dass sich diese Dateisystemspeicherorte `SHARED` im `WSAll` Speicherprofil und beide in der Liste der erforderlichen Dateisystemspeicherorte in der Warteschlange befinden`Q1`. Sie können die Dateisystemspeicherorte sehen, die `SHARED` für einen Job in Betracht gezogen werden, der mit einem bestimmten Speicherprofil im Rahmen des [GetStorageProfileForQueue Vorgangs](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetStorageProfileForQueue.html) eingereicht wird. `Q1`Verwenden Sie den folgenden Befehl, um das Speicherprofil `WSAll` für die Warteschlange abzufragen: ``` aws deadline get-storage-profile --farm-id $FARM_ID --storage-profile-id $WSALL_ID aws deadline get-storage-profile-for-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID --storage-profile-id $WSALL_ID ``` # Wie finden Jobs Eingabedateien für Jobanhänge Damit ein Job die Dateien verwenden kann, die Deadline Cloud mithilfe von Job-Anhängen auf Amazon S3 hochlädt, benötigt Ihr Job diese Dateien, die über das Dateisystem auf den Worker-Hosts verfügbar sind. Wenn eine [Sitzung](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#sessions) für Ihren Job auf einem Worker-Host läuft, lädt Deadline Cloud die Eingabedateien für den Job in ein temporäres Verzeichnis auf dem lokalen Laufwerk des Worker-Hosts herunter und fügt Pfadzuordnungsregeln für jeden Root-Pfad des Jobs zu seinem Dateisystem-Speicherort auf dem lokalen Laufwerk hinzu. Starten Sie für dieses Beispiel den Deadline Cloud-Worker-Agent auf einer CloudShell AWS-Tab. Lassen Sie alle zuvor eingereichten Jobs fertig laufen und löschen Sie dann die Job-Logs aus dem Logs-Verzeichnis: ``` rm -rf ~/devdemo-logs/queue-* ``` Das folgende Skript ändert das Job-Bundle so, dass es alle Dateien im temporären Arbeitsverzeichnis der Sitzung und den Inhalt der Datei mit den Pfadzuordnungsregeln anzeigt, und sendet dann einen Job mit dem geänderten Paket: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff deadline config set settings.storage_profile_id $WSALL_ID cat > ~/job_attachments_devguide/script.sh << EOF #!/bin/bash echo "Session working directory is: \$(pwd)" echo echo "Contents:" find . -type f echo echo "Path mapping rules file: \$1" jq . \$1 EOF cat > ~/job_attachments_devguide/template.yaml << EOF specificationVersion: jobtemplate-2023-09 name: "Job Attachments Explorer" parameterDefinitions: - name: ScriptFile type: PATH default: script.sh dataFlow: IN objectType: FILE steps: - name: Step script: actions: onRun: command: /bin/bash args: - "{{Param.ScriptFile}}" - "{{Session.PathMappingRulesFile}}" EOF deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/ ``` Sie können sich das Protokoll der Ausführung des Jobs ansehen, nachdem er vom Worker in Ihrer AWS CloudShell Umgebung ausgeführt wurde: ``` cat demoenv-logs/queue-*/session*.log ``` Aus dem Protokoll geht hervor, dass in der Sitzung als Erstes die beiden Eingabedateien für den Job auf den Worker heruntergeladen werden: ``` 2024-07-17 01:26:37,824 INFO ============================================== 2024-07-17 01:26:37,825 INFO --------- Job Attachments Download for Job 2024-07-17 01:26:37,825 INFO ============================================== 2024-07-17 01:26:37,825 INFO Syncing inputs using Job Attachments 2024-07-17 01:26:38,116 INFO Downloaded 142.0 B / 186.0 B of 2 files (Transfer rate: 0.0 B/s) 2024-07-17 01:26:38,174 INFO Downloaded 186.0 B / 186.0 B of 2 files (Transfer rate: 733.0 B/s) 2024-07-17 01:26:38,176 INFO Summary Statistics for file downloads: Processed 2 files totaling 186.0 B. Skipped re-processing 0 files totaling 0.0 B. Total processing time of 0.09752 seconds at 1.91 KB/s. ``` Als Nächstes folgt die Ausgabe von `script.sh` run by the job: + Die Eingabedateien, die beim Absenden des Jobs hochgeladen wurden, befinden sich in einem Verzeichnis, dessen Name mit „assetroot“ beginnt, im temporären Verzeichnis der Sitzung. + Die Pfade der Eingabedateien wurden relativ zum Verzeichnis „assetroot“ verschoben und nicht relativ zum Stammpfad für das Eingabemanifest des Jobs (). `"/"` + Die Datei mit den Regeln für die Pfadzuweisung enthält eine zusätzliche Regel, die dem absoluten Pfad des `"/"` Verzeichnisses „assetroot“ neu zugeordnet wird. Beispiel: ``` 2024-07-17 01:26:38,264 INFO Output: 2024-07-17 01:26:38,267 INFO Session working directory is: /sessions/session-5b33f 2024-07-17 01:26:38,267 INFO 2024-07-17 01:26:38,267 INFO Contents: 2024-07-17 01:26:38,269 INFO ./tmp_xdhbsdo.sh 2024-07-17 01:26:38,269 INFO ./tmpdi00052b.json 2024-07-17 01:26:38,269 INFO ./assetroot-assetroot-3751a/shared/projects/project2/file.txt 2024-07-17 01:26:38,269 INFO ./assetroot-assetroot-3751a/home/cloudshell-user/job_attachments_devguide/script.sh 2024-07-17 01:26:38,269 INFO 2024-07-17 01:26:38,270 INFO Path mapping rules file: /sessions/session-5b33f/tmpdi00052b.json 2024-07-17 01:26:38,282 INFO { 2024-07-17 01:26:38,282 INFO "version": "pathmapping-1.0", 2024-07-17 01:26:38,282 INFO "path_mapping_rules": [ 2024-07-17 01:26:38,282 INFO { 2024-07-17 01:26:38,282 INFO "source_path_format": "POSIX", 2024-07-17 01:26:38,282 INFO "source_path": "/shared/projects/project1", 2024-07-17 01:26:38,283 INFO "destination_path": "/mnt/projects/project1" 2024-07-17 01:26:38,283 INFO }, 2024-07-17 01:26:38,283 INFO { 2024-07-17 01:26:38,283 INFO "source_path_format": "POSIX", 2024-07-17 01:26:38,283 INFO "source_path": "/shared/common", 2024-07-17 01:26:38,283 INFO "destination_path": "/mnt/common" 2024-07-17 01:26:38,283 INFO }, 2024-07-17 01:26:38,283 INFO { 2024-07-17 01:26:38,283 INFO "source_path_format": "POSIX", 2024-07-17 01:26:38,283 INFO "source_path": "/", 2024-07-17 01:26:38,283 INFO "destination_path": "/sessions/session-5b33f/assetroot-assetroot-3751a" 2024-07-17 01:26:38,283 INFO } 2024-07-17 01:26:38,283 INFO ] 2024-07-17 01:26:38,283 INFO } ``` **Anmerkung** Wenn der Job, den Sie einreichen, mehrere Manifeste mit unterschiedlichen Stammpfaden enthält, gibt es für jeden Stammpfad ein anderes Verzeichnis mit dem Namen „assetroot“. Wenn Sie auf den verschobenen Dateisystemspeicherort einer Ihrer Eingabedateien, Verzeichnisse oder Dateisystemverzeichnisse verweisen müssen, können Sie entweder die Datei mit den Pfadzuordnungsregeln in Ihrem Job verarbeiten und die Neuzuordnung selbst durchführen oder der Jobvorlage in Ihrem Job-Bundle einen `PATH` Typ-Job-Parameter hinzufügen und den Wert, den Sie neu zuordnen müssen, als Wert dieses Parameters übergeben. Im folgenden Beispiel wird das Auftragspaket so geändert, dass es einen dieser Auftragsparameter hat, und sendet dann einen Job mit dem Speicherort des Dateisystems `/shared/projects/project2` als Wert: ``` cat > ~/job_attachments_devguide/template.yaml << EOF specificationVersion: jobtemplate-2023-09 name: "Job Attachments Explorer" parameterDefinitions: - name: LocationToRemap type: PATH steps: - name: Step script: actions: onRun: command: /bin/echo args: - "The location of {{RawParam.LocationToRemap}} in the session is {{Param.LocationToRemap}}" EOF deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/ \ -p LocationToRemap=/shared/projects/project2 ``` Die Protokolldatei für die Ausführung dieses Jobs enthält seine Ausgabe: ``` 2024-07-17 01:40:35,283 INFO Output: 2024-07-17 01:40:35,284 INFO The location of /shared/projects/project2 in the session is /sessions/session-5b33f/assetroot-assetroot-3751a ``` # Ausgabedateien von einem Job abrufen Dieses Beispiel zeigt, wie Deadline Cloud die von Ihren Jobs generierten Ausgabedateien identifiziert, entscheidet, ob diese Dateien auf Amazon S3 hochgeladen werden sollen, und wie Sie diese Ausgabedateien auf Ihre Workstation übertragen können. Verwenden Sie für dieses Beispiel das `job_attachments_devguide_output` Job-Bundle anstelle des `job_attachments_devguide` Job-Bundles. Erstellen Sie zunächst eine Kopie des Bundles in Ihrer AWS CloudShell Umgebung aus Ihrem Klon des Deadline GitHub Cloud-Beispiel-Repositorys: ``` cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide_output ~/ ``` Der wichtige Unterschied zwischen diesem Job-Bundle und dem `job_attachments_devguide` Job-Bundle besteht darin, dass der Jobvorlage ein neuer Job-Parameter hinzugefügt wurde: ``` ... parameterDefinitions: ... - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT default: ./output_dir description: This directory contains the output for all steps. ... ``` Die `dataFlow` Eigenschaft des Parameters hat den Wert`OUT`. Deadline Cloud verwendet den Wert von `dataFlow` Jobparametern mit einem Wert von `OUT` oder `INOUT` als Ausgabe Ihres Jobs. Wenn der Dateisystemspeicherort, der als Wert an diese Art von Jobparametern übergeben wurde, einem lokalen Dateisystemspeicherort auf dem Worker, der den Job ausführt, neu zugeordnet wird, sucht Deadline Cloud an dem Speicherort nach neuen Dateien und lädt diese als Jobausgaben auf Amazon S3 hoch. Um zu sehen, wie das funktioniert, starten Sie zunächst den Deadline Cloud-Worker-Agent in einem AWS CloudShell Tab. Lassen Sie alle zuvor eingereichten Jobs die Ausführung beenden. Löschen Sie anschließend die Jobprotokolle aus dem Protokollverzeichnis: ``` rm -rf ~/devdemo-logs/queue-* ``` Reichen Sie als Nächstes einen Job mit diesem Job-Bundle ein. Nachdem der Worker in Ihren CloudShell Läufen ausgeführt wurde, schauen Sie sich die Logs an: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff deadline config set settings.storage_profile_id $WSALL_ID deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID ./job_attachments_devguide_output ``` Das Protokoll zeigt, dass eine Datei als Ausgabe erkannt und auf Amazon S3 hochgeladen wurde: ``` 2024-07-17 02:13:10,873 INFO ---------------------------------------------- 2024-07-17 02:13:10,873 INFO Uploading output files to Job Attachments 2024-07-17 02:13:10,873 INFO ---------------------------------------------- 2024-07-17 02:13:10,873 INFO Started syncing outputs using Job Attachments 2024-07-17 02:13:10,955 INFO Found 1 file totaling 117.0 B in output directory: /sessions/session-7efa/assetroot-assetroot-3751a/output_dir 2024-07-17 02:13:10,956 INFO Uploading output manifest to DeadlineCloud/Manifests/farm-0011/queue-2233/job-4455/step-6677/task-6677-0/2024-07-17T02:13:10.835545Z_sessionaction-8899-1/c6808439dfc59f86763aff5b07b9a76c_output 2024-07-17 02:13:10,988 INFO Uploading 1 output file to S3: s3BucketName/DeadlineCloud/Data 2024-07-17 02:13:11,011 INFO Uploaded 117.0 B / 117.0 B of 1 file (Transfer rate: 0.0 B/s) 2024-07-17 02:13:11,011 INFO Summary Statistics for file uploads: Processed 1 file totaling 117.0 B. Skipped re-processing 0 files totaling 0.0 B. Total processing time of 0.02281 seconds at 5.13 KB/s. ``` Das Protokoll zeigt auch, dass Deadline Cloud ein neues Manifest-Objekt im Amazon S3 S3-Bucket erstellt hat, das für die Verwendung durch Jobanhänge in der Warteschlange konfiguriert ist`Q1`. Der Name des Manifest-Objekts wird von der Farm, der Warteschlange, dem Job, dem Schritt, der Aufgabe, dem Zeitstempel und den `sessionaction` Bezeichnern der Aufgabe abgeleitet, die die Ausgabe generiert hat. Laden Sie diese Manifestdatei herunter, um zu sehen, wo Deadline Cloud die Ausgabedateien für diese Aufgabe abgelegt hat: ``` # The name of queue `Q1`'s job attachments S3 bucket Q1_S3_BUCKET=$( aws deadline get-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --query 'jobAttachmentSettings.s3BucketName' | tr -d '"' ) # Fill this in with the object name from your log OBJECT_KEY="DeadlineCloud/Manifests/..." aws s3 cp --quiet s3://$Q1_S3_BUCKET/$OBJECT_KEY /dev/stdout | jq . ``` Das Manifest sieht wie folgt aus: ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "34178940e1ef9956db8ea7f7c97ed842", "mtime": 1721182390859777, "path": "output_dir/output.txt", "size": 117 } ], "totalSize": 117 } ``` Dies zeigt, dass der Inhalt der Ausgabedatei auf die gleiche Weise in Amazon S3 gespeichert wird wie Jobeingabedateien. Ähnlich wie Eingabedateien wird die Ausgabedatei in S3 mit einem Objektnamen gespeichert, der den Hash der Datei und das Präfix enthält`DeadlineCloud/Data`. ``` $ aws s3 ls --recursive s3://$Q1_S3_BUCKET | grep 34178940e1ef9956db8ea7f7c97ed842 2024-07-17 02:13:11 117 DeadlineCloud/Data/34178940e1ef9956db8ea7f7c97ed842.xxh128 ``` Sie können die Ausgabe eines Jobs mit dem Deadline Cloud-Monitor oder der Deadline Cloud-CLI auf Ihre Workstation herunterladen: ``` deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID ``` Der Wert des `OutputDir` Job-Parameters im übermittelten Job ist`./output_dir`, sodass die Ausgabe in ein Verzeichnis heruntergeladen wird, das `output_dir` innerhalb des Job-Bundle-Verzeichnisses aufgerufen wird. Wenn Sie einen absoluten Pfad oder einen anderen relativen Speicherort als Wert für angegeben haben`OutputDir`, würden die Ausgabedateien stattdessen an diesen Speicherort heruntergeladen. ``` $ deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID Downloading output from Job 'Job Attachments Explorer: Output' Summary of files to download: /home/cloudshell-user/job_attachments_devguide_output/output_dir/output.txt (1 file) You are about to download files which may come from multiple root directories. Here are a list of the current root directories: [0] /home/cloudshell-user/job_attachments_devguide_output > Please enter the index of root directory to edit, y to proceed without changes, or n to cancel the download (0, y, n) [y]: Downloading Outputs [####################################] 100% Download Summary: Downloaded 1 files totaling 117.0 B. Total download time of 0.14189 seconds at 824.0 B/s. Download locations (total file counts): /home/cloudshell-user/job_attachments_devguide_output (1 file) ``` # Dateien aus einem Schritt in einem abhängigen Schritt verwenden Dieses Beispiel zeigt, wie ein Schritt in einem Job auf die Ausgaben eines Schritts zugreifen kann, von dem er im selben Job abhängt. Um die Ergebnisse eines Schritts für einen anderen verfügbar zu machen, fügt Deadline Cloud einer Sitzung zusätzliche Aktionen hinzu, um diese Ausgaben herunterzuladen, bevor Aufgaben in der Sitzung ausgeführt werden. Sie teilen ihr mit, aus welchen Schritten die Ausgaben heruntergeladen werden sollen, indem Sie diese Schritte als Abhängigkeiten des Schritts deklarieren, der die Ausgaben verwenden muss. Verwenden Sie das `job_attachments_devguide_output` Job-Bundle für dieses Beispiel. Erstellen Sie zunächst in Ihrer AWS CloudShell Umgebung eine Kopie von Ihrem Klon des Deadline GitHub Cloud-Beispiel-Repositorys. Ändern Sie ihn, um einen abhängigen Schritt hinzuzufügen, der erst nach dem vorhandenen Schritt ausgeführt wird und die Ausgabe dieses Schritts verwendet: ``` cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide_output ~/ cat >> job_attachments_devguide_output/template.yaml << EOF - name: DependentStep dependencies: - dependsOn: Step script: actions: onRun: command: /bin/cat args: - "{{Param.OutputDir}}/output.txt" EOF ``` Der mit diesem modifizierten Auftragspaket erstellte Job wird in zwei separaten Sitzungen ausgeführt, eine für die Aufgabe im Schritt „Schritt“ und dann eine zweite für die Aufgabe im Schritt "DependentStep“. Starten Sie zunächst den Deadline Cloud-Worker-Agent in einem CloudShell Tab. Lassen Sie alle zuvor eingereichten Jobs fertig laufen und löschen Sie dann die Job-Logs aus dem Logs-Verzeichnis: ``` rm -rf ~/devdemo-logs/queue-* ``` Als Nächstes reichen Sie einen Job mit dem geänderten `job_attachments_devguide_output` Auftragspaket ein. Warten Sie, bis die Ausführung auf dem Worker in Ihrer CloudShell Umgebung abgeschlossen ist. Sehen Sie sich die Protokolle der beiden Sitzungen an: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff deadline config set settings.storage_profile_id $WSALL_ID deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID ./job_attachments_devguide_output # Wait for the job to finish running, and then: cat demoenv-logs/queue-*/session-* ``` Im Sitzungsprotokoll für die Aufgabe im genannten `DependentStep` Schritt werden zwei separate Download-Aktionen ausgeführt: ``` 2024-07-17 02:52:05,666 INFO ============================================== 2024-07-17 02:52:05,666 INFO --------- Job Attachments Download for Job 2024-07-17 02:52:05,667 INFO ============================================== 2024-07-17 02:52:05,667 INFO Syncing inputs using Job Attachments 2024-07-17 02:52:05,928 INFO Downloaded 207.0 B / 207.0 B of 1 file (Transfer rate: 0.0 B/s) 2024-07-17 02:52:05,929 INFO Summary Statistics for file downloads: Processed 1 file totaling 207.0 B. Skipped re-processing 0 files totaling 0.0 B. Total processing time of 0.03954 seconds at 5.23 KB/s. 2024-07-17 02:52:05,979 INFO 2024-07-17 02:52:05,979 INFO ============================================== 2024-07-17 02:52:05,979 INFO --------- Job Attachments Download for Step 2024-07-17 02:52:05,979 INFO ============================================== 2024-07-17 02:52:05,980 INFO Syncing inputs using Job Attachments 2024-07-17 02:52:06,133 INFO Downloaded 117.0 B / 117.0 B of 1 file (Transfer rate: 0.0 B/s) 2024-07-17 02:52:06,134 INFO Summary Statistics for file downloads: Processed 1 file totaling 117.0 B. Skipped re-processing 0 files totaling 0.0 B. Total processing time of 0.03227 seconds at 3.62 KB/s. ``` Bei der ersten Aktion wird die `script.sh` Datei heruntergeladen, die für den Schritt mit dem Namen „Schritt“ verwendet wurde. Bei der zweiten Aktion werden die Ausgaben aus diesem Schritt heruntergeladen. Deadline Cloud bestimmt, welche Dateien heruntergeladen werden sollen, indem das in diesem Schritt generierte Ausgabemanifest als Eingabemanifest verwendet wird. Später im selben Protokoll können Sie die Ausgabe des Schritts "DependentStep„sehen: ``` 2024-07-17 02:52:06,213 INFO Output: 2024-07-17 02:52:06,216 INFO Script location: /sessions/session-5b33f/assetroot-assetroot-3751a/script.sh ``` # Ressourcenlimits für Jobs erstellen Jobs, die an Deadline Cloud übermittelt werden, können von Ressourcen abhängen, die von mehreren Jobs gemeinsam genutzt werden. Beispielsweise kann eine Farm mehr Mitarbeiter als variable Lizenzen für eine bestimmte Ressource haben. Oder ein gemeinsam genutzter Dateiserver kann möglicherweise nur einer begrenzten Anzahl von Workern gleichzeitig Daten bereitstellen. In einigen Fällen können ein oder mehrere Jobs all diese Ressourcen beanspruchen, was aufgrund nicht verfügbarer Ressourcen zu Fehlern führt, wenn neue Mitarbeiter eingestellt werden. Um dieses Problem zu lösen, können Sie *Grenzwerte* für diese begrenzten Ressourcen verwenden. Deadline Cloud berücksichtigt die Verfügbarkeit eingeschränkter Ressourcen und verwendet diese Informationen, um sicherzustellen, dass Ressourcen verfügbar sind, wenn neue Mitarbeiter ihre Arbeit aufnehmen, sodass die Wahrscheinlichkeit geringer ist, dass Jobs aufgrund nicht verfügbarer Ressourcen ausfallen. Grenzwerte werden für die gesamte Farm erstellt. Für Aufträge, die an eine Warteschlange gesendet werden, können nur Limits gelten, die der Warteschlange zugeordnet sind. Wenn Sie ein Limit für einen Job angeben, der nicht mit der Warteschlange verknüpft ist, ist der Job nicht kompatibel und kann nicht ausgeführt werden. Um ein Limit zu verwenden, müssen Sie + [Erstellen Sie ein Limit](job-limit-create.md) + [Ordnen Sie ein Limit und einer Warteschlange zu](job-limit-associate.md) + [Reichen Sie einen Job ein, der Limits erfordert](job-limit-job.md) **Anmerkung** Wenn Sie einen Job mit eingeschränkten Ressourcen in einer Warteschlange ausführen, der kein Limit zugeordnet ist, kann dieser Job alle Ressourcen verbrauchen. Wenn Sie über eine eingeschränkte Ressource verfügen, stellen Sie sicher, dass alle Schritte in Aufträgen in Warteschlangen, die die Ressource verwenden, mit einem Limit verknüpft sind. Bei Grenzwerten, die in einer Farm definiert, einer Warteschlange zugeordnet und in einem Job angegeben sind, kann eines von vier Dingen passieren: + Wenn Sie ein Limit erstellen, es einer Warteschlange zuordnen und das Limit in der Vorlage eines Jobs angeben, wird der Job ausgeführt und verwendet nur die im Limit definierten Ressourcen. + Wenn Sie ein Limit erstellen, es in einer Jobvorlage angeben, das Limit aber keiner Warteschlange zuordnen, wird der Job als inkompatibel markiert und kann nicht ausgeführt werden. + Wenn Sie ein Limit erstellen, es keiner Warteschlange zuordnen und das Limit nicht in der Vorlage eines Jobs angeben, wird der Job ausgeführt, verwendet das Limit aber nicht. + Wenn Sie überhaupt kein Limit verwenden, wird der Job ausgeführt. Wenn Sie mehreren Warteschlangen ein Limit zuordnen, teilen sich die Warteschlangen die Ressourcen, für die das Limit gilt. Wenn Sie beispielsweise ein Limit von 100 erstellen und eine Warteschlange 60 Ressourcen verwendet, können andere Warteschlangen nur 40 Ressourcen verwenden. Wenn eine Ressource freigegeben wird, kann sie von einer Aufgabe aus einer beliebigen Warteschlange übernommen werden. Deadline Cloud bietet zwei AWS CloudFormation Messwerte, mit denen Sie die durch ein Limit bereitgestellten Ressourcen überwachen können. Sie können die aktuelle Anzahl der verwendeten Ressourcen und die maximale Anzahl der Ressourcen, die im Rahmen des Limits verfügbar sind, überwachen. Weitere Informationen finden Sie unter [Kennzahlen zum Ressourcenlimit](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits) im *Deadline Cloud Developer Guide*. Sie wenden ein Limit auf einen Auftragsschritt in einer Jobvorlage an. Wenn Sie im `amounts` Abschnitt eines Schritts den Namen der Mengenanforderung für ein Limit angeben und der Warteschlange des Jobs ein Limit zugeordnet `amountRequirementName` wird, werden die für diesen Schritt geplanten Aufgaben durch das Limit für die Ressource eingeschränkt. `hostRequirements` Wenn für einen Schritt eine Ressource erforderlich ist, die durch ein erreichtes Limit eingeschränkt ist, werden die Aufgaben in diesem Schritt nicht von weiteren Mitarbeitern übernommen. Sie können mehr als ein Limit auf einen Arbeitsschritt anwenden. Wenn in diesem Schritt beispielsweise zwei verschiedene Softwarelizenzen verwendet werden, können Sie für jede Lizenz ein eigenes Limit festlegen. Wenn für einen Schritt zwei Grenzwerte erforderlich sind und das Limit für eine der Ressourcen erreicht ist, werden Aufgaben in diesem Schritt nicht von weiteren Mitarbeitern übernommen, bis die Ressourcen verfügbar sind. ## Beenden und Löschen von Grenzwerten Wenn Sie die Zuordnung zwischen einer Warteschlange und einem Limit beenden oder löschen, beendet ein Job, der das Limit verwendet, die Planung von Aufgaben für Schritte, die dieses Limit erfordern, und blockiert die Erstellung neuer Sitzungen für einen Schritt. Aufgaben, die sich im Status BEREIT befinden, bleiben bereit, und Aufgaben werden automatisch fortgesetzt, sobald die Verbindung zwischen der Warteschlange und dem Limit wieder aktiv wird. Sie müssen keine Jobs in die Warteschlange stellen. Wenn Sie die Zuordnung zwischen einer Warteschlange und einem Limit beenden oder löschen, haben Sie zwei Möglichkeiten, die Ausführung von Aufgaben zu beenden: + Aufgaben beenden und stornieren — Mitarbeiter mit Sitzungen, die das Limit erreicht haben, stornieren alle Aufgaben. + Ausführen von Aufgaben beenden und beenden — Mitarbeiter mit Sitzungen, die das Limit erreicht haben, erledigen ihre Aufgaben. Wenn Sie ein Limit über die Konsole löschen, beenden die Mitarbeiter zunächst die Ausführung von Aufgaben sofort oder erst, wenn sie abgeschlossen sind. Wenn die Zuordnung gelöscht wird, passiert Folgendes: + Schritte, für die das Limit erforderlich ist, sind als nicht kompatibel gekennzeichnet. + Der gesamte Job, der diese Schritte enthält, wird abgebrochen, einschließlich der Schritte, für die das Limit nicht erforderlich ist. + Der Job ist als nicht kompatibel markiert. Wenn der Warteschlange, die dem Limit zugeordnet ist, eine Flotte mit einer Flottenkapazität zugeordnet ist, die dem Mengenanforderungsnamen des Limits entspricht, verarbeitet diese Flotte weiterhin Aufträge mit dem angegebenen Limit. # Erstellen Sie ein Limit Sie erstellen ein Limit mit der Deadline Cloud-Konsole oder dem [CreateLimit Vorgang in der Deadline Cloud-API](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html). Limits sind für eine Farm definiert, aber mit Warteschlangen verknüpft. Nachdem Sie ein Limit erstellt haben, können Sie es einer oder mehreren Warteschlangen zuordnen. **Um ein Limit zu erstellen** 1. Wählen Sie im Dashboard der [Deadline Cloud-Konsole (Deadline Cloud-Konsole](https://console.aws.amazon.com/deadlinecloud/home)) die Farm aus, für die Sie eine Warteschlange erstellen möchten. 1. Wählen Sie die Farm aus, zu der Sie das Limit hinzufügen möchten, wählen Sie den Tab **Limits** und dann **Limit erstellen** aus. 1. Geben Sie die Details für das Limit ein. Der **Name der Mengenanforderung** ist der Name, der in der Jobvorlage verwendet wird, um das Limit zu identifizieren. Er muss mit dem Präfix beginnen, **amount.** gefolgt von der Bezeichnung des Betrags. Der Name der Mengenanforderung muss in den Warteschlangen, die mit dem Limit verknüpft sind, eindeutig sein. 1. Wenn Sie „**Höchstbetrag festlegen**“ wählen, entspricht dies der Gesamtanzahl der Ressourcen, die nach diesem Limit zulässig sind. Wenn Sie „**Kein Höchstbetrag**“ wählen, ist die Ressourcennutzung nicht begrenzt. Auch wenn die Ressourcennutzung nicht begrenzt ist, wird die `CurrentCount` CloudWatch Amazon-Metrik ausgegeben, sodass Sie die Nutzung verfolgen können. Weitere Informationen finden Sie unter [CloudWatchMetriken](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html) im *Deadline Cloud Developer Guide*. 1. Wenn Sie bereits wissen, für welche Warteschlangen das Limit verwendet werden soll, können Sie sie jetzt auswählen. Sie müssen keine Warteschlange zuordnen, um ein Limit zu erstellen. 1. Wählen Sie **Limit erstellen** aus. # Ordnen Sie ein Limit und einer Warteschlange zu Nachdem Sie ein Limit erstellt haben, können Sie dem Limit eine oder mehrere Warteschlangen zuordnen. Nur Warteschlangen, die einem Grenzwert zugeordnet sind, verwenden die im Grenzwert angegebenen Werte. Sie erstellen eine Zuordnung zu einer Warteschlange mithilfe der Deadline Cloud-Konsole oder des [CreateQueueLimitAssociation Vorgangs in der Deadline Cloud-API](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html). **Um eine Warteschlange mit einem Limit zu verknüpfen** 1. Wählen Sie im Dashboard der [Deadline Cloud-Konsole (Deadline Cloud-Konsole](https://console.aws.amazon.com/deadlinecloud/home)) die Farm aus, der Sie ein Limit mit einer Warteschlange verknüpfen möchten. 1. Wählen Sie den Tab **Limits**, wählen Sie das Limit aus, dem eine Warteschlange zugeordnet werden soll, und wählen Sie dann **Limit bearbeiten** aus. 1. Wählen **Sie im Abschnitt Warteschlangen zuordnen** die Warteschlangen aus, die dem Limit zugeordnet werden sollen. 1. Wählen Sie **Änderungen speichern ** aus. # Reichen Sie einen Job ein, der Limits erfordert Sie wenden ein Limit an, indem Sie es als Hostanforderung für den Job oder Job-Schritt angeben. Wenn Sie in einem Schritt kein Limit angeben und dieser Schritt eine zugeordnete Ressource verwendet, wird die Nutzung des Schritts nicht auf das Limit angerechnet, wenn Jobs geplant werden. Bei einigen Deadline Cloud-Einreichern können Sie eine Hostanforderung festlegen. Sie können den Namen des Limits im Absender angeben, um das Limit anzuwenden. Wenn Ihr Einreicher das Hinzufügen von Hostanforderungen nicht unterstützt, können Sie auch ein Limit festlegen, indem Sie die Jobvorlage für den Job bearbeiten. **Um ein Limit auf einen Job-Schritt im Job-Bundle anzuwenden** 1. Öffnen Sie die Jobvorlage für den Job mit einem Texteditor. Die Jobvorlage befindet sich im Job-Bundle-Verzeichnis für den Job. Weitere Informationen finden Sie unter [Job-Pakete](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/build-job-bundle.html) im *Deadline Cloud Developer Guide*. 1. Suchen Sie die Schrittdefinition für den Schritt, auf den das Limit angewendet werden soll. 1. Fügen Sie der Schrittdefinition Folgendes hinzu. *amount.name*Ersetzen Sie es durch den Namen der Mengenanforderung für Ihr Limit. Für den typischen Gebrauch sollten Sie den `min` Wert auf 1 setzen. ------ #### [ YAML ] ``` hostRequirements: amounts: - name: amount.name min: 1 ``` ------ #### [ JSON ] ``` "hostRequirements": { "amounts": [ { "name": "amount.name", "min": "1" } } } ``` ------ Sie können einem Auftragsschritt wie folgt mehrere Grenzwerte hinzufügen. Ersetzen Sie *amount.name\$11* und *amount.name\$12* durch die Namen der Mengenanforderungen Ihrer Limits. ------ #### [ YAML ] ``` hostRequirements: amounts: - name: amount.name_1 min: 1 - name: amount.name_2 min: 1 ``` ------ #### [ JSON ] ``` "hostRequirements": { "amounts": [ { "name": "amount.name_1", "min": "1" }, { "name": "amount.name_2", "min": "1" } } } ``` ------ 1. Speichern Sie die Änderungen an der Jobvorlage. # So reichen Sie einen Job bei Deadline Cloud ein Es gibt viele verschiedene Möglichkeiten, Jobs bei AWS Deadline Cloud einzureichen. In diesem Abschnitt werden einige der Möglichkeiten beschrieben, wie Sie Jobs mithilfe der von Deadline Cloud bereitgestellten Tools oder durch die Erstellung eigener benutzerdefinierter Tools für Ihre Workloads einreichen können. + Von einem Terminal aus — wenn Sie zum ersten Mal ein Jobpaket entwickeln oder wenn Benutzer, die einen Job einreichen, sich mit der Befehlszeile auskennen + Aus einem Skript — zur Anpassung und Automatisierung von Workloads + Aus einer Anwendung — wenn die Arbeit des Benutzers in einer Anwendung stattfindet oder wenn der Kontext einer Anwendung wichtig ist. In den folgenden Beispielen werden die `deadline` Python-Bibliothek und das `deadline` Befehlszeilentool verwendet. Beide sind verfügbar [PyPi](https://pypi.org/project/deadline/)und werden [dort gehostet GitHub](https://github.com/aws-deadline/deadline-cloud). **Topics** + [Senden Sie einen Job von einem Terminal aus an Deadline Cloud](from-a-terminal.md) + [Senden Sie einen Job mithilfe eines Skripts an Deadline Cloud](from-a-script.md) + [Reichen Sie eine Stelle innerhalb einer Bewerbung ein](from-within-applications.md) # Senden Sie einen Job von einem Terminal aus an Deadline Cloud Wenn Sie nur ein Job-Bundle und die Deadline Cloud-CLI verwenden, können Sie oder Ihre technisch versierten Benutzer schnell das Schreiben von Jobpaketen wiederholen, um das Einreichen eines Jobs zu testen. Verwenden Sie den folgenden Befehl, um ein Job-Bundle einzureichen: ``` deadline bundle submit ``` Wenn Sie ein Job-Bundle mit Parametern einreichen, für die das Paket keine Standardwerte enthält, können Sie diese mit der `--parameter` Option`-p`/angeben. ``` deadline bundle submit -p = -p ... ``` Führen Sie den Befehl help aus, um eine vollständige Liste der verfügbaren Optionen zu erhalten: ``` deadline bundle submit --help ``` ## Senden Sie einen Job über eine GUI an Deadline Cloud Die Deadline Cloud CLI verfügt außerdem über eine grafische Benutzeroberfläche, über die Benutzer die Parameter sehen können, die sie angeben müssen, bevor sie einen Job einreichen. Wenn Ihre Benutzer es vorziehen, nicht mit der Befehlszeile zu interagieren, können Sie eine Desktop-Verknüpfung schreiben, die einen Dialog zum Einreichen eines bestimmten Job-Bundles öffnet: ``` deadline bundle gui-submit ``` Verwenden Sie die `--browse` Option can, damit der Benutzer ein Jobpaket auswählen kann: ``` deadline bundle gui-submit --browse ``` Eine vollständige Liste der verfügbaren Optionen erhalten Sie, wenn Sie den Befehl help ausführen: ``` deadline bundle gui-submit --help ``` # Senden Sie einen Job mithilfe eines Skripts an Deadline Cloud Um das Senden von Jobs an Deadline Cloud zu automatisieren, können Sie sie mithilfe von Tools wie Bash, Powershell und Batch-Dateien skripten. Sie können Funktionen wie das Auffüllen von Jobparametern aus Umgebungsvariablen oder anderen Anwendungen hinzufügen. Sie können auch mehrere Jobs hintereinander einreichen oder die Erstellung eines Auftragspakets per Skript abschicken. ## Einen Job mit Python einreichen Deadline Cloud verfügt auch über eine Open-Source-Python-Bibliothek für die Interaktion mit dem Dienst. Der [Quellcode ist verfügbar auf GitHub](https://github.com/aws-deadline/deadline-cloud). Die Bibliothek ist auf pypi über pip () verfügbar. `pip install deadline` Es ist dieselbe Bibliothek, die vom Deadline Cloud CLI-Tool verwendet wird: ``` from deadline.client import api job_bundle_path = "/path/to/job/bundle" job_parameters = [ { "name": "parameter_name", "value": "parameter_value" }, ] job_id = api.create_job_from_job_bundle( job_bundle_path, job_parameters ) print(job_id) ``` Um einen Dialog wie den `deadline bundle gui-submit` Befehl zu erstellen, können Sie die `show_job_bundle_submitter` Funktion von verwenden [`deadline.client.ui.job_bundle_submitter`.](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/job_bundle_submitter.py) Das folgende Beispiel startet eine Qt-Anwendung und zeigt den Job Bundle Submitter: ``` # The GUI components must be installed with pip install "deadline[gui]" import sys from qtpy.QtWidgets import QApplication from deadline.client.ui.job_bundle_submitter import show_job_bundle_submitter app = QApplication(sys.argv) submitter = show_job_bundle_submitter(browse=True) submitter.show() app.exec() print(submitter.create_job_response) ``` Um Ihren eigenen Dialog zu erstellen, können Sie die `SubmitJobToDeadlineDialog` Klasse in verwenden. [https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/dialogs/submit_job_to_deadline_dialog.py](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/dialogs/submit_job_to_deadline_dialog.py) Sie können Werte übergeben, Ihren eigenen auftragsspezifischen Tab einbetten und festlegen, wie das Job-Bundle erstellt (oder übergeben) wird. # Reichen Sie eine Stelle innerhalb einer Bewerbung ein Um Benutzern das Einreichen von Jobs zu erleichtern, können Sie die von einer Anwendung bereitgestellten Skriptlaufzeiten oder Plugin-Systeme verwenden. Die Benutzer haben eine vertraute Oberfläche, und Sie können leistungsstarke Tools erstellen, die die Benutzer beim Einreichen eines Workloads unterstützen. ## Job-Bundles in eine Anwendung einbetten Dieses Beispiel zeigt das Einreichen von Auftragspaketen, die Sie in der Anwendung zur Verfügung stellen. Um einem Benutzer Zugriff auf diese Job-Bundles zu gewähren, erstellen Sie ein Skript, das in ein Menüelement eingebettet ist, das die Deadline Cloud-CLI startet. Das folgende Skript ermöglicht es einem Benutzer, das Job-Bundle auszuwählen: ``` deadline bundle gui-submit --install-gui ``` Um stattdessen ein bestimmtes Job-Bundle in einem Menüelement zu verwenden, verwenden Sie Folgendes: ``` deadline bundle gui-submit --install-gui ``` Dadurch wird ein Dialogfeld geöffnet, in dem der Benutzer die Jobparameter, Eingaben und Ausgaben ändern und den Job dann weiterleiten kann. Sie können verschiedene Menüelemente für verschiedene Jobpakete einrichten, die ein Benutzer in einer Bewerbung einreichen kann. Wenn der Job, den Sie mit einem Job-Bundle einreichen, bei allen Einreichungen ähnliche Parameter und Ressourcenreferenzen enthält, können Sie die Standardwerte in das zugrunde liegende Job-Bundle eingeben. ## Holen Sie sich Informationen aus einer Bewerbung Um Informationen aus einer Anwendung abzurufen, sodass Benutzer sie nicht manuell zur Einreichung hinzufügen müssen, können Sie Deadline Cloud in die Anwendung integrieren, sodass Ihre Benutzer Jobs über eine vertraute Oberfläche einreichen können, ohne die Anwendung beenden oder Befehlszeilentools verwenden zu müssen. Wenn Ihre Anwendung über eine Scripting-Runtime verfügt, die Python und pyside/pyqt unterstützt, können Sie die GUI-Komponenten aus der [Deadline Cloud-Clientbibliothek](https://github.com/aws-deadline/deadline-cloud) verwenden, um eine Benutzeroberfläche zu erstellen. Ein Beispiel finden Sie unter Integration von [Deadline Cloud für Maya](https://github.com/aws-deadline/deadline-cloud-for-maya) unter. GitHub Die Deadline Cloud-Clientbibliothek bietet Operationen, die Folgendes tun, um Ihnen zu helfen, ein starkes integriertes Benutzererlebnis zu bieten: + Rufen Sie die Umgebungsparameter, Jobparameter und Asset-Referenzen aus Umgebungsvariablen ab und rufen Sie das Anwendungs-SDK auf. + Legen Sie die Parameter im Job-Bundle fest. Um zu vermeiden, dass das ursprüngliche Paket geändert wird, sollten Sie eine Kopie des Bundles erstellen und die Kopie einreichen. Wenn Sie den `deadline bundle gui-submit` Befehl verwenden, um das Job-Bundle zu senden, müssen Sie die `parameter_values.yaml` und `asset_references.yaml` -Dateien programmgesteuert verwenden, um die Informationen aus der Anwendung zu übergeben. Weitere Informationen zu diesen Dateien finden Sie unter. [Vorlagen für offene Stellenbeschreibungen (OpenJD) für Deadline Cloud](build-job-bundle.md) Wenn Sie komplexere Steuerelemente als die von OpenJD angebotenen benötigen, den Job vom Benutzer abstrahieren müssen oder die Integration an den visuellen Stil der Anwendung anpassen möchten, können Sie Ihren eigenen Dialog schreiben, der die Deadline Cloud-Clientbibliothek aufruft, um den Job einzureichen. # Jobs in Deadline Cloud planen Nachdem ein Auftrag erstellt wurde, plant AWS Deadline Cloud, dass er in einer oder mehreren Flotten bearbeitet wird, die einer Warteschlange zugeordnet sind. Die Flotte, die eine bestimmte Aufgabe bearbeitet, wird auf der Grundlage der für die Flotte konfigurierten Funktionen und der Hostanforderungen eines bestimmten Schritts ausgewählt. Jobs in einer Warteschlange werden in der Reihenfolge der bestmöglichen Priorität geplant, von der höchsten zur niedrigsten Priorität. Wenn zwei Jobs dieselbe Priorität haben, wird der älteste Job zuerst geplant. In den folgenden Abschnitten wird detailliert beschrieben, wie ein Job geplant wird. ## Prüfen Sie die Flottenkompatibilität Nachdem ein Job erstellt wurde, vergleicht Deadline Cloud die Hostanforderungen für jeden Schritt im Job mit den Fähigkeiten der Flotten, die mit der Warteschlange verknüpft sind, an die der Job übermittelt wurde. Wenn eine Flotte die Hostanforderungen erfüllt, wird der Job in den `READY` Status versetzt. Wenn für einen Schritt des Jobs Anforderungen gelten, die von einer Flotte, die der Warteschlange zugeordnet ist, nicht erfüllt werden können, wird der Status des Schritts auf gesetzt`NOT_COMPATIBLE`. Außerdem werden die restlichen Schritte des Jobs storniert. Die Funktionen für eine Flotte werden auf Flottenebene festgelegt. Selbst wenn ein Mitarbeiter in einer Flotte die Anforderungen des Auftrags erfüllt, werden ihm keine Aufgaben aus dem Auftrag zugewiesen, wenn seine Flotte die Anforderungen des Auftrags nicht erfüllt. Die folgende Jobvorlage enthält einen Schritt, der die Hostanforderungen für den Schritt spezifiziert: ``` name: Sample Job With Host Requirements specificationVersion: jobtemplate-2023-09 steps: - name: Step 1 script: actions: onRun: args: - '1' command: /usr/bin/sleep hostRequirements: amounts: # Capabilities starting with "amount." are amount capabilities. If they start with "amount.worker.", # they are defined by the OpenJD specification. Other names are free for custom usage. - name: amount.worker.vcpu min: 4 max: 8 attributes: - name: attr.worker.os.family anyOf: - linux ``` Dieser Job kann für eine Flotte mit den folgenden Funktionen geplant werden: ``` { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } ``` Dieser Job kann nicht für eine Flotte mit einer der folgenden Funktionen geplant werden: ``` { "vCpuCount": {"min": 4}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } The vCpuCount has no maximum, so it exceeds the maximum vCPU host requirement. { "vCpuCount": {"max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } The vCpuCount has no minimum, so it doesn't satisfy the minimum vCPU host requirement. { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "windows", "cpuArchitectureType": "x86_64" } The osFamily doesn't match. ``` ## Skalierung der Flotte Wenn ein Auftrag einer kompatiblen, servicemanagierten Flotte zugewiesen wird, wird die Flotte auto skaliert. Die Anzahl der Mitarbeiter in der Flotte ändert sich je nach der Anzahl der Aufgaben, die der Flotte zur Ausführung zur Verfügung stehen. Wenn ein Auftrag einer vom Kunden verwalteten Flotte zugewiesen wird, sind Mitarbeiter möglicherweise bereits vorhanden oder können mithilfe von ereignisbasierter Autoskalierung erstellt werden. Weitere Informationen finden Sie unter [Verwenden EventBridge zur Behandlung von Auto Scaling-Ereignissen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) im *Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch*. ## Sitzungen Die Aufgaben in einem Job sind in eine oder mehrere Sitzungen aufgeteilt. Die Mitarbeiter führen die Sitzungen durch, um die Umgebung einzurichten, die Aufgaben auszuführen und dann die Umgebung zu zerstören. Jede Sitzung besteht aus einer oder mehreren Aktionen, die ein Mitarbeiter ausführen muss. Wenn ein Mitarbeiter Abschnittsaktionen abschließt, können zusätzliche Sitzungsaktionen an den Mitarbeiter gesendet werden. Der Mitarbeiter verwendet in der Sitzung vorhandene Umgebungen und Jobanhänge wieder, um Aufgaben effizienter zu erledigen. Bei dienstverwalteten Flottenarbeitern werden Sitzungsverzeichnisse nach dem Ende der Sitzung gelöscht, andere Verzeichnisse werden jedoch zwischen den Sitzungen beibehalten. Dieses Verhalten ermöglicht es Ihnen, Caching-Strategien für Daten zu implementieren, die in mehreren Sitzungen wiederverwendet werden können. Um Daten zwischen Sitzungen zwischenzuspeichern, speichern Sie sie im Home-Verzeichnis des Benutzers, der den Job ausführt. Beispielsweise werden Conda-Pakete im Home-Verzeichnis des Job-Benutzers unter `C:\Users\job-user\.conda-pkgs` on Windows workers und `/home/job-user/.conda-pkgs` on Linux workers zwischengespeichert. Diese Daten bleiben verfügbar, bis der Worker heruntergefahren wird. Jobanhänge werden vom Einreicher erstellt, den Sie als Teil Ihres Deadline Cloud CLI-Jobpakets verwenden. Mit der `--attachments` Option für den Befehl können Sie auch Jobanhänge erstellen. `create-job` AWS CLI Umgebungen werden an zwei Stellen definiert: Warteschlangenumgebungen, die an eine bestimmte Warteschlange angehängt sind, und Job- und Schrittumgebungen, die in der Jobvorlage definiert sind. Es gibt vier Arten von Sitzungsaktionen: + `syncInputJobAttachments`— Lädt die Eingabe-Job-Anhänge an den Worker herunter. + `envEnter`— Führt die `onEnter` Aktionen für eine Umgebung aus. + `taskRun`— Führt die `onRun` Aktionen für eine Aufgabe aus. + `envExit`— Führt die `onExit` Aktionen für eine Umgebung aus. Die folgende Jobvorlage hat eine Schrittumgebung. Sie enthält eine `onEnter` Definition zum Einrichten der Schrittumgebung, eine `onRun` Definition, die die auszuführende Aufgabe definiert, und eine `onExit` Definition zum Abbau der Schrittumgebung. Die für diesen Job erstellten Sitzungen umfassen eine `envEnter` Aktion, eine oder mehrere `taskRun` Aktionen und dann eine `envExit` Aktion. ``` name: Sample Job with Maya Environment specificationVersion: jobtemplate-2023-09 steps: - name: Maya Step stepEnvironments: - name: Maya description: Runs Maya in the background. script: embeddedFiles: - name: initData filename: init-data.yaml type: TEXT data: | scene_file: MyAwesomeSceneFile renderer: arnold camera: persp actions: onEnter: command: MayaAdaptor args: - daemon - start - --init-data - file://{{Env.File.initData}} onExit: command: MayaAdaptor args: - daemon - stop parameterSpace: taskParameterDefinitions: - name: Frame range: 1-5 type: INT script: embeddedFiles: - name: runData filename: run-data.yaml type: TEXT data: | frame: {{Task.Param.Frame}} actions: onRun: command: MayaAdaptor args: - daemon - run - --run-data - file://{{ Task.File.runData }} ``` ### Pipelining von Sitzungsaktionen Durch das Pipelining von Sitzungsaktionen kann ein Scheduler einem Worker mehrere Sitzungsaktionen vorab zuweisen. Der Worker kann diese Aktionen dann sequenziell ausführen, wodurch die Leerlaufzeit zwischen Aufgaben reduziert oder ganz vermieden wird. Um eine erste Zuweisung zu erstellen, erstellt der Scheduler eine Sitzung mit einer Aufgabe, der Worker erledigt die Aufgabe und anschließend analysiert der Scheduler die Aufgabendauer, um future Zuweisungen zu bestimmen. Damit der Scheduler effektiv ist, gibt es Regeln für die Aufgabendauer. Für Aufgaben unter einer Minute verwendet der Scheduler ein Power-of-2-Wachstumsmuster. Bei einer 1-Sekunden-Aufgabe weist der Scheduler beispielsweise 2 neue Aufgaben zu, dann 4 und dann 8. Für Aufgaben, die länger als eine Minute dauern, weist der Scheduler nur eine neue Aufgabe zu, und das Pipelining bleibt deaktiviert. Um die Pipeline-Größe zu berechnen, geht der Scheduler wie folgt vor: + Verwendet die durchschnittliche Aufgabendauer abgeschlossener Aufgaben + Zielt darauf ab, den Mitarbeiter eine Minute lang zu beschäftigen + Berücksichtigt nur Aufgaben innerhalb derselben Sitzung + Gibt Daten zur Dauer nicht an alle Mitarbeiter weiter Durch die Weiterleitung von Sitzungsaktionen können Mitarbeiter sofort mit neuen Aufgaben beginnen und es gibt keine Wartezeiten zwischen den Anfragen des Terminplaners. Es sorgt auch für eine höhere Effizienz der Mitarbeiter und eine bessere Aufgabenverteilung bei lang andauernden Prozessen. Wenn ein neuer Job mit höherer Priorität verfügbar ist, beendet der Mitarbeiter außerdem die gesamte ihm zuvor zugewiesene Arbeit, bevor die aktuelle Sitzung endet und eine neue Sitzung aus einem Job mit höherer Priorität zugewiesen wird. ## Abhängigkeiten der Schritte Deadline Cloud unterstützt die Definition von Abhängigkeiten zwischen Schritten, sodass ein Schritt wartet, bis ein anderer Schritt abgeschlossen ist, bevor er gestartet wird. Sie können mehr als eine Abhängigkeit für einen Schritt definieren. Ein Schritt mit einer Abhängigkeit wird erst geplant, wenn alle Abhängigkeiten abgeschlossen sind. Wenn die Jobvorlage eine zirkuläre Abhängigkeit definiert, wird der Job abgelehnt und der Jobstatus wird auf gesetzt`CREATE_FAILED`. Mit der folgenden Jobvorlage wird ein Job in zwei Schritten erstellt. `StepB`hängt davon ab`StepA`. `StepB`wird erst ausgeführt, nachdem der `StepA` Vorgang erfolgreich abgeschlossen wurde. Nachdem der Job erstellt wurde, `StepA` befindet er sich im `READY` Status und `StepB` befindet sich im `PENDING` Status. Wenn der `StepA` Vorgang abgeschlossen ist, `StepB` wechselt er in den `READY` Status. `StepA`Schlägt fehl oder wurde der `StepA` Vorgang abgebrochen, `StepB` wechselt er in den `CANCELED` Status. Sie können eine Abhängigkeit von mehreren Schritten festlegen. Wenn beispielsweise von beiden `StepA` und `StepC` abhängt`StepB`, `StepC` wird erst gestartet, wenn die anderen beiden Schritte abgeschlossen sind. Für Schrittabhängigkeiten gelten die folgenden Einschränkungen: + **Abhängigkeiten pro Schritt** — Ein Schritt kann von maximal 128 anderen Schritten abhängen. + **Verbraucher pro Schritt** — Maximal 32 weitere Schritte können von einem einzigen Schritt abhängen. ``` name: Step-Step Dependency Test specificationVersion: 'jobtemplate-2023-09' steps: - name: A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task A Done! - name: B dependencies: - dependsOn: A # This means Step B depends on Step A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task B Done! ``` # Einen Job in Deadline Cloud ändern Sie können die folgenden `update` Befehle AWS Command Line Interface (AWS CLI) verwenden, um die Konfiguration eines Jobs zu ändern oder den Zielstatus eines Jobs, Schritts oder einer Aufgabe festzulegen: `` + `aws deadline update-job` + `aws deadline update-step` + `aws deadline update-task` Ersetzen Sie in den folgenden `update` Befehlsbeispielen jeden Befehl *`user input placeholder`* durch Ihre eigenen Informationen. **Example — Einen Job erneut in die Warteschlange stellen** Alle Aufgaben im Job wechseln in den `READY` Status, sofern es keine Schrittabhängigkeiten gibt. Schritte mit Abhängigkeiten wechseln zu entweder `READY` oder`PENDING`, wenn sie wiederhergestellt werden. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status PENDING ``` **Example — Stornieren Sie einen Job** Alle Aufgaben im Job, die nicht den Status haben `SUCCEEDED` oder markiert `FAILED` sind`CANCELED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status CANCELED ``` **Example — Einen Job als fehlgeschlagen markieren** Alle Aufgaben im Job, die den Status haben, `SUCCEEDED` bleiben unverändert. Alle anderen Aufgaben sind markiert`FAILED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status FAILED ``` **Example — Markiere einen Job als erfolgreich** Alle Aufgaben im Job werden in den `SUCCEEDED` Bundesstaat übertragen. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUCCEEDED ``` **Example — Einen Job aussetzen** Die Aufgaben des Jobs im `FAILED` Status `SUCCEEDED``CANCELED`, oder ändern sich nicht. Alle anderen Aufgaben sind markiert`SUSPENDED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUSPENDED ``` **Example — Ändern Sie die Priorität eines Jobs** Aktualisiert die Priorität eines Jobs in einer Warteschlange, um die Reihenfolge zu ändern, in der er geplant wird. Jobs mit höherer Priorität werden in der Regel zuerst geplant. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --priority 100 ``` **Example — Ändert die Anzahl der zulässigen fehlgeschlagenen Aufgaben** Aktualisiert die maximale Anzahl fehlgeschlagener Aufgaben, die der Job haben kann, bevor die verbleibenden Aufgaben abgebrochen werden. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-failed-tasks-count 200 ``` **Example — Ändert die Anzahl der zulässigen Aufgabenwiederholungen** Aktualisiert die maximale Anzahl von Wiederholungen für eine Aufgabe, bevor die Aufgabe fehlschlägt. Eine Aufgabe, die die maximale Anzahl von Wiederholungen erreicht hat, kann erst in die Warteschlange gestellt werden, wenn dieser Wert erhöht wird. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-retries-per-task 10 ``` **Example — Archivieren Sie einen Job** Aktualisiert den Lebenszyklusstatus des Jobs auf`ARCHIVED`. Archivierte Jobs können nicht geplant oder geändert werden. Sie können nur einen Job archivieren, der sich im `SUSPENDED` Status `FAILED``CANCELED`,`SUCCEEDED`, oder befindet. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --lifecycle-status ARCHIVED ``` **Example — Ändern Sie den Namen eines Jobs** Aktualisiert den Anzeigenamen eines Jobs. Der Jobname kann bis zu 128 Zeichen lang sein. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --name "New Job Name" ``` **Example — Ändern Sie die Beschreibung eines Jobs** Aktualisiert die Beschreibung eines Jobs. Die Beschreibung kann bis zu 2048 Zeichen lang sein. Um die bestehende Beschreibung zu entfernen, übergeben Sie eine leere Zeichenfolge. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --description "New Job Description" ``` **Example — Einen Schritt erneut in die Warteschlange stellen** Alle Aufgaben im Schritt wechseln in den `READY` Status, sofern keine Schrittabhängigkeiten bestehen. Aufgaben in Schritten mit Abhängigkeiten wechseln entweder zu `READY` oder`PENDING`, und die Aufgabe wird wiederhergestellt. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status PENDING ``` **Example — Brechen Sie einen Schritt ab** Alle Aufgaben in dem Schritt, die nicht den Status haben `SUCCEEDED` oder markiert `FAILED` sind`CANCELED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status CANCELED ``` **Example — Einen Schritt als fehlgeschlagen markieren** Alle Aufgaben in dem Schritt, die den Status haben, `SUCCEEDED` bleiben unverändert. Alle anderen Aufgaben sind markiert`FAILED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status FAILED ``` **Example — Markiere einen Schritt als erfolgreich** Alle Aufgaben in dem Schritt sind markiert`SUCCEEDED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUCCEEDED ``` **Example — Einen Schritt aussetzen** Aufgaben im Schritt im `FAILED` Status `SUCCEEDED``CANCELED`, oder ändern sich nicht. Alle anderen Aufgaben sind markiert`SUSPENDED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUSPENDED ``` **Example — Den Status einer Aufgabe ändern** Wenn Sie den Befehl `update-task` Deadline Cloud CLI verwenden, wechselt die Aufgabe in den angegebenen Status. ``` aws deadline update-task \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --task-id taskID \ --target-task-run-status SUCCEEDED | SUSPENDED | CANCELED | FAILED | PENDING ```