

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Configurazione dei lavori utilizzando ambienti di coda
<a name="configure-jobs"></a>

AWS Deadline Cloud utilizza *ambienti di coda* per configurare il software sui dipendenti. Un ambiente consente di eseguire attività che richiedono molto tempo, come la configurazione e lo smontaggio, una volta per tutte le attività di una sessione. Definisce le azioni da eseguire su un lavoratore all'avvio o all'interruzione di una sessione. È possibile configurare un ambiente per una coda, i lavori che vengono eseguiti in coda e i singoli passaggi per un lavoro.

Gli ambienti vengono definiti come ambienti di coda o ambienti di lavoro. Crea ambienti di coda con la console Deadline Cloud o con [Deadline: CreateQueueEnvironment](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueEnvironment.html) gestisci e definisci gli ambienti di lavoro nei modelli di lavoro dei lavori che invii. Seguono la specifica Open Job Description (OpenJD) per gli ambienti. Per i dettagli, vedere le specifiche[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) <Environment>di OpenJD su. GitHub

Oltre a una `name` e`description`, ogni ambiente contiene due campi che definiscono l'ambiente sull'host. Questi sono:
+ `script`— L'azione intrapresa quando questo ambiente viene eseguito su un lavoratore.
+ `variables`— Un insieme di name/value coppie di variabili d'ambiente che vengono impostate quando si entra nell'ambiente.

È necessario impostare almeno una delle `script` o`variables`.

È possibile definire più di un ambiente nel modello di lavoro. Ogni ambiente viene applicato nell'ordine in cui è elencato nel modello. È possibile utilizzarlo per gestire la complessità degli ambienti.

L'ambiente di coda predefinito per Deadline Cloud utilizza il gestore di pacchetti conda per caricare il software nell'ambiente, ma puoi usare altri gestori di pacchetti. L'ambiente predefinito definisce due parametri per specificare il software da caricare. Queste variabili sono impostate dai mittenti forniti da Deadline Cloud, sebbene sia possibile impostarle nei propri script e applicazioni che utilizzano l'ambiente predefinito. Questi sono:
+ `CondaPackages`— Un elenco separato da spazi di pacchetti conda che corrispondono alle specifiche da installare per il lavoro. Ad esempio, il mittente di Blender `blender=3.6` aggiungerebbe fotogrammi di rendering in Blender 3.6.
+ `CondaChannels`— Un elenco separato da spazi di canali conda da cui installare i pacchetti. Per le flotte gestite dai servizi, i pacchetti vengono installati dal canale. `deadline-cloud` Puoi aggiungere altri canali.

# Controlla l'ambiente di lavoro con gli ambienti di coda OpenJD
<a name="control-the-job-environment"></a>

È possibile definire ambienti personalizzati per i lavori di rendering utilizzando *ambienti di coda.* Un ambiente di coda è un modello che controlla le variabili di ambiente, le mappature dei file e altre impostazioni per i lavori in esecuzione in una coda specifica. Consente di personalizzare l'ambiente di esecuzione per i lavori inviati a una coda in base ai requisiti dei carichi di lavoro. AWS Deadline Cloud offre tre livelli annidati in cui è possibile applicare [ambienti Open Job Description (OpenJD): queue, job](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) e step. Definendo gli ambienti di coda, è possibile garantire prestazioni coerenti e ottimizzate per diversi tipi di lavori, ottimizzare l'allocazione delle risorse e semplificare la gestione delle code.

L'ambiente di coda è un modello che si collega a una coda del AWS proprio account dalla console di gestione o utilizzando il AWS . AWS CLIÈ possibile creare un ambiente per una coda oppure creare più ambienti di coda applicati per creare l'ambiente di esecuzione. Questo approccio consente di creare e testare un ambiente in fasi per garantire che funzioni correttamente per i propri job.

Gli ambienti Job e Step sono definiti nel modello di job utilizzato per creare un job nella coda. La sintassi di OpenJD è la stessa in queste diverse forme di ambienti. In questa sezione li mostreremo all'interno dei modelli di lavoro. 

