Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Créez des jobs à soumettre à Deadline Cloud
<a name="building-jobs"></a>

Vous soumettez des offres d'emploi à Deadline Cloud à l'aide de lots de tâches. Un ensemble de tâches est un ensemble de fichiers, y compris un modèle de [tâche Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) et tous les fichiers d'actifs nécessaires au rendu de la tâche.

 Le modèle de tâche décrit la manière dont les travailleurs traitent les actifs et y accèdent, et fournit le script qu'ils exécutent. Les offres d'emploi permettent aux artistes, aux directeurs techniques et aux développeurs de pipelines de soumettre facilement des tâches complexes à Deadline Cloud depuis leur poste de travail local ou leur ferme de rendu sur site. Les offres d'emploi sont particulièrement utiles pour les équipes travaillant sur des projets d'effets visuels, d'animation ou de rendu multimédia à grande échelle qui nécessitent des ressources informatiques évolutives à la demande.

Vous pouvez créer le lot de tâches à l'aide du système de fichiers local pour stocker les fichiers et d'un éditeur de texte pour créer le modèle de tâche. Après avoir créé le bundle, soumettez la tâche à Deadline Cloud à l'aide de la CLI de Deadline Cloud ou d'un outil tel qu'un émetteur Deadline Cloud

Vous pouvez stocker vos actifs dans un système de fichiers partagé entre vos employés, ou vous pouvez utiliser les pièces jointes aux tâches de Deadline Cloud pour automatiser le transfert des actifs vers des compartiments S3 où vos employés peuvent y accéder. Les pièces jointes aux tâches permettent également de transférer les résultats de vos tâches vers vos postes de travail.

 Les sections suivantes fournissent des instructions détaillées sur la création et la soumission de lots de tâches à Deadline Cloud. 

