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á. # Agende trabalhos no Deadline Cloud 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 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 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 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 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 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! ```