翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Deadline Cloud に送信するジョブを構築する
<a name="building-jobs"></a>

ジョブバンドルを使用して Deadline Cloud にジョブを送信します。ジョブバンドルは、[Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) ジョブテンプレートや、ジョブのレンダリングに必要なアセットファイルを含むファイルのコレクションです。

 ジョブテンプレートは、ワーカーがアセットを処理してアクセスする方法を説明し、ワーカーが実行するスクリプトを提供します。ジョブバンドルを使用すると、アーティスト、テクニカルディレクター、パイプライン開発者は、ローカルワークステーションまたはオンプレミスレンダーファームから Deadline Cloud に複雑なジョブを簡単に送信できます。ジョブバンドルは、スケーラブルなオンデマンドコンピューティングリソースを必要とする大規模な視覚効果、アニメーション、またはその他のメディアレンダリングプロジェクトに取り組むチームにとって特に便利です。

ローカルファイルシステムを使用してファイルを保存し、テキストエディタを使用してジョブバンドルを作成してジョブテンプレートを作成できます。バンドルを作成したら、Deadline Cloud CLI または Deadline Cloud 送信者などのツールを使用して Deadline Cloud にジョブを送信します。

ワーカー間で共有されているファイルシステムにアセットを保存することも、Deadline Cloud ジョブアタッチメントを使用して、ワーカーがアクセスできる S3 バケットへのアセットの移動を自動化することもできます。ジョブアタッチメントは、ジョブからの出力をワークステーションに戻すのにも役立ちます。

 以下のセクションでは、ジョブバンドルを作成して Deadline Cloud に送信する詳細な手順について説明します。