**Topics**
+ [Modèles Open Job Description (OpenJD) pour Deadline Cloud](build-job-bundle.md)
+ [Utilisation de fichiers dans le cadre de vos tâches](using-files-in-your-jobs.md)
+ [Utiliser les pièces jointes aux tâches pour partager des fichiers](build-job-attachments.md)
+ [Création de limites de ressources pour les tâches](build-job-limits.md)
+ [Comment soumettre une offre d'emploi à Deadline Cloud](submit-jobs-how.md)
+ [Planifier des tâches dans Deadline Cloud](build-jobs-scheduling.md)
+ [Modifier une tâche dans Deadline Cloud](build-jobs-modifying.md)

# Modèles Open Job Description (OpenJD) pour Deadline Cloud
<a name="build-job-bundle"></a>

Un ensemble de *tâches* est l'un des outils que vous utilisez pour définir des tâches pour AWS Deadline Cloud. Ils regroupent un modèle [Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) contenant des informations supplémentaires telles que les fichiers et les répertoires que vos tâches utilisent avec les pièces jointes aux tâches. Vous utilisez l'interface de ligne de commande (CLI) de Deadline Cloud pour utiliser un ensemble de tâches afin de soumettre des tâches à exécuter dans une file d'attente.

Un ensemble de tâches est une structure de répertoire qui contient un modèle de tâche OpenJD, d'autres fichiers qui définissent la tâche et les fichiers spécifiques à la tâche requis comme entrée pour votre tâche. Vous pouvez spécifier les fichiers qui définissent votre tâche sous forme de fichiers YAML ou JSON.

Le seul fichier requis est l'un `template.yaml` ou l'autre`template.json`. Vous pouvez également inclure les fichiers suivants :

```
/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
```

Utilisez un ensemble de tâches pour les soumissions de tâches personnalisées à l'aide de la CLI de Deadline Cloud et d'une pièce jointe, ou vous pouvez utiliser une interface de soumission graphique. Par exemple, voici un exemple de Blender tiré de GitHub. Pour exécuter l'exemple à l'aide de la commande suivante dans [le répertoire d'exemples de Blender](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles) :

```
deadline bundle gui-submit blender_render
```

![\[Exemple d'interface de soumission de tâches personnalisée pour Blender.\]](http://docs.aws.amazon.com/fr_fr/deadline-cloud/latest/developerguide/images/blender_submit_shared_settings.png)


Le panneau des paramètres spécifiques à la tâche est généré à partir des `userInterface` propriétés des paramètres de tâche définis dans le modèle de tâche.

Pour soumettre une tâche à l'aide de la ligne de commande, vous pouvez utiliser une commande similaire à la suivante

```
deadline bundle submit \
    --yes \
    --name Demo \
     -p BlenderSceneFile=location of scene file \
     -p OutputDir=file pathe for job output \
      blender_render/
```

Vous pouvez également utiliser la `deadline.client.api.create_job_from_job_bundle` fonction dans le package `deadline` Python.

Tous les plugins de soumission de tâches fournis avec Deadline Cloud, tels que le plug-in Autodesk Maya, génèrent un ensemble de tâches pour votre soumission, puis utilisent le package Python de Deadline Cloud pour soumettre votre travail à Deadline Cloud. Vous pouvez consulter les offres d'emploi soumises dans le répertoire de l'historique des tâches de votre poste de travail ou en utilisant un expéditeur. Vous pouvez trouver le répertoire de votre historique des tâches à l'aide de la commande suivante :

```
deadline config get settings.job_history_dir
```

Lorsque votre tâche est exécutée sur un worker Deadline Cloud, celui-ci a accès à des variables d'environnement qui lui fournissent des informations sur la tâche. Les variables d'environnement sont les suivantes :


| Nom de la variable | Available | 
| --- | --- | 
| DEADLINE\$1FARM\$1ID | Toutes les actions | 
| DATE\$1FLEET\$1ID | Toutes les actions | 
| DEADLINE\$1WORKER\$1ID | Toutes les actions | 
| DEADLINE\$1QUEUE\$1ID | Toutes les actions | 
| DATE\$1JOB\$1ID | Toutes les actions | 
| DEADLINE\$1STEP\$1ID | Actions relatives aux tâches | 
| ID\$1DEADLINE\$1SESSION | Toutes les actions | 
| ID\$1DEADLINE\$1TÂCHE | Actions relatives aux tâches | 
| DEADLINE\$1SESSION\$1ACTION\$1ID | Toutes les actions | 

**Topics**
+ [Éléments de modèles de tâches pour les offres d'emploi](build-job-bundle-template.md)
+ [Découpage des tâches pour les modèles de tâches](build-job-bundle-chunking.md)
+ [Éléments de valeurs de paramètres pour les ensembles de tâches](build-job-bundle-parameters.md)
+ [Éléments de référence aux actifs pour les offres d'emploi](build-job-bundle-assets.md)

# Éléments de modèles de tâches pour les offres d'emploi
<a name="build-job-bundle-template"></a>

Le modèle de tâche définit l'environnement d'exécution et les processus exécutés dans le cadre d'une tâche Deadline Cloud. Vous pouvez créer des paramètres dans un modèle afin qu'il puisse être utilisé pour créer des tâches dont les valeurs d'entrée ne diffèrent que par les valeurs d'entrée, un peu comme une fonction dans un langage de programmation.

Lorsque vous soumettez une tâche à Deadline Cloud, elle s'exécute dans tous les environnements de file d'attente appliqués à la file d'attente. Les environnements de file d'attente sont créés à l'aide de la spécification des environnements externes Open Job Description (OpenJD). Pour plus de détails, consultez le [modèle d'environnement](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#12-environment-template) dans le GitHub référentiel OpenJD.

Pour une introduction à la création d'une tâche à l'aide d'un modèle de tâche OpenJD, voir [Présentation de la création d'une tâche](https://github.com/OpenJobDescription/openjd-specifications/wiki/Introduction-to-Creating-a-Job) dans le référentiel OpenJD GitHub . Vous trouverez des informations supplémentaires dans la section [Comment les tâches sont exécutées](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run). Vous trouverez des exemples de modèles de tâches dans le `samples` répertoire du GitHub référentiel OpenJD.

Vous pouvez définir le modèle de tâche au format YAML (`template.yaml`) ou au format JSON (`template.json`). Les exemples de cette section sont présentés au format YAML.

Par exemple, le modèle de tâche de l'`blender_render`exemple définit un paramètre d'entrée `BlenderSceneFile` sous la forme d'un chemin de fichier :

```
- 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.
```

La `userInterface` propriété définit le comportement des interfaces utilisateur générées automatiquement à la fois pour la ligne de commande à l'aide de la `deadline bundle gui-submit` commande et dans les plug-ins de soumission de tâches pour des applications telles qu'Autodesk Maya.

Dans cet exemple, le widget d'interface utilisateur permettant de saisir une valeur pour le `BlenderSceneFile` paramètre est une boîte de dialogue de sélection de fichiers qui affiche uniquement les fichiers. `.blend`

![\[Un widget d'interface utilisateur permettant de saisir le paramètre du fichier de scène pour un modèle de tâche OpenJD.\]](http://docs.aws.amazon.com/fr_fr/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png)


Pour d'autres exemples d'utilisation de l'`userInteface`élément, consultez l'exemple [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) dans le référentiel sur. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub

Les `dataFlow` propriétés `objectType` et contrôlent le comportement des pièces jointes lorsque vous soumettez une tâche à partir d'un ensemble de tâches. Dans ce cas, `objectType: FILE` `dataFlow:IN` cela signifie que la valeur de `BlenderSceneFile` est un fichier d'entrée pour les pièces jointes aux tâches.

En revanche, la définition du `OutputDir` paramètre a `objectType: DIRECTORY` et `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.
```

La valeur du `OutputDir` paramètre est utilisée par les pièces jointes aux tâches comme répertoire dans lequel la tâche écrit les fichiers de sortie.

Pour plus d'informations sur les `dataFlow` propriétés `objectType` et, voir [JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)la [spécification Open Job Description](https://github.com/OpenJobDescription/openjd-specifications)

Le reste de l'exemple de modèle de `blender_render` tâche définit le flux de travail de la tâche comme une seule étape, chaque image de l'animation étant rendue comme une tâche distincte :

```
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}}
```

Par exemple, si la valeur du `Frames` paramètre est`1-10`, il définit 10 tâches. Chaque tâche possède une valeur différente pour le `Frame` paramètre. Pour exécuter une tâche, procédez comme suit :

1. Toutes les références de variables de la `data` propriété du fichier intégré sont étendues, par exemple`--render-frame 1`.

1. Le contenu de la `data` propriété est écrit dans un fichier du répertoire de travail de la session sur le disque.

1. La `onRun` commande de la tâche se résout en `bash location of embedded file` puis s'exécute.

Pour plus d'informations sur les fichiers intégrés, les sessions et les emplacements mappés par des chemins, consultez la section [Comment les tâches sont exécutées](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) dans la spécification Open [Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run).

Vous trouverez d'autres exemples de modèles de tâches dans le référentiel [deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles), ainsi que les [exemples de modèles fournis avec la spécification](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples) Open Job Descriptions.

# Découpage des tâches pour les modèles de tâches
<a name="build-job-bundle-chunking"></a>

Le découpage des tâches vous permet de regrouper plusieurs tâches en une seule unité de travail appelée partie. Dans une tâche de rendu, par exemple, cela signifie que Deadline Cloud peut distribuer plusieurs images ensemble au lieu d'une image par appel de commande. Cela réduit la charge de travail liée au démarrage des applications pour chaque tâche et réduit le temps d'exécution total des tâches. Pour plus de détails, voir [Exécuter plusieurs images à la fois](https://github.com/OpenJobDescription/openjd-specifications/wiki/Job-Intro-03-Creating-a-Job-Template#42-running-multiple-frames-at-a-time) dans le wiki OpenJD.

OpenJD prend en charge les extensions qui ajoutent des fonctionnalités facultatives aux modèles de tâches. Le découpage des tâches est activé en ajoutant l'`TASK_CHUNKING`extension. Pour utiliser le découpage, ajoutez l'extension à votre modèle de tâche et utilisez le type de paramètre de `CHUNK[INT]` tâche. Soumettez des tâches segmentées à l'aide de la même `deadline bundle submit` commande. Par exemple, le modèle de tâche suivant affiche les cadres par blocs de 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
```

Dans cet exemple, Deadline Cloud divise les 100 images en morceaux tels que `1-10``11-20`,, etc. La `{{Task.Param.Frame}}` variable s'étend jusqu'à une expression de plage telle que`1-10`. Comme elle `rangeConstraint` est définie sur`CONTIGUOUS`, la plage est toujours au `start-end` format. Le script analyse cette plage et transmet les images de début et de fin à Blender en utilisant les `-e` options `-s` et avec`--render-anim`.

La `chunks` propriété prend en charge les champs suivants :
+ `defaultTaskCount`— (Obligatoire) Combien de tâches combiner en un seul morceau. La valeur maximale est de 150.
+ `rangeConstraint`— (Obligatoire) Si`CONTIGUOUS`, un fragment est toujours une plage contiguë, par exemple. `1-10` Si`NONCONTIGUOUS`, un morceau peut être un ensemble arbitraire, comme`1,3,7-10`.
+ `targetRuntimeSeconds`— (Facultatif) Le temps d'exécution cible en secondes pour chaque segment. Deadline Cloud peut ajuster dynamiquement la taille des fragments pour s'approcher de cette cible une fois que certains fragments sont terminés.

Pour d'autres exemples de découpage de tâches, y compris des exemples de base et des exemples de Blender avec des segments contigus et non contigus, consultez les exemples de découpage de [tâches dans le référentiel d'exemples de Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking) sur. GitHub

**Exigences relatives à la gestion du parc par le client**  
Le découpage des tâches nécessite une version d'agent de travail compatible. Si vous utilisez des flottes gérées par le client, assurez-vous que vos agents de travail sont à jour avant de soumettre des tâches par segmentation. Les flottes gérées par des services utilisent toujours une version d'agent de travail compatible.

**Téléchargement du résultat pour les tâches segmentées**  
Lorsque vous téléchargez le résultat d'une tâche unique dans une tâche fragmentée, Deadline Cloud télécharge le résultat pour l'ensemble du fragment. Par exemple, si les images 1 à 10 ont été traitées ensemble, le téléchargement de la sortie pour l'image 3 inclut toutes les images 1 à 10. Cette fonctionnalité nécessite `deadline-cloud` la version 0.53.3 ou ultérieure.

# Éléments de valeurs de paramètres pour les ensembles de tâches
<a name="build-job-bundle-parameters"></a>

Vous pouvez utiliser le fichier de paramètres pour définir les valeurs de certains paramètres de tâche dans le modèle de tâche ou les arguments de demande d'[CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)opération dans le bundle de tâches afin de ne pas avoir à définir de valeurs lors de la soumission d'une tâche. L'interface utilisateur de soumission des tâches vous permet de modifier ces valeurs.

Vous pouvez définir le modèle de tâche au format YAML (`parameter_values.yaml`) ou au format JSON (`parameter_values.json`). Les exemples de cette section sont présentés au format YAML.

En YAML, le format du fichier est le suivant :

```
parameterValues:
- name: <string>
  value: <integer>, <float>, or <string>
- name: <string>
  value: <integer>, <float>, or <string>ab
... repeating as necessary
```

Chaque élément de la `parameterValues` liste doit être l'un des suivants :
+ Paramètre de tâche défini dans le modèle de tâche.
+ Paramètre de tâche défini dans un environnement de file d'attente pour la file d'attente à laquelle vous soumettez la tâche.
+ Paramètre spécial transmis à l'`CreateJob`opération lors de la création d'une tâche.
  + `deadline:priority`— La valeur doit être un entier. Il est transmis à l'`CreateJob`opération en tant que paramètre de [priorité](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-priority).
  + `deadline:targetTaskRunStatus`— La valeur doit être une chaîne. Il est transmis à l'`CreateJob`opération en tant que paramètre [targetTaskRunStatus](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus).
  + `deadline:maxFailedTasksCount`— La valeur doit être un entier. Il est transmis à l'`CreateJob`opération en tant que paramètre [maxFailedTasksCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount).
  + `deadline:maxRetriesPerTask`— La valeur doit être un entier. Il est transmis à l'`CreateJob`opération en tant que paramètre de [maxRetriesPertâche](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask).
  + `deadline:maxWorkercount`— La valeur doit être un entier. Il est transmis à l'`CreateJob`opération en tant que [maxWorkerCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask)paramètre.

Un modèle de tâche est toujours un modèle plutôt qu'une tâche spécifique à exécuter. Un fichier de valeurs de paramètres permet à un ensemble de tâches de servir de modèle si certains paramètres n'ont pas de valeurs définies dans ce fichier, ou de soumission de tâches spécifique si tous les paramètres ont des valeurs.

Par exemple, l'exemple [blender\$1render ne possède](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render) pas de fichier de paramètres et son modèle de tâche définit des paramètres sans valeurs par défaut. Ce modèle doit être utilisé comme modèle pour créer des tâches. Une fois que vous avez créé une tâche à l'aide de cette offre de tâches, Deadline Cloud écrit une nouvelle série de tâches dans le répertoire de l'historique des tâches. 

Par exemple, lorsque vous soumettez une tâche à l'aide de la commande suivante :

```
deadline bundle gui-submit blender_render/
```

Le nouveau lot de tâches contient un `parameter_values.yaml` fichier contenant les paramètres spécifiés :

```
% 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
```

Vous pouvez créer la même tâche à l'aide de la commande suivante :

```
deadline bundle submit ~/.deadline/job_history/\(default\)/2024-06/2024-06-20-01-JobBundle-Demo/
```

**Note**  
Le lot de tâches que vous soumettez est enregistré dans votre répertoire d'historique des tâches. Vous pouvez trouver l'emplacement de ce répertoire à l'aide de la commande suivante :  

```
deadline config get settings.job_history_dir
```

# Éléments de référence aux actifs pour les offres d'emploi
<a name="build-job-bundle-assets"></a>

Vous pouvez utiliser les [pièces jointes aux tâches](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) de Deadline Cloud pour transférer des fichiers entre votre poste de travail et Deadline Cloud. Le fichier de référence des actifs répertorie les fichiers et répertoires d'entrée, ainsi que les répertoires de sortie pour vos pièces jointes. Si vous ne listez pas tous les fichiers et répertoires de ce fichier, vous pouvez les sélectionner lorsque vous soumettez une tâche à l'aide de la `deadline bundle gui-submit` commande.

Ce fichier n'a aucun effet si vous n'utilisez pas de pièces jointes aux tâches.

Vous pouvez définir le modèle de tâche au format YAML (`asset_references.yaml`) ou au format JSON (`asset_references.json`). Les exemples de cette section sont présentés au format YAML.

En YAML, le format du fichier est le suivant :

```
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
```

Lorsque vous sélectionnez le fichier d'entrée ou de sortie à télécharger sur Amazon S3, Deadline Cloud compare le chemin du fichier aux chemins répertoriés dans vos profils de stockage. Chaque emplacement de système `SHARED` de fichiers de type -type dans un profil de stockage fait abstraction d'un partage de fichiers réseau monté sur vos postes de travail et vos hôtes de travail. Deadline Cloud télécharge uniquement les fichiers qui ne figurent pas sur l'un de ces partages de fichiers.

Pour plus d'informations sur la création et l'utilisation de profils de stockage, consultez la section [Stockage partagé dans Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) dans le *guide de l'utilisateur de AWS Deadline Cloud*.

**Example - Le fichier de référence des actifs créé par l'interface graphique de Deadline Cloud**  
Utilisez la commande suivante pour soumettre une tâche à l'aide de l'exemple [blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render).  

```
deadline bundle gui-submit blender_render/
```
Ajoutez des fichiers supplémentaires à la tâche dans l'onglet **Pièces jointes à la tâche** :  

![\[Le volet des pièces jointes de l'interface graphique de soumission des tâches de Deadline Cloud. Ajoutez le fichier d'entrée/private/tmp/bundle_demo/a_texture.png and the input directory /private/tmp/bundle_demo/assets.\]](http://docs.aws.amazon.com/fr_fr/deadline-cloud/latest/developerguide/images/blender_submit_add_job_attachments.png)

Après avoir soumis la tâche, vous pouvez consulter le `asset_references.yaml` fichier du bundle de tâches dans le répertoire de l'historique des tâches pour voir les actifs du fichier YAML :  

```
% 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: []
```

# Utilisation de fichiers dans le cadre de vos tâches
<a name="using-files-in-your-jobs"></a>

 La plupart des tâches que vous soumettez à AWS Deadline Cloud comportent des fichiers d'entrée et de sortie. Vos fichiers d'entrée et vos répertoires de sortie peuvent se trouver sur une combinaison de systèmes de fichiers partagés et de lecteurs locaux. Les offres d'emploi doivent localiser le contenu à ces emplacements. Deadline Cloud propose deux fonctionnalités, les [pièces jointes aux tâches](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) et [les profils de stockage](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) qui fonctionnent ensemble pour aider vos tâches à localiser les fichiers dont elles ont besoin. 

Les offres d'emploi offrent plusieurs avantages
+ Déplacer des fichiers entre hôtes à l'aide d'Amazon S3
+ Transférez des fichiers de votre poste de travail vers des hôtes professionnels et vice versa
+ Disponible pour les tâches dans les files d'attente pour lesquelles vous activez la fonctionnalité
+ Principalement utilisé avec les flottes gérées par les services, mais également compatible avec les flottes gérées par le client.

 Utilisez des profils de stockage pour cartographier la disposition des emplacements des systèmes de fichiers partagés sur votre poste de travail et sur les hôtes de travail. Ce mappage permet à vos tâches de localiser les fichiers et répertoires partagés lorsque leur emplacement diffère entre votre poste de travail et les hôtes de travail, comme dans le cas de configurations multiplateformes avec des postes de travail Windows basés et des hôtes de travail Linux basés. La carte de configuration de votre système de fichiers du profil de stockage est également utilisée par les pièces jointes aux tâches pour identifier les fichiers dont elles ont besoin pour être transférées entre les hôtes via Amazon S3. 

 Si vous n'utilisez pas de pièces jointes aux tâches et que vous n'avez pas besoin de remapper les emplacements des fichiers et des répertoires entre les postes de travail et les hôtes de travail, vous n'avez pas besoin de modéliser vos partages de fichiers à l'aide de profils de stockage. 

**Topics**
+ [Exemple d'infrastructure de projet](sample-project-infrastructure.md)
+ [Profils de stockage et mappage des chemins](storage-profiles-and-path-mapping.md)

# Exemple d'infrastructure de projet
<a name="sample-project-infrastructure"></a>

Pour démontrer l'utilisation des pièces jointes aux tâches et des profils de stockage, configurez un environnement de test avec deux projets distincts. Vous pouvez utiliser la console Deadline Cloud pour créer les ressources de test.

1. Si ce n'est pas déjà fait, créez un parc de tests. Pour créer une ferme, suivez la procédure décrite dans [Créer une ferme](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html). 

1. Créez deux files d'attente pour les tâches dans chacun des deux projets. Pour créer des files d'attente, suivez la procédure décrite dans [Créer une file d'attente](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html).

   1. Créez la première file d'attente appelée**Q1**. Utilisez la configuration suivante, utilisez les valeurs par défaut pour tous les autres éléments.
      + Pour les pièces jointes aux tâches, choisissez **Create a new Amazon S3 bucket**.
      + Sélectionnez **Activer l'association avec les flottes gérées par le client**.
      + Pour exécuter en tant qu'utilisateur, entrez à **jobuser** la fois l'utilisateur et le groupe POSIX.
      + Pour le rôle de service de file d'attente, créez un nouveau rôle nommé **AssetDemoFarm-Q1-Role**
      + Décochez la case par défaut de l'environnement de file d'attente Conda.

   1. Créez la deuxième file d'attente appelée**Q2**. Utilisez la configuration suivante, utilisez les valeurs par défaut pour tous les autres éléments.
      + Pour les pièces jointes aux tâches, choisissez **Create a new Amazon S3 bucket**.
      + Sélectionnez **Activer l'association avec les flottes gérées par le client**.
      + Pour exécuter en tant qu'utilisateur, entrez à **jobuser** la fois l'utilisateur et le groupe POSIX.
      + Pour le rôle de service de file d'attente, créez un nouveau rôle nommé **AssetDemoFarm-Q2-Role**
      + Décochez la case par défaut de l'environnement de file d'attente Conda.

1. Créez une flotte unique gérée par le client qui exécute les tâches à partir des deux files d'attente. Pour créer le parc, suivez la procédure décrite dans [Créer un parc géré par le client](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html). Utilisez la configuration suivante :
   + Pour **Nom**, utilisez**DemoFleet**.
   + Pour le **type de flotte**, sélectionnez **Géré par le client**
   + Pour le **rôle de service de flotte**, créez un nouveau rôle nommé **AssetDemoFarm-Fleet-Role**.
   + N'associez la flotte à aucune file d'attente.

L'environnement de test suppose que trois systèmes de fichiers sont partagés entre les hôtes à l'aide de partages de fichiers réseau. Dans cet exemple, les emplacements portent les noms suivants :
+ `FSCommon`- contient les actifs de travail d'entrée communs aux deux projets.
+ `FS1`- contient les actifs de travail d'entrée et de sortie pour le projet 1.
+ `FS2`- contient les actifs de travail d'entrée et de sortie pour le projet 2.

L'environnement de test suppose également qu'il existe trois postes de travail, comme suit :
+ `WSAll`- Un poste Linux de travail basé utilisé par les développeurs pour tous les projets. Les emplacements des systèmes de fichiers partagés sont les suivants :
  + `FSCommon`: `/shared/common`
  + `FS1`: `/shared/projects/project1`
  + `FS2`: `/shared/projects/project2`
+ `WS1`- Un poste Windows de travail basé utilisé pour le projet 1. Les emplacements des systèmes de fichiers partagés sont les suivants :
  + `FSCommon`: `S:\`
  + `FS1`: `Z:\`
  + `FS2`: Non disponible
+ `WS1`- Un poste de travail macOS basé utilisé pour le projet 2. Les emplacements du système de fichiers partagé sont les suivants :
  + `FSCommon`: `/Volumes/common`
  + `FS1`: Non disponible
  + `FS2`: `/Volumes/projects/project2`

Enfin, définissez les emplacements des systèmes de fichiers partagés pour les employés de votre flotte. Les exemples suivants font référence à cette configuration sous le nom de`WorkerConfig`. Les emplacements partagés sont les suivants : 
+ `FSCommon`: `/mnt/common`
+ `FS1`: `/mnt/projects/project1`
+ `FS2`: `/mnt/projects/project2`

 Vous n'avez pas besoin de configurer de systèmes de fichiers partagés, de postes de travail ou de travailleurs correspondant à cette configuration. Les emplacements partagés n'ont pas besoin d'exister pour la démonstration. 

# Profils de stockage et mappage des chemins
<a name="storage-profiles-and-path-mapping"></a>

Utilisez des profils de stockage pour modéliser les systèmes de fichiers de votre poste de travail et de vos hôtes de travail. Chaque profil de stockage décrit le système d'exploitation et la structure du système de fichiers de l'une de vos configurations système. Cette rubrique décrit comment utiliser les profils de stockage pour modéliser les configurations du système de fichiers de vos hôtes afin que Deadline Cloud puisse générer des règles de mappage de chemins pour vos tâches, et comment ces règles de mappage de chemins sont générées à partir de vos profils de stockage.

Lorsque vous soumettez une tâche à Deadline Cloud, vous pouvez fournir un identifiant de profil de stockage facultatif pour la tâche. Ce profil de stockage décrit le système de fichiers du poste de travail émetteur. Il décrit la configuration du système de fichiers d'origine utilisée par les chemins de fichiers du modèle de tâche.

Vous pouvez également associer un profil de stockage à une flotte. Le profil de stockage décrit la configuration du système de fichiers de tous les hôtes de travail du parc. Si vous avez des employés dont la configuration du système de fichiers est différente, ces travailleurs doivent être affectés à un parc différent de votre ferme.

 Les règles de mappage de chemins décrivent comment les chemins doivent être remappés entre la façon dont ils sont spécifiés dans la tâche et l'emplacement réel du chemin sur un hôte de travail. Deadline Cloud compare la configuration du système de fichiers décrite dans le profil de stockage d'une tâche avec le profil de stockage du parc qui exécute la tâche afin de dériver ces règles de mappage de chemins. 

**Topics**
+ [Modélisez les emplacements des systèmes de fichiers partagés à l'aide de profils de stockage](modeling-your-shared-filesystem-locations-with-storage-profiles.md)
+ [Configuration des profils de stockage pour les flottes](configuring-storage-profiles-for-fleets.md)
+ [Configuration des profils de stockage pour les files d'attente](storage-profiles-for-queues.md)
+ [Dériver les règles de mappage des chemins à partir des profils de stockage](deriving-path-mapping-rules-from-storage-profiles.md)

# Modélisez les emplacements des systèmes de fichiers partagés à l'aide de profils de stockage
<a name="modeling-your-shared-filesystem-locations-with-storage-profiles"></a>

 Un profil de stockage modélise la configuration du système de fichiers de l'une de vos configurations d'hôte. Il existe quatre configurations hôtes différentes dans l'[exemple d'infrastructure de projet](). Dans cet exemple, vous créez un profil de stockage distinct pour chacun d'entre eux. Vous pouvez créer un profil de stockage à l'aide de l'une des méthodes suivantes :
+ [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
+ [Console AWS](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html#storage-profile)

 Un profil de stockage est constitué d'une liste d'emplacements de systèmes de fichiers qui indiquent chacun à Deadline Cloud l'emplacement et le type d'emplacement du système de fichiers pertinent pour les tâches soumises ou exécutées sur un hôte. Un profil de stockage ne doit modéliser que les emplacements pertinents pour les tâches. Par exemple, l'`FSCommon`emplacement partagé est situé sur le poste de travail `WS1` à`S:\`, de sorte que l'emplacement du système de fichiers correspondant est le suivant : 

```
{
    "name": "FSCommon",
    "path": "S:\\",
    "type": "SHARED"
}
```

 Utilisez les commandes suivantes pour créer le profil de stockage pour les configurations de station de travail `WS1``WS2`, `WS3` et la configuration de l'utilisateur à `WorkerConfig` l'aide de la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)in [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

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"}
  ]'
```

**Note**  
Vous devez faire référence aux emplacements des systèmes de fichiers dans vos profils de stockage en utilisant les mêmes valeurs pour la `name` propriété dans tous les profils de stockage de votre parc de serveurs. Deadline Cloud compare les noms pour déterminer si les emplacements des systèmes de fichiers issus de différents profils de stockage font référence au même emplacement lors de la génération des règles de mappage de chemins. 

# Configuration des profils de stockage pour les flottes
<a name="configuring-storage-profiles-for-fleets"></a>

Vous pouvez configurer un parc de manière à inclure un profil de stockage qui modélise les emplacements des systèmes de fichiers de tous les employés du parc. La configuration du système de fichiers hôte de tous les travailleurs d'une flotte doit correspondre au profil de stockage de cette flotte. Les travailleurs ayant des configurations de système de fichiers différentes doivent appartenir à des flottes distinctes. 

Pour définir la configuration de votre flotte afin d'utiliser le profil `WorkerConfig` de stockage, utilisez le fichier [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)dans [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
    }
  }"
```

# Configuration des profils de stockage pour les files d'attente
<a name="storage-profiles-for-queues"></a>

 La configuration d'une file d'attente inclut une liste de noms distinguant majuscules et minuscules des emplacements du système de fichiers partagé auxquels les tâches soumises à la file d'attente doivent avoir accès. Par exemple, les tâches soumises à la file d'attente `Q1` nécessitent des emplacements `FSCommon` de système de fichiers et. `FS1` Les tâches soumises à la file d'attente `Q2` nécessitent l'emplacement du système de fichiers `FSCommon` et`FS2`. 

Pour définir les configurations de la file d'attente afin d'exiger ces emplacements de système de fichiers, utilisez le script suivant : 

```
# 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
```

 La configuration d'une file d'attente inclut également une liste de profils de stockage autorisés qui s'applique aux tâches soumises à cette file d'attente et aux flottes associées à cette file d'attente. Seuls les profils de stockage qui définissent les emplacements du système de fichiers pour tous les emplacements de système de fichiers requis pour la file d'attente sont autorisés dans la liste des profils de stockage autorisés de la file d'attente. 

Une tâche échoue si vous la soumettez avec un profil de stockage qui ne figure pas dans la liste des profils de stockage autorisés pour la file d'attente. Vous pouvez toujours soumettre une tâche sans profil de stockage à une file d'attente. Les configurations de poste de travail sont étiquetées `WSAll` et `WS1` toutes deux possèdent les emplacements de système de fichiers requis (`FSCommon`et`FS1`) pour la file d'attente`Q1`. Ils doivent être autorisés à soumettre des tâches à la file d'attente. De même, les configurations des postes `WSAll` de travail `WS2` répondent aux exigences en matière de file d'attente`Q2`. Ils doivent être autorisés à soumettre des tâches à cette file d'attente. Mettez à jour les deux configurations de file d'attente pour autoriser les tâches à être soumises avec ces profils de stockage à l'aide du script suivant : 

```
# 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
```

 Si vous ajoutez le profil `WS2` de stockage à la liste des profils de stockage autorisés pour la file d'attente, `Q1` il échoue : 

```
$ 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
```

 Cela est dû au fait que le profil de `WS2` stockage ne contient pas de définition de l'emplacement du système de fichiers nommé `FS1` `Q1` requis par la file d'attente. 

 L'association d'un parc configuré à un profil de stockage ne figurant pas dans la liste des profils de stockage autorisés de la file d'attente échoue également. Par exemple : 

```
$ 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.
```

Pour corriger l'erreur, ajoutez le profil de stockage nommé `WorkerConfig` à la liste des profils de stockage autorisés pour la file d'attente `Q1` et la file d'attente`Q2`. Associez ensuite le parc à ces files d'attente afin que les employés du parc puissent exécuter des tâches à partir des deux files d'attente. 

```
# 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
```

# Dériver les règles de mappage des chemins à partir des profils de stockage
<a name="deriving-path-mapping-rules-from-storage-profiles"></a>

 Les règles de mappage de chemins décrivent comment les chemins doivent être remappés entre la tâche et l'emplacement réel du chemin sur un hôte de travail. Lorsqu'une tâche est exécutée sur un travailleur, le profil de stockage de la tâche est comparé au profil de stockage du parc du travailleur afin de déterminer les règles de mappage des chemins pour la tâche. 

 Deadline Cloud crée une règle de mappage pour chacun des emplacements de système de fichiers requis dans la configuration de la file d'attente. Par exemple, une tâche soumise avec le profil de `WSAll` stockage à mettre en file d'attente `Q1` est soumise aux règles de mappage des chemins : 
+  `FSComm`: `/shared/common -> /mnt/common` 
+  `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` 

 Deadline Cloud crée des règles pour les emplacements du système de `FS1` fichiers `FSComm` et, mais pas pour l'emplacement du système de `FS2` fichiers, même si les profils `WSAll` et `WorkerConfig` de stockage le définissent tous deux`FS2`. Cela est dû au fait que `Q1` la liste des emplacements de système de fichiers requis de la file d'attente est`["FSComm", "FS1"]`. 

 Vous pouvez confirmer les règles de mappage de chemin disponibles pour les tâches soumises avec un profil de stockage particulier en soumettant une tâche qui imprime le [fichier de règles de mappage de chemin d'Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping), puis en lisant le journal de session une fois la tâche terminée : 

```
# 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}}" ]
            }
          }
        }
      }
    ]
  }'
```

 Si vous utilisez la [CLI Deadline Cloud](https://pypi.org/project/deadline/) pour soumettre des tâches, ses paramètres de `settings.storage_profile_id` configuration définissent le profil de stockage que les tâches soumises avec la CLI auront. Pour soumettre des tâches avec le profil `WSAll` de stockage, définissez : 

```
deadline config set settings.storage_profile_id $WSALL_ID
```

 Pour exécuter un travailleur géré par le client comme s'il s'exécutait dans l'infrastructure d'exemple, suivez la procédure décrite dans la section [Exécuter l'agent de travail dans le](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/run-worker.html) *guide de l'utilisateur de Deadline Cloud* pour exécuter un travailleur avec. AWS CloudShell Si vous avez déjà suivi ces instructions, supprimez d'abord `~/demoenv-persist` les répertoires `~/demoenv-logs` et. Définissez également les valeurs des variables d'`DEV_CMF_ID`environnement `DEV_FARM_ID` et auxquelles les directions font référence comme suit avant de procéder : 

```
DEV_FARM_ID=$FARM_ID
DEV_CMF_ID=$FLEET_ID
```

 Une fois la tâche exécutée, vous pouvez consulter les règles de mappage des chemins dans le fichier journal de la tâche : 

```
cat demoenv-logs/${QUEUE1_ID}/*.log
...
JJSON log results (see below)
...
```

Le journal contient le mappage des systèmes de `FSComm` fichiers `FS1` et. Reformatée pour plus de lisibilité, l'entrée du journal ressemble à ceci :

```
{
    "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"
        }
    ]
```

 Vous pouvez soumettre des tâches avec différents profils de stockage pour voir comment les règles de mappage des chemins changent. 

# Utiliser les pièces jointes aux tâches pour partager des fichiers
<a name="build-job-attachments"></a>

Utilisez les *pièces jointes aux tâches* pour rendre les fichiers ne figurant pas dans les répertoires partagés disponibles pour vos tâches et pour capturer les fichiers de sortie s'ils ne sont pas écrits dans des répertoires partagés. Job Attachments utilise Amazon S3 pour transférer les fichiers entre les hôtes. Les fichiers sont stockés dans des compartiments S3 et il n'est pas nécessaire de télécharger un fichier si son contenu n'a pas changé.

Vous devez utiliser des pièces jointes lorsque vous exécutez des tâches sur des [flottes gérées par des services, car les](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html) hôtes ne partagent pas l'emplacement des systèmes de fichiers. Les pièces jointes aux tâches sont également utiles dans les [flottes gérées par les clients lorsque les](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/manage-cmf.html) fichiers d'entrée ou de sortie d'une tâche sont stockés sur un système de fichiers réseau partagé, par exemple lorsque votre ensemble de [tâches contient des scripts](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html) shell ou Python. 

 Lorsque vous soumettez un ensemble de tâches à l'aide de la [CLI de Deadline Cloud](https://pypi.org/project/deadline/) ou d'un émetteur de Deadline Cloud, les pièces jointes aux tâches utilisent le profil de stockage de la tâche et les emplacements du système de fichiers requis dans la file d'attente pour identifier les fichiers d'entrée qui ne se trouvent pas sur un hôte de travail et qui doivent être téléchargés sur Amazon S3 dans le cadre de la soumission de la tâche. Ces profils de stockage aident également Deadline Cloud à identifier les fichiers de sortie sur les sites d'accueil des travailleurs qui doivent être téléchargés sur Amazon S3 afin d'être disponibles sur votre poste de travail. 

 Les exemples de pièces jointes aux tâches utilisent les configurations de ferme, de flotte, de files d'attente et de profils de stockage issues de [Exemple d'infrastructure de projet](sample-project-infrastructure.md) et[Profils de stockage et mappage des chemins](storage-profiles-and-path-mapping.md). Vous devriez parcourir ces sections avant celle-ci. 

Dans les exemples suivants, vous utilisez un exemple de série de tâches comme point de départ, puis vous le modifiez pour explorer les fonctionnalités de la pièce jointe aux tâches. Les offres d'emploi constituent le meilleur moyen pour vos offres d'emploi d'utiliser les pièces jointes. Ils combinent un modèle de [tâche Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki) dans un répertoire avec des fichiers supplémentaires qui répertorient les fichiers et les répertoires requis par les tâches utilisant le bundle de tâches. Pour plus d'informations sur les offres d'emploi, consultez[Modèles Open Job Description (OpenJD) pour Deadline Cloud](build-job-bundle.md).

# Soumission de fichiers avec une tâche
<a name="submitting-files-with-a-job"></a>

Avec Deadline Cloud, vous pouvez permettre aux flux de travail d'accéder aux fichiers d'entrée qui ne sont pas disponibles dans les emplacements des systèmes de fichiers partagés sur les hôtes de travail. Les pièces jointes aux tâches permettent aux tâches de rendu d'accéder à des fichiers résidant uniquement sur le disque d'un poste de travail local ou dans un environnement de parc géré par des services. Lorsque vous soumettez un ensemble de tâches, vous pouvez inclure des listes de fichiers d'entrée et de répertoires requis par la tâche. Deadline Cloud identifie ces fichiers non partagés, les télécharge depuis la machine locale vers Amazon S3 et les télécharge sur l'hôte du poste de travail. Il rationalise le processus de transfert des actifs d'entrée vers les nœuds de rendu, garantissant ainsi que tous les fichiers requis sont accessibles pour l'exécution distribuée des tâches.

Vous pouvez spécifier les fichiers des tâches directement dans le bundle de tâches, utiliser les paramètres du modèle de tâche que vous fournissez à l'aide de variables d'environnement ou d'un script, et utiliser le `assets_references` fichier de la tâche. Vous pouvez utiliser l'une de ces méthodes ou une combinaison des trois. Vous pouvez spécifier un profil de stockage pour le bundle de la tâche afin qu'il ne télécharge que les fichiers modifiés sur le poste de travail local.

Cette section utilise un exemple de bundle de tâches GitHub pour montrer comment Deadline Cloud identifie les fichiers de votre tâche à télécharger, comment ces fichiers sont organisés dans Amazon S3 et comment ils sont mis à la disposition des hôtes de travail traitant vos tâches. 

**Topics**
+ [Comment Deadline Cloud télécharge des fichiers sur Amazon S3](what-job-attachments-uploads-to-amazon-s3.md)
+ [Comment Deadline Cloud choisit les fichiers à télécharger](how-job-attachments-decides-what-to-upload-to-amazon-s3.md)
+ [Comment les tâches trouvent-elles les fichiers d'entrée des pièces jointes](how-jobs-find-job-attachments-input-files.md)

# Comment Deadline Cloud télécharge des fichiers sur Amazon S3
<a name="what-job-attachments-uploads-to-amazon-s3"></a>

Cet exemple montre comment Deadline Cloud télécharge des fichiers depuis votre poste de travail ou votre hôte de travail vers Amazon S3 afin qu'ils puissent être partagés. Il utilise un exemple de bundle de tâches GitHub et la CLI de Deadline Cloud pour soumettre des tâches.

 Commencez par cloner le [ GitHubréférentiel d'échantillons de Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples) dans votre [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)environnement, puis copiez le bundle de `job_attachments_devguide` tâches dans votre répertoire personnel : 

```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide ~/
```

 Installez la [CLI de Deadline Cloud](https://pypi.org/project/deadline/) pour soumettre des ensembles de tâches : 

```
pip install deadline --upgrade
```

 Le bundle de `job_attachments_devguide` tâches comporte une seule étape avec une tâche qui exécute un script shell bash dont l'emplacement du système de fichiers est transmis en tant que paramètre de tâche. La définition du paramètre de tâche est la suivante : 

```
...
- name: ScriptFile
  type: PATH
  default: script.sh
  dataFlow: IN
  objectType: FILE
...
```

 La `IN` valeur de la `dataFlow` propriété indique aux pièces jointes à la tâche que la valeur du `ScriptFile` paramètre est une entrée de la tâche. La valeur de la `default` propriété est un emplacement relatif par rapport au répertoire du bundle de tâches, mais il peut également s'agir d'un chemin absolu. Cette définition de paramètre déclare le `script.sh` fichier du répertoire du bundle de tâches en tant que fichier d'entrée requis pour l'exécution de la tâche. 

 Ensuite, assurez-vous qu'aucun profil de stockage n'est configuré sur la CLI de Deadline Cloud, puis soumettez la tâche à la file d'attente `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/
```

 Le résultat de la CLI de Deadline Cloud après l'exécution de cette commande est le suivant : 

```
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
```

Lorsque vous soumettez la tâche, Deadline Cloud hache d'abord le `script.sh` fichier, puis le télécharge sur Amazon S3. 

Deadline Cloud traite le compartiment S3 comme un espace de stockage adressable par le contenu. Les fichiers sont téléchargés vers des objets S3. Le nom de l'objet est dérivé d'un hachage du contenu du fichier. Si deux fichiers ont un contenu identique, ils ont la même valeur de hachage, quel que soit leur emplacement ou leur nom. Ce stockage adressable par contenu permet à Deadline Cloud d'éviter de télécharger un fichier s'il est déjà disponible.

 Vous pouvez utiliser l'[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) pour voir les objets qui ont été chargés sur Amazon S3 : 

```
# 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
```

 Deux objets ont été chargés sur S3 : 
+  `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`— Le contenu de`script.sh`. [La valeur de `87cb19095dd5d78fcaf56384ef0e6241` la clé d'objet est le hachage du contenu du fichier, et l'extension `xxh128` indique que la valeur de hachage a été calculée sous la forme d'un xxhash de 128 bits.](https://xxhash.com/) 
+  `DeadlineCloud/Manifests/<farm-id>/<queue-id>/Inputs/<guid>/a1d221c7fd97b08175b3872a37428e8c_input`— L'objet manifeste pour la soumission de la tâche. Les valeurs `<farm-id>``<queue-id>`, et `<guid>` sont l'identifiant de votre ferme, l'identifiant de la file d'attente et une valeur hexadécimale aléatoire. La valeur `a1d221c7fd97b08175b3872a37428e8c` dans cet exemple est une valeur de hachage calculée à partir de la chaîne`/home/cloudshell-user/job_attachments_devguide`, le répertoire dans lequel se `script.sh` trouve le répertoire. 

 L'objet manifeste contient les informations relatives aux fichiers d'entrée sur un chemin racine spécifique téléchargés vers S3 dans le cadre de la soumission de la tâche. Téléchargez ce fichier manifeste (`aws s3 cp s3://$Q1_S3_BUCKET/<objectname>`). Son contenu est similaire à : 

```
{
    "hashAlg": "xxh128",
    "manifestVersion": "2023-03-03",
    "paths": [
        {
            "hash": "87cb19095dd5d78fcaf56384ef0e6241",
            "mtime": 1721147454416085,
            "path": "script.sh",
            "size": 39
        }
    ],
    "totalSize": 39
}
```

Cela indique que le fichier `script.sh` a été chargé et que le hachage du contenu de ce fichier est `87cb19095dd5d78fcaf56384ef0e6241` le même. Cette valeur de hachage correspond à la valeur du nom `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128` de l'objet. Il est utilisé par Deadline Cloud pour savoir quel objet télécharger pour le contenu de ce fichier.

 Le schéma complet de ce fichier est [disponible dans GitHub](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/job_attachments/asset_manifests/v2023_03_03/validate.py). 

Lorsque vous utilisez cette [CreateJob opération](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html), vous pouvez définir l'emplacement des objets du manifeste. Vous pouvez utiliser l'[GetJobopération](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) pour voir l'emplacement : 

```
{
    "attachments": {
        "file system": "COPIED",
        "manifests": [
            {
                "inputManifestHash": "5b0db3d311805ea8de7787b64cbbe8b3",
                "inputManifestPath": "<farm-id>/<queue-id>/Inputs/<guid>/a1d221c7fd97b08175b3872a37428e8c_input",
                "rootPath": "/home/cloudshell-user/job_attachments_devguide",
                "rootPathFormat": "posix"
            }
        ]
    },
    ...
}
```

# Comment Deadline Cloud choisit les fichiers à télécharger
<a name="how-job-attachments-decides-what-to-upload-to-amazon-s3"></a>

 Les fichiers et répertoires que les pièces jointes aux tâches considèrent comme des entrées pour votre tâche sont les suivants : 
+  Les valeurs de tous les paramètres de tâche de `PATH` type -type définis dans le modèle de tâches du bundle de tâches avec une `dataFlow` valeur de `IN` ou`INOUT`.
+  Les fichiers et répertoires répertoriés en tant qu'entrées dans le fichier de référence des actifs du bundle de tâches. 

 Si vous soumettez une tâche sans profil de stockage, tous les fichiers considérés pour le téléchargement sont chargés. Si vous soumettez une tâche avec un profil de stockage, les fichiers ne sont pas chargés vers Amazon S3 s'ils se trouvent dans les emplacements du système de fichiers de `SHARED` type du profil de stockage, qui sont également des emplacements de système de fichiers obligatoires pour la file d'attente. Ces emplacements sont censés être disponibles sur les hôtes de travail qui exécutent la tâche. Il n'est donc pas nécessaire de les télécharger sur S3. 

 Dans cet exemple, vous créez des emplacements de système de `SHARED` fichiers `WSAll` dans votre CloudShell environnement AWS, puis vous ajoutez des fichiers à ces emplacements de système de fichiers. Utilisez la commande suivante : 

```
# 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
```

 Ajoutez ensuite un fichier de références d'actifs au bundle de tâches qui inclut tous les fichiers que vous avez créés en tant qu'entrées pour le travail. Utilisez la commande suivante : 

```
cat > ${HOME}/job_attachments_devguide/asset_references.yaml << EOF
assetReferences:
  inputs:
    filenames:
    - /shared/common/file.txt
    directories:
    - /shared/projects/project1
    - /shared/projects/project2
EOF
```

 Configurez ensuite la CLI de Deadline Cloud pour soumettre les tâches avec le profil de `WSAll` stockage, puis soumettez le bundle de tâches : 

```
# 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 télécharge deux fichiers sur Amazon S3 lorsque vous soumettez la tâche. Vous pouvez télécharger les objets du manifeste de la tâche depuis S3 pour voir les fichiers téléchargés : 

```
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
```

 Dans cet exemple, il existe un seul fichier manifeste dont le contenu est le suivant : 

```
{
    "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
}
```

 Utilisez l'[GetJob opération](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) pour le manifeste pour vérifier qu'il s'`rootPath`agit de «/». 

```
aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID --query 'attachments.manifests[*]'
```

 Le chemin racine d'un ensemble de fichiers d'entrée est toujours le sous-chemin commun le plus long de ces fichiers. Si votre tâche a été soumise à la Windows place et que certains fichiers d'entrée n'ont aucun sous-chemin commun parce qu'ils se trouvent sur des lecteurs différents, vous voyez un chemin racine distinct sur chaque lecteur. Les chemins d'un manifeste sont toujours relatifs au chemin racine du manifeste. Les fichiers d'entrée qui ont été téléchargés sont donc les suivants : 
+  `/home/cloudshell-user/job_attachments_devguide/script.sh`— Le fichier de script contenu dans le bundle de tâches. 
+  `/shared/projects/project2/file.txt`— Le fichier situé dans un emplacement `SHARED` du système de fichiers dans le profil `WSAll` de stockage qui **ne figure pas** dans la liste des emplacements de système de fichiers requis pour la file d'attente`Q1`. 

Les fichiers situés dans les emplacements du système de fichiers `FSCommon` (`/shared/common/file.txt`) et `FS1` (`/shared/projects/project1/file.txt`) ne figurent pas dans la liste. Cela est dû au fait que ces emplacements de système de fichiers se trouvent `SHARED` dans le profil `WSAll` de stockage et qu'ils figurent tous deux dans la liste des emplacements de système de fichiers requis dans la file d'attente`Q1`. 

Vous pouvez voir les emplacements du système de fichiers pris en compte `SHARED` pour une tâche soumise avec un profil de stockage particulier lors de l'[GetStorageProfileForQueue opération](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetStorageProfileForQueue.html). Pour rechercher le profil de stockage `WSAll` pour la file d'attente, `Q1` utilisez la commande suivante : 

```
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
```

# Comment les tâches trouvent-elles les fichiers d'entrée des pièces jointes
<a name="how-jobs-find-job-attachments-input-files"></a>

 Pour qu'une tâche utilise les fichiers que Deadline Cloud télécharge sur Amazon S3 à l'aide de pièces jointes, elle a besoin que ces fichiers soient disponibles via le système de fichiers sur les hôtes de travail. Lorsqu'une [session](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#sessions) pour votre tâche s'exécute sur un hôte de travail, Deadline Cloud télécharge les fichiers d'entrée de la tâche dans un répertoire temporaire sur le disque local de l'hôte de travail et ajoute des règles de mappage de chemin pour chacun des chemins racines de la tâche vers son emplacement dans le système de fichiers sur le disque local. 

 Pour cet exemple, lancez l'agent de travail Deadline Cloud dans un CloudShell onglet AWS. Laissez toutes les tâches déjà soumises terminer leur exécution, puis supprimez les journaux des tâches du répertoire des journaux : 

```
rm -rf ~/devdemo-logs/queue-*
```

 Le script suivant modifie le bundle de tâches pour afficher tous les fichiers du répertoire de travail temporaire de la session ainsi que le contenu du fichier de règles de mappage de chemins, puis soumet un job avec le bundle modifié : 

```
# 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/
```

 Vous pouvez consulter le journal de l'exécution de la tâche une fois qu'elle a été exécutée par le travailleur dans votre AWS CloudShell environnement : 

```
cat demoenv-logs/queue-*/session*.log
```

Le journal indique que la première chose qui se produit au cours de la session est que les deux fichiers d'entrée de la tâche sont téléchargés vers le travailleur : 

```
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.
```

 Vient ensuite le résultat de `script.sh` run by the job : 
+  Les fichiers d'entrée téléchargés lors de la soumission de la tâche se trouvent dans un répertoire dont le nom commence par « assetroot » dans le répertoire temporaire de la session. 
+  Les chemins des fichiers d'entrée ont été déplacés par rapport au répertoire « assetroot » plutôt que par rapport au chemin racine du manifeste d'entrée () de la tâche. `"/"`
+  Le fichier de règles de mappage de chemins contient une règle supplémentaire qui `"/"` correspond au chemin absolu du répertoire « assetroot ». 

 Par exemple : 

```
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 }
```

**Note**  
 Si la tâche que vous soumettez comporte plusieurs manifestes avec des chemins racines différents, il existe un répertoire nommé « assetroot » différent pour chacun des chemins racines. 

 Si vous devez référencer l'emplacement du système de fichiers déplacé de l'un de vos fichiers d'entrée, répertoires ou emplacements de système de fichiers, vous pouvez soit traiter le fichier de règles de mappage de chemins dans votre tâche et effectuer le remappage vous-même, soit ajouter un paramètre de tâche de `PATH` type au modèle de tâche de votre ensemble de tâches et transmettre la valeur que vous devez remapper en tant que valeur de ce paramètre. Par exemple, l'exemple suivant modifie le lot de tâches pour qu'il comporte l'un de ces paramètres de tâche, puis soumet une tâche avec l'emplacement du système de fichiers `/shared/projects/project2` comme valeur : 

```
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
```

 Le fichier journal de l'exécution de cette tâche contient sa sortie : 

```
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
```

# Obtenir des fichiers de sortie à partir d'une tâche
<a name="getting-output-files-from-a-job"></a>

Cet exemple montre comment Deadline Cloud identifie les fichiers de sortie générés par vos tâches, décide de télécharger ou non ces fichiers sur Amazon S3 et comment vous pouvez obtenir ces fichiers de sortie sur votre poste de travail. 

 Utilisez le lot de `job_attachments_devguide_output` tâches au lieu du lot de `job_attachments_devguide` tâches dans cet exemple. Commencez par créer une copie du bundle dans votre AWS CloudShell environnement à partir de votre clone du GitHub référentiel d'échantillons de Deadline Cloud : 

```
cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide_output ~/
```

 La différence importante entre cet ensemble de tâches et le lot de `job_attachments_devguide` tâches réside dans l'ajout d'un nouveau paramètre de tâche dans le modèle de tâche : 

```
...
parameterDefinitions:
...
- name: OutputDir
  type: PATH
  objectType: DIRECTORY
  dataFlow: OUT
  default: ./output_dir
  description: This directory contains the output for all steps.
