기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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

*작업 번들*은 AWS Deadline Cloud에 대한 작업을 정의하는 데 사용하는 도구 중 하나입니다. 작업 첨부 파일에 사용하는 파일 및 디렉터리와 같은 추가 정보와 함께 [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/ko_kr/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` 함수를 사용할 수 있습니다.

Autodesk Maya 플러그인과 같이 Deadline Cloud와 함께 제공되는 모든 작업 제출자 플러그인은 제출을 위한 작업 번들을 생성한 다음 Deadline Cloud Python 패키지를 사용하여 Deadline Cloud에 작업을 제출합니다. 워크스테이션의 작업 기록 디렉터리에서 또는 제출자를 사용하여 제출된 작업 번들을 볼 수 있습니다. 다음 명령을 사용하여 작업 기록 디렉터리를 찾을 수 있습니다.

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

작업이 Deadline Cloud 작업자에서 실행 중인 경우 작업에 대한 정보를 제공하는 환경 변수에 액세스할 수 있습니다. 환경 변수는 다음과 같습니다.


| 변수 이름 | Available | 
| --- | --- | 
| 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` 속성은 명령을 사용하고 Autodesk Maya와 같은 애플리케이션의 작업 제출 플러그인 내에서 `deadline bundle gui-submit` 명령줄 모두에 대해 자동으로 생성된 사용자 인터페이스의 동작을 정의합니다.

이 예제에서 `BlenderSceneFile` 파라미터 값을 입력하기 위한 UI 위젯은 파일만 표시하는 `.blend` 파일 선택 대화 상자입니다.

![\[OpenJD 작업 템플릿의 장면 파일 파라미터를 입력하기 위한 사용자 인터페이스 위젯입니다.\]](http://docs.aws.amazon.com/ko_kr/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png)


`userInteface` 요소 사용에 대한 자세한 예는 GitHub의 deadline-cloud-samples 리포지토리에서 [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) 

`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](https://github.com/OpenJobDescription/openjd-specifications) Job Description 사양의 [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)의 [작업 실행 방법을](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) 리포지토리에는 작업 템플릿의 더 많은 예와 Open Job Descriptions 사양과 함께 제공되는 [템플릿 샘플](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples)이 있습니다.

# 작업 템플릿에 대한 작업 청킹
<a name="build-job-bundle-chunking"></a>

작업 청킹을 사용하면 여러 작업을 청크라는 단일 작업 단위로 그룹화할 수 있습니다. 예를 들어 렌더링 작업에서 Deadline Cloud는 명령 호출당 하나의 프레임 대신 여러 프레임을 함께 디스패치할 수 있습니다. 이렇게 하면 각 작업에 대한 애플리케이션 시작 오버헤드가 줄어들고 총 작업 런타임이 단축됩니다. 자세한 내용은 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` – (필수) 단일 청크로 결합할 작업 수입니다. 최대값은 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) 샘플을 참조하세요.

**고객 관리형 플릿 요구 사항**  
작업 청킹에는 호환되는 작업자 에이전트 버전이 필요합니다. 고객 관리형 플릿을 사용하는 경우 청킹으로 작업을 제출하기 전에 작업자 에이전트가 업데이트되었는지 확인합니다. 서비스 관리형 플릿은 항상 호환되는 작업자 에이전트 버전을 사용합니다.

**청크 작업에 대한 출력 다운로드**  
청크 작업에서 단일 작업에 대한 출력을 다운로드하면 Deadline Cloud는 전체 청크에 대한 출력을 다운로드합니다. 예를 들어 프레임 1\$110이 함께 처리된 경우 프레임 3에 대한 출력을 다운로드하면 모든 프레임 1\$110이 포함됩니다. 이 기능을 사용하려면 `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는 이러한 파일 공유 중 하나에 없는 파일만 업로드합니다.

스토리지 프로파일 생성 및 사용에 대한 자세한 내용은 [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/ko_kr/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)이라는 두 가지 기능을 제공합니다.

작업 첨부 파일은 몇 가지 이점을 제공합니다.
+ Amazon S3를 사용하여 호스트 간에 파일 이동
+ 워크스테이션에서 작업자 호스트로 또는 그 반대로 파일 전송
+ 기능을 활성화하는 대기열의 작업에 사용 가능
+ 주로 서비스 관리형 플릿과 함께 사용되지만 고객 관리형 플릿과도 호환됩니다.

 스토리지 프로파일을 사용하여 워크스테이션 및 작업자 호스트에서 공유 파일 시스템 위치의 레이아웃을 매핑합니다. 이 매핑은 기반 워크스테이션 및 Windows기반 작업자 호스트를 사용한 교차 플랫폼 설정과 같이 워크스테이션과 Linux작업자 호스트의 위치가 다를 때 작업이 공유 파일 및 디렉터리를 찾는 데 도움이 됩니다. 파일 시스템 구성의 스토리지 프로파일 맵은 작업 첨부 파일에서도 Amazon S3를 통해 호스트 간에 통신하는 데 필요한 파일을 식별하는 데 사용됩니다.

 작업 첨부 파일을 사용하지 않고 워크스테이션과 작업자 호스트 간에 파일 및 디렉터리 위치를 다시 매핑할 필요가 없는 경우 스토리지 프로파일로 파일 공유를 모델링할 필요가 없습니다.

**Topics**
+ [샘플 프로젝트 인프라](sample-project-infrastructure.md)
+ [스토리지 프로파일 및 경로 매핑](storage-profiles-and-path-mapping.md)

# 샘플 프로젝트 인프라
<a name="sample-project-infrastructure"></a>

작업 연결 및 스토리지 프로파일 사용을 시연하려면 두 개의 별도 프로젝트로 테스트 환경을 설정합니다. 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 버킷 생성을** 선택합니다.
      + **고객 관리형 플릿과의 연결 활성화를** 선택합니다.
      + 사용자로 실행의 경우 POSIX 사용자와 그룹 모두에 **jobuser**를 입력합니다.
      + 대기열 서비스 역할의 경우 라는 새 역할을 생성합니다. **AssetDemoFarm-Q1-Role** 
      + 기본 conda 대기열 환경 확인란의 선택을 취소합니다.

   1. 라는 두 번째 대기열을 생성합니다**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>

 스토리지 프로파일은 호스트 구성 중 하나의 파일 시스템 구성을 모델링합니다. [샘플 프로젝트 인프라]()에는 네 가지 호스트 구성이 있습니다. 이 예제에서는 각각에 대해 별도의 스토리지 프로파일을 생성합니다. 다음 중 하나를 사용하여 스토리지 프로파일을 생성할 수 있습니다.
+ [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"
}
```

 다음 명령을 사용하여의를 `WorkerConfig` 사용하여 워크스테이션 구성 `WS2`, 및 `WS1`에 대한 스토리지 프로파일`WS3`과 작업자 구성을 생성합니다. [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는 이름을 비교하여 경로 매핑 규칙을 생성할 때 서로 다른 스토리지 프로파일의 파일 시스템 위치가 동일한 위치를 참조하고 있는지 확인합니다.

# 플릿의 스토리지 프로파일 구성
<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` 프로파일에 해당 대기열에 `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.
```

오류를 해결하려면 대기열`Q1`과 대기열 모두에 허용되는 스토리지 프로파일 `WorkerConfig` 목록에 라는 스토리지 프로파일을 추가합니다`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"]`.

 [Open 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}}" ]
            }
          }
        }
      }
    ]
  }'
