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.
# Configuration des tâches à l'aide d'environnements de file d'
AWS Deadline Cloud utilise *des environnements de file d'attente* pour configurer le logiciel sur vos employés. Un environnement vous permet d'effectuer des tâches chronophages, telles que la configuration et le démontage, une fois pour toutes les tâches d'une session. Il définit les actions à exécuter sur un travailleur lors du démarrage ou de l'arrêt d'une session. Vous pouvez configurer un environnement pour une file d'attente, les tâches exécutées dans la file d'attente et les étapes individuelles d'une tâche.
Vous définissez les environnements comme des environnements de file d'attente ou des environnements de travail. Créez des environnements de file d'attente avec la console Deadline Cloud ou avec l'CreateQueueEnvironmentopération [deadline :](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueEnvironment.html) et définissez des environnements de travail dans les modèles de tâches des tâches que vous soumettez. Ils suivent la spécification Open Job Description (OpenJD) pour les environnements. Pour plus de détails, reportez-vous[https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) à la spécification OpenJD sur GitHub.
Outre un `name` et`description`, chaque environnement contient deux champs qui définissent l'environnement sur l'hôte. Il s'agit des options suivantes :
+ `script`— L'action entreprise lorsque cet environnement est exécuté sur un travailleur.
+ `variables`— Ensemble de name/value paires de variables d'environnement définies lors de l'entrée dans l'environnement.
Vous devez définir au moins l'une des valeurs suivantes : `script` ou`variables`.
Vous pouvez définir plusieurs environnements dans votre modèle de tâche. Chaque environnement est appliqué dans l'ordre dans lequel il est répertorié dans le modèle. Vous pouvez l'utiliser pour gérer la complexité de vos environnements.
L'environnement de file d'attente par défaut pour Deadline Cloud utilise le gestionnaire de packages conda pour charger le logiciel dans l'environnement, mais vous pouvez utiliser d'autres gestionnaires de packages. L'environnement par défaut définit deux paramètres pour spécifier le logiciel à charger. Ces variables sont définies par les émetteurs fournis par Deadline Cloud, mais vous pouvez les définir dans vos propres scripts et applications utilisant l'environnement par défaut. Il s'agit des options suivantes :
+ `CondaPackages`— Une liste séparée par des espaces des packages conda correspondant aux spécifications à installer pour le travail. Par exemple, l'émetteur de Blender ajouterait des images `blender=3.6` au rendu dans Blender 3.6.
+ `CondaChannels`— Liste séparée par des espaces de canaux conda à partir desquels installer les packages. Pour les flottes gérées par des services, les packages sont installés depuis le canal. `deadline-cloud` Vous pouvez ajouter d'autres chaînes.
# Contrôlez l'environnement de travail avec les environnements de file d'attente OpenJD
Vous pouvez définir des environnements personnalisés pour vos tâches de rendu à l'aide *d'environnements de file d'attente*. Un environnement de file d'attente est un modèle qui contrôle les variables d'environnement, les mappages de fichiers et les autres paramètres des tâches exécutées dans une file d'attente spécifique. Il vous permet d'adapter l'environnement d'exécution des tâches soumises à une file d'attente aux exigences de vos charges de travail. AWS Deadline Cloud propose trois niveaux imbriqués dans lesquels vous pouvez appliquer les [environnements Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) : file d'attente, job et step. En définissant des environnements de file d'attente, vous pouvez garantir des performances cohérentes et optimisées pour différents types de tâches, rationaliser l'allocation des ressources et simplifier la gestion des files d'attente.
L'environnement de file d'attente est un modèle que vous attachez à une file d'attente de votre AWS compte depuis la console de AWS gestion ou à l'aide du AWS CLI. Vous pouvez créer un environnement pour une file d'attente, ou vous pouvez créer plusieurs environnements de file d'attente qui s'appliquent afin de créer l'environnement d'exécution. Cette approche vous permet de créer et de tester un environnement par étapes afin de vous assurer qu'il fonctionne correctement pour vos tâches.
Les environnements des tâches et des étapes sont définis dans le modèle de tâche que vous utilisez pour créer une tâche dans votre file d'attente. La syntaxe OpenJD est la même dans ces différentes formes d'environnements. Dans cette section, nous les montrerons à l'intérieur des modèles de tâches.
**Topics**
+ [Définir des variables d'environnement dans un environnement de file d'attente](set-environment-variables.md)
+ [Définir le chemin dans un environnement de file d'attente](set-the-path.md)
+ [Exécuter un processus daemon en arrière-plan depuis l'environnement de file d'attente](run-a-background-daemon-process.md)
# Définir des variables d'environnement dans un environnement de file d'attente
De nombreuses applications et frameworks utilisent des variables d'environnement pour contrôler les paramètres des fonctionnalités, les niveaux de journalisation et la configuration de l'affichage. Vous pouvez utiliser les [environnements Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) pour définir des variables d'environnement dont héritera chaque commande de tâche relevant de leur champ d'application.
## Portée de la variable d'environnement
AWS Deadline Cloud applique des variables d'environnement issues des environnements de file d'attente que vous attachez à une file d'attente. Dans un modèle de tâche, vous pouvez également définir des variables d'environnement au niveau de la tâche et de l'étape à l'aide des [environnements OpenJD.](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) Les variables définies dans une portée plus étroite remplacent les variables portant le même nom dans une portée plus large.
+ **Environnement de file d'attente** : modèle que vous attachez à une file d'attente dans Deadline Cloud. Les variables s'appliquent à toutes les tâches soumises à la file d'attente. Vous pouvez définir des variables à l'aide d'une `variables` carte pour les valeurs fixes ou utiliser des scripts pour les valeurs dynamiques.
+ **Environnement de travail** : défini ci-dessous `jobEnvironments` dans un modèle de travail. Les variables s'appliquent à toutes les étapes et tâches du travail. Une variable au niveau de la tâche remplace une variable au niveau de la file d'attente portant le même nom.
+ **Environnement des étapes** : défini ci-dessous `stepEnvironments` dans un modèle de tâche. Les variables s'appliquent uniquement aux tâches de cette étape. Une variable de niveau étape remplace une variable de niveau tâche ou de file d'attente portant le même nom.
## Définition de variables dans un environnement de file d'attente
Vous pouvez définir des variables d'environnement dans un environnement de file d'attente à l'aide d'une `variables` carte pour les valeurs fixes ou à l'`script`aide d'une `onEnter` action pour les valeurs dynamiques.
Le modèle d'environnement de file d'attente suivant utilise une `variables` carte pour définir la `QT_QPA_PLATFORM` variable sur`offscreen`, ce qui permet aux applications utilisant le [Qt Framework](https://www.qt.io/product/framework) de s'exécuter sur des hôtes de travail sans affichage interactif.
```
specificationVersion: 'environment-2023-09'
environment:
name: QtOffscreen
variables:
QT_QPA_PLATFORM: offscreen
```
Pour les valeurs dynamiques, telles que la modification `PATH` ou l'activation d'environnements virtuels, utilisez un script qui imprime des lignes `openjd_env: VAR=value` au format standard. Le `openjd_env:` préfixe est obligatoire. L'utilisation de `echo``export`, ou d'autres mécanismes shell sans le préfixe ne propage pas les variables vers les jobs et les tâches.
Le modèle d'environnement de file d'attente suivant définit la `QT_QPA_PLATFORM` variable à l'aide d'un script.
```
specificationVersion: 'environment-2023-09'
environment:
name: QtOffscreen
script:
actions:
onEnter:
command: bash
args:
- "{{Env.File.Enter}}"
embeddedFiles:
- name: Enter
type: TEXT
data: |
#!/bin/env bash
set -euo pipefail
echo "openjd_env: QT_QPA_PLATFORM=offscreen"
```
Pour associer un environnement de file d'attente à votre file d'attente, utilisez la console Deadline Cloud ou le AWS CLI. Pour plus d'informations, consultez la section [Création d'un environnement de file d'attente](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html) dans le guide de l'utilisateur de AWS Deadline Cloud. La AWS CLI commande suivante crée un environnement de file d'attente à partir d'un fichier modèle.
```
aws deadline create-queue-environment \
--farm-id FARM_ID \
--queue-id QUEUE_ID \
--priority 1 \
--template-type YAML \
--template file://my-queue-env.yaml
```
Pour des exemples plus complexes, tels que la création et l'activation d'environnements virtuels Conda, consultez les [exemples d'environnement de file d'attente Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/queue_environments) sur GitHub.
## Définition de variables dans un modèle de tâche
Dans un modèle de tâche, ajoutez une `variables` carte à une `stepEnvironments` entrée `jobEnvironments` ou. Chaque entrée est une paire clé-valeur où la clé est le nom de la variable et la valeur est la valeur de la variable.
Le modèle de tâche suivant définit la variable d'`QT_QPA_PLATFORM`environnement sur`offscreen`, ce qui permet aux applications utilisant le [Qt Framework](https://www.qt.io/product/framework) de s'exécuter sur des hôtes de travail sans affichage interactif.
```
specificationVersion: 'jobtemplate-2023-09'
name: MyJob
jobEnvironments:
- name: JobEnv
variables:
QT_QPA_PLATFORM: offscreen
```
Vous pouvez définir plusieurs variables dans une seule définition d'environnement.
```
jobEnvironments:
- name: JobEnv
variables:
JOB_VERBOSITY: MEDIUM
JOB_PROJECT_ID: my-project-id
JOB_ENDPOINT_URL: https://my-host-name/my/path
QT_QPA_PLATFORM: offscreen
```
Vous pouvez référencer les paramètres de tâche dans des valeurs variables à l'aide de la `{{Param.ParameterName}}` syntaxe.
```
jobEnvironments:
- name: JobEnv
variables:
JOB_EXAMPLE_PARAM: "{{Param.ExampleParam}}"
```
Pour remplacer une variable de niveau tâche pour une étape spécifique, définissez une `stepEnvironments` entrée portant le même nom de variable. L'exemple suivant définit `JOB_PROJECT_ID` au niveau de la tâche avec la valeur`project-12`, puis remplace la valeur au niveau de l'étape par`step-project-12`. Les tâches de l'étape utilisent la valeur du niveau de l'étape.
```
specificationVersion: 'jobtemplate-2023-09'
name: MyJob
jobEnvironments:
- name: JobEnv
variables:
JOB_PROJECT_ID: project-12
steps:
- name: MyStep
stepEnvironments:
- name: StepEnv
variables:
JOB_PROJECT_ID: step-project-12
```
## Essayez-le : Exécution de l'exemple de variable d'environnement
Le référentiel d'exemples de Deadline Cloud inclut un ensemble de [tâches qui explique la définition et l'affichage des variables d'environnement](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_vars/template.yaml). L'exemple de modèle de tâche définit des variables au niveau de la tâche et de l'étape, puis exécute une tâche qui imprime le résultat fusionné. Utilisez la procédure suivante pour exécuter l'échantillon et inspecter les résultats.
### Conditions préalables
1. Si vous ne possédez pas de ferme Deadline Cloud avec une file d'attente et un parc Linux associé, suivez l'expérience d'intégration guidée dans la [console Deadline Cloud](https://console.aws.amazon.com/deadlinecloud/home) pour en créer une avec les paramètres par défaut.
1. Si vous ne disposez pas de la CLI Deadline Cloud et du moniteur AWS Deadline Cloud sur votre poste de travail, suivez les étapes décrites dans [Configurer les émetteurs Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html).
1. `git`À utiliser pour cloner le [ GitHubréférentiel d'échantillons de Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples).
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
cd deadline-cloud-samples/job_bundles
```
### Exécution de l'exemple
1. Utilisez la CLI de Deadline Cloud pour envoyer l'`job_env_vars`échantillon.
```
deadline bundle submit job_env_vars
```
1. Dans le moniteur Deadline Cloud, sélectionnez la nouvelle tâche pour suivre sa progression. Une fois qu'un travailleur est disponible dans le Linux parc associé à la file d'attente, la tâche se termine en quelques secondes. Sélectionnez la tâche, puis choisissez **Afficher les journaux** dans le menu supérieur droit du panneau des tâches.
### Comparaison des actions de session avec leurs définitions
La vue du journal montre trois actions de session. Ouvrez le fichier [job\$1env\$1vars/template.yaml](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_vars/template.yaml) dans un éditeur de texte pour comparer chaque action avec sa définition dans le modèle de tâche.
1. Sélectionnez l'action **Lancer** une JobEnv session. La sortie du journal indique les variables d'environnement définies au niveau du travail.
```
Setting: JOB_VERBOSITY=MEDIUM
Setting: JOB_EXAMPLE_PARAM=An example parameter value
Setting: JOB_PROJECT_ID=project-12
Setting: JOB_ENDPOINT_URL=https://internal-host-name/some/path
Setting: QT_QPA_PLATFORM=offscreen
```
Les lignes suivantes du modèle de tâche définissent cet environnement.
```
jobEnvironments:
- name: JobEnv
variables:
JOB_VERBOSITY: MEDIUM
JOB_EXAMPLE_PARAM: "{{Param.ExampleParam}}"
JOB_PROJECT_ID: project-12
JOB_ENDPOINT_URL: https://internal-host-name/some/path
QT_QPA_PLATFORM: offscreen
```
1. Sélectionnez l'action **Lancer** une StepEnv session. La sortie du journal indique les variables au niveau de l'étape, y compris les variables remplacées`JOB_PROJECT_ID`.
```
Setting: STEP_VERBOSITY=HIGH
Setting: JOB_PROJECT_ID=step-project-12
```
Les lignes suivantes du modèle de tâche définissent cet environnement.
```
stepEnvironments:
- name: StepEnv
variables:
STEP_VERBOSITY: HIGH
JOB_PROJECT_ID: step-project-12
```
1. Sélectionnez l'action **Task Run** session. La sortie du journal indique les variables d'environnement fusionnées disponibles pour la tâche. Notez que cela `JOB_PROJECT_ID` utilise la valeur `step-project-12` au niveau de l'étape.
```
Environment variables starting with JOB_*:
JOB_ENDPOINT_URL=https://internal-host-name/some/path
JOB_EXAMPLE_PARAM='An example parameter value'
JOB_PROJECT_ID=step-project-12
JOB_VERBOSITY=MEDIUM
Environment variables starting with STEP_*:
STEP_VERBOSITY=HIGH
```
# Définir le chemin dans un environnement de file d'attente
Utilisez les environnements OpenJD pour fournir de nouvelles commandes dans un environnement. Vous créez d'abord un répertoire contenant des fichiers de script, puis vous ajoutez ce répertoire aux variables d'`PATH`environnement afin que les exécutables de votre script puissent les exécuter sans avoir à spécifier le chemin du répertoire à chaque fois. La liste des variables d'une définition d'environnement ne permet pas de modifier la variable. Pour ce faire, exécutez plutôt un script. Une fois que le script a configuré les choses et les a modifiées`PATH`, il exporte la variable vers le runtime OpenJD avec la commande. `echo "openjd_env: PATH=$PATH"`
## Conditions préalables
Procédez comme suit pour exécuter l'[exemple de bundle de tâches avec des variables d'environnement](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_vars/template.yaml) provenant du référentiel github d'échantillons de Deadline Cloud.
1. Si vous ne possédez pas de ferme Deadline Cloud avec une file d'attente et un parc Linux associé, suivez l'expérience d'intégration guidée dans la [console Deadline Cloud](https://console.aws.amazon.com/deadlinecloud/home) pour en créer une avec les paramètres par défaut.
1. Si vous ne disposez pas de la CLI Deadline Cloud et du moniteur Deadline Cloud sur votre poste de travail, suivez les étapes décrites dans la [section Configurer les émetteurs Deadline Cloud dans le guide](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html) de l'utilisateur.
1. `git`À utiliser pour cloner le [ GitHubréférentiel d'échantillons de Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples).
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
Cloning into 'deadline-cloud-samples'...
...
cd deadline-cloud-samples/job_bundles
```
## Exécutez l'exemple de chemin
1. Utilisez la CLI de Deadline Cloud pour envoyer l'`job_env_with_new_command`échantillon.
```
$ deadline bundle submit job_env_with_new_command
Submitting to Queue: MySampleQueue
...
```
1. Dans le moniteur Deadline Cloud, vous verrez la nouvelle tâche et pourrez suivre sa progression. Une fois que le Linux parc associé à la file d'attente dispose d'un collaborateur disponible pour exécuter la tâche, celle-ci se termine en quelques secondes. Sélectionnez la tâche, puis choisissez l'option **Afficher les journaux** dans le menu supérieur droit du panneau des tâches.
Sur la droite se trouvent deux actions de session, **Lancer RandomSleepCommand** et **Exécuter une tâche**. L'afficheur de journal au centre de la fenêtre correspond à l'action de session sélectionnée sur la droite.
## Comparez les actions de session avec leurs définitions
Dans cette section, vous utilisez le moniteur Deadline Cloud pour comparer les actions de session avec celles définies dans le modèle de tâche. Il fait suite à la section précédente.
Ouvrez le fichier [job\$1env\$1with\$1new\$1command/template.yaml dans un éditeur de texte](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_with_new_command/template.yaml). Comparez les actions de session à l'endroit où elles sont définies dans le modèle de tâche.
1. Sélectionnez l'action **Lancer** une RandomSleepCommand session dans le moniteur Deadline Cloud. Vous verrez la sortie du journal comme suit.
```
2024/07/16 17:25:32-07:00
2024/07/16 17:25:32-07:00 ==============================================
2024/07/16 17:25:32-07:00 --------- Entering Environment: RandomSleepCommand
2024/07/16 17:25:32-07:00 ==============================================
2024/07/16 17:25:32-07:00 ----------------------------------------------
2024/07/16 17:25:32-07:00 Phase: Setup
2024/07/16 17:25:32-07:00 ----------------------------------------------
2024/07/16 17:25:32-07:00 Writing embedded files for Environment to disk.
2024/07/16 17:25:32-07:00 Mapping: Env.File.Enter -> /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/embedded_filesf3tq_1os/tmpbt8j_c3f
2024/07/16 17:25:32-07:00 Mapping: Env.File.SleepScript -> /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/embedded_filesf3tq_1os/tmperastlp4
2024/07/16 17:25:32-07:00 Wrote: Enter -> /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/embedded_filesf3tq_1os/tmpbt8j_c3f
2024/07/16 17:25:32-07:00 Wrote: SleepScript -> /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/embedded_filesf3tq_1os/tmperastlp4
2024/07/16 17:25:32-07:00 ----------------------------------------------
2024/07/16 17:25:32-07:00 Phase: Running action
2024/07/16 17:25:32-07:00 ----------------------------------------------
2024/07/16 17:25:32-07:00 Running command sudo -u job-user -i setsid -w /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/tmpbwrquq5u.sh
2024/07/16 17:25:32-07:00 Command started as pid: 2205
2024/07/16 17:25:32-07:00 Output:
2024/07/16 17:25:33-07:00 openjd_env: PATH=/sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/bin:/opt/conda/condabin:/home/job-user/.local/bin:/home/job-user/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin
No newer logs at this moment.
```
Les lignes suivantes du modèle de tâche spécifient cette action.
```
jobEnvironments:
- name: RandomSleepCommand
description: Adds a command 'random-sleep' to the environment.
script:
actions:
onEnter:
command: bash
args:
- "{{Env.File.Enter}}"
embeddedFiles:
- name: Enter
type: TEXT
data: |
#!/bin/env bash
set -euo pipefail
# Make a bin directory inside the session's working directory for providing new commands
mkdir -p '{{Session.WorkingDirectory}}/bin'
# If this bin directory is not already in the PATH, then add it
if ! [[ ":$PATH:" == *':{{Session.WorkingDirectory}}/bin:'* ]]; then
export "PATH={{Session.WorkingDirectory}}/bin:$PATH"
# This message to Open Job Description exports the new PATH value to the environment
echo "openjd_env: PATH=$PATH"
fi
# Copy the SleepScript embedded file into the bin directory
cp '{{Env.File.SleepScript}}' '{{Session.WorkingDirectory}}/bin/random-sleep'
chmod u+x '{{Session.WorkingDirectory}}/bin/random-sleep'
- name: SleepScript
type: TEXT
runnable: true
data: |
...
```
1. Sélectionnez l'action **Lancer** une StepEnv session dans le moniteur Deadline Cloud. La sortie du journal s'affiche comme suit.
```
2024/07/16 17:25:33-07:00
2024/07/16 17:25:33-07:00 ==============================================
2024/07/16 17:25:33-07:00 --------- Running Task
2024/07/16 17:25:33-07:00 ==============================================
2024/07/16 17:25:33-07:00 ----------------------------------------------
2024/07/16 17:25:33-07:00 Phase: Setup
2024/07/16 17:25:33-07:00 ----------------------------------------------
2024/07/16 17:25:33-07:00 Writing embedded files for Task to disk.
2024/07/16 17:25:33-07:00 Mapping: Task.File.Run -> /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/embedded_filesf3tq_1os/tmpdrwuehjf
2024/07/16 17:25:33-07:00 Wrote: Run -> /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/embedded_filesf3tq_1os/tmpdrwuehjf
2024/07/16 17:25:33-07:00 ----------------------------------------------
2024/07/16 17:25:33-07:00 Phase: Running action
2024/07/16 17:25:33-07:00 ----------------------------------------------
2024/07/16 17:25:33-07:00 Running command sudo -u job-user -i setsid -w /sessions/session-ab132a51b9b54d5da22cbe839dd946baaw1c8hk5/tmpz81iaqfw.sh
2024/07/16 17:25:33-07:00 Command started as pid: 2256
2024/07/16 17:25:33-07:00 Output:
2024/07/16 17:25:34-07:00 + random-sleep 12.5 27.5
2024/07/16 17:26:00-07:00 Sleeping for duration 26.90
2024/07/16 17:26:00-07:00 ----------------------------------------------
2024/07/16 17:26:00-07:00 Uploading output files to Job Attachments
2024/07/16 17:26:00-07:00 ----------------------------------------------
```
1. Les lignes suivantes du modèle de tâche spécifient cette action.
```
steps:
- name: EnvWithCommand
script:
actions:
onRun:
command: bash
args:
- '{{Task.File.Run}}'
embeddedFiles:
- name: Run
type: TEXT
data: |
set -xeuo pipefail
# Run the script installed into PATH by the job environment
random-sleep 12.5 27.5
hostRequirements:
attributes:
- name: attr.worker.os.family
anyOf:
- linux
```
# Exécuter un processus daemon en arrière-plan depuis l'environnement de file d'attente
Dans de nombreux cas d'utilisation du rendu, le chargement de l'application et des données de scène peut prendre beaucoup de temps. Si une tâche les recharge pour chaque image, elle consacrera le plus clair de son temps aux frais généraux. Il est souvent possible de charger l'application une seule fois en tant que processus démon en arrière-plan, de lui faire charger les données de scène, puis de lui envoyer des commandes via une communication inter-processus (IPC) pour effectuer les rendus.
La plupart des intégrations open source de Deadline Cloud utilisent ce modèle. Le projet Open Job Description fournit une [bibliothèque d'exécution d'adaptateurs](https://github.com/OpenJobDescription/openjd-adaptor-runtime-for-python) avec des modèles IPC robustes sur tous les systèmes d'exploitation pris en charge.
Pour illustrer ce modèle, il existe un [exemple de bundle de tâches autonome](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_daemon_process/template.yaml) qui utilise Python et du code bash pour implémenter un démon d'arrière-plan et l'IPC pour les tâches permettant de communiquer avec celui-ci. Le démon est implémenté en Python et écoute un SIGUSR1 signal POSIX indiquant quand traiter une tâche. Les détails de la tâche sont transmis au démon dans un fichier JSON spécifique, et les résultats de l'exécution de la tâche sont renvoyés sous la forme d'un autre fichier JSON.
## Conditions préalables
Procédez comme suit pour exécuter l'[exemple de bundle de tâches avec un processus démon à partir du référentiel](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_daemon_process/template.yaml) github d'échantillons de Deadline Cloud.
1. Si vous ne possédez pas de ferme Deadline Cloud avec une file d'attente et un parc Linux associé, suivez l'expérience d'intégration guidée dans la [console Deadline Cloud](https://console.aws.amazon.com/deadlinecloud/home) pour en créer une avec les paramètres par défaut.
1. Si vous ne disposez pas de la CLI Deadline Cloud et du moniteur Deadline Cloud sur votre poste de travail, suivez les étapes décrites dans la [section Configurer les émetteurs Deadline Cloud dans le guide](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html) de l'utilisateur.
1. `git`À utiliser pour cloner le [ GitHubréférentiel d'échantillons de Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples).
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
Cloning into 'deadline-cloud-samples'...
...
cd deadline-cloud-samples/job_bundles
```
## Exécutez l'exemple de daemon
1. Utilisez la CLI de Deadline Cloud pour envoyer l'`job_env_daemon_process`échantillon.
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
Cloning into 'deadline-cloud-samples'...
...
cd deadline-cloud-samples/job_bundles
```
1. Dans l'application de surveillance Deadline Cloud, vous verrez le nouveau travail et pourrez suivre sa progression. Une fois que le Linux parc associé à la file d'attente dispose d'un collaborateur disponible pour exécuter la tâche, celle-ci est terminée en une minute environ. Une fois l'une des tâches sélectionnée, choisissez l'option **Afficher les journaux** dans le menu supérieur droit du panneau des tâches.
Sur la droite, il y a deux actions de session, **Lancer DaemonProcess** et **Exécuter une tâche**. L'afficheur de journal au centre de la fenêtre correspond à l'action de session sélectionnée sur la droite.
Sélectionnez l'option **Afficher les journaux de toutes les tâches**. La chronologie montre le reste des tâches exécutées dans le cadre de la session, ainsi que l'`Shut down DaemonProcess`action qui a quitté l'environnement.
## Afficher les journaux des démons
1. Dans cette section, vous utilisez le moniteur Deadline Cloud pour comparer les actions de session avec celles définies dans le modèle de tâche. Il fait suite à la section précédente.
Ouvrez le fichier [job\$1env\$1daemon\$1process/template.yaml](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_daemon_process/template.yaml) dans un éditeur de texte. Comparez les actions de session à l'endroit où elles sont définies dans le modèle de tâche.
1. Sélectionnez l'action de `Launch DaemonProcess` session dans le moniteur Deadline Cloud. Vous verrez la sortie du journal comme suit.
```
2024/07/17 16:27:20-07:00
2024/07/17 16:27:20-07:00 ==============================================
2024/07/17 16:27:20-07:00 --------- Entering Environment: DaemonProcess
2024/07/17 16:27:20-07:00 ==============================================
2024/07/17 16:27:20-07:00 ----------------------------------------------
2024/07/17 16:27:20-07:00 Phase: Setup
2024/07/17 16:27:20-07:00 ----------------------------------------------
2024/07/17 16:27:20-07:00 Writing embedded files for Environment to disk.
2024/07/17 16:27:20-07:00 Mapping: Env.File.Enter -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/enter-daemon-process-env.sh
2024/07/17 16:27:20-07:00 Mapping: Env.File.Exit -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/exit-daemon-process-env.sh
2024/07/17 16:27:20-07:00 Mapping: Env.File.DaemonScript -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/daemon-script.py
2024/07/17 16:27:20-07:00 Mapping: Env.File.DaemonHelperFunctions -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/daemon-helper-functions.sh
2024/07/17 16:27:20-07:00 Wrote: Enter -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/enter-daemon-process-env.sh
2024/07/17 16:27:20-07:00 Wrote: Exit -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/exit-daemon-process-env.sh
2024/07/17 16:27:20-07:00 Wrote: DaemonScript -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/daemon-script.py
2024/07/17 16:27:20-07:00 Wrote: DaemonHelperFunctions -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/daemon-helper-functions.sh
2024/07/17 16:27:20-07:00 ----------------------------------------------
2024/07/17 16:27:20-07:00 Phase: Running action
2024/07/17 16:27:20-07:00 ----------------------------------------------
2024/07/17 16:27:20-07:00 Running command sudo -u job-user -i setsid -w /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/tmp_u8slys3.sh
2024/07/17 16:27:20-07:00 Command started as pid: 2187
2024/07/17 16:27:20-07:00 Output:
2024/07/17 16:27:21-07:00 openjd_env: DAEMON_LOG=/sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/daemon.log
2024/07/17 16:27:21-07:00 openjd_env: DAEMON_PID=2223
2024/07/17 16:27:21-07:00 openjd_env: DAEMON_BASH_HELPER_SCRIPT=/sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/daemon-helper-functions.sh
```
Les lignes suivantes du modèle de tâche spécifient cette action.
```
stepEnvironments:
- name: DaemonProcess
description: Runs a daemon process for the step's tasks to share.
script:
actions:
onEnter:
command: bash
args:
- "{{Env.File.Enter}}"
onExit:
command: bash
args:
- "{{Env.File.Exit}}"
embeddedFiles:
- name: Enter
filename: enter-daemon-process-env.sh
type: TEXT
data: |
#!/bin/env bash
set -euo pipefail
DAEMON_LOG='{{Session.WorkingDirectory}}/daemon.log'
echo "openjd_env: DAEMON_LOG=$DAEMON_LOG"
nohup python {{Env.File.DaemonScript}} > $DAEMON_LOG 2>&1 &
echo "openjd_env: DAEMON_PID=$!"
echo "openjd_env: DAEMON_BASH_HELPER_SCRIPT={{Env.File.DaemonHelperFunctions}}"
echo 0 > 'daemon_log_cursor.txt'
...
```
1. Sélectionnez l'une des actions de session Task run : N dans le moniteur Deadline Cloud. Vous verrez la sortie du journal comme suit.
```
2024/07/17 16:27:22-07:00
2024/07/17 16:27:22-07:00 ==============================================
2024/07/17 16:27:22-07:00 --------- Running Task
2024/07/17 16:27:22-07:00 ==============================================
2024/07/17 16:27:22-07:00 Parameter values:
2024/07/17 16:27:22-07:00 Frame(INT) = 2
2024/07/17 16:27:22-07:00 ----------------------------------------------
2024/07/17 16:27:22-07:00 Phase: Setup
2024/07/17 16:27:22-07:00 ----------------------------------------------
2024/07/17 16:27:22-07:00 Writing embedded files for Task to disk.
2024/07/17 16:27:22-07:00 Mapping: Task.File.Run -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/run-task.sh
2024/07/17 16:27:22-07:00 Wrote: Run -> /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/embedded_fileswy00x5ra/run-task.sh
2024/07/17 16:27:22-07:00 ----------------------------------------------
2024/07/17 16:27:22-07:00 Phase: Running action
2024/07/17 16:27:22-07:00 ----------------------------------------------
2024/07/17 16:27:22-07:00 Running command sudo -u job-user -i setsid -w /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/tmpv4obfkhn.sh
2024/07/17 16:27:22-07:00 Command started as pid: 2301
2024/07/17 16:27:22-07:00 Output:
2024/07/17 16:27:23-07:00 Daemon PID is 2223
2024/07/17 16:27:23-07:00 Daemon log file is /sessions/session-972e21d98dde45e59c7153bd9258a64dohwg4yg1/daemon.log
2024/07/17 16:27:23-07:00
2024/07/17 16:27:23-07:00 === Previous output from daemon
2024/07/17 16:27:23-07:00 ===
2024/07/17 16:27:23-07:00
2024/07/17 16:27:23-07:00 Sending command to daemon
2024/07/17 16:27:23-07:00 Received task result:
2024/07/17 16:27:23-07:00 {
2024/07/17 16:27:23-07:00 "result": "SUCCESS",
2024/07/17 16:27:23-07:00 "processedTaskCount": 1,
2024/07/17 16:27:23-07:00 "randomValue": 0.2578537967668988,
2024/07/17 16:27:23-07:00 "failureRate": 0.1
2024/07/17 16:27:23-07:00 }
2024/07/17 16:27:23-07:00
2024/07/17 16:27:23-07:00 === Daemon log from running the task
2024/07/17 16:27:23-07:00 Loading the task details file
2024/07/17 16:27:23-07:00 Received task details:
2024/07/17 16:27:23-07:00 {
2024/07/17 16:27:23-07:00 "pid": 2329,
2024/07/17 16:27:23-07:00 "frame": 2
2024/07/17 16:27:23-07:00 }
2024/07/17 16:27:23-07:00 Processing frame number 2
2024/07/17 16:27:23-07:00 Writing result
2024/07/17 16:27:23-07:00 Waiting until a USR1 signal is sent...
2024/07/17 16:27:23-07:00 ===
2024/07/17 16:27:23-07:00
2024/07/17 16:27:23-07:00 ----------------------------------------------
2024/07/17 16:27:23-07:00 Uploading output files to Job Attachments
2024/07/17 16:27:23-07:00 ----------------------------------------------
```
Les lignes suivantes du modèle de tâche spécifient cette action. Étapes :
```
steps:
- name: EnvWithDaemonProcess
parameterSpace:
taskParameterDefinitions:
- name: Frame
type: INT
range: "{{Param.Frames}}"
stepEnvironments:
...
script:
actions:
onRun:
timeout: 60
command: bash
args:
- '{{Task.File.Run}}'
embeddedFiles:
- name: Run
filename: run-task.sh
type: TEXT
data: |
# This bash script sends a task to the background daemon process,
# then waits for it to respond with the output result.
set -euo pipefail
source "$DAEMON_BASH_HELPER_SCRIPT"
echo "Daemon PID is $DAEMON_PID"
echo "Daemon log file is $DAEMON_LOG"
print_daemon_log "Previous output from daemon"
send_task_to_daemon "{\"pid\": $$, \"frame\": {{Task.Param.Frame}} }"
wait_for_daemon_task_result
echo Received task result:
echo "$TASK_RESULT" | jq .
print_daemon_log "Daemon log from running the task"
hostRequirements:
attributes:
- name: attr.worker.os.family
anyOf:
- linux
```
# Soumettez des candidatures pour vos emplois
Vous pouvez utiliser un environnement de file d'attente pour charger des applications afin de traiter vos tâches. Lorsque vous créez un parc géré par des services à l'aide de la console Deadline Cloud, vous avez la possibilité de créer un environnement de file d'attente qui utilise le gestionnaire de packages Conda pour charger les applications.
Si vous souhaitez utiliser un autre gestionnaire de packages, vous pouvez créer un environnement de file d'attente pour ce gestionnaire. Pour un exemple d'utilisation de Rez, voir[Utiliser un autre gestionnaire de packages](#provide-applications-other-package).
Deadline Cloud fournit un canal conda pour charger une sélection d'applications de rendu dans votre environnement. Ils prennent en charge les soumetteurs fournis par Deadline Cloud pour les applications de création de contenu numérique.
Vous pouvez également charger un logiciel pour conda-forge à utiliser dans le cadre de vos travaux. Les exemples suivants montrent des modèles de tâches utilisant l'environnement de file d'attente fourni par Deadline Cloud pour charger des applications avant d'exécuter la tâche.
**Topics**
+ [Obtenir une application depuis un canal Conda](#provide-applications-get-application)
+ [Utiliser un autre gestionnaire de packages](#provide-applications-other-package)
## Obtenir une application depuis un canal Conda
Vous pouvez créer un environnement de file d'attente personnalisé pour vos employés de Deadline Cloud, qui installe le logiciel de votre choix. Cet exemple d'environnement de file d'attente présente le même comportement que l'environnement utilisé par la console pour les flottes gérées par des services. Il exécute directement conda pour créer l'environnement.
L'environnement crée un nouvel environnement virtuel Conda pour chaque session Deadline Cloud exécutée sur un travailleur, puis supprime l'environnement une fois l'opération terminée.
Conda met en cache les packages téléchargés afin qu'ils n'aient pas besoin d'être téléchargés à nouveau, mais chaque session doit lier tous les packages à l'environnement.
L'environnement définit trois scripts qui s'exécutent lorsque Deadline Cloud démarre une session sur un worker. Le premier script s'exécute lorsque l'`onEnter`action est appelée. Il appelle les deux autres pour configurer les variables d'environnement. Une fois l'exécution du script terminée, l'environnement conda est disponible avec toutes les variables d'environnement spécifiées définies.
Pour la dernière version de l'exemple, consultez [conda\$1queue\$1env\$1console\$1equivalent.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/conda_queue_env_console_equivalent.yaml) dans le référentiel sur. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub
Si vous souhaitez utiliser une application qui n'est pas disponible dans le canal conda, vous pouvez créer un canal conda dans Amazon S3, puis créer vos propres packages pour cette application. Pour en savoir plus, consultez [Création d'un canal conda à l'aide de S3](configure-jobs-s3-channel.md).
### Obtenez des bibliothèques open source auprès de conda-forge
Cette section décrit comment utiliser les bibliothèques open source de la `conda-forge` chaîne. L'exemple suivant est un modèle de tâche qui utilise le package `polars` Python.
La tâche définit les `CondaChannels` paramètres `CondaPackages` et définis dans l'environnement de file d'attente qui indiquent à Deadline Cloud où se procurer le package.
La section du modèle de tâche qui définit les paramètres est la suivante :
```
- name: CondaPackages
description: A list of conda packages to install. The job expects a Queue Environment to handle this.
type: STRING
default: polars
- name: CondaChannels
description: A list of conda channels to get packages from. The job expects a Queue Environment to handle this.
type: STRING
default: conda-forge
```
Pour obtenir la dernière version de l'exemple complet de modèle de tâche, consultez [stage\$11\$1self\$1contained\$1template/template.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/job_bundles/job_dev_progression/stage_1_self_contained_template/template.yaml). Pour la dernière version de l'environnement de file d'attente qui charge les packages conda, consultez [conda\$1queue\$1env\$1console\$1equivalent.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/conda_queue_env_console_equivalent.yaml) dans le référentiel sur. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub
### Accédez Blender à la chaîne Deadline-Cloud
L'exemple suivant montre un modèle de tâche Blender issu du canal `deadline-cloud` conda. Ce canal prend en charge les émetteurs fournis par Deadline Cloud pour les logiciels de création de contenu numérique, mais vous pouvez utiliser le même canal pour charger le logiciel pour votre propre usage.
Pour obtenir la liste des logiciels fournis par le `deadline-cloud` canal, consultez la section [Environnement de file d'attente par défaut](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html#conda-queue-environment) dans le *guide de l'utilisateur de AWS Deadline Cloud*.
Cette tâche définit le `CondaPackages` paramètre défini dans l'environnement de file d'attente pour indiquer à Deadline Cloud de le charger Blender dans l'environnement.
La section du modèle de tâche qui définit le paramètre est la suivante :
```
- name: CondaPackages
type: STRING
userInterface:
control: LINE_EDIT
label: Conda Packages
groupLabel: Software Environment
default: blender
description: >
Tells the queue environment to install Blender from the deadline-cloud conda channel.
```
Pour obtenir la dernière version de l'exemple complet de modèle de tâche, consultez [blender\$1render/template.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/job_bundles/blender_render/template.yaml). Pour la dernière version de l'environnement de file d'attente qui charge les packages conda, consultez [conda\$1queue\$1env\$1console\$1equivalent.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/conda_queue_env_console_equivalent.yaml) dans le référentiel sur. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline)GitHub
## Utiliser un autre gestionnaire de packages
Le gestionnaire de packages par défaut pour Deadline Cloud est conda. Si vous devez utiliser un autre gestionnaire de packages, par exempleRez, vous pouvez créer un environnement de file d'attente personnalisé contenant des scripts utilisant votre gestionnaire de packages à la place.
Cet exemple d'environnement de file d'attente présente le même comportement que l'environnement utilisé par la console pour les flottes gérées par des services. Il remplace le gestionnaire de packages conda parRez.
L'environnement définit trois scripts qui s'exécutent lorsque Deadline Cloud démarre une session sur un worker. Le premier script s'exécute lorsque l'`onEnter`action est appelée. Il appelle les deux autres pour configurer les variables d'environnement. Une fois l'exécution du script terminée, l'Rezenvironnement est disponible avec toutes les variables d'environnement spécifiées définies.
L'exemple suppose que vous avez une flotte gérée par le client qui utilise un système de fichiers partagé pour les packages Rez.
Pour la dernière version de l'exemple, consultez [rez\$1queue\$1env.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/rez_queue_env.yaml) dans le référentiel sur. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline)GitHub