**Topics**
+ [Imposta le variabili di ambiente in un ambiente di coda](set-environment-variables.md)
+ [Imposta il percorso in un ambiente di coda](set-the-path.md)
+ [Esegui un processo demone in background dall'ambiente di coda](run-a-background-daemon-process.md)

# Imposta le variabili di ambiente in un ambiente di coda
<a name="set-environment-variables"></a>

Molte applicazioni e framework utilizzano variabili di ambiente per controllare le impostazioni delle funzionalità, i livelli di registrazione e la configurazione dello schermo. È possibile utilizzare [gli ambienti Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) per impostare le variabili di ambiente che ogni comando di task all'interno del relativo ambito eredita.

## Ambito della variabile di ambiente
<a name="set-env-vars-scope"></a>

AWS Deadline Cloud applica le variabili di ambiente dagli ambienti di coda collegati a una coda. [All'interno di un modello di lavoro, puoi anche definire le variabili di ambiente a livello di processo e fase utilizzando gli ambienti OpenJD.](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#4-environment) Le variabili definite in un ambito più ristretto sostituiscono le variabili con lo stesso nome in un ambito più ampio.
+ **Ambiente di coda**: un modello da allegare a una coda in Deadline Cloud. Le variabili si applicano a tutti i lavori inviati alla coda. È possibile impostare variabili con una `variables` mappa per valori fissi o utilizzare script per valori dinamici.
+ **Ambiente di lavoro**: definito `jobEnvironments` in un modello di lavoro. Le variabili si applicano a tutte le fasi e le attività del lavoro. Una variabile a livello di processo sostituisce una variabile a livello di coda con lo stesso nome.
+ **Ambiente a fasi: definito in un modello** di lavoro. `stepEnvironments` Le variabili si applicano solo alle attività di quella fase. Una variabile a livello di fase sostituisce una variabile a livello di processo o di coda con lo stesso nome.

## Impostazione delle variabili in un ambiente di coda
<a name="set-env-vars-queue-env"></a>

È possibile impostare le variabili di ambiente in un ambiente di coda utilizzando una `variables` mappa per valori fissi o utilizzando un'`script``onEnter`azione per valori dinamici.

Il seguente modello di ambiente di coda utilizza una `variables` mappa su cui impostare la `QT_QPA_PLATFORM` variabile`offscreen`, che consente alle applicazioni che utilizzano [Qt Framework](https://www.qt.io/product/framework) di funzionare su host di lavoro senza un display interattivo.

```
specificationVersion: 'environment-2023-09'
environment:
  name: QtOffscreen
  variables:
    QT_QPA_PLATFORM: offscreen
```

Per valori dinamici, come la modifica `PATH` o l'attivazione di ambienti virtuali, usa uno script che stampa le righe nel formato `openjd_env: VAR=value` su stdout. Il `openjd_env:` prefisso è obbligatorio. L'utilizzo di `echo``export`, o altri meccanismi di shell senza il prefisso non propaga le variabili ai job e alle attività.

Il seguente modello di ambiente di coda imposta la `QT_QPA_PLATFORM` variabile utilizzando uno 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"
```

Per collegare un ambiente di coda alla tua coda, usa la console Deadline Cloud o il. AWS CLI Per ulteriori informazioni, consulta [Creare un ambiente di coda](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html) nella Guida per l'utente di AWS Deadline Cloud. Il AWS CLI comando seguente crea un ambiente di coda da un file modello.

```
aws deadline create-queue-environment \
    --farm-id FARM_ID \
    --queue-id QUEUE_ID \
    --priority 1 \
    --template-type YAML \
    --template file://my-queue-env.yaml
```

Per esempi più complessi, come la creazione e l'attivazione di ambienti virtuali conda, consulta gli esempi di ambiente di [coda di Deadline Cloud su](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/queue_environments). GitHub

## Impostazione delle variabili in un modello di lavoro
<a name="set-env-vars-job-template"></a>

In un modello di lavoro, aggiungi una `variables` mappa a una `stepEnvironments` voce `jobEnvironments` or. Ogni voce è una coppia chiave-valore in cui la chiave è il nome della variabile e il valore è il valore della variabile.

Il seguente modello di lavoro imposta la variabile di `QT_QPA_PLATFORM` ambiente su`offscreen`, che consente alle applicazioni che utilizzano [Qt Framework](https://www.qt.io/product/framework) di funzionare su host di lavoro senza un display interattivo.

```
specificationVersion: 'jobtemplate-2023-09'
name: MyJob
jobEnvironments:
- name: JobEnv
  variables:
    QT_QPA_PLATFORM: offscreen
```

È possibile impostare più variabili in un'unica definizione di ambiente.

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

È possibile fare riferimento ai parametri del lavoro in valori variabili utilizzando la `{{Param.ParameterName}}` sintassi.

```
jobEnvironments:
- name: JobEnv
  variables:
    JOB_EXAMPLE_PARAM: "{{Param.ExampleParam}}"
```

Per sovrascrivere una variabile a livello di job per un passaggio specifico, definite una `stepEnvironments` voce con lo stesso nome di variabile. L'esempio seguente definisce `JOB_PROJECT_ID` a livello di processo il valore`project-12`, quindi sostituisce il valore a livello di fase con. `step-project-12` Le attività della fase utilizzano il valore a livello di fase.

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

## Prova: esegui l'esempio della variabile di ambiente
<a name="set-env-vars-example"></a>

L'archivio di esempi di Deadline Cloud include un [job bundle che dimostra l'impostazione e](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_vars/template.yaml) la visualizzazione delle variabili di ambiente. Il modello di lavoro di esempio definisce le variabili sia a livello di processo che a livello di fase, quindi esegue un'attività che stampa il risultato unito. Utilizzare la procedura seguente per eseguire il campione e controllare i risultati.

### Prerequisiti
<a name="set-prerequisites"></a>

1. Se non disponi di una farm Deadline Cloud con una coda e una flotta Linux associata, segui l'esperienza di onboarding guidata nella [console Deadline Cloud](https://console.aws.amazon.com/deadlinecloud/home) per crearne una con le impostazioni predefinite.

1. Se non disponi della CLI di Deadline Cloud AWS e del monitor Deadline Cloud sulla tua workstation, segui i passaggi [in Configurare](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html) i mittenti di Deadline Cloud.

1. [Utilizzalo per clonare l'archivio di esempi `git` di Deadline Cloud. GitHub](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
   ```

### Esecuzione dell'esempio
<a name="set-run-example"></a>

1. Utilizza la CLI di Deadline Cloud per inviare `job_env_vars` il campione.

   ```
   deadline bundle submit job_env_vars
   ```

1. Nel monitor Deadline Cloud, seleziona il nuovo lavoro per monitorarne l'avanzamento. Dopo che la Linux flotta associata alla coda ha un lavoratore disponibile, il lavoro viene completato in pochi secondi. Seleziona l'attività, quindi scegli **Visualizza registri** nel menu in alto a destra del pannello delle attività.

### Confronto delle azioni della sessione con le relative definizioni
<a name="set-compare-actions"></a>

La visualizzazione del registro mostra tre azioni di sessione. Apri il file [job\$1env\$1vars/template.yaml in un editor di testo per confrontare ogni azione con la sua definizione](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_vars/template.yaml) nel modello di lavoro.

1. ** JobEnvSeleziona** l'azione Avvia sessione. L'output del registro mostra le variabili di ambiente a livello di job che vengono impostate.

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

   Le righe seguenti del modello di lavoro definiscono questo ambiente.

   ```
   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. Seleziona l'azione **Avvia StepEnv** sessione. L'output del registro mostra le variabili a livello di fase, incluse quelle sostituite. `JOB_PROJECT_ID`

   ```
   Setting: STEP_VERBOSITY=HIGH
   Setting: JOB_PROJECT_ID=step-project-12
   ```

   Le righe seguenti del modello di lavoro definiscono questo ambiente.

   ```
   stepEnvironments:
   - name: StepEnv
     variables:
       STEP_VERBOSITY: HIGH
       JOB_PROJECT_ID: step-project-12
   ```

1. Seleziona l'azione **Task run** session. L'output del registro mostra le variabili di ambiente unite disponibili per l'attività. Si noti che `JOB_PROJECT_ID` utilizza il valore a livello di fase. `step-project-12`

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

# Imposta il percorso in un ambiente di coda
<a name="set-the-path"></a>

Usa gli ambienti OpenJD per fornire nuovi comandi in un ambiente. Per prima cosa create una directory contenente i file di script, quindi aggiungete quella directory alle variabili di `PATH` ambiente in modo che gli eseguibili dello script possano eseguirli senza dover specificare ogni volta il percorso della directory. L'elenco delle variabili in una definizione di ambiente non fornisce un modo per modificare la variabile, quindi è possibile farlo eseguendo invece uno script. Dopo che lo script ha impostato le cose e modificato la`PATH`, esporta la variabile nel runtime di OpenJD con il comando. `echo "openjd_env: PATH=$PATH"` 

## Prerequisiti
<a name="set-prerequisites"></a>

 Esegui i passaggi seguenti per eseguire il [pacchetto di job di esempio con le variabili di ambiente](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_vars/template.yaml) dal repository github degli esempi di Deadline Cloud. 

1.  Se non disponi di una Deadline Cloud farm con una coda e una flotta Linux associata, segui l'esperienza di onboarding guidata nella console [Deadline](https://console.aws.amazon.com/deadlinecloud/home) Cloud per crearne una con le impostazioni predefinite. 

1.  Se non disponi della CLI di Deadline Cloud e del monitor Deadline Cloud sulla tua workstation, segui i passaggi [in Configurare i mittenti di Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html) dalla guida per l'utente. 

1.  [Utilizzalo per clonare l'archivio di esempi `git` di Deadline Cloud. GitHub](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
   ```

## Esegui l'esempio di percorso
<a name="path-run-sample"></a>

1.  Utilizza la CLI di Deadline Cloud per inviare `job_env_with_new_command` il campione.

   ```
    $ deadline bundle submit job_env_with_new_command
    Submitting to Queue: MySampleQueue
    ...
   ```

1.  Nel monitor Deadline Cloud, vedrai il nuovo lavoro e potrai monitorarne l'avanzamento. Una volta che la Linux flotta associata alla coda ha un lavoratore disponibile per eseguire l'attività del lavoro, il lavoro viene completato in pochi secondi. Seleziona l'attività, quindi scegli l'opzione **Visualizza registri** nel menu in alto a destra del pannello delle attività. 

    Sulla destra ci sono due azioni di sessione, **Launch RandomSleepCommand** e **Task run**. Il visualizzatore di log al centro della finestra corrisponde all'azione della sessione selezionata sulla destra. 

## Confronta le azioni della sessione con le relative definizioni
<a name="path-view-logs"></a>

In questa sezione si utilizza il monitor Deadline Cloud per confrontare le azioni della sessione con il punto in cui sono definite nel modello di lavoro. Continua dalla sezione precedente. 

Apri il file [job\$1env\$1with\$1new\$1command/template.yaml in un editor](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_with_new_command/template.yaml) di testo. Confrontate le azioni della sessione con quelle definite nel modello di lavoro. 

1.  Seleziona l'azione **Avvia RandomSleepCommand** sessione nel monitor Deadline Cloud. Vedrai l'output del registro come segue.

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

    Le seguenti righe del modello di lavoro hanno specificato questa azione.

   ```
    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.  Seleziona l'azione **Avvia StepEnv** sessione nel monitor Deadline Cloud. L'output del log viene visualizzato come segue. 

   ```
    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.  Questa azione è stata specificata nelle righe seguenti del modello di lavoro.

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

# Esegui un processo demone in background dall'ambiente di coda
<a name="run-a-background-daemon-process"></a>

 In molti casi d'uso del rendering, il caricamento dei dati dell'applicazione e della scena può richiedere molto tempo. Se un job li ricarica per ogni frame, impiegherà la maggior parte del tempo a sovraccaricare. Spesso è possibile caricare l'applicazione una sola volta come processo demone in background, fare in modo che carichi i dati della scena e quindi inviarle i comandi tramite la comunicazione tra processi (IPC) per eseguire i rendering. 

 Molte delle integrazioni open source di Deadline Cloud utilizzano questo modello. Il progetto Open Job Description fornisce una [libreria di runtime di adattatori](https://github.com/OpenJobDescription/openjd-adaptor-runtime-for-python) con modelli IPC robusti su tutti i sistemi operativi supportati. 

 Per dimostrare questo modello, esiste un [pacchetto di job di esempio autonomo](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_daemon_process/template.yaml) che utilizza Python e codice bash per implementare un demone in background e l'IPC per le attività per comunicare con esso. Il demone è implementato in Python e ascolta un SIGUSR1 segnale POSIX per sapere quando elaborare un'attività. I dettagli dell'attività vengono passati al demone in un file JSON specifico e i risultati dell'esecuzione dell'operazione vengono restituiti come un altro file JSON. 

## Prerequisiti
<a name="daemon-prerequisites"></a>

 Esegui i passaggi seguenti per eseguire il [pacchetto di job di esempio con un processo daemon](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_daemon_process/template.yaml) dal repository github degli esempi di Deadline Cloud. 

1.  [Se non disponi di una farm Deadline Cloud con una coda e una flotta Linux associata, segui l'esperienza di onboarding guidata nella console Deadline Cloud per crearne una con le impostazioni predefinite.](https://console.aws.amazon.com/deadlinecloud/home) 

1.  Se non disponi della CLI di Deadline Cloud e del monitor Deadline Cloud sulla tua workstation, segui i passaggi [in Configurare i mittenti di Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submitter.html) dalla guida per l'utente. 

1.  [Utilizzalo per clonare l'archivio di esempi `git` di Deadline Cloud. GitHub](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
   ```

## Esegui l'esempio del demone
<a name="daemon-run-sample"></a>

1.  Utilizza la CLI di Deadline Cloud per inviare `job_env_daemon_process` il campione.

   ```
    git clone https://github.com/aws-deadline/deadline-cloud-samples.git
   Cloning into 'deadline-cloud-samples'...
    ...
   cd deadline-cloud-samples/job_bundles
   ```

1.  Nell'applicazione di monitoraggio Deadline Cloud, vedrai il nuovo lavoro e potrai monitorarne l'avanzamento. Una volta che il Linux parco macchine associato alla coda ha un lavoratore disponibile per eseguire l'operazione, questa viene completata in circa un minuto. Con una delle attività selezionate, scegli l'opzione **Visualizza registri** nel menu in alto a destra del pannello delle attività. 

    Sulla destra ci sono due azioni di sessione, **Launch DaemonProcess** e **Task run**. Il visualizzatore di log al centro della finestra corrisponde all'azione della sessione selezionata sulla destra. 

    Seleziona l'opzione **Visualizza i registri per tutte le attività**. La sequenza temporale mostra il resto delle attività eseguite come parte della sessione e l'`Shut down DaemonProcess`azione uscita dall'ambiente. 

## Visualizza i registri dei demoni
<a name="daemon-view-logs"></a>

1. In questa sezione si utilizza il monitor Deadline Cloud per confrontare le azioni della sessione con il punto in cui sono definite nel modello di lavoro. Continua dalla sezione precedente. 

    Apri il file [job\$1env\$1daemon\$1process/template.yaml in un editor](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/job_env_daemon_process/template.yaml) di testo. Confrontate le azioni della sessione con quelle definite nel modello di lavoro. 

1.  Seleziona l'azione della `Launch DaemonProcess` sessione nel monitor di Deadline Cloud. Vedrai l'output del registro come segue.

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

    Le seguenti righe del modello di lavoro hanno specificato questa azione.

   ```
      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.  Seleziona una delle azioni Task run: N session nel monitor Deadline Cloud. Vedrai l'output del registro come segue.

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

    Le seguenti righe del modello di lavoro sono ciò che specifica questa azione. ```passi: 

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

# Fornisci candidature per i tuoi lavori
<a name="provide-applications"></a>

È possibile utilizzare un ambiente di coda per caricare le applicazioni per elaborare i lavori. Quando crei una flotta gestita dai servizi utilizzando la console Deadline Cloud, hai la possibilità di creare un ambiente di coda che utilizza il gestore di pacchetti conda per caricare le applicazioni. 

Se desideri utilizzare un gestore di pacchetti diverso, puoi creare un ambiente di coda per quel gestore. Per un esempio di utilizzo di Rez, vedi[Usa un gestore di pacchetti diverso](#provide-applications-other-package).

Deadline Cloud fornisce un canale conda per caricare una selezione di applicazioni di rendering nel tuo ambiente. Supportano i mittenti che Deadline Cloud fornisce per le applicazioni di creazione di contenuti digitali. 

Puoi anche caricare software per conda-forge da utilizzare nei tuoi lavori. Gli esempi seguenti mostrano modelli di lavoro che utilizzano l'ambiente di coda fornito da Deadline Cloud per caricare le applicazioni prima di eseguire il lavoro.

**Topics**
+ [Ottenere un'applicazione da un canale conda](#provide-applications-get-application)
+ [Usa un gestore di pacchetti diverso](#provide-applications-other-package)

## Ottenere un'applicazione da un canale conda
<a name="provide-applications-get-application"></a>

Puoi creare un ambiente di coda personalizzato per i tuoi lavoratori di Deadline Cloud che installino il software che preferisci. Questo esempio di ambiente di coda ha lo stesso comportamento dell'ambiente utilizzato dalla console per le flotte gestite dai servizi. Esegue direttamente conda per creare l'ambiente.

L'ambiente crea un nuovo ambiente virtuale conda per ogni sessione di Deadline Cloud eseguita su un lavoratore, quindi elimina l'ambiente al termine. 

Conda memorizza nella cache i pacchetti scaricati in modo che non debbano essere scaricati nuovamente, ma ogni sessione deve collegare tutti i pacchetti all'ambiente.

L'ambiente definisce tre script che vengono eseguiti quando Deadline Cloud avvia una sessione su un lavoratore. Il primo script viene eseguito quando viene chiamata l'`onEnter`azione. Chiama gli altri due per impostare le variabili di ambiente. Al termine dell'esecuzione dello script, l'ambiente conda è disponibile con tutte le variabili di ambiente specificate impostate.

Per la versione più recente dell'esempio, vedete [conda\$1queue\$1env\$1console\$1equivalent.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/conda_queue_env_console_equivalent.yaml) nel repository on. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub

Se desideri utilizzare un'applicazione che non è disponibile nel canale conda, puoi creare un canale conda in Amazon S3 e quindi creare i tuoi pacchetti per quell'applicazione. Per ulteriori informazioni, consulta [Crea un canale conda usando S3](configure-jobs-s3-channel.md).

### Ottieni librerie open source da conda-forge
<a name="get-application-csv-example"></a>

Questa sezione descrive come utilizzare le librerie open source del canale. `conda-forge` L'esempio seguente è un modello di lavoro che utilizza il pacchetto `polars` Python.

Il job imposta i `CondaChannels` parametri `CondaPackages` and definiti nell'ambiente di coda che indicano a Deadline Cloud dove trovare il pacchetto.

La sezione del modello di lavoro che imposta i parametri è:

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

Per la versione più recente del modello di lavoro di esempio completo, vedete [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). [Per la versione più recente dell'ambiente di coda che carica i pacchetti conda, vedete conda\$1queue\$1env\$1console\$1equivalent.yaml nel repository on. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline)](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/conda_queue_env_console_equivalent.yaml) GitHub 

### Accedi Blender dal canale deadline-cloud
<a name="get-application-blender"></a>

L'esempio seguente mostra un modello di lavoro che Blender proviene dal canale conda. `deadline-cloud` Questo canale supporta i mittenti forniti da Deadline Cloud per il software di creazione di contenuti digitali, sebbene sia possibile utilizzare lo stesso canale per caricare software per uso personale.

Per un elenco del software fornito dal `deadline-cloud` canale, consulta [Ambiente di coda predefinito](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html#conda-queue-environment) nella Guida per l'utente di *AWS Deadline* Cloud.

Questo lavoro imposta il `CondaPackages` parametro definito nell'ambiente di coda per indicare a Deadline Cloud di Blender caricarsi nell'ambiente. 

La sezione del modello di lavoro che imposta il parametro è:

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

Per la versione più recente del modello di lavoro di esempio completo, vedi [blender\$1render/template.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/job_bundles/blender_render/template.yaml). [Per la versione più recente dell'ambiente di coda che carica i pacchetti conda, vedi conda\$1queue\$1env\$1console\$1equivalent.yaml nel repository on. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline)](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/conda_queue_env_console_equivalent.yaml)GitHub 

## Usa un gestore di pacchetti diverso
<a name="provide-applications-other-package"></a>

Il gestore di pacchetti predefinito per Deadline Cloud è conda. Se è necessario utilizzare un gestore di pacchetti diverso, ad esempioRez, è possibile creare un ambiente di coda personalizzato che contenga script che utilizzano invece il gestore di pacchetti. 

Questo esempio di ambiente di coda fornisce lo stesso comportamento dell'ambiente utilizzato dalla console per le flotte gestite dai servizi. Sostituisce il gestore di pacchetti conda con. Rez 

L'ambiente definisce tre script che vengono eseguiti quando Deadline Cloud avvia una sessione su un lavoratore. Il primo script viene eseguito quando viene chiamata l'`onEnter`azione. Chiama gli altri due per impostare le variabili di ambiente. Al termine dell'esecuzione dello script, l'Rezambiente è disponibile con tutte le variabili di ambiente specificate impostate.

L'esempio presuppone che si disponga di una flotta gestita dal cliente che utilizza un file system condiviso per i pacchetti Rez.

Per la versione più recente dell'esempio, vedi [rez\$1queue\$1env.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/rez_queue_env.yaml) nel repository su. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline)GitHub