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à. # Crea lavori da inviare a Deadline Cloud Invii offerte di lavoro a Deadline Cloud utilizzando i pacchetti di lavoro. Un job bundle è una raccolta di file, tra cui un modello di [lavoro Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) e qualsiasi file di asset necessario per eseguire il rendering del lavoro. Il modello di lavoro descrive come i lavoratori elaborano e accedono agli asset e fornisce lo script eseguito dal lavoratore. I Job bundle consentono ad artisti, direttori tecnici e sviluppatori di pipeline di inviare facilmente lavori complessi a Deadline Cloud dalle loro workstation locali o dalla render farm locale. I Job bundle sono particolarmente utili per i team che lavorano su effetti visivi, animazioni o altri progetti di rendering multimediale su larga scala che richiedono risorse di elaborazione scalabili e su richiesta. È possibile creare il job bundle utilizzando il file system locale per archiviare i file e un editor di testo per creare il modello di lavoro. Dopo aver creato il pacchetto, invia il lavoro a Deadline Cloud utilizzando la CLI di Deadline Cloud o uno strumento come un mittente di Deadline Cloud Puoi archiviare le tue risorse in un file system condiviso tra i tuoi dipendenti oppure puoi utilizzare gli allegati di lavoro di Deadline Cloud per automatizzare lo spostamento delle risorse nei bucket S3, dove i dipendenti possono accedervi. Gli allegati Job aiutano anche a riportare l'output dai lavori alle workstation. Le seguenti sezioni forniscono istruzioni dettagliate sulla creazione e l'invio di pacchetti di lavoro a Deadline Cloud. **Topics** + [Modelli Open Job Description (OpenJD) per Deadline Cloud](build-job-bundle.md) + [Utilizzo dei file nei lavori](using-files-in-your-jobs.md) + [Usa gli allegati del lavoro per condividere file](build-job-attachments.md) + [Creare limiti di risorse per i lavori](build-job-limits.md) + [Come inviare un'offerta di lavoro a Deadline Cloud](submit-jobs-how.md) + [Pianifica lavori in Deadline Cloud](build-jobs-scheduling.md) + [Modifica un lavoro in Deadline Cloud](build-jobs-modifying.md) # Modelli Open Job Description (OpenJD) per Deadline Cloud Un *job bundle* è uno degli strumenti che usi per definire i lavori per AWS Deadline Cloud. Raggruppano un modello di [Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) con informazioni aggiuntive come file e directory che i lavori utilizzano con gli allegati del lavoro. Utilizzi l'interfaccia a riga di comando (CLI) di Deadline Cloud per utilizzare un pacchetto di lavori per inviare lavori per l'esecuzione di una coda. Un job bundle è una struttura di directory che contiene un modello di lavoro OpenJD, altri file che definiscono il lavoro e file specifici del lavoro richiesti come input per il lavoro. È possibile specificare i file che definiscono il lavoro come file YAML o JSON. L'unico file richiesto è o. `template.yaml` `template.json` Puoi anche includere i seguenti file: ``` /template.yaml (or template.json) /asset_references.yaml (or asset_references.json) /parameter_values.yaml (or parameter_values.json) /other job-specific files and directories ``` Utilizza un pacchetto di lavori per l'invio di lavori personalizzati con la CLI di Deadline Cloud e un allegato di lavoro, oppure puoi utilizzare un'interfaccia grafica di invio. Ad esempio, quello che segue è l'esempio di Blender di. GitHub Per eseguire l'esempio, utilizzate il seguente comando nella directory di [esempio di Blender](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles): ``` deadline bundle gui-submit blender_render ``` ![\[Un esempio di interfaccia personalizzata per l'invio di lavori per Blender.\]](http://docs.aws.amazon.com/it_it/deadline-cloud/latest/developerguide/images/blender_submit_shared_settings.png) Il pannello delle impostazioni specifiche del lavoro viene generato dalle `userInterface` proprietà dei parametri del lavoro definiti nel modello di lavoro. Per inviare un lavoro utilizzando la riga di comando, è possibile utilizzare un comando simile al seguente ``` deadline bundle submit \ --yes \ --name Demo \ -p BlenderSceneFile=location of scene file \ -p OutputDir=file pathe for job output \ blender_render/ ``` Oppure puoi usare la `deadline.client.api.create_job_from_job_bundle` funzione nel pacchetto `deadline` Python. Tutti i plugin per l'invio dei lavori forniti con Deadline Cloud, come il plug-in Autodesk Maya, generano un pacchetto di lavori per l'invio e quindi utilizzano il pacchetto Deadline Cloud Python per inviare il lavoro a Deadline Cloud. Puoi vedere i pacchetti di offerte di lavoro inviati nella directory della cronologia dei lavori della tua postazione di lavoro o utilizzando un mittente. È possibile trovare la directory della cronologia delle mansioni con il seguente comando: ``` deadline config get settings.job_history_dir ``` Quando il tuo lavoro è in esecuzione su un lavoratore Deadline Cloud, ha accesso a variabili di ambiente che forniscono informazioni sul lavoro. Le variabili di ambiente sono: | Nome della variabile | Disponibilità | | --- | --- | | DEADLINE\$1FARM\$1ID | Tutte le operazioni | | DEADLINE\$1FLOTTE\$1ID | Tutte le operazioni | | ID\$1DEADLINE\$1WORKER | Tutte le operazioni | | ID\$1CODA DI SCADENZA | Tutte le operazioni | | ID\$1DEADLINE\$1JOB\$1ID | Tutte le operazioni | | ID\$1FASE DI SCADENZA | Azioni relative alle attività | | DEADLINE\$1SESSION\$1ID | Tutte le operazioni | | ID\$1ATTIVITÀ\$1SCADENZA | Azioni relative alle attività | | DEADLINE\$1SESSIONACTION\$1ID | Tutte le operazioni | **Topics** + [Elementi del modello di lavoro per i pacchetti di lavoro](build-job-bundle-template.md) + [Suddivisione delle attività per i modelli di lavoro](build-job-bundle-chunking.md) + [Valori dei parametri, elementi per i job bundle.](build-job-bundle-parameters.md) + [Elementi di riferimento delle risorse per i pacchetti di lavoro](build-job-bundle-assets.md) # Elementi del modello di lavoro per i pacchetti di lavoro Il modello di lavoro definisce l'ambiente di runtime e i processi che vengono eseguiti come parte di un job di Deadline Cloud. È possibile creare parametri in un modello in modo che possa essere utilizzato per creare lavori che differiscono solo nei valori di input, proprio come una funzione in un linguaggio di programmazione. Quando invii un lavoro a Deadline Cloud, questo viene eseguito in qualsiasi ambiente di coda applicato alla coda. Gli ambienti di coda vengono creati utilizzando la specifica degli ambienti esterni Open Job Description (OpenJD). Per i dettagli, consulta il [modello Environment nel repository](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#12-environment-template) OpenJD. GitHub Per un'introduzione alla creazione di un lavoro con un modello di lavoro OpenJD, vedi [Introduzione alla creazione di un lavoro](https://github.com/OpenJobDescription/openjd-specifications/wiki/Introduction-to-Creating-a-Job) nel repository OpenJD. GitHub [Ulteriori informazioni sono disponibili in Come vengono eseguiti i lavori.](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) Sono disponibili esempi di modelli di lavoro nella directory del GitHub repository OpenJD. `samples` È possibile definire il modello di lavoro in formato YAML (`template.yaml`) o in formato JSON (). `template.json` Gli esempi in questa sezione sono mostrati in formato YAML. Ad esempio, il modello di lavoro per l'`blender_render`esempio definisce un parametro di input `BlenderSceneFile` come percorso di file: ``` - name: BlenderSceneFile type: PATH objectType: FILE dataFlow: IN userInterface: control: CHOOSE_INPUT_FILE label: Blender Scene File groupLabel: Render Parameters fileFilters: - label: Blender Scene Files patterns: ["*.blend"] - label: All Files patterns: ["*"] description: > Choose the Blender scene file to render. Use the 'Job Attachments' tab to add textures and other files that the job needs. ``` La `userInterface` proprietà definisce il comportamento delle interfacce utente generate automaticamente sia per la riga di comando che utilizza il `deadline bundle gui-submit` comando sia all'interno dei plugin di invio dei lavori per applicazioni come Autodesk Maya. In questo esempio, il widget dell'interfaccia utente per l'immissione di un valore per il `BlenderSceneFile` parametro è una finestra di dialogo per la selezione dei file che mostra solo i file. `.blend` ![\[Un widget di interfaccia utente per l'immissione del parametro del file di scena per un modello di lavoro OpenJD.\]](http://docs.aws.amazon.com/it_it/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png) Per ulteriori esempi di utilizzo dell'`userInteface`elemento, consultate l'esempio [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) nel repository su. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub Le `dataFlow` proprietà `objectType` and controllano il comportamento degli allegati delle offerte di lavoro quando invii un'offerta di lavoro da un pacchetto di offerte di lavoro. In questo caso, `objectType: FILE` `dataFlow:IN` significa che il valore di `BlenderSceneFile` è un file di input per gli allegati del lavoro. Al contrario, la definizione del `OutputDir` parametro ha `objectType: DIRECTORY` e`dataFlow: OUT`: ``` - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT userInterface: control: CHOOSE_DIRECTORY label: Output Directory groupLabel: Render Parameters default: "./output" description: Choose the render output directory. ``` Il valore del `OutputDir` parametro viene utilizzato dagli allegati del lavoro come directory in cui il lavoro scrive i file di output. Per ulteriori informazioni sulle `dataFlow` proprietà `objectType` e, vedere [JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)la [specifica Open Job Description](https://github.com/OpenJobDescription/openjd-specifications) Il resto dell'esempio di modello di `blender_render` lavoro definisce il flusso di lavoro del lavoro come un singolo passaggio, con ogni fotogramma dell'animazione renderizzato come un'attività separata: ``` steps: - name: RenderBlender parameterSpace: taskParameterDefinitions: - name: Frame type: INT range: "{{Param.Frames}}" script: actions: onRun: command: bash # Note: {{Task.File.Run}} is a variable that expands to the filename on the worker host's # disk where the contents of the 'Run' embedded file, below, is written. args: ['{{Task.File.Run}}'] embeddedFiles: - name: Run type: TEXT data: | # Configure the task to fail if any individual command fails. set -xeuo pipefail mkdir -p '{{Param.OutputDir}}' blender --background '{{Param.BlenderSceneFile}}' \ --render-output '{{Param.OutputDir}}/{{Param.OutputPattern}}' \ --render-format {{Param.Format}} \ --use-extension 1 \ --render-frame {{Task.Param.Frame}} ``` Ad esempio, se il valore del `Frames` parametro è`1-10`, definisce 10 attività. Ogni task ha un valore diverso per il `Frame` parametro. Per eseguire un'attività: 1. Ad esempio, tutti i riferimenti alle variabili nella `data` proprietà del file incorporato vengono espansi`--render-frame 1`. 1. Il contenuto della `data` proprietà viene scritto su un file nella directory di lavoro della sessione su disco. 1. Il `onRun` comando dell'attività si risolve in `bash location of embedded file` e quindi viene eseguito. Per ulteriori informazioni su file incorporati, sessioni e percorsi mappati, vedere [How job are run](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) [nella specifica Open Job](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) Description. Esistono altri esempi di modelli di lavoro nel repository [deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles), oltre agli [esempi di modelli](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples) forniti con la specifica Open Job Descriptions. # Suddivisione delle attività per i modelli di lavoro La suddivisione in blocchi delle attività consente di raggruppare più attività in un'unica unità di lavoro denominata chunk. In un lavoro di rendering, ad esempio, ciò significa che Deadline Cloud può inviare più frame insieme anziché un frame per chiamata di comando. Ciò riduce il sovraccarico di avvio delle applicazioni per ogni attività e riduce la durata totale del lavoro. Per i dettagli, consulta [Esecuzione di più frame alla volta nel wiki](https://github.com/OpenJobDescription/openjd-specifications/wiki/Job-Intro-03-Creating-a-Job-Template#42-running-multiple-frames-at-a-time) di OpenJD. OpenJD supporta estensioni che aggiungono funzionalità opzionali ai modelli di lavoro. La suddivisione in blocchi delle attività viene abilitata aggiungendo l'estensione. `TASK_CHUNKING` Per utilizzare la suddivisione in blocchi, aggiungi l'estensione al tuo modello di lavoro e utilizza il tipo di parametro dell'`CHUNK[INT]`attività. Invia lavori suddivisi in blocchi utilizzando lo stesso comando. `deadline bundle submit` Ad esempio, il seguente modello di lavoro esegue il rendering dei frame in blocchi di 10: ``` specificationVersion: 'jobtemplate-2023-09' extensions: - TASK_CHUNKING name: Blender Render with Contiguous Chunking parameterDefinitions: - name: BlenderSceneFile type: PATH objectType: FILE dataFlow: IN - name: Frames type: STRING default: "1-100" - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT default: "./output" steps: - name: RenderBlender parameterSpace: taskParameterDefinitions: - name: Frame type: CHUNK[INT] range: "{{Param.Frames}}" chunks: defaultTaskCount: 10 rangeConstraint: CONTIGUOUS script: actions: onRun: command: bash args: ["{{Task.File.Run}}"] embeddedFiles: - name: Run type: TEXT data: | set -xeuo pipefail mkdir -p '{{Param.OutputDir}}' # Parse the chunk range (e.g., "1-10") into start and end frames START_FRAME="$(echo '{{Task.Param.Frame}}' | cut -d- -f1)" END_FRAME="$(echo '{{Task.Param.Frame}}' | cut -d- -f2)" blender --background '{{Param.BlenderSceneFile}}' \ --render-output '{{Param.OutputDir}}/output_####' \ --render-format PNG \ --use-extension 1 \ -s "$START_FRAME" \ -e "$END_FRAME" \ --render-anim ``` In questo esempio, Deadline Cloud divide i 100 frame in blocchi come, e così via. `1-10` `11-20` La `{{Task.Param.Frame}}` variabile si espande in un'espressione di intervallo come. `1-10` Poiché `rangeConstraint` è impostato su`CONTIGUOUS`, l'intervallo è sempre in `start-end` formato. Lo script analizza questo intervallo e passa i frame iniziale e finale a Blender usando le `-e` opzioni `-s` e with. `--render-anim` La `chunks` proprietà supporta i seguenti campi: + `defaultTaskCount`— (Obbligatorio) Quante attività combinare in un unico blocco. Il valore massimo è 150. + `rangeConstraint`— (Obbligatorio) Se`CONTIGUOUS`, un blocco è sempre un intervallo contiguo come. `1-10` Se`NONCONTIGUOUS`, un blocco può essere un insieme arbitrario, ad esempio. `1,3,7-10` + `targetRuntimeSeconds`— (Facoltativo) Il tempo di esecuzione previsto in secondi per ogni blocco. Deadline Cloud può regolare dinamicamente la dimensione dei blocchi per avvicinarsi a questo obiettivo una volta completati alcuni blocchi. [Per altri esempi di suddivisione in blocchi delle attività, inclusi esempi di base e di Blender con blocchi contigui e non contigui, consulta gli esempi di suddivisione in blocchi delle attività nell'archivio degli esempi di Deadline Cloud su.](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking) GitHub **Requisiti della flotta gestita dal cliente** La suddivisione delle attività richiede una versione di Worker Agent compatibile. Se utilizzi flotte gestite dai clienti, assicurati che i tuoi worker agent siano aggiornati prima di inviare lavori con chunking. Le flotte gestite dai servizi utilizzano sempre una versione di Worker Agent compatibile. **Scaricamento dell'output per lavori suddivisi in blocchi** Quando scarichi l'output per una singola attività in un lavoro suddiviso in blocchi, Deadline Cloud scarica l'output per l'intero blocco. Ad esempio, se i frame 1-10 sono stati elaborati insieme, il download dell'output per il frame 3 include tutti i frame 1-10. Questa funzionalità richiede la `deadline-cloud` versione 0.53.3 o successiva. # Valori dei parametri, elementi per i job bundle. È possibile utilizzare il file dei parametri per impostare i valori di alcuni parametri del processo nel modello di lavoro o gli argomenti della richiesta di [CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)operazione nel job bundle in modo da non dover impostare valori quando si invia un lavoro. L'interfaccia utente per l'invio dei lavori consente di modificare questi valori. È possibile definire il modello di lavoro in formato YAML (`parameter_values.yaml`) o in formato JSON (). `parameter_values.json` Gli esempi in questa sezione sono mostrati in formato YAML. In YAML, il formato del file è: ``` parameterValues: - name: value: , , or - name: value: , , or ab ... repeating as necessary ``` Ogni elemento dell'`parameterValues`elenco deve essere uno dei seguenti: + Un parametro di lavoro definito nel modello di lavoro. + Un parametro di lavoro definito in un ambiente di coda per la coda a cui si invia il lavoro.. + Un parametro speciale passato all'`CreateJob`operazione durante la creazione di un lavoro. + `deadline:priority`— Il valore deve essere un numero intero. Viene passato all'`CreateJob`operazione come parametro [prioritario](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-priority). + `deadline:targetTaskRunStatus`— Il valore deve essere una stringa. Viene passato all'`CreateJob`operazione come parametro [targetTaskRunStatus](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus). + `deadline:maxFailedTasksCount`— Il valore deve essere un numero intero. Viene passato all'`CreateJob`operazione come parametro [maxFailedTasksCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount). + `deadline:maxRetriesPerTask`— Il valore deve essere un numero intero. Viene passato all'`CreateJob`operazione come parametro [maxRetriesPerTask](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask). + `deadline:maxWorkercount`— Il valore deve essere un numero intero. Viene passato all'`CreateJob`operazione come [maxWorkerCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask)parametro. Un modello di lavoro è sempre un modello anziché un processo specifico da eseguire. Un file di valori dei parametri consente a un job bundle di fungere da modello se alcuni parametri non hanno valori definiti in questo file o come invio di job specifico se tutti i parametri hanno valori. Ad esempio, l'esempio [blender\$1render non ha un file di parametri e il relativo modello di lavoro definisce parametri senza valori predefiniti](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render). Questo modello deve essere usato come modello per creare lavori. Dopo aver creato un job utilizzando questo job bundle, Deadline Cloud scrive un nuovo job bundle nella directory della cronologia dei lavori. Ad esempio, quando invii un lavoro con il seguente comando: ``` deadline bundle gui-submit blender_render/ ``` Il nuovo job bundle contiene un `parameter_values.yaml` file che contiene i parametri specificati: ``` % cat ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/parameter_values.yaml parameterValues: - name: deadline:targetTaskRunStatus value: READY - name: deadline:maxFailedTasksCount value: 10 - name: deadline:maxRetriesPerTask value: 5 - name: deadline:priority value: 75 - name: BlenderSceneFile value: /private/tmp/bundle_demo/bmw27_cpu.blend - name: Frames value: 1-10 - name: OutputDir value: /private/tmp/bundle_demo/output - name: OutputPattern value: output_#### - name: Format value: PNG - name: CondaPackages value: blender - name: RezPackages value: blender ``` È possibile creare lo stesso lavoro con il seguente comando: ``` deadline bundle submit ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/ ``` **Nota** Il job bundle inviato viene salvato nella directory della cronologia dei lavori. Puoi trovare la posizione di quella directory con il seguente comando: ``` deadline config get settings.job_history_dir ``` # Elementi di riferimento delle risorse per i pacchetti di lavoro Puoi utilizzare [gli allegati di lavoro](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) di Deadline Cloud per trasferire file avanti e indietro tra la tua workstation e Deadline Cloud. Il file di riferimento delle risorse elenca i file e le directory di input, nonché le directory di output per gli allegati. Se non elencate tutti i file e le directory in questo file, potete selezionarli quando inviate un lavoro con il comando. `deadline bundle gui-submit` Questo file non ha effetto se non si utilizzano gli allegati del lavoro. È possibile definire il modello di lavoro in formato YAML (`asset_references.yaml`) o in formato JSON (). `asset_references.json` Gli esempi in questa sezione sono mostrati in formato YAML. In YAML, il formato del file è: ``` assetReferences: inputs: # Filenames on the submitting workstation whose file contents are needed as # inputs to run the job. filenames: - list of file paths # Directories on the submitting workstation whose contents are needed as inputs # to run the job. directories: - list of directory paths outputs: # Directories on the submitting workstation where the job writes output files # if running locally. directories: - list of directory paths # Paths referenced by the job, but not necessarily input or output. # Use this if your job uses the name of a path in some way, but does not explicitly need # the contents of that path. referencedPaths: - list of directory paths ``` Quando si seleziona il file di input o output da caricare su Amazon S3, Deadline Cloud confronta il percorso del file con i percorsi elencati nei profili di archiviazione. Ogni posizione del file system `SHARED` di tipo in un profilo di archiviazione astrae una condivisione di file di rete montata sulle workstation e sugli host di lavoro. Deadline Cloud carica solo i file che non si trovano su una di queste condivisioni di file. Per ulteriori informazioni sulla creazione e l'utilizzo dei profili di archiviazione, consulta [Archiviazione condivisa in Deadline Cloud nella](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) Guida per l'utente di *AWS Deadline* Cloud. **Example - Il file di riferimento delle risorse creato dalla GUI di Deadline Cloud** Utilizzate il comando seguente per inviare un lavoro utilizzando l'esempio [blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render). ``` deadline bundle gui-submit blender_render/ ``` Aggiungi alcuni file aggiuntivi al lavoro nella scheda **Job attachments**: ![\[Il riquadro degli allegati del lavoro della GUI di invio dei lavori di Deadline Cloud. Aggiungi il file di input/. private/tmp/bundle_demo/a_texture.png and the input directory /private/tmp/bundle_demo/assets\]](http://docs.aws.amazon.com/it_it/deadline-cloud/latest/developerguide/images/blender_submit_add_job_attachments.png) Dopo aver inviato il lavoro, puoi guardare il `asset_references.yaml` file nel job bundle nella directory della cronologia dei lavori per vedere le risorse nel file YAML: ``` % cat ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/asset_references.yaml assetReferences: inputs: filenames: - /private/tmp/bundle_demo/a_texture.png directories: - /private/tmp/bundle_demo/assets outputs: directories: [] referencedPaths: [] ``` # Utilizzo dei file nei lavori Molti dei lavori che invii a AWS Deadline Cloud contengono file di input e output. I file di input e le directory di output possono trovarsi su una combinazione di file system condivisi e unità locali. I lavori devono localizzare il contenuto in tali posizioni. Deadline Cloud offre due funzionalità, [gli allegati dei](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) lavori e [i profili di archiviazione](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) che interagiscono per aiutare le aziende a individuare i file di cui hanno bisogno. Gli allegati Job offrono diversi vantaggi + Spostamento di file tra host utilizzando Amazon S3 + Trasferisci file dalla tua postazione di lavoro agli host di lavoro e viceversa + Disponibile per i lavori in coda in cui è abilitata la funzione + Utilizzato principalmente con flotte gestite dai servizi, ma anche compatibile con flotte gestite dai clienti. Utilizza i profili di storage per mappare il layout delle posizioni condivise dei file system sulla workstation e sugli host dei lavoratori. Questa mappatura aiuta i job a localizzare file e directory condivisi quando le loro posizioni differiscono tra la workstation e gli host di lavoro, ad esempio configurazioni multipiattaforma con workstation basate e worker host basati. Windows Linux La mappa del profilo di storage della configurazione del file system viene utilizzata anche dagli allegati dei lavori per identificare i file necessari per lo spostamento tra gli host tramite Amazon S3. Se non utilizzi gli allegati di lavoro e non hai bisogno di rimappare le posizioni di file e directory tra le workstation e gli host di lavoro, non è necessario modellare le condivisioni di file con profili di storage. **Topics** + [Esempio di infrastruttura di progetto](sample-project-infrastructure.md) + [Profili di archiviazione e mappatura dei percorsi](storage-profiles-and-path-mapping.md) # Esempio di infrastruttura di progetto Per dimostrare l'utilizzo degli allegati di lavoro e dei profili di archiviazione, configura un ambiente di test con due progetti separati. Puoi utilizzare la console Deadline Cloud per creare le risorse di test. 1. Se non l'hai già fatto, crea una test farm. Per creare una fattoria, segui la procedura descritta in [Creare una fattoria](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html). 1. Crea due code per i lavori in ciascuno dei due progetti. Per creare code, segui la procedura riportata in [Creare una](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html) coda. 1. Crea la prima coda chiamata. **Q1** Usa la seguente configurazione, usa i valori predefiniti per tutti gli altri elementi. + Per gli allegati dei lavori, scegli **Crea un nuovo bucket Amazon S3**. + Seleziona **Abilita l'associazione con** flotte gestite dal cliente. + Per eseguire come utente, inserisci sia l'utente che **jobuser** il gruppo POSIX. + Per il ruolo del servizio di coda, create un nuovo ruolo denominato **AssetDemoFarm-Q1-Role** + Deseleziona la casella di controllo predefinita dell'ambiente di coda conda. 1. Crea la seconda coda chiamata. **Q2** Usa la seguente configurazione, usa i valori predefiniti per tutti gli altri elementi. + Per gli allegati dei lavori, scegli **Crea un nuovo bucket Amazon S3**. + Seleziona **Abilita l'associazione con** flotte gestite dal cliente. + Per eseguire come utente, inserisci sia l'utente che **jobuser** il gruppo POSIX. + Per il ruolo del servizio di coda, create un nuovo ruolo denominato **AssetDemoFarm-Q2-Role** + Deseleziona la casella di controllo predefinita dell'ambiente di coda conda. 1. Crea un'unica flotta gestita dal cliente che esegua i lavori da entrambe le code. Per creare il parco veicoli, segui la procedura riportata in [Creare un](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html) parco veicoli gestito dal cliente. Utilizza la seguente configurazione: + Per **Nome**, usa**DemoFleet**. + Per il **tipo di flotta** scegli **Customer managed** + Per il **ruolo Fleet Service**, crea un nuovo ruolo denominato **AssetDemoFarm-Fleet-Role**. + Non associate la flotta a nessuna coda. L'ambiente di test presuppone che vi siano tre file system condivisi tra host che utilizzano condivisioni di file di rete. In questo esempio, le posizioni hanno i seguenti nomi: + `FSCommon`- contiene risorse lavorative di input comuni a entrambi i progetti. + `FS1`- contiene risorse lavorative di input e output per il progetto 1. + `FS2`- contiene risorse lavorative di input e output per il progetto 2. L'ambiente di test presuppone inoltre che vi siano tre workstation, come segue: + `WSAll`- Una workstation Linux basata sugli sviluppatori utilizzata dagli sviluppatori per tutti i progetti. Le posizioni dei file system condivisi sono: + `FSCommon`: `/shared/common` + `FS1`: `/shared/projects/project1` + `FS2`: `/shared/projects/project2` + `WS1`- Una workstation Windows basata sul progetto 1. Le posizioni dei file system condivisi sono: + `FSCommon`: `S:\` + `FS1`: `Z:\` + `FS2`: non disponibile + `WS1`- Una workstation macOS basata sul progetto 2. Le posizioni condivise del file system sono: + `FSCommon`: `/Volumes/common` + `FS1`: Non disponibile + `FS2`: `/Volumes/projects/project2` Infine, definisci le posizioni dei file system condivise per i lavoratori della tua flotta. Gli esempi che seguono si riferiscono a questa configurazione come`WorkerConfig`. Le posizioni condivise sono: + `FSCommon`: `/mnt/common` + `FS1`: `/mnt/projects/project1` + `FS2`: `/mnt/projects/project2` Non è necessario configurare file system, workstation o worker condivisi che corrispondano a questa configurazione. Non è necessario che le posizioni condivise esistano per la dimostrazione. # Profili di archiviazione e mappatura dei percorsi Utilizza i profili di storage per modellare i file system sulla workstation e sugli host dei lavoratori. Ogni profilo di storage descrive il sistema operativo e il layout del file system di una delle configurazioni di sistema. Questo argomento descrive come utilizzare i profili di archiviazione per modellare le configurazioni del file system degli host in modo che Deadline Cloud possa generare regole di mappatura dei percorsi per i tuoi lavori e come tali regole di mappatura dei percorsi vengono generate dai tuoi profili di archiviazione. Quando invii un lavoro a Deadline Cloud, puoi fornire un ID del profilo di archiviazione opzionale per il lavoro. Questo profilo di archiviazione descrive il file system della workstation di invio. Descrive la configurazione originale del file system utilizzata dai percorsi dei file nel modello di lavoro. È inoltre possibile associare un profilo di archiviazione a una flotta. Il profilo di storage descrive la configurazione del file system di tutti gli host di lavoro del parco macchine. Se si dispone di lavoratori con una configurazione del file system diversa, tali lavoratori devono essere assegnati a una flotta diversa nella fattoria. Le regole di mappatura dei percorsi descrivono come i percorsi devono essere rimappati dal modo in cui sono specificati nel lavoro alla posizione effettiva del percorso su un host di lavoro. Deadline Cloud confronta la configurazione del file system descritta nel profilo di archiviazione di un lavoro con il profilo di archiviazione del parco macchine che esegue il lavoro per ricavare queste regole di mappatura dei percorsi. **Topics** + [Modella le posizioni dei file system condivise con profili di archiviazione](modeling-your-shared-filesystem-locations-with-storage-profiles.md) + [Configura i profili di archiviazione per le flotte](configuring-storage-profiles-for-fleets.md) + [Configura i profili di archiviazione per le code](storage-profiles-for-queues.md) + [Deriva le regole di mappatura dei percorsi dai profili di archiviazione](deriving-path-mapping-rules-from-storage-profiles.md) # Modella le posizioni dei file system condivise con profili di archiviazione Un profilo di storage modella la configurazione del file system di una delle configurazioni host. Nell'infrastruttura del [progetto di esempio]() sono disponibili quattro diverse configurazioni host. In questo esempio si crea un profilo di archiviazione separato per ciascuna di esse. È possibile creare un profilo di archiviazione utilizzando uno dei seguenti metodi: + [CreateStorageProfile API](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateStorageProfile.html) + [AWS::Deadline::StorageProfile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-deadline-storageprofile.html) CloudFormation risorsa + [Console AWS](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html#storage-profile) Un profilo di archiviazione è costituito da un elenco di posizioni del file system, ciascuna delle quali indica a Deadline Cloud la posizione e il tipo di posizione del file system rilevante per i lavori inviati o eseguiti su un host. Un profilo di archiviazione deve modellare solo le posizioni pertinenti per i lavori. Ad esempio, la `FSCommon` posizione condivisa si trova sulla workstation `WS1` presso`S:\`, quindi la posizione del file system corrispondente è: ``` { "name": "FSCommon", "path": "S:\\", "type": "SHARED" } ``` Utilizzate i seguenti comandi per creare il profilo di archiviazione per le configurazioni `WS1` della workstation `WS3` e la configurazione del worker `WorkerConfig` utilizzando in: `WS2` [AWS CLI[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WSAll \ --os-family LINUX \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"/shared/common"}, {"name": "FS1", "type":"SHARED", "path":"/shared/projects/project1"}, {"name": "FS2", "type":"SHARED", "path":"/shared/projects/project2"} ]' aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WS1 \ --os-family WINDOWS \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"S:\\"}, {"name": "FS1", "type":"SHARED", "path":"Z:\\"} ]' aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WS2 \ --os-family MACOS \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"/Volumes/common"}, {"name": "FS2", "type":"SHARED", "path":"/Volumes/projects/project2"} ]' aws deadline create-storage-profile --farm-id $FARM_ID \ --display-name WorkerCfg \ --os-family LINUX \ --file-system-locations \ '[ {"name": "FSCommon", "type":"SHARED", "path":"/mnt/common"}, {"name": "FS1", "type":"SHARED", "path":"/mnt/projects/project1"}, {"name": "FS2", "type":"SHARED", "path":"/mnt/projects/project2"} ]' ``` **Nota** È necessario fare riferimento alle posizioni del file system nei profili di archiviazione utilizzando gli stessi valori per la `name` proprietà in tutti i profili di archiviazione della farm. Deadline Cloud confronta i nomi per determinare che le posizioni dei file system di diversi profili di archiviazione si riferiscono alla stessa posizione durante la generazione delle regole di mappatura dei percorsi. # Configura i profili di archiviazione per le flotte È possibile configurare una flotta per includere un profilo di archiviazione che modelli le posizioni dei file system su tutti i lavoratori del parco macchine. La configurazione del file system host di tutti i lavoratori di una flotta deve corrispondere al profilo di storage della flotta. I lavoratori con configurazioni di file system diverse devono appartenere a flotte separate. Per impostare la configurazione della flotta in modo da utilizzare il profilo `WorkerConfig` di archiviazione, utilizza in: [AWS CLI[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of FLEET_ID to your fleet's identifier FLEET_ID=fleet-00112233445566778899aabbccddeeff # Change the value of WORKER_CFG_ID to your storage profile named WorkerConfig WORKER_CFG_ID=sp-00112233445566778899aabbccddeeff FLEET_WORKER_MODE=$( \ aws deadline get-fleet --farm-id $FARM_ID --fleet-id $FLEET_ID \ --query '.configuration.customerManaged.mode' \ ) FLEET_WORKER_CAPABILITIES=$( \ aws deadline get-fleet --farm-id $FARM_ID --fleet-id $FLEET_ID \ --query '.configuration.customerManaged.workerCapabilities' \ ) aws deadline update-fleet --farm-id $FARM_ID --fleet-id $FLEET_ID \ --configuration \ "{ \"customerManaged\": { \"storageProfileId\": \"$WORKER_CFG_ID\", \"mode\": $FLEET_WORKER_MODE, \"workerCapabilities\": $FLEET_WORKER_CAPABILITIES } }" ``` # Configura i profili di archiviazione per le code La configurazione di una coda include un elenco di nomi con distinzione tra maiuscole e minuscole delle posizioni condivise del file system a cui i lavori inviati alla coda richiedono l'accesso. Ad esempio, i lavori inviati alla coda `Q1` richiedono posizioni del file system e. `FSCommon` `FS1` I lavori inviati alla coda `Q2` richiedono posizioni del file system e. `FSCommon` `FS2` Per impostare le configurazioni della coda in modo che richiedano queste posizioni del file system, utilizzate lo script seguente: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of QUEUE2_ID to queue Q2's identifier QUEUE2_ID=queue-00112233445566778899aabbccddeeff aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --required-file-system-location-names-to-add FSComm FS1 aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \ --required-file-system-location-names-to-add FSComm FS2 ``` La configurazione di una coda include anche un elenco di profili di archiviazione consentiti che si applica ai lavori inviati e alle flotte associate a tale coda. Nell'elenco dei profili di archiviazione consentiti della coda sono consentiti solo i profili di archiviazione che definiscono le posizioni del file system per tutte le posizioni del file system richieste per la coda. Un processo ha esito negativo se lo si invia con un profilo di archiviazione non presente nell'elenco dei profili di archiviazione consentiti per la coda. Puoi sempre inviare un lavoro senza profilo di archiviazione a una coda. Le configurazioni delle workstation sono etichettate `WSAll` ed `WS1` entrambe hanno le posizioni del file system richieste (`FSCommon`e`FS1`) per la coda. `Q1` Devono essere autorizzati a inviare lavori alla coda. Allo stesso modo, le configurazioni delle workstation `WS2` soddisfano `WSAll` i requisiti per la coda. `Q2` Devono essere autorizzati a inviare lavori a quella coda. Aggiorna entrambe le configurazioni di coda per consentire l'invio dei lavori con questi profili di archiviazione utilizzando lo script seguente: ``` # Change the value of WSALL_ID to the identifier of the WSAll storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff # Change the value of WS1 to the identifier of the WS1 storage profile WS1_ID=sp-00112233445566778899aabbccddeeff # Change the value of WS2 to the identifier of the WS2 storage profile WS2_ID=sp-00112233445566778899aabbccddeeff aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --allowed-storage-profile-ids-to-add $WSALL_ID $WS1_ID aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \ --allowed-storage-profile-ids-to-add $WSALL_ID $WS2_ID ``` Se si aggiunge il profilo `WS2` di archiviazione all'elenco dei profili di archiviazione consentiti per la coda`Q1`, l'operazione fallisce: ``` $ aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --allowed-storage-profile-ids-to-add $WS2_ID An error occurred (ValidationException) when calling the UpdateQueue operation: Storage profile id: sp-00112233445566778899aabbccddeeff does not have required file system location: FS1 ``` Questo perché il profilo `WS2` di archiviazione non contiene una definizione per la posizione del file system denominata richiesta dalla `FS1` coda`Q1`. Anche l'associazione di una flotta configurata con un profilo di archiviazione non presente nell'elenco dei profili di archiviazione consentiti della coda non riesce. Esempio: ``` $ aws deadline create-queue-fleet-association --farm-id $FARM_ID \ --fleet-id $FLEET_ID \ --queue-id $QUEUE1_ID An error occurred (ValidationException) when calling the CreateQueueFleetAssociation operation: Mismatch between storage profile ids. ``` Per correggere l'errore, aggiungi il profilo di archiviazione denominato `WorkerConfig` all'elenco dei profili di archiviazione consentiti sia per la coda che per la coda`Q1`. `Q2` Quindi, associa la flotta a queste code in modo che i lavoratori del parco macchine possano eseguire i lavori da entrambe le code. ``` # Change the value of FLEET_ID to your fleet's identifier FLEET_ID=fleet-00112233445566778899aabbccddeeff # Change the value of WORKER_CFG_ID to your storage profile named WorkerCfg WORKER_CFG_ID=sp-00112233445566778899aabbccddeeff aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --allowed-storage-profile-ids-to-add $WORKER_CFG_ID aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \ --allowed-storage-profile-ids-to-add $WORKER_CFG_ID aws deadline create-queue-fleet-association --farm-id $FARM_ID \ --fleet-id $FLEET_ID \ --queue-id $QUEUE1_ID aws deadline create-queue-fleet-association --farm-id $FARM_ID \ --fleet-id $FLEET_ID \ --queue-id $QUEUE2_ID ``` # Deriva le regole di mappatura dei percorsi dai profili di archiviazione Le regole di mappatura dei percorsi descrivono come devono essere rimappati i percorsi dal lavoro alla posizione effettiva del percorso su un host di lavoro. Quando un'attività è in esecuzione su un lavoratore, il profilo di archiviazione del lavoro viene confrontato con il profilo di archiviazione del parco macchine del lavoratore per ricavare le regole di mappatura dei percorsi per l'attività. Deadline Cloud crea una regola di mappatura per ciascuna delle posizioni del file system richieste nella configurazione della coda. Ad esempio, un lavoro inviato con il profilo di `WSAll` archiviazione da mettere in coda `Q1` ha le seguenti regole di mappatura dei percorsi: + `FSComm`: `/shared/common -> /mnt/common` + `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` Deadline Cloud crea regole per le posizioni del `FS1` file system `FSComm` and, ma non per la posizione del `FS2` file system, anche se definite sia dal profilo che dal `WSAll` profilo `WorkerConfig` di archiviazione. `FS2` Questo perché l'elenco delle posizioni richieste `Q1` del file system di queue è. `["FSComm", "FS1"]` È possibile confermare le regole di mappatura dei percorsi disponibili per i lavori inviati con un particolare profilo di archiviazione inviando un lavoro che stampi il [file delle regole di mappatura dei percorsi di Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping) e quindi leggendo il registro della sessione dopo il completamento del lavoro: ``` # Change the value of FARM_ID to your farm's identifier FARM_ID=farm-00112233445566778899aabbccddeeff # Change the value of QUEUE1_ID to queue Q1's identifier QUEUE1_ID=queue-00112233445566778899aabbccddeeff # Change the value of WSALL_ID to the identifier of the WSALL storage profile WSALL_ID=sp-00112233445566778899aabbccddeeff aws deadline create-job --farm-id $FARM_ID --queue-id $QUEUE1_ID \ --priority 50 \ --storage-profile-id $WSALL_ID \ --template-type JSON --template \ '{ "specificationVersion": "jobtemplate-2023-09", "name": "DemoPathMapping", "steps": [ { "name": "ShowPathMappingRules", "script": { "actions": { "onRun": { "command": "/bin/cat", "args": [ "{{Session.PathMappingRulesFile}}" ] } } } } ] }' ``` Se utilizzi la [CLI di Deadline Cloud](https://pypi.org/project/deadline/) per inviare lavori, la relativa impostazione di `settings.storage_profile_id` configurazione imposta il profilo di archiviazione che avranno i lavori inviati con la CLI. Per inviare lavori con il profilo di `WSAll` archiviazione, imposta: ``` deadline config set settings.storage_profile_id $WSALL_ID ``` Per gestire un worker gestito dal cliente come se fosse in esecuzione nell'infrastruttura di esempio, segui la procedura descritta in [Esegui il worker agent](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/run-worker.html) nella *Deadline Cloud User Guide* to run a worker with. AWS CloudShell Se hai già seguito queste istruzioni, elimina prima le directory `~/demoenv-logs` and`~/demoenv-persist`. Inoltre, prima di procedere, impostate i valori delle variabili `DEV_FARM_ID` e di `DEV_CMF_ID` ambiente a cui fanno riferimento le direzioni come segue: ``` DEV_FARM_ID=$FARM_ID DEV_CMF_ID=$FLEET_ID ``` Dopo l'esecuzione del processo, puoi visualizzare le regole di mappatura dei percorsi nel file di registro del processo: ``` cat demoenv-logs/${QUEUE1_ID}/*.log ... JJSON log results (see below) ... ``` Il registro contiene la mappatura sia per il file system che per quello `FS1` dei `FSComm` file. Riformattata per motivi di leggibilità, la voce di registro ha il seguente aspetto: ``` { "version": "pathmapping-1.0", "path_mapping_rules": [ { "source_path_format": "POSIX", "source_path": "/shared/projects/project1", "destination_path": "/mnt/projects/project1" }, { "source_path_format": "POSIX", "source_path": "/shared/common", "destination_path": "/mnt/common" } ] ``` Puoi inviare lavori con diversi profili di archiviazione per vedere come cambiano le regole di mappatura dei percorsi. # Usa gli allegati del lavoro per condividere file 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 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 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///Inputs//a1d221c7fd97b08175b3872a37428e8c_input`— L'oggetto manifesto per l'invio del lavoro. I valori ````, e `` 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/`. 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": "//Inputs//a1d221c7fd97b08175b3872a37428e8c_input", "rootPath": "/home/cloudshell-user/job_attachments_devguide", "rootPathFormat": "posix" } ] }, ... } ``` # In che modo Deadline Cloud sceglie i file da caricare 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 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 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 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 ``` # Creare limiti di risorse per i lavori I lavori inviati a Deadline Cloud possono dipendere da risorse condivise tra più lavori. Ad esempio, un'azienda agricola può avere più lavoratori rispetto alle licenze fluttuanti per una risorsa specifica. Oppure un file server condiviso può essere in grado di fornire dati solo a un numero limitato di lavoratori contemporaneamente. In alcuni casi, uno o più lavori possono richiedere tutte queste risorse, causando errori dovuti alla mancanza di risorse all'ingresso di nuovi lavoratori. Per risolvere questo problema, puoi utilizzare *dei limiti* per queste risorse limitate. Deadline Cloud tiene conto della disponibilità di risorse limitate e utilizza tali informazioni per garantire che le risorse siano disponibili all'avvio dei nuovi dipendenti, in modo che i lavori abbiano una minore probabilità di fallire a causa della mancanza di risorse. I limiti vengono creati per l'intera azienda agricola. I lavori inviati a una coda possono acquisire solo i limiti associati alla coda. Se si specifica un limite per un lavoro non associato alla coda, il lavoro non è compatibile e non verrà eseguito. Per utilizzare un limite, devi + [Crea un limite](job-limit-create.md) + [Associa un limite e una coda](job-limit-associate.md) + [Invia un lavoro che richiede dei limiti](job-limit-job.md) **Nota** Se si esegue un processo con risorse limitate in una coda non associata a un limite, tale processo può consumare tutte le risorse. Se disponi di una risorsa limitata, assicurati che tutti i passaggi dei lavori nelle code che utilizzano la risorsa siano associati a un limite. Per i limiti definiti in una farm, associati a una coda e specificati in un lavoro, può succedere una delle quattro cose seguenti: + Se si crea un limite, lo si associa a una coda e si specifica il limite nel modello di un lavoro, il processo viene eseguito e utilizza solo le risorse definite nel limite. + Se si crea un limite, lo si specifica in un modello di processo, ma non si associa il limite a una coda, il processo viene contrassegnato come incompatibile e non verrà eseguito. + Se si crea un limite, non lo si associa a una coda e non si specifica il limite nel modello di un processo, il processo viene eseguito ma non utilizza il limite. + Se non si utilizza affatto un limite, il processo viene eseguito. Se si associa un limite a più code, le code condividono le risorse vincolate dal limite. Ad esempio, se si crea un limite di 100 e una coda utilizza 60 risorse, le altre code possono utilizzare solo 40 risorse. Quando una risorsa viene rilasciata, può essere utilizzata da un'operazione da qualsiasi coda. Deadline Cloud fornisce due AWS CloudFormation metriche per aiutarti a monitorare le risorse fornite da un limite. Puoi monitorare il numero attuale di risorse in uso e il numero massimo di risorse disponibili entro il limite. Per ulteriori informazioni, consulta le [metriche relative al limite delle risorse](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits) nella *Deadline Cloud Developer Guide*. Applichi un limite a una fase di lavoro in un modello di lavoro. Quando si specifica la quantità, il nome del requisito di un limite nella `amounts` sezione `hostRequirements` di una fase e un limite corrispondente `amountRequirementName` viene associato alla coda del lavoro, le attività pianificate per questa fase sono vincolate dal limite della risorsa. Se una fase richiede una risorsa limitata da un limite raggiunto, le attività di quella fase non verranno raccolte da altri lavoratori. È possibile applicare più di un limite a una fase di lavoro. Ad esempio, se la fase utilizza due licenze software diverse, è possibile applicare un limite separato per ciascuna licenza. Se una fase richiede due limiti e viene raggiunto il limite per una delle risorse, le attività di quella fase non verranno acquisite da altri lavoratori finché le risorse non saranno disponibili. ## Interruzione ed eliminazione dei limiti Quando si interrompe o si elimina l'associazione tra una coda e un limite, un job che utilizza il limite interrompe la pianificazione delle attività relative ai passaggi che richiedono tale limite e blocca la creazione di nuove sessioni per un passaggio. Le attività che si trovano nello stato READY rimangono pronte e le attività riprendono automaticamente quando l'associazione tra la coda e il limite diventa nuovamente attiva. Non è necessario richiedere alcun lavoro. Quando interrompi o elimini l'associazione tra una coda e un limite, hai due scelte su come interrompere l'esecuzione delle attività: + Interrompi e annulla le attività: i lavoratori con sessioni che hanno raggiunto il limite annullano tutte le attività. + Interrompi e termina le attività in esecuzione: i lavoratori con sessioni che hanno raggiunto il limite completano le proprie attività. Quando si elimina un limite utilizzando la console, i lavoratori interrompono innanzitutto l'esecuzione delle attività immediatamente o alla fine una volta completate. Quando l'associazione viene eliminata, accade quanto segue: + Le fasi che richiedono il limite sono contrassegnate come non compatibili. + L'intero processo contenente tali passaggi viene annullato, compresi i passaggi che non richiedono il limite. + Il lavoro è contrassegnato come non compatibile. Se alla coda associata al limite è associata una flotta con una capacità corrispondente all'importo richiesto (nome del limite), tale flotta continuerà a elaborare i lavori con il limite specificato. # Crea un limite Puoi creare un limite utilizzando la console Deadline Cloud o l'[CreateLimit operazione nell'API Deadline](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html) Cloud. I limiti sono definiti per una fattoria, ma associati alle code. Dopo aver creato un limite, è possibile associarlo a una o più code. **Per creare un limite** 1. Dalla dashboard della console Deadline Cloud ([console Deadline Cloud](https://console.aws.amazon.com/deadlinecloud/home)), seleziona la farm per cui desideri creare una coda. 1. **Scegli la farm a cui aggiungere il limite, scegli la scheda **Limiti**, quindi scegli Crea limite.** 1. Fornisci i dettagli del limite. Il **nome del requisito di importo** è il nome utilizzato nel modello di lavoro per identificare il limite. Deve iniziare con il prefisso **amount.** seguito dal nome dell'importo. Il nome del requisito relativo all'importo deve essere univoco nelle code associate al limite. 1. Se scegli **Imposta un importo massimo**, questo è il numero totale di risorse consentite da questo limite. Se scegli **Nessun importo massimo, l'**utilizzo delle risorse non è limitato. Anche quando l'utilizzo delle risorse non è limitato, viene emessa la CloudWatch metrica `CurrentCount` Amazon in modo da poter monitorare l'utilizzo. Per ulteriori informazioni, consulta le [CloudWatchmetriche](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html) nella *Deadline* Cloud Developer Guide. 1. Se conosci già le code che devono utilizzare il limite, puoi sceglierle ora. Non è necessario associare una coda per creare un limite. 1. Scegli **Crea limite**. # Associa un limite e una coda Dopo aver creato un limite, puoi associare una o più code al limite. Solo le code associate a un limite utilizzano i valori specificati nel limite. Si crea un'associazione con una coda utilizzando la console Deadline Cloud o l'[CreateQueueLimitAssociation operazione nell'API Deadline](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html) Cloud. **Per associare una coda a un limite** 1. Dalla dashboard della console Deadline Cloud ([console Deadline Cloud](https://console.aws.amazon.com/deadlinecloud/home)), seleziona la farm in cui desideri associare un limite a una coda. 1. **Scegli la scheda **Limiti**, scegli il limite a cui associare una coda, quindi scegli Modifica limite.** 1. Nella sezione **Associa code**, scegli le code da associare al limite. 1. Scegli **Save changes** (Salva modifiche). # Invia un lavoro che richiede dei limiti Puoi applicare un limite specificandolo come requisito dell'host per il lavoro o la fase del lavoro. Se non si specifica un limite in una fase e tale fase utilizza una risorsa associata, l'utilizzo della fase non viene conteggiato nel limite quando i lavori sono pianificati. Alcuni mittenti di Deadline Cloud ti consentono di impostare un requisito di host. Puoi specificare il nome del requisito relativo all'importo del limite nel mittente per applicare il limite. Se il mittente non supporta l'aggiunta dei requisiti dell'host, puoi anche applicare un limite modificando il modello di lavoro relativo al lavoro. **Per applicare un limite a una fase di lavoro nel pacchetto di lavoro** 1. Apri il modello di lavoro per il lavoro utilizzando un editor di testo. Il modello di lavoro si trova nella directory dei pacchetti di lavoro relativa al lavoro. Per ulteriori informazioni, consulta [Job bundles](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/build-job-bundle.html) nella *Deadline Cloud Developer Guide*. 1. Trova la definizione della fase a cui applicare il limite. 1. Aggiungi quanto segue alla definizione del passo. *amount.name*Sostituiscilo con il nome del requisito relativo all'importo del limite. Per un utilizzo tipico, è necessario impostare il `min` valore su 1. ------ #### [ YAML ] ``` hostRequirements: amounts: - name: amount.name min: 1 ``` ------ #### [ JSON ] ``` "hostRequirements": { "amounts": [ { "name": "amount.name", "min": "1" } } } ``` ------ È possibile aggiungere più limiti a una fase di lavoro come segue. Sostituisci *amount.name\$11* e *amount.name\$12* inserisci i nomi dei requisiti relativi agli importi indicati nei tuoi limiti. ------ #### [ YAML ] ``` hostRequirements: amounts: - name: amount.name_1 min: 1 - name: amount.name_2 min: 1 ``` ------ #### [ JSON ] ``` "hostRequirements": { "amounts": [ { "name": "amount.name_1", "min": "1" }, { "name": "amount.name_2", "min": "1" } } } ``` ------ 1. Salva le modifiche al modello di lavoro. # Come inviare un'offerta di lavoro a Deadline Cloud Esistono molti modi diversi per inviare offerte di lavoro a AWS Deadline Cloud. Questa sezione descrive alcuni dei modi in cui puoi inviare lavori utilizzando gli strumenti forniti da Deadline Cloud o creando strumenti personalizzati per i tuoi carichi di lavoro. + Da un terminale, per quando stai sviluppando per la prima volta un pacchetto di lavori o quando gli utenti che inviano un lavoro si sentono a proprio agio utilizzando la riga di comando + Da uno script: per personalizzare e automatizzare i carichi di lavoro + Da un'applicazione: per quando il lavoro dell'utente è in un'applicazione o quando il contesto di un'applicazione è importante. I seguenti esempi utilizzano la libreria `deadline` Python e lo strumento da `deadline` riga di comando. Entrambi sono disponibili [PyPi](https://pypi.org/project/deadline/)e [ospitati su. GitHub](https://github.com/aws-deadline/deadline-cloud) **Topics** + [Invia un lavoro a Deadline Cloud da un terminale](from-a-terminal.md) + [Invia un lavoro a Deadline Cloud utilizzando uno script](from-a-script.md) + [Invia un'offerta di lavoro all'interno di una candidatura](from-within-applications.md) # Invia un lavoro a Deadline Cloud da un terminale Utilizzando solo un job bundle e la CLI di Deadline Cloud, tu o i tuoi utenti più tecnici potete iniziare rapidamente a scrivere pacchetti di lavoro per testare l'invio di un lavoro. Usa il seguente comando per inviare un job bundle: ``` deadline bundle submit ``` Se invii un job bundle con parametri che non hanno valori predefiniti nel bundle, puoi specificarli con l'opzione/. `-p` `--parameter` ``` deadline bundle submit -p = -p ... ``` Per un elenco completo delle opzioni disponibili, esegui il comando help: ``` deadline bundle submit --help ``` ## Invia un lavoro a Deadline Cloud utilizzando una GUI La CLI di Deadline Cloud è inoltre dotata di un'interfaccia utente grafica che consente agli utenti di visualizzare i parametri che devono fornire prima di inviare un lavoro. Se i tuoi utenti preferiscono non interagire con la riga di comando, puoi scrivere una scorciatoia sul desktop che apra una finestra di dialogo per inviare un pacchetto di lavori specifico: ``` deadline bundle gui-submit ``` Utilizza l'`--browse`opzione can in modo che l'utente possa selezionare un pacchetto di lavori: ``` deadline bundle gui-submit --browse ``` Per un elenco completo delle opzioni disponibili, esegui il comando help: ``` deadline bundle gui-submit --help ``` # Invia un lavoro a Deadline Cloud utilizzando uno script Per automatizzare l'invio di lavori a Deadline Cloud, puoi creare script utilizzando strumenti come bash, Powershell e file batch. È possibile aggiungere funzionalità come la compilazione dei parametri del lavoro da variabili di ambiente o altre applicazioni. Puoi anche inviare più lavori di seguito o creare uno script per la creazione di un pacchetto di lavori da inviare. ## Invia un lavoro usando Python Deadline Cloud dispone anche di una libreria Python open source per interagire con il servizio. Il [codice sorgente è disponibile](https://github.com/aws-deadline/deadline-cloud) su. GitHub La libreria è disponibile su pypi tramite pip ()`pip install deadline`. È la stessa libreria utilizzata dallo strumento CLI Deadline Cloud: ``` from deadline.client import api job_bundle_path = "/path/to/job/bundle" job_parameters = [ { "name": "parameter_name", "value": "parameter_value" }, ] job_id = api.create_job_from_job_bundle( job_bundle_path, job_parameters ) print(job_id) ``` [Per creare una finestra di dialogo come il `deadline bundle gui-submit` comando, puoi usare `show_job_bundle_submitter` la funzione di. `deadline.client.ui.job_bundle_submitter`](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/job_bundle_submitter.py) L'esempio seguente avvia un'applicazione Qt e mostra il job bundle submitter: ``` # The GUI components must be installed with pip install "deadline[gui]" import sys from qtpy.QtWidgets import QApplication from deadline.client.ui.job_bundle_submitter import show_job_bundle_submitter app = QApplication(sys.argv) submitter = show_job_bundle_submitter(browse=True) submitter.show() app.exec() print(submitter.create_job_response) ``` Per creare la tua finestra di dialogo puoi usare la `SubmitJobToDeadlineDialog` classe in. [https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/dialogs/submit_job_to_deadline_dialog.py](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/dialogs/submit_job_to_deadline_dialog.py) Puoi trasmettere valori, incorporare la tua scheda specifica del lavoro e determinare come il job bundle viene creato (o passato). # Invia un'offerta di lavoro all'interno di una candidatura Per facilitare l'invio dei lavori da parte degli utenti, è possibile utilizzare i runtime di script o i sistemi di plug-in forniti da un'applicazione. Gli utenti dispongono di un'interfaccia familiare ed è possibile creare potenti strumenti che assistono gli utenti nell'invio di un carico di lavoro. ## Incorpora pacchetti di lavoro in un'applicazione Questo esempio dimostra l'invio di pacchetti di lavoro che rendi disponibili nell'applicazione. Per consentire a un utente di accedere a questi pacchetti di lavoro, crea uno script incorporato in una voce di menu che avvia la CLI di Deadline Cloud. Lo script seguente consente a un utente di selezionare il job bundle: ``` deadline bundle gui-submit --install-gui ``` Per utilizzare invece un job bundle specifico in una voce di menu, utilizzate quanto segue: ``` deadline bundle gui-submit --install-gui ``` Si apre una finestra di dialogo in cui l'utente può modificare i parametri, gli input e gli output del lavoro e quindi inviare il lavoro. È possibile avere diverse voci di menu per diversi pacchetti di lavoro che un utente può inviare in una candidatura. Se il lavoro che invii con un pacchetto di offerte di lavoro contiene parametri e riferimenti alle risorse simili tra gli invii, puoi inserire i valori predefiniti nel pacchetto di lavoro sottostante. ## Ottieni informazioni da una candidatura Per estrarre informazioni da un'applicazione in modo che gli utenti non debbano aggiungerle manualmente all'invio, puoi integrare Deadline Cloud con l'applicazione in modo che gli utenti possano inviare lavori utilizzando un'interfaccia familiare senza dover uscire dall'applicazione o utilizzare strumenti da riga di comando. Se la tua applicazione ha un runtime di scripting che supporta Python e pyside/pyqt, puoi utilizzare i componenti della GUI dalla libreria client [Deadline](https://github.com/aws-deadline/deadline-cloud) Cloud per creare un'interfaccia utente. [Per un esempio, consulta l'integrazione di Deadline Cloud for Maya su.](https://github.com/aws-deadline/deadline-cloud-for-maya) GitHub La libreria client Deadline Cloud fornisce operazioni che eseguono le seguenti operazioni per aiutarti a fornire un'esperienza utente solida e integrata: + Recupera i parametri di ambiente della coda, i parametri di lavoro e i riferimenti agli asset dalle variabili di ambiente e chiamando l'SDK dell'applicazione. + Imposta i parametri nel job bundle. Per evitare di modificare il pacchetto originale, è necessario creare una copia del pacchetto e inviare la copia. Se si utilizza il `deadline bundle gui-submit` comando per inviare il job bundle, è necessario digitare programmaticamente `asset_references.yaml` i file `parameter_values.yaml` and per passare le informazioni dall'applicazione. Per ulteriori informazioni su questi file, vedere. [Modelli Open Job Description (OpenJD) per Deadline Cloud](build-job-bundle.md) Se hai bisogno di controlli più complessi di quelli offerti da OpenJD, hai bisogno di astrarre il lavoro dall'utente o vuoi fare in modo che l'integrazione corrisponda allo stile visivo dell'applicazione, puoi scrivere la tua finestra di dialogo che richiami la libreria client di Deadline Cloud per inviare il lavoro. # Pianifica lavori in Deadline Cloud Dopo aver creato un lavoro, AWS Deadline Cloud ne pianifica l'elaborazione su una o più flotte associate a una coda. La flotta che elabora una particolare attività viene scelta in base alle funzionalità configurate per la flotta e ai requisiti dell'host di una fase specifica. I lavori in coda sono programmati in base all'ordine di priorità più elevato, dal più alto al più basso. Quando due lavori hanno la stessa priorità, il lavoro più vecchio viene pianificato per primo. Le seguenti sezioni forniscono dettagli sul processo di pianificazione di un lavoro. ## Determina la compatibilità della flotta Dopo la creazione di un lavoro, Deadline Cloud verifica i requisiti dell'host per ogni fase del lavoro rispetto alle capacità delle flotte associate alla coda a cui è stato inviato il lavoro. Se una flotta soddisfa i requisiti dell'host, il lavoro viene assegnato allo stato. `READY` Se una fase del lavoro presenta requisiti che non possono essere soddisfatti da una flotta associata alla coda, lo stato della fase viene impostato `NOT_COMPATIBLE` su. Inoltre, gli altri passaggi del processo vengono annullati. Le capacità di una flotta sono impostate a livello di flotta. Anche se un lavoratore di una flotta soddisfa i requisiti del lavoro, non gli verranno assegnati compiti dal lavoro se la flotta non soddisfa i requisiti del lavoro. Il seguente modello di lavoro presenta una fase che specifica i requisiti dell'host per la fase: ``` name: Sample Job With Host Requirements specificationVersion: jobtemplate-2023-09 steps: - name: Step 1 script: actions: onRun: args: - '1' command: /usr/bin/sleep hostRequirements: amounts: # Capabilities starting with "amount." are amount capabilities. If they start with "amount.worker.", # they are defined by the OpenJD specification. Other names are free for custom usage. - name: amount.worker.vcpu min: 4 max: 8 attributes: - name: attr.worker.os.family anyOf: - linux ``` Questo lavoro può essere programmato per una flotta con le seguenti funzionalità: ``` { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } ``` Questo lavoro non può essere programmato per una flotta con nessuna delle seguenti funzionalità: ``` { "vCpuCount": {"min": 4}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } The vCpuCount has no maximum, so it exceeds the maximum vCPU host requirement. { "vCpuCount": {"max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } The vCpuCount has no minimum, so it doesn't satisfy the minimum vCPU host requirement. { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "windows", "cpuArchitectureType": "x86_64" } The osFamily doesn't match. ``` ## Scalabilità della flotta Quando un lavoro viene assegnato a una flotta compatibile gestita dai servizi, la flotta viene ridimensionata automaticamente. Il numero di lavoratori della flotta cambia in base al numero di attività disponibili per l'esecuzione della flotta. Quando un lavoro viene assegnato a una flotta gestita dal cliente, è possibile che i lavoratori esistano già o possano essere creati utilizzando la scalabilità automatica basata su eventi. Per ulteriori informazioni, consulta [Use EventBridge to handle auto scaling events](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) nella *Amazon EC2 Auto* Scaling User Guide. ## Sessioni Le attività di un job sono suddivise in una o più sessioni. I lavoratori eseguono le sessioni per configurare l'ambiente, eseguire le attività e quindi demolire l'ambiente. Ogni sessione è composta da una o più azioni che un lavoratore deve intraprendere. Quando un lavoratore completa le azioni della sezione, al lavoratore possono essere inviate azioni di sessione aggiuntive. Il lavoratore riutilizza gli ambienti e gli allegati di lavoro esistenti nella sessione per completare le attività in modo più efficiente. Sui lavoratori della flotta gestiti dal servizio, le directory delle sessioni vengono eliminate al termine della sessione, ma le altre directory vengono conservate tra le sessioni. Questo comportamento consente di implementare strategie di memorizzazione nella cache per i dati che possono essere riutilizzati in più sessioni. Per memorizzare nella cache i dati tra le sessioni, memorizzali nella home directory dell'utente che esegue il processo. Ad esempio, i pacchetti conda vengono memorizzati nella cache nella home directory dell'utente del lavoro all'indirizzo `C:\Users\job-user\.conda-pkgs` on Windows workers e `/home/job-user/.conda-pkgs` on Linux workers. Questi dati rimangono disponibili fino alla chiusura del lavoratore. Gli allegati di lavoro vengono creati dal mittente che utilizzi come parte del pacchetto di lavori CLI di Deadline Cloud. Puoi anche creare allegati di lavoro utilizzando l'opzione relativa al comando. `--attachments` `create-job` AWS CLI Gli ambienti sono definiti in due punti: ambienti di coda collegati a una coda specifica e ambienti di lavoro e fasi definiti nel modello di lavoro. Esistono quattro tipi di azioni di sessione: + `syncInputJobAttachments`— Scarica gli allegati del lavoro di input per il lavoratore. + `envEnter`— Esegue le `onEnter` azioni per un ambiente. + `taskRun`— Esegue le `onRun` azioni relative a un'attività. + `envExit`— Esegue le `onExit` azioni per un ambiente. Il seguente modello di lavoro ha un ambiente a fasi. Ha una `onEnter` definizione per configurare l'ambiente delle fasi, una `onRun` definizione che definisce l'attività da eseguire e una `onExit` definizione per eliminare l'ambiente delle fasi. Le sessioni create per questo lavoro includeranno un'`envEnter`azione, una o più `taskRun` azioni e quindi un'`envExit`azione. ``` name: Sample Job with Maya Environment specificationVersion: jobtemplate-2023-09 steps: - name: Maya Step stepEnvironments: - name: Maya description: Runs Maya in the background. script: embeddedFiles: - name: initData filename: init-data.yaml type: TEXT data: | scene_file: MyAwesomeSceneFile renderer: arnold camera: persp actions: onEnter: command: MayaAdaptor args: - daemon - start - --init-data - file://{{Env.File.initData}} onExit: command: MayaAdaptor args: - daemon - stop parameterSpace: taskParameterDefinitions: - name: Frame range: 1-5 type: INT script: embeddedFiles: - name: runData filename: run-data.yaml type: TEXT data: | frame: {{Task.Param.Frame}} actions: onRun: command: MayaAdaptor args: - daemon - run - --run-data - file://{{ Task.File.runData }} ``` ### Pipeline delle azioni della sessione La pipeline delle azioni di sessione consente a uno scheduler di preassegnare più azioni di sessione a un lavoratore. Il lavoratore può quindi eseguire queste azioni in sequenza, riducendo o eliminando i tempi di inattività tra le attività. Per creare un'assegnazione iniziale, lo scheduler crea una sessione con un'attività, il lavoratore completa l'attività e quindi lo scheduler analizza la durata dell'attività per determinare le assegnazioni future. Affinché lo scheduler sia efficace, esistono regole sulla durata delle attività. Per le attività di durata inferiore a un minuto, lo scheduler utilizza un modello di crescita power-of-2. Ad esempio, per un'attività di 1 secondo, lo scheduler assegna 2 nuove attività, quindi 4, quindi 8. Per le attività di durata superiore a un minuto, lo scheduler assegna solo una nuova attività e la pipelining rimane disabilitata. Per calcolare le dimensioni della pipeline, lo scheduler esegue le seguenti operazioni: + Utilizza la durata media delle attività completate + Mira a mantenere il lavoratore occupato per un minuto + Considera solo le attività all'interno della stessa sessione + Non condivide i dati sulla durata tra i lavoratori Grazie alla pipeline delle azioni di sessione, i lavoratori iniziano immediatamente nuove attività e non ci sono tempi di attesa tra le richieste dello scheduler. Fornisce inoltre una maggiore efficienza dei lavoratori e una migliore distribuzione delle attività per i processi a lunga durata. Inoltre, se è disponibile un nuovo lavoro con priorità più alta, il lavoratore terminerà tutto il lavoro precedentemente assegnato prima della fine della sessione corrente e prima che venga assegnata una nuova sessione da un lavoro con priorità più alta. ## Dipendenze tra fasi Deadline Cloud supporta la definizione delle dipendenze tra i passaggi in modo che un passaggio attenda il completamento di un altro passaggio prima di iniziare. Puoi definire più di una dipendenza per un passaggio. Un passaggio con una dipendenza non è pianificato fino al completamento di tutte le relative dipendenze. Se il modello di lavoro definisce una dipendenza circolare, il lavoro viene rifiutato e lo stato del processo viene impostato su. `CREATE_FAILED` Il seguente modello di lavoro crea un lavoro con due passaggi. `StepB`dipende da`StepA`. `StepB`viene eseguito solo dopo essere stato `StepA` completato con successo. Dopo la creazione del lavoro, `StepA` si trova nello `READY` stato e `StepB` si trova nello `PENDING` stato. Al `StepA` termine, `StepB` passa allo `READY` stato. Se `StepA` fallisce o se `StepA` viene annullato, `StepB` passa allo `CANCELED` stato. È possibile impostare una dipendenza su più passaggi. Ad esempio, `StepC` dipende da entrambi `StepA` e`StepB`, `StepC` non inizierà fino al termine degli altri due passaggi. Le dipendenze dei passaggi hanno le seguenti restrizioni: + **Dipendenze per fase**: una fase può dipendere da un massimo di 128 altre fasi. + **Consumatori per fase**: un massimo di altri 32 passaggi possono dipendere da un singolo passaggio. ``` name: Step-Step Dependency Test specificationVersion: 'jobtemplate-2023-09' steps: - name: A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task A Done! - name: B dependencies: - dependsOn: A # This means Step B depends on Step A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task B Done! ``` # Modifica un lavoro in Deadline Cloud Puoi utilizzare i seguenti `update` comandi AWS Command Line Interface (AWS CLI) per modificare la configurazione di un lavoro o per impostare lo stato di destinazione di un lavoro, un passaggio o un'attività: `` + `aws deadline update-job` + `aws deadline update-step` + `aws deadline update-task` Nei seguenti esempi di `update` comandi, sostituiteli *`user input placeholder`* con le vostre informazioni. **Example — Richiedere un lavoro** Tutte le attività del lavoro passano `READY` allo stato, a meno che non vi siano dipendenze tra fasi. I passaggi con dipendenze passano a uno o all'altro `READY` o `PENDING` man mano che vengono ripristinati. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status PENDING ``` **Example — Annullare un lavoro** Tutte le attività del lavoro che non hanno lo stato `SUCCEEDED` o `FAILED` sono contrassegnate`CANCELED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status CANCELED ``` **Example — Contrassegna un lavoro come non riuscito** Tutte le attività del lavoro che hanno lo stato `SUCCEEDED` rimangono invariate. Tutte le altre attività sono contrassegnate`FAILED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status FAILED ``` **Example — Contrassegna un lavoro riuscito** Tutte le attività lavorative vengono trasferite allo `SUCCEEDED` stato. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUCCEEDED ``` **Example — Sospendere un lavoro** Le attività del lavoro nello `SUCCEEDED` `FAILED` stato o non cambiano. `CANCELED` Tutte le altre attività sono contrassegnate`SUSPENDED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUSPENDED ``` **Example — Modificare la priorità di un lavoro** Aggiorna la priorità di un lavoro in coda per modificare l'ordine in cui è pianificato. I lavori con priorità più alta vengono generalmente pianificati per primi. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --priority 100 ``` **Example — Modificare il numero di attività non riuscite consentite** Aggiorna il numero massimo di attività non riuscite che il lavoro può avere prima che le attività rimanenti vengano annullate. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-failed-tasks-count 200 ``` **Example — Modifica il numero di tentativi consentiti per le nuove attività** Aggiorna il numero massimo di tentativi per un'attività prima che l'operazione abbia esito negativo. Un'attività che ha raggiunto il numero massimo di tentativi non può essere richiesta finché questo valore non viene aumentato. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-retries-per-task 10 ``` **Example — Archivia un lavoro** Aggiorna lo stato del ciclo di vita del lavoro su. `ARCHIVED` I lavori archiviati non possono essere pianificati o modificati. È possibile archiviare solo un lavoro che si trova nello `SUSPENDED` stato `FAILED``CANCELED`,`SUCCEEDED`, o. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --lifecycle-status ARCHIVED ``` **Example — Modificare il nome di un lavoro** Aggiorna il nome visualizzato di un lavoro. Il nome del lavoro può contenere fino a 128 caratteri. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --name "New Job Name" ``` **Example — Modificare la descrizione di un lavoro** Aggiorna la descrizione di un lavoro. La descrizione può contenere fino a 2048 caratteri. Per rimuovere la descrizione esistente, passa una stringa vuota. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --description "New Job Description" ``` **Example — Richiedi un passaggio** Tutte le attività della fase passano `READY` allo stato, a meno che non vi siano dipendenze tra fasi. Le attività in fasi con dipendenze passano a uno `READY` o all'altro e `PENDING` l'attività viene ripristinata. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status PENDING ``` **Example — Annullare un passaggio** Tutte le attività del passaggio che non hanno lo stato `SUCCEEDED` o `FAILED` sono contrassegnate`CANCELED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status CANCELED ``` **Example — Contrassegna un passaggio come fallito** Tutte le attività del passaggio che hanno lo stato `SUCCEEDED` rimangono invariate. Tutte le altre attività sono contrassegnate`FAILED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status FAILED ``` **Example — Contrassegna un passaggio riuscito** Tutte le attività del passaggio sono contrassegnate`SUCCEEDED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUCCEEDED ``` **Example — Sospendere un passaggio** Le attività del passaggio nello `SUCCEEDED` `FAILED` stato o non vengono modificate. `CANCELED` Tutte le altre attività sono contrassegnate`SUSPENDED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUSPENDED ``` **Example — Modificare lo stato di un'attività** Quando si utilizza il comando CLI `update-task` Deadline Cloud, l'attività passa allo stato specificato. ``` aws deadline update-task \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --task-id taskID \ --target-task-run-status SUCCEEDED | SUSPENDED | CANCELED | FAILED | PENDING ```