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