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.

Planifier des tâches dans Deadline Cloud

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 sont planifiées dans l'ordre de priorité du meilleur effort, du plus haut 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

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 surNOT_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 affecté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 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

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 dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.

Séances

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 qu'un collaborateur 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.

Les pièces jointes aux tâches sont créées par l'expéditeur que vous utilisez dans le cadre de votre offre de CLI tâches Deadline Cloud. Vous pouvez également créer des pièces jointes à des tâches à l'aide de l'--attachmentsoption 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 :

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

Dépendances des étapes

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 planifiée que lorsque toutes ses dépendances sont 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 surCREATE_FAILED.

Le modèle de tâche suivant crée une tâche en deux étapes. StepBdépend deStepA. StepBne 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 etStepB, StepC ne démarrera pas tant que les deux autres étapes ne seront pas terminées.

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!