As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Crie trabalhos para enviar ao Deadline Cloud
<a name="building-jobs"></a>

Você envia trabalhos para o Deadline Cloud usando pacotes de trabalhos. Um pacote de tarefas é uma coleção de arquivos, incluindo um modelo de [tarefa Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) e todos os arquivos de ativos necessários para renderizar a tarefa.

 O modelo de trabalho descreve como os trabalhadores processam e acessam os ativos e fornece o script que o trabalhador executa. Os pacotes de tarefas permitem que artistas, diretores técnicos e desenvolvedores de funis enviem facilmente trabalhos complexos para o Deadline Cloud a partir de suas estações de trabalho locais ou do render farm local. Os pacotes de tarefas são particularmente úteis para equipes que trabalham em efeitos visuais, animações ou outros projetos de renderização de mídia em grande escala que exigem recursos computacionais escaláveis e sob demanda.

Você pode criar o pacote de tarefas usando o sistema de arquivos local para armazenar arquivos e um editor de texto para criar o modelo de tarefa. Depois de criar o pacote, envie o trabalho para o Deadline Cloud usando a CLI do Deadline Cloud ou uma ferramenta como um remetente do Deadline Cloud

Você pode armazenar seus ativos em um sistema de arquivos compartilhado entre seus funcionários ou pode usar os anexos de trabalho do Deadline Cloud para automatizar a transferência de ativos para compartimentos do S3, onde seus funcionários podem acessá-los. Os anexos de trabalho também ajudam a mover a saída de seus trabalhos de volta para suas estações de trabalho.

 As seções a seguir fornecem instruções detalhadas sobre como criar e enviar pacotes de tarefas para o Deadline Cloud. 

**Topics**
+ [Modelos de Open Job Description (OpenJD) para Deadline Cloud](build-job-bundle.md)
+ [Usando arquivos em seus trabalhos](using-files-in-your-jobs.md)
+ [Use anexos de trabalho para compartilhar arquivos](build-job-attachments.md)
+ [Crie limites de recursos para trabalhos](build-job-limits.md)
+ [Como enviar uma vaga para o Deadline Cloud](submit-jobs-how.md)
+ [Agende trabalhos no Deadline Cloud](build-jobs-scheduling.md)
+ [Modificar um trabalho no Deadline Cloud](build-jobs-modifying.md)

# Modelos de Open Job Description (OpenJD) para Deadline Cloud
<a name="build-job-bundle"></a>