**Topics**
+ [Deadline Cloud の Open Job Description (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)
+ [Deadline Cloud でジョブをスケジュールする](build-jobs-scheduling.md)
+ [Deadline Cloud でジョブを変更する](build-jobs-modifying.md)

# Deadline Cloud の Open Job Description (OpenJD) テンプレート
<a name="build-job-bundle"></a>

*ジョブバンドル*は、Deadline Cloud のジョブを定義するために使用するツールの 1 AWS つです。Open [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 とジョブアタッチメントでカスタムジョブ送信にジョブバンドルを使用するか、グラフィカル送信インターフェイスを使用できます。例えば、GitHub の Blender サンプルは次のとおりです。[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/ja_jp/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/
```

または、Python `deadline` パッケージで `deadline.client.api.create_job_from_job_bundle`関数を使用できます。

Autodesk Maya プラグインなど、Deadline Cloud に付属しているすべてのジョブ送信者プラグインは、送信用のジョブバンドルを生成し、Deadline Cloud Python パッケージを使用してジョブを Deadline Cloud に送信します。送信されたジョブバンドルは、ワークステーションのジョブ履歴ディレクトリまたは送信者を使用して確認できます。ジョブ履歴ディレクトリは、次のコマンドで確認できます。

```
deadline config get settings.job_history_dir
```

ジョブが Deadline Cloud ワーカーで実行されている場合、ジョブに関する情報を提供する環境変数にアクセスできます。環境変数は次のとおりです。


| 変数名 | 使用可能 | 
| --- | --- | 
| DEADLINE\$1FARM\$1ID | すべてのアクション | 
| DEADLINE\$1FLEET\$1ID | すべてのアクション | 
| DEADLINE\$1WORKER\$1ID | すべてのアクション | 
| DEADLINE\$1QUEUE\$1ID | すべてのアクション | 
| DEADLINE\$1JOB\$1ID | すべてのアクション | 
| DEADLINE\$1STEP\$1ID | タスクアクション | 
| DEADLINE\$1SESSION\$1ID | すべてのアクション | 
| DEADLINE\$1TASK\$1ID | タスクアクション | 
| DEADLINE\$1SESSIONACTION\$1ID | すべてのアクション | 

**Topics**
+ [ジョブバンドルのジョブテンプレート要素](build-job-bundle-template.md)
+ [ジョブテンプレートのタスクチャンキング](build-job-bundle-chunking.md)
+ [ジョブバンドルのパラメータ値要素](build-job-bundle-parameters.md)
+ [アセットがジョブバンドルの要素を参照する](build-job-bundle-assets.md)

# ジョブバンドルのジョブテンプレート要素
<a name="build-job-bundle-template"></a>

ジョブテンプレートは、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` プロパティは、 `deadline bundle gui-submit` コマンドを使用するコマンドラインと、Autodesk Maya などのアプリケーションのジョブ送信プラグイン内の両方で自動的に生成されるユーザーインターフェイスの動作を定義します。

この例では、 `BlenderSceneFile`パラメータの値を入力するための UI ウィジェットは、ファイルのみを表示する`.blend`ファイル選択ダイアログです。

![\[OpenJD ジョブテンプレートのシーンファイルパラメータを入力するためのユーザーインターフェイスウィジェット。\]](http://docs.aws.amazon.com/ja_jp/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png)


`userInteface` 要素を使用するその他の例については、GitHub の [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) リポジトリの [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) サンプルを参照してください。

`objectType` および `dataFlow`プロパティは、ジョブバンドルからジョブを送信するときのジョブアタッチメントの動作を制御します。この場合、 `objectType: FILE`と `BlenderSceneFile`は、 の値がジョブアタッチメントの入力ファイルである`dataFlow:IN`ことを意味します。

対照的に、 `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`プロパティの詳細については、[Open Job Description 仕様](https://github.com/OpenJobDescription/openjd-specifications)の[JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)」を参照してください。

残りの`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 個のタスクを定義します。タスクごとに `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)の[「How jobs are run](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run)」を参照してください。

deadline[deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles) リポジトリには、ジョブテンプレートの例と、Open Job Descriptions 仕様で提供されている[テンプレートのサンプル](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples)が他にもあります。

# ジョブテンプレートのタスクチャンキング
<a name="build-job-bundle-chunking"></a>

タスクチャンキングを使用すると、複数のタスクをチャンクと呼ばれる単一の作業単位にグループ化できます。たとえば、レンダリングジョブでは、Deadline Cloud はコマンド呼び出しごとに 1 フレームではなく、複数のフレームを一緒にディスパッチできることを意味します。これにより、各タスクでアプリケーションを起動するオーバーヘッドが軽減され、合計ジョブランタイムが短縮されます。詳細については、OpenJD Wiki の[「一度に複数のフレームを実行する](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`形式です。スクリプトはこの範囲を解析し、 の `-s`および `-e`オプションを使用して開始フレームと終了フレームを Blender に渡します`--render-anim`。

`chunks` プロパティは、次のフィールドをサポートしています。
+ `defaultTaskCount` – (必須) 1 つのチャンクに結合するタスクの数。最大値は 150 です。
+ `rangeConstraint` – (必須) の場合`CONTIGUOUS`、チャンクは常に のような連続した範囲です`1-10`。の場合`NONCONTIGUOUS`、チャンクは のような任意のセットにすることができます`1,3,7-10`。
+ `targetRuntimeSeconds` – (オプション) 各チャンクの秒単位のターゲットランタイム。Deadline Cloud は、いくつかのチャンクが完了すると、このターゲットに近づくようにチャンクサイズを動的に調整できます。

連続チャンクと非連続チャンクの両方を含む基本および Blender の例を含むその他のタスクチャンキングの例については、GitHub の [Deadline Cloud サンプルリポジトリの「タスクチャンキングサンプル](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking)」を参照してください。

**カスタマーマネージドフリートの要件**  
タスクチャンキングには、互換性のあるワーカーエージェントバージョンが必要です。カスタマーマネージドフリートを使用する場合は、チャンキングでジョブを送信する前に、ワーカーエージェントが更新されていることを確認してください。サービスマネージドフリートは常に互換性のあるワーカーエージェントバージョンを使用します。

**チャンクジョブの出力のダウンロード**  
チャンクジョブ内の 1 つのタスクの出力をダウンロードすると、Deadline Cloud はチャンク全体の出力をダウンロードします。例えば、フレーム 1～10 が一緒に処理された場合、フレーム 3 の出力のダウンロードにはすべてのフレーム 1～10 が含まれます。この機能には`deadline-cloud`バージョン 0.53.3 以降が必要です。

# ジョブバンドルのパラメータ値要素
<a name="build-job-bundle-parameters"></a>

パラメータファイルを使用して、ジョブテンプレートまたはジョブバンドルの [CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html) オペレーションリクエスト引数の一部のジョブパラメータの値を設定できるため、ジョブの送信時に値を設定する必要はありません。ジョブ送信用の UI を使用すると、これらの値を変更できます。

ジョブテンプレートは、YAML 形式 (`parameter_values.yaml`) または JSON 形式 () で定義できます`parameter_values.json`。このセクションの例は YAML 形式で示されています。

YAML では、ファイルの形式は次のとおりです。

```
parameterValues:
- name: <string>
  value: <integer>, <float>, or <string>
- name: <string>
  value: <integer>, <float>, or <string>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` – 値は文字列である必要があります。これは [targetTaskRunStatus](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus) パラメータとして `CreateJob`オペレーションに渡されます。
  + `deadline:maxFailedTasksCount` – 値は整数である必要があります。これは、[maxFailedTasksCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount) パラメータとして `CreateJob`オペレーションに渡されます。
  + `deadline:maxRetriesPerTask` – 値は整数である必要があります。[maxRetriesPerTask](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
```

# アセットがジョブバンドルの要素を参照する
<a name="build-job-bundle-assets"></a>

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 は、これらのファイル共有の 1 つにないファイルのみをアップロードします。

ストレージプロファイルの作成と使用の詳細については、[「Deadline Cloud ユーザーガイド」の「Deadline Cloud の共有ストレージ](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html)」を参照してください。 *AWS *

**Example - Deadline Cloud GUI によって作成されたアセットリファレンスファイル**  
次のコマンドを使用して、[Blender\$1render サンプル](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render)を使用してジョブを送信します。  

```
deadline bundle gui-submit blender_render/
```
ジョブアタッチメントタブの**ジョブ**にいくつかのファイルを追加します。  

![\[Deadline Cloud ジョブ送信 GUI のジョブアタッチメントペイン。入力ファイル /private/tmp/bundle_demo/a_texture.png と入力ディレクトリ /private/tmp/bundle_demo/assets を追加します。\]](http://docs.aws.amazon.com/ja_jp/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: []
```

# ジョブでのファイルの使用
<a name="using-files-in-your-jobs"></a>

 AWS Deadline 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)の 2 つの機能があり、ジョブが連携して必要なファイルを見つけるのに役立ちます。

ジョブアタッチメントにはいくつかの利点があります
+ Amazon S3 を使用してホスト間でファイルを移動する
+ ワークステーションからワーカーホストにファイルを転送する、またはその逆
+ この機能を有効にするキュー内のジョブで使用可能
+ 主にサービスマネージドフリートで使用されますが、カスタマーマネージドフリートとも互換性があります。

 ストレージプロファイルを使用して、ワークステーションとワーカーホスト上の共有ファイルシステムの場所のレイアウトをマッピングします。このマッピングは、 ベースのワークステーションと Windowsベースのワーカーホストを使用したクロスプラットフォーム設定など、ワークステーションとワーカーホストで場所が異なる場合に、ジョブが共有ファイルやディレクトリを見つけるのに役立ちますLinux。ファイルシステム設定のストレージプロファイルのマップは、Amazon S3 を介してホスト間で転送する必要があるファイルを識別するために、ジョブアタッチメントによっても使用されます。

 ジョブアタッチメントを使用しておらず、ワークステーションとワーカーホスト間でファイルとディレクトリの場所を再マッピングする必要がない場合は、ストレージプロファイルを使用してファイル共有をモデル化する必要はありません。

**Topics**
+ [サンプルプロジェクトインフラストラクチャ](sample-project-infrastructure.md)
+ [ストレージプロファイルとパスマッピング](storage-profiles-and-path-mapping.md)

# サンプルプロジェクトインフラストラクチャ
<a name="sample-project-infrastructure"></a>

ジョブアタッチメントとストレージプロファイルの使用をデモンストレーションするには、2 つの異なるプロジェクトでテスト環境を設定します。Deadline Cloud コンソールを使用して、テストリソースを作成できます。

1. まだ作成していない場合は、テストファームを作成します。ファームを作成するには、[「ファームの作成](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html)」の手順に従います。

1. 2 つのプロジェクトのそれぞれで、ジョブ用に 2 つのキューを作成します。キューを作成するには、[「キューの作成](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html)」の手順に従います。

   1. という名前の最初のキューを作成します**Q1**。次の設定を使用して、他のすべての項目にデフォルトを使用します。
      + ジョブアタッチメントで、**新しい Amazon S3 バケットを作成する**を選択します。
      + **カスタマーマネージドフリートとの関連付けを有効にする**を選択します。
      + ユーザーとして実行する場合は、POSIX ユーザーとグループ**jobuser**の両方に を入力します。
      + キューサービスロールに、 という名前の新しいロールを作成します。 **AssetDemoFarm-Q1-Role**
      + デフォルトの conda キュー環境チェックボックスをオフにします。

   1. という名前の 2 番目のキューを作成します**Q2**。次の設定を使用して、他のすべての項目にデフォルトを使用します。
      + ジョブアタッチメントで、**新しい Amazon S3 バケットを作成する**を選択します。
      + **カスタマーマネージドフリートとの関連付けを有効にする**を選択します。
      + ユーザーとして実行する場合は、POSIX ユーザーとグループ**jobuser**の両方に を入力します。
      + キューサービスロールに、 という名前の新しいロールを作成します。 **AssetDemoFarm-Q2-Role**
      + デフォルトの conda キュー環境チェックボックスをオフにします。

1. 両方のキューからジョブを実行する単一のカスタマーマネージドフリートを作成します。フリートを作成するには、[「カスタマーマネージドフリートを作成する](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html)」の手順に従います。次の設定を使用します。
   + **名前**には、 を使用します**DemoFleet**。
   + **フリートタイプ** **カスタマーマネージド** を選択する
   + **フリートサービスロール**には、**AssetDemoFarm-Fleet-Role** という名前の新しいロールを作成します。
   + フリートをキューに関連付けないでください。

テスト環境では、ネットワークファイル共有を使用してホスト間で共有されているファイルシステムが 3 つあることを前提としています。この例では、ロケーションの名前は次のとおりです。
+ `FSCommon` - 両方のプロジェクトに共通の入力ジョブアセットが含まれます。
+ `FS1` - プロジェクト 1 の入力ジョブアセットと出力ジョブアセットが含まれます。
+ `FS2` - プロジェクト 2 の入力ジョブアセットと出力ジョブアセットが含まれます。

テスト環境では、次のように 3 つのワークステーションがあることも前提としています。
+ `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`

 この設定に一致する共有ファイルシステム、ワークステーション、またはワーカーをセットアップする必要はありません。デモンストレーションのために共有場所が存在する必要はありません。

# ストレージプロファイルとパスマッピング
<a name="storage-profiles-and-path-mapping"></a>

ストレージプロファイルを使用して、ワークステーションとワーカーホストのファイルシステムをモデル化します。各ストレージプロファイルは、いずれかのシステム設定のオペレーティングシステムとファイルシステムのレイアウトを記述します。このトピックでは、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)

# ストレージプロファイルを使用して共有ファイルシステムの場所をモデル化する
<a name="modeling-your-shared-filesystem-locations-with-storage-profiles"></a>

 ストレージプロファイルは、ホスト設定のいずれかのファイルシステム設定をモデル化します。[サンプルプロジェクトインフラストラクチャ]()には 4 つの異なるホスト設定があります。この例では、それぞれに個別のストレージプロファイルを作成します。ストレージプロファイルは、次のいずれかを使用して作成できます。
+ [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`および [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)の `WorkerConfig`を使用してワーカー設定のストレージプロファイルを作成します[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 は名前を比較して、パスマッピングルールを生成するときに、異なるストレージプロファイルのファイルシステムの場所が同じ場所を参照しているかどうかを確認します。

# フリートのストレージプロファイルを設定する
<a name="configuring-storage-profiles-for-fleets"></a>

フリート内のすべてのワーカーのファイルシステムの場所をモデル化するストレージプロファイルを含めるようにフリートを設定できます。フリート内のすべてのワーカーのホストファイルシステム設定は、フリートのストレージプロファイルと一致する必要があります。ファイルシステム設定が異なるワーカーは、別々のフリートに存在する必要があります。

`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
    }
  }"
```

# キューのストレージプロファイルを設定する
<a name="storage-profiles-for-queues"></a>

 キューの設定には、キューに送信されたジョブがアクセスする必要がある共有ファイルシステムの場所の大文字と小文字を区別する名前のリストが含まれます。たとえば、キューに送信されたジョブにはファイルシステムの場所`FSCommon`と `Q1`が必要です`FS1`。キューに送信されるジョブには、ファイルシステムの場所 `FSCommon` と `Q2`が必要です`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`、キュー に必要なファイルシステムの場所 (`FSCommon` と `FS1`) `WS1`があります`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`ストレージプロファイルに、キュー`FS1`が`Q1`必要とする という名前のファイルシステムの場所の定義が含まれていないためです。

 キューの許可されたストレージプロファイルのリストに含まれていないストレージプロファイルに設定されたフリートの関連付けも失敗します。例えば、次のようになります。

```
$ 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
```

# ストレージプロファイルからパスマッピングルールを取得する
<a name="deriving-path-mapping-rules-from-storage-profiles"></a>

 パスマッピングルールは、ジョブからワーカーホスト上のパスの実際の場所にパスを再マッピングする方法を説明します。タスクがワーカーで実行されている場合、ジョブのストレージプロファイルがワーカーのフリートのストレージプロファイルと比較され、タスクのパスマッピングルールが取得されます。

 Deadline Cloud は、キューの設定に必要なファイルシステムの場所ごとにマッピングルールを作成します。たとえば、`WSAll`ストレージプロファイルを使用してキューに送信されたジョブ`Q1`には、パスマッピングルールがあります。
+  `FSComm`: `/shared/common -> /mnt/common` 
+  `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` 

 Deadline Cloud は、 `FSComm`と `FS1` ファイルシステムの場所のルールを作成しますが、 `WSAll`と の両方の`WorkerConfig`ストレージプロファイルが を定義している場合でも、`FS2`ファイルシステムの場所は作成しません`FS2`。これは、キュー`Q1`の必要なファイルシステムの場所のリストが であるためです`["FSComm", "FS1"]`。

 オープンジョブ[の説明のパスマッピングルールファイルを出力するジョブを送信し、ジョブの完了後にセッションログを読み取ることで、特定のストレージプロファイルで送信されたジョブで使用できるパスマッピングルール](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}}" ]
            }
          }
        }
      }
    ]
  }'