```

 [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)에서 작업을 실행할 때 작업 연결을 사용해야 합니다. 작업 연결은 작업 [번들에](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html) [셸 또는 Python 스크립트가 포함된 경우와 같이 작업의 입력 또는 출력 파일이 공유 네트워크 파일 시스템에 저장되는 경우 고객 관리형 플릿](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` 파일을 사용할 수 있습니다. 이러한 방법 중 하나 또는 세 가지 방법의 조합을 사용할 수 있습니다. 로컬 워크스테이션에서 변경된 파일만 업로드하도록 작업에 대한 번들의 스토리지 프로파일을 지정할 수 있습니다.

이 섹션에서는 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 셸 스크립트를 실행하는 작업이 포함된 단일 단계가 있습니다. 작업 파라미터의 정의는 다음과 같습니다.

```
...
- name: ScriptFile
  type: PATH
  default: script.sh
  dataFlow: IN
  objectType: FILE
...
```

 `dataFlow` 속성 값은 작업 연결에 `ScriptFile` 파라미터 값이 작업에 대한 입력임을 `IN` 알려줍니다. `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`의 값은 파일 내용의 해시이며 확장자는 해시 값이 128비트 [xxhash](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에 업로드할 때 작업에 대한 입력으로 고려하는 파일 및 디렉터리는 다음과 같습니다.
+  또는 값을 사용하여 작업 번들의 작업 템플릿에 정의된 모든 `PATH`유형 작업 파라미터의 `dataFlow` 값`IN`입니다`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는 작업을 제출할 때 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` - 대기열에 필요한 `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
```

로그는 세션에서 첫 번째로 발생하는 작업이 작업자에게 다운로드되는 두 개의 입력 파일임을 보여줍니다.

```
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"-named 디렉터리가 있습니다.

 입력 파일, 디렉터리 또는 파일 시스템 위치 중 하나의 재배치된 파일 시스템 위치를 참조해야 하는 경우 작업에서 경로 매핑 규칙 파일을 처리하고 재매핑을 직접 수행하거나 작업 번들의 작업 템플릿에 `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` 작업 파라미터의 값을 작업의 출력`OUT``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)