Um *pacote de tarefas* é uma das ferramentas que você usa para definir trabalhos para o AWS Deadline Cloud. Eles agrupam um modelo de [Open Job Description (OpenJD)](https://github.com/OpenJobDescription/openjd-specifications) com informações adicionais, como arquivos e diretórios que seus trabalhos usam com anexos de trabalhos. Você usa a interface de linha de comando (CLI) do Deadline Cloud para usar um pacote de trabalhos para enviar trabalhos para execução de uma fila.

Um pacote de tarefas é uma estrutura de diretórios que contém um modelo de tarefa do OpenJD, outros arquivos que definem a tarefa e arquivos específicos da tarefa necessários como entrada para sua tarefa. Você pode especificar os arquivos que definem seu trabalho como arquivos YAML ou JSON.

O único arquivo necessário é `template.yaml` ou`template.json`. Você também pode incluir os seguintes arquivos:

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

Use um pacote de trabalhos para envios de trabalhos personalizados com a CLI do Deadline Cloud e um anexo de trabalho, ou você pode usar uma interface gráfica de envio. Por exemplo, a seguir está a amostra do Blender de GitHub. Para executar a amostra usando o seguinte comando no [diretório de amostras do Blender](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles):

```
deadline bundle gui-submit blender_render
```

![\[Um exemplo de uma interface personalizada de envio de trabalhos para o Blender.\]](http://docs.aws.amazon.com/pt_br/deadline-cloud/latest/developerguide/images/blender_submit_shared_settings.png)


O painel de configurações específicas do trabalho é gerado a partir das `userInterface` propriedades dos parâmetros do trabalho definidos no modelo do trabalho.

Para enviar um trabalho usando a linha de comando, você pode usar um comando semelhante ao seguinte

```
deadline bundle submit \
    --yes \
    --name Demo \
     -p BlenderSceneFile=location of scene file \
     -p OutputDir=file pathe for job output \
      blender_render/
```

Ou você pode usar a `deadline.client.api.create_job_from_job_bundle` função no pacote `deadline` Python.

Todos os plug-ins de envio de trabalhos fornecidos com o Deadline Cloud, como o plug-in Autodesk Maya, geram um pacote de trabalhos para seu envio e, em seguida, usam o pacote Python do Deadline Cloud para enviar seu trabalho para o Deadline Cloud. Você pode ver os pacotes de tarefas enviados no diretório de histórico de tarefas da sua estação de trabalho ou usando um remetente. Você pode encontrar seu diretório de histórico de trabalhos com o seguinte comando:

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

Quando seu trabalho está sendo executado em um funcionário do Deadline Cloud, ele tem acesso às variáveis de ambiente que fornecem informações sobre o trabalho. As variáveis de ambiente são:


| Nome da variável | Available (Disponível) | 
| --- | --- | 
| DEADLINE\$1FARM\$1ID | Todas as ações | 
| DEADLINE\$1FLEET\$1ID | Todas as ações | 
| ID\$1DE\$1TRABALHO\$1PRAZO | Todas as ações | 
| ID\$1DE\$1DATA\$1LIMITE | Todas as ações | 
| DEADLINE\$1JOB\$1ID | Todas as ações | 
| ID\$1DA\$1PASSO\$1PRAZO | Ações da tarefa | 
| ID\$1DA\$1SESSÃO\$1PRAZO | Todas as ações | 
| ID\$1DA\$1TAREFA\$1PRAZO | Ações da tarefa | 
| ID\$1DE\$1DA\$1AÇÃO DA SESSÃO | Todas as ações | 

**Topics**
+ [Elementos do modelo de trabalho para pacotes de tarefas](build-job-bundle-template.md)
+ [Divisão de tarefas para modelos de trabalho](build-job-bundle-chunking.md)
+ [Elementos de valores de parâmetros para pacotes de tarefas](build-job-bundle-parameters.md)
+ [Elementos de referências de ativos para pacotes de tarefas](build-job-bundle-assets.md)

# Elementos do modelo de trabalho para pacotes de tarefas
<a name="build-job-bundle-template"></a>

O modelo de trabalho define o ambiente de execução e os processos que são executados como parte de um trabalho do Deadline Cloud. Você pode criar parâmetros em um modelo para que ele possa ser usado para criar trabalhos que diferem somente nos valores de entrada, assim como uma função em uma linguagem de programação.

Quando você envia um trabalho para o Deadline Cloud, ele é executado em qualquer ambiente de fila aplicado à fila. Os ambientes de fila são criados usando a especificação de ambientes externos Open Job Description (OpenJD). Para obter detalhes, consulte o [modelo de ambiente](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#12-environment-template) no repositório OpenJD. GitHub 

Para uma introdução à criação de um trabalho com um modelo de trabalho do OpenJD, consulte [Introdução à criação de um trabalho](https://github.com/OpenJobDescription/openjd-specifications/wiki/Introduction-to-Creating-a-Job) no repositório do GitHub OpenJD. Informações adicionais podem ser encontradas em [Como os trabalhos são executados](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run). Há exemplos de modelos de trabalho no diretório do GitHub repositório OpenJD. `samples`

Você pode definir o modelo de trabalho no formato YAML (`template.yaml`) ou no formato JSON (`template.json`). Os exemplos nesta seção são mostrados no formato YAML.

Por exemplo, o modelo de trabalho da `blender_render` amostra define um parâmetro de entrada `BlenderSceneFile` como um caminho de arquivo:

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

A `userInterface` propriedade define o comportamento das interfaces de usuário geradas automaticamente para a linha de comando usando o `deadline bundle gui-submit` comando e nos plug-ins de envio de tarefas para aplicativos como o Autodesk Maya.

Neste exemplo, o widget de interface do usuário para inserir um valor para o `BlenderSceneFile` parâmetro é uma caixa de diálogo de seleção de arquivos que mostra somente arquivos. `.blend`

![\[Um widget de interface de usuário para inserir o parâmetro do arquivo de cena para um modelo de trabalho do OpenJD.\]](http://docs.aws.amazon.com/pt_br/deadline-cloud/latest/developerguide/images/blender_submit_scene_file_widget.png)


Para ver mais exemplos de uso do `userInteface` elemento, consulte a amostra [gui\$1control\$1showcase](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/gui_control_showcase) no repositório em. [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline) GitHub

As `dataFlow` propriedades `objectType` e controlam o comportamento dos anexos de tarefas quando você envia uma tarefa de um pacote de tarefas. Nesse caso, `objectType: FILE` e `dataFlow:IN` significa que o valor de `BlenderSceneFile` é um arquivo de entrada para anexos do trabalho.

Em contraste, a definição do `OutputDir` parâmetro tem `objectType: DIRECTORY` e`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.
```

O valor do `OutputDir` parâmetro é usado pelos anexos da tarefa como o diretório em que a tarefa grava os arquivos de saída.

Para obter mais informações sobre as `dataFlow` propriedades `objectType` e, consulte [JobPathParameterDefinition](https://github.com/OpenJobDescription/openjd-specifications/wiki/2023-09-Template-Schemas#22-jobpathparameterdefinition)a [especificação Open Job Description](https://github.com/OpenJobDescription/openjd-specifications)

O restante da amostra do modelo de `blender_render` tarefa define o fluxo de trabalho como uma única etapa, com cada quadro da animação renderizado como uma tarefa separada:

```
steps:
- name: RenderBlender
  parameterSpace:
    taskParameterDefinitions:
    - name: Frame
      type: INT
      range: "{{Param.Frames}}"
  script:
    actions:
      onRun:
        command: bash
        # Note: {{Task.File.Run}} is a variable that expands to the filename on the worker host's
        # disk where the contents of the 'Run' embedded file, below, is written.
        args: ['{{Task.File.Run}}']
    embeddedFiles:
      - name: Run
        type: TEXT
        data: |
          # Configure the task to fail if any individual command fails.
          set -xeuo pipefail

          mkdir -p '{{Param.OutputDir}}'

          blender --background '{{Param.BlenderSceneFile}}' \
                  --render-output '{{Param.OutputDir}}/{{Param.OutputPattern}}' \
                  --render-format {{Param.Format}} \
                  --use-extension 1 \
                  --render-frame {{Task.Param.Frame}}
```

Por exemplo, se o valor do `Frames` parâmetro for`1-10`, ele define 10 tarefas. Cada tarefa tem um valor diferente para o `Frame` parâmetro. Para executar uma tarefa:

1. Todas as referências de variáveis na `data` propriedade do arquivo incorporado são expandidas, por exemplo`--render-frame 1`.

1. O conteúdo da `data` propriedade é gravado em um arquivo no diretório de trabalho da sessão no disco.

1. O `onRun` comando da tarefa é resolvido `bash location of embedded file` e, em seguida, executado.

Para obter mais informações sobre arquivos incorporados, sessões e locais mapeados por caminhos, consulte [Como os trabalhos são executados](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run) na especificação Open [Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run).

Há mais exemplos de modelos de trabalho no repositório [deadline-cloud-samples/job\$1bundles](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles), bem como os [exemplos de modelos](https://github.com/OpenJobDescription/openjd-specifications/tree/mainline/samples) fornecidos com a especificação Open Job Descriptions.

# Divisão de tarefas para modelos de trabalho
<a name="build-job-bundle-chunking"></a>

O agrupamento de tarefas permite agrupar várias tarefas em uma única unidade de trabalho chamada fragmento. Em um trabalho de renderização, por exemplo, isso significa que o Deadline Cloud pode enviar vários quadros juntos em vez de um quadro por invocação de comando. Isso reduz a sobrecarga de iniciar aplicativos para cada tarefa e reduz o tempo de execução total do trabalho. Para obter detalhes, consulte [Executando vários quadros ao mesmo tempo](https://github.com/OpenJobDescription/openjd-specifications/wiki/Job-Intro-03-Creating-a-Job-Template#42-running-multiple-frames-at-a-time) no wiki do OpenJD.

O OpenJD suporta extensões que adicionam recursos opcionais aos modelos de trabalho. A fragmentação de tarefas é ativada com a adição da `TASK_CHUNKING` extensão. Para usar o agrupamento, adicione a extensão ao seu modelo de trabalho e use o tipo de parâmetro da `CHUNK[INT]` tarefa. Envie trabalhos fragmentados usando o mesmo `deadline bundle submit` comando. Por exemplo, o modelo de trabalho a seguir renderiza quadros em blocos de 10:

```
specificationVersion: 'jobtemplate-2023-09'
extensions:
  - TASK_CHUNKING
name: Blender Render with Contiguous Chunking
parameterDefinitions:
  - name: BlenderSceneFile
    type: PATH
    objectType: FILE
    dataFlow: IN
  - name: Frames
    type: STRING
    default: "1-100"
  - name: OutputDir
    type: PATH
    objectType: DIRECTORY
    dataFlow: OUT
    default: "./output"
steps:
  - name: RenderBlender
    parameterSpace:
      taskParameterDefinitions:
        - name: Frame
          type: CHUNK[INT]
          range: "{{Param.Frames}}"
          chunks:
            defaultTaskCount: 10
            rangeConstraint: CONTIGUOUS
    script:
      actions:
        onRun:
          command: bash
          args: ["{{Task.File.Run}}"]
      embeddedFiles:
        - name: Run
          type: TEXT
          data: |
            set -xeuo pipefail
            
            mkdir -p '{{Param.OutputDir}}'
            
            # Parse the chunk range (e.g., "1-10") into start and end frames
            START_FRAME="$(echo '{{Task.Param.Frame}}' | cut -d- -f1)"
            END_FRAME="$(echo '{{Task.Param.Frame}}' | cut -d- -f2)"
            
            blender --background '{{Param.BlenderSceneFile}}' \
                    --render-output '{{Param.OutputDir}}/output_####' \
                    --render-format PNG \
                    --use-extension 1 \
                    -s "$START_FRAME" \
                    -e "$END_FRAME" \
                    --render-anim
```

Neste exemplo, o Deadline Cloud divide os 100 quadros em partes como `1-10``11-20`, e assim por diante. A `{{Task.Param.Frame}}` variável se expande para uma expressão de intervalo como`1-10`. Como `rangeConstraint` está definido como`CONTIGUOUS`, o intervalo está sempre no `start-end` formato. O script analisa esse intervalo e passa os quadros inicial e final para o Blender usando as `-e` opções `-s` e com. `--render-anim`

A `chunks` propriedade suporta os seguintes campos:
+ `defaultTaskCount`— (Obrigatório) Quantas tarefas combinar em um único bloco. O valor máximo é 150.
+ `rangeConstraint`— (Obrigatório) Se`CONTIGUOUS`, um pedaço é sempre um intervalo contíguo, como. `1-10` Se`NONCONTIGUOUS`, um pedaço pode ser um conjunto arbitrário, como. `1,3,7-10`
+ `targetRuntimeSeconds`— (Opcional) O tempo de execução desejado em segundos para cada bloco. O Deadline Cloud pode ajustar dinamicamente o tamanho do bloco para se aproximar dessa meta depois que alguns trechos forem concluídos.

[Para mais exemplos de fragmentação de tarefas, incluindo exemplos básicos e do Blender com partes contíguas e não contíguas, consulte os exemplos de fragmentação de tarefas no repositório de amostras do Deadline Cloud em.](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/task_chunking) GitHub

**Requisitos de frota gerenciados pelo cliente**  
A fragmentação de tarefas requer uma versão compatível do agente de trabalho. Se você usa frotas gerenciadas pelo cliente, certifique-se de que seus agentes de trabalho estejam atualizados antes de enviar trabalhos com fragmentação. As frotas gerenciadas por serviços sempre usam uma versão de agente de trabalho compatível.

**Baixando a saída para trabalhos fragmentados**  
Quando você baixa a saída de uma única tarefa em um trabalho fragmentado, o Deadline Cloud baixa a saída de todo o fragmento. Por exemplo, se os quadros de 1 a 10 foram processados juntos, o download da saída do quadro 3 incluirá todos os quadros de 1 a 10. Esse recurso requer a `deadline-cloud` versão 0.53.3 ou posterior.

# Elementos de valores de parâmetros para pacotes de tarefas
<a name="build-job-bundle-parameters"></a>

Você pode usar o arquivo de parâmetros para definir os valores de alguns dos parâmetros do trabalho no modelo de trabalho ou argumentos da solicitação de [CreateJob](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html)operação no pacote de trabalhos para que você não precise definir valores ao enviar um trabalho. A interface do usuário para envio de trabalhos permite que você modifique esses valores.

Você pode definir o modelo de trabalho no formato YAML (`parameter_values.yaml`) ou no formato JSON (`parameter_values.json`). Os exemplos nesta seção são mostrados no formato YAML.

No YAML, o formato do arquivo é:

```
parameterValues:
- name: <string>
  value: <integer>, <float>, or <string>
- name: <string>
  value: <integer>, <float>, or <string>ab
... repeating as necessary
```

Cada elemento da `parameterValues` lista deve ser um dos seguintes:
+ Um parâmetro de trabalho definido no modelo de trabalho.
+ Um parâmetro de trabalho definido em um ambiente de fila para a fila para a qual você envia o trabalho.
+ Um parâmetro especial passado para a `CreateJob` operação ao criar um trabalho.
  + `deadline:priority`— O valor deve ser um número inteiro. Ele é passado para a `CreateJob` operação como parâmetro de [prioridade](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-priority).
  + `deadline:targetTaskRunStatus`— O valor deve ser uma string. Ele é passado para a `CreateJob` operação como o parâmetro [targetTaskRunStatus](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-targetTaskRunStatus).
  + `deadline:maxFailedTasksCount`— O valor deve ser um número inteiro. Ele é passado para a `CreateJob` operação como o parâmetro [maxFailedTasksCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxFailedTasksCount).
  + `deadline:maxRetriesPerTask`— O valor deve ser um número inteiro. Ele é passado para a `CreateJob` operação como o parâmetro [maxRetriesPerTask](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask).
  + `deadline:maxWorkercount`— O valor deve ser um número inteiro. Ele é passado para a `CreateJob` operação como [maxWorkerCount](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html#deadlinecloud-CreateJob-request-maxRetriesPerTask)parâmetro.

Um modelo de trabalho é sempre um modelo em vez de um trabalho específico a ser executado. Um arquivo de valores de parâmetros permite que um pacote de tarefas atue como um modelo se alguns parâmetros não tiverem valores definidos nesse arquivo ou como um envio de trabalho específico se todos os parâmetros tiverem valores.

Por exemplo, a [amostra blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render) não tem um arquivo de parâmetros e seu modelo de trabalho define parâmetros sem valores padrão. Esse modelo deve ser usado como modelo para criar trabalhos. Depois de criar um trabalho usando esse pacote de trabalhos, o Deadline Cloud grava um novo pacote de trabalhos no diretório do histórico de trabalhos. 

Por exemplo, quando você envia um trabalho com o seguinte comando:

```
deadline bundle gui-submit blender_render/
```

O novo pacote de tarefas contém um `parameter_values.yaml` arquivo que contém os parâmetros especificados:

```
% cat ~/.deadline/job_history/\(default\)/2024-06/2024-06-20-01-JobBundle-Demo/parameter_values.yaml
parameterValues:
- name: deadline:targetTaskRunStatus
  value: READY
- name: deadline:maxFailedTasksCount
  value: 10
- name: deadline:maxRetriesPerTask
  value: 5
- name: deadline:priority
  value: 75
- name: BlenderSceneFile
  value: /private/tmp/bundle_demo/bmw27_cpu.blend
- name: Frames
  value: 1-10
- name: OutputDir
  value: /private/tmp/bundle_demo/output
- name: OutputPattern
  value: output_####
- name: Format
  value: PNG
- name: CondaPackages
  value: blender
- name: RezPackages
  value: blender
```

Você pode criar o mesmo trabalho com o seguinte comando:

```
deadline bundle submit ~/.deadline/job_history/\(default\)/2024-06/2024-06-20-01-JobBundle-Demo/
```

**nota**  
O pacote de trabalhos que você envia é salvo no seu diretório de histórico de trabalhos. Você pode encontrar a localização desse diretório com o seguinte comando:  

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

# Elementos de referências de ativos para pacotes de tarefas
<a name="build-job-bundle-assets"></a>

Você pode usar [os anexos de trabalho](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) do Deadline Cloud para transferir arquivos entre sua estação de trabalho e o Deadline Cloud. O arquivo de referência do ativo lista os arquivos e diretórios de entrada, bem como os diretórios de saída dos seus anexos. Se você não listar todos os arquivos e diretórios desse arquivo, poderá selecioná-los ao enviar um trabalho com o `deadline bundle gui-submit` comando.

Esse arquivo não tem efeito se você não estiver usando anexos de trabalho.

Você pode definir o modelo de trabalho no formato YAML (`asset_references.yaml`) ou no formato JSON (`asset_references.json`). Os exemplos nesta seção são mostrados no formato YAML.

No YAML, o formato do arquivo é:

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

Ao selecionar o arquivo de entrada ou saída para carregar no Amazon S3, o Deadline Cloud compara o caminho do arquivo com os caminhos listados em seus perfis de armazenamento. Cada localização do sistema `SHARED` de arquivos do tipo -type em um perfil de armazenamento abstrai um compartilhamento de arquivos de rede que está montado em suas estações de trabalho e hosts de trabalho. O Deadline Cloud carrega somente arquivos que não estão em um desses compartilhamentos de arquivos.

Para obter mais informações sobre como criar e usar perfis de armazenamento, consulte [Armazenamento compartilhado no Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) no *Guia do usuário do AWS Deadline Cloud*.

**Example - O arquivo de referência do ativo criado pela GUI do Deadline Cloud**  
Use o comando a seguir para enviar um trabalho usando a amostra [blender\$1render](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/blender_render).  

```
deadline bundle gui-submit blender_render/
```
Adicione alguns arquivos adicionais ao trabalho na guia **Anexos do trabalho**:  

![\[O painel de anexos do trabalho da GUI de envio de trabalhos do Deadline Cloud. Adicione o arquivo de entrada/private/tmp/bundle_demo/a_texture.png and the input directory /private/tmp/bundle_demo/assets.\]](http://docs.aws.amazon.com/pt_br/deadline-cloud/latest/developerguide/images/blender_submit_add_job_attachments.png)

Depois de enviar o trabalho, você pode ver o `asset_references.yaml` arquivo no pacote de trabalhos no diretório do histórico de trabalhos para ver os ativos no arquivo 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: []
```

# Usando arquivos em seus trabalhos
<a name="using-files-in-your-jobs"></a>

 Muitos dos trabalhos que você envia para o AWS Deadline Cloud têm arquivos de entrada e saída. Seus arquivos de entrada e diretórios de saída podem estar localizados em uma combinação de sistemas de arquivos compartilhados e unidades locais. Os trabalhos precisam localizar o conteúdo nesses locais. O Deadline Cloud fornece dois recursos, [anexos de tarefas](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-job-attachments.html) e [perfis de armazenamento](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html) que funcionam juntos para ajudar seus trabalhos a localizar os arquivos de que precisam. 

Os anexos de emprego oferecem vários benefícios
+ Mova arquivos entre hosts usando o Amazon S3
+ Transfira arquivos da sua estação de trabalho para os hosts dos funcionários e vice-versa
+ Disponível para trabalhos em filas nas quais você ativa o recurso
+ Usado principalmente com frotas gerenciadas por serviços, mas também compatível com frotas gerenciadas pelo cliente.

 Use perfis de armazenamento para mapear o layout dos locais compartilhados do sistema de arquivos em sua estação de trabalho e nos hosts de trabalho. Esse mapeamento ajuda seus trabalhos a localizar arquivos e diretórios compartilhados quando suas localizações diferem entre sua estação de trabalho e hosts de trabalho, como configurações multiplataforma com estações de trabalho baseadas e hosts de trabalho Windows baseados. Linux O mapa do perfil de armazenamento da configuração do seu sistema de arquivos também é usado pelos anexos de tarefas para identificar os arquivos que precisam ser transferidos entre os hosts por meio do Amazon S3. 

 Se você não estiver usando anexos de trabalho e não precisar remapear os locais de arquivos e diretórios entre estações de trabalho e hosts de trabalho, não precisará modelar seus compartilhamentos de arquivos com perfis de armazenamento. 

**Topics**
+ [Exemplo de infraestrutura de projeto](sample-project-infrastructure.md)
+ [Perfis de armazenamento e mapeamento de caminhos](storage-profiles-and-path-mapping.md)

# Exemplo de infraestrutura de projeto
<a name="sample-project-infrastructure"></a>

Para demonstrar o uso de anexos de tarefas e perfis de armazenamento, configure um ambiente de teste com dois projetos separados. Você pode usar o console do Deadline Cloud para criar os recursos de teste.

1. Se você ainda não o fez, crie uma fazenda de testes. Para criar uma fazenda, siga o procedimento em [Criar uma fazenda](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/farms.html). 

1. Crie duas filas para trabalhos em cada um dos dois projetos. Para criar filas, siga o procedimento em [Criar uma fila](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html).

   1. Crie a primeira fila chamada**Q1**. Use a configuração a seguir, use os padrões para todos os outros itens.
      + Para anexos de trabalho, escolha **Criar um novo bucket do Amazon S3**.
      + Selecione **Habilitar associação com frotas gerenciadas pelo cliente**.
      + Para executar como usuário, insira tanto **jobuser** para o usuário quanto para o grupo POSIX.
      + Para a função de serviço de fila, crie uma nova função chamada **AssetDemoFarm-Q1-Role**
      + Desmarque a caixa de seleção padrão do ambiente de fila conda.

   1. Crie a segunda fila chamada**Q2**. Use a configuração a seguir, use os padrões para todos os outros itens.
      + Para anexos de trabalho, escolha **Criar um novo bucket do Amazon S3**.
      + Selecione **Habilitar associação com frotas gerenciadas pelo cliente**.
      + Para executar como usuário, insira tanto **jobuser** para o usuário quanto para o grupo POSIX.
      + Para a função de serviço de fila, crie uma nova função chamada **AssetDemoFarm-Q2-Role**
      + Desmarque a caixa de seleção padrão do ambiente de fila conda.

1. Crie uma única frota gerenciada pelo cliente que execute os trabalhos nas duas filas. Para criar a frota, siga o procedimento em [Criar uma frota gerenciada pelo cliente](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-a-cmf.html). Use a seguinte configuração:
   + Para **Nome**, use**DemoFleet**.
   + Para **Tipo de frota**, escolha **Gerenciado pelo cliente**
   + Para a **função de serviço Fleet**, crie uma nova função chamada **AssetDemoFarm-Fleet-Role**.
   + Não associe a frota a nenhuma fila.

O ambiente de teste pressupõe que há três sistemas de arquivos compartilhados entre hosts usando compartilhamentos de arquivos de rede. Neste exemplo, os locais têm os seguintes nomes:
+ `FSCommon`- contém ativos de trabalho de entrada que são comuns aos dois projetos.
+ `FS1`- contém ativos de trabalho de entrada e saída para o projeto 1.
+ `FS2`- contém ativos de trabalho de entrada e saída para o projeto 2.

O ambiente de teste também pressupõe que haja três estações de trabalho, da seguinte forma:
+ `WSAll`- Uma estação de trabalho Linux baseada usada por desenvolvedores para todos os projetos. Os locais do sistema de arquivos compartilhados são:
  + `FSCommon`: `/shared/common`
  + `FS1`: `/shared/projects/project1`
  + `FS2`: `/shared/projects/project2`
+ `WS1`- Uma estação de trabalho Windows baseada usada para o projeto 1. Os locais do sistema de arquivos compartilhados são:
  + `FSCommon`: `S:\`
  + `FS1`: `Z:\`
  + `FS2`: Não disponível
+ `WS1`- Uma estação de trabalho macOS baseada usada para o projeto 2.Os locais do sistema de arquivos compartilhados são:
  + `FSCommon`: `/Volumes/common`
  + `FS1`: Não disponível
  + `FS2`: `/Volumes/projects/project2`

Por fim, defina os locais compartilhados do sistema de arquivos para os trabalhadores da sua frota. Os exemplos a seguir se referem a essa configuração como`WorkerConfig`. Os locais compartilhados são: 
+ `FSCommon`: `/mnt/common`
+ `FS1`: `/mnt/projects/project1`
+ `FS2`: `/mnt/projects/project2`

 Você não precisa configurar nenhum sistema de arquivos, estações de trabalho ou trabalhadores compartilhados que correspondam a essa configuração. Os locais compartilhados não precisam existir para a demonstração. 

# Perfis de armazenamento e mapeamento de caminhos
<a name="storage-profiles-and-path-mapping"></a>

Use perfis de armazenamento para modelar os sistemas de arquivos em sua estação de trabalho e hosts de trabalho. Cada perfil de armazenamento descreve o sistema operacional e o layout do sistema de arquivos de uma das configurações do sistema. Este tópico descreve como usar perfis de armazenamento para modelar as configurações do sistema de arquivos de seus hosts para que o Deadline Cloud possa gerar regras de mapeamento de caminhos para seus trabalhos e como essas regras de mapeamento de caminhos são geradas a partir de seus perfis de armazenamento.

Ao enviar um trabalho para o Deadline Cloud, você pode fornecer um ID de perfil de armazenamento opcional para o trabalho. Esse perfil de armazenamento descreve o sistema de arquivos da estação de trabalho de envio. Ele descreve a configuração original do sistema de arquivos que os caminhos de arquivo no modelo de trabalho usam.

Você também pode associar um perfil de armazenamento a uma frota. O perfil de armazenamento descreve a configuração do sistema de arquivos de todos os hosts de trabalho na frota. Se você tiver trabalhadores com diferentes configurações de sistema de arquivos, esses trabalhadores devem ser atribuídos a uma frota diferente em sua fazenda.

 As regras de mapeamento de caminhos descrevem como os caminhos devem ser remapeados, desde a forma como são especificados no trabalho até a localização real do caminho em um host de trabalho. O Deadline Cloud compara a configuração do sistema de arquivos descrita no perfil de armazenamento de um trabalho com o perfil de armazenamento da frota que está executando o trabalho para derivar essas regras de mapeamento de caminhos. 

**Topics**
+ [Modele locais de sistemas de arquivos compartilhados com perfis de armazenamento](modeling-your-shared-filesystem-locations-with-storage-profiles.md)
+ [Configurar perfis de armazenamento para frotas](configuring-storage-profiles-for-fleets.md)
+ [Configurar perfis de armazenamento para filas](storage-profiles-for-queues.md)
+ [Derive regras de mapeamento de caminhos a partir de perfis de armazenamento](deriving-path-mapping-rules-from-storage-profiles.md)

# Modele locais de sistemas de arquivos compartilhados com perfis de armazenamento
<a name="modeling-your-shared-filesystem-locations-with-storage-profiles"></a>

 Um perfil de armazenamento modela a configuração do sistema de arquivos de uma de suas configurações de host. Há quatro configurações de host diferentes na [infraestrutura do projeto de amostra](). Neste exemplo, você cria um perfil de armazenamento separado para cada um. Você pode criar um perfil de armazenamento usando qualquer um dos seguintes:
+ [CreateStorageProfile API](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateStorageProfile.html)
+ [AWS::Deadline::StorageProfile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-deadline-storageprofile.html) CloudFormation recurso
+ [Console do AWS](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/storage-shared.html#storage-profile)

 Um perfil de armazenamento é composto por uma lista de localizações do sistema de arquivos, cada uma informando ao Deadline Cloud a localização e o tipo de localização do sistema de arquivos que é relevante para trabalhos enviados ou executados em um host. Um perfil de armazenamento só deve modelar os locais relevantes para os trabalhos. Por exemplo, o `FSCommon` local compartilhado está localizado na estação de trabalho `WS1` em`S:\`, então o local correspondente do sistema de arquivos é: 

```
{
    "name": "FSCommon",
    "path": "S:\\",
    "type": "SHARED"
}
```

 Use os comandos a seguir para criar o perfil de armazenamento para as configurações `WS1` da estação de trabalho `WS3` e a configuração do trabalhador `WorkerConfig` usando o [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)in: `WS2` [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff

aws deadline create-storage-profile --farm-id $FARM_ID \
  --display-name WSAll \
  --os-family LINUX \
  --file-system-locations \
  '[
      {"name": "FSCommon", "type":"SHARED", "path":"/shared/common"},
      {"name": "FS1", "type":"SHARED", "path":"/shared/projects/project1"},
      {"name": "FS2", "type":"SHARED", "path":"/shared/projects/project2"}
  ]'

aws deadline create-storage-profile --farm-id $FARM_ID \
  --display-name WS1 \
  --os-family WINDOWS \
  --file-system-locations \
  '[
      {"name": "FSCommon", "type":"SHARED", "path":"S:\\"},
      {"name": "FS1", "type":"SHARED", "path":"Z:\\"}
   ]'

aws deadline create-storage-profile --farm-id $FARM_ID \
  --display-name WS2 \
  --os-family MACOS \
  --file-system-locations \
  '[
      {"name": "FSCommon", "type":"SHARED", "path":"/Volumes/common"},
      {"name": "FS2", "type":"SHARED", "path":"/Volumes/projects/project2"}
  ]'

aws deadline create-storage-profile --farm-id $FARM_ID \
  --display-name WorkerCfg \
  --os-family LINUX \
  --file-system-locations \
  '[
      {"name": "FSCommon", "type":"SHARED", "path":"/mnt/common"},
      {"name": "FS1", "type":"SHARED", "path":"/mnt/projects/project1"},
      {"name": "FS2", "type":"SHARED", "path":"/mnt/projects/project2"}
  ]'
```

**nota**  
Você deve consultar os locais do sistema de arquivos em seus perfis de armazenamento usando os mesmos valores para a `name` propriedade em todos os perfis de armazenamento em sua fazenda. O Deadline Cloud compara os nomes para determinar se os locais do sistema de arquivos de diferentes perfis de armazenamento se referem ao mesmo local ao gerar regras de mapeamento de caminhos. 

# Configurar perfis de armazenamento para frotas
<a name="configuring-storage-profiles-for-fleets"></a>

Você pode configurar uma frota para incluir um perfil de armazenamento que modele as localizações do sistema de arquivos em todos os trabalhadores da frota. A configuração do sistema de arquivos host de todos os trabalhadores em uma frota deve corresponder ao perfil de armazenamento da frota. Trabalhadores com diferentes configurações de sistema de arquivos devem estar em frotas separadas. 

Para definir a configuração da sua frota para usar o perfil `WorkerConfig` de armazenamento, use o [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)em [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
    }
  }"
```

# Configurar perfis de armazenamento para filas
<a name="storage-profiles-for-queues"></a>

 A configuração de uma fila inclui uma lista de nomes com distinção entre maiúsculas e minúsculas dos locais do sistema de arquivos compartilhado aos quais os trabalhos enviados à fila exigem acesso. Por exemplo, trabalhos enviados à fila `Q1` exigem locais do sistema de arquivos e. `FSCommon` `FS1` Os trabalhos enviados à fila `Q2` exigem localizações do sistema de arquivos `FSCommon` e. `FS2` 

Para definir as configurações da fila para exigir esses locais do sistema de arquivos, use o seguinte script: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of QUEUE2_ID to queue Q2's identifier
QUEUE2_ID=queue-00112233445566778899aabbccddeeff

aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \
  --required-file-system-location-names-to-add FSComm FS1

aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \
  --required-file-system-location-names-to-add FSComm FS2
```

 A configuração de uma fila também inclui uma lista de perfis de armazenamento permitidos que se aplicam aos trabalhos enviados e às frotas associadas a essa fila. Somente perfis de armazenamento que definem os locais do sistema de arquivos para todos os locais necessários do sistema de arquivos para a fila são permitidos na lista de perfis de armazenamento permitidos da fila. 

Um trabalho falhará se você o enviar com um perfil de armazenamento que não esteja na lista de perfis de armazenamento permitidos para a fila. Você sempre pode enviar um trabalho sem perfil de armazenamento para uma fila. As configurações da estação de trabalho rotuladas `WSAll` e `WS1` ambas têm os locais necessários do sistema de arquivos (`FSCommon`e`FS1`) para a fila. `Q1` Eles precisam ter permissão para enviar trabalhos para a fila. Da mesma forma, as configurações `WSAll` da estação de trabalho `WS2` atendem aos requisitos de fila. `Q2` Eles precisam ter permissão para enviar trabalhos para essa fila. Atualize as duas configurações de fila para permitir que os trabalhos sejam enviados com esses perfis de armazenamento usando o seguinte script: 

```
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff
# Change the value of WS1 to the identifier of the WS1 storage profile
WS1_ID=sp-00112233445566778899aabbccddeeff
# Change the value of WS2 to the identifier of the WS2 storage profile
WS2_ID=sp-00112233445566778899aabbccddeeff

aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID \
  --allowed-storage-profile-ids-to-add $WSALL_ID $WS1_ID

aws deadline update-queue --farm-id $FARM_ID --queue-id $QUEUE2_ID \
  --allowed-storage-profile-ids-to-add $WSALL_ID $WS2_ID
```

 Se você adicionar o perfil `WS2` de armazenamento à lista de perfis de armazenamento permitidos para a fila, `Q1` ele falhará: 

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

 Isso ocorre porque o perfil `WS2` de armazenamento não contém uma definição para a localização do sistema de arquivos chamada `FS1` que a fila `Q1` exige. 

 A associação de uma frota configurada a um perfil de armazenamento que não está na lista de perfis de armazenamento permitidos da fila também falha. Por exemplo: 

```
$ aws deadline create-queue-fleet-association --farm-id $FARM_ID \
   --fleet-id $FLEET_ID \
   --queue-id $QUEUE1_ID

An error occurred (ValidationException) when calling the CreateQueueFleetAssociation operation: Mismatch between storage profile ids.
```

Para corrigir o erro, adicione o perfil de armazenamento nomeado `WorkerConfig` à lista de perfis de armazenamento permitidos para fila `Q1` e fila`Q2`. Em seguida, associe a frota a essas filas para que os trabalhadores da frota possam executar trabalhos em ambas as filas. 

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

# Derive regras de mapeamento de caminhos a partir de perfis de armazenamento
<a name="deriving-path-mapping-rules-from-storage-profiles"></a>

 As regras de mapeamento de caminhos descrevem como os caminhos devem ser remapeados do trabalho até a localização real do caminho em um host de trabalho. Quando uma tarefa está sendo executada em um trabalhador, o perfil de armazenamento do trabalho é comparado ao perfil de armazenamento da frota do trabalhador para derivar as regras de mapeamento de caminhos para a tarefa. 

 O Deadline Cloud cria uma regra de mapeamento para cada um dos locais necessários do sistema de arquivos na configuração da fila. Por exemplo, um trabalho enviado com o perfil `WSAll` de armazenamento para a fila `Q1` tem as regras de mapeamento de caminhos: 
+  `FSComm`: `/shared/common -> /mnt/common` 
+  `FS1`: `/shared/projects/project1 -> /mnt/projects/project1` 

 O Deadline Cloud cria regras para `FSComm` os locais do sistema de `FS1` arquivos, mas não para o local do sistema de `FS2` arquivos, embora os perfis `WSAll` e `WorkerConfig` de armazenamento sejam definidos`FS2`. Isso ocorre porque a lista `Q1` de localizações obrigatórias do sistema de arquivos da fila é`["FSComm", "FS1"]`. 

 Você pode confirmar as regras de mapeamento de caminhos disponíveis para trabalhos enviados com um perfil de armazenamento específico enviando um trabalho que imprima o [arquivo de regras de mapeamento de caminhos do Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping) e, em seguida, lendo o registro da sessão após a conclusão do trabalho: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSALL storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

aws deadline create-job --farm-id $FARM_ID --queue-id $QUEUE1_ID \
  --priority 50 \
  --storage-profile-id $WSALL_ID \
  --template-type JSON --template \
  '{
    "specificationVersion": "jobtemplate-2023-09",
    "name": "DemoPathMapping",
    "steps": [
      {
        "name": "ShowPathMappingRules",
        "script": {
          "actions": {
            "onRun": {
              "command": "/bin/cat",
              "args": [ "{{Session.PathMappingRulesFile}}" ]
            }
          }
        }
      }
    ]
  }'
```

 Se você usar a [CLI do Deadline Cloud](https://pypi.org/project/deadline/) para enviar trabalhos, sua `settings.storage_profile_id` configuração define o perfil de armazenamento que os trabalhos enviados com a CLI terão. Para enviar trabalhos com o perfil `WSAll` de armazenamento, defina: 

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

 Para executar um trabalhador gerenciado pelo cliente como se estivesse sendo executado na infraestrutura de amostra, siga o procedimento em [Executar o agente de trabalho](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/run-worker.html) no *Guia do usuário do Deadline Cloud* para executar um trabalhador com. AWS CloudShell Se você seguiu essas instruções antes, exclua primeiro `~/demoenv-logs` os `~/demoenv-persist` diretórios e. Além disso, defina os valores das variáveis de `DEV_CMF_ID` ambiente `DEV_FARM_ID` e de ambiente às quais as direções fazem referência da seguinte forma antes de fazer isso: 

```
DEV_FARM_ID=$FARM_ID
DEV_CMF_ID=$FLEET_ID
```

 Depois que o trabalho for executado, você poderá ver as regras de mapeamento de caminhos no arquivo de log do trabalho: 

```
cat demoenv-logs/${QUEUE1_ID}/*.log
...
JJSON log results (see below)
...
```

O log contém mapeamento para os sistemas de `FSComm` arquivos `FS1` e. Reformatada para facilitar a leitura, a entrada do registro tem a seguinte aparência:

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

 Você pode enviar trabalhos com diferentes perfis de armazenamento para ver como as regras de mapeamento de caminhos mudam. 

# Use anexos de trabalho para compartilhar arquivos
<a name="build-job-attachments"></a>

Use *anexos de tarefas* para disponibilizar arquivos que não estão em diretórios compartilhados para suas tarefas e para capturar os arquivos de saída se eles não estiverem gravados em diretórios compartilhados. Job attachments usa o Amazon S3 para transferir arquivos entre hosts. Os arquivos são armazenados em buckets do S3 e você não precisa fazer upload de um arquivo se o conteúdo não tiver sido alterado.

Você deve usar anexos de trabalho ao executar trabalhos em [frotas gerenciadas por serviços, pois os](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/smf-manage.html) hosts não compartilham os locais do sistema de arquivos. Os anexos de trabalho também são úteis com [frotas gerenciadas pelo cliente quando os](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/manage-cmf.html) arquivos de entrada ou saída de um trabalho são armazenados em um sistema de arquivos de rede compartilhado, como quando seu pacote de [trabalhos contém scripts shell ou Python](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/submit-job-bundle.html). 

 Quando você envia um pacote de trabalhos com a [CLI do Deadline Cloud](https://pypi.org/project/deadline/) ou com um remetente do Deadline Cloud, os anexos do trabalho usam o perfil de armazenamento do trabalho e os locais necessários do sistema de arquivos da fila para identificar os arquivos de entrada que não estão em um host de trabalho e devem ser enviados para o Amazon S3 como parte do envio do trabalho. Esses perfis de armazenamento também ajudam o Deadline Cloud a identificar os arquivos de saída nos locais de hospedagem dos trabalhadores que devem ser carregados no Amazon S3 para que estejam disponíveis em sua estação de trabalho. 

 Os exemplos de anexos de trabalho usam as configurações de fazenda, frota, filas e perfis de armazenamento de e. [Exemplo de infraestrutura de projeto](sample-project-infrastructure.md) [Perfis de armazenamento e mapeamento de caminhos](storage-profiles-and-path-mapping.md) Você deve passar por essas seções antes desta. 

Nos exemplos a seguir, você usa um pacote de tarefas de amostra como ponto de partida e, em seguida, o modifica para explorar a funcionalidade do anexo de tarefas. Pacotes de tarefas são a melhor maneira de seus trabalhos usarem anexos de trabalho. Eles combinam um modelo de [trabalho do Open Job Description](https://github.com/OpenJobDescription/openjd-specifications/wiki) em um diretório com arquivos adicionais que listam os arquivos e diretórios exigidos pelos trabalhos que usam o pacote de trabalhos. Para obter mais informações sobre pacotes de tarefas, consulte[Modelos de Open Job Description (OpenJD) para Deadline Cloud](build-job-bundle.md).

# Enviando arquivos com um trabalho
<a name="submitting-files-with-a-job"></a>

Com o Deadline Cloud, você pode permitir que os fluxos de trabalho acessem arquivos de entrada que não estão disponíveis em locais de sistemas de arquivos compartilhados em hosts de trabalho. Os anexos de tarefas permitem que as tarefas de renderização acessem arquivos que residem somente em uma unidade de estação de trabalho local ou em um ambiente de frota gerenciado por serviços. Ao enviar um pacote de tarefas, você pode incluir listas de arquivos de entrada e diretórios exigidos pelo trabalho. O Deadline Cloud identifica esses arquivos não compartilhados, os carrega da máquina local para o Amazon S3 e os baixa para o host do trabalhador. Ele simplifica o processo de transferência de ativos de entrada para os nós de renderização, garantindo que todos os arquivos necessários estejam acessíveis para execução distribuída de trabalhos.

Você pode especificar os arquivos para trabalhos diretamente no pacote de trabalhos, usar parâmetros no modelo de trabalho que você fornece usando variáveis de ambiente ou um script e usar o `assets_references` arquivo do trabalho. Você pode usar um desses métodos ou uma combinação dos três. Você pode especificar um perfil de armazenamento para o pacote do trabalho para que ele carregue somente os arquivos que foram alterados na estação de trabalho local.

Esta seção usa um exemplo de pacote de tarefas GitHub para demonstrar como o Deadline Cloud identifica os arquivos em seu trabalho para upload, como esses arquivos são organizados no Amazon S3 e como são disponibilizados para os hosts de trabalho que processam seus trabalhos. 

**Topics**
+ [Como o Deadline Cloud carrega arquivos para o Amazon S3](what-job-attachments-uploads-to-amazon-s3.md)
+ [Como o Deadline Cloud escolhe os arquivos a serem enviados](how-job-attachments-decides-what-to-upload-to-amazon-s3.md)
+ [Como os trabalhos encontram arquivos de entrada de anexos de trabalhos](how-jobs-find-job-attachments-input-files.md)

# Como o Deadline Cloud carrega arquivos para o Amazon S3
<a name="what-job-attachments-uploads-to-amazon-s3"></a>

Este exemplo mostra como o Deadline Cloud carrega arquivos da sua estação de trabalho ou host de trabalho para o Amazon S3 para que eles possam ser compartilhados. Ele usa um pacote de tarefas de amostra GitHub e a CLI do Deadline Cloud para enviar trabalhos.

 Comece clonando o [ GitHubrepositório de amostras do Deadline Cloud](https://github.com/aws-deadline/deadline-cloud-samples) em seu [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)ambiente e, em seguida, copie o pacote de `job_attachments_devguide` tarefas em seu diretório inicial: 

```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide ~/
```

 Instale a [CLI do Deadline Cloud](https://pypi.org/project/deadline/) para enviar pacotes de tarefas: 

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

 O pacote de `job_attachments_devguide` tarefas tem uma única etapa com uma tarefa que executa um script bash shell cujo local do sistema de arquivos é passado como um parâmetro do trabalho. A definição do parâmetro do trabalho é: 

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

 O `IN` valor da `dataFlow` propriedade informa aos anexos do trabalho que o valor do `ScriptFile` parâmetro é uma entrada para o trabalho. O valor da `default` propriedade é um local relativo ao diretório do pacote de tarefas, mas também pode ser um caminho absoluto. Essa definição de parâmetro declara o `script.sh` arquivo no diretório do pacote de tarefas como um arquivo de entrada necessário para a execução da tarefa. 

 Em seguida, certifique-se de que a CLI do Deadline Cloud não tenha um perfil de armazenamento configurado e envie o trabalho para a fila: `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/
```

 A saída da CLI do Deadline Cloud após a execução desse comando é semelhante a: 

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

Quando você envia o trabalho, o Deadline Cloud primeiro faz o hash do `script.sh` arquivo e depois o carrega para o Amazon S3. 

O Deadline Cloud trata o bucket S3 como armazenamento endereçável ao conteúdo. Os arquivos são enviados para objetos do S3. O nome do objeto é derivado de um hash do conteúdo do arquivo. Se dois arquivos tiverem conteúdos idênticos, eles terão o mesmo valor de hash, independentemente de onde os arquivos estejam localizados ou do nome que tenham. Esse armazenamento endereçável por conteúdo permite que o Deadline Cloud evite o upload de um arquivo se ele já estiver disponível.

 Você pode usar a [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) para ver os objetos que foram enviados para o 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
```

 Dois objetos foram enviados para o S3: 
+  `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128`— O conteúdo do`script.sh`. [O valor `87cb19095dd5d78fcaf56384ef0e6241` na chave do objeto é o hash do conteúdo do arquivo, e a extensão `xxh128` indica que o valor do hash foi calculado como um xxhash de 128 bits.](https://xxhash.com/) 
+  `DeadlineCloud/Manifests/<farm-id>/<queue-id>/Inputs/<guid>/a1d221c7fd97b08175b3872a37428e8c_input`— O objeto manifesto para o envio do trabalho. Os valores `<farm-id>``<queue-id>`, e `<guid>` são o identificador da fazenda, o identificador da fila e um valor hexidecimal aleatório. O valor `a1d221c7fd97b08175b3872a37428e8c` neste exemplo é um valor de hash calculado a partir da string`/home/cloudshell-user/job_attachments_devguide`, o diretório em que `script.sh` está localizado. 

 O objeto de manifesto contém as informações dos arquivos de entrada em um caminho raiz específico carregado no S3 como parte do envio do trabalho. Baixe esse arquivo de manifesto (`aws s3 cp s3://$Q1_S3_BUCKET/<objectname>`). Seu conteúdo é semelhante a: 

```
{
    "hashAlg": "xxh128",
    "manifestVersion": "2023-03-03",
    "paths": [
        {
            "hash": "87cb19095dd5d78fcaf56384ef0e6241",
            "mtime": 1721147454416085,
            "path": "script.sh",
            "size": 39
        }
    ],
    "totalSize": 39
}
```

Isso indica que o arquivo `script.sh` foi carregado e o hash do conteúdo desse arquivo é`87cb19095dd5d78fcaf56384ef0e6241`. Esse valor de hash corresponde ao valor no nome `DeadlineCloud/Data/87cb19095dd5d78fcaf56384ef0e6241.xxh128` do objeto. Ele é usado pelo Deadline Cloud para saber qual objeto baixar para o conteúdo desse arquivo.

 O esquema completo desse arquivo está [disponível em GitHub](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/job_attachments/asset_manifests/v2023_03_03/validate.py). 

Ao usar a [CreateJob operação](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateJob.html), você pode definir a localização dos objetos do manifesto. Você pode usar a [GetJoboperação](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) para ver a localização: 

```
{
    "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"
            }
        ]
    },
    ...
}
```

# Como o Deadline Cloud escolhe os arquivos a serem enviados
<a name="how-job-attachments-decides-what-to-upload-to-amazon-s3"></a>

 Os arquivos e diretórios que os anexos de trabalho consideram para serem carregados no Amazon S3 como entradas para seu trabalho são: 
+  Os valores de todos os parâmetros `PATH` de trabalho do tipo definidos no modelo de trabalho do pacote de tarefas com um `dataFlow` valor de `IN` ou. `INOUT`
+  Os arquivos e diretórios listados como entradas no arquivo de referências de ativos do pacote de tarefas. 

 Se você enviar um trabalho sem perfil de armazenamento, todos os arquivos considerados para envio serão enviados. Se você enviar um trabalho com um perfil de armazenamento, os arquivos não serão enviados para o Amazon S3 se estiverem localizados nos locais do sistema de arquivos do `SHARED` tipo do perfil de armazenamento, que também são locais obrigatórios do sistema de arquivos para a fila. Espera-se que esses locais estejam disponíveis nos hosts de trabalho que executam o trabalho, portanto, não há necessidade de carregá-los para o S3. 

 Neste exemplo, você cria locais do sistema de `SHARED` arquivos `WSAll` em seu CloudShell ambiente da AWS e, em seguida, adiciona arquivos a esses locais do sistema de arquivos. Use o seguinte comando: 

```
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

sudo mkdir -p /shared/common /shared/projects/project1 /shared/projects/project2
sudo chown -R cloudshell-user:cloudshell-user /shared

for d in /shared/common /shared/projects/project1 /shared/projects/project2; do
  echo "File contents for $d" > ${d}/file.txt
done
```

 Em seguida, adicione um arquivo de referências de ativos ao pacote de tarefas que inclua todos os arquivos que você criou como entradas para o trabalho. Use o seguinte comando: 

```
cat > ${HOME}/job_attachments_devguide/asset_references.yaml << EOF
assetReferences:
  inputs:
    filenames:
    - /shared/common/file.txt
    directories:
    - /shared/projects/project1
    - /shared/projects/project2
EOF
```

 Em seguida, configure a CLI do Deadline Cloud para enviar trabalhos com o perfil `WSAll` de armazenamento e, em seguida, envie o pacote de trabalhos: 

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

O Deadline Cloud carrega dois arquivos para o Amazon S3 quando você envia o trabalho. Você pode baixar os objetos de manifesto do trabalho do S3 para ver os arquivos enviados: 

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

 Neste exemplo, há um único arquivo de manifesto com o seguinte conteúdo: 

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

 Use a [GetJob operação](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetJob.html) do manifesto para ver se `rootPath` é “/”. 

```
aws deadline get-job --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID --query 'attachments.manifests[*]'
```

 O caminho raiz para o conjunto de arquivos de entrada é sempre o subcaminho comum mais longo desses arquivos. Se o seu trabalho foi enviado pelo Windows Instead e há arquivos de entrada sem um subcaminho comum porque eles estavam em unidades diferentes, você verá um caminho raiz separado em cada unidade. Os caminhos em um manifesto são sempre relativos ao caminho raiz do manifesto, então os arquivos de entrada que foram carregados são: 
+  `/home/cloudshell-user/job_attachments_devguide/script.sh`— O arquivo de script no pacote de tarefas. 
+  `/shared/projects/project2/file.txt`— O arquivo em um local do sistema de `SHARED` arquivos no perfil `WSAll` de armazenamento que **não** está na lista de locais necessários do sistema de arquivos para a fila`Q1`. 

Os arquivos nos locais do sistema de arquivos `FSCommon` (`/shared/common/file.txt`) e `FS1` (`/shared/projects/project1/file.txt`) não estão na lista. Isso ocorre porque esses locais do sistema de arquivos estão `SHARED` no perfil `WSAll` de armazenamento e ambos estão na lista de locais necessários do sistema de arquivos na fila`Q1`. 

Você pode ver os locais do sistema de arquivos considerados `SHARED` para um trabalho que é enviado com um perfil de armazenamento específico com a [GetStorageProfileForQueue operação](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_GetStorageProfileForQueue.html). Para consultar o perfil de armazenamento `WSAll` para fila, `Q1` use o seguinte comando: 

```
aws deadline get-storage-profile --farm-id $FARM_ID --storage-profile-id $WSALL_ID

aws deadline get-storage-profile-for-queue --farm-id $FARM_ID --queue-id $QUEUE1_ID --storage-profile-id $WSALL_ID
```

# Como os trabalhos encontram arquivos de entrada de anexos de trabalhos
<a name="how-jobs-find-job-attachments-input-files"></a>

 Para que um trabalho use os arquivos que o Deadline Cloud carrega para o Amazon S3 usando anexos de trabalho, seu trabalho precisa desses arquivos disponíveis por meio do sistema de arquivos nos hosts do trabalhador. Quando uma [sessão](https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#sessions) do seu trabalho é executada em um host de trabalho, o Deadline Cloud baixa os arquivos de entrada do trabalho em um diretório temporário na unidade local do host de trabalho e adiciona regras de mapeamento de caminhos para cada um dos caminhos raiz do trabalho na localização do sistema de arquivos na unidade local. 

 Neste exemplo, inicie o agente Deadline Cloud Worker em uma CloudShell guia da AWS. Deixe que todos os trabalhos enviados anteriormente terminem de ser executados e, em seguida, exclua os registros de trabalhos do diretório de registros: 

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

 O script a seguir modifica o pacote de tarefas para mostrar todos os arquivos no diretório de trabalho temporário da sessão e o conteúdo do arquivo de regras de mapeamento de caminhos e, em seguida, envia uma tarefa com o pacote modificado: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id $WSALL_ID

cat > ~/job_attachments_devguide/script.sh << EOF
#!/bin/bash

echo "Session working directory is: \$(pwd)"
echo
echo "Contents:"
find . -type f
echo
echo "Path mapping rules file: \$1"
jq . \$1
EOF

cat > ~/job_attachments_devguide/template.yaml << EOF
specificationVersion: jobtemplate-2023-09
name: "Job Attachments Explorer"
parameterDefinitions:
- name: ScriptFile
  type: PATH
  default: script.sh
  dataFlow: IN
  objectType: FILE
steps:
- name: Step
  script:
    actions:
      onRun:
        command: /bin/bash
        args:
        - "{{Param.ScriptFile}}"
        - "{{Session.PathMappingRulesFile}}"
EOF

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/
```

 Você pode ver o registro da execução do trabalho após ele ter sido executado pelo trabalhador em seu AWS CloudShell ambiente: 

```
cat demoenv-logs/queue-*/session*.log
```

O registro mostra que a primeira coisa que ocorre na sessão é que os dois arquivos de entrada do trabalho são baixados para o trabalhador: 

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

 A seguir está a saída de `script.sh` run by the job: 
+  Os arquivos de entrada enviados quando o trabalho foi enviado estão localizados em um diretório cujo nome começa com “assetroot” no diretório temporário da sessão. 
+  Os caminhos dos arquivos de entrada foram realocados em relação ao diretório “assetroot” em vez de em relação ao caminho raiz do manifesto de entrada () do trabalho. `"/"`
+  O arquivo de regras de mapeamento de caminhos contém uma regra adicional que é remapeada `"/"` para o caminho absoluto do diretório “assetroot”. 

 Por exemplo: 

```
2024-07-17 01:26:38,264 INFO Output:
2024-07-17 01:26:38,267 INFO Session working directory is: /sessions/session-5b33f
2024-07-17 01:26:38,267 INFO 
2024-07-17 01:26:38,267 INFO Contents:
2024-07-17 01:26:38,269 INFO ./tmp_xdhbsdo.sh
2024-07-17 01:26:38,269 INFO ./tmpdi00052b.json
2024-07-17 01:26:38,269 INFO ./assetroot-assetroot-3751a/shared/projects/project2/file.txt
2024-07-17 01:26:38,269 INFO ./assetroot-assetroot-3751a/home/cloudshell-user/job_attachments_devguide/script.sh
2024-07-17 01:26:38,269 INFO 
2024-07-17 01:26:38,270 INFO Path mapping rules file: /sessions/session-5b33f/tmpdi00052b.json
2024-07-17 01:26:38,282 INFO {
2024-07-17 01:26:38,282 INFO   "version": "pathmapping-1.0",
2024-07-17 01:26:38,282 INFO   "path_mapping_rules": [
2024-07-17 01:26:38,282 INFO     {
2024-07-17 01:26:38,282 INFO       "source_path_format": "POSIX",
2024-07-17 01:26:38,282 INFO       "source_path": "/shared/projects/project1",
2024-07-17 01:26:38,283 INFO       "destination_path": "/mnt/projects/project1"
2024-07-17 01:26:38,283 INFO     },
2024-07-17 01:26:38,283 INFO     {
2024-07-17 01:26:38,283 INFO       "source_path_format": "POSIX",
2024-07-17 01:26:38,283 INFO       "source_path": "/shared/common",
2024-07-17 01:26:38,283 INFO       "destination_path": "/mnt/common"
2024-07-17 01:26:38,283 INFO     },
2024-07-17 01:26:38,283 INFO     {
2024-07-17 01:26:38,283 INFO       "source_path_format": "POSIX",
2024-07-17 01:26:38,283 INFO       "source_path": "/",
2024-07-17 01:26:38,283 INFO       "destination_path": "/sessions/session-5b33f/assetroot-assetroot-3751a"
2024-07-17 01:26:38,283 INFO     }
2024-07-17 01:26:38,283 INFO   ]
2024-07-17 01:26:38,283 INFO }
```

**nota**  
 Se o trabalho que você enviar tiver vários manifestos com caminhos raiz diferentes, há um diretório com o nome “assetroot” diferente para cada um dos caminhos raiz. 

 Se precisar referenciar a localização do sistema de arquivos realocado de um dos seus arquivos de entrada, diretórios ou localizações do sistema de arquivos, você pode processar o arquivo de regras de mapeamento de caminhos em sua tarefa e realizar o remapeamento sozinho, ou adicionar um parâmetro de `PATH` tipo de tarefa ao modelo de tarefa em seu pacote de tarefas e passar o valor que você precisa remapear como o valor desse parâmetro. Por exemplo, o exemplo a seguir modifica o pacote de tarefas para ter um desses parâmetros de tarefa e, em seguida, envia uma tarefa com a localização `/shared/projects/project2` do sistema de arquivos como seu valor: 

```
cat > ~/job_attachments_devguide/template.yaml << EOF
specificationVersion: jobtemplate-2023-09
name: "Job Attachments Explorer"
parameterDefinitions:
- name: LocationToRemap
  type: PATH
steps:
- name: Step
  script:
    actions:
      onRun:
        command: /bin/echo
        args:
        - "The location of {{RawParam.LocationToRemap}} in the session is {{Param.LocationToRemap}}"
EOF

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID job_attachments_devguide/ \
  -p LocationToRemap=/shared/projects/project2
```

 O arquivo de log para a execução desse trabalho contém sua saída: 

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

# Obtendo arquivos de saída de um trabalho
<a name="getting-output-files-from-a-job"></a>

Este exemplo mostra como o Deadline Cloud identifica os arquivos de saída que seus trabalhos geram, decide se deseja fazer o upload desses arquivos para o Amazon S3 e como você pode obter esses arquivos de saída em sua estação de trabalho. 

 Use o pacote de `job_attachments_devguide_output` tarefas em vez do pacote de `job_attachments_devguide` tarefas para este exemplo. Comece fazendo uma cópia do pacote em seu AWS CloudShell ambiente a partir do seu clone do repositório de amostras GitHub do Deadline Cloud: 

```
cp -r deadline-cloud-samples/job_bundles/job_attachments_devguide_output ~/
```

 A diferença importante entre esse pacote de tarefas e o pacote de `job_attachments_devguide` tarefas é a adição de um novo parâmetro de tarefa no modelo de tarefa: 

```
...
parameterDefinitions:
...
- name: OutputDir
  type: PATH
  objectType: DIRECTORY
  dataFlow: OUT
  default: ./output_dir
  description: This directory contains the output for all steps.
...
```

 A `dataFlow` propriedade do parâmetro tem o valor`OUT`. O Deadline Cloud usa o valor dos parâmetros do `dataFlow` trabalho com um valor de `OUT` ou `INOUT` como resultados do seu trabalho. Se a localização do sistema de arquivos passada como um valor para esses tipos de parâmetros de trabalho for remapeada para uma localização do sistema de arquivos local no trabalhador que executa o trabalho, o Deadline Cloud procurará novos arquivos no local e os enviará para o Amazon S3 como resultados do trabalho. 

 Para ver como isso funciona, primeiro inicie o agente do Deadline Cloud Worker em uma AWS CloudShell guia. Permita que todos os trabalhos enviados anteriormente terminem de ser executados. Em seguida, exclua os registros de tarefas do diretório de registros: 

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

 Em seguida, envie um trabalho com esse pacote de trabalhos. Depois que o trabalhador estiver executando suas CloudShell execuções, veja os registros: 

```
# Change the value of FARM_ID to your farm's identifier
FARM_ID=farm-00112233445566778899aabbccddeeff
# Change the value of QUEUE1_ID to queue Q1's identifier
QUEUE1_ID=queue-00112233445566778899aabbccddeeff
# Change the value of WSALL_ID to the identifier of the WSAll storage profile
WSALL_ID=sp-00112233445566778899aabbccddeeff

deadline config set settings.storage_profile_id $WSALL_ID

deadline bundle submit --farm-id $FARM_ID --queue-id $QUEUE1_ID ./job_attachments_devguide_output
```

 O registro mostra que um arquivo foi detectado como saída e carregado no 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.
```

 O registro também mostra que o Deadline Cloud criou um novo objeto de manifesto no bucket do Amazon S3 configurado para uso por anexos de trabalho na fila. `Q1` O nome do objeto manifesto é derivado do farm, da fila, do trabalho, da etapa, da tarefa, do carimbo de data/hora e dos `sessionaction` identificadores da tarefa que gerou a saída. Baixe esse arquivo de manifesto para ver onde o Deadline Cloud colocou os arquivos de saída para essa tarefa: 

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

 O manifesto se parece com: 

```
{
  "hashAlg": "xxh128",
  "manifestVersion": "2023-03-03",
  "paths": [
    {
      "hash": "34178940e1ef9956db8ea7f7c97ed842",
      "mtime": 1721182390859777,
      "path": "output_dir/output.txt",
      "size": 117
    }
  ],
  "totalSize": 117
}
```

 Isso mostra que o conteúdo do arquivo de saída é salvo no Amazon S3 da mesma forma que os arquivos de entrada do trabalho são salvos. Semelhante aos arquivos de entrada, o arquivo de saída é armazenado no S3 com um nome de objeto contendo o hash do arquivo e o prefixo. `DeadlineCloud/Data` 

```
$ aws s3 ls --recursive s3://$Q1_S3_BUCKET | grep 34178940e1ef9956db8ea7f7c97ed842
2024-07-17 02:13:11        117 DeadlineCloud/Data/34178940e1ef9956db8ea7f7c97ed842.xxh128
```

 Você pode baixar a saída de um trabalho para sua estação de trabalho usando o monitor do Deadline Cloud ou a CLI do Deadline Cloud: 

```
deadline job download-output --farm-id $FARM_ID --queue-id $QUEUE1_ID --job-id $JOB_ID
```

 O valor do parâmetro do `OutputDir` trabalho no trabalho enviado é`./output_dir`, portanto, a saída é baixada para um diretório chamado `output_dir` dentro do diretório do pacote de trabalhos. Se você especificou um caminho absoluto ou um local relativo diferente como valor para`OutputDir`, os arquivos de saída seriam baixados para esse local. 

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

# Usando arquivos de uma etapa em uma etapa dependente
<a name="using-files-output-from-a-step-in-a-dependent-step"></a>

Este exemplo mostra como uma etapa em uma tarefa pode acessar as saídas de uma etapa da qual ela depende na mesma tarefa. 

 Para disponibilizar as saídas de uma etapa para outra, o Deadline Cloud adiciona ações adicionais a uma sessão para baixar essas saídas antes de executar tarefas na sessão. Você diz a ele de quais etapas fazer o download das saídas declarando essas etapas como dependências da etapa que precisa usar as saídas. 

Use o pacote de `job_attachments_devguide_output` tarefas para este exemplo. Comece fazendo uma cópia em seu AWS CloudShell ambiente a partir do seu clone do GitHub repositório de amostras do Deadline Cloud. Modifique-a para adicionar uma etapa dependente que só é executada após a etapa existente e usa a saída dessa etapa: 

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

 O trabalho criado com esse pacote de trabalhos modificado é executado como duas sessões separadas, uma para a tarefa na etapa “Etapa” e outra para a tarefa na etapa "DependentStep”. 

Primeiro, inicie o agente Deadline Cloud Worker em uma CloudShell guia. Deixe que todos os trabalhos enviados anteriormente terminem de ser executados e, em seguida, exclua os registros do trabalho do diretório de registros: 

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

 Em seguida, envie um trabalho usando o pacote de `job_attachments_devguide_output` trabalhos modificado. Espere até que ele termine de ser executado no trabalhador em seu CloudShell ambiente. Veja os registros das duas sessões: 

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

 No registro da sessão da tarefa na etapa denominada`DependentStep`, há duas ações de download separadas executadas: 

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

 A primeira ação baixa o `script.sh` arquivo usado pela etapa chamada “Etapa”. A segunda ação baixa as saídas dessa etapa. O Deadline Cloud determina quais arquivos baixar usando o manifesto de saída gerado por essa etapa como um manifesto de entrada. 

 Mais tarde, no mesmo registro, você pode ver a saída da etapa chamada "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
```

# Crie limites de recursos para trabalhos
<a name="build-job-limits"></a>

Os trabalhos enviados ao Deadline Cloud podem depender de recursos compartilhados entre vários trabalhos. Por exemplo, uma fazenda pode ter mais trabalhadores do que licenças flutuantes para um recurso específico. Ou um servidor de arquivos compartilhado pode ser capaz de fornecer dados apenas para um número limitado de trabalhadores ao mesmo tempo. Em alguns casos, um ou mais trabalhos podem reivindicar todos esses recursos, causando erros devido à indisponibilidade de recursos quando novos trabalhadores são contratados. 

Para ajudar a resolver isso, você pode usar *limites* para esses recursos restritos. O Deadline Cloud considera a disponibilidade de recursos restritos e usa essas informações para garantir que os recursos estejam disponíveis à medida que novos funcionários são iniciados, para que os trabalhos tenham uma probabilidade menor de falhar devido à indisponibilidade de recursos.

Os limites são criados para toda a fazenda. Os trabalhos enviados a uma fila só podem adquirir limites associados à fila. Se você especificar um limite para um trabalho que não esteja associado à fila, o trabalho não será compatível e não será executado.

Para usar um limite, você 
+ [Crie um limite](job-limit-create.md)
+ [Associar um limite e uma fila](job-limit-associate.md)
+ [Envie um trabalho que exija limites](job-limit-job.md)

**nota**  
Se você executar um trabalho que tenha recursos restringidos em uma fila que não esteja associada a um limite, esse trabalho poderá consumir todos os recursos. Se você tiver um recurso restrito, certifique-se de que todas as etapas em trabalhos em filas que usam o recurso estejam associadas a um limite.

Para limites definidos em uma fazenda, associados a uma fila e especificados em um trabalho, uma das quatro coisas pode acontecer:
+ Se você criar um limite, associá-lo a uma fila e especificar o limite no modelo de um trabalho, o trabalho será executado e usará somente os recursos definidos no limite.
+ Se você criar um limite, especificá-lo em um modelo de trabalho, mas não associar o limite a uma fila, o trabalho será marcado como incompatível e não será executado.
+ Se você criar um limite, não o associar a uma fila e não especificar o limite no modelo de um trabalho, o trabalho será executado, mas não usará o limite.
+ Se você não usar nenhum limite, o trabalho será executado.

Se você associar um limite a várias filas, as filas compartilharão os recursos restringidos pelo limite. Por exemplo, se você criar um limite de 100 e uma fila estiver usando 60 recursos, outras filas poderão usar somente 40 recursos. Quando um recurso é liberado, ele pode ser usado por uma tarefa de qualquer fila.

O Deadline Cloud fornece duas AWS CloudFormation métricas para ajudar você a monitorar os recursos fornecidos por um limite. Você pode monitorar o número atual de recursos em uso e o número máximo de recursos disponíveis no limite. Para obter mais informações, consulte [Métricas de limite de recursos](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html#cloudwatch-metrics-limits) no *Guia do desenvolvedor do Deadline Cloud*.

Você aplica um limite a uma etapa do trabalho em um modelo de trabalho. Quando você especifica o nome da exigência de quantidade de um limite na `amounts` seção `hostRequirements` de uma etapa e um limite com o mesmo `amountRequirementName` é associado à fila do trabalho, as tarefas agendadas para essa etapa são restringidas pelo limite do recurso.

Se uma etapa exigir um recurso limitado por um limite atingido, as tarefas dessa etapa não serão realizadas por funcionários adicionais.

Você pode aplicar mais de um limite a uma etapa do trabalho. Por exemplo, se a etapa usar duas licenças de software diferentes, você poderá aplicar um limite separado para cada licença. Se uma etapa exigir dois limites e o limite de um dos recursos for atingido, as tarefas dessa etapa não serão realizadas por outros trabalhadores até que os recursos estejam disponíveis.

## Interrompendo e excluindo limites
<a name="job-limit-stop-delete"></a>

Quando você interrompe ou exclui a associação entre uma fila e um limite, um trabalho usando o limite interrompe o agendamento de tarefas a partir de etapas que exigem esse limite e bloqueia a criação de novas sessões para uma etapa.

As tarefas que estão no estado PRONTO permanecem prontas e as tarefas são retomadas automaticamente com a associação entre a fila e o limite se tornam ativas novamente. Você não precisa recolocar nenhum trabalho na fila.

Ao interromper ou excluir a associação entre uma fila e um limite, você tem duas opções sobre como interromper a execução de tarefas:
+ Pare e cancele tarefas — os trabalhadores com sessões que atingiram o limite cancelam todas as tarefas.
+ Pare e conclua as tarefas em execução — os trabalhadores com sessões que atingiram o limite concluem suas tarefas.

Quando você exclui um limite usando o console, os trabalhadores primeiro param de executar tarefas imediatamente ou, eventualmente, quando elas são concluídas. Quando a associação é excluída, acontece o seguinte: 
+ As etapas que exigem o limite estão marcadas como não compatíveis.
+ Todo o trabalho contendo essas etapas é cancelado, incluindo etapas que não exigem o limite.
+ O trabalho está marcado como não compatível.

Se a fila associada ao limite tiver uma frota associada com uma capacidade de frota que corresponda ao nome da exigência de quantidade do limite, essa frota continuará processando trabalhos com o limite especificado.

# Crie um limite
<a name="job-limit-create"></a>

Você cria um limite usando o console do Deadline Cloud ou a [CreateLimit operação na API Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateLimit.html). Os limites são definidos para uma fazenda, mas associados às filas. Depois de criar um limite, você pode associá-lo a uma ou mais filas.

**Para criar um limite**

1. No painel do console do [Deadline Cloud (console](https://console.aws.amazon.com/deadlinecloud/home) do Deadline Cloud), selecione a fazenda para a qual você deseja criar uma fila.

1. Escolha a fazenda à qual adicionar o limite, escolha a guia **Limites** e, em seguida, escolha **Criar limite**.

1. Forneça os detalhes do limite. O **nome do requisito de valor** é o nome usado no modelo de trabalho para identificar o limite. Ele deve começar com o prefixo **amount.** seguido pelo nome do valor. O nome do requisito de quantia deve ser exclusivo nas filas associadas ao limite.

1. Se você escolher **Definir um valor máximo**, esse será o número total de recursos permitidos por esse limite. Se você escolher **Sem quantidade máxima**, o uso de recursos não será limitado. Mesmo quando o uso de recursos não é limitado, a CloudWatch métrica da `CurrentCount` Amazon é emitida para que você possa acompanhar o uso. Para obter mais informações, consulte [CloudWatchas métricas](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/cloudwatch-metrics.html) no *Guia do desenvolvedor do Deadline Cloud*.

1. Se você já conhece as filas que devem usar o limite, você pode escolhê-las agora. Você não precisa associar uma fila para criar um limite.

1. Escolha **Criar limite**.

# Associar um limite e uma fila
<a name="job-limit-associate"></a>

Depois de criar um limite, você pode associar uma ou mais filas ao limite. Somente as filas associadas a um limite usam os valores especificados no limite.

Você cria uma associação com uma fila usando o console do Deadline Cloud ou a [CreateQueueLimitAssociation operação na API do Deadline Cloud](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueueLimitAssociation.html).

**Para associar uma fila a um limite**

1. No painel do console do [Deadline Cloud (console](https://console.aws.amazon.com/deadlinecloud/home) do Deadline Cloud), selecione a fazenda em que você deseja associar um limite a uma fila.

1. Escolha a guia **Limites**, escolha o limite ao qual associar uma fila e escolha **Editar limite**.

1. Na seção **Associar filas**, escolha as filas a serem associadas ao limite.

1. Escolha **Salvar alterações**.

# Envie um trabalho que exija limites
<a name="job-limit-job"></a>

Você aplica um limite especificando-o como um requisito de host para o trabalho ou etapa do trabalho. Se você não especificar um limite em uma etapa e essa etapa usar um recurso associado, o uso da etapa não será contabilizado no limite quando os trabalhos forem agendados.

Alguns remetentes do Deadline Cloud permitem que você defina um requisito de anfitrião. Você pode especificar o nome do requisito de valor do limite no remetente para aplicar o limite.

Se o remetente não aceitar a adição de requisitos de hospedagem, você também pode aplicar um limite editando o modelo de trabalho para o trabalho.

**Para aplicar um limite a uma etapa do trabalho no pacote de tarefas**

1. Abra o modelo de trabalho para o trabalho usando um editor de texto. O modelo de trabalho está localizado no diretório do pacote de tarefas do trabalho. Para obter mais informações, consulte [Pacotes de tarefas](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/build-job-bundle.html) no *Guia do desenvolvedor do Deadline Cloud*.

1. Encontre a definição da etapa à qual aplicar o limite.

1. Adicione o seguinte à definição da etapa. *amount.name*Substitua pelo nome do valor exigido do seu limite. Para uso típico, você deve definir o `min` valor como 1.

------
#### [ YAML ]

   ```
     hostRequirements:
       amounts:
       - name: amount.name
         min: 1
   ```

------
#### [ JSON ]

   ```
   "hostRequirements": {
       "amounts": [
           {
               "name": "amount.name",
               "min": "1"
           }
       }
   }
   ```

------

   Você pode adicionar vários limites a uma etapa do trabalho da seguinte maneira. Substitua *amount.name\$11* e *amount.name\$12* pelos nomes dos requisitos de valor de seus limites.

------
#### [ 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. Salve as alterações no modelo de trabalho.

# Como enviar uma vaga para o Deadline Cloud
<a name="submit-jobs-how"></a>

Há muitas maneiras diferentes de enviar trabalhos para o AWS Deadline Cloud. Esta seção descreve algumas maneiras pelas quais você pode enviar trabalhos usando as ferramentas fornecidas pelo Deadline Cloud ou criando suas próprias ferramentas personalizadas para suas cargas de trabalho. 
+ De um terminal — para quando você está desenvolvendo um pacote de tarefas pela primeira vez ou quando os usuários que enviam uma tarefa se sentem confortáveis usando a linha de comando
+ A partir de um script — para personalizar e automatizar cargas de trabalho
+ De um aplicativo — para quando o trabalho do usuário está em um aplicativo ou quando o contexto de um aplicativo é importante.

 Os exemplos a seguir usam a biblioteca `deadline` Python e a ferramenta de linha de `deadline` comando. Ambos estão disponíveis [PyPi](https://pypi.org/project/deadline/)e [hospedados em GitHub](https://github.com/aws-deadline/deadline-cloud). 

**Topics**
+ [Envie um trabalho para o Deadline Cloud a partir de um terminal](from-a-terminal.md)
+ [Envie um trabalho para o Deadline Cloud usando um script](from-a-script.md)
+ [Envie uma vaga dentro de uma candidatura](from-within-applications.md)

# Envie um trabalho para o Deadline Cloud a partir de um terminal
<a name="from-a-terminal"></a>

Usando apenas um pacote de tarefas e a CLI do Deadline Cloud, você ou seus usuários mais técnicos podem rapidamente escrever pacotes de tarefas para testar o envio de um trabalho. Use o comando a seguir para enviar um pacote de tarefas: 

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

 Se você enviar um pacote de tarefas com parâmetros que não tenham padrões no pacote, você poderá especificá-los com a opção /. `-p` `--parameter` 

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

 Para obter uma lista completa das opções disponíveis, execute o comando help: 

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

## Envie um trabalho para o Deadline Cloud usando uma GUI
<a name="with-a-submission-window"></a>

 A CLI do Deadline Cloud também vem com uma interface gráfica de usuário que permite que os usuários vejam os parâmetros que devem fornecer antes de enviar um trabalho. Se seus usuários preferirem não interagir com a linha de comando, você pode escrever um atalho na área de trabalho que abre uma caixa de diálogo para enviar um pacote de tarefas específico: 

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

 Use a `--browse` opção can para que o usuário possa selecionar um pacote de tarefas: 

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

 Para obter uma lista completa das opções disponíveis, execute o comando help: 

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

# Envie um trabalho para o Deadline Cloud usando um script
<a name="from-a-script"></a>

 Para automatizar o envio de trabalhos para o Deadline Cloud, você pode criá-los usando ferramentas como bash, Powershell e arquivos em lote. 

Você pode adicionar funcionalidades como preencher parâmetros de trabalho a partir de variáveis de ambiente ou outros aplicativos. Você também pode enviar vários trabalhos em uma linha ou criar um script para a criação de um pacote de trabalhos para envio. 

## Envie um trabalho usando Python
<a name="with-python"></a>

O Deadline Cloud também tem uma biblioteca Python de código aberto para interagir com o serviço. O [código-fonte está disponível em GitHub](https://github.com/aws-deadline/deadline-cloud). 

A biblioteca está disponível em pypi via pip (). `pip install deadline` É a mesma biblioteca usada pela ferramenta CLI do Deadline Cloud: 

```
from deadline.client import api

job_bundle_path = "/path/to/job/bundle"
job_parameters = [
    {
        "name": "parameter_name",
        "value": "parameter_value"
    },
]

job_id = api.create_job_from_job_bundle(
    job_bundle_path,
    job_parameters
)
print(job_id)
```

 Para criar uma caixa de diálogo como o `deadline bundle gui-submit` comando, você pode usar a `show_job_bundle_submitter` função do [`deadline.client.ui.job_bundle_submitter`.](https://github.com/aws-deadline/deadline-cloud/blob/mainline/src/deadline/client/ui/job_bundle_submitter.py) 

 O exemplo a seguir inicia um aplicativo Qt e mostra o remetente do pacote de tarefas: 

```
# The GUI components must be installed with pip install "deadline[gui]"
import sys
from qtpy.QtWidgets import QApplication
from deadline.client.ui.job_bundle_submitter import show_job_bundle_submitter

app = QApplication(sys.argv)
submitter = show_job_bundle_submitter(browse=True)
submitter.show()
app.exec()
print(submitter.create_job_response)
```

Para criar seu próprio diálogo, você pode usar a `SubmitJobToDeadlineDialog` classe em [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). Você pode transmitir valores, incorporar sua própria guia específica do trabalho e determinar como o pacote de trabalhos é criado (ou transmitido). 

# Envie uma vaga dentro de uma candidatura
<a name="from-within-applications"></a>

 Para facilitar o envio de trabalhos pelos usuários, você pode usar os tempos de execução de scripts ou os sistemas de plug-ins fornecidos por um aplicativo. Os usuários têm uma interface familiar e você pode criar ferramentas poderosas que os auxiliam no envio de uma carga de trabalho. 

## Incorporar pacotes de tarefas em um aplicativo
<a name="simple-embedding"></a>

Este exemplo demonstra o envio de pacotes de tarefas que você disponibiliza no aplicativo.

 Para dar ao usuário acesso a esses pacotes de tarefas, crie um script incorporado em um item de menu que inicie a CLI do Deadline Cloud. 

 O script a seguir permite que o usuário selecione o pacote de tarefas: 

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

 Em vez disso, para usar um pacote de tarefas específico em um item de menu, use o seguinte: 

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

 Isso abre uma caixa de diálogo na qual o usuário pode modificar os parâmetros, entradas e saídas do trabalho e, em seguida, enviar o trabalho. Você pode ter itens de menu diferentes para pacotes de tarefas diferentes para um usuário enviar em uma inscrição. 

Se o trabalho enviado com um pacote de trabalhos contiver parâmetros e referências de ativos semelhantes em todos os envios, você poderá preencher os valores padrão no pacote de trabalhos subjacente. 

## Obtenha informações de um aplicativo
<a name="deep-integration"></a>

Para extrair informações de um aplicativo para que os usuários não precisem adicioná-las manualmente ao envio, você pode integrar o Deadline Cloud ao aplicativo para que seus usuários possam enviar trabalhos usando uma interface familiar sem precisar sair do aplicativo ou usar ferramentas de linha de comando.

Se seu aplicativo tiver um tempo de execução de script compatível com Python e pyside/pyqt, você poderá usar os componentes da GUI da biblioteca de cliente do [Deadline Cloud para criar uma interface de usuário](https://github.com/aws-deadline/deadline-cloud). Por exemplo, consulte [Integração do Deadline Cloud para Maya](https://github.com/aws-deadline/deadline-cloud-for-maya) em GitHub. 

A biblioteca cliente do Deadline Cloud fornece operações que fazem o seguinte para ajudar você a fornecer uma experiência de usuário forte e integrada:
+ Extraia parâmetros de ambiente de fila, parâmetros de trabalho e referências de ativos a partir de variáveis de ambiente e chamando o SDK do aplicativo.
+ Defina os parâmetros no pacote de tarefas. Para evitar a modificação do pacote original, você deve fazer uma cópia do pacote e enviar a cópia.

Se você usar o `deadline bundle gui-submit` comando para enviar o pacote de tarefas, deverá programaticamente os `asset_references.yaml` arquivos `parameter_values.yaml` e para transmitir as informações do aplicativo. Para obter mais informações sobre esses arquivos, consulte[Modelos de Open Job Description (OpenJD) para Deadline Cloud](build-job-bundle.md).

Se você precisar de controles mais complexos do que os oferecidos pelo OpenJD, precisar abstrair o trabalho do usuário ou quiser que a integração corresponda ao estilo visual do aplicativo, você pode escrever sua própria caixa de diálogo que chama a biblioteca cliente do Deadline Cloud para enviar o trabalho.

# Agende trabalhos no Deadline Cloud
<a name="build-jobs-scheduling"></a>

Depois que um trabalho é criado, AWS o Deadline Cloud o programa para ser processado em uma ou mais frotas associadas a uma fila. A frota que processa uma tarefa específica é escolhida com base nos recursos configurados para a frota e nos requisitos do host de uma etapa específica.

Os trabalhos em uma fila são programados na ordem de prioridade de melhor esforço, da maior para a menor. Quando dois trabalhos têm a mesma prioridade, o trabalho mais antigo é agendado primeiro.

As seções a seguir fornecem detalhes do processo de agendamento de um trabalho.

## Determine a compatibilidade da frota
<a name="jobs-scheduling-compatibility"></a>

Depois que um trabalho é criado, o Deadline Cloud verifica os requisitos do host para cada etapa do trabalho em relação aos recursos das frotas associadas à fila para a qual o trabalho foi enviado. Se uma frota atender aos requisitos do anfitrião, o trabalho será colocado no `READY` estado.

Se alguma etapa do trabalho tiver requisitos que não possam ser atendidos por uma frota associada à fila, o status da etapa será definido como. `NOT_COMPATIBLE` Além disso, as demais etapas do trabalho são canceladas.

As capacidades de uma frota são definidas no nível da frota. Mesmo que um trabalhador em uma frota atenda aos requisitos do trabalho, ele não receberá tarefas do trabalho se sua frota não atender aos requisitos do trabalho.

O modelo de tarefa a seguir tem uma etapa que especifica os requisitos de host para a etapa:

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

Esse trabalho pode ser programado para uma frota com os seguintes recursos:

```
{
    "vCpuCount": {"min": 4, "max": 8},
    "memoryMiB": {"min": 1024},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64"
}
```

Esse trabalho não pode ser programado para uma frota com nenhum dos seguintes recursos:

```
{
    "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.
```

## Dimensionamento da frota
<a name="jobs-scheduling-scaling"></a>

Quando um trabalho é atribuído a uma frota compatível com gerenciamento de serviços, a frota é escalada automaticamente. O número de trabalhadores na frota muda com base no número de tarefas disponíveis para a frota executar.

Quando um trabalho é atribuído a uma frota gerenciada pelo cliente, os trabalhadores podem já existir ou podem ser criados usando o escalonamento automático baseado em eventos. Para obter mais informações, consulte [Use EventBridge para lidar com eventos de auto scaling no Guia](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) do usuário do *Amazon EC2 Auto* Scaling.

## Sessões
<a name="jobs-scheduling-sessions"></a>

As tarefas em um trabalho são divididas em uma ou mais sessões. Os trabalhadores executam as sessões para configurar o ambiente, executar as tarefas e, em seguida, destruir o ambiente. Cada sessão é composta por uma ou mais ações que um trabalhador deve realizar.

Quando um trabalhador conclui as ações da seção, ações adicionais da sessão podem ser enviadas ao trabalhador. O funcionário reutiliza os ambientes e os anexos de trabalho existentes na sessão para concluir as tarefas com mais eficiência.

Em trabalhadores de frotas gerenciados por serviços, os diretórios de sessão são excluídos após o término da sessão, mas outros diretórios são mantidos entre as sessões. Esse comportamento permite que você implemente estratégias de armazenamento em cache para dados que podem ser reutilizados em várias sessões. Para armazenar dados em cache entre as sessões, armazene-os no diretório inicial do usuário que está executando o trabalho. Por exemplo, os pacotes conda são armazenados em cache no diretório inicial do usuário do trabalho em `C:\Users\job-user\.conda-pkgs` on Windows workers e `/home/job-user/.conda-pkgs` on Linux workers. Esses dados permanecem disponíveis até que o trabalhador seja desligado.

Os anexos de trabalho são criados pelo remetente e você usa como parte do pacote de trabalhos da CLI do Deadline Cloud. Você também pode criar anexos de trabalho usando a `--attachments` opção do comando. `create-job` AWS CLI Os ambientes são definidos em dois lugares: ambientes de fila anexados a uma fila específica e ambientes de tarefas e etapas definidos no modelo de trabalho.

Há quatro tipos de ação de sessão:
+ `syncInputJobAttachments`— Faz o download dos anexos do trabalho de entrada para o trabalhador.
+ `envEnter`— Executa as `onEnter` ações para um ambiente.
+ `taskRun`— Executa as `onRun` ações de uma tarefa.
+ `envExit`— Executa as `onExit` ações para um ambiente.

O modelo de trabalho a seguir tem um ambiente de etapas. Ele tem uma `onEnter` definição para configurar o ambiente de etapas, uma `onRun` definição que define a tarefa a ser executada e uma `onExit` definição para derrubar o ambiente de etapas. As sessões criadas para esse trabalho incluirão uma `envEnter` ação, uma ou mais `taskRun` ações e, em seguida, uma `envExit` ação.

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

### Pipelining de ações de sessão
<a name="jobs-session-pipelining"></a>

O pipeline de ações de sessão permite que um agendador pré-atribua várias ações de sessão a um trabalhador. O trabalhador pode então executar essas ações sequencialmente, reduzindo ou eliminando o tempo ocioso entre as tarefas.

Para criar uma atribuição inicial, o agendador cria uma sessão com uma tarefa, o trabalhador conclui a tarefa e, em seguida, o agendador analisa a duração da tarefa para determinar as atribuições futuras.

Para que o agendador seja eficaz, existem regras de duração da tarefa. Para tarefas com menos de um minuto, o agendador usa um padrão de crescimento de potência de 2. Por exemplo, para uma tarefa de 1 segundo, o agendador atribui 2 novas tarefas, depois 4 e depois 8. Para tarefas com mais de um minuto, o agendador atribui apenas uma nova tarefa e o pipeline permanece desativado.

Para calcular o tamanho do pipeline, o programador faz o seguinte:
+ Usa a duração média das tarefas concluídas
+ Visa manter o trabalhador ocupado por um minuto
+ Considera somente tarefas dentro da mesma sessão
+ Não compartilha dados de duração entre os trabalhadores

Com o pipeline de ações da sessão, os trabalhadores iniciam novas tarefas imediatamente e não há tempo de espera entre as solicitações do agendador. Ele também fornece maior eficiência do trabalhador e melhor distribuição de tarefas para processos de longa execução.

Além disso, se houver um novo trabalho de maior prioridade disponível, o trabalhador concluirá todo o trabalho anteriormente atribuído antes que a sessão atual termine e uma nova sessão de um trabalho de maior prioridade seja atribuída.

## Dependências de etapas
<a name="jobs-scheduling-dependencies"></a>

O Deadline Cloud suporta a definição de dependências entre as etapas para que uma etapa espere até que outra seja concluída antes de começar. Você pode definir mais de uma dependência para uma etapa. Uma etapa com uma dependência não é agendada até que todas as dependências estejam concluídas.

Se o modelo de trabalho definir uma dependência circular, o trabalho será rejeitado e o status do trabalho será definido como. `CREATE_FAILED`

O modelo de trabalho a seguir cria um trabalho com duas etapas. `StepB`depende de`StepA`. `StepB`só é executado após `StepA` ser concluído com sucesso. 

Depois que o trabalho é criado, `StepA` está no `READY` estado e `StepB` está no `PENDING` estado. Depois de `StepA` terminar, `StepB` se muda para o `READY` estado. Se `StepA` falhar ou `StepA` for cancelado, `StepB` passa para o `CANCELED` estado.

Você pode definir uma dependência em várias etapas. Por exemplo, `StepC` depende de ambos `StepA` e`StepB`, `StepC` não começará até que as outras duas etapas terminem.

As dependências de etapas têm as seguintes restrições:
+ **Dependências por etapa** — Uma etapa pode depender de no máximo 128 outras etapas.
+ **Consumidores por etapa** — No máximo 32 outras etapas podem depender de uma única etapa.

```
name: Step-Step Dependency Test
specificationVersion: 'jobtemplate-2023-09'
steps:
- name: A
  script:
    actions:
      onRun:
        command: bash
        args: ['{{ Task.File.run }}']
    embeddedFiles:
      - name: run
        type: TEXT
        data: |
          #!/bin/env bash

          set -euo pipefail

          sleep 1
          echo Task A Done!
- name: B
  dependencies:
  - dependsOn: A # This means Step B depends on Step A
  script:
    actions:
      onRun:
        command: bash
        args: ['{{ Task.File.run }}']
    embeddedFiles:
      - name: run
        type: TEXT
        data: |
          #!/bin/env bash

          set -euo pipefail

          sleep 1
          echo Task B Done!
```

# Modificar um trabalho no Deadline Cloud
<a name="build-jobs-modifying"></a>

Você pode usar os seguintes `update` comandos AWS Command Line Interface (AWS CLI) para modificar a configuração de um trabalho ou definir o status de destino de um trabalho, etapa ou tarefa: ``
+ `aws deadline update-job`
+ `aws deadline update-step`
+ `aws deadline update-task`

Nos exemplos de `update` comandos a seguir, substitua cada um *`user input placeholder`* por suas próprias informações.

**Example — Solicitar um trabalho**  
Todas as tarefas na tarefa mudam para o `READY` status, a menos que haja dependências de etapas. As etapas com dependências mudam para uma `READY` ou à `PENDING` medida que são restauradas.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status PENDING
```

**Example — Cancelar um trabalho**  
Todas as tarefas no trabalho que não têm o status `SUCCEEDED` ou `FAILED` estão marcadas`CANCELED`.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status CANCELED
```

**Example — Marcar que um trabalho falhou**  
Todas as tarefas no trabalho que têm o status permanecem `SUCCEEDED` inalteradas. Todas as outras tarefas estão marcadas`FAILED`.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status FAILED
```

**Example — Marque um trabalho bem-sucedido**  
Todas as tarefas do trabalho são transferidas para o `SUCCEEDED` estado.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status SUCCEEDED
```

**Example — Suspender um emprego**  
As tarefas no trabalho no `FAILED` estado `SUCCEEDED``CANCELED`, ou não mudam. Todas as outras tarefas estão marcadas`SUSPENDED`.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--target-task-run-status SUSPENDED
```

**Example — Mudar a prioridade de um trabalho**  
Atualiza a prioridade de um trabalho em uma fila para alterar a ordem em que ele está agendado. Os trabalhos de maior prioridade geralmente são agendados primeiro.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--priority 100
```

**Example — Alterar o número de tarefas com falha permitidas**  
Atualiza o número máximo de tarefas com falha que o trabalho pode ter antes que as tarefas restantes sejam canceladas.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--max-failed-tasks-count 200
```

**Example — Alterar o número de novas tentativas de tarefas permitidas**  
Atualiza o número máximo de tentativas de uma tarefa antes que a tarefa falhe. Uma tarefa que tenha atingido o número máximo de novas tentativas não pode ser colocada novamente na fila até que esse valor seja aumentado.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--max-retries-per-task 10
```

**Example — Arquivar um trabalho**  
Atualiza o status do ciclo de vida do trabalho para. `ARCHIVED` Os trabalhos arquivados não podem ser agendados nem modificados. Você só pode arquivar um trabalho que esteja no `SUSPENDED` estado `FAILED``CANCELED`,`SUCCEEDED`,, ou.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--lifecycle-status ARCHIVED
```

**Example — Alterar o nome de um emprego**  
Atualiza o nome de exibição de um trabalho. O nome do trabalho pode ter até 128 caracteres.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--name "New Job Name"
```

**Example — Alterar a descrição de um trabalho**  
Atualiza a descrição de um trabalho. A descrição pode ter até 2048 caracteres. Para remover a descrição existente, passe uma string vazia.  

```
aws deadline update-job \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--description "New Job Description"
```

**Example — Recoloque uma etapa na fila**  
Todas as tarefas na etapa mudam para o `READY` estado, a menos que haja dependências de etapas. As tarefas em etapas com dependências mudam para `READY` ou`PENDING`, e a tarefa é restaurada.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status PENDING
```

**Example — Cancelar uma etapa**  
Todas as tarefas na etapa que não têm o status `SUCCEEDED` ou `FAILED` estão marcadas`CANCELED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status CANCELED
```

**Example — Marcar uma etapa que falhou**  
Todas as tarefas na etapa que têm o status permanecem `SUCCEEDED` inalteradas. Todas as outras tarefas estão marcadas`FAILED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status FAILED
```

**Example — Marque uma etapa bem-sucedida**  
Todas as tarefas na etapa estão marcadas`SUCCEEDED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status SUCCEEDED
```

**Example — Suspender uma etapa**  
As tarefas na etapa do `FAILED` estado `SUCCEEDED``CANCELED`,, ou não mudam. Todas as outras tarefas estão marcadas`SUSPENDED`.  

```
aws deadline update-step \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--target-task-run-status SUSPENDED
```

**Example — Alterar o status de uma tarefa**  
Quando você usa o comando da CLI do `update-task` Deadline Cloud, a tarefa muda para o status especificado.  

```
aws deadline update-task \
--farm-id farmID \
--queue-id queueID \
--job-id jobID \
--step-id stepID \
--task-id taskID \
--target-task-run-status SUCCEEDED | SUSPENDED | CANCELED | FAILED | PENDING
```