Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Cree trabajos para enviarlos a Deadline Cloud Los trabajos se envían a Deadline Cloud mediante paquetes de trabajos. Un paquete de trabajos es una colección de archivos que incluye una plantilla de [trabajo de Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) y cualquier archivo de activos necesario para renderizar el trabajo. La plantilla de trabajo describe cómo los trabajadores procesan los activos y acceden a ellos, y proporciona el script que ejecuta el trabajador. Los paquetes de trabajo permiten a los artistas, directores técnicos y desarrolladores de proyectos enviar fácilmente trabajos complejos a Deadline Cloud desde sus estaciones de trabajo locales o desde una granja de renderizados local. Los paquetes de tareas son especialmente útiles para los equipos que trabajan en proyectos de efectos visuales, animaciones u otros proyectos de renderización multimedia a gran escala que requieren recursos informáticos escalables y bajo demanda. Puede crear el paquete de tareas mediante el sistema de archivos local para almacenar los archivos y un editor de texto para crear la plantilla de tareas. Después de crear el paquete, envía el trabajo a Deadline Cloud mediante la CLI de Deadline Cloud o una herramienta como un remitente de Deadline Cloud Puedes almacenar tus activos en un sistema de archivos compartido entre tus trabajadores, o puedes usar los archivos adjuntos de trabajo de Deadline Cloud para automatizar el traslado de los activos a depósitos de S3 donde tus trabajadores puedan acceder a ellos. Los adjuntos de trabajo también ayudan a mover la salida de sus trabajos a sus estaciones de trabajo. En las siguientes secciones se proporcionan instrucciones detalladas sobre cómo crear y enviar paquetes de trabajos a Deadline Cloud. **Topics** + [Plantillas Open Job Description (OpenJD) para Deadline Cloud](build-job-bundle.md) + [Uso de archivos en sus trabajos](using-files-in-your-jobs.md) + [Usa archivos adjuntos de trabajo para compartir archivos](build-job-attachments.md) + [Cree límites de recursos para los trabajos](build-job-limits.md) + [Cómo enviar un trabajo a Deadline Cloud](submit-jobs-how.md) + [Programe trabajos en Deadline Cloud](build-jobs-scheduling.md) + [Modificar un trabajo en Deadline Cloud](build-jobs-modifying.md) # Plantillas Open Job Description (OpenJD) para Deadline Cloud Un *paquete de trabajos* es una de las herramientas que se utilizan para definir los trabajos en AWS Deadline Cloud. Agrupan una plantilla de [Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) con información adicional, como archivos y directorios que utilizan sus trabajos con adjuntos de trabajo. Utiliza la interfaz de línea de comandos (CLI) de Deadline Cloud para usar un paquete de trabajos para enviar trabajos para que se ejecute una cola. Un paquete de trabajos es una estructura de directorios que contiene una plantilla de trabajo de OpenJD, otros archivos que definen el trabajo y archivos específicos del trabajo necesarios como entrada para el trabajo. Puede especificar los archivos que definen su trabajo como archivos YAML o JSON. El único archivo obligatorio es `template.yaml` o`template.json`. También puede incluir los siguientes archivos: ``` /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 ``` Usa un paquete de trabajos para enviar trabajos personalizados con la CLI de Deadline Cloud y un adjunto de trabajo, o puedes usar una interfaz gráfica de envío. Por ejemplo, el siguiente es el ejemplo de Blender de GitHub. Para ejecutar el ejemplo, usa el siguiente comando en [el directorio de ejemplos de Blender](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles): ``` deadline bundle gui-submit blender_render ``` ![\[Un ejemplo de una interfaz de envío de trabajos personalizada para Blender.\]](http://docs.aws.amazon.com/es_es/deadline-cloud/latest/developerguide/images/blender_submit_shared_settings.png) El panel de ajustes específicos del trabajo se genera a partir de las `userInterface` propiedades de los parámetros del trabajo definidos en la plantilla del trabajo. Para enviar un trabajo mediante la línea de comandos, puede utilizar un comando similar al siguiente ``` deadline bundle submit \ --yes \ --name Demo \ -p BlenderSceneFile=location of scene file \ -p OutputDir=file pathe for job output \ blender_render/ ``` O puede usar la `deadline.client.api.create_job_from_job_bundle` función en el paquete `deadline` Python. Todos los complementos de envío de trabajos incluidos en Deadline Cloud, como el complemento Autodesk Maya, generan un paquete de trabajos para su envío y, a continuación, utilizan el paquete Python de Deadline Cloud para enviar su trabajo a Deadline Cloud. Puede ver los paquetes de trabajos enviados en el directorio del historial de trabajos de su estación de trabajo o mediante un remitente. Puede encontrar el directorio del historial de trabajos con el siguiente comando: ``` deadline config get settings.job_history_dir ``` Cuando tu trabajo se ejecuta en un trabajador de Deadline Cloud, este tiene acceso a variables de entorno que le proporcionan información sobre el trabajo. Las variables de entorno son: | Nombre de variable | Disponible | | --- | --- | | DEADLINE\$1FARM\$1ID | Todas las acciones | | DEADLINE\$1FLEET\$1ID | Todas las acciones | | DEADLINE\$1WORKER\$1ID | Todas las acciones | | DEADLINE\$1QUEUE\$1ID | Todas las acciones | | DEADLINE\$1JOB\$1ID | Todas las acciones | | DEADLINE\$1STEP\$1ID | Acciones de tareas | | DEADLINE\$1SESSION\$1ID | Todas las acciones | | DEADLINE\$1TASK\$1ID | Acciones de tareas | | DEADLINE\$1SESSIONACTION\$1ID | Todas las acciones | **Topics** + [Elementos de plantillas de trabajo para paquetes de trabajos](build-job-bundle-template.md) + [Fragmentación de tareas para plantillas de trabajo](build-job-bundle-chunking.md) + [Elementos de valores de parámetros para paquetes de trabajos](build-job-bundle-parameters.md) + [Elementos de referencia de activos para paquetes de trabajos](build-job-bundle-assets.md) # Elementos de plantillas de trabajo para paquetes de trabajos La plantilla de trabajo define el entorno de ejecución y los procesos que se ejecutan como parte de un trabajo de Deadline Cloud. Puede crear parámetros en una plantilla para utilizarla para crear trabajos que solo difieran en los valores de entrada, como ocurre con una función en un lenguaje de programación. Cuando envías un trabajo a Deadline Cloud, se ejecuta en cualquier entorno de cola aplicado a la cola. Los entornos de colas se crean utilizando la especificación de entornos externos Open Job Description (OpenJD). Para obtener más información, consulte la [plantilla de entorno](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#12-environment-template) en el repositorio de GitHub OpenJD. Para ver una introducción a la creación de un trabajo con una plantilla de trabajo de OpenJD, consulte [Introducción a la creación de un trabajo](https://github.com/OpenJobDescription/openjd-specifications/wiki/Introduction-to-Creating-a-Job) en el repositorio de GitHub OpenJD. Puede encontrar más información en [Cómo se ejecutan los trabajos](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run). Hay ejemplos de plantillas de trabajo en el `samples` directorio del GitHub repositorio de OpenJD. Puede definir la plantilla de trabajo en formato YAML (`template.yaml`) o en formato JSON (`template.json`). Los ejemplos de esta sección se muestran en formato YAML. Por ejemplo, la plantilla de trabajo del `blender_render` ejemplo define un parámetro de entrada `BlenderSceneFile` como una ruta de archivo: ``` - 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` propiedad define el comportamiento de las interfaces de usuario generadas automáticamente tanto en la línea de comandos mediante el `deadline bundle gui-submit` comando como en los complementos de envío de trabajos para aplicaciones como Autodesk Maya. En este ejemplo, el widget de interfaz de usuario para introducir un valor para el `BlenderSceneFile` parámetro es un cuadro de diálogo de selección de archivos que muestra solo los archivos. `.blend` ![\[Un widget de interfaz de usuario para introducir el parámetro del archivo de escena para una plantilla de trabajo de OpenJD.\]](http://docs.aws.amazon.com/es_es/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png) Para ver más ejemplos del uso del `userInteface` elemento, consulta el ejemplo [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) en el repositorio de. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub `dataFlow`Las propiedades `objectType` y controlan el comportamiento de los adjuntos de trabajo cuando se envía un trabajo desde un paquete de trabajos. En este caso, `objectType: FILE` y `dataFlow:IN` significan que el valor de `BlenderSceneFile` es un archivo de entrada para los trabajos adjuntos. Por el contrario, la definición del `OutputDir` parámetro tiene `objectType: DIRECTORY` y`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. ``` Los adjuntos del trabajo utilizan el valor del `OutputDir` parámetro como directorio en el que el trabajo escribe los archivos de salida. Para obtener más información sobre las `dataFlow` propiedades `objectType` y, consulte [JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)la [especificación Open Job Description](https://github.com/OpenJobDescription/openjd-specifications) El resto del ejemplo de plantilla de `blender_render` trabajo define el flujo de trabajo como un solo paso, en el que cada fotograma de la animación se representa como una tarea independiente: ``` 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}} ``` Por ejemplo, si el valor del `Frames` parámetro es`1-10`, define 10 tareas. Cada una de las tareas tiene un valor diferente para el `Frame` parámetro. Para ejecutar una tarea: 1. Por ejemplo, se expanden todas las referencias a variables de la `data` propiedad del archivo incrustado`--render-frame 1`. 1. El contenido de la `data` propiedad se escribe en un archivo del directorio de trabajo de la sesión en el disco. 1. El `onRun` comando de la tarea se resuelve en `bash location of embedded file` y, a continuación, se ejecuta. Para obtener más información sobre los archivos incrustados, las sesiones y las ubicaciones con mapas de rutas, consulte [Cómo se ejecutan los trabajos](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) en la especificación Open [Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run). Hay más ejemplos de plantillas de trabajo en el repositorio [deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles), así como los [ejemplos de plantillas que se proporcionan con la especificación](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples) Open Job Descriptions. # Fragmentación de tareas para plantillas de trabajo La fragmentación de tareas te permite agrupar varias tareas en una sola unidad de trabajo denominada fragmento. En un trabajo de renderizado, por ejemplo, esto significa que Deadline Cloud puede enviar varios fotogramas juntos en lugar de un fotograma por cada invocación de comando. Esto reduce la sobrecarga que supone iniciar las aplicaciones para cada tarea y acorta el tiempo total de ejecución del trabajo. Para obtener más información, consulte [Ejecutar varios fotogramas a la vez](https://github.com/OpenJobDescription/openjd-specifications/wiki/Job-Intro-03-Creating-a-Job-Template#42-running-multiple-frames-at-a-time) en la wiki de OpenJD. OpenJD admite extensiones que añaden funciones opcionales a las plantillas de trabajo. La fragmentación de tareas se habilita añadiendo la `TASK_CHUNKING` extensión. Para utilizar la fragmentación, añada la extensión a la plantilla de trabajo y utilice el tipo de parámetro de `CHUNK[INT]` tarea. Envíe los trabajos fragmentados con el mismo `deadline bundle submit` comando. Por ejemplo, la siguiente plantilla de trabajo representa los marcos en bloques de 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 ``` En este ejemplo, Deadline Cloud divide los 100 fotogramas en fragmentos, por ejemplo `1-10``11-20`, y así sucesivamente. La `{{Task.Param.Frame}}` variable se expande a una expresión de rango como`1-10`. Como `rangeConstraint` está establecida en`CONTIGUOUS`, el rango siempre está en `start-end` formato. El script analiza este rango y pasa los fotogramas inicial y final a Blender usando las `-e` opciones `-s` y con`--render-anim`. La `chunks` propiedad admite los siguientes campos: + `defaultTaskCount`— (Obligatorio) Cuántas tareas se van a combinar en un solo bloque. El valor máximo es 150. + `rangeConstraint`— (Obligatorio) Si`CONTIGUOUS`, un fragmento es siempre un rango contiguo, como. `1-10` Si`NONCONTIGUOUS`, un fragmento puede ser un conjunto arbitrario, como. `1,3,7-10` + `targetRuntimeSeconds`— (Opcional) El tiempo de ejecución objetivo en segundos para cada fragmento. Deadline Cloud puede ajustar dinámicamente el tamaño de los fragmentos para acercarse a este objetivo una vez que se hayan completado algunos fragmentos. Para ver más ejemplos de fragmentación de tareas, incluidos ejemplos básicos y de Blender con fragmentos contiguos y no contiguos, consulta los ejemplos de fragmentación de [tareas](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking) en el repositorio de muestras de Deadline Cloud en. GitHub **Requisitos de flota gestionados por el cliente** La fragmentación de tareas requiere una versión de agente de trabajo compatible. Si utilizas flotas gestionadas por el cliente, asegúrate de que tus agentes de trabajo estén actualizados antes de enviar los trabajos con fragmentación. Las flotas gestionadas por el servicio siempre utilizan una versión de agente de trabajo compatible. **¿Descargando los resultados de los trabajos fragmentados** Cuando descargas el resultado de una sola tarea de un trabajo fragmentado, Deadline Cloud descarga el resultado de todo el fragmento. Por ejemplo, si los fotogramas del 1 al 10 se procesaron juntos, la descarga del resultado del fotograma 3 incluye todos los fotogramas del 1 al 10. Esta función requiere la `deadline-cloud` versión 0.53.3 o posterior. # Elementos de valores de parámetros para paquetes de trabajos Puede usar el archivo de parámetros para establecer los valores de algunos de los parámetros del trabajo en la plantilla de trabajo o los argumentos de la solicitud de [CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)operación del paquete de trabajos, de modo que no necesite establecer valores al enviar un trabajo. La interfaz de usuario para el envío de trabajos le permite modificar estos valores. Puede definir la plantilla de trabajo en formato YAML (`parameter_values.yaml`) o formato JSON (`parameter_values.json`). Los ejemplos de esta sección se muestran en formato YAML. En YAML, el formato del archivo es: ``` parameterValues: - name: value: , , or - name: value: , , or ab ... repeating as necessary ``` Cada elemento de la `parameterValues` lista debe ser uno de los siguientes: + Un parámetro de trabajo definido en la plantilla de trabajo. + Un parámetro de trabajo definido en un entorno de colas para la cola a la que se envía el trabajo. + Parámetro especial que se transfiere a la `CreateJob` operación al crear un trabajo. + `deadline:priority`— El valor debe ser un número entero. Se pasa a la `CreateJob` operación como parámetro de [prioridad](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-priority). + `deadline:targetTaskRunStatus`— El valor debe ser una cadena. Se pasa a la `CreateJob` operación como parámetro de [targetTaskRunestado](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus). + `deadline:maxFailedTasksCount`— El valor debe ser un número entero. Se pasa a la `CreateJob` operación como parámetro [maxFailedTasksCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount). + `deadline:maxRetriesPerTask`— El valor debe ser un número entero. Se pasa a la `CreateJob` operación como parámetro de [maxRetriesPertarea](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask). + `deadline:maxWorkercount`— El valor debe ser un número entero. Se pasa a la `CreateJob` operación como [maxWorkerCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask)parámetro. Una plantilla de trabajo es siempre una plantilla y no un trabajo específico que ejecutar. Un archivo de valores de parámetros permite que un paquete de trabajos actúe como plantilla si algunos parámetros no tienen valores definidos en este archivo, o como un envío de trabajo específico si todos los parámetros tienen valores. Por ejemplo, el [ejemplo de blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render) no tiene un archivo de parámetros y su plantilla de trabajo define parámetros sin valores predeterminados. Esta plantilla debe usarse como plantilla para crear trabajos. Después de crear un trabajo con este paquete de trabajos, Deadline Cloud escribe un nuevo paquete de trabajos en el directorio del historial de trabajos. Por ejemplo, cuando envías un trabajo con el siguiente comando: ``` deadline bundle gui-submit blender_render/ ``` El nuevo paquete de trabajos contiene un `parameter_values.yaml` archivo que contiene los parámetros especificados: ``` % 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 ``` Puede crear el mismo trabajo con el siguiente comando: ``` deadline bundle submit ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/ ``` **nota** El paquete de trabajos que envíe se guarda en el directorio del historial de trabajos. Puede encontrar la ubicación de ese directorio con el siguiente comando: ``` deadline config get settings.job_history_dir ``` # Elementos de referencia de activos para paquetes de trabajos Puedes usar los [archivos adjuntos de trabajo](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) de Deadline Cloud para transferir archivos de un lado a otro entre tu estación de trabajo y Deadline Cloud. El archivo de referencia de activos incluye los archivos y directorios de entrada, así como los directorios de salida para tus archivos adjuntos. Si no incluye todos los archivos y directorios de este archivo, puede seleccionarlos al enviar un trabajo con el `deadline bundle gui-submit` comando. Este archivo no tiene ningún efecto si no utiliza adjuntos de trabajo. Puede definir la plantilla de trabajo en formato YAML (`asset_references.yaml`) o en formato JSON (`asset_references.json`). Los ejemplos de esta sección se muestran en formato YAML. En YAML, el formato del archivo es: ``` 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 ``` Al seleccionar el archivo de entrada o salida para cargarlo en Amazon S3, Deadline Cloud compara la ruta del archivo con las rutas que aparecen en sus perfiles de almacenamiento. Cada ubicación `SHARED` de sistema de archivos de un perfil de almacenamiento abstrae un recurso compartido de archivos de red que está montado en sus estaciones de trabajo y en los hosts de los trabajadores. Deadline Cloud carga solo los archivos que no se encuentran en uno de estos recursos compartidos de archivos. Para obtener más información sobre la creación y el uso de perfiles de almacenamiento, consulte [Almacenamiento compartido en Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) en la *Guía del usuario de AWS Deadline Cloud*. **Example - El archivo de referencia de activos creado por la GUI de Deadline Cloud** Usa el siguiente comando para enviar un trabajo usando el ejemplo de [blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render). ``` deadline bundle gui-submit blender_render/ ``` Añada algunos archivos adicionales al trabajo en la pestaña **Adjuntos del trabajo**: ![\[El panel de adjuntos de trabajos de la GUI de envío de trabajos de Deadline Cloud. Agregue el archivo de entrada/private/tmp/bundle_demo/a_texture.png and the input directory /private/tmp/bundle_demo/assets.\]](http://docs.aws.amazon.com/es_es/deadline-cloud/latest/developerguide/images/blender_submit_add_job_attachments.png) Después de enviar el trabajo, puede consultar el `asset_references.yaml` archivo del paquete de trabajos en el directorio del historial de trabajos para ver los activos del archivo 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: [] ``` # Uso de archivos en sus trabajos Muchos de los trabajos que envías a AWS Deadline Cloud tienen archivos de entrada y salida. Los archivos de entrada y los directorios de salida pueden estar ubicados en una combinación de sistemas de archivos compartidos y unidades locales. Los trabajos deben ubicar el contenido en esas ubicaciones. Deadline Cloud ofrece dos funciones, [los archivos adjuntos de los trabajos](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) y [los perfiles de almacenamiento](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) que funcionan en conjunto para ayudar a sus trabajos a localizar los archivos que necesitan. Los adjuntos de trabajo ofrecen varios beneficios + Mueva archivos entre hosts mediante Amazon S3 + Transfiera archivos desde su estación de trabajo a los hosts de los trabajadores y viceversa + Disponible para los trabajos en colas en los que se habilita la función + Se utiliza principalmente con flotas gestionadas por el servicio, pero también es compatible con las flotas gestionadas por el cliente. Utilice los perfiles de almacenamiento para mapear el diseño de las ubicaciones de los sistemas de archivos compartidos en su estación de trabajo y en los hosts de los trabajadores. Este mapeo ayuda a sus trabajos a localizar los archivos y directorios compartidos cuando sus ubicaciones difieren entre la estación de trabajo y los hosts de los trabajadores, por ejemplo, en configuraciones multiplataforma con estaciones de trabajo basadas y hosts de trabajo basados en servidores de trabajo Windows basados. Linux Los adjuntos de trabajo también utilizan el mapa del perfil de almacenamiento de la configuración del sistema de archivos para identificar los archivos que necesitan transferirse de un host a otro a través de Amazon S3. Si no utiliza adjuntos de tareas y no necesita reasignar las ubicaciones de los archivos y directorios entre las estaciones de trabajo y los hosts de los trabajadores, no necesitará modelar sus archivos compartidos con perfiles de almacenamiento. **Topics** + [Ejemplo de infraestructura de proyecto](sample-project-infrastructure.md) + [Perfiles de almacenamiento y mapeo de rutas](storage-profiles-and-path-mapping.md) # Ejemplo de infraestructura de proyecto Para demostrar el uso de los archivos adjuntos de trabajo y los perfiles de almacenamiento, configure un entorno de prueba con dos proyectos distintos. Puede usar la consola de Deadline Cloud para crear los recursos de prueba. 1. Si aún no lo has hecho, crea una granja de pruebas. Para crear una granja, siga el procedimiento descrito en [Crear una granja](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html). 1. Cree dos colas para los trabajos en cada uno de los dos proyectos. Para crear colas, siga el procedimiento descrito en [Crear una](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html) cola. 1. Cree la primera cola llamada. **Q1** Utilice la siguiente configuración, utilice los valores predeterminados para todos los demás elementos. + Para adjuntar trabajos, selecciona **Crear un nuevo bucket de Amazon S3**. + Seleccione **Habilitar la asociación con flotas gestionadas por el cliente**. + Para ejecutar como usuario, introduzca tanto el usuario como **jobuser** el grupo de POSIX. + Para el rol de servicio de colas, cree un nuevo rol llamado **AssetDemoFarm-Q1-Role** + Desactive la casilla de verificación del entorno de colas conda predeterminado. 1. Cree la segunda cola llamada. **Q2** Utilice la siguiente configuración, utilice los valores predeterminados para todos los demás elementos. + Para adjuntar trabajos, selecciona **Crear un nuevo bucket de Amazon S3**. + Seleccione **Habilitar la asociación con flotas gestionadas por el cliente**. + Para ejecutar como usuario, introduzca tanto el usuario como **jobuser** el grupo de POSIX. + Para el rol de servicio de colas, cree un nuevo rol llamado **AssetDemoFarm-Q2-Role** + Desactive la casilla de verificación del entorno de colas conda predeterminado. 1. Cree una flota única gestionada por el cliente que ejecute los trabajos de ambas colas. Para crear la flota, siga el procedimiento descrito en [Crear una](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html) flota gestionada por el cliente. Utilice la siguiente configuración: + Para **Nombre**, utilice**DemoFleet**. + Para el **tipo de flota**, seleccione **Gestionado por el cliente** + Para el **rol de servicio de flota**, cree un nuevo rol denominado **AssetDemoFarm-Fleet-Role**. + No asocies la flota a ninguna cola. El entorno de prueba supone que hay tres sistemas de archivos compartidos entre los hosts que utilizan recursos compartidos de archivos de red. En este ejemplo, las ubicaciones tienen los siguientes nombres: + `FSCommon`- contiene activos de trabajo de entrada que son comunes a ambos proyectos. + `FS1`- contiene los activos de trabajo de entrada y salida para el proyecto 1. + `FS2`- contiene los activos de trabajo de entrada y salida para el proyecto 2. El entorno de prueba también supone que hay tres estaciones de trabajo, de la siguiente manera: + `WSAll`- Una estación de trabajo Linux basada que utilizan los desarrolladores para todos los proyectos. Las ubicaciones del sistema de archivos compartidos son: + `FSCommon`: `/shared/common` + `FS1`: `/shared/projects/project1` + `FS2`: `/shared/projects/project2` + `WS1`- Una estación de trabajo Windows basada en el proyecto 1. Las ubicaciones del sistema de archivos compartidos son: + `FSCommon`: `S:\` + `FS1`: `Z:\` + `FS2`: No disponible + `WS1`- Una estación de trabajo macOS basada en el proyecto 2. Las ubicaciones del sistema de archivos compartidos son: + `FSCommon`: `/Volumes/common` + `FS1`: No disponible + `FS2`: `/Volumes/projects/project2` Por último, defina las ubicaciones del sistema de archivos compartidos para los trabajadores de su flota. Los ejemplos siguientes se refieren a esta configuración como`WorkerConfig`. Las ubicaciones compartidas son: + `FSCommon`: `/mnt/common` + `FS1`: `/mnt/projects/project1` + `FS2`: `/mnt/projects/project2` No necesita configurar ningún sistema de archivos, estaciones de trabajo o trabajadores compartidos que coincidan con esta configuración. No es necesario que las ubicaciones compartidas existan para la demostración. # Perfiles de almacenamiento y mapeo de rutas Utilice los perfiles de almacenamiento para modelar los sistemas de archivos de las estaciones de trabajo y los hosts de los trabajadores. Cada perfil de almacenamiento describe el diseño del sistema operativo y del sistema de archivos de una de las configuraciones del sistema. En este tema se describe cómo usar los perfiles de almacenamiento para modelar las configuraciones del sistema de archivos de sus hosts, de modo que Deadline Cloud pueda generar reglas de mapeo de rutas para sus trabajos, y cómo se generan esas reglas de mapeo de rutas a partir de sus perfiles de almacenamiento. Cuando envíes un trabajo a Deadline Cloud, puedes proporcionar un ID de perfil de almacenamiento opcional para el trabajo. Este perfil de almacenamiento describe el sistema de archivos de la estación de trabajo que lo envía. Describe la configuración original del sistema de archivos que utilizan las rutas de archivos de la plantilla de trabajo. También puede asociar un perfil de almacenamiento a una flota. El perfil de almacenamiento describe la configuración del sistema de archivos de todos los hosts trabajadores de la flota. Si tiene trabajadores con una configuración de sistema de archivos diferente, esos trabajadores deben estar asignados a una flota diferente en su granja. Las reglas de mapeo de rutas describen cómo se deben reasignar las rutas desde la forma en que se especifican en el trabajo hasta la ubicación real de la ruta en el host de un trabajador. Deadline Cloud compara la configuración del sistema de archivos descrita en el perfil de almacenamiento de un trabajo con el perfil de almacenamiento de la flota que ejecuta el trabajo para derivar estas reglas de mapeo de rutas. **Topics** + [Modele ubicaciones de sistemas de archivos compartidos con perfiles de almacenamiento](modeling-your-shared-filesystem-locations-with-storage-profiles.md) + [Configure los perfiles de almacenamiento para las flotas](configuring-storage-profiles-for-fleets.md) + [Configure los perfiles de almacenamiento para las colas](storage-profiles-for-queues.md) + [Obtenga reglas de mapeo de rutas a partir de los perfiles de almacenamiento](deriving-path-mapping-rules-from-storage-profiles.md) # Modele ubicaciones de sistemas de archivos compartidos con perfiles de almacenamiento Un perfil de almacenamiento modela la configuración del sistema de archivos de una de las configuraciones de su host. Hay cuatro configuraciones de host diferentes en la [infraestructura del proyecto de muestra](). En este ejemplo, se crea un perfil de almacenamiento independiente para cada uno. Puede crear un perfil de almacenamiento mediante cualquiera de las siguientes opciones: + [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 recurso + [Consola de AWS](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html#storage-profile) Un perfil de almacenamiento se compone de una lista de ubicaciones de sistemas de archivos, cada una de las cuales indica a Deadline Cloud la ubicación y el tipo de ubicación del sistema de archivos relevantes para los trabajos enviados desde o ejecutados en un host. Un perfil de almacenamiento solo debe modelar las ubicaciones relevantes para los trabajos. Por ejemplo, la `FSCommon` ubicación compartida se encuentra en la estación de trabajo de `WS1``S:\`, por lo que la ubicación correspondiente del sistema de archivos es: ``` { "name": "FSCommon", "path": "S:\\", "type": "SHARED" } ``` Utilice los siguientes comandos para crear el perfil de almacenamiento para las configuraciones de las `WS1` estaciones de trabajo `WS3` y la configuración de trabajo `WorkerConfig` mediante el [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)comando in: `WS2` [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/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** Debe consultar las ubicaciones del sistema de archivos en sus perfiles de almacenamiento utilizando los mismos valores para la `name` propiedad en todos los perfiles de almacenamiento de su granja. Deadline Cloud compara los nombres para determinar si las ubicaciones de los sistemas de archivos de diferentes perfiles de almacenamiento hacen referencia a la misma ubicación al generar las reglas de mapeo de rutas. # Configure los perfiles de almacenamiento para las flotas Puede configurar una flota para que incluya un perfil de almacenamiento que modele las ubicaciones de los sistemas de archivos de todos los trabajadores de la flota. La configuración del sistema de archivos anfitrión de todos los trabajadores de una flota debe coincidir con el perfil de almacenamiento de la flota. Los trabajadores con diferentes configuraciones de sistemas de archivos deben estar en flotas separadas. Para establecer la configuración de su flota para usar el perfil de `WorkerConfig` almacenamiento, utilice: [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 } }" ``` # Configure los perfiles de almacenamiento para las colas La configuración de una cola incluye una lista de nombres de las ubicaciones del sistema de archivos compartidos a las que deben acceder los trabajos enviados a la cola, que distinguen mayúsculas de minúsculas. Por ejemplo, los trabajos enviados a la cola `Q1` requieren ubicaciones del sistema de archivos y. `FSCommon` `FS1` Los trabajos enviados a la cola requieren ubicaciones en los sistemas de archivos `Q2` y. `FSCommon` `FS2` Para configurar las configuraciones de la cola de modo que requieran estas ubicaciones del sistema de archivos, utilice el siguiente script: ``` # 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 configuración de una cola también incluye una lista de perfiles de almacenamiento permitidos que se aplica a los trabajos enviados a esa cola y a las flotas asociadas a ella. En la lista de perfiles de almacenamiento permitidos de la cola solo se permiten los perfiles de almacenamiento que definen las ubicaciones del sistema de archivos para todas las ubicaciones de sistemas de archivos requeridas para la cola. Se produce un error en un trabajo si lo envía con un perfil de almacenamiento que no figura en la lista de perfiles de almacenamiento permitidos para la cola. Siempre puedes enviar un trabajo sin perfil de almacenamiento a una cola. Las configuraciones de las estaciones de trabajo están etiquetadas `WSAll` y `WS1` ambas tienen las ubicaciones de sistema de archivos requeridas (`FSCommon`y`FS1`) para la cola. `Q1` Deben poder enviar los trabajos a la cola. Del mismo modo, las estaciones de trabajo configuran `WSAll` y `WS2` cumplen los requisitos de cola. `Q2` Deben poder enviar trabajos a esa cola. Actualice ambas configuraciones de cola para permitir que los trabajos se envíen con estos perfiles de almacenamiento mediante el siguiente script: ``` # 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 ``` Si agrega el perfil `WS2` de almacenamiento a la lista de perfiles de almacenamiento permitidos para la cola, se produce `Q1` un error: ``` $ 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 ``` Esto se debe a que el perfil de `WS2` almacenamiento no contiene una definición para la ubicación del sistema de archivos con el nombre `FS1` que requiere la cola`Q1`. También se produce un error al asociar una flota configurada con un perfil de almacenamiento que no está en la lista de perfiles de almacenamiento permitidos de la cola. Por ejemplo: ``` $ 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. ``` Para corregir el error, añada el perfil de almacenamiento mencionado `WorkerConfig` a la lista de perfiles de almacenamiento permitidos tanto para la cola como para la cola`Q1`. `Q2` A continuación, asocie la flota a estas colas para que los trabajadores de la flota puedan ejecutar los trabajos desde ambas colas. ``` # 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 ``` # Obtenga reglas de mapeo de rutas a partir de los perfiles de almacenamiento Las reglas de mapeo de rutas describen cómo se deben reasignar las rutas desde el trabajo hasta la ubicación real de la ruta en un host de trabajo. Cuando se ejecuta una tarea en un trabajador, el perfil de almacenamiento del trabajo se compara con el perfil de almacenamiento de la flota del trabajador para obtener las reglas de mapeo de rutas de la tarea. Deadline Cloud crea una regla de mapeo para cada una de las ubicaciones del sistema de archivos requeridas en la configuración de la cola. Por ejemplo, un trabajo enviado con el perfil de `WSAll` almacenamiento a la cola `Q1` tiene las siguientes reglas de mapeo de rutas: + `FSComm`: `/shared/common -> /mnt/common` + `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` Deadline Cloud crea reglas para las ubicaciones `FSComm` y del sistema de `FS1` archivos, pero no para la ubicación del sistema de `FS2` archivos, aunque estén definidas tanto por el `WSAll` perfil como por el `WorkerConfig` de almacenamiento. `FS2` Esto se debe a que `Q1` la lista de ubicaciones de sistemas de archivos obligatorias de Queue sí lo es`["FSComm", "FS1"]`. Para confirmar las reglas de mapeo de rutas disponibles para los trabajos enviados con un perfil de almacenamiento concreto, envíe un trabajo que imprima el [archivo de reglas de mapeo de rutas de Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping) y, a continuación, lea el registro de sesión una vez finalizado el trabajo: ``` # 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}}" ] } } } } ] }' ``` Si usa la [CLI de Deadline Cloud](https://pypi.org/project/deadline/) para enviar trabajos, su `settings.storage_profile_id` configuración establece el perfil de almacenamiento que tendrán los trabajos enviados con la CLI. Para enviar trabajos con el perfil `WSAll` de almacenamiento, configure: ``` deadline config set settings.storage_profile_id $WSALL_ID ``` Para ejecutar un trabajador gestionado por el cliente como si se estuviera ejecutando en la infraestructura de ejemplo, siga el procedimiento descrito en [Ejecute el agente de trabajo](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/run-worker.html) de la *Guía del usuario de Deadline Cloud* para ejecutar un trabajador. AWS CloudShell Si ha seguido esas instrucciones anteriormente, elimine primero los `~/demoenv-persist` directorios `~/demoenv-logs` y. Además, establezca los valores de las variables de `DEV_CMF_ID` entorno `DEV_FARM_ID` y las variables de entorno a las que hacen referencia las instrucciones de la siguiente manera antes de hacerlo: ``` DEV_FARM_ID=$FARM_ID DEV_CMF_ID=$FLEET_ID ``` Una vez ejecutado el trabajo, puede ver las reglas de mapeo de rutas en el archivo de registro del trabajo: ``` cat demoenv-logs/${QUEUE1_ID}/*.log ... JJSON log results (see below) ... ``` El registro contiene el mapeo del sistema de `FSComm` archivos `FS1` y del sistema de archivos. Reformateada para facilitar la lectura, la entrada de registro tiene el siguiente aspecto: ``` { "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" } ] ``` Puede enviar trabajos con diferentes perfiles de almacenamiento para ver cómo cambian las reglas de mapeo de rutas. # Usa archivos adjuntos de trabajo para compartir archivos Usa los archivos *adjuntos de trabajo* para hacer que los archivos que no están en los directorios compartidos estén disponibles para tus trabajos y para capturar los archivos de salida si no están escritos en los directorios compartidos. Job attachments utiliza Amazon S3 para transferir archivos entre hosts. Los archivos se almacenan en depósitos de S3 y no es necesario cargar un archivo si su contenido no ha cambiado. Debe usar adjuntos de trabajo cuando ejecute trabajos en [flotas administradas por el servicio](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html), ya que los hosts no comparten las ubicaciones del sistema de archivos. Los adjuntos de trabajo también son útiles con [las flotas administradas por el cliente cuando los](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/manage-cmf.html) archivos de entrada o salida de un trabajo se almacenan en un sistema de archivos de red compartido, como cuando el [paquete de trabajos](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html) contiene scripts de shell o Python. Cuando envía un paquete de trabajos con la [CLI de Deadline Cloud](https://pypi.org/project/deadline/) o un remitente de Deadline Cloud, los adjuntos de trabajos utilizan el perfil de almacenamiento del trabajo y las ubicaciones del sistema de archivos requeridas por la cola para identificar los archivos de entrada que no se encuentran en el host de un trabajador y que deben cargarse en Amazon S3 como parte del envío de trabajos. Estos perfiles de almacenamiento también ayudan a Deadline Cloud a identificar los archivos de salida en las ubicaciones de alojamiento de los trabajadores que deben cargarse en Amazon S3 para que estén disponibles en su estación de trabajo. Los ejemplos de adjuntos de trabajo utilizan las configuraciones de granja, flota, colas y perfiles de almacenamiento desde [Ejemplo de infraestructura de proyecto](sample-project-infrastructure.md) y. [Perfiles de almacenamiento y mapeo de rutas](storage-profiles-and-path-mapping.md) Deberías revisar esas secciones antes que esta. En los ejemplos siguientes, utiliza un paquete de trabajos de muestra como punto de partida y, a continuación, lo modifica para explorar las funciones de Job Adjunt. Los paquetes de trabajos son la mejor forma de que sus trabajos utilicen adjuntos de trabajo. Combinan una plantilla de [trabajo de Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki) en un directorio con archivos adicionales que enumeran los archivos y directorios necesarios para los trabajos que utilizan el paquete de trabajos. Para obtener más información sobre los paquetes de trabajos, consulte[Plantillas Open Job Description (OpenJD) para Deadline Cloud](build-job-bundle.md). # Envío de archivos con un trabajo Con Deadline Cloud, puedes permitir que los flujos de trabajo accedan a los archivos de entrada que no están disponibles en las ubicaciones de los sistemas de archivos compartidos de los anfitriones de los trabajadores. Los adjuntos de trabajo permiten que los trabajos de renderización accedan a los archivos que se encuentran únicamente en la unidad de una estación de trabajo local o en un entorno de flota gestionado por el servicio. Al enviar un paquete de trabajos, puede incluir listas de los archivos y directorios de entrada necesarios para el trabajo. Deadline Cloud identifica estos archivos no compartidos, los carga desde la máquina local a Amazon S3 y los descarga en el host del trabajador. Agiliza el proceso de transferencia de los activos de entrada a los nodos de renderizado, lo que garantiza que todos los archivos necesarios estén accesibles para la ejecución distribuida de los trabajos. Puede especificar los archivos de los trabajos directamente en el paquete de trabajos, utilizar los parámetros de la plantilla de trabajo que proporcione mediante variables de entorno o un script y utilizar el `assets_references` archivo del trabajo. Puede utilizar uno de estos métodos o una combinación de los tres. Puede especificar un perfil de almacenamiento para el paquete del trabajo de modo que solo cargue los archivos que se hayan modificado en la estación de trabajo local. En esta sección, se utiliza un ejemplo de paquete de trabajos GitHub para demostrar cómo Deadline Cloud identifica los archivos del trabajo que va a cargar, cómo se organizan esos archivos en Amazon S3 y cómo se ponen a disposición de los anfitriones de los trabajadores que procesan sus trabajos. **Topics** + [Cómo carga Deadline Cloud los archivos a Amazon S3](what-job-attachments-uploads-to-amazon-s3.md) + [Cómo elige Deadline Cloud los archivos que desea cargar](how-job-attachments-decides-what-to-upload-to-amazon-s3.md) + [¿Cómo encuentran los trabajos los archivos de entrada adjuntos a los trabajos?](how-jobs-find-job-attachments-input-files.md) # Cómo carga Deadline Cloud los archivos a Amazon S3 En este ejemplo, se muestra cómo Deadline Cloud carga archivos desde su estación de trabajo o host de trabajo a Amazon S3 para poder compartirlos. Utiliza un paquete de trabajos de muestra GitHub y la CLI de Deadline Cloud para enviar los trabajos. Comience por clonar el [ GitHubrepositorio de muestras de Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples) en su [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)entorno y, a continuación, copie el paquete de `job_attachments_devguide` trabajos en su directorio principal: ``` git clone https://github.com/aws-deadline/deadline-cloud-samples.git cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide ~/ ``` Instale la [CLI de Deadline Cloud](https://pypi.org/project/deadline/) para enviar paquetes de trabajos: ``` pip install deadline --upgrade ``` El paquete de `job_attachments_devguide` tareas consta de un solo paso con una tarea que ejecuta un script de shell en bash cuya ubicación en el sistema de archivos se transmite como parámetro del trabajo. La definición del parámetro de trabajo es: ``` ... - name: ScriptFile type: PATH default: script.sh dataFlow: IN objectType: FILE ... ``` El `IN` valor de la `dataFlow` propiedad indica a los adjuntos del trabajo que el valor del `ScriptFile` parámetro es una entrada para el trabajo. El valor de la `default` propiedad es una ubicación relativa al directorio del paquete de tareas, pero también puede ser una ruta absoluta. Esta definición de parámetro declara el `script.sh` archivo del directorio del paquete de trabajos como un archivo de entrada necesario para que se ejecute el trabajo. A continuación, asegúrese de que la CLI de Deadline Cloud no tenga un perfil de almacenamiento configurado y, a continuación, envíe el trabajo a la cola`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/ ``` El resultado de la CLI de Deadline Cloud después de ejecutar este comando tiene el siguiente aspecto: ``` 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 ``` Al enviar el trabajo, Deadline Cloud primero crea un hash del `script.sh` archivo y, a continuación, lo carga en Amazon S3. Deadline Cloud trata el depósito de S3 como almacenamiento direccionable por contenido. Los archivos se cargan en objetos de S3. El nombre del objeto se deriva de un hash del contenido del archivo. Si dos archivos tienen el mismo contenido, tienen el mismo valor hash independientemente de dónde estén ubicados los archivos o de su nombre. Este almacenamiento de contenido direccionable permite a Deadline Cloud evitar cargar un archivo si ya está disponible. Puede usar la [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) para ver los objetos que se cargaron en 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 ``` Se cargaron dos objetos en S3: + `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`— El contenido de`script.sh`. El valor `87cb19095dd5d78fcaf56384ef0e6241` de la clave del objeto es el hash del contenido del archivo y la extensión `xxh128` indica que el valor hash se calculó como un [xxhash](https://xxhash.com/) de 128 bits. + `DeadlineCloud/Manifests///Inputs//a1d221c7fd97b08175b3872a37428e8c_input`— El objeto del manifiesto para el envío del trabajo. Los valores `` y `` son el identificador de la granja, el identificador de la cola y un valor hexadecimal aleatorio. `` El valor `a1d221c7fd97b08175b3872a37428e8c` de este ejemplo es un valor hash calculado a partir de la cadena`/home/cloudshell-user/job_attachments_devguide`, el directorio en el que se encuentra`script.sh`. El objeto de manifiesto contiene la información de los archivos de entrada de una ruta raíz específica que se cargaron en S3 como parte del envío del trabajo. Descargue este archivo de manifiesto (`aws s3 cp s3://$Q1_S3_BUCKET/`). Su contenido es similar al de: ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "87cb19095dd5d78fcaf56384ef0e6241", "mtime": 1721147454416085, "path": "script.sh", "size": 39 } ], "totalSize": 39 } ``` Esto indica que el archivo `script.sh` se ha cargado y el hash del contenido de ese archivo lo es`87cb19095dd5d78fcaf56384ef0e6241`. Este valor hash coincide con el valor del nombre del objeto`DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`. Deadline Cloud lo utiliza para saber qué objeto descargar para el contenido de este archivo. El esquema completo de este archivo está [disponible en GitHub](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/job_attachments/asset_manifests/v2023_03_03/validate.py). Al utilizar la [CreateJob operación](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html), puede establecer la ubicación de los objetos del manifiesto. Puedes usar la [GetJoboperación](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) para ver la ubicación: ``` { "attachments": { "file system": "COPIED", "manifests": [ { "inputManifestHash": "5b0db3d311805ea8de7787b64cbbe8b3", "inputManifestPath": "//Inputs//a1d221c7fd97b08175b3872a37428e8c_input", "rootPath": "/home/cloudshell-user/job_attachments_devguide", "rootPathFormat": "posix" } ] }, ... } ``` # Cómo elige Deadline Cloud los archivos que desea cargar Los archivos y directorios que job attachments considera para cargar en Amazon S3 como entradas para su trabajo son: + Los valores de todos los parámetros `PATH` de trabajo de tipo definido en la plantilla de trabajo del paquete de trabajos con un `dataFlow` valor de `IN` o`INOUT`. + Los archivos y directorios que aparecen como entradas en el archivo de referencias de activos del paquete de trabajos. Si envía un trabajo sin perfil de almacenamiento, se cargarán todos los archivos que desee cargar. Si envía un trabajo con un perfil de almacenamiento, los archivos no se cargan en Amazon S3 si se encuentran en ubicaciones de sistema de archivos `SHARED` tipo perfil de almacenamiento que también son ubicaciones de sistema de archivos obligatorias para la cola. Se espera que estas ubicaciones estén disponibles en los hosts de trabajo que ejecutan el trabajo, por lo que no es necesario cargarlas en S3. En este ejemplo, crea ubicaciones de sistemas de `SHARED` archivos `WSAll` en su CloudShell entorno de AWS y, a continuación, añade archivos a esas ubicaciones de sistemas de archivos. Utilice el siguiente 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 ``` A continuación, añada un archivo de referencias de activos al paquete de trabajos que incluya todos los archivos que creó como entradas para el trabajo. Utilice el siguiente 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 ``` A continuación, configure la CLI de Deadline Cloud para enviar los trabajos con el perfil de `WSAll` almacenamiento y, a continuación, envíe el paquete de trabajos: ``` # 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 carga dos archivos a Amazon S3 cuando envías el trabajo. Puede descargar los objetos del manifiesto del trabajo desde S3 para ver los archivos cargados: ``` 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 ``` En este ejemplo, hay un único archivo de manifiesto con el siguiente contenido: ``` { "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 } ``` Usa la [GetJob operación](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) del manifiesto para comprobar que `rootPath` es «/». ``` aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID --query 'attachments.manifests[*]' ``` La ruta raíz del conjunto de archivos de entrada es siempre la subruta común más larga de esos archivos. Si el trabajo se envió desde, Windows en cambio, y hay archivos de entrada que no tienen una subruta común porque se encuentran en unidades diferentes, verá una ruta raíz independiente en cada unidad. Las rutas de un manifiesto siempre son relativas a la ruta raíz del manifiesto, por lo que los archivos de entrada que se cargaron son los siguientes: + `/home/cloudshell-user/job_attachments_devguide/script.sh`— El archivo de script del paquete de tareas. + `/shared/projects/project2/file.txt`— El archivo en una ubicación del sistema de `SHARED` archivos del perfil `WSAll` de almacenamiento que **no** figura en la lista de ubicaciones de sistemas de archivos obligatorias para la cola`Q1`. Los archivos en las ubicaciones del sistema de archivos `FSCommon` (`/shared/common/file.txt`) y `FS1` (`/shared/projects/project1/file.txt`) no están en la lista. Esto se debe a que esas ubicaciones del sistema de archivos están `SHARED` en el perfil de `WSAll` almacenamiento y ambas están en la lista de ubicaciones obligatorias del sistema de archivos en cola`Q1`. Con la [GetStorageProfileForQueue operación](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetStorageProfileForQueue.html), puede ver las ubicaciones de los sistemas de archivos consideradas `SHARED` para un trabajo que se envía con un perfil de almacenamiento determinado. Para consultar el perfil de almacenamiento `WSAll` de la cola, `Q1` utilice el siguiente 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 ``` # ¿Cómo encuentran los trabajos los archivos de entrada adjuntos a los trabajos? Para que un trabajo utilice los archivos que Deadline Cloud carga en Amazon S3 mediante adjuntos de trabajo, su trabajo necesita esos archivos disponibles a través del sistema de archivos de los hosts de los trabajadores. Cuando una [sesión](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#sessions) de tu trabajo se ejecuta en el host de un trabajador, Deadline Cloud descarga los archivos de entrada del trabajo en un directorio temporal de la unidad local del anfitrión del trabajador y añade reglas de mapeo de rutas para cada una de las rutas raíz del trabajo a la ubicación del sistema de archivos en la unidad local. Para este ejemplo, inicie el agente de trabajo de Deadline Cloud en una CloudShell pestaña de AWS. Deje que los trabajos enviados anteriormente terminen de ejecutarse y, a continuación, elimine los registros de trabajos del directorio de registros: ``` rm -rf ~/devdemo-logs/queue-* ``` El siguiente script modifica el paquete de trabajos para mostrar todos los archivos del directorio de trabajo temporal de la sesión y el contenido del archivo de reglas de mapeo de rutas y, a continuación, envía un trabajo con el paquete modificado: ``` # 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/ ``` Puede consultar el registro de la ejecución de la tarea después de que la haya ejecutado el trabajador de su AWS CloudShell entorno: ``` cat demoenv-logs/queue-*/session*.log ``` El registro muestra que lo primero que ocurre en la sesión es que los dos archivos de entrada del trabajo se descargan al trabajador: ``` 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. ``` El siguiente es el resultado de `script.sh` run by the job: + Los archivos de entrada que se cargaron al enviar el trabajo se encuentran en un directorio cuyo nombre comienza por «assetroot» en el directorio temporal de la sesión. + Las rutas de los archivos de entrada se han reubicado en relación con el directorio «assetroot» en lugar de en relación con la ruta raíz del manifiesto de entrada () del trabajo. `"/"` + El archivo de reglas de mapeo de rutas contiene una regla adicional que se reasigna `"/"` a la ruta absoluta del directorio «assetroot». Por ejemplo: ``` 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** Si el trabajo que envías tiene varios manifiestos con diferentes rutas raíz, habrá un directorio con el nombre «assetroot» diferente para cada una de las rutas raíz. Si necesita hacer referencia a la ubicación del sistema de archivos reubicado de uno de sus archivos de entrada, directorios o ubicaciones del sistema de archivos, puede procesar el archivo de reglas de mapeo de rutas en su trabajo y realizar la reasignación usted mismo, o agregar un parámetro de trabajo de `PATH` tipo a la plantilla de trabajo en su paquete de trabajos y pasar el valor que necesita reasignar como valor de ese parámetro. Por ejemplo, el ejemplo siguiente modifica el paquete de trabajos para que tenga uno de estos parámetros de trabajo y, a continuación, envía un trabajo con la ubicación del sistema de archivos `/shared/projects/project2` como valor: ``` 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 ``` El archivo de registro de la ejecución de este trabajo contiene el resultado: ``` 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 ``` # Obtener los archivos de salida de un trabajo En este ejemplo, se muestra cómo Deadline Cloud identifica los archivos de salida que generan sus trabajos, decide si los carga en Amazon S3 y cómo puede colocarlos en su estación de trabajo. En este ejemplo, utilice el `job_attachments_devguide_output` paquete de `job_attachments_devguide` trabajos en lugar del paquete de trabajos. Comience por hacer una copia del paquete en su AWS CloudShell entorno a partir de su clon del GitHub repositorio de muestras de Deadline Cloud: ``` cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide_output ~/ ``` La diferencia importante entre este paquete de trabajos y el paquete de `job_attachments_devguide` trabajos es la adición de un nuevo parámetro de trabajo en la plantilla de trabajo: ``` ... parameterDefinitions: ... - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT default: ./output_dir description: This directory contains the output for all steps. ... ``` La `dataFlow` propiedad del parámetro tiene el valor`OUT`. Deadline Cloud utiliza el valor de los parámetros del `dataFlow` trabajo con un valor `INOUT` igual `OUT` o como resultados de su trabajo. Si la ubicación del sistema de archivos transferida como valor a este tipo de parámetros de trabajo se reasigna a una ubicación del sistema de archivos local del trabajador que ejecuta el trabajo, Deadline Cloud buscará nuevos archivos en la ubicación y los cargará en Amazon S3 como resultados del trabajo. Para ver cómo funciona, primero inicia el agente de trabajadores de Deadline Cloud en una AWS CloudShell pestaña. Deje que los trabajos enviados anteriormente terminen de ejecutarse. A continuación, elimine los registros de trabajos del directorio de registros: ``` rm -rf ~/devdemo-logs/queue-* ``` A continuación, envíe un trabajo con este paquete de trabajos. Después de que el trabajador CloudShell ejecute sus ejecuciones, observe los registros: ``` # 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 ``` El registro muestra que se detectó un archivo como salida y se cargó en 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. ``` El registro también muestra que Deadline Cloud creó un nuevo objeto de manifiesto en el bucket de Amazon S3 configurado para que lo usen los adjuntos de trabajos en cola`Q1`. El nombre del objeto de manifiesto se deriva de la granja, la cola, el trabajo, el paso, la tarea, la marca de tiempo y los `sessionaction` identificadores de la tarea que generó el resultado. Descarga este archivo de manifiesto para ver dónde ha colocado Deadline Cloud los archivos de salida para esta tarea: ``` # 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 . ``` El manifiesto tiene este aspecto: ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "34178940e1ef9956db8ea7f7c97ed842", "mtime": 1721182390859777, "path": "output_dir/output.txt", "size": 117 } ], "totalSize": 117 } ``` Esto muestra que el contenido del archivo de salida se guarda en Amazon S3 de la misma manera que se guardan los archivos de entrada del trabajo. Al igual que los archivos de entrada, el archivo de salida se almacena en S3 con un nombre de objeto que contiene el hash del archivo y el prefijo`DeadlineCloud/Data`. ``` $ aws s3 ls --recursive s3://$Q1_S3_BUCKET | grep 34178940e1ef9956db8ea7f7c97ed842 2024-07-17 02:13:11 117 DeadlineCloud/Data/34178940e1ef9956db8ea7f7c97ed842.xxh128 ``` Puede descargar el resultado de un trabajo a su estación de trabajo mediante el monitor de Deadline Cloud o la CLI de Deadline Cloud: ``` deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID ``` El valor del parámetro del `OutputDir` trabajo en el trabajo enviado es`./output_dir`, por lo que los resultados se descargan a un directorio llamado `output_dir` dentro del directorio del paquete de trabajos. Si especificó una ruta absoluta o una ubicación relativa diferente como valor`OutputDir`, los archivos de salida se descargarán en esa ubicación. ``` $ 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) ``` # Utilizar archivos de un paso en un paso dependiente Este ejemplo muestra cómo un paso de un trabajo puede acceder a los resultados de un paso del que depende en el mismo trabajo. Para que los resultados de un paso estén disponibles para otro, Deadline Cloud añade acciones adicionales a una sesión para descargar esos resultados antes de ejecutar tareas en la sesión. Para indicarle de qué pasos debe descargar los resultados, debe declarar esos pasos como dependencias del paso que debe utilizar los resultados. Utilice el paquete de `job_attachments_devguide_output` tareas para este ejemplo. Comience por hacer una copia en su AWS CloudShell entorno desde su clon del GitHub repositorio de muestras de Deadline Cloud. Modifíquelo para añadir un paso dependiente que solo se ejecute después del paso existente y utilice el resultado de ese paso: ``` 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 ``` El trabajo creado con este paquete de trabajos modificado se ejecuta en dos sesiones independientes, una para la tarea del paso «Paso» y otra para la tarea del paso «DependentStep». Primero, inicie el agente de trabajo de Deadline Cloud en una CloudShell pestaña. Deje que los trabajos enviados anteriormente terminen de ejecutarse y, a continuación, elimine los registros de trabajos del directorio de registros: ``` rm -rf ~/devdemo-logs/queue-* ``` A continuación, envíe un trabajo con el paquete de `job_attachments_devguide_output` trabajos modificado. Espere a que termine de ejecutarse en el trabajador de su CloudShell entorno. Observe los registros de las dos sesiones: ``` # 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-* ``` En el registro de sesiones de la tarea del paso mencionado`DependentStep`, se ejecutan dos acciones de descarga independientes: ``` 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 primera acción descarga el `script.sh` archivo utilizado por el paso denominado «Paso». La segunda acción descarga los resultados de ese paso. Deadline Cloud determina qué archivos descargar utilizando el manifiesto de salida generado en ese paso como manifiesto de entrada. Al final del mismo registro, puedes ver el resultado del paso denominado "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 ``` # Cree límites de recursos para los trabajos Los trabajos enviados a Deadline Cloud pueden depender de los recursos que se comparten entre varios trabajos. Por ejemplo, una granja puede tener más trabajadores que las licencias flotantes para un recurso específico. O bien, es posible que un servidor de archivos compartido solo pueda entregar datos a un número limitado de trabajadores al mismo tiempo. En algunos casos, uno o más trabajos pueden ocupar todos estos recursos y provocar errores debido a que los recursos no están disponibles cuando comienzan a trabajar nuevos trabajadores. Para ayudar a solucionar este problema, puedes usar *límites* para estos recursos limitados. Deadline Cloud tiene en cuenta la disponibilidad de los recursos limitados y utiliza esa información para garantizar que los recursos estén disponibles a medida que se van incorporando nuevos trabajadores, de forma que los trabajos tengan menos probabilidades de fracasar debido a la falta de recursos. Se establecen límites para toda la granja. Los trabajos enviados a una cola solo pueden adquirir los límites asociados a la cola. Si especificas un límite para un trabajo que no está asociado a la cola, el trabajo no es compatible y no se ejecutará. Para usar un límite, debes + [Crea un límite](job-limit-create.md) + [Asocia un límite y una cola](job-limit-associate.md) + [Envíe un trabajo que requiera límites](job-limit-job.md) **nota** Si ejecuta un trabajo que tiene recursos limitados en una cola que no está asociada a un límite, ese trabajo puede consumir todos los recursos. Si tiene un recurso restringido, asegúrese de que todos los pasos de los trabajos de las colas que utilizan el recurso estén asociados a un límite. En el caso de los límites definidos en una granja, asociados a una cola y especificados en un trabajo, puede ocurrir una de estas cuatro cosas: + Si crea un límite, lo asocia a una cola y especifica el límite en la plantilla de un trabajo, el trabajo se ejecuta y utiliza solo los recursos definidos en el límite. + Si crea un límite, lo especifica en una plantilla de trabajo, pero no lo asocia a una cola, el trabajo se marcará como incompatible y no se ejecutará. + Si crea un límite, no lo asocia a una cola ni especifica el límite en la plantilla de un trabajo, el trabajo se ejecuta pero no utiliza el límite. + Si no utiliza ningún límite, el trabajo se ejecuta. Si asocias un límite a varias colas, las colas comparten los recursos limitados por el límite. Por ejemplo, si crea un límite de 100 y una cola utiliza 60 recursos, las demás colas solo pueden utilizar 40 recursos. Cuando se libera un recurso, una tarea de cualquier cola lo puede ocupar. Deadline Cloud proporciona dos AWS CloudFormation métricas para ayudarte a supervisar los recursos que proporciona un límite. Puede supervisar la cantidad actual de recursos en uso y la cantidad máxima de recursos disponibles dentro del límite. Para obtener más información, consulta [las métricas del límite de recursos](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits) en la *Guía para desarrolladores de Deadline Cloud*. Aplicas un límite a un paso de trabajo en una plantilla de trabajo. Al especificar la cantidad requerida (nombre) de un límite en la `amounts` sección `hostRequirements` de un paso y `amountRequirementName` se asocia un límite con el mismo nombre a la cola de trabajos, las tareas programadas para este paso están restringidas por el límite del recurso. Si un paso requiere un recurso limitado por un límite alcanzado, más trabajadores no se encargarán de las tareas de ese paso. Puede aplicar más de un límite a un paso del trabajo. Por ejemplo, si el paso utiliza dos licencias de software diferentes, puede aplicar un límite diferente para cada licencia. Si un paso requiere dos límites y se alcanza el límite de uno de los recursos, más trabajadores no se encargarán de las tareas de ese paso hasta que los recursos estén disponibles. ## Detener y eliminar los límites Al detener o eliminar la asociación entre una cola y un límite, un trabajo que utilice el límite deja de programar las tareas a partir de los pasos que requieren este límite y bloquea la creación de nuevas sesiones para un paso. Las tareas que están preparadas permanecen listas y las tareas se reanudan automáticamente cuando la asociación entre la cola y el límite vuelve a activarse. No es necesario volver a poner en cola ningún trabajo. Al detener o eliminar la asociación entre una cola y un límite, tiene dos opciones para detener la ejecución de tareas: + Detener y cancelar tareas: los trabajadores con sesiones en las que se ha alcanzado el límite cancelan todas las tareas. + Detener y terminar la ejecución de las tareas: los trabajadores con sesiones que han alcanzado el límite completan sus tareas. Al eliminar un límite mediante la consola, los trabajadores primero dejan de ejecutar las tareas inmediatamente o, finalmente, cuando las terminan. Cuando se elimina la asociación, ocurre lo siguiente: + Los pasos que requieren el límite están marcados como no compatibles. + Se cancela todo el trabajo que contiene esos pasos, incluidos los pasos que no requieren el límite. + El trabajo está marcado como no compatible. Si la cola asociada al límite tiene una flota asociada con una capacidad de flota que coincide con la cantidad requerida (nombre del límite), esa flota seguirá procesando los trabajos con el límite especificado. # Crea un límite Puede crear un límite mediante la consola de Deadline Cloud o la [CreateLimit operación en la API de Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html). Los límites se definen para una granja, pero se asocian a las colas. Tras crear un límite, puede asociarlo a una o más colas. **Para crear un límite** 1. En el panel de la consola de [Deadline Cloud (consola](https://console.aws.amazon.com/deadlinecloud/home) de Deadline Cloud), selecciona la granja para la que quieres crear una cola. 1. Elige la granja a la que quieres añadir el límite, selecciona la pestaña **Límites** y, a continuación, selecciona **Crear límite**. 1. Proporcione los detalles del límite. El **nombre del importe obligatorio** es el nombre utilizado en la plantilla de trabajo para identificar el límite. Debe empezar por el prefijo **amount.** seguido del nombre del importe. El nombre del importe requerido debe ser exclusivo en las colas asociadas al límite. 1. Si elige **Establecer una cantidad máxima**, esa es la cantidad total de recursos permitidos por este límite. Si eliges **Sin cantidad máxima**, el uso de los recursos no está limitado. Incluso cuando el uso de los recursos no está limitado, la CloudWatch métrica de `CurrentCount` Amazon se emite para que puedas realizar un seguimiento del uso. Para obtener más información, consulta [CloudWatchlas métricas](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html) en la *Guía para desarrolladores de Deadline Cloud*. 1. Si ya conoces las colas que deberían usar el límite, puedes elegirlas ahora. No necesitas asociar una cola para crear un límite. 1. Selecciona **Crear límite**. # Asocia un límite y una cola Tras crear un límite, puede asociar una o más colas al límite. Solo las colas asociadas a un límite utilizan los valores especificados en el límite. Para crear una asociación con una cola, utilice la consola de Deadline Cloud o la [CreateQueueLimitAssociation operación de la API de Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html). **Para asociar una cola a un límite** 1. En el panel de la consola de [Deadline Cloud (consola](https://console.aws.amazon.com/deadlinecloud/home) de Deadline Cloud), selecciona la granja a la que quieres asociar un límite a una cola. 1. Selecciona la pestaña **Límites**, elige el límite al que quieres asociar una cola y, a continuación, selecciona **Editar** límite. 1. En la sección **Asociar colas**, elija las colas que desee asociar al límite. 1. Seleccione **Save changes (Guardar cambios)**. # Envíe un trabajo que requiera límites Para aplicar un límite, debe especificarlo como un requisito de anfitrión para el trabajo o paso del trabajo. Si no especificas un límite en un paso y ese paso usa un recurso asociado, el uso del paso no se descuenta del límite cuando se programan los trabajos. Algunos remitentes de Deadline Cloud te permiten establecer un requisito de anfitrión. Puede especificar el nombre del requisito de cantidad del límite en el remitente para aplicar el límite. Si el remitente no admite la adición de requisitos de anfitrión, también puedes aplicar un límite editando la plantilla de trabajo correspondiente al trabajo. **Para aplicar un límite a un paso de trabajo del paquete de trabajos** 1. Abra la plantilla de trabajo del trabajo mediante un editor de texto. La plantilla de trabajo se encuentra en el directorio del paquete de trabajos del trabajo. Para obtener más información, consulte [Paquetes de trabajos](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/build-job-bundle.html) en la *Guía para desarrolladores de Deadline Cloud*. 1. Busca la definición del paso al que quieres aplicar el límite. 1. Añada lo siguiente a la definición del paso. *amount.name*Sustitúyalo por el nombre del importe obligatorio de tu límite. Para un uso normal, debe establecer el `min` valor en 1. ------ #### [ YAML ] ``` hostRequirements: amounts: - name: amount.name min: 1 ``` ------ #### [ JSON ] ``` "hostRequirements": { "amounts": [ { "name": "amount.name", "min": "1" } } } ``` ------ Puede añadir varios límites a un paso de trabajo de la siguiente manera. Sustituya *amount.name\$11* y *amount.name\$12* por los nombres de los requisitos de importe de sus límites. ------ #### [ 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. Guarde los cambios en la plantilla de trabajo. # Cómo enviar un trabajo a Deadline Cloud Hay muchas formas diferentes de enviar trabajos a AWS Deadline Cloud. En esta sección, se describen algunas de las formas en las que puedes enviar trabajos utilizando las herramientas que ofrece Deadline Cloud o creando tus propias herramientas personalizadas para tus cargas de trabajo. + Desde un terminal: para cuando estés desarrollando un paquete de trabajos por primera vez o cuando los usuarios que envíen un trabajo se sientan cómodos usando la línea de comandos + Desde un script: para personalizar y automatizar las cargas de trabajo + Desde una aplicación: para cuando el trabajo del usuario está en una aplicación o cuando el contexto de una aplicación es importante. Los ejemplos siguientes utilizan la biblioteca de `deadline` Python y la herramienta de línea de `deadline` comandos. Ambas están disponibles [PyPi](https://pypi.org/project/deadline/)y [alojadas en GitHub](https://github.com/aws-deadline/deadline-cloud). **Topics** + [Envía un trabajo a Deadline Cloud desde una terminal](from-a-terminal.md) + [Envía un trabajo a Deadline Cloud mediante un script](from-a-script.md) + [Envíe un trabajo dentro de una solicitud](from-within-applications.md) # Envía un trabajo a Deadline Cloud desde una terminal Con solo un paquete de trabajos y la CLI de Deadline Cloud, usted o sus usuarios más técnicos pueden repetir rápidamente la redacción de paquetes de trabajos para probar el envío de un trabajo. Usa el siguiente comando para enviar un paquete de trabajos: ``` deadline bundle submit ``` Si envía un paquete de trabajos con parámetros que no tienen valores predeterminados en el paquete, puede especificarlos con la `--parameter` opción`-p`/. ``` deadline bundle submit -p = -p ... ``` Para obtener una lista completa de las opciones disponibles, ejecute el comando help: ``` deadline bundle submit --help ``` ## Envíe un trabajo a Deadline Cloud mediante una interfaz gráfica La CLI de Deadline Cloud también incluye una interfaz gráfica de usuario que permite a los usuarios ver los parámetros que deben proporcionar antes de enviar un trabajo. Si sus usuarios prefieren no interactuar con la línea de comandos, puede escribir un atajo de escritorio que abra un cuadro de diálogo para enviar un paquete de tareas específico: ``` deadline bundle gui-submit ``` Utilice la `--browse` opción can para que el usuario pueda seleccionar un paquete de trabajos: ``` deadline bundle gui-submit --browse ``` Para obtener una lista completa de las opciones disponibles, ejecute el comando help: ``` deadline bundle gui-submit --help ``` # Envía un trabajo a Deadline Cloud mediante un script Para automatizar el envío de trabajos a Deadline Cloud, puedes programarlos con herramientas como bash, Powershell y archivos por lotes. Puedes añadir funciones como rellenar los parámetros del trabajo a partir de variables de entorno u otras aplicaciones. También puede enviar varios trabajos seguidos o programar la creación de un paquete de trabajos para enviarlos. ## Enviar un trabajo con Python Deadline Cloud también tiene una biblioteca Python de código abierto para interactuar con el servicio. El [código fuente está disponible en GitHub](https://github.com/aws-deadline/deadline-cloud). La biblioteca está disponible en pypi a través de pip (). `pip install deadline` Es la misma biblioteca que utiliza la herramienta CLI de 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) ``` Para crear un diálogo como el `deadline bundle gui-submit` comando, puede utilizar la `show_job_bundle_submitter` función de [`deadline.client.ui.job_bundle_submitter`.](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/job_bundle_submitter.py) En el siguiente ejemplo, se inicia una aplicación de Qt y se muestra el remitente del paquete de tareas: ``` # 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) ``` Para crear su propio diálogo, puede usar la `SubmitJobToDeadlineDialog` clase en [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). Puede transferir valores, incrustar su propia pestaña específica para el trabajo y determinar cómo se crea (o transfiere) el paquete de trabajos. # Envíe un trabajo dentro de una solicitud Para facilitar a los usuarios el envío de trabajos, puede utilizar los tiempos de ejecución de secuencias de comandos o los sistemas de complementos que proporciona una aplicación. Los usuarios disponen de una interfaz familiar y se pueden crear potentes herramientas que les ayuden a enviar una carga de trabajo. ## Inserte paquetes de trabajos en una aplicación En este ejemplo, se muestra el envío de los paquetes de trabajos que usted pone a disposición en la solicitud. Para dar a un usuario acceso a estos paquetes de trabajos, cree un script incrustado en un elemento del menú que inicie la CLI de Deadline Cloud. El siguiente script permite al usuario seleccionar el paquete de trabajos: ``` deadline bundle gui-submit --install-gui ``` Para utilizar en su lugar un paquete de tareas específico en un elemento del menú, utilice lo siguiente: ``` deadline bundle gui-submit --install-gui ``` Esto abre un cuadro de diálogo en el que el usuario puede modificar los parámetros, las entradas y las salidas del trabajo y, a continuación, enviar el trabajo. Puede disponer de diferentes elementos de menú para distintos paquetes de trabajo para que un usuario los envíe en una solicitud. Si el trabajo que envía con un paquete de trabajos contiene parámetros y referencias de activos similares en todas las solicitudes, puede rellenar los valores predeterminados del paquete de trabajos subyacente. ## Obtenga información de una solicitud Para extraer información de una aplicación para que los usuarios no tengan que añadirla manualmente a la presentación, puedes integrar Deadline Cloud con la aplicación para que tus usuarios puedan enviar los trabajos mediante una interfaz familiar sin necesidad de salir de la aplicación ni utilizar herramientas de línea de comandos. Si su aplicación tiene un tiempo de ejecución de secuencias de comandos compatible con Python y pyside/pyqt, puede usar los componentes de la interfaz gráfica de usuario de la [biblioteca de clientes de Deadline Cloud para crear](https://github.com/aws-deadline/deadline-cloud) una interfaz de usuario. Para ver un ejemplo, consulta la integración de [Deadline Cloud para Maya en](https://github.com/aws-deadline/deadline-cloud-for-maya). GitHub La biblioteca de clientes de Deadline Cloud proporciona operaciones que hacen lo siguiente para ayudarlo a brindar una experiencia de usuario sólida e integrada: + Extraiga los parámetros del entorno de colas, los parámetros de los trabajos y las referencias a los activos desde las variables de entorno y mediante una llamada al SDK de la aplicación. + Establezca los parámetros en el paquete de tareas. Para evitar modificar el paquete original, debe hacer una copia del paquete y enviar la copia. Si utiliza el `deadline bundle gui-submit` comando para enviar el paquete de tareas, debe utilizar los `asset_references.yaml` archivos `parameter_values.yaml` y mediante programación para pasar la información de la aplicación. Para obtener más información sobre estos archivos, consulte. [Plantillas Open Job Description (OpenJD) para Deadline Cloud](build-job-bundle.md) Si necesita controles más complejos que los que ofrece OpenJD, necesita abstraer el trabajo del usuario o quiere que la integración se adapte al estilo visual de la aplicación, puede escribir su propio cuadro de diálogo que llame a la biblioteca de clientes de Deadline Cloud para enviar el trabajo. # Programe trabajos en Deadline Cloud Una vez creado un trabajo, AWS Deadline Cloud lo programa para que se procese en una o más de las flotas asociadas a una cola. La flota que procesa una tarea en particular se elige en función de las capacidades configuradas para la flota y los requisitos del anfitrión de un paso específico. Los trabajos de una cola se programan siguiendo el orden de prioridad de mayor a menor, de mayor a menor. Cuando dos trabajos tienen la misma prioridad, el trabajo más antiguo se programa primero. En las siguientes secciones se proporcionan detalles del proceso de programación de un trabajo. ## Determine la compatibilidad de la flota Una vez creado un trabajo, Deadline Cloud compara los requisitos de alojamiento para cada paso del trabajo con las capacidades de las flotas asociadas a la cola a la que se envió el trabajo. Si una flota cumple con los requisitos de hospedaje, el trabajo pasa a manos del `READY` estado. Si algún paso del trabajo tiene requisitos que una flota asociada a la cola no puede cumplir, el estado del paso se establece en. `NOT_COMPATIBLE` Además, el resto de los pasos del trabajo se cancelan. Las capacidades de una flota se establecen a nivel de flota. Incluso si un trabajador de una flota cumple con los requisitos del trabajo, no se le asignarán tareas del trabajo si su flota no cumple con los requisitos del trabajo. La siguiente plantilla de trabajo tiene un paso que especifica los requisitos de anfitrión para el paso: ``` 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 ``` Este trabajo se puede programar para una flota con las siguientes capacidades: ``` { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } ``` Este trabajo no se puede programar para una flota con ninguna de las siguientes capacidades: ``` { "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. ``` ## Escalado de flotas Cuando se asigna un trabajo a una flota compatible gestionada por un servicio, la flota se escala automáticamente. La cantidad de trabajadores de la flota cambia en función de la cantidad de tareas disponibles para la flota. Cuando se asigna un trabajo a una flota gestionada por el cliente, es posible que ya existan trabajadores o que se puedan crear mediante el escalado automático basado en eventos. Para obtener más información, consulte [Uso EventBridge para gestionar eventos de autoescalado](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) en la Guía del *usuario de Amazon EC2 Auto Scaling*. ## Sesiones Las tareas de un trabajo se dividen en una o más sesiones. Los trabajadores dirigen las sesiones para configurar el entorno, ejecutar las tareas y, a continuación, desmantelar el entorno. Cada sesión se compone de una o más acciones que el trabajador debe realizar. A medida que un trabajador completa las acciones de la sección, se le pueden enviar acciones de sesión adicionales. El trabajador reutiliza los entornos existentes y los adjuntos de trabajo en la sesión para completar las tareas de manera más eficiente. En el caso de los trabajadores de flotas gestionados por el servicio, los directorios de las sesiones se eliminan una vez finalizada la sesión, pero los demás directorios se conservan entre sesiones. Este comportamiento le permite implementar estrategias de almacenamiento en caché para los datos que se pueden reutilizar en varias sesiones. Para almacenar en caché los datos entre sesiones, guárdelos en el directorio principal del usuario que ejecuta el trabajo. Por ejemplo, los paquetes conda se almacenan en caché en el directorio principal del usuario del trabajo, en `C:\Users\job-user\.conda-pkgs` on Windows workers y `/home/job-user/.conda-pkgs` on Linux workers. Estos datos permanecen disponibles hasta que el trabajador deje de trabajar. El remitente crea los adjuntos de trabajo y los utilizas como parte de tu paquete de trabajos CLI de Deadline Cloud. También puede crear adjuntos de trabajo mediante la `--attachments` opción del `create-job` AWS CLI comando. Los entornos se definen en dos lugares: los entornos de cola adjuntos a una cola específica y los entornos de tareas y escalones definidos en la plantilla de trabajos. Hay cuatro tipos de acciones de sesión: + `syncInputJobAttachments`— Descarga los archivos adjuntos al trabajo de entrada para el trabajador. + `envEnter`— Realiza las `onEnter` acciones de un entorno. + `taskRun`— Realiza las `onRun` acciones de una tarea. + `envExit`— Realiza las `onExit` acciones para un entorno. La siguiente plantilla de trabajo tiene un entorno escalonado. Tiene una `onEnter` definición para configurar el entorno escalonado, una `onRun` definición que define la tarea que se va a ejecutar y una `onExit` definición para desmantelar el entorno escalonado. Las sesiones creadas para este trabajo incluirán una `envEnter` acción, una o más `taskRun` acciones y, a continuación, una `envExit` acción. ``` 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 }} ``` ### Canalización de las acciones de la sesión La canalización de acciones de sesión permite a un programador preasignar varias acciones de sesión a un trabajador. A continuación, el trabajador puede ejecutar estas acciones de forma secuencial, lo que reduce o elimina el tiempo de inactividad entre tareas. Para crear una asignación inicial, el planificador crea una sesión con una tarea, el trabajador completa la tarea y, a continuación, el planificador analiza la duración de la tarea para determinar las futuras asignaciones. Para que el programador sea efectivo, existen reglas de duración de las tareas. Para las tareas de menos de un minuto, el programador utiliza un patrón de crecimiento de 2 potencias. Por ejemplo, para una tarea de 1 segundo, el planificador asigna 2 tareas nuevas, luego 4 y luego 8. Para las tareas de más de un minuto, el planificador asigna solo una nueva tarea y la canalización permanece desactivada. Para calcular el tamaño de la canalización, el programador hace lo siguiente: + Utiliza la duración media de las tareas completadas + Su objetivo es mantener ocupado al trabajador durante un minuto + Considera solo las tareas de la misma sesión + No comparte los datos de duración entre los trabajadores Con la canalización de las acciones de la sesión, los trabajadores comienzan nuevas tareas de forma inmediata y no hay tiempo de espera entre las solicitudes del programador. También proporciona una mayor eficiencia de los trabajadores y una mejor distribución de las tareas para los procesos de larga duración. Además, si hay disponible un nuevo trabajo de mayor prioridad, el trabajador terminará todo el trabajo que se le asignó anteriormente antes de que finalice la sesión actual y se le asigne una nueva sesión de un trabajo de mayor prioridad. ## Dependencias escalonadas Deadline Cloud permite definir las dependencias entre los pasos, de modo que un paso espere a que se complete otro paso antes de empezar. Puedes definir más de una dependencia para un paso. Un paso con una dependencia no se programa hasta que todas sus dependencias estén completas. Si la plantilla de trabajo define una dependencia circular, el trabajo se rechaza y su estado se establece en. `CREATE_FAILED` La siguiente plantilla de trabajo crea un trabajo en dos pasos. `StepB`depende de`StepA`. `StepB`solo se ejecuta después de que `StepA` se complete correctamente. Una vez creado el trabajo, `StepA` se encuentra en el `READY` estado y `StepB` se encuentra en el `PENDING` estado. Una vez `StepA` finalizado, `StepB` pasa al `READY` estado. Si `StepA` se produce un error o `StepA` se cancela, `StepB` pasa al `CANCELED` estado. Puede establecer una dependencia en varios pasos. Por ejemplo, si `StepC` depende de ambos `StepA` pasos`StepB`, `StepC` no empezará hasta que finalicen los otros dos pasos. Las dependencias escalonadas tienen las siguientes restricciones: + **Dependencias por paso**: un paso puede depender de un máximo de otros 128 pasos. + **Consumidores por paso**: un máximo de otros 32 pasos pueden depender de un solo paso. ``` 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! ``` # Modificar un trabajo en Deadline Cloud Puede usar los siguientes `update` comandos AWS Command Line Interface (AWS CLI) para modificar la configuración de un trabajo o para establecer el estado objetivo de un trabajo, paso o tarea: `` + `aws deadline update-job` + `aws deadline update-step` + `aws deadline update-task` En los siguientes ejemplos de `update` comandos, sustituya cada uno *`user input placeholder`* por su propia información. **Example — Volver a poner en cola un trabajo** Todas las tareas del trabajo cambian al `READY` estado, a menos que haya dependencias entre pasos. Los pasos con dependencias cambian a uno `READY` o a `PENDING` medida que se restauran. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status PENDING ``` **Example — Cancelar un trabajo** Todas las tareas del trabajo que no tienen el estado `SUCCEEDED` o `FAILED` están marcadas`CANCELED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status CANCELED ``` **Example — Marcar un trabajo fallido** Todas las tareas del trabajo que tienen ese estado `SUCCEEDED` permanecen sin cambios. Todas las demás tareas están marcadas`FAILED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status FAILED ``` **Example — Marcar un trabajo como exitoso** Todas las tareas del trabajo se trasladan al `SUCCEEDED` estado. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUCCEEDED ``` **Example — Suspender un trabajo** Las tareas del trabajo en el `FAILED` estado `SUCCEEDED``CANCELED`, o no cambian. Todas las demás tareas están marcadas`SUSPENDED`. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUSPENDED ``` **Example — Cambiar la prioridad de un trabajo** Actualiza la prioridad de un trabajo en una cola para cambiar el orden en que está programado. Por lo general, los trabajos de mayor prioridad se programan primero. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --priority 100 ``` **Example — Cambiar el número de tareas fallidas permitidas** Actualiza el número máximo de tareas fallidas que puede tener el trabajo antes de que se cancelen las tareas restantes. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-failed-tasks-count 200 ``` **Example — Cambia el número de reintentos de tareas permitidos** Actualiza el número máximo de reintentos de una tarea antes de que se produzca un error en la tarea. Una tarea que ha alcanzado el número máximo de reintentos no se puede volver a poner en cola hasta que se aumente este valor. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-retries-per-task 10 ``` **Example — Archivar un trabajo** Actualiza el estado del ciclo de vida del trabajo a`ARCHIVED`. Los trabajos archivados no se pueden programar ni modificar. Solo puede archivar un trabajo que se encuentre en el `SUSPENDED` estado `FAILED``CANCELED`,`SUCCEEDED`, o. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --lifecycle-status ARCHIVED ``` **Example — Cambiar el nombre de un trabajo** Actualiza el nombre para mostrar de un trabajo. El nombre del trabajo puede tener hasta 128 caracteres. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --name "New Job Name" ``` **Example — Cambiar la descripción de un trabajo** Actualiza la descripción de un trabajo. La descripción puede tener una longitud máxima de 2048 caracteres. Para eliminar la descripción existente, pase una cadena vacía. ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --description "New Job Description" ``` **Example — Volver a poner en cola un paso** Todas las tareas del paso cambian al `READY` estado, a menos que haya dependencias entre pasos. Las tareas de los pasos con dependencias cambian a uno `READY` o `PENDING` varios pasos y la tarea se restaura. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status PENDING ``` **Example — Cancelar un paso** Todas las tareas del paso que no tienen el estado `SUCCEEDED` o `FAILED` están marcadas`CANCELED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status CANCELED ``` **Example — Marcar un paso como fallido** Todas las tareas del paso que tienen ese estado `SUCCEEDED` permanecen sin cambios. Todas las demás tareas están marcadas`FAILED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status FAILED ``` **Example — Marcar un paso como exitoso** Todas las tareas del paso están marcadas`SUCCEEDED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUCCEEDED ``` **Example — Suspender un paso** Las tareas del paso en el `FAILED` estado `SUCCEEDED``CANCELED`, o no cambian. Todas las demás tareas están marcadas`SUSPENDED`. ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUSPENDED ``` **Example — Cambiar el estado de una tarea** Al utilizar el comando CLI de `update-task` Deadline Cloud, la tarea cambia al estado especificado. ``` 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 ```