```

# 종속 단계의 단계에서 파일 사용
<a name="using-files-output-from-a-step-in-a-dependent-step"></a>

이 예제는 작업의 한 단계가 동일한 작업에서 의존하는 단계에서 출력에 액세스하는 방법을 보여줍니다.

 한 단계의 출력을 다른 단계에서 사용할 수 있도록 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
```

 이 수정된 작업 번들로 생성된 작업은 두 개의 개별 세션으로 실행되며, 하나는 "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
```

# 작업에 대한 리소스 제한 생성
<a name="build-job-limits"></a>

Deadline Cloud에 제출된 작업은 여러 작업 간에 공유되는 리소스에 따라 달라질 수 있습니다. 예를 들어 팜에는 특정 리소스에 대한 유동 라이선스보다 더 많은 작업자가 있을 수 있습니다. 또는 공유 파일 서버는 제한된 수의 작업자에게만 동시에 데이터를 제공할 수 있습니다. 경우에 따라 하나 이상의 작업이 이러한 리소스를 모두 클레임하여 새 작업자가 시작할 때 사용할 수 없는 리소스로 인해 오류가 발생할 수 있습니다.

이를 해결하기 위해 이러한 제한된 리소스에 대한 *제한을* 사용할 수 있습니다. Deadline Cloud는 제한된 리소스의 가용성을 고려하고 해당 정보를 사용하여 리소스를 사용할 수 없는 리소스로 인해 작업이 실패할 가능성이 낮도록 새 작업자가 시작할 때 리소스를 사용할 수 있도록 합니다.

전체 팜에 대한 제한이 생성됩니다. 대기열에 제출된 작업은 대기열과 연결된 제한만 획득할 수 있습니다. 대기열과 연결되지 않은 작업에 대한 제한을 지정하면 작업이 호환되지 않으며 실행되지 않습니다.

제한을 사용하려면 
+ [한도 생성](job-limit-create.md)
+ [한도와 대기열 연결](job-limit-associate.md)
+ [제한이 필요한 작업 제출](job-limit-job.md)

**참고**  
제한과 연결되지 않은 대기열에 제한된 리소스가 있는 작업을 실행하는 경우 해당 작업은 모든 리소스를 사용할 수 있습니다. 제한된 리소스가 있는 경우 리소스를 사용하는 대기열에 있는 작업의 모든 단계가 제한과 연결되어 있는지 확인합니다.

팜에 정의되고 대기열과 연결되며 작업에 지정된 제한의 경우 다음 네 가지 중 하나가 발생할 수 있습니다.
+ 제한을 생성하고 대기열에 연결한 다음 작업 템플릿에 제한을 지정하면 작업이 실행되고 제한에 정의된 리소스만 사용됩니다.
+ 제한을 생성하여 작업 템플릿에 지정하지만 제한을 대기열과 연결하지 않으면 작업이 호환되지 않는 것으로 표시되고 실행되지 않습니다.
+ 제한을 생성하고 대기열과 연결하지 않으며 작업 템플릿에 제한을 지정하지 않으면 작업이 실행되지만 제한을 사용하지 않습니다.
+ 제한을 전혀 사용하지 않으면 작업이 실행됩니다.

제한을 여러 대기열에 연결하면 대기열은 제한에 의해 제한된 리소스를 공유합니다. 예를 들어 100개의 제한을 생성하고 대기열 하나가 60개의 리소스를 사용하는 경우 다른 대기열은 40개의 리소스만 사용할 수 있습니다. 리소스가 릴리스되면 모든 대기열의 작업에서 리소스를 가져올 수 있습니다.

Deadline Cloud는 한도에서 제공하는 리소스를 모니터링하는 데 도움이 되는 두 가지 AWS CloudFormation지표를 제공합니다. 현재 사용 중인 리소스 수와 한도에서 사용 가능한 최대 리소스 수를 모니터링할 수 있습니다. 자세한 내용은 *Deadline Cloud 개발자 안내서*의 [리소스 제한 지표](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits)를 참조하세요.

작업 템플릿의 작업 단계에 제한을 적용합니다. `hostRequirements` 단계의 `amounts` 섹션에 한도의 금액 요구 사항 이름을 지정하고 동일한의 한도`amountRequirementName`가 작업 대기열과 연결된 경우이 단계에 예약된 작업은 리소스의 한도에 의해 제한됩니다.

단계에 도달하는 제한으로 제한되는 리소스가 필요한 경우 추가 작업자가 해당 단계의 작업을 선택하지 않습니다.

작업 단계에 제한을 두 개 이상 적용할 수 있습니다. 예를 들어 단계에서 서로 다른 두 소프트웨어 라이선스를 사용하는 경우 각 라이선스에 대해 별도의 제한을 적용할 수 있습니다. 단계에 두 가지 제한이 필요하고 리소스 중 하나에 대한 한도에 도달하면 리소스를 사용할 수 있을 때까지 추가 작업자가 해당 단계의 작업을 선택하지 않습니다.

## 제한 중지 및 삭제
<a name="job-limit-stop-delete"></a>

대기열과 제한 간의 연결을 중지하거나 삭제하면 제한을 사용하는 작업은이 제한이 필요한 단계에서 작업 예약을 중지하고 단계에 대한 새 세션 생성을 차단합니다.

준비 상태인 태스크는 준비 상태로 유지되며 대기열과 한도 간의 연결과 함께 태스크가 자동으로 재개됩니다. 작업을 다시 대기열에 넣을 필요가 없습니다.

대기열과 한도 간의 연결을 중지하거나 삭제할 때 작업 실행을 중지하는 방법에 대한 두 가지 선택 사항이 있습니다.
+ 작업 중지 및 취소 - 제한을 획득한 세션이 있는 작업자는 모든 작업을 취소합니다.
+ 작업 중지 및 완료 - 한도를 획득한 세션이 있는 작업자는 작업을 완료합니다.

콘솔을 사용하여 제한을 삭제하면 작업자는 작업을 완료하면 즉시 또는 결국 실행을 중지합니다. 연결이 삭제되면 다음과 같은 상황이 발생합니다.
+ 제한이 필요한 단계는 호환되지 않는 것으로 표시됩니다.
+ 제한이 필요하지 않은 단계를 포함하여 이러한 단계가 포함된 전체 작업이 취소됩니다.
+ 작업이 호환되지 않음으로 표시되어 있습니다.

한도와 연결된 대기열에 한도의 금액 요구 사항 이름과 일치하는 플릿 기능이 있는 연결된 플릿이 있는 경우 해당 플릿은 지정된 한도로 작업을 계속 처리합니다.

# 한도 생성
<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. Deadline Cloud 콘솔([Deadline Cloud 콘솔](https://console.aws.amazon.com/deadlinecloud/home)) 대시보드에서 대기열을 생성할 팜을 선택합니다.

1. 한도를 추가할 팜을 선택하고 **한도 ** 탭을 선택한 다음 **한도 생성을** 선택합니다.

1. 제한에 대한 세부 정보를 제공합니다. **금액 요구 사항 이름은** 작업 템플릿에서 제한을 식별하는 데 사용되는 이름입니다. 접두사와 **amount.** 금액 이름으로 시작해야 합니다. 금액 요구 사항 이름은 한도와 연결된 대기열에서 고유해야 합니다.

1. **최대량 설정을** 선택하면이 한도에서 허용하는 총 리소스 수입니다. **최대 금액 없음을** 선택하면 리소스 사용량이 제한되지 않습니다. 리소스 사용량이 제한되지 않더라도 `CurrentCount` Amazon CloudWatch 지표가 생성되므로 사용량을 추적할 수 있습니다. 자세한 내용은 *Deadline* [Cloud 개발자 안내서의 CloudWatch 지표](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html)를 참조하세요.

1. 제한을 사용해야 하는 대기열을 이미 알고 있는 경우 지금 선택할 수 있습니다. 제한을 생성하기 위해 대기열을 연결할 필요가 없습니다.

1. **한도 생성을** 선택합니다.

# 한도와 대기열 연결
<a name="job-limit-associate"></a>

한도를 생성한 후 하나 이상의 대기열을 한도와 연결할 수 있습니다. 제한과 연결된 대기열만 제한에 지정된 값을 사용합니다.

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. **변경 사항 저장**을 선택합니다.

# 제한이 필요한 작업 제출
<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에서 제공하는 도구를 사용하거나 워크로드에 맞는 사용자 지정 도구를 생성하여 작업을 제출할 수 있는 몇 가지 방법을 설명합니다.
+ 터미널에서 - 작업 번들을 처음 개발하는 경우 또는 작업을 제출하는 사용자가 명령줄을 사용하는 것이 편한 경우
+ 스크립트에서 - 워크로드 사용자 지정 및 자동화
+ 애플리케이션에서 - 사용자의 작업이 애플리케이션에 있는 경우 또는 애플리케이션의 컨텍스트가 중요한 경우.

 다음 예제에서는 `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에 작업 제출
