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

# Usa gli allegati del lavoro per condividere file
<a name="build-job-attachments"></a>

Usa *gli allegati di lavoro* per rendere disponibili per i tuoi lavori i file che non si trovano nelle directory condivise e per acquisire i file di output se non vengono scritti in directory condivise. Job attachments utilizza Amazon S3 per trasferire i file tra host. I file vengono archiviati in bucket S3 e non è necessario caricare un file se il suo contenuto non è cambiato.

È necessario utilizzare gli allegati dei lavori quando si eseguono lavori su [flotte gestite dai servizi](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html), poiché gli host non condividono le posizioni dei file system. Gli allegati di lavoro sono utili anche con le [flotte gestite dal cliente quando i](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/manage-cmf.html) file di input o output di un lavoro sono archiviati su un file system di rete condiviso, ad esempio quando il [job bundle contiene](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html) script shell o Python. 

 Quando invii un pacchetto di lavoro con la [CLI di Deadline](https://pypi.org/project/deadline/) Cloud o un mittente di Deadline Cloud, gli allegati di lavoro utilizzano il profilo di archiviazione del lavoro e le posizioni del file system richieste della coda per identificare i file di input che non si trovano su un host di lavoro e devono essere caricati su Amazon S3 come parte dell'invio del lavoro. Questi profili di archiviazione aiutano anche Deadline Cloud a identificare i file di output nelle postazioni host dei lavoratori che devono essere caricati su Amazon S3 in modo che siano disponibili sulla tua workstation. 

 Gli esempi di job attachments utilizzano le configurazioni della farm, della flotta, delle code e dei profili di archiviazione di e. [Esempio di infrastruttura di progetto](sample-project-infrastructure.md) [Profili di archiviazione e mappatura dei percorsi](storage-profiles-and-path-mapping.md) È necessario esaminare queste sezioni prima di questa. 

Negli esempi seguenti, si utilizza un job bundle di esempio come punto di partenza, quindi lo si modifica per esplorare le funzionalità di Job Attachment. I Job bundle sono il modo migliore per i tuoi lavori di utilizzare gli allegati di lavoro. Combinano un modello di [lavoro Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki) in una directory con file aggiuntivi che elencano i file e le directory richiesti dai lavori che utilizzano il job bundle. Per ulteriori informazioni sui pacchetti di lavoro, vedere. [Modelli Open Job Description (OpenJD) per Deadline Cloud](build-job-bundle.md)

# Invio di file con un lavoro
<a name="submitting-files-with-a-job"></a>

Con Deadline Cloud, puoi consentire ai flussi di lavoro di accedere ai file di input che non sono disponibili in posizioni di file system condivise sugli host dei lavoratori. I Job attachments consentono ai processi di rendering di accedere ai file che risiedono solo su un'unità di lavoro locale o su un ambiente di flotta gestito dai servizi. Quando si invia un pacchetto di lavori, è possibile includere elenchi di file di input e directory richiesti dal lavoro. Deadline Cloud identifica questi file non condivisi, li carica dal computer locale su Amazon S3 e li scarica sull'host di lavoro. Semplifica il processo di trasferimento delle risorse di input ai nodi di rendering, garantendo che tutti i file richiesti siano accessibili per l'esecuzione distribuita del lavoro.

È possibile specificare i file per i lavori direttamente nel job bundle, utilizzare i parametri nel modello di lavoro fornito utilizzando variabili di ambiente o uno script e utilizzare il file del lavoro. `assets_references` È possibile utilizzare uno di questi metodi o una combinazione di tutti e tre. È possibile specificare un profilo di archiviazione per il pacchetto per il lavoro in modo che carichi solo i file che sono stati modificati sulla workstation locale.

Questa sezione utilizza un esempio di job bundle GitHub per dimostrare in che modo Deadline Cloud identifica i file del job da caricare, come tali file sono organizzati in Amazon S3 e come vengono messi a disposizione dei worker host che elaborano i lavori. 

**Topics**
+ [In che modo Deadline Cloud carica i file su Amazon S3](what-job-attachments-uploads-to-amazon-s3.md)
+ [In che modo Deadline Cloud sceglie i file da caricare](how-job-attachments-decides-what-to-upload-to-amazon-s3.md)
+ [In che modo le offerte di lavoro trovano i file di input allegati](how-jobs-find-job-attachments-input-files.md)

# In che modo Deadline Cloud carica i file su Amazon S3
<a name="what-job-attachments-uploads-to-amazon-s3"></a>

Questo esempio mostra come Deadline Cloud carica i file dalla tua workstation o dal tuo host di lavoro su Amazon S3 in modo che possano essere condivisi. Utilizza un pacchetto di lavori di esempio GitHub e la CLI di Deadline Cloud per inviare lavori.

 Inizia clonando l'[ GitHubarchivio di esempi di Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples) nel tuo [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)ambiente, quindi copia il `job_attachments_devguide` job bundle nella tua home directory: 

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

 Installa la [CLI di Deadline Cloud](https://pypi.org/project/deadline/) per inviare pacchetti di lavoro: 

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

 Il `job_attachments_devguide` job bundle prevede un unico passaggio con un'attività che esegue uno script di shell bash la cui posizione del file system viene passata come parametro di lavoro. La definizione del parametro job è: 

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

 Il `IN` valore della `dataFlow` proprietà indica agli allegati del lavoro che il valore del `ScriptFile` parametro è un input per il lavoro. Il valore della `default` proprietà è una posizione relativa alla directory del job bundle, ma può anche essere un percorso assoluto. Questa definizione di parametro dichiara il `script.sh` file nella directory del job bundle come file di input necessario per l'esecuzione del processo. 

 Quindi, assicurati che la CLI di Deadline Cloud non abbia un profilo di archiviazione configurato, quindi invia il lavoro alla coda: `Q1` 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id ''

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/
```

 L'output della CLI di Deadline Cloud dopo l'esecuzione di questo comando è simile a: 

```
Submitting to Queue: Q1
...
Hashing Attachments  [####################################]  100%
Hashing Summary:
    Processed 1 file totaling 39.0 B.
    Skipped re-processing 0 files totaling 0.0 B.
    Total processing time of 0.0327 seconds at 1.19 KB/s.

Uploading Attachments  [####################################]  100%
Upload Summary:
    Processed 1 file totaling 39.0 B.
    Skipped re-processing 0 files totaling 0.0 B.
    Total processing time of 0.25639 seconds at 152.0 B/s.

Waiting for Job to be created...
Submitted job bundle:
   job_attachments_devguide/
Job creation completed successfully
job-74148c13342e4514b63c7a7518657005
```

Quando invii il lavoro, Deadline Cloud esegue prima l'hash del `script.sh` file e poi lo carica su Amazon S3. 

Deadline Cloud considera il bucket S3 come un archivio indirizzabile ai contenuti. I file vengono caricati su oggetti S3. Il nome dell'oggetto deriva da un hash del contenuto del file. Se due file hanno contenuti identici, hanno lo stesso valore hash indipendentemente da dove si trovano i file o dal loro nome. Questa archiviazione indirizzabile ai contenuti consente a Deadline Cloud di evitare di caricare un file se è già disponibile.

 Puoi usare l'[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) per vedere gli oggetti che sono stati caricati su Amazon S3: 

```
# The name of queue `Q1`'s job attachments S3 bucket
Q1_S3_BUCKET=$(
  aws deadline get-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \
    --query 'jobAttachmentSettings.s3BucketName' | tr -d '"'
)

aws s3 ls s3://$Q1_S3_BUCKET --recursive
```

 Due oggetti sono stati caricati su S3: 
+  `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`— Il contenuto di. `script.sh` [Il valore `87cb19095dd5d78fcaf56384ef0e6241` nella chiave dell'oggetto è l'hash del contenuto del file e l'estensione `xxh128` indica che il valore hash è stato calcolato come xxhash a 128 bit.](https://xxhash.com/) 
+  `DeadlineCloud/Manifests/<farm-id>/<queue-id>/Inputs/<guid>/a1d221c7fd97b08175b3872a37428e8c_input`— L'oggetto manifesto per l'invio del lavoro. I valori `<farm-id>``<queue-id>`, e `<guid>` sono l'identificatore della fattoria, l'identificatore di coda e un valore esadecimale casuale. Il valore `a1d221c7fd97b08175b3872a37428e8c` in questo esempio è un valore hash calcolato dalla stringa`/home/cloudshell-user/job_attachments_devguide`, la directory in cui si trova. `script.sh` 

 L'oggetto manifest contiene le informazioni per i file di input su un percorso root specifico caricato su S3 come parte dell'invio del lavoro. Scarica questo file manifesto ()`aws s3 cp s3://$Q1_S3_BUCKET/<objectname>`. Il suo contenuto è simile a: 

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

Ciò indica che il file `script.sh` è stato caricato e l'hash del contenuto di quel file è`87cb19095dd5d78fcaf56384ef0e6241`. Questo valore hash corrisponde al valore nel nome dell'oggetto. `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128` Viene utilizzato da Deadline Cloud per sapere quale oggetto scaricare per il contenuto di questo file.

 Lo schema completo di questo file è [disponibile in GitHub](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/job_attachments/asset_manifests/v2023_03_03/validate.py). 

Quando si utilizza l'[CreateJob operazione](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html), è possibile impostare la posizione degli oggetti del manifesto. È possibile utilizzare l'[GetJoboperazione](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) per visualizzare la posizione: 

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

# In che modo Deadline Cloud sceglie i file da caricare
<a name="how-job-attachments-decides-what-to-upload-to-amazon-s3"></a>

 I file e le directory che Job Attachments considera per il caricamento su Amazon S3 come input per il processo sono: 
+  I valori di tutti i parametri `PATH` di processo di tipo definiti nel modello di lavoro del job bundle con il valore o. `dataFlow` `IN` `INOUT`
+  I file e le directory elencati come input nel file di riferimenti agli asset del job bundle. 

 Se invii un lavoro senza profilo di archiviazione, vengono caricati tutti i file considerati per il caricamento. Se invii un lavoro con un profilo di storage, i file non vengono caricati su Amazon S3 se si trovano nelle posizioni del file system di `SHARED` tipo del profilo di storage, che sono anche posizioni del file system necessarie per la coda. Queste posizioni dovrebbero essere disponibili sugli host di lavoro che eseguono il lavoro, quindi non è necessario caricarle su S3. 

 In questo esempio, crei posizioni dei `SHARED` file system `WSAll` nel tuo CloudShell ambiente AWS e poi aggiungi file a tali posizioni. Utilizza il seguente comando: 

```
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

sudo mkdir -p /shared/common /shared/projects/project1 /shared/projects/project2
sudo chown -R cloudshell-user:cloudshell-user /shared

for d in /shared/common /shared/projects/project1 /shared/projects/project2; do
  echo "File contents for $d" > ${d}/file.txt
done
```

 Successivamente, aggiungi un file di riferimenti agli asset al job bundle che include tutti i file che hai creato come input per il job. Utilizza il seguente comando: 

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

 Quindi, configura la CLI di Deadline Cloud per inviare lavori con `WSAll` il profilo di archiviazione, quindi invia il pacchetto di lavori: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id $WSALL_ID

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/
```

Deadline Cloud carica due file su Amazon S3 quando invii il lavoro. Puoi scaricare gli oggetti manifest per il lavoro da S3 per vedere i file caricati: 

```
for manifest in $( \
  aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID \
    --query 'attachments.manifests[].inputManifestPath' \
    | jq -r '.[]'
); do
  echo "Manifest object: $manifest"
  aws s3 cp --quiet s3://$Q1_S3_BUCKET/DeadlineCloud/Manifests/$manifest /dev/stdout | jq .
done
```

 In questo esempio, c'è un singolo file manifest con i seguenti contenuti: 

```
{
    "hashAlg": "xxh128",
    "manifestVersion": "2023-03-03",
    "paths": [
        {
            "hash": "87cb19095dd5d78fcaf56384ef0e6241",
            "mtime": 1721147454416085,
            "path": "home/cloudshell-user/job_attachments_devguide/script.sh",
            "size": 39
        },
        {
            "hash": "af5a605a3a4e86ce7be7ac5237b51b79",
            "mtime": 1721163773582362,
            "path": "shared/projects/project2/file.txt",
            "size": 44
        }
    ],
    "totalSize": 83
}
```

 Utilizzate l'[GetJob operazione](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) per il manifesto per vedere che `rootPath` è «/». 

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

 Il percorso principale per un set di file di input è sempre il sottopercorso comune più lungo di tali file. Se il lavoro è stato inviato Windows invece da e ci sono file di input senza un sottopercorso comune perché si trovavano su unità diverse, viene visualizzato un percorso principale separato su ogni unità. I percorsi in un manifesto sono sempre relativi al percorso principale del manifesto, quindi i file di input che sono stati caricati sono: 
+  `/home/cloudshell-user/job_attachments_devguide/script.sh`— Il file di script nel job bundle. 
+  `/shared/projects/project2/file.txt`— Il file in una posizione del `SHARED` file system nel profilo `WSAll` di archiviazione che **non** è nell'elenco delle posizioni del file system richieste per la coda`Q1`. 

I file nelle posizioni del file system `FSCommon` (`/shared/common/file.txt`) e `FS1` (`/shared/projects/project1/file.txt`) non sono presenti nell'elenco. Questo perché tali posizioni del file system si trovano `SHARED` nel profilo di `WSAll` archiviazione ed entrambe sono nell'elenco delle posizioni del file system richieste in coda`Q1`. 

È possibile visualizzare le posizioni del file system prese in considerazione `SHARED` per un lavoro inviato con un particolare profilo di archiviazione con l'[GetStorageProfileForQueue operazione](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetStorageProfileForQueue.html). Per richiedere il profilo di archiviazione `WSAll` per la coda, `Q1` utilizzare il seguente comando: 

```
aws deadline get-storage-profile --farm-id $FARM_ID --storage-profile-id $WSALL_ID

aws deadline get-storage-profile-for-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID --storage-profile-id $WSALL_ID
```

# In che modo le offerte di lavoro trovano i file di input allegati
<a name="how-jobs-find-job-attachments-input-files"></a>

 Affinché un lavoro utilizzi i file che Deadline Cloud carica su Amazon S3 utilizzando gli allegati del lavoro, il tuo lavoro ha bisogno di quei file disponibili tramite il file system sugli host dei lavoratori. Quando una [sessione](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#sessions) per il tuo lavoro viene eseguita su un host di lavoro, Deadline Cloud scarica i file di input per il lavoro in una directory temporanea sull'unità locale dell'host di lavoro e aggiunge regole di mappatura dei percorsi per ciascuno dei percorsi principali del lavoro alla posizione del file system sull'unità locale. 

 Per questo esempio, avvia l'agente di lavoro Deadline Cloud in una CloudShell scheda AWS. Consenti a tutti i job inviati in precedenza di terminare l'esecuzione, quindi elimina i job logs dalla directory logs: 

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

 Lo script seguente modifica il job bundle per mostrare tutti i file nella directory di lavoro temporanea della sessione e il contenuto del file delle regole di mappatura dei percorsi, quindi invia un job con il pacchetto modificato: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id $WSALL_ID

cat > ~/job_attachments_devguide/script.sh << EOF
#!/bin/bash

echo "Session working directory is: \$(pwd)"
echo
echo "Contents:"
find . -type f
echo
echo "Path mapping rules file: \$1"
jq . \$1
EOF

cat > ~/job_attachments_devguide/template.yaml << EOF
specificationVersion: jobtemplate-2023-09
name: "Job Attachments Explorer"
parameterDefinitions:
- name: ScriptFile
  type: PATH
  default: script.sh
  dataFlow: IN
  objectType: FILE
steps:
- name: Step
  script:
    actions:
      onRun:
        command: /bin/bash
        args:
        - "{{Param.ScriptFile}}"
        - "{{Session.PathMappingRulesFile}}"
EOF

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/
```

 È possibile visualizzare il registro dell'esecuzione del lavoro dopo che è stato eseguito dal lavoratore nel proprio ambiente: AWS CloudShell 

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

Il registro mostra che la prima cosa che si verifica nella sessione è che i due file di input per il lavoro vengono scaricati sul lavoratore: 

```
2024-07-17 01:26:37,824 INFO ==============================================
2024-07-17 01:26:37,825 INFO --------- Job Attachments Download for Job
2024-07-17 01:26:37,825 INFO ==============================================
2024-07-17 01:26:37,825 INFO Syncing inputs using Job Attachments
2024-07-17 01:26:38,116 INFO Downloaded 142.0 B / 186.0 B of 2 files (Transfer rate: 0.0 B/s)
2024-07-17 01:26:38,174 INFO Downloaded 186.0 B / 186.0 B of 2 files (Transfer rate: 733.0 B/s)
2024-07-17 01:26:38,176 INFO Summary Statistics for file downloads:
Processed 2 files totaling 186.0 B.
Skipped re-processing 0 files totaling 0.0 B.
Total processing time of 0.09752 seconds at 1.91 KB/s.
```

 Il prossimo è l'output di `script.sh` run by the job: 
+  I file di input caricati al momento dell'invio del lavoro si trovano in una directory il cui nome inizia con «assetroot» nella directory temporanea della sessione. 
+  I percorsi dei file di input sono stati riposizionati rispetto alla directory «assetroot» anziché rispetto al percorso principale per l'input manifest () del lavoro. `"/"`
+  Il file delle regole di mappatura dei percorsi contiene una regola aggiuntiva che si rimappa `"/"` al percorso assoluto della directory «assetroot». 

 Esempio: 

```
2024-07-17 01:26:38,264 INFO Output:
2024-07-17 01:26:38,267 INFO Session working directory is: /sessions/session-5b33f
2024-07-17 01:26:38,267 INFO 
2024-07-17 01:26:38,267 INFO Contents:
2024-07-17 01:26:38,269 INFO ./tmp_xdhbsdo.sh
2024-07-17 01:26:38,269 INFO ./tmpdi00052b.json
2024-07-17 01:26:38,269 INFO ./assetroot-assetroot-3751a/shared/projects/project2/file.txt
2024-07-17 01:26:38,269 INFO ./assetroot-assetroot-3751a/home/cloudshell-user/job_attachments_devguide/script.sh
2024-07-17 01:26:38,269 INFO 
2024-07-17 01:26:38,270 INFO Path mapping rules file: /sessions/session-5b33f/tmpdi00052b.json
2024-07-17 01:26:38,282 INFO {
2024-07-17 01:26:38,282 INFO   "version": "pathmapping-1.0",
2024-07-17 01:26:38,282 INFO   "path_mapping_rules": [
2024-07-17 01:26:38,282 INFO     {
2024-07-17 01:26:38,282 INFO       "source_path_format": "POSIX",
2024-07-17 01:26:38,282 INFO       "source_path": "/shared/projects/project1",
2024-07-17 01:26:38,283 INFO       "destination_path": "/mnt/projects/project1"
2024-07-17 01:26:38,283 INFO     },
2024-07-17 01:26:38,283 INFO     {
2024-07-17 01:26:38,283 INFO       "source_path_format": "POSIX",
2024-07-17 01:26:38,283 INFO       "source_path": "/shared/common",
2024-07-17 01:26:38,283 INFO       "destination_path": "/mnt/common"
2024-07-17 01:26:38,283 INFO     },
2024-07-17 01:26:38,283 INFO     {
2024-07-17 01:26:38,283 INFO       "source_path_format": "POSIX",
2024-07-17 01:26:38,283 INFO       "source_path": "/",
2024-07-17 01:26:38,283 INFO       "destination_path": "/sessions/session-5b33f/assetroot-assetroot-3751a"
2024-07-17 01:26:38,283 INFO     }
2024-07-17 01:26:38,283 INFO   ]
2024-07-17 01:26:38,283 INFO }
```

**Nota**  
 Se il lavoro inviato contiene più manifesti con percorsi root diversi, esiste una directory denominata «assetroot» diversa per ciascuno dei percorsi root. 

 Se è necessario fare riferimento alla posizione del file system trasferito di uno dei file di input, delle directory o delle posizioni del file system, è possibile elaborare il file delle regole di mappatura dei percorsi nel job ed eseguire la rimappatura autonomamente, oppure aggiungere un parametro `PATH` type job al modello di lavoro nel job bundle e passare il valore da rimappare come valore di quel parametro. Ad esempio, l'esempio seguente modifica il job bundle in modo che abbia uno di questi parametri di job e quindi invia un job con la posizione del file system `/shared/projects/project2` come valore: 

```
cat > ~/job_attachments_devguide/template.yaml << EOF
specificationVersion: jobtemplate-2023-09
name: "Job Attachments Explorer"
parameterDefinitions:
- name: LocationToRemap
  type: PATH
steps:
- name: Step
  script:
    actions:
      onRun:
        command: /bin/echo
        args:
        - "The location of {{RawParam.LocationToRemap}} in the session is {{Param.LocationToRemap}}"
EOF

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/ \
  -p LocationToRemap=/shared/projects/project2
```

 Il file di registro per l'esecuzione di questo processo contiene il relativo output: 

```
2024-07-17 01:40:35,283 INFO Output:
2024-07-17 01:40:35,284 INFO The location of /shared/projects/project2 in the session is /sessions/session-5b33f/assetroot-assetroot-3751a
```

# Ottenere file di output da un lavoro
<a name="getting-output-files-from-a-job"></a>

Questo esempio mostra come Deadline Cloud identifica i file di output generati dai tuoi lavori, decide se caricare tali file su Amazon S3 e come trasferirli sulla tua workstation. 

 Per questo esempio, usa il `job_attachments_devguide_output` job bundle anziché il `job_attachments_devguide` job bundle. Inizia creando una copia del pacchetto nel tuo AWS CloudShell ambiente dal tuo clone dell'archivio di esempi di Deadline Cloud: GitHub 

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

 La differenza importante tra questo job bundle e il `job_attachments_devguide` job bundle è l'aggiunta di un nuovo parametro di job nel modello di job: 

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

 La `dataFlow` proprietà del parametro ha il valore. `OUT` Deadline Cloud utilizza il valore dei parametri del `dataFlow` lavoro con un valore pari `OUT` o `INOUT` come output del lavoro. Se la posizione del file system passata come valore a questi tipi di parametri di lavoro viene rimappata a una posizione del file system locale sul lavoratore che esegue il lavoro, Deadline Cloud cercherà nuovi file nella posizione e li caricherà su Amazon S3 come output del lavoro. 

 Per vedere come funziona, avvia innanzitutto il worker agent di Deadline Cloud in una scheda. AWS CloudShell Lascia che tutti i lavori inviati in precedenza finiscano di essere eseguiti. Quindi elimina i registri dei lavori dalla directory dei registri: 

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

 Successivamente, invia un lavoro con questo pacchetto di offerte di lavoro. Dopo che il lavoratore è entrato a far parte delle tue CloudShell attività, guarda i log: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id $WSALL_ID

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID ./job_attachments_devguide_output
```

 Il log mostra che un file è stato rilevato come output e caricato su Amazon S3: 

```
2024-07-17 02:13:10,873 INFO ----------------------------------------------
2024-07-17 02:13:10,873 INFO Uploading output files to Job Attachments
2024-07-17 02:13:10,873 INFO ----------------------------------------------
2024-07-17 02:13:10,873 INFO Started syncing outputs using Job Attachments
2024-07-17 02:13:10,955 INFO Found 1 file totaling 117.0 B in output directory: /sessions/session-7efa/assetroot-assetroot-3751a/output_dir
2024-07-17 02:13:10,956 INFO Uploading output manifest to DeadlineCloud/Manifests/farm-0011/queue-2233/job-4455/step-6677/task-6677-0/2024-07-17T02:13:10.835545Z_sessionaction-8899-1/c6808439dfc59f86763aff5b07b9a76c_output
2024-07-17 02:13:10,988 INFO Uploading 1 output file to S3: s3BucketName/DeadlineCloud/Data
2024-07-17 02:13:11,011 INFO Uploaded 117.0 B / 117.0 B of 1 file (Transfer rate: 0.0 B/s)
2024-07-17 02:13:11,011 INFO Summary Statistics for file uploads:
Processed 1 file totaling 117.0 B.
Skipped re-processing 0 files totaling 0.0 B.
Total processing time of 0.02281 seconds at 5.13 KB/s.
```

 Il registro mostra anche che Deadline Cloud ha creato un nuovo oggetto manifest nel bucket Amazon S3 configurato per l'utilizzo da parte degli allegati di lavoro in coda. `Q1` Il nome dell'oggetto manifesto deriva dalla farm, dalla queue, dal job, dallo step, dal task, dal timestamp e dagli `sessionaction` identificatori dell'attività che ha generato l'output. Scarica questo file manifest per vedere dove Deadline Cloud ha inserito i file di output per questa attività: 

```
# The name of queue `Q1`'s job attachments S3 bucket
Q1_S3_BUCKET=$(
  aws deadline get-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \
    --query 'jobAttachmentSettings.s3BucketName' | tr -d '"'
)

# Fill this in with the object name from your log
OBJECT_KEY="DeadlineCloud/Manifests/..."

aws s3 cp --quiet s3://$Q1_S3_BUCKET/$OBJECT_KEY /dev/stdout | jq .
```

 Il manifesto ha il seguente aspetto: 

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

 Ciò dimostra che il contenuto del file di output viene salvato su Amazon S3 nello stesso modo in cui vengono salvati i file di input del lavoro. Analogamente ai file di input, il file di output viene archiviato in S3 con un nome di oggetto contenente l'hash del file e il prefisso. `DeadlineCloud/Data` 

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

 Puoi scaricare l'output di un lavoro sulla tua workstation utilizzando il monitor Deadline Cloud o la CLI di Deadline Cloud: 

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

 Il valore del parametro `OutputDir` job nel job inviato è`./output_dir`, quindi l'output viene scaricato in una directory chiamata `output_dir` all'interno della directory del job bundle. Se avete specificato un percorso assoluto o una posizione relativa diversa come valore per`OutputDir`, i file di output verranno invece scaricati in quella posizione. 

```
$ deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID
Downloading output from Job 'Job Attachments Explorer: Output'

Summary of files to download:
    /home/cloudshell-user/job_attachments_devguide_output/output_dir/output.txt (1 file)

You are about to download files which may come from multiple root directories. Here are a list of the current root directories:
[0] /home/cloudshell-user/job_attachments_devguide_output
> Please enter the index of root directory to edit, y to proceed without changes, or n to cancel the download (0, y, n) [y]: 

Downloading Outputs  [####################################]  100%
Download Summary:
    Downloaded 1 files totaling 117.0 B.
    Total download time of 0.14189 seconds at 824.0 B/s.
    Download locations (total file counts):
        /home/cloudshell-user/job_attachments_devguide_output (1 file)
```

# Utilizzo di file da un passaggio a un passaggio dipendente
<a name="using-files-output-from-a-step-in-a-dependent-step"></a>

Questo esempio mostra come una fase di un processo può accedere agli output di una fase da cui dipende nello stesso processo. 

 Per rendere gli output di un passaggio disponibili per un altro, Deadline Cloud aggiunge azioni aggiuntive a una sessione per scaricare tali output prima di eseguire le attività nella sessione. Gli dici da quali passaggi scaricare gli output dichiarando tali passaggi come dipendenze del passaggio che deve utilizzare gli output. 

Usa il `job_attachments_devguide_output` job bundle per questo esempio. Inizia creando una copia nel tuo AWS CloudShell ambiente dal tuo clone del repository di esempi di Deadline Cloud. GitHub Modificalo per aggiungere un passaggio dipendente che venga eseguito solo dopo il passaggio esistente e utilizzi l'output di quel passaggio: 

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

cat >> job_attachments_devguide_output/template.yaml << EOF
- name: DependentStep
  dependencies:
  - dependsOn: Step
  script:
    actions:
      onRun:
        command: /bin/cat
        args:
        - "{{Param.OutputDir}}/output.txt"
EOF
```

 Il processo creato con questo job bundle modificato viene eseguito come due sessioni separate, una per l'attività nel passaggio «Step» e la seconda per l'attività nel passaggio "DependentStep». 

Per prima cosa avvia il worker agent di Deadline Cloud in una CloudShell scheda. Lascia terminare l'esecuzione di tutti i lavori inviati in precedenza, quindi elimina i log dei lavori dalla directory dei log: 

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

 Successivamente, invia un lavoro utilizzando il pacchetto di `job_attachments_devguide_output` lavori modificato. Attendi che finisca di essere eseguito sul lavoratore del tuo CloudShell ambiente. Guarda i log delle due sessioni: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id $WSALL_ID

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID ./job_attachments_devguide_output

# Wait for the job to finish running, and then:

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

 Nel registro delle sessioni relativo all'attività indicata nella fase indicata`DependentStep`, vengono eseguite due azioni di download separate: 

```
2024-07-17 02:52:05,666 INFO ==============================================
2024-07-17 02:52:05,666 INFO --------- Job Attachments Download for Job
2024-07-17 02:52:05,667 INFO ==============================================
2024-07-17 02:52:05,667 INFO Syncing inputs using Job Attachments
2024-07-17 02:52:05,928 INFO Downloaded 207.0 B / 207.0 B of 1 file (Transfer rate: 0.0 B/s)
2024-07-17 02:52:05,929 INFO Summary Statistics for file downloads:
Processed 1 file totaling 207.0 B.
Skipped re-processing 0 files totaling 0.0 B.
Total processing time of 0.03954 seconds at 5.23 KB/s.

2024-07-17 02:52:05,979 INFO 
2024-07-17 02:52:05,979 INFO ==============================================
2024-07-17 02:52:05,979 INFO --------- Job Attachments Download for Step
2024-07-17 02:52:05,979 INFO ==============================================
2024-07-17 02:52:05,980 INFO Syncing inputs using Job Attachments
2024-07-17 02:52:06,133 INFO Downloaded 117.0 B / 117.0 B of 1 file (Transfer rate: 0.0 B/s)
2024-07-17 02:52:06,134 INFO Summary Statistics for file downloads:
Processed 1 file totaling 117.0 B.
Skipped re-processing 0 files totaling 0.0 B.
Total processing time of 0.03227 seconds at 3.62 KB/s.
```

 La prima azione scarica il `script.sh` file utilizzato dal passaggio denominato «Step». La seconda azione scarica gli output di quel passaggio. Deadline Cloud determina quali file scaricare utilizzando il manifesto di output generato da quel passaggio come manifesto di input. 

 Più avanti nello stesso registro, puoi vedere l'output del passaggio denominato "DependentStep«: 

```
2024-07-17 02:52:06,213 INFO Output:
2024-07-17 02:52:06,216 INFO Script location: /sessions/session-5b33f/assetroot-assetroot-3751a/script.sh
```