本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 创建要提交到截止日期云的作业您可以使用任务捆绑包向 Deadline Cloud 提交作业。作业捆绑包是文件的集合，包括[开放式作业描述 (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) 作业模板和呈现作业所需的任何资产文件。作业模板描述了工作人员如何处理和访问资产，并提供了工作人员运行的脚本。Job bundle 使美术师、技术总监和管道开发人员能够轻松地从本地工作站或本地渲染农场向 Deadline Cloud 提交复杂作业。Job bundle 对于从事需要可扩展的按需计算资源的大型视觉效果、动画或其他媒体渲染项目的团队特别有用。您可以使用本地文件系统来存储文件，使用文本编辑器来创建作业模板。创建捆绑包后，使用 Deadline Cloud CLI 或 Deadline Cloud 提交者之类的工具将任务提交到 Deadline Cloud 您可以将资产存储在工作人员之间共享的文件系统中，也可以使用 Deadline Cloud 作业附件自动将资产移动到 S3 存储桶，让工作人员可以在那里访问它们。Job 附件还有助于将作业的输出移回工作站。以下各节提供了有关创建工作捆绑包并将其提交到 Deadline Cloud 的详细说明。 **Topics** + [Deadline Cloud 的打开职位描述 (OpenJD) 模板](build-job-bundle.md) + [在作业中使用文件](using-files-in-your-jobs.md) + [使用作业附件共享文件](build-job-attachments.md) + [为作业设置资源限制](build-job-limits.md) + [如何向 Deadline Cloud 提交工作](submit-jobs-how.md) + [在截止日期云中安排作业](build-jobs-scheduling.md) + [在截止日期云中修改作业](build-jobs-modifying.md) # Deadline Cloud 的打开职位描述 (OpenJD) 模板 *任务捆绑包*是你用来为 De AWS adline Cloud 定义作业的工具之一。他们将 Ope [n Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) 模板与附加信息分组，例如您的作业与作业附件一起使用的文件和目录。您可以使用 Deadline Cloud 命令行界面 (CLI) 使用任务捆绑包提交任务以供队列运行。作业捆绑包是一种目录结构，其中包含 OpenJD 作业模板、定义作业的其他文件以及作业输入所需的特定于作业的文件。您可以将定义任务的文件指定为 YAML 或 JSON 文件。唯一需要的文件是`template.yaml`或`template.json`。您还可以包含以下文件： ``` /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 ``` 使用作业捆绑包通过 Deadline Cloud CLI 和作业附件提交自定义作业，也可以使用图形提交界面。例如，以下是来自 Blender 的示例 GitHub。在 [Blender 示例目录](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles)中使用以下命令运行示例： ``` deadline bundle gui-submit blender_render ``` ![\[Blender 的自定义作业提交界面示例。\]](http://docs.aws.amazon.com/zh_cn/deadline-cloud/latest/developerguide/images/blender_submit_shared_settings.png) 特定于作业的设置面板由作业模板中定义的作业参数的`userInterface`属性生成。要使用命令行提交作业，您可以使用类似于以下内容的命令 ``` deadline bundle submit \ --yes \ --name Demo \ -p BlenderSceneFile=location of scene file \ -p OutputDir=file pathe for job output \ blender_render/ ``` 或者你可以使用 `deadline` Python 包中的`deadline.client.api.create_job_from_job_bundle`函数。 Deadline Cloud 提供的所有作业提交者插件，例如 Autodesk Maya 插件，都会生成一个供你提交的作业包，然后使用 Deadline Cloud Python 包将你的作业提交到 Deadline Cloud。您可以在工作站的作业历史目录中查看已提交的作业捆绑包，也可以使用提交者查看。您可以使用以下命令找到您的作业历史目录： ``` deadline config get settings.job_history_dir ``` 当您的作业在 Deadline Cloud 工作线程上运行时，它可以访问环境变量，这些变量为其提供有关该作业的信息。环境变量是： | 变量名称 | 可用 | | --- | --- | | DEADLINE\$1FARM\$1ID | 所有操作 | | DEADLINE\$1FLEET\$1ID | 所有操作 | | DEADLINE\$1WORKER\$1ID | 所有操作 | | 截止日期\$1队列\$1ID | 所有操作 | | 截止日期\$1JOB\$1ID | 所有操作 | | 截止日期\$1STEP\$1ID | 任务操作 | | 截止日期\$1会话\$1ID | 所有操作 | | DEADLINE\$1TASK\$1ID | 任务操作 | | 截止日期会话操作\$1ID | 所有操作 | **Topics** + [作业捆绑包的作业模板元素](build-job-bundle-template.md) + [作业模板的任务分块](build-job-bundle-chunking.md) + [任务捆绑包的参数值元素](build-job-bundle-parameters.md) + [作业捆绑包的资产参考元素](build-job-bundle-assets.md) # 作业捆绑包的作业模板元素作业模板定义了运行时环境和作为 Deadline Cloud 作业的一部分运行的进程。你可以在模板中创建参数，这样它就可以用来创建只在输入值上有所不同的作业，就像编程语言中的函数一样。当您向 Deadline Cloud 提交作业时，该任务将在应用于该队列的任何队列环境中运行。队列环境是使用 Open Job Description (OpenJD) 外部环境规范构建的。有关详细信息，请参阅 OpenJD GitHub 存储库中的[环境模板](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#12-environment-template)。有关使用 OpenJD 作业模板创建作业的[简介，请参阅在 OpenJD GitHub 存储库中创建作业](https://github.com/OpenJobDescription/openjd-specifications/wiki/Introduction-to-Creating-a-Job)简介。更多信息可以在[作业的运行方式](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run)中找到。OpenJD GitHub 存储库的`samples`目录中有作业模板示例。您可以用 YAML 格式 (`template.yaml`) 或 JSON 格式 (`template.json`) 定义作业模板。本节中的示例以 YAML 格式显示。例如，该`blender_render`示例的作业模板将输入参数定义`BlenderSceneFile`为文件路径： ``` - 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. ``` 该`userInterface`属性定义了使用命令的命令行自动生成的用户界面的行为，也定义了在 Autodesk Maya 等应用程序的作业提交插件中自动生成的用户界面的行为。`deadline bundle gui-submit` 在此示例中，用于输入`BlenderSceneFile`参数值的 UI 控件是一个仅显示文件的文件选择对话框。`.blend` ![\[用于输入 OpenJD 作业模板的场景文件参数的用户界面控件。\]](http://docs.aws.amazon.com/zh_cn/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png) 有关使用该`userInteface`元素的更多示例，请参阅存储库中的 [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) 示例。[deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub `objectType`和`dataFlow`属性控制从作业捆绑包提交作业时作业附件的行为。在本例中`objectType: FILE`，and `dataFlow:IN` 表示的值`BlenderSceneFile`是作业附件的输入文件。相比之下，`OutputDir`参数的定义有`objectType: DIRECTORY`和`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. ``` 作业附件使用该`OutputDir`参数的值作为作业写入输出文件的目录。有关`objectType`和`dataFlow`属性的更多信息，请参阅 Ope [n Job Description 规范[JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)](https://github.com/OpenJobDescription/openjd-specifications)中的 `blender_render`作业模板示例的其余部分将作业的工作流程定义为单个步骤，动画中的每一帧都呈现为单独的任务： ``` 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}} ``` 例如，如果`Frames`参数的值为`1-10`，则它定义 10 个任务。每个 has task 的`Frame`参数值都不同。要运行任务，请执行以下操作： 1. 例如，嵌入式文件`data`属性中的所有变量引用都会被展开`--render-frame 1`。 1. 该`data`属性的内容将写入磁盘上会话工作目录中的一个文件中。 1. 任务的`onRun`命令解析为，`bash location of embedded file`然后运行。有关嵌入文件、会话和路径映射位置的更多信息，请参阅 Open [Job Description 规范中的作业运行方式](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run)[。](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) [deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles) 存储库中还有更多作业模板示例，以及随开放职位[描述规范提供的模板示例](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples)。 # 作业模板的任务分块任务分块允许您将多个任务分组为一个工作单元，称为块。例如，在渲染作业中，这意味着 Deadline Cloud 可以一起调度多个帧，而不是每次命令调用一帧。这减少了为每个任务启动应用程序的开销，并缩短了作业的总运行时间。有关详细信息，请参阅 OpenJD 维基中的[一次运行多个帧](https://github.com/OpenJobDescription/openjd-specifications/wiki/Job-Intro-03-Creating-a-Job-Template#42-running-multiple-frames-at-a-time)。 OpenJD 支持为作业模板添加可选功能的扩展。通过添加`TASK_CHUNKING`扩展来启用任务分块。要使用分块，请将扩展添加到您的作业模板中，然后使用`CHUNK[INT]`任务参数类型。使用相同的`deadline bundle submit`命令提交分块作业。例如，以下作业模板以 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 ``` 在此示例中，Deadline Cloud 将 100 个帧分成诸如`1-10``11-20`、之类的块。`{{Task.Param.Frame}}`变量会扩展为范围表达式，例如`1-10`。因为设置`rangeConstraint`为`CONTIGUOUS`，所以范围始终是`start-end`格式化的。该脚本解析此范围，并使用和`-e`选项将起始帧和结束帧传递给 Blender。`-s` `--render-anim` 该`chunks`属性支持以下字段： + `defaultTaskCount`—（必填）要将多少任务合并成一个块。最大值为 150。 + `rangeConstraint`—（必需）如果`CONTIGUOUS`，则区块始终是一个连续的范围，例如。`1-10`如果`NONCONTIGUOUS`，则区块可以是任意集合，比如`1,3,7-10`。 + `targetRuntimeSeconds`—（可选）每个区块的目标运行时间（以秒为单位）。在某些区块完成后，Deadline Cloud 可以动态调整区块大小以接近该目标。有关更多任务分块示例，包括包含连续和非连续区块的基本示例和 Blender 示例，请参阅 Deadline Cloud [示例存储库中的任务分块](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking)示例。 GitHub **客户管理的车队要求** 任务分块需要兼容的工作器代理版本。如果您使用客户管理的队列，请确保在提交带有分块的作业之前更新您的工作人员代理。服务托管队列始终使用兼容的工作代理版本。 **正在下载分块作业的输出** 当你下载分块作业中单个任务的输出时，Deadline Cloud 会下载整个区块的输出。例如，如果将第 1-10 帧一起处理，则下载第 3 帧的输出将包括所有 1-10 帧。此功能需要`deadline-cloud`版本 0.53.3 或更高版本。 # 任务捆绑包的参数值元素您可以使用参数文件来设置任务模板中某些任务参数的值或任务捆绑包中的[CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)操作请求参数的值，这样在提交任务时就无需设置值。提交作业的用户界面允许您修改这些值。您可以用 YAML 格式 (`parameter_values.yaml`) 或 JSON 格式 (`parameter_values.json`) 定义作业模板。本节中的示例以 YAML 格式显示。在 YAML 中，文件的格式为： ``` parameterValues: - name: value: , , or - name: value: , , or ab ... repeating as necessary ``` `parameterValues`列表中的每个元素都必须是以下元素之一： + 在作业模板中定义的作业参数。 + 在队列环境中为你提交作业的队列定义的作业参数... + 创建作业时传递给`CreateJob`操作的特殊参数。 + `deadline:priority`— 该值必须为整数。它作为[优先级](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-priority)参数传递给`CreateJob`操作。 + `deadline:targetTaskRunStatus`— 该值必须是字符串。它作为[targetTaskRun状态](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus)参数传递给`CreateJob`操作。 + `deadline:maxFailedTasksCount`— 该值必须为整数。它作为 C [maxFailedTasksount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount) 参数传递给`CreateJob`操作。 + `deadline:maxRetriesPerTask`— 该值必须为整数。它作为 T [maxRetriesPerask](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask) 参数传递给`CreateJob`操作。 + `deadline:maxWorkercount`— 该值必须为整数。它作为[maxWorkerCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask)参数传递给`CreateJob`操作。作业模板始终是一个模板，而不是要运行的特定作业。如果某些参数在此文件中未定义值，则参数值文件使作业捆绑包可以充当模板，或者如果所有参数都有值，则可以用作特定的作业提交。例如，[blender\$1render 示例](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render)没有参数文件，其作业模板定义的参数没有默认值。此模板必须用作创建作业的模板。使用此任务捆绑包创建任务后，Deadline Cloud 会将新的任务捆绑包写入作业历史记录目录。例如，当您使用以下命令提交作业时： ``` deadline bundle gui-submit blender_render/ ``` 新的任务捆绑包包含一个包含指定参数的`parameter_values.yaml`文件： ``` % 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 ``` 您可以使用以下命令创建相同的作业： ``` deadline bundle submit ~/.deadline/job_history/$default$/2024-06/2024-06-20-01-JobBundle-Demo/ ``` **注意** 您提交的任务包将保存到您的作业历史记录目录中。你可以使用以下命令找到该目录的位置： ``` deadline config get settings.job_history_dir ``` # 作业捆绑包的资产参考元素你可以使用 Deadline Cloud [作业附件](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html)在工作站和 Deadline Cloud 之间来回传输文件。资产参考文件列出了输入文件和目录，以及附件的输出目录。如果您没有列出此文件中的所有文件和目录，则可以在使用`deadline bundle gui-submit`命令提交作业时选择它们。如果您不使用作业附件，则此文件无效。您可以用 YAML 格式 (`asset_references.yaml`) 或 JSON 格式 (`asset_references.json`) 定义作业模板。本节中的示例以 YAML 格式显示。在 YAML 中，文件的格式为： ``` 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 ``` 在选择要上传到 Amazon S3 的输入或输出文件时，Deadline Cloud 会将文件路径与您的存储配置文件中列出的路径进行比较。存储配置`SHARED`文件中的每个文件系统位置都抽象出安装在工作站和工作主机上的网络文件共享。Deadline Cloud 仅上传不在其中一个文件共享中的文件。有关创建和使用存储配置文件的更多信息，请参阅 Dead [line Cloud *用户指南中的 Deadline Cloud* 中的共享存储](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html)。AWS **Example -由 Deadline Cloud GUI 创建的资产参考文件** 使用以下命令通过 [blender\$1rend](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render) er 示例提交作业。 ``` deadline bundle gui-submit blender_render/ ``` 在 Job **附件选项卡上向作业**添加一些其他文件： ![\[Deadline Cloud 作业提交 GUI 的作业附件窗格。添加输入文件/private/tmp/bundle_demo/a_texture.png and the input directory /private/tmp/bundle_demo/assets。\]](http://docs.aws.amazon.com/zh_cn/deadline-cloud/latest/developerguide/images/blender_submit_add_job_attachments.png) 提交作业后，您可以查看作业历史目录中任务捆绑包中的`asset_references.yaml`文件，以查看 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: [] ``` # 在作业中使用文件您提交给 De AWS adline Cloud 的许多作业都有输入和输出文件。您的输入文件和输出目录可能位于共享文件系统和本地驱动器的组合上。工作需要在这些位置找到内容。Deadline Cloud 提供两种功能，即[作业附件](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html)和[存储配置](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html)文件，它们可以协同工作，帮助您的作业找到所需的文件。 Job 附件有多项好处 + 使用 Amazon S3 在主机之间移动文件 + 将文件从工作站传输到工作主机，反之亦然 + 适用于已启用该功能的队列中的作业 + 主要用于服务管理的车队，但也与客户管理的车队兼容。使用存储配置文件映射工作站和工作主机上共享文件系统位置的布局。当您的工作站和工作主机的位置不同时，此映射可以帮助您的作业找到共享文件和目录，例如使用Windows基于工作站和Linux基于工作主机的跨平台设置。任务附件还使用存储配置文件中的文件系统配置映射来识别通过 Amazon S3 在主机之间穿梭所需的文件。如果您不使用作业附件，并且不需要在工作站和工作主机之间重新映射文件和目录位置，则无需使用存储配置文件对文件共享进行建模。 **Topics** + [示例项目基础架构](sample-project-infrastructure.md) + [存储配置文件和路径映射](storage-profiles-and-path-mapping.md) # 示例项目基础架构要演示如何使用作业附件和存储配置文件，请设置一个包含两个独立项目的测试环境。您可以使用 Deadline Cloud 控制台来创建测试资源。 1. 如果您还没有，请创建一个测试场。要创建场，请按照[创建场中的步骤进行](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html)操作。 1. 在这两个项目中分别为作业创建两个队列。要创建队列，请按照[创建队列中的步骤进行](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html)操作。 1. 创建第一个名为的队列**Q1**。使用以下配置，对所有其他项目使用默认配置。 + 对于任务附件，请选择**创建新的 Amazon S3 存储桶**。 + 选择 “**启用与客户管理的车队的关联**”。 + 对于以用户身份运行，请同时输入 **jobuser** POSIX 用户和群组。 + 对于队列服务角色，创建一个名为的新角色 **AssetDemoFarm-Q1-Role** + 清除默认 conda 队列环境复选框。 1. 创建第二个名为的队列**Q2**。使用以下配置，对所有其他项目使用默认配置。 + 对于任务附件，请选择**创建新的 Amazon S3 存储桶**。 + 选择 “**启用与客户管理的车队的关联**”。 + 对于以用户身份运行，请同时输入 **jobuser** POSIX 用户和群组。 + 对于队列服务角色，创建一个名为的新角色 **AssetDemoFarm-Q2-Role** + 清除默认 conda 队列环境复选框。 1. 创建一个由客户管理的队列来运行两个队列中的作业。要创建队列，请按照[创建客户管理的队列中的步骤进行](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html)操作。使用以下配置： + 对于 **“名称”**，使用**DemoFleet**。 + 对于**舰队类型**，请选择**客户管理** + 对于**舰队服务角色**，创建一个名为 **AssetDemoFarm-Fleet-R** ole 的新角色。 + 请勿将队列与任何队列关联。测试环境假设主机之间使用网络文件共享共享三个文件系统。在此示例中，这些地点的名称如下： + `FSCommon`-包含两个项目通用的输入作业资产。 + `FS1`-包含项目 1 的输入和输出作业资产。 + `FS2`-包含项目 2 的输入和输出作业资产。测试环境还假设有三个工作站，如下所示： + `WSAll`-开发人员在所有项目中使用的Linux基于工作站。共享文件系统的位置是： + `FSCommon`: `/shared/common` + `FS1`: `/shared/projects/project1` + `FS2`: `/shared/projects/project2` + `WS1`-用于项目 1 的Windows基于工作站。共享文件系统的位置是： + `FSCommon`: `S:\` + `FS1`: `Z:\` + `FS2`: 不可用 + `WS1`-用于项目 2 的macOS基于工作站。共享文件系统位置为： + `FSCommon`: `/Volumes/common` + `FS1`: 不可用 + `FS2`: `/Volumes/projects/project2` 最后，为队列中的工作人员定义共享文件系统位置。以下示例将此配置称为`WorkerConfig`。共享位置是： + `FSCommon`: `/mnt/common` + `FS1`: `/mnt/projects/project1` + `FS2`: `/mnt/projects/project2` 您无需设置任何与此配置相匹配的共享文件系统、工作站或工作服务器。演示不需要存在共享地点。 # 存储配置文件和路径映射使用存储配置文件对工作站和工作主机上的文件系统进行建模。每个存储配置文件都描述了其中一个系统配置的操作系统和文件系统布局。本主题介绍如何使用存储配置文件对主机的文件系统配置进行建模，以便 Deadline Cloud 可以为您的作业生成路径映射规则，以及如何根据存储配置文件生成这些路径映射规则。当你向 Deadline Cloud 提交任务时，你可以为该任务提供一个可选的存储配置文件 ID。此存储配置文件描述了提交工作站的文件系统。它描述了作业模板中的文件路径使用的原始文件系统配置。您也可以将存储配置文件与队列关联。存储配置文件描述了队列中所有工作主机的文件系统配置。如果您的工作服务器具有不同的文件系统配置，则必须将这些工作人员分配到服务器场中的不同队列。路径映射规则描述了应如何将路径从作业中的指定方式重新映射到工作主机上路径的实际位置。Deadline Cloud 将作业存储配置文件中描述的文件系统配置与运行该任务的队列的存储配置文件进行比较，以得出这些路径映射规则。 **Topics** + [使用存储配置文件对共享文件系统位置进行建模](modeling-your-shared-filesystem-locations-with-storage-profiles.md) + [为队列配置存储配置文件](configuring-storage-profiles-for-fleets.md) + [为队列配置存储配置文件](storage-profiles-for-queues.md) + [根据存储配置文件派生路径映射规则](deriving-path-mapping-rules-from-storage-profiles.md) # 使用存储配置文件对共享文件系统位置进行建模存储配置文件对其中一个主机配置的文件系统配置进行建模。[示例项目基础架构]()中有四种不同的主机配置。在此示例中，您将为每个配置文件创建单独的存储配置文件。您可以使用以下任一方法创建存储配置文件： + [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 资源 + [AWS 控制台](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html#storage-profile) 存储配置文件由文件系统位置列表组成，每个位置都告诉 Deadline Cloud 与从主机提交或在主机上运行的作业相关的文件系统位置的位置和类型。存储配置文件应仅对与作业相关的位置进行建模。例如，共享`FSCommon`位置位于工作站`WS1`上`S:\`，因此相应的文件系统位置为： ``` { "name": "FSCommon", "path": "S:\\", "type": "SHARED" } ``` 使用以下命令为工作站配置`WS1`、和工作器配置创建存储配置文件`WS2`，`WS3`并`WorkerConfig`使用[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)中的命令创建工作器配置 [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"} ]' ``` **注意** 在服务器场中所有存储配置文件中，必须使用相同的`name`属性值来引用存储配置文件中的文件系统位置。Deadline Cloud 比较名称以确定在生成路径映射规则时，来自不同存储配置文件的文件系统位置指的是相同的位置。 # 为队列配置存储配置文件您可以将队列配置为包含存储配置文件，该配置文件对队列中所有工作人员的文件系统位置进行建模。队列中所有工作人员的主机文件系统配置必须与其队列的存储配置文件相匹配。具有不同文件系统配置的工作人员必须位于不同的队列中。要将队列的配置设置为使用`WorkerConfig`存储配置文件，请使用[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)中的 [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 # 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 } }" ``` # 为队列配置存储配置文件队列的配置包括一份区分大小写的共享文件系统位置名称列表，提交到队列的作业需要访问这些位置。例如，提交到队列的作业`Q1`需要文件系统位置`FSCommon`和。`FS1`提交到队列的作业`Q2`需要文件系统位置`FSCommon`和`FS2`。要将队列的配置设置为需要这些文件系统位置，请使用以下脚本： ``` # 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 ``` 队列的配置还包括允许的存储配置文件列表，这些配置文件适用于提交给该队列的作业以及与该队列关联的队列。队列允许的存储配置文件列表中只允许为队列的所有必需文件系统位置定义文件系统位置的存储配置文件。如果您提交任务时使用的存储配置文件不在队列允许的存储配置文件列表中，则作业将失败。您可以随时向队列提交没有存储配置文件的作业。标有标签`WSAll`的工作站配置`WS1`都有队列所需的文件系统位置（`FSCommon`和`FS1`）`Q1`。需要允许他们向队列提交作业。同样，工作站`WSAll`的配置也`WS2`符合队列的要求`Q2`。需要允许他们向该队列提交作业。使用以下脚本更新两个队列配置，以允许使用这些存储配置文件提交作业： ``` # 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 ``` 如果将`WS2`存储配置文件添加到队列允许的存储配置文件列表中，`Q1`则会失败： ``` $ 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 ``` 这是因为`WS2`存储配置文件不包含该队列`Q1`所需的文件系统位置`FS1`的定义。将配置的队列与不在队列允许的存储配置文件列表中的存储配置文件关联也会失败。例如： ``` $ 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. ``` 要修复错误，请将名为`WorkerConfig`的存储配置文件添加到队列`Q1`和队列允许的存储配置文件列表中`Q2`。然后，将队列与这些队列相关联，以便队列中的工作人员可以运行两个队列中的作业。 ``` # 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 ``` # 根据存储配置文件派生路径映射规则路径映射规则描述了如何将路径从作业重新映射到工作主机上路径的实际位置。当任务在工作程序上运行时，会将该作业的存储配置文件与工作人员队列的存储配置文件进行比较，以得出该任务的路径映射规则。 Deadline Cloud 为队列配置中每个必需的文件系统位置创建映射规则。例如，使用`WSAll`存储配置文件提交到队列的作业`Q1`具有路径映射规则： + `FSComm`: `/shared/common -> /mnt/common` + `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` Deadline Cloud 会为`FSComm`和`FS1`文件系统位置创建规则，但不会为`FS2`文件系统位置创建规则，即使`WSAll`和`WorkerConfig`存储配置文件都定义了也是如此`FS2`。这是因为队列`Q1`的所需文件系统位置列表是`["FSComm", "FS1"]`。您可以通过提交打印出 Ope [n Job Description 路径映射规则文件的作业，然后在作业完成后读取会话日志，来确认使用特定存储配置文件提交的作业可用的路径映射规则](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping)： ``` # 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}}" ] } } } } ] }' ``` 如果您使用 De [adline Cloud CLI](https://pypi.org/project/deadline/) 提交作业，则其配置`settings.storage_profile_id`设置将设置通过 CLI 提交的作业将具有的存储配置文件。要使用`WSAll`存储配置文件提交作业，请设置： ``` deadline config set settings.storage_profile_id $WSALL_ID ``` 要像在示例基础架构中运行一样运行客户管理的工作器，请按照《De *adline Cloud 用户指南》*中的 “[运行工作器代理](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/run-worker.html)” 中的步骤来运行工作器。 AWS CloudShell如果您之前按照这些说明进行操作，请先删除`~/demoenv-logs`和`~/demoenv-persist`目录。此外，在执行此操作之前，请按如下方式设置方向所引用的`DEV_FARM_ID`和`DEV_CMF_ID`环境变量的值： ``` DEV_FARM_ID=$FARM_ID DEV_CMF_ID=$FLEET_ID ``` 作业运行后，您可以在作业的日志文件中看到路径映射规则： ``` cat demoenv-logs/${QUEUE1_ID}/*.log ... JJSON log results (see below) ... ``` 该日志包含`FS1`和`FSComm`文件系统的映射。为了便于阅读，重新格式化了日志条目，如下所示： ``` { "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" } ] ``` 您可以提交具有不同存储配置文件的作业，以查看路径映射规则是如何变化的。 # 使用作业附件共享文件使用*作业附件*使不在共享目录中的文件可用于您的作业，如果输出文件未写入共享目录，则可以捕获这些文件。Job 附件使用 Amazon S3 在主机之间传输文件。文件存储在 S3 存储桶中，如果文件内容未更改，则无需上传文件。在[服务管理的队列](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html)上运行作业时，必须使用作业附件，因为主机不共享文件系统位置。当作业的输入或输出文件存储在共享网络文件系统上时，例如当你的任务包中[包含 shell 或 Python 脚本时，作业](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html)附件对[客户管理的队](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/manage-cmf.html)列也很有用。当您使用 Deadline [Cloud CLI 或 Dead](https://pypi.org/project/deadline/) line Cloud 提交者提交任务捆绑包时，作业附件会使用作业的存储配置文件和队列所需的文件系统位置来识别不在工作主机上且应作为作业提交的一部分上传到 Amazon S3 的输入文件。这些存储配置文件还有助于 Deadline Cloud 识别工作服务器主机位置中的输出文件，这些文件必须上传到 Amazon S3 才能供您的工作站使用。作业附件示例使用和中的服务器场、队列、队列和存储配置文件配置[存储配置文件和路径映射](storage-profiles-and-path-mapping.md)。[示例项目基础架构](sample-project-infrastructure.md)在此之前，您应该仔细阅读这些部分。在以下示例中，您使用示例作业捆绑包作为起点，然后对其进行修改以探索作业附件的功能。Job bundle 是您的工作使用作业附件的最佳方式。它们将目录中的 O [pen](https://github.com/OpenJobDescription/openjd-specifications/wiki) Job Description 作业模板与列出使用任务捆绑包的作业所需的文件和目录的其他文件组合在一起。有关任务捆绑包的更多信息，请参阅[Deadline Cloud 的打开职位描述 (OpenJD) 模板](build-job-bundle.md)。 # 使用作业提交文件借助 Deadline Cloud，您可以启用作业工作流来访问工作主机的共享文件系统位置中不可用的输入文件。Job 附件允许渲染任务访问仅位于本地工作站驱动器或服务管理的队列环境中的文件。提交任务包时，可以包括作业所需的输入文件和目录的列表。Deadline Cloud 识别这些非共享文件，将其从本地计算机上传到 Amazon S3，然后将其下载到工作主机。它简化了将输入资源传输到渲染节点的过程，确保分布式作业执行所需的所有文件均可访问。您可以直接在作业捆绑包中为作业指定文件，使用使用环境变量或脚本提供的作业模板中的参数，以及使用作业的`assets_references`文件。您可以使用其中一种方法或三种方法的组合。您可以为任务的捆绑包指定存储配置文件，使其仅上传本地工作站上已更改的文件。本节使用中的示例任务捆绑包 GitHub 来演示 Deadline Cloud 如何识别任务中要上传的文件、这些文件在 Amazon S3 中的组织方式，以及如何将它们提供给处理您任务的工作主机。 **Topics** + [Deadline Cloud 如何将文件上传到亚马逊 S3](what-job-attachments-uploads-to-amazon-s3.md) + [Deadline Cloud 如何选择要上传的文件](how-job-attachments-decides-what-to-upload-to-amazon-s3.md) + [作业如何查找工作附件输入文件](how-jobs-find-job-attachments-input-files.md) # Deadline Cloud 如何将文件上传到亚马逊 S3 此示例显示 Deadline Cloud 如何将文件从您的工作站或工作主机上传到 Amazon S3，以便共享这些文件。它使用来自的示例任务包 GitHub 和 Deadline Cloud CLI 来提交作业。首先将 De [adline Cloud 示例 GitHub存储库](https://github.com/aws-deadline/deadline-cloud-samples)克隆到您的[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)环境中，然后将`job_attachments_devguide`任务包复制到您的主目录中： ``` git clone https://github.com/aws-deadline/deadline-cloud-samples.git cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide ~/ ``` 安装 De [adline Cloud CLI](https://pypi.org/project/deadline/) 以提交工作捆绑包： ``` pip install deadline --upgrade ``` `job_attachments_devguide`任务包只有一个步骤，任务运行一个 bash shell 脚本，该脚本的文件系统位置作为作业参数传递。作业参数的定义是： ``` ... - name: ScriptFile type: PATH default: script.sh dataFlow: IN objectType: FILE ... ``` 该`dataFlow`属性的`IN`值告诉作业附件，该`ScriptFile`参数的值是作业的输入。该`default`属性的值是作业包目录的相对位置，但也可以是绝对路径。此参数定义将作业包目录中的`script.sh`文件声明为作业运行所需的输入文件。接下来，请确保 Deadline Cloud CLI 没有配置存储配置文件，然后将任务提交到队列`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/ ``` 运行此命令后 Deadline Cloud CLI 的输出如下所示： ``` 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 ``` 当您提交任务时，Deadline Cloud 会先对`script.sh`文件进行哈希处理，然后将其上传到 Amazon S3。 Deadline Cloud 将 S3 存储桶视为内容可寻址的存储。文件上传到 S3 对象。对象名称源自文件内容的哈希值。如果两个文件的内容相同，则无论文件位于何处或名称如何，它们都具有相同的哈希值。这种内容寻址存储使得 Deadline Cloud 能够避免上传已经可用的文件。您可以使用 [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) 来查看上传到 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 ``` 两个对象已上传到 S3： + `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`— 的内容`script.sh`。对象键`87cb19095dd5d78fcaf56384ef0e6241`中的值是文件内容的哈希值，扩展名`xxh128`表示哈希值是以 128 位 [xx](https://xxhash.com/) hash 计算得出的。 + `DeadlineCloud/Manifests///Inputs//a1d221c7fd97b08175b3872a37428e8c_input`— 作业提交的清单对象。````、和的值``是您的服务器场标识符、队列标识符和随机十六进制值。此示例`a1d221c7fd97b08175b3872a37428e8c`中的值是根据字符串`/home/cloudshell-user/job_attachments_devguide`（所在`script.sh`目录）计算得出的哈希值。清单对象包含作为任务提交的一部分上传到 S3 的特定根路径上的输入文件的信息。下载此清单文件 (`aws s3 cp s3://$Q1_S3_BUCKET/`)。其内容类似于： ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "87cb19095dd5d78fcaf56384ef0e6241", "mtime": 1721147454416085, "path": "script.sh", "size": 39 } ], "totalSize": 39 } ``` 这表示文件`script.sh`已上传，该文件内容的哈希值为`87cb19095dd5d78fcaf56384ef0e6241`。此哈希值与对象名称中的值相匹配`DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`。Deadline Cloud 使用它来知道要为该文件的内容下载哪个对象。此文件的完整架构[可在中找到 GitHub](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/job_attachments/asset_manifests/v2023_03_03/validate.py)。使用该[CreateJob 操作](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)时，您可以设置清单对象的位置。您可以使用该[GetJob操作](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html)来查看位置： ``` { "attachments": { "file system": "COPIED", "manifests": [ { "inputManifestHash": "5b0db3d311805ea8de7787b64cbbe8b3", "inputManifestPath": "//Inputs//a1d221c7fd97b08175b3872a37428e8c_input", "rootPath": "/home/cloudshell-user/job_attachments_devguide", "rootPathFormat": "posix" } ] }, ... } ``` # Deadline Cloud 如何选择要上传的文件任务附件考虑上传到 Amazon S3 作为任务输入的文件和目录是： + 在作业捆绑包的作业模板中定义的所有 `PATH`-type 作业参数的值，其`dataFlow`值为`IN`或`INOUT`。 + 在作业捆绑包的资产引用文件中作为输入列出的文件和目录。如果您提交的工作没有存储配置文件，则会上传所有考虑上传的文件。如果您提交带有存储配置文件的任务，则如果文件位于存储配置文件的 `SHARED`-type 文件系统位置，而这些位置也是队列所需的文件系统位置，则不会将其上传到 Amazon S3。这些位置预计将在运行任务的工作服务器主机上可用，因此无需将其上传到 S3。在此示例中，您在 AWS CloudShell 环境`WSAll`中创建`SHARED`文件系统位置，然后将文件添加到这些文件系统位置。使用以下命令： ``` # 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 ``` 接下来，将资产引用文件添加到作业捆绑包中，该文件包含您作为作业输入创建的所有文件。使用以下命令： ``` cat > ${HOME}/job_attachments_devguide/asset_references.yaml << EOF assetReferences: inputs: filenames: - /shared/common/file.txt directories: - /shared/projects/project1 - /shared/projects/project2 EOF ``` 接下来，将 Deadline Cloud CLI 配置为使用`WSAll`存储配置文件提交作业，然后提交任务捆绑包： ``` # 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 会将两个文件上传到 Amazon S3。您可以从 S3 下载任务的清单对象以查看上传的文件： ``` 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 ``` 在此示例中，有一个包含以下内容的清单文件： ``` { "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 } ``` 使用清单的[GetJob 操作](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html)可以查看是否`rootPath`为 “/”。 ``` aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID --query 'attachments.manifests[*]' ``` 一组输入文件的根路径始终是这些文件中最长的公共子路径。如果您的作业是从中提交的，并且由于输入文件位于不同的驱动器上Windows而没有公共子路径，则您会在每个驱动器上看到一个单独的根路径。清单中的路径始终相对于清单的根路径，因此上传的输入文件为： + `/home/cloudshell-user/job_attachments_devguide/script.sh`— 作业包中的脚本文件。 + `/shared/projects/project2/file.txt`— `WSAll` 存储配置`SHARED`文件中文件系统位置中**不**在队列所需文件系统位置列表中的文件`Q1`。文件系统位置 `FSCommon` (`/shared/common/file.txt`) 和 `FS1` (`/shared/projects/project1/file.txt`) 中的文件不在列表中。这是因为这些文件系统位置位于`WSAll`存储配置文件`SHARED`中，并且都在队列中所需的文件系统位置列表中`Q1`。您可以看到在操作中使用特定存储配置文件提交的[GetStorageProfileForQueue 作业](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetStorageProfileForQueue.html)所考虑`SHARED`的文件系统位置。要查询队列`WSAll`的存储配置文件，`Q1`请使用以下命令： ``` 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 ``` # 作业如何查找工作附件输入文件要使任务使用 Deadline Cloud 通过任务附件上传到 Amazon S3 的文件，您的任务需要这些文件可通过工作主机上的文件系统获得。当作业的[会话](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#sessions)在工作服务器主机上运行时，Deadline Cloud 会将作业的输入文件下载到工作服务器主机本地驱动器上的临时目录中，并将每个作业根路径的路径映射规则添加到其在本地驱动器上的文件系统位置。在此示例中，在 AWS CloudShell 选项卡中启动 Deadline Cloud 工作者代理。让之前提交的所有作业完成运行，然后从日志目录中删除作业日志： ``` rm -rf ~/devdemo-logs/queue-* ``` 以下脚本修改作业捆绑包以显示会话临时工作目录中的所有文件和路径映射规则文件的内容，然后使用修改后的捆绑包提交作业： ``` # 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/ ``` 在工作程序在您的 AWS CloudShell 环境中运行作业后，您可以查看作业的运行日志： ``` cat demoenv-logs/queue-*/session*.log ``` 日志显示，会话中发生的第一件事是将作业的两个输入文件下载到工作器上： ``` 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. ``` 接下来是作业`script.sh`运行的输出： + 提交作业时上传的输入文件位于会话临时目录中名称以 “assetroot” 开头的目录下。 + 输入文件的路径已相对于 “assetroot” 目录重新定位，而不是相对于作业输入清单 () 的根路径。`"/"` + 路径映射规则文件包含一个额外的规则，该规则会重新映射`"/"`到 “assetroot” 目录的绝对路径。例如： ``` 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 } ``` **注意** 如果您提交的作业有多个具有不同根路径的清单，则每个根路径都有一个不同的 “assetroot” 命名目录。如果您需要引用某个输入文件、目录或文件系统位置的重定位文件系统位置，则可以处理作业中的路径映射规则文件并自己执行重新映射，也可以将`PATH`类型作业参数添加到作业包中的作业模板中，然后将需要重新映射的值作为该参数的值传递。例如，以下示例修改任务捆绑包使其具有以下作业参数之一，然后提交以文件系统位置`/shared/projects/project2`为其值的作业： ``` 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 ``` 此作业运行的日志文件包含其输出： ``` 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 ``` # 从作业中获取输出文件此示例显示 Deadline Cloud 如何识别您的任务生成的输出文件，决定是否将这些文件上传到 Amazon S3，以及如何在工作站上获取这些输出文件。在本示例中，使用`job_attachments_devguide_output`任务捆绑包而不是`job_attachments_devguide`任务捆绑包。首先，从克隆的 Deadline Cloud 示例 GitHub存储库中复制 AWS CloudShell 环境中的捆绑包： ``` cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide_output ~/ ``` 此任务捆绑包和任务捆绑包之间的重要区别是在作业模板中添加了一个新的作业参数：`job_attachments_devguide` ``` ... parameterDefinitions: ... - name: OutputDir type: PATH objectType: DIRECTORY dataFlow: OUT default: ./output_dir description: This directory contains the output for all steps. ... ``` 参数的`dataFlow`属性具有值`OUT`。Deadline Cloud 使用值为`OUT`或的`dataFlow`作业参数的值`INOUT`作为作业的输出。如果将作为值传递给这类任务参数的文件系统位置重新映射到运行该作业的工作程序上的本地文件系统位置，则 Deadline Cloud 将在该位置查找新文件并将这些文件作为任务输出上传到 Amazon S3。要了解其工作原理，请先在 AWS CloudShell 选项卡中启动 Deadline Cloud 工作器代理。让之前提交的所有作业完成运行。然后从日志目录中删除作业日志： ``` rm -rf ~/devdemo-logs/queue-* ``` 接下来，使用此工作捆绑包提交作业。在你 CloudShell运行的工作线程之后，查看日志： ``` # 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 ``` 日志显示检测到一个文件作为输出并上传到 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. ``` 日志还显示，Deadline Cloud 在 Amazon S3 存储桶中创建了一个新的清单对象，该存储桶配置为供队列中的任务附件使用`Q1`。清单对象的名称源自生成输出的任务的场、队列、作业、步骤、任务、时间戳和`sessionaction`标识符。下载此清单文件，查看 Deadline Cloud 将此任务的输出文件放在哪里： ``` # 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 . ``` 清单如下所示： ``` { "hashAlg": "xxh128", "manifestVersion": "2023-03-03", "paths": [ { "hash": "34178940e1ef9956db8ea7f7c97ed842", "mtime": 1721182390859777, "path": "output_dir/output.txt", "size": 117 } ], "totalSize": 117 } ``` 这表明输出文件内容保存到 Amazon S3 的方法与保存任务输入文件的方式相同。与输入文件类似，输出文件存储在 S3 中，其对象名包含文件哈希值和前缀`DeadlineCloud/Data`。 ``` $ aws s3 ls --recursive s3://$Q1_S3_BUCKET | grep 34178940e1ef9956db8ea7f7c97ed842 2024-07-17 02:13:11 117 DeadlineCloud/Data/34178940e1ef9956db8ea7f7c97ed842.xxh128 ``` 你可以使用 Deadline Cloud 监控器或 Deadline Cloud CLI 将任务的输出下载到你的工作站： ``` deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID ``` 提交的`OutputDir`作业中作业参数的值为`./output_dir`，因此输出将下载到作业捆绑包目录`output_dir`中名为的目录中。如果您将绝对路径或不同的相对位置指定为的值`OutputDir`，则输出文件将改为下载到该位置。 ``` $ 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) ``` # 使用依赖步骤中某个步骤中的文件此示例说明了作业中的一个步骤如何访问同一作业中它所依赖的步骤的输出。为了使一个步骤的输出可供另一个步骤使用，Deadline Cloud 向会话添加了其他操作，以便在会话中运行任务之前下载这些输出。你可以通过将这些步骤声明为需要使用输出的步骤的依赖关系来告诉它从哪些步骤下载输出。在此示例中使用`job_attachments_devguide_output`任务捆绑包。首先，在您的 AWS CloudShell 环境中从克隆的 Deadline Cloud 示例 GitHub存储库中制作一份副本。对其进行修改以添加一个依赖步骤，该步骤仅在现有步骤之后运行并使用该步骤的输出： ``` 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 ``` 使用此修改后的作业捆绑包创建的作业作为两个单独的会话运行，一个用于步骤 “Step” 中的任务，另一个用于步骤 “DependentStep” 中的任务。首先在 CloudShell 选项卡中启动 Deadline Cloud 工作器代理。让之前提交的所有作业完成运行，然后从日志目录中删除作业日志： ``` rm -rf ~/devdemo-logs/queue-* ``` 接下来，使用修改后的任务捆绑包提交`job_attachments_devguide_output`作业。等待它在您 CloudShell 环境中的工作器上完成运行。查看两个会话的日志： ``` # 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-* ``` 在名为的步骤中任务的会话日志中`DependentStep`，有两个单独的下载操作正在运行： ``` 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. ``` 第一个操作下载名为 “Step” 的步骤所使用的`script.sh`文件。第二个操作下载该步骤的输出。Deadline Cloud 使用该步骤生成的输出清单作为输入清单来确定要下载哪些文件。在同一篇日志的后面，你可以看到名为 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 ``` # 为作业设置资源限制提交到 Deadline Cloud 的作业可能取决于多个作业之间共享的资源。例如，对于特定资源，农场的工人人数可能多于浮动许可证。或者，共享文件服务器可能只能同时向有限数量的工作人员提供数据。在某些情况下，一个或多个作业可能会占用所有这些资源，从而在新员工开始工作时由于资源不可用而导致错误。为了帮助解决这个问题，你可以对这些受*限*的资源使用限制。Deadline Cloud 考虑了受限资源的可用性，并使用这些信息来确保在新员工启动时资源可用，从而降低由于资源不可用而导致工作失败的可能性。为整个服务器场创建了限制。提交到队列的作业只能获得与队列关联的限制。如果您为与队列无关的作业指定限制，则该作业不兼容且无法运行。要使用限制，您 + [创建限制](job-limit-create.md) + [关联限制和队列](job-limit-associate.md) + [提交需要限制的职位](job-limit-job.md) **注意** 如果您在与限制无关的队列中运行一个资源受限的作业，则该作业可能会消耗所有资源。如果您的资源受限，请确保使用该资源的队列中作业中的所有步骤都与限制相关联。对于在服务器场中定义的限制、与队列关联的限制以及在作业中指定的限制，可能会发生以下四种情况之一： + 如果您创建了限制，将其与队列关联并在作业的模板中指定了限制，则该作业将运行并仅使用限制中定义的资源。 + 如果您创建了限制，在作业模板中指定该限制，但不要将限制与队列相关联，则该作业将被标记为不兼容且无法运行。 + 如果您创建了限制，请勿将其与队列关联，也未在作业模板中指定限制，则作业会运行，但不会使用该限制。 + 如果您根本不使用限制，则作业就会运行。如果您将限制关联到多个队列，则这些队列将共享受该限制约束的资源。例如，如果您创建的限制为 100，而一个队列使用 60 个资源，则其他队列只能使用 40 个资源。资源被释放后，任务可以从任何队列中获取该资源。 Deadline Cloud 提供了两个AWS CloudFormation指标来帮助您监控限额提供的资源。您可以监控当前使用的资源数量以及限制中可用的最大资源数量。有关更多信息，请参阅 De *adline Cloud 开发者指南*中的[资源限制指标](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits)。您可以对作业模板中的作业步骤应用限制。当您在步骤的`amounts`部分中指定限制的金额要求名称，并且与任务队列关联的限制与该限制关联时，为该步骤安排的任务将受到资源限制的限制。`hostRequirements` `amountRequirementName` 如果某个步骤需要的资源受到达到限制的限制，则该步骤中的任务将不会由其他工作人员接管。您可以对一个任务步骤应用多个限制。例如，如果该步骤使用两个不同的软件许可证，则可以为每个许可证应用单独的限制。如果一个步骤需要两个限制，并且已达到其中一个资源的限制，则在资源可用之前，该步骤中的任务不会被其他工作人员接管。 ## 停止和删除限制当您停止或删除队列与限制之间的关联时，使用该限制的作业会停止从需要此限制的步骤中调度任务，并阻止为步骤创建新会话。处于 READY 状态的任务仍处于就绪状态，任务会自动恢复，队列和限制之间的关联再次变为活动状态。您无需重新排队任何作业。停止或删除队列与限制之间的关联时，在如何停止运行任务方面有两种选择： + 停止和取消任务 — 会话达到限制的工作人员会取消所有任务。 + 停止并完成正在运行的任务 — 会话达到限制的工作人员完成任务。使用控制台删除限制时，工作人员首先会立即停止运行任务，或者最终在任务完成后停止运行。删除关联后，会发生以下情况： + 需要限制的步骤标记为 “不兼容”。 + 包含这些步骤的整个任务都将被取消，包括不需要限制的步骤。 + 该作业被标记为不兼容。如果与限制关联的队列的关联队列具有与限制的数量要求名称相匹配的队列，则该队列将继续处理具有指定限制的任务。 # 创建限制您可以使用 Deadline Cloud 控制台或 Deadline C [loud API 中的CreateLimit 操作](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html)来创建限制。限制是为服务器场定义的，但与队列相关联。创建限制后，您可以将其与一个或多个队列关联。 **要创建限制** 1. 从 Deadline Clou [d 控制台（Deadline Cloud 控制台）控制台](https://console.aws.amazon.com/deadlinecloud/home)中，选择要为其创建队列的场。 1. 选择要添加限制的场，选择 “**限制**” 选项卡，然后选择 “**创建限制**”。 1. 提供限制的详细信息。**金额要求名称**是作业模板中用来标识限额的名称。它必须以前缀开头，**amount.**后跟金额名称。金额要求名称在与限额关联的队列中必须是唯一的。 1. 如果您选择 “**设置最大数量**”，则即该限制允许的资源总数。如果选择 “**无最大数量**”，则资源使用量不受限制。即使资源使用不受限制，也会发布 `CurrentCount` Amazon CloudWatch 指标，以便您可以跟踪使用情况。有关更多信息，请参阅 De *adline Cloud 开发者指南*中的[CloudWatch指标](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html)。 1. 如果您已经知道应该使用限制的队列，则可以立即选择它们。您无需关联队列即可创建限制。 1. 选择 “**创建限制**”。 # 关联限制和队列创建限制后，您可以将一个或多个队列与限制相关联。只有与限制关联的队列才使用限制中指定的值。您可以使用 Deadline Cloud 控制台或 Deadline Cloud [API 中的CreateQueueLimitAssociation 操作创建与队列的](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html)关联。 **将队列与限制相关联** 1. 从 Deadline Cl [oud 控制台（Deadline Cloud 控制台）控制台](https://console.aws.amazon.com/deadlinecloud/home)中，选择要将限制与队列关联的场。 1. 选择 “**限制**” 选项卡，选择要与队列关联的限制，然后选择 “**编辑限制”**。 1. 在**关联队列**部分中，选择要与限制关联的队列。 1. 选择**保存更改**。 # 提交需要限制的职位您可以通过将其指定为作业或作业步骤的主机要求来应用限制。如果您未在步骤中指定限制，并且该步骤使用关联的资源，则该步骤的使用量不会计入计划作业时的限制。某些 Deadline Cloud 提交者允许您设置主机要求。您可以在提交者中指定限额的金额要求名称以应用限额。如果您的提交者不支持添加主持人要求，您也可以通过编辑职位的作业模板来应用限制。 **对任务捆绑包中的任务步骤应用限制** 1. 使用文本编辑器打开作业模板。作业模板位于作业的作业捆绑包目录中。有关更多信息，请参阅 De *adline Cloud 开发者指南*中的 [Job 捆绑包](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/build-job-bundle.html)。 1. 找到要应用限制的步骤的步骤定义。 1. 将以下内容添加到步骤定义中。*amount.name*替换为限额的金额要求名称。对于典型用法，应将该`min`值设置为 1。 ------ #### [ YAML ] ``` hostRequirements: amounts: - name: amount.name min: 1 ``` ------ #### [ JSON ] ``` "hostRequirements": { "amounts": [ { "name": "amount.name", "min": "1" } } } ``` ------ 您可以按如下方式向任务步骤添加多个限制。*amount.name\$12*用限额的金额要求名称替换*amount.name\$11*和。 ------ #### [ 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. 保存对作业模板的更改。 # 如何向 Deadline Cloud 提交工作向 De AWS adline Cloud 提交作业的方式有很多。本节介绍使用Deadline Cloud提供的工具或为工作负载创建自己的自定义工具来提交作业的一些方法。 + 从终端——当你第一次开发任务捆绑包时，或者当用户可以轻松地使用命令行提交作业时 + 来自脚本 — 用于自定义和自动化工作负载 + 来自应用程序 — 当用户的工作在应用程序中时，或者当应用程序的上下文很重要时。以下示例使用 `deadline` Python 库和`deadline`命令行工具。两者均可从中获得 [PyPi](https://pypi.org/project/deadline/)，并[托管在上 GitHub](https://github.com/aws-deadline/deadline-cloud)。 **Topics** + [从终端向 Deadline Cloud 提交作业](from-a-terminal.md) + [使用脚本向 Deadline Cloud 提交作业](from-a-script.md) + [在申请中提交工作](from-within-applications.md) # 从终端向 Deadline Cloud 提交作业仅使用任务包和 Deadline Cloud CLI，您或您的技术含量更高的用户就可以快速迭代编写作业捆绑包来测试提交作业。使用以下命令提交任务捆绑包： ``` deadline bundle submit ``` 如果您提交的任务捆绑包的参数在捆绑包中没有默认值，则可以使用`-p`/`--parameter`选项指定它们。 ``` deadline bundle submit -p = -p ... ``` 要查看可用选项的完整列表，请运行 help 命令： ``` deadline bundle submit --help ``` ## 使用 GUI 向 Deadline Cloud 提交作业 Deadline Cloud CLI 还带有图形用户界面，使用户能够在提交作业之前查看他们必须提供的参数。如果您的用户不想与命令行交互，则可以编写一个桌面快捷方式，打开一个对话框来提交特定的任务包： ``` deadline bundle gui-submit ``` 使用 c `--browse` an 选项，这样用户就可以选择任务捆绑包： ``` deadline bundle gui-submit --browse ``` 要查看可用选项的完整列表，请运行 help 命令： ``` deadline bundle gui-submit --help ``` # 使用脚本向 Deadline Cloud 提交作业要自动将作业提交到 Deadline Cloud，你可以使用 bash、Powershell 和批处理文件等工具编写作业脚本。您可以添加诸如从环境变量或其他应用程序填充作业参数之类的功能。您也可以连续提交多个作业，或者编写要提交的任务捆绑包的创建脚本。 ## 使用 Python 提交作业 Deadline Cloud 还有一个用于与该服务进行交互的开源 Python 库。[源代码可在上找到 GitHub](https://github.com/aws-deadline/deadline-cloud)。该库可通过 pip () `pip install deadline` 在 pypi 上使用。它与 Deadline Cloud CLI 工具使用的库相同： ``` 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) ``` 要创建类似`deadline bundle gui-submit`命令的对话框，您可以使用中的`show_job_bundle_submitter`函数[`deadline.client.ui.job_bundle_submitter`。](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/job_bundle_submitter.py) 以下示例启动 Qt 应用程序并显示任务包提交者： ``` # 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) ``` 要创建自己的对话框，你可以使用中的`SubmitJobToDeadlineDialog`类[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)。您可以传入值，嵌入自己的任务特定选项卡，并确定如何创建（或传入）任务包。 # 在申请中提交工作为了便于用户提交作业，您可以使用应用程序提供的脚本运行时或插件系统。用户拥有熟悉的界面，您可以创建强大的工具来帮助用户提交工作负载。 ## 在应用程序中嵌入作业捆绑包此示例演示如何提交您在应用程序中提供的任务捆绑包。要允许用户访问这些任务包，请创建一个嵌入在菜单项中的脚本来启动 Deadline Cloud CLI。以下脚本允许用户选择作业捆绑包： ``` deadline bundle gui-submit --install-gui ``` 要改用菜单项中的特定任务包，请使用以下命令： ``` deadline bundle gui-submit --install-gui ``` 这将打开一个对话框，用户可以在其中修改作业参数、输入和输出，然后提交作业。您可以为不同的工作捆绑包设置不同的菜单项，供用户在应用程序中提交。如果您使用作业捆绑包提交的作业在提交时包含相似的参数和资产引用，则可以在底层作业捆绑包中填写默认值。 ## 从应用程序获取信息要从应用程序中提取信息，这样用户就不必手动将其添加到提交中，您可以将 Deadline Cloud 与应用程序集成，这样您的用户就可以使用熟悉的界面提交作业，而无需退出应用程序或使用命令行工具。如果您的应用程序具有支持 Python 和 pyside/pyqt 的脚本运行时，则可以使用 De [adline Cloud 客户端库](https://github.com/aws-deadline/deadline-cloud)中的 GUI 组件来创建用户界面。有关示例，请参阅上的 [Maya 截止日期云集成](https://github.com/aws-deadline/deadline-cloud-for-maya) GitHub。 Deadline Cloud 客户端库提供的操作可执行以下操作，以帮助您提供强大的集成用户体验： + 通过调用应用程序 SDK 从环境变量中提取队列环境参数、作业参数和资产引用。 + 在作业捆绑包中设置参数。为避免修改原始捆绑包，您应该制作捆绑包的副本并提交副本。如果您使用`deadline bundle gui-submit`命令提交任务捆绑包，则必须以编程方式使用`parameter_values.yaml`和`asset_references.yaml`文件来传递来自应用程序的信息。有关这些文件的更多信息，请参阅[Deadline Cloud 的打开职位描述 (OpenJD) 模板](build-job-bundle.md)。如果您需要比 OpenJD 提供的控件更复杂的控件，需要将作业从用户手中抽象出来，或者想要使集成与应用程序的视觉风格相匹配，则可以编写自己的对话框，调用 Deadline Cloud 客户端库来提交作业。 # 在截止日期云中安排作业任务创建后，De AWS adline Cloud 会安排在与队列关联的一个或多个队列上对其进行处理。处理特定任务的队列是根据为队列配置的功能和特定步骤的主机要求来选择的。队列中的作业按尽力而为的优先顺序进行调度，从高到低。当两个作业具有相同优先级时，将首先安排最早的作业。以下各节详细介绍了安排作业的过程。 ## 确定机队兼容性创建任务后，Deadline Cloud 会根据与提交任务的队列关联的队列的能力来检查作业中每个步骤的主机要求。如果舰队符合主机要求，则该任务将进入该`READY`状态。如果任务中的任何步骤具有与队列关联的队列无法满足的要求，则该步骤的状态将设置为`NOT_COMPATIBLE`。此外，作业中的其余步骤也将被取消。舰队的能力是在舰队级别设置的。即使车队中的工人符合工作要求，如果其车队不符合工作要求，也不会从工作中为其分配任务。以下作业模板的步骤指定了该步骤的主机要求： ``` 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 ``` 可以将此任务安排给具有以下功能的舰队： ``` { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } ``` 无法将此任务安排给具有以下任何功能的舰队： ``` { "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. ``` ## 实例集扩展将任务分配给兼容的服务托管队列时，队列会自动缩放。车队中的工作人员数量会根据可供车队运行的任务数量而变化。将任务分配给客户管理的队列时，工作人员可能已经存在，或者可以使用基于事件的 auto Scaling 创建工作人员。有关更多信息，请参阅 *Amazon EC2 Auto Scaling 用户指南中的用于 EventBridge处理自动扩展*[事件](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html)。 ## 会话作业中的任务分为一个或多个会话。工作人员运行会话来设置环境，运行任务，然后拆除环境。每个会话都由工作人员必须采取的一项或多项操作组成。工作人员完成分区操作后，可以向该工作人员发送其他会话操作。工作人员在会话中重复使用现有环境和作业附件，以更高效地完成任务。在服务管理的车队工作人员上，会话目录将在会话结束后删除，但其他目录将在会话之间保留。此行为允许您为可在多个会话中重复使用的数据实施缓存策略。要在会话之间缓存数据，请将其存储在运行作业的用户的主目录下。例如，conda 包缓存在作业用户的主目录下，位于Windows工作人员和Linux工作人员`C:\Users\job-user\.conda-pkgs``/home/job-user/.conda-pkgs`上。在工作人员关闭之前，这些数据一直可用。作业附件由提交者创建，您将其用作 Deadline Cloud CLI 任务捆绑包的一部分。您也可以使用`create-job` AWS CLI 命令的`--attachments`选项创建作业附件。环境在两个位置定义：附加到特定队列的队列环境以及作业模板中定义的作业和步骤环境。有四种会话操作类型： + `syncInputJobAttachments`— 将输入的作业附件下载给工作人员。 + `envEnter`— 对环境执行`onEnter`操作。 + `taskRun`— 执行任务的`onRun`操作。 + `envExit`— 对环境执行`onExit`操作。以下作业模板具有步骤环境。它有一个`onEnter`用于设置步骤环境的`onRun`定义、一个定义要运行的任务的定义以及一个用于拆除步骤环境的`onExit`定义。为此作业创建的会话将包括一个`envEnter`操作、一个或多个`taskRun`操作，然后是一个`envExit`操作。 ``` 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 }} ``` ### 会话操作流水线会话操作流水线允许调度器将多个会话操作预先分配给工作人员。然后，工作人员可以按顺序运行这些操作，从而减少或消除任务之间的空闲时间。要创建初始分配，调度器会创建一个包含一个任务的会话，工作人员完成任务，然后调度器分析任务持续时间以确定未来的分配。为了使调度程序生效，有任务持续时间规则。对于一分钟以下的任务，调度程序使用 2 的乘方增长模式。例如，对于 1 秒钟的任务，调度器会分配 2 个新任务，然后分配 4 个新任务，然后分配 8 个新任务。对于超过一分钟的任务，调度程序仅分配一个新任务，管道传输仍处于禁用状态。要计算管道大小，调度器会执行以下操作： + 使用已完成任务的平均任务持续时间 + 旨在让员工忙一分钟 + 仅考虑同一会话中的任务 + 不在工作人员之间共享工期数据通过会话操作流水线，工作人员可以立即开始新任务，并且在调度器请求之间没有等待时间。它还为长时间运行的流程提供了更高的员工效率和更好的任务分配。此外，如果有新的更高优先级的作业可用，则工作人员将在当前会话结束之前完成先前分配的所有工作，并分配来自更高优先级作业的新会话。 ## 步骤依赖关系 Deadline Cloud 支持定义步骤之间的依赖关系，以便一个步骤等到另一个步骤完成后再开始。您可以为一个步骤定义多个依赖关系。只有在所有依赖项都完成之后，才会安排具有依赖关系的步骤。如果作业模板定义了循环依赖关系，则该作业将被拒绝，作业状态将设置为`CREATE_FAILED`。以下作业模板创建了一个包含两个步骤的作业。 `StepB`取决于`StepA`。 `StepB`仅在成功`StepA`完成后运行。作业创建后，`StepA`处于`READY`状态并`StepB`处于`PENDING`状态。`StepA`完成后，`StepB`移动到`READY`状态。如果`StepA`失败或已取消，则`StepA``StepB`移至`CANCELED`状态。您可以为多个步骤设置依赖关系。例如，如果同时`StepC`依赖`StepA`和`StepB`，`StepC`则要等到其他两个步骤完成后才会启动。步骤依赖关系具有以下限制： + **每个步骤的依赖关系**-一个步骤最多可以依赖于 128 个其他步骤。 + **每个步骤的使用者** — 单个步骤最多可以有 32 个其他步骤。 ``` 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! ``` # 在截止日期云中修改作业您可以使用以下 AWS Command Line Interface (AWS CLI) `update` 命令修改作业的配置，或者设置作业、步骤或任务的目标状态：`` + `aws deadline update-job` + `aws deadline update-step` + `aws deadline update-task` 在以下命令示例中，将每个`update`命令替换*`user input placeholder`*为您自己的信息。 **Example — 重新排队作业** 除非存在步骤依赖关系，否则作业中的所有任务都会切换到`READY`状态。具有依赖关系的步骤在恢复时切换到任一`READY`或`PENDING`。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status PENDING ``` **Example — 取消作业** 作业中所有没有状态`SUCCEEDED`或已标记`FAILED`的任务`CANCELED`。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status CANCELED ``` **Example — 将任务标记为失败** 作业中所有处于该状态的任务`SUCCEEDED`都保持不变。所有其他任务都已标记`FAILED`。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status FAILED ``` **Example — 将工作标记为成功** 作业中的所有任务都将变为`SUCCEEDED`状态。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUCCEEDED ``` **Example — 暂停作业** 作业中处于`SUCCEEDED``CANCELED`、或`FAILED`状态的任务不会改变。所有其他任务都已标记`SUSPENDED`。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --target-task-run-status SUSPENDED ``` **Example — 更改作业的优先级** 更新队列中任务的优先级以更改其调度顺序。优先级较高的作业通常先安排。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --priority 100 ``` **Example — 更改允许的失败任务数** 更新在取消剩余任务之前该任务可以执行的最大失败任务数。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-failed-tasks-count 200 ``` **Example — 更改允许的任务重试次数** 更新任务失败前任务的最大重试次数。已达到最大重试次数的任务在增加该值之前无法重新排队。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --max-retries-per-task 10 ``` **Example — 存档作业** 将作业的生命周期状态更新为`ARCHIVED`。无法安排或修改已存档的作业。您只能存档处于`FAILED`、`CANCELED``SUCCEEDED`、或`SUSPENDED`状态的作业。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --lifecycle-status ARCHIVED ``` **Example — 更改作业的名称** 更新作业的显示名称。任务名称的长度最多为 128 个字符。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --name "New Job Name" ``` **Example — 更改职位描述** 更新任务描述。描述的长度最多可为 2048 个字符。要删除现有描述，请传递一个空字符串。 ``` aws deadline update-job \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --description "New Job Description" ``` **Example — 重新排队步骤** 除非存在步骤依赖关系，否则步骤中的所有任务都会切换到`READY`状态。具有依赖关系的步骤中的任务会切换到`READY`或`PENDING`，任务将恢复。 ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status PENDING ``` **Example — 取消步骤** 步骤中所有没有状态`SUCCEEDED`或已标记`FAILED`的任务`CANCELED`。 ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status CANCELED ``` **Example — 将步骤标记为失败** 步骤中所有状态为的任务`SUCCEEDED`均保持不变。所有其他任务都已标记`FAILED`。 ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status FAILED ``` **Example — 将步骤标记为成功** 该步骤中的所有任务都已标记`SUCCEEDED`。 ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUCCEEDED ``` **Example — 暂停步骤** 处于`SUCCEEDED``CANCELED`、或`FAILED`状态的步骤中的任务不会更改。所有其他任务都已标记`SUSPENDED`。 ``` aws deadline update-step \ --farm-id farmID \ --queue-id queueID \ --job-id jobID \ --step-id stepID \ --target-task-run-status SUSPENDED ``` **Example — 更改任务的状态** 当您使用 De `update-task` adline Cloud CLI 命令时，任务会切换到指定的状态。 ``` 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 ```