...
```

 La `dataFlow` propriété du paramètre possède la valeur`OUT`. Deadline Cloud utilise la valeur des paramètres de `dataFlow` tâche avec une valeur égale `OUT` ou `INOUT` en tant que résultats de votre tâche. Si l'emplacement du système de fichiers transmis sous forme de valeur à ces types de paramètres de tâche est remappé à un emplacement du système de fichiers local sur le serveur de travail qui exécute le travail, Deadline Cloud recherchera de nouveaux fichiers à cet emplacement et les téléchargera sur Amazon S3 en tant que résultats de travail. 

 Pour voir comment cela fonctionne, lancez d'abord l'agent de travail Deadline Cloud dans un AWS CloudShell onglet. Laissez toutes les tâches déjà soumises terminer leur exécution. Supprimez ensuite les journaux des tâches du répertoire des journaux : 

```
rm -rf ~/devdemo-logs/queue-*
```

 Soumettez ensuite une tâche avec cet ensemble de tâches. Une fois que le worker a CloudShell exécuté vos courses, consultez les journaux : 

```
# 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
```

 Le journal indique qu'un fichier a été détecté en sortie et chargé sur Amazon S3 : 

```
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.
```

 Le journal indique également que Deadline Cloud a créé un nouvel objet manifeste dans le compartiment Amazon S3 configuré pour être utilisé par les pièces jointes aux tâches en file d'attente`Q1`. Le nom de l'objet manifeste est dérivé de la batterie de serveurs, de la file d'attente, de la tâche, de l'étape, de la tâche, de l'horodatage et des `sessionaction` identifiants de la tâche qui a généré le résultat. Téléchargez ce fichier manifeste pour voir où Deadline Cloud a placé les fichiers de sortie pour cette tâche : 

```
# 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 .
```

 Le manifeste se présente comme suit : 

```
{
  "hashAlg": "xxh128",
  "manifestVersion": "2023-03-03",
  "paths": [
    {
      "hash": "34178940e1ef9956db8ea7f7c97ed842",
      "mtime": 1721182390859777,
      "path": "output_dir/output.txt",
      "size": 117
    }
  ],
  "totalSize": 117
}
```

 Cela montre que le contenu du fichier de sortie est enregistré sur Amazon S3 de la même manière que les fichiers d'entrée des tâches. Comme pour les fichiers d'entrée, le fichier de sortie est stocké dans S3 avec un nom d'objet contenant le hachage du fichier et le préfixe`DeadlineCloud/Data`. 

```
$ aws s3 ls --recursive s3://$Q1_S3_BUCKET | grep 34178940e1ef9956db8ea7f7c97ed842
2024-07-17 02:13:11        117 DeadlineCloud/Data/34178940e1ef9956db8ea7f7c97ed842.xxh128
```

 Vous pouvez télécharger le résultat d'une tâche sur votre poste de travail à l'aide du moniteur Deadline Cloud ou de la CLI de Deadline Cloud : 

```
deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID
```

 La valeur du paramètre de `OutputDir` tâche dans la tâche soumise est`./output_dir`, de sorte que la sortie est téléchargée dans un répertoire appelé `output_dir` dans le répertoire du bundle de tâches. Si vous avez spécifié un chemin absolu ou un emplacement relatif différent comme valeur pour`OutputDir`, les fichiers de sortie seront plutôt téléchargés vers cet emplacement. 

```
$ 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)
```

# Utilisation des fichiers d'une étape dans une étape dépendante
<a name="using-files-output-from-a-step-in-a-dependent-step"></a>

Cet exemple montre comment une étape d'une tâche peut accéder aux sorties d'une étape dont elle dépend dans la même tâche. 

 Pour rendre les résultats d'une étape accessibles à une autre, Deadline Cloud ajoute des actions supplémentaires à une session afin de télécharger ces résultats avant d'exécuter des tâches dans la session. Vous lui indiquez à partir de quelles étapes télécharger les sorties en déclarant ces étapes comme des dépendances de l'étape qui doit utiliser les sorties. 

Utilisez le `job_attachments_devguide_output` job bundle pour cet exemple. Commencez par créer une copie dans votre AWS CloudShell environnement à partir de votre clone du GitHub référentiel d'échantillons de Deadline Cloud. Modifiez-le pour ajouter une étape dépendante qui ne s'exécute qu'après l'étape existante et utilise le résultat de cette étape : 

```
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
```

 La tâche créée avec cet ensemble de tâches modifié s'exécute sous la forme de deux sessions distinctes, une pour la tâche de l'étape « Étape », puis une seconde pour la tâche de l'étape « DependentStep ». 

Démarrez d'abord l'agent de travail de Deadline Cloud dans un CloudShell onglet. Laissez toutes les tâches déjà soumises terminer leur exécution, puis supprimez les journaux des tâches du répertoire des journaux : 

```
rm -rf ~/devdemo-logs/queue-*
```

 Soumettez ensuite une tâche à l'aide de l'ensemble de `job_attachments_devguide_output` tâches modifié. Attendez qu'il ait fini de s'exécuter sur le travailleur de votre CloudShell environnement. Consultez les journaux des deux sessions : 

```
# 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-*
```

 Dans le journal de session de la tâche de l'étape nommée`DependentStep`, deux actions de téléchargement distinctes sont exécutées : 

```
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.
```

 La première action télécharge le `script.sh` fichier utilisé par l'étape nommée « Étape ». La deuxième action télécharge les résultats de cette étape. Deadline Cloud détermine les fichiers à télécharger en utilisant le manifeste de sortie généré par cette étape comme manifeste d'entrée. 

 À la fin du même journal, vous pouvez voir le résultat de l'étape nommée DependentStep « » : 

```
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
```

# Création de limites de ressources pour les tâches
<a name="build-job-limits"></a>

Les tâches soumises à Deadline Cloud peuvent dépendre de ressources partagées entre plusieurs tâches. Par exemple, une ferme peut avoir plus de travailleurs que de permis flottants pour une ressource spécifique. Il se peut également qu'un serveur de fichiers partagé ne soit en mesure de fournir des données qu'à un nombre limité de travailleurs en même temps. Dans certains cas, une ou plusieurs tâches peuvent exiger toutes ces ressources, ce qui entraîne des erreurs dues à l'indisponibilité des ressources lorsque de nouveaux travailleurs commencent à travailler. 

Pour résoudre ce problème, vous pouvez utiliser *des limites* pour ces ressources limitées. Deadline Cloud tient compte de la disponibilité de ressources limitées et utilise ces informations pour garantir que les ressources sont disponibles au fur et à mesure que les nouveaux travailleurs démarrent, afin que les emplois soient moins susceptibles d'échouer en raison de l'indisponibilité des ressources.

Des limites sont créées pour l'ensemble de la ferme. Les tâches soumises à une file d'attente ne peuvent être soumises qu'aux limites associées à la file d'attente. Si vous spécifiez une limite pour une tâche qui n'est pas associée à la file d'attente, la tâche n'est pas compatible et ne sera pas exécutée.

Pour utiliser une limite, vous 
+ [Création d'une limite](job-limit-create.md)
+ [Associer une limite et une file d'attente](job-limit-associate.md)
+ [Soumettre une offre d'emploi nécessitant des limites](job-limit-job.md)

**Note**  
Si vous exécutez une tâche dont les ressources sont limitées dans une file d'attente non associée à une limite, cette tâche peut consommer toutes les ressources. Si votre ressource est limitée, assurez-vous que toutes les étapes des tâches dans les files d'attente qui utilisent cette ressource sont associées à une limite.

Pour les limites définies dans un parc de serveurs, associées à une file d'attente et spécifiées dans une tâche, l'une des quatre situations suivantes peut se produire :
+ Si vous créez une limite, que vous l'associez à une file d'attente et que vous spécifiez la limite dans le modèle d'une tâche, la tâche s'exécute et n'utilise que les ressources définies dans la limite.
+ Si vous créez une limite, que vous la spécifiez dans un modèle de tâche, mais que vous n'associez pas la limite à une file d'attente, la tâche est marquée comme incompatible et ne sera pas exécutée.
+ Si vous créez une limite, ne l'associez pas à une file d'attente et ne spécifiez pas la limite dans le modèle d'une tâche, la tâche s'exécute mais n'utilise pas la limite.
+ Si vous n'utilisez aucune limite, la tâche s'exécute.

Si vous associez une limite à plusieurs files d'attente, celles-ci partagent les ressources limitées par cette limite. Par exemple, si vous créez une limite de 100 et qu'une file d'attente utilise 60 ressources, les autres files d'attente ne peuvent utiliser que 40 ressources. Lorsqu'une ressource est publiée, elle peut être utilisée par une tâche de n'importe quelle file d'attente.

Deadline Cloud fournit deux AWS CloudFormation indicateurs pour vous aider à surveiller les ressources fournies par une limite. Vous pouvez surveiller le nombre actuel de ressources utilisées et le nombre maximum de ressources disponibles dans la limite. Pour plus d'informations, consultez la section [Mesures relatives aux limites de ressources](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits) dans le *guide du développeur de Deadline Cloud*.

Vous appliquez une limite à une étape de tâche dans un modèle de tâche. Lorsque vous spécifiez le nom du montant requis pour une limite dans la `amounts` section `hostRequirements` d'une étape et qu'une limite associée à ce montant `amountRequirementName` est associée à la file d'attente du travail, les tâches planifiées pour cette étape sont limitées par la limite de la ressource.

Si une étape nécessite une ressource limitée par une limite atteinte, les tâches de cette étape ne seront pas prises en charge par des travailleurs supplémentaires.

Vous pouvez appliquer plusieurs limites à une étape de travail. Par exemple, si l'étape utilise deux licences logicielles différentes, vous pouvez appliquer une limite distincte pour chaque licence. Si une étape nécessite deux limites et que la limite de l'une des ressources est atteinte, les tâches de cette étape ne seront pas prises en charge par d'autres travailleurs tant que les ressources ne seront pas disponibles.

## Arrêter et supprimer des limites
<a name="job-limit-stop-delete"></a>

Lorsque vous arrêtez ou supprimez l'association entre une file d'attente et une limite, une tâche utilisant la limite arrête de planifier les tâches à partir des étapes qui nécessitent cette limite et bloque la création de nouvelles sessions pour une étape.

Les tâches à l'état PRÊT restent prêtes, et les tâches reprennent automatiquement lorsque l'association entre la file d'attente et la limite redevient active. Vous n'avez pas besoin de demander des offres d'emploi.

Lorsque vous arrêtez ou supprimez l'association entre une file d'attente et une limite, deux options s'offrent à vous pour arrêter l'exécution des tâches :
+ Arrêter et annuler des tâches : les travailleurs dont les sessions ont atteint la limite annulent toutes les tâches.
+ Arrêtez et terminez l'exécution des tâches : les travailleurs dont les sessions ont atteint la limite terminent leurs tâches.

Lorsque vous supprimez une limite à l'aide de la console, les collaborateurs arrêtent d'abord d'exécuter les tâches immédiatement ou éventuellement lorsqu'elles sont terminées. Lorsque l'association est supprimée, les événements suivants se produisent : 
+ Les étapes nécessitant cette limite sont signalées comme non compatibles.
+ L'intégralité de la tâche contenant ces étapes est annulée, y compris les étapes qui ne nécessitent pas de limite.
+ La tâche est marquée comme non compatible.

Si la file d'attente associée à la limite est associée à un parc dont la capacité correspond au nom du montant requis pour la limite, ce parc continuera à traiter les tâches avec la limite spécifiée.

# Création d'une limite
<a name="job-limit-create"></a>

Vous créez une limite à l'aide de la console Deadline Cloud ou de l'[CreateLimit opération de l'API Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html). Les limites sont définies pour un parc, mais associées à des files d'attente. Après avoir créé une limite, vous pouvez l'associer à une ou plusieurs files d'attente.

**Pour créer une limite**

1. Dans le tableau de bord de la console [Deadline Cloud (console](https://console.aws.amazon.com/deadlinecloud/home) Deadline Cloud), sélectionnez la ferme pour laquelle vous souhaitez créer une file d'attente.

1. Choisissez la ferme à laquelle ajouter la limite, cliquez sur l'onglet **Limites**, puis choisissez **Créer une limite**.

1. Fournissez les détails de la limite. Le **nom de l'exigence de montant** est le nom utilisé dans le modèle de tâche pour identifier la limite. Il doit commencer par le préfixe **amount.** suivi du nom du montant. Le nom du montant requis doit être unique dans les files d'attente associées à la limite.

1. Si vous choisissez **Définir un montant maximum**, il s'agit du nombre total de ressources autorisées par cette limite. Si vous choisissez **Aucun montant maximum**, l'utilisation des ressources n'est pas limitée. Même lorsque l'utilisation des ressources n'est pas limitée, la CloudWatch métrique `CurrentCount` Amazon est émise afin que vous puissiez suivre l'utilisation. Pour plus d'informations, consultez les [CloudWatchstatistiques](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html) dans le *guide du développeur de Deadline Cloud*.

1. Si vous connaissez déjà les files d'attente qui devraient utiliser cette limite, vous pouvez les choisir dès maintenant. Il n'est pas nécessaire d'associer une file d'attente pour créer une limite.

1. Choisissez **Créer une limite**.

# Associer une limite et une file d'attente
<a name="job-limit-associate"></a>

Après avoir créé une limite, vous pouvez associer une ou plusieurs files d'attente à la limite. Seules les files d'attente associées à une limite utilisent les valeurs spécifiées dans la limite.

Vous créez une association avec une file d'attente à l'aide de la console Deadline Cloud ou de l'[CreateQueueLimitAssociation opération de l'API Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html).

**Pour associer une file d'attente à une limite**

1. Dans le tableau de bord de la console [Deadline Cloud (console](https://console.aws.amazon.com/deadlinecloud/home) Deadline Cloud), sélectionnez la ferme dans laquelle vous souhaitez associer une limite à une file d'attente.

1. Cliquez sur l'onglet **Limites**, choisissez la limite à laquelle associer une file d'attente, puis choisissez **Modifier la limite**.

1. Dans la section **Associer les files d'attente**, choisissez les files d'attente à associer à la limite.

1. Sélectionnez **Enregistrer les modifications**.

# Soumettre une offre d'emploi nécessitant des limites
<a name="job-limit-job"></a>

Vous appliquez une limite en la spécifiant comme exigence d'hôte pour le travail ou l'étape du travail. Si vous ne spécifiez pas de limite dans une étape et que cette étape utilise une ressource associée, l'utilisation de l'étape n'est pas prise en compte dans la limite lorsque les tâches sont planifiées.

Certains émetteurs de Deadline Cloud vous permettent de définir une exigence en matière d'hôte. Vous pouvez spécifier le nom du montant requis pour la limite dans l'expéditeur pour appliquer la limite.

Si votre auteur ne prend pas en charge l'ajout d'exigences relatives à l'hôte, vous pouvez également appliquer une limite en modifiant le modèle de tâche correspondant à la tâche.

**Pour appliquer une limite à une étape d'une tâche dans le lot de tâches**

1. Ouvrez le modèle de tâche correspondant à la tâche à l'aide d'un éditeur de texte. Le modèle de tâche se trouve dans le répertoire des ensembles de tâches correspondant à la tâche. Pour plus d'informations, consultez la section [Job bundles](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/build-job-bundle.html) dans le *guide du développeur de Deadline Cloud*.

1. Trouvez la définition de l'étape à laquelle appliquer la limite.

1. Ajoutez ce qui suit à la définition de l'étape. Remplacez *amount.name* le nom de votre limite par le montant requis. Pour une utilisation normale, vous devez définir la `min` valeur sur 1.

------
#### [ YAML ]

   ```
     hostRequirements:
       amounts:
       - name: amount.name
         min: 1
   ```

------
#### [ JSON ]

   ```
   "hostRequirements": {
       "amounts": [
           {
               "name": "amount.name",
               "min": "1"
           }
       }
   }
   ```

------

   Vous pouvez ajouter plusieurs limites à une étape de travail comme suit. Remplacez *amount.name\$11* et *amount.name\$12* par les noms des exigences relatives au montant de vos limites.

------
#### [ 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. Enregistrez les modifications apportées au modèle de tâche.

# Comment soumettre une offre d'emploi à Deadline Cloud
<a name="submit-jobs-how"></a>

Il existe de nombreuses manières de soumettre des offres d'emploi à AWS Deadline Cloud. Cette section décrit certaines des manières dont vous pouvez soumettre des tâches à l'aide des outils fournis par Deadline Cloud ou en créant vos propres outils personnalisés pour vos charges de travail. 
+ Depuis un terminal : lorsque vous développez un ensemble de tâches pour la première fois ou lorsque les utilisateurs qui soumettent une tâche sont à l'aise avec la ligne de commande
+ À partir d'un script, pour personnaliser et automatiser les charges de travail
+ À partir d'une application : lorsque le travail de l'utilisateur est effectué dans une application ou lorsque le contexte d'une application est important.

 Les exemples suivants utilisent la bibliothèque `deadline` Python et l'outil de ligne de `deadline` commande. Les deux sont disponibles [PyPi](https://pypi.org/project/deadline/)et [hébergés sur GitHub](https://github.com/aws-deadline/deadline-cloud). 

**Topics**
+ [Soumettre une offre d'emploi à Deadline Cloud depuis un terminal](from-a-terminal.md)
+ [Soumettre une tâche à Deadline Cloud à l'aide d'un script](from-a-script.md)
+ [Soumettre une offre d'emploi dans le cadre d'une candidature](from-within-applications.md)

# Soumettre une offre d'emploi à Deadline Cloud depuis un terminal
<a name="from-a-terminal"></a>

En utilisant uniquement un ensemble de tâches et la CLI de Deadline Cloud, vous ou vos utilisateurs plus techniques pouvez rapidement itérer sur la rédaction de lots de tâches pour tester la soumission d'une tâche. Utilisez la commande suivante pour soumettre un ensemble de tâches : 

```
deadline bundle submit <path-to-job-bundle>
```

 Si vous soumettez un ensemble de tâches dont les paramètres ne sont pas définis par défaut, vous pouvez les spécifier à l'aide de l'`--parameter`option`-p`/. 

```
deadline bundle submit <path-to-job-bundle> -p <parameter-name>=<parameter-value> -p ...
```

 Pour obtenir la liste complète des options disponibles, exécutez la commande d'aide : 

```
deadline bundle submit --help
```

## Soumettre une tâche à Deadline Cloud à l'aide d'une interface graphique
<a name="with-a-submission-window"></a>

 La CLI de Deadline Cloud est également dotée d'une interface utilisateur graphique qui permet aux utilisateurs de voir les paramètres qu'ils doivent fournir avant de soumettre une tâche. Si vos utilisateurs préfèrent ne pas interagir avec la ligne de commande, vous pouvez écrire un raccourci sur le bureau qui ouvre une boîte de dialogue pour soumettre un ensemble de tâches spécifique : 

```
deadline bundle gui-submit <path-to-job-bundle>
```

 Utilisez l'`--browse`option can afin que l'utilisateur puisse sélectionner un ensemble de tâches : 

```
deadline bundle gui-submit --browse
```

 Pour obtenir la liste complète des options disponibles, exécutez la commande d'aide : 

```
deadline bundle gui-submit --help
```

# Soumettre une tâche à Deadline Cloud à l'aide d'un script
<a name="from-a-script"></a>

 Pour automatiser la soumission de tâches à Deadline Cloud, vous pouvez les scripter à l'aide d'outils tels que bash, Powershell et de fichiers batch. 

Vous pouvez ajouter des fonctionnalités telles que le remplissage des paramètres de tâche à partir de variables d'environnement ou d'autres applications. Vous pouvez également soumettre plusieurs tâches d'affilée ou créer un script pour créer un ensemble de tâches à soumettre. 

## Soumettre une offre d'emploi en Python
<a name="with-python"></a>

Deadline Cloud dispose également d'une bibliothèque Python open source pour interagir avec le service. Le [code source est disponible sur GitHub](https://github.com/aws-deadline/deadline-cloud). 

La bibliothèque est disponible sur pypi via pip (). `pip install deadline` Il s'agit de la même bibliothèque que celle utilisée par l'outil Deadline Cloud CLI : 

```
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)
```

 Pour créer une boîte de dialogue comme la `deadline bundle gui-submit` commande, vous pouvez utiliser la `show_job_bundle_submitter` fonction du [`deadline.client.ui.job_bundle_submitter`.](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/job_bundle_submitter.py) 

 L'exemple suivant démarre une application Qt et montre l'expéditeur du bundle de tâches : 

```
# 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)
```

Pour créer votre propre boîte de dialogue, vous pouvez utiliser la `SubmitJobToDeadlineDialog` classe dans [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). Vous pouvez transmettre des valeurs, intégrer votre propre onglet spécifique à la tâche et déterminer comment le lot de tâches est créé (ou transmis). 

# Soumettre une offre d'emploi dans le cadre d'une candidature
<a name="from-within-applications"></a>

 Pour permettre aux utilisateurs de soumettre facilement des tâches, vous pouvez utiliser les environnements d'exécution de script ou les systèmes de plugins fournis par une application. Les utilisateurs disposent d'une interface familière et vous pouvez créer de puissants outils qui les aident lors de la soumission d'une charge de travail. 

## Intégrer des offres d'emploi dans une candidature
<a name="simple-embedding"></a>

Cet exemple montre comment soumettre des offres d'emploi que vous mettez à disposition dans l'application.

 Pour permettre à un utilisateur d'accéder à ces ensembles de tâches, créez un script intégré dans un élément de menu qui lance la CLI de Deadline Cloud. 

 Le script suivant permet à l'utilisateur de sélectionner le lot de tâches : 

```
deadline bundle gui-submit --install-gui
```

 Pour utiliser un ensemble de tâches spécifique dans un élément de menu à la place, utilisez ce qui suit : 

```
deadline bundle gui-submit </path/to/job/bundle> --install-gui
```

 Cela ouvre une boîte de dialogue dans laquelle l'utilisateur peut modifier les paramètres, les entrées et les sorties de la tâche, puis soumettre la tâche. Vous pouvez avoir différents éléments de menu pour différents ensembles de tâches à soumettre par un utilisateur dans le cadre d'une candidature. 

Si le travail que vous soumettez avec un ensemble de tâches contient des paramètres et des références d'actifs similaires dans toutes les soumissions, vous pouvez renseigner les valeurs par défaut dans le lot de tâches sous-jacent. 

## Obtenir des informations à partir d'une application
<a name="deep-integration"></a>

Pour extraire des informations d'une application afin que les utilisateurs n'aient pas à les ajouter manuellement à la soumission, vous pouvez intégrer Deadline Cloud à l'application afin que vos utilisateurs puissent soumettre des tâches via une interface familière sans avoir à quitter l'application ou à utiliser des outils de ligne de commande.

Si votre application dispose d'un environnement d'exécution de script qui prend en charge Python et pyside/pyqt, vous pouvez utiliser les composants de l'interface graphique de la [bibliothèque cliente de Deadline Cloud pour créer](https://github.com/aws-deadline/deadline-cloud) une interface utilisateur. Pour un exemple, consultez [Deadline Cloud pour l'intégration de Maya](https://github.com/aws-deadline/deadline-cloud-for-maya) sur GitHub. 

La bibliothèque cliente de Deadline Cloud propose les opérations suivantes pour vous aider à fournir une expérience utilisateur intégrée solide :
+ Extrayez les paramètres d'environnement de la file d'attente, les paramètres de tâche et les références aux actifs à partir de variables d'environnement et en appelant le SDK de l'application.
+ Définissez les paramètres dans le bundle de tâches. Pour éviter de modifier le lot d'origine, vous devez en faire une copie et envoyer la copie.

Si vous utilisez la `deadline bundle gui-submit` commande pour soumettre le bundle de tâches, vous devez programmer les `asset_references.yaml` fichiers `parameter_values.yaml` et pour transmettre les informations de l'application. Pour plus d'informations sur ces fichiers, consultez[Modèles Open Job Description (OpenJD) pour Deadline Cloud](build-job-bundle.md).

Si vous avez besoin de contrôles plus complexes que ceux proposés par OpenJD, si vous souhaitez soustraire le travail à l'utilisateur ou si vous souhaitez que l'intégration corresponde au style visuel de l'application, vous pouvez écrire votre propre boîte de dialogue qui appelle la bibliothèque cliente de Deadline Cloud pour soumettre le travail.

# Planifier des tâches dans Deadline Cloud
<a name="build-jobs-scheduling"></a>

Après la création d'une tâche, AWS Deadline Cloud planifie son traitement sur une ou plusieurs flottes associées à une file d'attente. La flotte qui traite une tâche particulière est choisie en fonction des capacités configurées pour la flotte et des exigences de l'hôte pour une étape spécifique.

Les tâches d'une file d'attente sont planifiées dans l'ordre de priorité le plus élevé, du plus élevé au plus bas. Lorsque deux tâches ont la même priorité, la tâche la plus ancienne est planifiée en premier.

Les sections suivantes fournissent des informations détaillées sur le processus de planification d'une tâche.

## Déterminer la compatibilité de la flotte
<a name="jobs-scheduling-compatibility"></a>

Après la création d'une tâche, Deadline Cloud vérifie les exigences de l'hôte pour chaque étape de la tâche par rapport aux capacités des flottes associées à la file d'attente à laquelle la tâche a été soumise. Si une flotte répond aux exigences de l'hôte, le poste est confié à l'`READY`État.

Si une étape de la tâche comporte des exigences qui ne peuvent pas être satisfaites par une flotte associée à la file d'attente, le statut de l'étape est défini sur`NOT_COMPATIBLE`. De plus, les autres étapes de la tâche sont annulées.

Les capacités d'une flotte sont définies au niveau de la flotte. Même si un travailleur d'un parc répond aux exigences du poste, aucune tâche ne lui sera assignée si son parc ne répond pas aux exigences du poste.

Le modèle de tâche suivant comporte une étape qui spécifie les exigences de l'hôte pour l'étape :

```
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
```

Cette tâche peut être planifiée pour une flotte dotée des fonctionnalités suivantes :

```
{
    "vCpuCount": {"min": 4, "max": 8},
    "memoryMiB": {"min": 1024},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64"
}
```

Cette tâche ne peut pas être planifiée pour une flotte dotée de l'une des fonctionnalités suivantes :

```
{
    "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.
```

## Dimensionnement du parc
<a name="jobs-scheduling-scaling"></a>

Lorsqu'une tâche est attribuée à un parc géré par des services compatibles, le parc est redimensionné automatiquement. Le nombre de travailleurs de la flotte varie en fonction du nombre de tâches pouvant être exécutées par la flotte.

Lorsqu'une tâche est attribuée à un parc géré par le client, il se peut que des employés existent déjà ou qu'ils puissent être créés à l'aide de la mise à l'échelle automatique basée sur les événements. Pour plus d'informations, consultez la section [Utiliser EventBridge pour gérer les événements de dimensionnement automatique](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) dans le guide de l'*utilisateur d'Amazon EC2 Auto Scaling*.

## Séances
<a name="jobs-scheduling-sessions"></a>

Les tâches d'une tâche sont divisées en une ou plusieurs sessions. Les travailleurs exécutent les sessions pour configurer l'environnement, exécuter les tâches, puis détruire l'environnement. Chaque session est composée d'une ou de plusieurs actions que le travailleur doit effectuer.

Au fur et à mesure qu'un collaborateur exécute des actions de section, des actions de session supplémentaires peuvent lui être envoyées. Le travailleur réutilise les environnements existants et les pièces jointes aux tâches au cours de la session pour effectuer les tâches de manière plus efficace.

Pour les employés de flotte gérés par des services, les répertoires de sessions sont supprimés à la fin de la session, mais les autres répertoires sont conservés entre les sessions. Ce comportement vous permet de mettre en œuvre des stratégies de mise en cache pour les données qui peuvent être réutilisées au cours de plusieurs sessions. Pour mettre en cache les données entre les sessions, stockez-les dans le répertoire personnel de l'utilisateur exécutant le travail. Par exemple, les packages conda sont mis en cache dans le répertoire personnel de l'utilisateur à l'adresse `C:\Users\job-user\.conda-pkgs` on Windows workers et `/home/job-user/.conda-pkgs` on Linux workers. Ces données restent disponibles jusqu'à ce que le travailleur arrête ses activités.

Les pièces jointes aux tâches sont créées par l'émetteur que vous utilisez dans le cadre de votre offre de tâches Deadline Cloud CLI. Vous pouvez également créer des pièces jointes à des tâches à l'aide de l'`--attachments`option de `create-job` AWS CLI commande. Les environnements sont définis à deux endroits : les environnements de file d'attente attachés à une file d'attente spécifique et les environnements de travail et d'étapes définis dans le modèle de travail.

Il existe quatre types d'actions de session :
+ `syncInputJobAttachments`— Télécharge les pièces jointes aux tâches saisies vers le travailleur.
+ `envEnter`— Exécute les `onEnter` actions pour un environnement.
+ `taskRun`— Exécute les `onRun` actions correspondant à une tâche.
+ `envExit`— Exécute les `onExit` actions pour un environnement.

Le modèle de tâche suivant comporte un environnement par étapes. Il contient une `onEnter` définition pour configurer l'environnement des étapes, une `onRun` définition qui définit la tâche à exécuter et une `onExit` définition pour démonter l'environnement des étapes. Les sessions créées pour cette tâche incluront une `envEnter` action, une ou plusieurs `taskRun` actions, puis une `envExit` action.

```
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 des actions de session
<a name="jobs-session-pipelining"></a>

Le pipeline des actions de session permet à un planificateur de préattribuer plusieurs actions de session à un travailleur. Le travailleur peut ensuite exécuter ces actions de manière séquentielle, ce qui réduit ou élimine le temps d'inactivité entre les tâches.

Pour créer une affectation initiale, le planificateur crée une session avec une tâche, le collaborateur exécute la tâche, puis le planificateur analyse la durée de la tâche pour déterminer les futures affectations.

Pour que le planificateur soit efficace, il existe des règles relatives à la durée des tâches. Pour les tâches de moins d'une minute, le planificateur utilise un schéma de croissance basé sur la puissance de 2. Par exemple, pour une tâche d'une seconde, le planificateur affecte 2 nouvelles tâches, puis 4, puis 8. Pour les tâches de plus d'une minute, le planificateur n'assigne qu'une seule nouvelle tâche et le pipeline reste désactivé.

Pour calculer la taille du pipeline, le planificateur effectue les opérations suivantes :
+ Utilise la durée moyenne des tâches par rapport aux tâches terminées
+ Vise à occuper le travailleur pendant une minute
+ Ne prend en compte que les tâches au cours de la même session
+ Ne partage pas les données relatives à la durée entre les travailleurs

Grâce au pipeline des actions de session, les employés commencent immédiatement de nouvelles tâches et il n'y a aucun temps d'attente entre les demandes du planificateur. Il permet également d'améliorer l'efficacité des travailleurs et de mieux répartir les tâches pour les processus de longue durée.

En outre, si une nouvelle tâche plus prioritaire est disponible, le travailleur terminera toutes les tâches précédemment assignées avant la fin de sa session en cours et une nouvelle session provenant d'une tâche plus prioritaire sera attribuée.

## Dépendances des étapes
<a name="jobs-scheduling-dependencies"></a>

Deadline Cloud prend en charge la définition des dépendances entre les étapes afin qu'une étape attende la fin d'une autre étape avant de commencer. Vous pouvez définir plusieurs interdépendances pour une étape. Une étape comportant une dépendance n'est pas planifiée tant que toutes ses dépendances ne sont pas terminées.

Si le modèle de tâche définit une dépendance circulaire, la tâche est rejetée et son statut est défini sur`CREATE_FAILED`.

Le modèle de tâche suivant crée une tâche en deux étapes. `StepB`dépend de`StepA`. `StepB`ne s'exécute qu'une fois `StepA` terminé avec succès. 

Une fois le travail créé, `StepA` il est dans l'`READY`état et `StepB` est dans l'`PENDING`état. Après avoir `StepA` terminé, `StepB` passe à l'`READY`état. En cas d'`StepA`échec ou `StepA` d'annulation, `StepB` passe à l'`CANCELED`état.

Vous pouvez définir une dépendance pour plusieurs étapes. Par exemple, si `StepC` cela dépend des deux `StepA` et`StepB`, `StepC` ne démarrera pas tant que les deux autres étapes ne seront pas terminées.

Les dépendances entre les étapes sont soumises aux restrictions suivantes :
+ **Dépendances par étape** — Une étape peut dépendre d'un maximum de 128 autres étapes.
+ **Consommateurs par étape** — Un maximum de 32 autres étapes peut dépendre d'une seule étape.

```
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!
```

# Modifier une tâche dans Deadline Cloud
<a name="build-jobs-modifying"></a>

Vous pouvez utiliser les `update` commandes suivantes AWS Command Line Interface (AWS CLI) pour modifier la configuration d'une tâche ou pour définir le statut cible d'une tâche, d'une étape ou d'une tâche : ``
+ `aws deadline update-job`
+ `aws deadline update-step`
+ `aws deadline update-task`

Dans les exemples de `update` commandes suivants, remplacez chacune *`user input placeholder`* par vos propres informations.

**Example — Demander une offre d'emploi**  
Toutes les tâches de la tâche passent au `READY` statut, sauf s'il existe des dépendances entre les étapes. Les étapes comportant des dépendances passent à l'une `READY` ou l'autre à `PENDING` mesure qu'elles sont restaurées.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status PENDING
```

**Example — Annuler une offre d'emploi**  
Toutes les tâches de la tâche qui n'ont pas le statut requis `SUCCEEDED` ou qui `FAILED` sont marquées`CANCELED`.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status CANCELED
```

**Example — Marquer l'échec d'une tâche**  
Toutes les tâches du poste dont le statut est défini `SUCCEEDED` restent inchangées. Toutes les autres tâches sont marquées`FAILED`.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status FAILED
```

**Example — Marquer un travail réussi**  
Toutes les tâches du poste sont transférées à l'`SUCCEEDED`état.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status SUCCEEDED
```

**Example — Suspendre une tâche**  
Les tâches du poste dans l'`FAILED`état `SUCCEEDED``CANCELED`, ou ne changent pas. Toutes les autres tâches sont marquées`SUSPENDED`.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status SUSPENDED
```

**Example — Modifier la priorité d'une tâche**  
Met à jour la priorité d'une tâche dans une file d'attente pour modifier l'ordre dans lequel elle est planifiée. Les tâches les plus prioritaires sont généralement planifiées en premier.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--priority 100
```

**Example — Modifie le nombre de tâches échouées autorisées**  
Actualise le nombre maximum de tâches échouées que la tâche peut avoir avant que les tâches restantes ne soient annulées.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--max-failed-tasks-count 200
```

**Example — Modifie le nombre de tentatives de tâches autorisées**  
Actualise le nombre maximal de tentatives pour une tâche avant que celle-ci n'échoue. Une tâche qui a atteint le nombre maximum de tentatives ne peut pas être mise en attente tant que cette valeur n'est pas augmentée.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--max-retries-per-task 10
```

**Example — Archiver une tâche**  
Met à jour l'état du cycle de vie de la tâche sur`ARCHIVED`. Les tâches archivées ne peuvent être ni planifiées ni modifiées. Vous ne pouvez archiver qu'une tâche dont l'`SUSPENDED`état est `FAILED` `CANCELED``SUCCEEDED`,, ou.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--lifecycle-status ARCHIVED
```

**Example — Changer le nom d'une tâche**  
Met à jour le nom d'affichage d'une tâche. Le nom de la tâche peut comporter jusqu'à 128 caractères.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--name "New Job Name"
```

**Example — Modifier la description d'un poste**  
Met à jour la description d'une tâche. La description peut comporter jusqu'à 2 048 caractères. Pour supprimer la description existante, transmettez une chaîne vide.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--description "New Job Description"
```

**Example — Demander une étape**  
Toutes les tâches de l'étape passent à l'`READY`état, sauf s'il existe des dépendances entre les étapes. Les tâches des étapes comportant des dépendances passent à l'une `READY` ou l'autre`PENDING`, et la tâche est restaurée.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status PENDING
```

**Example — Annuler une étape**  
Toutes les tâches de l'étape qui n'ont pas le statut `SUCCEEDED` ou qui `FAILED` sont marquées`CANCELED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status CANCELED
```

**Example — Marquer l'échec d'une étape**  
Toutes les tâches de l'étape dont le statut est `SUCCEEDED` défini restent inchangées. Toutes les autres tâches sont marquées`FAILED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status FAILED
```

**Example — Marquer une étape comme réussie**  
Toutes les tâches de l'étape sont marquées`SUCCEEDED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status SUCCEEDED
```

**Example — Suspendre une étape**  
Les tâches de l'étape à l'`FAILED`état `SUCCEEDED``CANCELED`, ou ne changent pas. Toutes les autres tâches sont marquées`SUSPENDED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status SUSPENDED
```

**Example — Modifier le statut d'une tâche**  
Lorsque vous utilisez la commande `update-task` Deadline Cloud CLI, la tâche passe à l'état spécifié.  

```
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
```