<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는 대기열과 연결된 하나 이상의 플릿에서 처리되도록 예약합니다. 특정 작업을 처리하는 플릿은 플릿에 대해 구성된 기능과 특정 단계의 호스트 요구 사항에 따라 선택됩니다.

대기열의 작업은 가장 높은 우선 순위부터 가장 낮은 순서로 예약됩니다. 두 작업의 우선 순위가 같으면 가장 오래된 작업이 먼저 예약됩니다.

다음 섹션에서는 작업 예약 프로세스에 대한 세부 정보를 제공합니다.

## 플릿 호환성 확인
<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>

호환되는 서비스 관리형 플릿에 작업이 할당되면 플릿이 자동으로 조정됩니다. 플릿의 작업자 수는 플릿이 실행할 수 있는 작업 수에 따라 변경됩니다.

작업이 고객 관리형 플릿에 할당되면 작업자가 이미 존재하거나 이벤트 기반 Auto Scaling을 사용하여 생성할 수 있습니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 [ EventBridge를 사용하여 Auto Scaling 이벤트 처리를 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) 참조하세요. *Amazon EC2 Auto Scaling *

## 세션
<a name="jobs-scheduling-sessions"></a>

작업의 작업은 하나 이상의 세션으로 나뉩니다. 작업자는 세션을 실행하여 환경을 설정하고 작업을 실행한 다음 환경을 해제합니다. 각 세션은 작업자가 수행해야 하는 하나 이상의 작업으로 구성됩니다.