```

 [Deadline Cloud CLI](https://pypi.org/project/deadline/) を使用してジョブを送信する場合、その`settings.storage_profile_id`設定により、CLI で送信されたジョブが持つストレージプロファイルが設定されます。`WSAll` ストレージプロファイルを使用してジョブを送信するには、以下を設定します。

```
deadline config set settings.storage_profile_id $WSALL_ID
```

 サンプルインフラストラクチャで実行されているかのようにカスタマーマネージドワーカーを実行するには、*Deadline 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"
        }
    ]
```

 異なるストレージプロファイルを持つジョブを送信して、パスマッピングルールがどのように変化するかを確認できます。

# ジョブアタッチメントを使用してファイルを共有する
<a name="build-job-attachments"></a>

*ジョブアタッチメント*を使用して、共有ディレクトリにないファイルをジョブで使用できるようにし、共有ディレクトリに書き込まれていない場合は出力ファイルをキャプチャします。ジョブアタッチメントはAmazon S3 を使用してホスト間でファイルをバッファリングします。ファイルは S3 バケットに保存され、コンテンツが変更されていない場合はファイルをアップロードする必要はありません。

ホストはファイルシステムの場所を共有しないため、[サービスマネージドフリート](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html)でジョブを実行するときはジョブアタッチメントを使用する必要があります。ジョブアタッチメントは、ジョブバンドルにシェルや 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](https://pypi.org/project/deadline/) または Deadline Cloud 送信者のいずれかを使用してジョブバンドルを送信すると、ジョブアタッチメントはジョブのストレージプロファイルとキューの必要なファイルシステムの場所を使用して、ワーカーホストになく、ジョブ送信の一部として Amazon S3 にアップロードする必要がある入力ファイルを識別します。これらのストレージプロファイルは、Deadline Cloud がワークステーションで使用できるように Amazon S3 にアップロードする必要があるワーカーホストロケーション内の出力ファイルを識別するのにも役立ちます。

 ジョブアタッチメントの例では、 および のファーム、フリート、キュー、ストレージプロファイル設定を使用します[サンプルプロジェクトインフラストラクチャ](sample-project-infrastructure.md)[ストレージプロファイルとパスマッピング](storage-profiles-and-path-mapping.md)。この前に、これらのセクションを確認してください。

次の例では、サンプルジョブバンドルを開始点として使用し、ジョブアタッチメントの機能を調べるために変更します。ジョブバンドルは、ジョブがジョブアタッチメントを使用するのに最適な方法です。ディレクトリ内の [Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki) ジョブテンプレートと、ジョブバンドルを使用するジョブに必要なファイルとディレクトリを一覧表示する追加ファイルを組み合わせます。ジョブバンドルの詳細については、「」を参照してください[Deadline Cloud の Open Job Description (OpenJD) テンプレート](build-job-bundle.md)。

# ジョブを使用したファイルの送信
<a name="submitting-files-with-a-job"></a>

Deadline Cloud を使用すると、ジョブワークフローを有効にして、ワーカーホストの共有ファイルシステムロケーションで使用できない入力ファイルにアクセスできます。ジョブアタッチメントを使用すると、レンダリングジョブはローカルワークステーションドライブまたはサービスマネージドフリート環境にのみ存在するファイルにアクセスできます。ジョブバンドルを送信するときに、ジョブに必要な入力ファイルとディレクトリのリストを含めることができます。Deadline Cloud は、これらの共有されていないファイルを識別し、ローカルマシンから Amazon S3 にアップロードして、ワーカーホストにダウンロードします。これにより、入力アセットをレンダリングノードに転送するプロセスが合理化され、分散ジョブの実行に必要なすべてのファイルにアクセスできるようになります。

ジョブバンドルでジョブのファイルを直接指定し、環境変数またはスクリプトを使用して指定したジョブテンプレートでパラメータを使用し、ジョブの `assets_references` ファイルを使用できます。これらの方法のいずれか、または 3 つすべての組み合わせを使用できます。ローカルワークステーションで変更されたファイルのみをアップロードするように、ジョブのバンドルのストレージプロファイルを指定できます。

このセクションでは、GitHub のジョブバンドルの例を使用して、Deadline Cloud がアップロードするジョブ内のファイルを識別する方法、それらのファイルを Amazon S3 で整理する方法、およびジョブを処理するワーカーホストがそれらのファイルを使用可能にする方法を示します。

**Topics**
+ [Deadline Cloud が Amazon 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 が Amazon S3 にファイルをアップロードする方法
<a name="what-job-attachments-uploads-to-amazon-s3"></a>

この例では、Deadline Cloud がワークステーションまたはワーカーホストから Amazon S3 にファイルをアップロードして共有できるようにする方法を示します。GitHub と Deadline Cloud CLI のサンプルジョブバンドルを使用してジョブを送信します。

 まず、[Deadline 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 ~/
```

 [Deadline Cloud CLI ](https://pypi.org/project/deadline/)をインストールしてジョブバンドルを送信します。

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

 `job_attachments_devguide` ジョブバンドルには、ファイルシステムの場所がジョブパラメータとして渡される bash シェルスクリプトを実行するタスクを含む 1 つのステップがあります。ジョブパラメータの定義は次のとおりです。

```
...
- 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 オブジェクトにアップロードされます。オブジェクト名は、ファイルの内容のハッシュから派生します。2 つのファイルに同じコンテンツがある場合、ファイルの場所や名前に関係なく、ハッシュ値は同じです。このコンテンツアドレス可能なストレージにより、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
```

 2 つのオブジェクトが S3 にアップロードされました。
+  `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128` – の内容`script.sh`。オブジェクトキー`87cb19095dd5d78fcaf56384ef0e6241`の値はファイルの内容のハッシュであり、拡張子はハッシュ値が 128 ビット [xx ハッシュ](https://xxhash.com/)として計算された`xxh128`ことを示します。
+  `DeadlineCloud/Manifests/<farm-id>/<queue-id>/Inputs/<guid>/a1d221c7fd97b08175b3872a37428e8c_input` – ジョブ送信のマニフェストオブジェクト。値 `<farm-id>`、`<queue-id>`、 `<guid>`はファーム識別子、キュー識別子、ランダムな 16 進値です。この例`a1d221c7fd97b08175b3872a37428e8c`の値は、 が配置されているディレクトリである文字列 から計算`/home/cloudshell-user/job_attachments_devguide`されたハッシュ値`script.sh`です。

 マニフェストオブジェクトには、ジョブの送信の一部として S3 にアップロードされた特定のルートパスの入力ファイルに関する情報が含まれます。このマニフェストファイル () をダウンロードします`aws s3 cp s3://$Q1_S3_BUCKET/<objectname>`。その内容は次のようになります。

```
{
    "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": "<farm-id>/<queue-id>/Inputs/<guid>/a1d221c7fd97b08175b3872a37428e8c_input",
                "rootPath": "/home/cloudshell-user/job_attachments_devguide",
                "rootPathFormat": "posix"
            }
        ]
    },
    ...
}
```

# Deadline Cloud がアップロードするファイルを選択する方法
<a name="how-job-attachments-decides-what-to-upload-to-amazon-s3"></a>

 ジョブアタッチメントが Amazon S3 へのアップロードをジョブへの入力と見なすファイルとディレクトリは次のとおりです。
+  `IN` または の値を持つジョブバンドルのジョブテンプレートで定義されたすべての `PATH`タイプのジョブパラメータ`dataFlow`の値`INOUT`。
+  ジョブバンドルのアセットリファレンスファイルの入力としてリストされているファイルとディレクトリ。

 ストレージプロファイルのないジョブを送信すると、アップロードの対象となるすべてのファイルがアップロードされます。ストレージプロファイルを使用してジョブを送信する場合、ファイルは、キューに必要なファイルシステムの場所であるストレージプロファイルの `SHARED`タイプのファイルシステムの場所にある場合、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
```

 次に、`WSAll`ストレージプロファイルを使用してジョブを送信するように Deadline Cloud CLI を設定し、ジョブバンドルを送信します。

```
# 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 は、ジョブを送信するときに 2 つのファイルを 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
```

 この例では、次の内容のマニフェストファイルが 1 つあります。

```
{
    "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` – キュー に必要な`SHARED`ファイルシステムの場所のリストに含まれ**ていない**`WSAll`ストレージプロファイル内のファイルシステムの場所にあるファイル`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
```

# ジョブがジョブアタッチメント入力ファイルを検索する方法
<a name="how-jobs-find-job-attachments-input-files"></a>

 ジョブアタッチメントを使用して 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
```

ログは、セッションで最初に発生するのは、ジョブの 2 つの入力ファイルがワーカーにダウンロードされることを示しています。

```
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」ディレクトリの絶対パス`"/"`に再マッピングする追加のルールが含まれています。

 例えば、次のようになります。

```
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
```

# ジョブからの出力ファイルの取得
<a name="getting-output-files-from-a-job"></a>

この例では、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 は、`dataFlow`ジョブの出力`INOUT`として `OUT`または の値を持つジョブパラメータの値を使用します。これらの種類のジョブパラメータに値として渡されたファイルシステムの場所が、ジョブを実行するワーカーのローカルファイルシステムの場所に再マッピングされた場合、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 Monitor または 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)
```

# 依存ステップのステップからのファイルの使用
<a name="using-files-output-from-a-step-in-a-dependent-step"></a>

この例では、ジョブの 1 つのステップが同じジョブで依存するステップの出力にアクセスする方法を示します。

 あるステップの出力を別のステップで使用できるようにするために、Deadline Cloud はセッションにアクションを追加して、セッションでタスクを実行する前にそれらの出力をダウンロードします。出力を使用する必要があるステップの依存関係としてこれらのステップを宣言することで、出力を からダウンロードするステップを指示します。

この例の`job_attachments_devguide_output`ジョブバンドルを使用します。まず、Deadline Cloud サンプル GitHub リポジトリのクローンから AWS CloudShell 環境にコピーを作成します。既存のステップの後にのみ実行され、そのステップの出力を使用する依存ステップを追加するように変更します。

```
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
```

 この変更されたジョブバンドルで作成されたジョブは、2 つの異なるセッションとして実行されます。1 つはステップ「Step」のタスク用で、もう 1 つはステップDependentStep」のタスク用です。

まず、CloudShell タブで Deadline Cloud ワーカーエージェントを起動します。以前に送信したジョブの実行を終了し、ログディレクトリからジョブログを削除します。

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

 次に、変更されたジョブバンドルを使用して`job_attachments_devguide_output`ジョブを送信します。CloudShell 環境のワーカーでの実行が完了するまで待ちます。2 つのセッションのログを確認します。

```
# 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`、2 つの個別のダウンロードアクションが実行されます。

```
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`ファイルをダウンロードします。2 番目のアクションは、そのステップから出力をダウンロードします。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
```

# ジョブのリソース制限を作成する
<a name="build-job-limits"></a>

Deadline Cloud に送信されるジョブは、複数のジョブ間で共有されるリソースに依存する場合があります。たとえば、ファームには、特定のリソースのフローティングライセンスよりも多くのワーカーが存在する場合があります。または、共有ファイルサーバーは、同時に限られた数のワーカーにのみデータを提供できます。場合によっては、1 つ以上のジョブがこれらのリソースをすべて要求し、新しいワーカーの起動時にリソースが使用できないためにエラーが発生することがあります。

これを解決するために、これらの制約されたリソース*の制限*を使用できます。Deadline Cloud は、制約されたリソースの可用性を考慮し、その情報を使用して、新しいワーカーの起動時にリソースが利用可能になるようにします。これにより、リソースが利用できないためにジョブが失敗する可能性が低くなります。

制限はファーム全体に作成されます。キューに送信されたジョブは、キューに関連付けられた制限のみを取得できます。キューに関連付けられていないジョブの制限を指定すると、ジョブは互換性がなく、実行されません。

制限を使用するには、
+ [制限を作成する](job-limit-create.md)
+ [制限とキューを関連付ける](job-limit-associate.md)
+ [制限が必要なジョブを送信する](job-limit-job.md)

**注記**  
制限に関連付けられていないキューに制約されたリソースを持つジョブを実行すると、そのジョブはすべてのリソースを消費できます。制約のあるリソースがある場合は、リソースを使用するキュー内のジョブのすべてのステップが制限に関連付けられていることを確認してください。

ファームで定義され、キューに関連付けられ、ジョブで指定されている制限の場合、次の 4 つのことのいずれかが発生する可能性があります。
+ 制限を作成してキューに関連付け、ジョブのテンプレートで制限を指定すると、ジョブが実行され、制限で定義されたリソースのみが使用されます。
+ 制限を作成し、ジョブテンプレートで指定しますが、制限をキューに関連付けない場合、ジョブは互換性がないとマークされ、実行されません。
+ 制限を作成し、キューに関連付けず、ジョブのテンプレートで制限を指定しない場合、ジョブは実行されますが、制限は使用されません。
+ 制限をまったく使用しない場合、ジョブが実行されます。

制限を複数のキューに関連付けると、キューは制限によって制約されるリソースを共有します。たとえば、100 の制限を作成し、1 つのキューが 60 個のリソースを使用している場合、他のキューは 40 個のリソースしか使用できません。リソースが解放されると、任意のキューからタスクがリソースを取得できます。

Deadline Cloud には、制限によって提供されるリソースのモニタリングに役立つ 2 つのAWS CloudFormationメトリクスが用意されています。使用中のリソースの現在の数と、制限内で使用可能なリソースの最大数をモニタリングできます。詳細については、*「Deadline Cloud Developer Guide*」の[「Resource limit metrics](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits)」を参照してください。

ジョブテンプレートのジョブステップに制限を適用します。ステップの `amounts`セクションで制限の量要件名を指定し、同じ を持つ制限`amountRequirementName`がジョブ`hostRequirements`のキューに関連付けられている場合、このステップでスケジュールされるタスクはリソースの制限によって制約されます。

ステップで制限に達したリソースが必要な場合、そのステップのタスクは追加のワーカーによって取得されません。

ジョブステップには複数の制限を適用できます。たとえば、ステップで 2 つの異なるソフトウェアライセンスを使用している場合、ライセンスごとに個別の制限を適用できます。ステップに 2 つの制限が必要で、いずれかのリソースの制限に達した場合、そのステップのタスクは、リソースが利用可能になるまで追加のワーカーによって取得されません。

## 制限の停止と削除
<a name="job-limit-stop-delete"></a>

キューと制限の間の関連付けを停止または削除すると、制限を使用するジョブは、この制限を必要とするステップのタスクのスケジュールを停止し、ステップの新しいセッションの作成をブロックします。

READY 状態のタスクは準備状態のままで、キューと制限間の関連付けによってタスクが自動的に再開され、再びアクティブになります。ジョブを再キューに入れる必要はありません。

キューと制限間の関連付けを停止または削除する場合、タスクの実行を停止する方法には 2 つの選択肢があります。
+ タスクの停止とキャンセル – 制限を取得したセッションを持つワーカーは、すべてのタスクをキャンセルします。
+ 実行中のタスクを停止して終了する – 制限を取得したセッションを持つワーカーはタスクを完了します。

コンソールを使用して制限を削除すると、ワーカーはまずタスクの実行をすぐに停止するか、最終的にタスクの完了時に停止します。関連付けが削除されると、次のようになります。
+ 制限が必要なステップは互換性がないとマークされます。
+ 制限を必要としないステップを含め、これらのステップを含むジョブ全体がキャンセルされます。
+ ジョブは互換性がないとマークされています。

制限に関連付けられたキューに、制限の量要件名と一致するフリート機能を持つフリートが関連付けられている場合、そのフリートは指定された制限でジョブを処理し続けます。

# 制限を作成する
<a name="job-limit-create"></a>

Deadline Cloud コンソールまたは [Deadline Cloud API の CreateLimit オペレーション](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html)を使用して制限を作成します。制限はファームに対して定義されますが、キューに関連付けられます。制限を作成したら、1 つ以上のキューに関連付けることができます。

**制限を作成するには**

1. Deadline Cloud コンソール ([Deadline Cloud コンソール](https://console.aws.amazon.com/deadlinecloud/home)) ダッシュボードから、キューを作成するファームを選択します。

1. 制限を追加するファームを選択し、**制限**タブを選択し、**制限の作成**を選択します。

1. 制限の詳細を入力します。**金額要件名**は、制限を識別するためにジョブテンプレートで使用される名前です。プレフィックスの**amount.**後に金額名が続く必要があります。金額要件名は、制限に関連付けられたキューで一意である必要があります。

1. **最大量を設定する** を選択した場合、これはこの制限で許可されるリソースの合計数です。**最大量なし**を選択した場合、リソース使用量は制限されません。リソースの使用が制限されていない場合でも、`CurrentCount`Amazon CloudWatch メトリクスが出力されるため、使用状況を追跡できます。詳細については、*「Deadline* [CloudWatch metrics](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html)」を参照してください。

1. 制限を使用するキューが既にわかっている場合は、今すぐ選択できます。制限を作成するためにキューを関連付ける必要はありません。

1. **制限の作成** を選択します。

# 制限とキューを関連付ける
<a name="job-limit-associate"></a>

制限を作成したら、1 つ以上のキューを制限に関連付けることができます。制限に関連付けられているキューのみが、制限で指定された値を使用します。

Deadline Cloud コンソールまたは Deadline Cloud [API の CreateQueueLimitAssociation オペレーションを使用して、](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html)キューとの関連付けを作成します。

**キューを制限に関連付けるには**

1. Deadline Cloud コンソール ([Deadline Cloud コンソール](https://console.aws.amazon.com/deadlinecloud/home)) ダッシュボードから、制限をキューに関連付けるファームを選択します。

1. **制限**タブを選択し、キューを関連付ける制限を選択し、**制限の編集**を選択します。

1. **キューの関連付け**セクションで、制限に関連付けるキューを選択します。

1. **[Save changes]** (変更の保存) をクリックします。

# 制限が必要なジョブを送信する
<a name="job-limit-job"></a>

制限を適用するには、制限をジョブまたはジョブステップのホスト要件として指定します。ステップで制限を指定せず、そのステップが関連するリソースを使用する場合、ジョブがスケジュールされたとき、ステップの使用量は制限に対してカウントされません。

一部の Deadline Cloud 送信者では、ホスト要件を設定できます。送信者で制限の金額要件名を指定して、制限を適用できます。

送信者がホスト要件の追加をサポートしていない場合は、ジョブのジョブテンプレートを編集して制限を適用することもできます。

**ジョブバンドルのジョブステップに制限を適用するには**

1. テキストエディタを使用してジョブのジョブテンプレートを開きます。ジョブテンプレートは、ジョブのジョブバンドルディレクトリにあります。詳細については、*Deadline Cloud デベロッパーガイド*の[「ジョブバンドル](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\$11* と *amount.name\$12* を、制限の金額要件名に置き換えます。

------
#### [ 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 にジョブを送信する方法
<a name="submit-jobs-how"></a>

 AWS Deadline Cloud にジョブを送信するには、さまざまな方法があります。このセクションでは、Deadline Cloud が提供するツールを使用するか、ワークロード用に独自のカスタムツールを作成してジョブを送信する方法をいくつか説明します。
+ ターミナルから – ジョブバンドルを初めて開発する場合、またはジョブを送信するユーザーがコマンドラインの使用に慣れている場合
+ スクリプトから – ワークロードのカスタマイズと自動化
+ アプリケーションから – ユーザーの作業がアプリケーションにある場合、またはアプリケーションのコンテキストが重要な場合。

 次の例では、Python `deadline` ライブラリと`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 にジョブを送信する
<a name="from-a-terminal"></a>

ジョブバンドルと Deadline Cloud CLI のみを使用すると、ユーザーまたはより技術的なユーザーは、ジョブバンドルの書き込みをすばやく繰り返してジョブの送信をテストできます。ジョブバンドルを送信するには、次のコマンドを使用します。

```
deadline bundle submit <path-to-job-bundle>
```

 バンドルにデフォルトがないパラメータを含むジョブバンドルを送信する場合は、/ `-p` `--parameter`オプションで指定できます。

```
deadline bundle submit <path-to-job-bundle> -p <parameter-name>=<parameter-value> -p ...
```

 使用可能なオプションの完全なリストについては、ヘルプコマンドを実行します。

```
deadline bundle submit --help
```

## GUI を使用して Deadline Cloud にジョブを送信する
<a name="with-a-submission-window"></a>

 Deadline Cloud CLI には、ジョブを送信する前にユーザーが指定する必要があるパラメータを表示できるようにするグラフィカルユーザーインターフェイスも付属しています。ユーザーがコマンドラインを操作したくない場合は、特定のジョブバンドルを送信するダイアログを開くデスクトップショートカットを記述できます。

```
deadline bundle gui-submit <path-to-job-bundle>
```

 `--browse` オプションを使用すると、ユーザーはジョブバンドルを選択できます。

```
deadline bundle gui-submit --browse
```

 使用可能なオプションの完全なリストについては、ヘルプコマンドを実行します。

```
deadline bundle gui-submit --help
```

# スクリプトを使用して Deadline Cloud にジョブを送信する
<a name="from-a-script"></a>

 Deadline Cloud へのジョブの送信を自動化するには、bash、Powershell、バッチファイルなどのツールを使用してジョブをスクリプト化できます。

環境変数や他のアプリケーションからジョブパラメータを入力するなどの機能を追加できます。複数のジョブを連続して送信したり、送信するジョブバンドルの作成をスクリプト化したりすることもできます。

## Python を使用してジョブを送信する
<a name="with-python"></a>

Deadline Cloud には、 サービスとやり取りするためのオープンソースの Python ライブラリもあります。[ソースコードは GitHub で入手できます](https://github.com/aws-deadline/deadline-cloud)。

ライブラリは pip () 経由で pypi で使用できます`pip install deadline`。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)。値を渡す、独自のジョブ固有のタブを埋め込む、ジョブバンドルの作成 (または渡される) 方法を決定できます。

# アプリケーション内でジョブを送信する
<a name="from-within-applications"></a>

 ユーザーがジョブを簡単に送信できるように、アプリケーションが提供するスクリプトランタイムまたはプラグインシステムを使用できます。ユーザーには使い慣れたインターフェイスがあり、ワークロードの送信時にユーザーを支援する強力なツールを作成できます。

## アプリケーションにジョブバンドルを埋め込む
<a name="simple-embedding"></a>

この例では、アプリケーションで利用できるジョブバンドルを送信する方法を示します。

 これらのジョブバンドルへのアクセス権をユーザーに付与するには、Deadline Cloud CLI を起動するメニュー項目に埋め込まれたスクリプトを作成します。

 次のスクリプトを使用すると、ユーザーはジョブバンドルを選択できます。

```
deadline bundle gui-submit --install-gui
```

 代わりにメニュー項目で特定のジョブバンドルを使用するには、以下を使用します。

```
deadline bundle gui-submit </path/to/job/bundle> --install-gui
```

 これにより、ユーザーがジョブパラメータ、入力、出力を変更し、ジョブを送信できるダイアログが開きます。ユーザーがアプリケーションで送信するジョブバンドルごとに異なるメニュー項目を設定できます。

ジョブバンドルで送信するジョブに、送信間で同様のパラメータとアセット参照が含まれている場合は、基盤となるジョブバンドルのデフォルト値を入力できます。

## アプリケーションから情報を取得する
<a name="deep-integration"></a>

ユーザーが送信に手動で追加する必要がないようにアプリケーションから情報を取得するには、Deadline Cloud をアプリケーションと統合して、ユーザーがアプリケーションを終了したりコマンドラインツールを使用したりすることなく、使い慣れたインターフェイスを使用してジョブを送信できるようにします。

アプリケーションに Python と pyside/pyqt をサポートするスクリプトランタイムがある場合は、[Deadline Cloud クライアントライブラリ](https://github.com/aws-deadline/deadline-cloud)の GUI コンポーネントを使用して UI を作成できます。例については、GitHub の[「Deadline Cloud for Maya integration](https://github.com/aws-deadline/deadline-cloud-for-maya)」を参照してください。

Deadline Cloud クライアントライブラリには、強力な統合ユーザーエクスペリエンスを提供するために以下を実行するオペレーションが用意されています。
+ プルキュー環境パラメータ、ジョブパラメータ、アセットリファレンスは、アプリケーション SDK を呼び出して環境変数を形成します。
+ ジョブバンドルのパラメータを設定します。元のバンドルを変更しないようにするには、バンドルのコピーを作成し、コピーを送信する必要があります。

`deadline bundle gui-submit` コマンドを使用してジョブバンドルを送信する場合は、 `parameter_values.yaml`および `asset_references.yaml` ファイルをプログラムで使用して、アプリケーションから情報を渡す必要があります。これらのファイルの詳細については、「」を参照してください[Deadline Cloud の Open Job Description (OpenJD) テンプレート](build-job-bundle.md)。

OpenJD が提供するコントロールよりも複雑なコントロールが必要な場合、ユーザーからジョブを抽象化する必要がある場合、または統合をアプリケーションのビジュアルスタイルと一致させる場合は、Deadline Cloud クライアントライブラリを呼び出してジョブを送信する独自のダイアログを作成できます。

# Deadline Cloud でジョブをスケジュールする
<a name="build-jobs-scheduling"></a>

ジョブが作成されると、 AWS Deadline Cloud はキューに関連付けられた 1 つ以上のフリートで処理されるようにスケジュールします。特定のタスクを処理するフリートは、フリート用に設定された機能と特定のステップのホスト要件に基づいて選択されます。

キュー内のジョブは、ベストエフォートの優先順位で、最も高い順にスケジュールされます。2 つのジョブの優先度が同じ場合、最も古いジョブが最初にスケジュールされます。

以下のセクションでは、ジョブをスケジュールするプロセスの詳細について説明します。

## フリートの互換性を確認する
<a name="jobs-scheduling-compatibility"></a>

ジョブが作成されると、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.
```

## フリートスケーリング
<a name="jobs-scheduling-scaling"></a>

ジョブが互換性のあるサービスマネージドフリートに割り当てられると、フリートは自動スケーリングされます。フリート内のワーカーの数は、フリートが実行できるタスクの数に応じて変わります。

ジョブがカスタマーマネージドフリートに割り当てられると、ワーカーがすでに存在しているか、イベントベースの自動スケーリングを使用して作成できます。詳細については、*Amazon EC2 Auto Scaling * [ユーザーガイド」のEventBridge を使用して自動スケーリングイベントを処理する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html)」を参照してください。

## セッション
<a name="jobs-scheduling-sessions"></a>

ジョブのタスクは 1 つ以上のセッションに分割されます。ワーカーはセッションを実行して環境をセットアップし、タスクを実行してから、環境を破棄します。各セッションは、ワーカーが実行する必要がある 1 つ以上のアクションで構成されます。

ワーカーがセクションアクションを完了すると、追加のセッションアクションをワーカーに送信できます。ワーカーは、セッション内の既存の環境とジョブアタッチメントを再利用して、タスクをより効率的に完了します。

サービスマネージドフリートワーカーでは、セッションディレクトリはセッション終了後に削除されますが、他のディレクトリはセッション間で保持されます。この動作により、複数のセッションで再利用できるデータのキャッシュ戦略を実装できます。セッション間でデータをキャッシュするには、ジョブを実行しているユーザーのホームディレクトリに保存します。たとえば、conda パッケージは、ワーカーの とWindowsワーカーの `C:\Users\job-user\.conda-pkgs`のジョブユーザーのホームディレクトリ`/home/job-user/.conda-pkgs`にキャッシュされますLinux。このデータは、ワーカーがシャットダウンするまで引き続き使用できます。

ジョブアタッチメントは、Deadline Cloud CLI ジョブバンドルの一部として使用する送信者によって作成されます。`create-job` AWS CLI コマンドの `--attachments`オプションを使用してジョブアタッチメントを作成することもできます。環境は、特定のキューにアタッチされたキュー環境と、ジョブテンプレートで定義されたジョブ環境とステップ環境の 2 つの場所で定義されます。

セッションアクションには 4 つのタイプがあります。
+ `syncInputJobAttachments` – 入力ジョブの添付ファイルをワーカーにダウンロードします。
+ `envEnter` – 環境の`onEnter`アクションを実行します。
+ `taskRun` – タスクの`onRun`アクションを実行します。
+ `envExit` – 環境の`onExit`アクションを実行します。

次のジョブテンプレートにはステップ環境があります。ステップ環境を設定する`onEnter`定義、実行するタスクを定義する`onRun`定義、ステップ環境を破棄する`onExit`定義があります。このジョブ用に作成されたセッションには、 `envEnter`アクション、1 つ以上の `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 }}
```

### セッションアクションのパイプライン化
<a name="jobs-session-pipelining"></a>

セッションアクションのパイプラインにより、スケジューラは複数のセッションアクションをワーカーに事前割り当てできます。その後、ワーカーはこれらのアクションを順番に実行し、タスク間のアイドル時間を短縮または排除できます。

初期割り当てを作成するには、スケジューラが 1 つのタスクでセッションを作成し、ワーカーがタスクを完了してから、スケジューラがタスク期間を分析して今後の割り当てを決定します。

スケジューラを有効にするには、タスク期間ルールがあります。1 分未満のタスクの場合、スケジューラは Power-of-2 成長パターンを使用します。たとえば、1 秒のタスクの場合、スケジューラは 2 つの新しいタスクを割り当て、次に 4、次に 8 を割り当てます。1 分間のタスクの場合、スケジューラは新しいタスクを 1 つだけ割り当て、パイプライン作成は無効のままになります。

パイプラインサイズを計算するために、スケジューラは以下を実行します。
+ 完了したタスクの平均タスク期間を使用します
+ ワーカーを 1 分間ビジー状態に保つことを目指します。
+ 同じセッション内のタスクのみを考慮します
+ ワーカー間で期間データを共有しない

セッションアクションが枯渇すると、ワーカーは新しいタスクをすぐに開始し、スケジューラリクエスト間の待機時間はありません。また、長時間実行されるプロセスのワーカー効率が向上し、タスク分散が向上します。

さらに、新しい優先度の高いジョブが利用可能である場合、ワーカーは現在のセッションが終了し、優先度の高いジョブからの新しいセッションが割り当てられる前に、以前に割り当てられたすべての作業を完了します。

## ステップの依存関係
<a name="jobs-scheduling-dependencies"></a>

Deadline Cloud は、ステップ間の依存関係の定義をサポートしているため、あるステップは別のステップが完了するまで待機してから開始します。ステップには複数の依存関係を定義できます。依存関係を持つステップは、すべての依存関係が完了するまでスケジュールされません。

ジョブテンプレートが循環依存関係を定義している場合、ジョブは拒否され、ジョブのステータスは に設定されます`CREATE_FAILED`。

次のジョブテンプレートは、2 つのステップでジョブを作成します。 `StepB`は に依存し`StepA`ます。 が正常に`StepA`完了した後に`StepB`のみ実行されます。

ジョブが作成されると、 `StepA`は `READY`状態になり、 `StepB`は `PENDING`状態になります。`StepA` が終了すると、 は `READY`状態`StepB`に移行します。が`StepA`失敗した場合、または `StepA`がキャンセルされた場合、 は `CANCELED`状態`StepB`に移行します。

複数のステップに依存関係を設定できます。たとえば、 `StepC`が `StepA`と の両方に依存する場合`StepB`、 `StepC`は他の 2 つのステップが完了するまで開始しません。

ステップの依存関係には以下の制限があります。
+ **ステップあたりの依存関係** – ステップは、最大 128 個の他のステップに依存します。
+ **ステップあたりのコンシューマー** – 1 つのステップに応じて、最大 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!
```

# Deadline Cloud でジョブを変更する
<a name="build-jobs-modifying"></a>

次の 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`ステータスに切り替わります。依存関係を持つステップは、復元`PENDING`時に `READY`または のいずれかに切り替わります。  

```
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 – タスクのステータスを変更する**  
`update-task` Deadline 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
```