작업자가 섹션 작업을 완료하면 추가 세션 작업을 작업자에게 보낼 수 있습니다. 작업자는 세션의 기존 환경과 작업 연결을 재사용하여 작업을 보다 효율적으로 완료합니다.

서비스 관리형 플릿 작업자의 경우 세션이 종료된 후 세션 디렉터리가 삭제되지만 다른 디렉터리는 세션 간에 유지됩니다. 이 동작을 사용하면 여러 세션에서 재사용할 수 있는 데이터에 대한 캐싱 전략을 구현할 수 있습니다. 세션 간에 데이터를 캐싱하려면 작업을 실행하는 사용자의 홈 디렉터리 아래에 저장합니다. 예를 들어 conda 패키지는 작업자 및 Windows 작업자의에 `C:\Users\job-user\.conda-pkgs` 있는 작업 사용자의 홈 디렉터리 `/home/job-user/.conda-pkgs` 아래에 캐시됩니다Linux. 이 데이터는 작업자가 종료될 때까지 계속 사용할 수 있습니다.

작업 첨부 파일은 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 }}
```

### 세션 작업 파이프라이닝
<a name="jobs-session-pipelining"></a>

세션 작업 파이프라이닝을 사용하면 스케줄러가 작업자에게 여러 세션 작업을 사전 할당할 수 있습니다. 그런 다음 작업자는 이러한 작업을 순차적으로 실행하여 작업 간 유휴 시간을 줄이거나 제거할 수 있습니다.

초기 할당을 생성하기 위해 스케줄러는 하나의 작업으로 세션을 생성하고, 작업자는 작업을 완료한 다음, 스케줄러는 작업 기간을 분석하여 향후 할당을 결정합니다.

스케줄러가 유효하려면 작업 기간 규칙이 있습니다. 1분 미만의 작업의 경우 스케줄러는 Power-of-2 성장 패턴을 사용합니다. 예를 들어 1초 태스크의 경우 스케줄러는 2개의 새 태스크를 할당한 다음 4개, 8개를 할당합니다. 1분 이상 태스크의 경우 스케줄러는 새 태스크를 하나만 할당하고 파이프라이닝은 비활성화된 상태로 유지됩니다.

파이프라인 크기를 계산하기 위해 스케줄러는 다음을 수행합니다.
+ 완료된 작업의 평균 작업 기간을 사용합니다.
+ 작업자를 1분 동안 바쁘게 유지하는 것을 목표로 합니다.
+ 동일한 세션 내의 작업만 고려합니다.
+ 작업자 간에 기간 데이터를 공유하지 않음

세션 작업 피플라이닝을 사용하면 작업자가 즉시 새 작업을 시작하고 스케줄러 요청 사이에 대기 시간이 없습니다. 또한 장기 실행 프로세스를 위해 작업자 효율성과 작업 분산을 개선합니다.

또한 사용 가능한 우선순위가 더 높은 새 작업이 있는 경우 작업자는 현재 세션이 종료되고 우선순위가 더 높은 작업의 새 세션이 할당되기 전에 이전에 할당된 모든 작업을 완료합니다.

## 단계 종속성
<a name="jobs-scheduling-dependencies"></a>

Deadline Cloud는 한 단계가 시작하기 전에 다른 단계가 완료될 때까지 대기하도록 단계 간 종속성 정의를 지원합니다. 단계에 대한 종속성을 두 개 이상 정의할 수 있습니다. 종속성이 있는 단계는 모든 종속성이 완료될 때까지 예약되지 않습니다.

작업 템플릿이 순환 종속성을 정의하면 작업이 거부되고 작업 상태가 로 설정됩니다`CREATE_FAILED`.

다음 작업 템플릿은 두 단계로 작업을 생성합니다.는에 `StepB` 따라 달라집니다`StepA`.는가 성공적으로 `StepA` 완료된 후에`StepB`만 실행됩니다.

작업이 생성된 후 `StepA`는 `READY` 상태가 되고 `StepB`는 `PENDING` 상태가 됩니다. 가 `StepA` 완료되면 `READY` 상태로 `StepB` 이동합니다. 가 `StepA` 실패하거나이 취소되면 `StepA`가 `CANCELED` 상태로 `StepB` 전환됩니다.

여러 단계에 종속성을 설정할 수 있습니다. 예를 들어 `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!
```

# 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 - 작업 설명 변경**  
작업에 대한 설명을 업데이트합니다. 설명은 최대 2,048자까지 가능합니다. 기존 설명을 제거하려면 빈 문자열을 전달합니다.  

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