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á.
# Tarefas
Empregos são a unidade de trabalho iniciada por AWS Batch. Os trabalhos podem ser invocados como aplicações em contêineres executáveis em instâncias de contêiner do Amazon ECS em um cluster do ECS.
Os trabalhos em contêineres podem fazer referência a uma imagem de contêiner, comando e parâmetros de contêiner. Para obter mais informações, consulte [JobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_JobDefinition.html).
Você pode enviar um grande número de trabalhos simples e independentes.
**Topics**
+ [Tutorial: enviar um trabalho](submit_job.md)
+ [Empregos de serviços em AWS Batch](service-jobs.md)
+ [Estados do trabalho](job_states.md)
+ [AWS Batch variáveis do ambiente de trabalho](job_env_vars.md)
+ [Repetições de trabalho automatizadas](job_retries.md)
+ [Dependências do trabalho](job_dependencies.md)
+ [Tempos limite de trabalho](job_timeouts.md)
+ [Trabalhos do Amazon EKS](eks-jobs.md)
+ [Trabalhos em paralelo de vários nós](multi-node-parallel-jobs.md)
+ [Trabalhos paralelos de vários nós no Amazon EKS](mnp-eks-jobs.md)
+ [Trabalhos de matriz](array_jobs.md)
+ [Executar trabalhos de GPU](gpu-jobs.md)
+ [Exibir AWS Batch trabalhos em uma fila de trabalhos](view-jobs.md)
+ [AWS Batch Procure empregos em uma fila de empregos](searching-filtering-jobs.md)
+ [Modos de rede para AWS Batch trabalhos](networking-modes-jobs.md)
+ [Exibir registros de AWS Batch trabalhos em CloudWatch Registros](review-job-logs.md)
+ [Revise as informações do AWS Batch trabalho](review-job-info.md)
# Tutorial: enviar um trabalho
Depois de registrar uma definição de trabalho, você pode enviá-la como um trabalho para uma fila de AWS Batch trabalhos. Você pode substituir muitos dos parâmetros especificados no campo de definição de trabalho em runtime.
**Para enviar um trabalho**
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Na barra de navegação, selecione o Região da AWS a ser usado.
1. No painel de navegação, escolha **Tarefas**.
1. Escolha **Enviar Novo Trabalho**.
1. Em **Nome**, insira um nome exclusivo para a sua definição de trabalho. Os nomes podem ter até 128 caracteres. Pode conter letras minúsculas, maiúsculas, números, hifens e (-) e sublinhados (\$1).
1. Para **Definição de Trabalho**, escolha uma definição de trabalho existente para o seu trabalho. Para obter mais informações, consulte [Criar uma definição de tarefa de nó único](create-job-definition.md).
1. Para **Fila de Trabalhos**, escolha uma fila de trabalhos existente. Para obter mais informações, consulte [Crie uma fila de trabalhos](create-job-queue.md).
1. Em **Dependências do Trabalho**, escolha **Adicionar Dependência do Trabalho**.
1. Em **ID do Trabalho**, insira a ID do trabalho para todas as dependências. Em seguida, escolha **Adicionar Dependências do Trabalho**. Um trabalho pode ter até 20 dependências. Para obter mais informações, consulte [Dependências do trabalho](job_dependencies.md).
1. (Somente para trabalhos de matriz) Em **Tamanho da Matriz**, especifique um tamanho entre 2 e 10.000.
1. (Opcional) Expanda **Tags** e então, escolha **Adicionar Tag** para adicionar tags ao recurso. Insira uma chave e um valor opcional e então escolha **Adicionar Tag**.
1. Escolha **Próxima página**.
1. Na seção **Substituições de Trabalho**:
1.
(Opcional) Em **Prioridade de agendamento**, insira um valor de prioridade de agendamento entre 0 e 100. Valores mais altos têm maior prioridade.
1. (Opcional) Para **Tentativas de Trabalho**, insira o número máximo de vezes que AWS Batch tenta mover o trabalho para um status `RUNNABLE`. Você pode inserir um número inteiro entre 1 e 10. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
1. (Opcional) Em **Tempo Limite de Execução**, insira o valor do tempo limite (em segundos). O tempo limite de execução é o período de tempo antes que um trabalho não concluído seja encerrado. Se uma tentativa exceder o tempo limite de duração, ela será parada e o status será alterado para `FAILED`. Para obter mais informações, consulte [Tempos limite de trabalho](job_timeouts.md). O valor mínimo é 60 segundos.
**Importante**
Não confie em trabalhos executados com recursos do Fargate por mais de 14 dias. Depois de 14 dias, os recursos do Fargate podem não estar mais disponíveis e é provável que o trabalho ser encerrado.
1. (Opcional) Ative **Propagar Tags** para propagar tags do trabalho e da definição de trabalho para a tarefa do Amazon ECS.
1. Expanda **Configuração Adicional**.
1. (Opcional) Em **Repetir condições da estratégia**, escolha **Adicionar avaliação na saída**. Insira pelo menos um valor de parâmetro e escolha uma **Ação**. Para cada conjunto de condições, **Ação** deve ser definida como **Tentar Novamente** ou **Sair**. Essas ações significam o seguinte:
+ **Tentar novamente** — AWS Batch tenta novamente até que o número de tentativas de trabalho que você especificou seja atingido.
+ **Sair** — AWS Batch para de tentar novamente o trabalho.
**Importante**
Se você escolher **Adicionar Avaliação na Saída**, configure pelo menos um parâmetro e uma **Ação**, ou escolha **Remover Avaliação na Saída**.
1. Em **Parâmetros**, escolha **Adicionar Parâmetros** para adicionar espaços reservados de substituição de parâmetros. Em seguida, insira uma **Chave** e um **Valor** opcional.
1. Na seção **Substituição de Contêineres**:
1. Em **Comando**, insira os comandos no campo como o equivalente da matriz de string **JSON**.
Esse parâmetro é mapeado para `Cmd` na seção [Criar um contêiner](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) da [Docker Remote API](https://docs.docker.com/engine/api/v1.38/) e o parâmetro `COMMAND` de [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Para obter mais informações sobre o `CMD` parâmetro Docker, consulte [https://docs.docker.com/engine/reference/builder/](https://docs.docker.com/engine/reference/builder/#cmd) \$1cmd.
**nota**
O parâmetro não pode conter uma string vazia.
1. Para **v CPUs**, insira o número de v CPUs a ser reservado para o contêiner. Esse parâmetro é mapeado para `CpuShares` na seção [Criar um Contêiner](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) da [API remota do Docker](https://docs.docker.com/engine/api/v1.38/) e a opção `--cpu-shares` para [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Cada vCPU equivale a 1.024 compartilhamentos de CPU. Você deve especificar pelo menos uma vCPU.
1. Em **Memória**, insira o limite de memória que está disponível para o contêiner. Caso seu contêiner tente exceder a memória especificada, o mesmo será interrompido. Esse parâmetro é mapeado para `Memory` na seção [Criar um Contêiner](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) da [API Remota Docker](https://docs.docker.com/engine/api/v1.38/) e para a opção `--memory` para [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Você deve especificar pelo menos 4 MiB de memória para uma tarefa.
**nota**
Para maximizar o uso dos recursos, priorize a memória para trabalhos de um tipo específico de instância. Para obter mais informações, consulte [Gerenciamento de memória de recursos de computação](memory-management.md).
1. (Opcional) Em **Número de GPUs**, escolha o número de GPUs a ser reservado para o contêiner.
1. (Opcional) Em **Variáveis de Ambiente**, escolha **Adicionar Variável de Ambiente** para adicionar variáveis de ambiente como pares de nome/valor. Essas variáveis serão passadas para o contêiner.
1. Escolha **Próxima página**.
1. Em **Revisão de Trabalho**, revise as etapas de configuração. Se precisar fazer alterações, escolha **Edit** (Editar). Quando terminar, escolha **Criar Definição de Trabalho**.
# Empregos de serviços em AWS Batch
AWS Batch os trabalhos de serviço permitem que você envie solicitações aos AWS serviços por meio de filas de AWS Batch trabalhos. Atualmente, AWS Batch apoia trabalhos SageMaker de treinamento como empregos de serviços. Diferentemente dos trabalhos em contêineres, nos quais AWS Batch gerencia a execução subjacente do contêiner, os trabalhos de serviço AWS Batch permitem fornecer recursos de agendamento e enfileiramento de trabalhos, enquanto o AWS serviço de destino (como a SageMaker IA) lida com a execução real do trabalho.
AWS Batch for SageMaker Training jobs permite que cientistas de dados enviem trabalhos de treinamento com prioridades para filas configuráveis, garantindo que as cargas de trabalho sejam executadas sem intervenção assim que os recursos estiverem disponíveis. Esse recurso trata de desafios comuns, como coordenação de recursos, prevenção de gastos excessivos acidentais, atendimento às restrições orçamentárias, otimização de custos com instâncias reservadas e eliminação da necessidade de coordenação manual entre os membros da equipe.
Os trabalhos de serviço diferem dos trabalhos em contêineres de várias maneiras principais:
+ **Envio de trabalhos**: os trabalhos de serviço devem ser enviados usando a [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. Os trabalhos de serviço não podem ser enviados pelo console AWS Batch .
+ **Execução do trabalho**: AWS Batch agenda e enfileira os trabalhos de serviço, mas o AWS serviço de destino executa a carga de trabalho real.
+ **Identificadores de recursos**: uso de trabalhos de serviço ARNs que contêm “trabalho de serviço” em vez de “trabalho” para diferenciá-los dos trabalhos em contêineres.
Para começar com trabalhos AWS Batch de serviço para SageMaker treinamento, consulte[Começando a usar AWS Batch a SageMaker IA](getting-started-sagemaker.md).
**Topics**
+ [Cargas úteis de trabalho de serviço em AWS Batch](service-job-payload.md)
+ [Envie um trabalho de serviço em AWS Batch](service-job-submit.md)
+ [Mapeando AWS Batch o status do trabalho do serviço para o status de SageMaker IA](service-job-status.md)
+ [Estratégias de nova tentativa de emprego no serviço em AWS Batch](service-job-retries.md)
+ [Monitore trabalhos de serviço em uma AWS Batch fila](monitor-sagemaker-job-queue.md)
+ [Encerrar trabalhos de serviço](terminate-service-jobs.md)
# Cargas úteis de trabalho de serviço em AWS Batch
Ao enviar trabalhos de serviço usando [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), você fornece dois parâmetros principais que definem o trabalho: `serviceJobType` `serviceRequestPayload` e.
+ O `serviceJobType` especifica qual AWS serviço executará o trabalho. Para trabalhos SageMaker de treinamento, esse valor é`SAGEMAKER_TRAINING`.
+ `serviceRequestPayload` é uma string codificada em JSON que contém a solicitação completa que normalmente seria enviada diretamente para o serviço de destino. Para trabalhos de SageMaker treinamento, essa carga contém os mesmos parâmetros que você usaria com a [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)API de SageMaker IA.
Para ver uma lista completa de todos os parâmetros disponíveis e suas descrições, consulte a referência da [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)API SageMaker AI. Todos os parâmetros suportados pelo `CreateTrainingJob` podem ser incluídos na carga útil do seu trabalho de serviço.
Para ver exemplos de mais configurações de tarefas de treinamento [APIs, consulte CLI SDKs](https://docs.aws.amazon.com/sagemaker/latest/dg/api-and-sdk-reference-overview.html) e o Guia [SageMaker do Desenvolvedor de IA](https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html).
Recomendamos usar o PySDK para a criação de trabalhos de serviço porque o PySDK tem classes auxiliares e utilitários. Para ver um exemplo de uso do PySDK, consulte exemplos de [SageMaker IA](https://github.com/aws/amazon-sagemaker-examples) em. GitHub
## Exemplo de carga útil de trabalho de serviço
O exemplo a seguir mostra uma carga útil de um trabalho de serviço simples para um trabalho de SageMaker treinamento que executa um script de treinamento “hello world”:
Essa carga útil seria passada como uma string JSON para o parâmetro `serviceRequestPayload` ao chamar o `SubmitServiceJob`.
```
{
"TrainingJobName": "my-simple-training-job",
"RoleArn": "arn:aws:iam::123456789012:role/SageMakerExecutionRole",
"AlgorithmSpecification": {
"TrainingInputMode": "File",
"TrainingImage": "763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-cpu-py310",
"ContainerEntrypoint": [
"echo",
"hello world"
]
},
"ResourceConfig": {
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"VolumeSizeInGB": 1
},
"OutputDataConfig": {
"S3OutputPath": "s3://your-output-bucket/output"
},
"StoppingCondition": {
"MaxRuntimeInSeconds": 30
}
}
```
# Envie um trabalho de serviço em AWS Batch
Para enviar trabalhos de serviço para AWS Batch, você usa a [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. Você pode enviar trabalhos usando o SDK AWS CLI ou.
Se ainda não tiver um perfil de execução, você deverá criar um antes de enviar seu trabalho de serviço. Para criar a função de execução de SageMaker IA, consulte [Como usar funções de execução de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html) no *[guia do desenvolvedor de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)*.
## Fluxo de trabalho de envio de trabalhos de serviço
Quando você envia um trabalho de serviço, AWS Batch segue este fluxo de trabalho:
1. AWS Batch recebe sua `[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)` solicitação e valida os parâmetros AWS Batch específicos. O `serviceRequestPayload` passa sem validação.
1. O trabalho entra no estado `SUBMITTED` e é colocado na fila de trabalhos especificada
1. AWS Batch avalia se há capacidade disponível no ambiente de serviço para `RUNNABLE` trabalhos na frente da fila
1. Se a capacidade estiver disponível, o trabalho será transferido para a IA `SCHEDULED` e o trabalho será passado para a SageMaker IA
1. Quando a capacidade for adquirida e a SageMaker IA fizer o download dos dados do trabalho de serviço, o trabalho de serviço iniciará a inicialização e o trabalho será alterado para`STARTING`.
1. Quando a SageMaker IA começa a executar o trabalho, seu status é alterado para`RUNNING`.
1. Enquanto a SageMaker IA executa o trabalho, AWS Batch monitora seu progresso e mapeia os estados do serviço para os estados do AWS Batch trabalho. Para detalhes sobre como os estados dos trabalhos de serviço são mapeados, consulte [Mapeando AWS Batch o status do trabalho do serviço para o status de SageMaker IA](service-job-status.md)
1. Quando o trabalho de serviço é concluído, ele passa para `SUCCEEDED` e qualquer saída está pronta para o download.
## Pré-requisitos
Antes de enviar um trabalho de serviço, verifique se você tem:
+ **Ambiente de serviço**: um ambiente de serviço que define limites de capacidade. Para obter mais informações, consulte [Crie um ambiente de serviço em AWS Batch](create-service-environments.md).
+ **SageMaker fila de trabalhos — Uma fila** de SageMaker trabalhos para fornecer agendamento de trabalhos. Para obter mais informações, consulte [Criar uma fila de trabalhos do SageMaker Training no AWS Batch](create-sagemaker-job-queue.md).
+ **Permissões do IAM**: permissões para criar e gerenciar filas de trabalhos AWS Batch e ambientes de serviço. Para obter mais informações, consulte [AWS Batch Políticas, funções e permissões do IAM](IAM_policies.md).
## Envie um trabalho de serviço com a AWS CLI
Veja a seguir como enviar um trabalho de serviço usando a AWS CLI:
```
aws batch submit-service-job \
--job-name "my-sagemaker-training-job" \
--job-queue "my-sagemaker-job-queue" \
--service-job-type "SAGEMAKER_TRAINING" \
--service-request-payload '{\"TrainingJobName\": \"sagemaker-training-job-example\", \"AlgorithmSpecification\": {\"TrainingImage\": \"123456789012.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:1.8.0-cpu-py3\", \"TrainingInputMode\": \"File\", \"ContainerEntrypoint\": [\"sleep\", \"1\"]}, \"RoleArn\":\"arn:aws:iam::123456789012:role/SageMakerExecutionRole\", \"OutputDataConfig\": {\"S3OutputPath\": \"s3://example-bucket/model-output/\"}, \"ResourceConfig\": {\"InstanceType\": \"ml.m5.large\", \"InstanceCount\": 1, \"VolumeSizeInGB\": 1}}'
--client-token "unique-token-12345"
```
Para obter mais informações sobre o parâmetro `serviceRequestPayload`, consulte [Cargas úteis de trabalho de serviço em AWS Batch](service-job-payload.md).
# Mapeando AWS Batch o status do trabalho do serviço para o status de SageMaker IA
Quando você envia trabalhos para uma SageMaker fila de trabalhos usando [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), AWS Batch gerencia o ciclo de vida do trabalho e mapeia os estados do trabalho para [estados de AWS Batch trabalho](job_states.md) de SageMaker treinamento equivalentes. Os trabalhos de serviço, como trabalhos de SageMaker treinamento, seguem um ciclo de vida de estado diferente dos trabalhos tradicionais em contêineres. Embora os trabalhos de serviço compartilhem a maioria dos estados com os trabalhos em contêineres, eles introduzem o estado `SCHEDULED` e apresentam diferentes comportamentos de repetição, principalmente para lidar com erros de capacidade insuficientes do serviço de destino.
A tabela a seguir mostra o estado do AWS Batch trabalho e o SageMaker Status/ SecondaryStatus correspondente:
| Status do lote | SageMaker Status primário da IA | SageMaker Status secundário de IA | Description |
| --- | --- | --- | --- |
| SUBMITTED | N/D | N/D | Trabalho enviado para a fila, aguardando a avaliação do agendador. |
| RUNNABLE | N/D | N/D | Trabalho na fila e pronto para agendamento. Os trabalhos nesse estado são iniciados assim que há recursos suficientes no ambiente de serviço. Os trabalhos podem permanecer nesse estado indefinidamente quando não há recursos suficientes. |
| SCHEDULED | InProgress | Pending | Trabalho de serviço enviado com sucesso à SageMaker AI |
| STARTING | InProgress | Downloading | SageMaker Trabalho de treinamento baixando dados e imagens. A capacidade da tarefa de treinamento foi adquirida e a inicialização do trabalho começa. |
| RUNNING | InProgress | Training | SageMaker Algoritmo de execução de tarefas de treinamento |
| RUNNING | InProgress | Uploading | SageMaker Trabalho de treinamento: upload de artefatos de saída após a conclusão do treinamento |
| SUCCEEDED | Completed | Completed | SageMaker Trabalho de treinamento concluído com sucesso. O envio dos artefatos de saída foi concluído. |
| FAILED | Failed | Failed | SageMaker O trabalho de treinamento encontrou um erro irrecuperável. |
| FAILED | Stopped | Stopped | SageMaker O trabalho de treinamento foi interrompido manualmenteStopTrainingJob. |
# Estratégias de nova tentativa de emprego no serviço em AWS Batch
As estratégias de repetição de tarefas de serviço AWS Batch permitem repetir automaticamente tarefas de serviço com falha sob condições específicas.
Os trabalhos de serviço podem exigir várias tentativas por vários motivos:
+ **Problemas temporários de serviço**: erros internos de serviço, controle de utilização ou interrupções temporárias podem fazer com que os trabalhos falhem durante o envio ou a execução.
+ **Falhas na inicialização do treinamento**: problemas durante a inicialização do trabalho, como problemas de extração de imagens ou erros de inicialização, podem ser resolvidos na nova tentativa.
Ao configurar estratégias de nova tentativa apropriadas, você pode melhorar as taxas de sucesso no trabalho e reduzir a necessidade de intervenção manual, especialmente para workloads de treinamento de longa duração.
**nota**
Os trabalhos de serviço repetem automaticamente certos tipos de falhas, como erros de capacidade insuficiente, sem consumir suas tentativas de repetição configuradas. Sua estratégia de repetição lida principalmente com outros tipos de falhas, como erros de algoritmo ou problemas de serviço.
## Configurar estratégias de repetição
As estratégias de repetição de tarefas de serviço são configuradas usando [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html), que suporta contagens simples de repetições e lógica de repetição condicional.
### Configuração de repetição
A estratégia de repetição mais simples especifica o número de tentativas que devem ser feitas se um trabalho de serviço falhar:
```
{
"retryStrategy": {
"attempts": 3
}
}
```
Essa configuração permite que o trabalho de serviço seja repetido até 3 vezes em caso de falha.
**Importante**
O valor `attempts` representa o número total de vezes que o trabalho pode ser colocado no estado `RUNNABLE`, incluindo a tentativa inicial. Um valor de 3 significa que haverá uma tentativa inicial do trabalho e, em seguida, ele será repetido até 2 vezes adicionais se falhar.
### Repita a configuração com evaluateOnExit
Você pode usar o parâmetro `evaluateOnExit` para especificar as condições sob as quais os trabalhos devem ser repetidos ou podem falhar. Isso é útil quando diferentes tipos de falhas exigem tratamento diferente.
A matriz `evaluateOnExit` pode conter até 5 estratégias de repetição, cada uma especificando uma ação (`RETRY` ou `EXIT`) e condições com base nos motivos do status:
```
{
"retryStrategy": {
"attempts": 5,
"evaluateOnExit": [
{
"action": "RETRY",
"onStatusReason": "Received status from SageMaker: InternalServerError*"
},
{
"action": "EXIT",
"onStatusReason": "Received status from SageMaker: ValidationException*"
},
{
"action": "EXIT",
"onStatusReason": "*"
}
]
}
}
```
Esta configuração:
+ Tenta novamente trabalhos que falham devido a erros internos do servidor de SageMaker IA
+ Falha imediatamente trabalhos que encontram exceções de validação (erros do cliente que não serão resolvidos por meio de uma nova tentativa)
+ Inclui uma regra abrangente para sair de qualquer outro tipo de falha
#### Correspondência de padrão do motivo de status
O parâmetro `onStatusReason` oferece suporte à correspondência de padrões com até 512 caracteres. Os padrões podem usar curingas (\$1) e corresponder aos motivos de status retornados pela SageMaker IA.
Para trabalhos de serviço, as mensagens de status da SageMaker IA são prefixadas com “Status recebido de SageMaker:” para diferenciá-las das mensagens AWS Batch geradas. Os padrões comuns incluem:
+ `Received status from SageMaker: InternalServerError*` - Correspondência com erros internos de serviço
+ `Received status from SageMaker: ValidationException*` - Correspondência com erros de validação do cliente
+ `Received status from SageMaker: ResourceLimitExceeded*` - Correspondência com erros de limite de recursos
+ `*CapacityError*` - Correspondência com falhas relacionadas à capacidade
**dica**
Use a correspondência de padrões específicos para lidar com diferentes tipos de erro de forma adequada. Por exemplo, repetir os erros internos do servidor, mas falhar imediatamente os erros de validação que indicam problemas com os parâmetros do trabalho.
# Monitore trabalhos de serviço em uma AWS Batch fila
Você pode monitorar o status dos trabalhos em sua fila de trabalhos de SageMaker treinamento usando `list-service-jobs` e. `get-job-queue-snapshot`
Veja os trabalhos em execução na sua fila:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNING
```
Veja os trabalhos em espera na fila:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNABLE
```
Exibir trabalhos que foram enviados, SageMaker mas ainda não estão em execução:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status SCHEDULED
```
Obtenha um instantâneo dos trabalhos na frente da sua fila:
```
aws batch get-job-queue-snapshot --job-queue my-sm-training-fifo-jq
```
Esse comando mostra a ordem dos próximos trabalhos de serviço em sua fila.
## Obter informações detalhadas sobre o trabalho de serviço
Use a operação [https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html) para obter informações abrangentes sobre um trabalho de serviço específico, incluindo seu status atual, identificadores de recursos de serviço e informações detalhadas sobre tentativas.
Visualizar informações detalhadas sobre um trabalho específico:
```
aws batch describe-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d
```
Esse comando retorna informações abrangentes sobre o trabalho, incluindo:
+ ARN do trabalho e status atual
+ Identificadores de recursos de serviço (como ARN do trabalho SageMaker de treinamento)
+ Prioridade de agendamento e configuração de novas tentativas
+ Carga útil da solicitação de serviço contendo os parâmetros originais do serviço
+ Informações detalhadas da tentativa com horários de início e término
+ Mensagens de status do serviço de destino
## Monitore trabalhos SageMaker de treinamento
Ao monitorar os trabalhos de SageMaker treinamento AWS Batch, você pode acessar as informações do AWS Batch trabalho e os detalhes subjacentes do trabalho de SageMaker treinamento.
O identificador do recurso de serviço nos detalhes do trabalho contém o ARN do trabalho de SageMaker treinamento:
```
{
"latestAttempt": {
"serviceResourceId": {
"name": "TrainingJobArn",
"value": "arn:aws:sagemaker:us-east-1:123456789012:training-job/my-training-job"
}
}
}
```
Você pode usar esse ARN para obter detalhes adicionais diretamente de: SageMaker
```
aws sagemaker describe-training-job \
--training-job-name my-training-job
```
Monitore o progresso do trabalho verificando AWS Batch o status e o status do trabalho de SageMaker treinamento. O status do AWS Batch trabalho mostra o ciclo de vida geral do trabalho, enquanto o status do trabalho de SageMaker treinamento fornece detalhes específicos do serviço sobre o processo de treinamento.
# Encerrar trabalhos de serviço
Use a operação [https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html) para interromper um trabalho de serviço em execução.
Encerre um trabalho de serviço específico:
```
aws batch terminate-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d \
--reason "Job terminated by user request"
```
Quando você encerra um trabalho de serviço, AWS Batch interrompe o trabalho e notifica o serviço de destino. Para trabalhos SageMaker de treinamento, isso também interromperá o trabalho de treinamento em SageMaker IA.
# Estados do trabalho
Quando você envia um trabalho para uma fila de AWS Batch trabalhos, o trabalho entra no `SUBMITTED` estado. Em seguida, ele passa pelos seguintes estados, até ter êxito (sai com código `0`) ou falhar (saindo com um código diferente de zero). Os trabalhos do AWS Batch podem ter os seguintes estados:
`SUBMITTED`
Um trabalho que foi enviado para a fila e ainda não foi avaliado pelo programador. O programador avalia o trabalho para determinar se ele tem dependências pendentes na conclusão bem-sucedida de todos os outros trabalhos. Se houver dependências, o trabalho será movido para `PENDING`. Se não houver dependências, o trabalho será movido para `RUNNABLE`.
`PENDING`
Um trabalho que reside na fila e ainda não pode ser executado devido a dependência de outro trabalho ou recurso. Após as dependências serem atendidas, o trabalho é movido para `RUNNABLE`.
Os pais dos trabalhos de matriz são atualizados para `PENDING` quando qualquer trabalho secundário é atualizado `RUNNABLE` e permanecem no `PENDING` status enquanto os trabalhos secundários estão em execução. Para visualizar esses trabalhos, filtre por `PENDING` status até que todos os trabalhos secundários atinjam um estado terminal.
`RUNNABLE`
Um trabalho que reside na fila, não tem dependências pendentes e, portanto, está pronto para ser programado para um host. Os trabalhos nesse estado são iniciados assim que recursos suficientes estão disponíveis em um dos ambientes de computação mapeados para a fila do trabalho. No entanto, os trabalhos podem permanecer nesse estado indefinidamente quando recursos suficientes estiverem indisponíveis.
Se os trabalhos não progredirem para `STARTING`, consulte [Trabalhos presos no status `RUNNABLE`](job_stuck_in_runnable.md) na seção de solução de problemas.
`STARTING`
Esses trabalhos foram programados para um host e as operações de inicialização de contêiner relevantes estão em andamento. Após a imagem de contêiner ser obtida e o contêiner estar em execução, o trabalho ocorre a transição do trabalho para `RUNNING`.
A duração da extração da imagem, a duração da conclusão de initContainer do Amazon EKS e a duração da resolução de containerDependency do Amazon ECS ocorrem no estado STARTING. O tempo necessário para extrair uma imagem do seu trabalho é equivalente ao tempo em que o trabalho estará no estado STARTING.
Por exemplo, se demorar três minutos para extrair a imagem do trabalho, ele ficará no estado STARTING por três minutos. Se initContainers demorar dez minutos no total para ser concluído, seu trabalho do Amazon EKS ficará em STARTING por dez minutos. Se você tiver conjuntos de containerDependencies do Amazon ECS no seu trabalho do Amazon ECS, esse trabalho ficará em STARTING até que todas as dependências do contêiner (seu runtime) sejam resolvidas. STARTING não está incluído nos tempos limite; a duração começa em RUNNING. Para obter mais informações, consulte [Estados de trabalhos](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html).
`RUNNING`
O trabalho é executado como um contêiner, em uma instância de contêiner do Amazon ECS em um ambiente de computação. Quando o contêiner do trabalho é encerrado, o código de saída do processo determina se o trabalho foi bem-sucedido ou não. Um código de saída `0` indica êxito, e qualquer código de saída diferente de zero, falha. Se o trabalho associado a uma falha na tentativa tiver tentativas restantes em sua configuração de estratégia de repetição opcional, o trabalho será movido para `RUNNABLE` novamente. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
Os registros de `RUNNING` trabalhos estão disponíveis em CloudWatch Registros. O grupo de logs é `/aws/batch/job`, e o formato do nome do fluxo de logs, o seguinte: `first200CharsOfJobDefinitionName/default/ecs_task_id`. Esse formato pode mudar no futuro.
Depois que um trabalho atinge o `RUNNING` status, você pode recuperar programaticamente o nome do fluxo de registros com a operação da [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Para obter mais informações, consulte [Exibir dados de registro enviados para CloudWatch registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) no *Guia do usuário do Amazon CloudWatch Logs*. Por padrão, esses logs nunca expiram. No entanto, é possível modificar o período de retenção. Para obter mais informações, consulte [Alterar a retenção de dados do log em CloudWatch registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) no *Guia do usuário do Amazon CloudWatch Logs*.
`SUCCEEDED`
O trabalho foi concluído com êxito com um código de saída `0`. O estado do trabalho para `SUCCEEDED` trabalhos persiste AWS Batch por pelo menos 7 dias.
Os registros de `SUCCEEDED` trabalhos estão disponíveis em CloudWatch Registros. O grupo de logs é `/aws/batch/job`, e o formato do nome do fluxo de logs, o seguinte: `first200CharsOfJobDefinitionName/default/ecs_task_id`. Esse formato pode mudar no futuro.
Depois que um trabalho atinge o `RUNNING` status, você pode recuperar programaticamente o nome do fluxo de registros com a operação da [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Para obter mais informações, consulte [Exibir dados de registro enviados para CloudWatch registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) no *Guia do usuário do Amazon CloudWatch Logs*. Por padrão, esses logs nunca expiram. No entanto, é possível modificar o período de retenção. Para obter mais informações, consulte [Alterar a retenção de dados do log em CloudWatch registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) no *Guia do usuário do Amazon CloudWatch Logs*.
`FAILED`
Ocorreu falha na tarefa em todas as tentativas. O estado da tarefa para tarefas `FAILED` persiste no AWS Batch por pelo menos 7 dias.
Os registros de `FAILED` trabalhos estão disponíveis em CloudWatch Registros. O grupo de logs é `/aws/batch/job`, e o formato do nome do fluxo de logs, o seguinte: `first200CharsOfJobDefinitionName/default/ecs_task_id`. Esse formato pode mudar no futuro.
Depois que um trabalho atinge o `RUNNING` status, você pode recuperar programaticamente seu fluxo de registros com a operação da [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Para obter mais informações, consulte [Exibir dados de registro enviados para CloudWatch registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) no *Guia do usuário do Amazon CloudWatch Logs*. Por padrão, esses logs nunca expiram. No entanto, é possível modificar o período de retenção. Para obter mais informações, consulte [Alterar a retenção de dados do log em CloudWatch registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) no *Guia do usuário do Amazon CloudWatch Logs*.
# AWS Batch variáveis do ambiente de trabalho
AWS Batch define variáveis de ambiente específicas em trabalhos de contêiner. Essas variáveis de ambiente fornecem introspecção para os contêineres dentro dos trabalhos. Você pode utilizar os valores dessas variáveis na lógica de seus aplicativos. Todas as variáveis AWS Batch definidas começam com o `AWS_BATCH_` prefixo. Esse é um prefixo de variável de ambiente protegido. Você não pode usar esse prefixo para suas próprias variáveis, em definições de trabalhos ou substituições.
As seguintes variáveis de ambiente estão disponíveis em contêineres de trabalho:
`AWS_BATCH_CE_NAME`
Essa variável é definida como o nome do ambiente de computação no qual o trabalho é colocado.
`AWS_BATCH_JOB_ARRAY_INDEX`
Essa variável só é definida em trabalhos de matriz filhos. O índice de trabalho de matriz começa com 0, e cada trabalho filho recebe um número de índice exclusivo. Por exemplo, um trabalho de matriz com 10 filhos tem valores de índice de 0 a 9. Você pode utilizar esse valor de índice para controlar como os filhos do trabalho de matriz serão diferenciados. Para obter mais informações, consulte [Usar o índice de trabalho de matriz para controle de diferenciação de trabalhos](array_index_example.md).
`AWS_BATCH_JOB_ARRAY_SIZE`
Essa variável é definida para o tamanho do trabalho da matriz pai. O tamanho do trabalho da matriz pai é passado para o trabalho de matriz filho nessa variável.
`AWS_BATCH_JOB_ATTEMPT`
Essa variável é definida como o número de tentativas de trabalho. A primeira tentativa recebe o número 1. Para obter mais informações, consulte [Repetições de trabalho automatizadas](job_retries.md).
`AWS_BATCH_JOB_ID`
Essa variável é definida como a ID do AWS Batch trabalho.
`AWS_BATCH_JOB_KUBERNETES_NODE_UID`
Essa variável é definida como o UID do Kubernetes do objeto de nó que está no cluster do Kubernetes onde o pod é executado. Essa variável é definida somente para trabalhos executados nos recursos do Amazon EKS. Para obter mais informações, consulte [UIDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids) *na documentação Kubernetes*.
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Essa variável é definida apenas em tarefas em paralelo de vários nós. Essa variável é definida como o número índice do nó principal do trabalho. O código do seu aplicativo pode comparar o `AWS_BATCH_JOB_MAIN_NODE_INDEX` ao `AWS_BATCH_JOB_NODE_INDEX` em um nó individual para determinar se ele é o nó principal.
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Essa variável é definida apenas em nós filhos de trabalhos em paralelo de vários nós. Essa variável não está presente no nó principal, mas está definida como o IPv4 endereço privado do nó principal do trabalho. O código da aplicação do nó filho pode utilizar esse endereço para comunicar-se com o nó principal.
`AWS_BATCH_JOB_NODE_INDEX`
Essa variável é definida apenas em tarefas em paralelo de vários nós. Essa variável é definida como o número do índice de nós do nó. O índice do nó começa em 0, e cada nó filho recebe um número índice exclusivo. Por exemplo, uma tarefa em paralelo de vários nós com 10 filhos possui valores índice de 0-9.
`AWS_BATCH_JOB_NUM_NODES`
Essa variável é definida apenas em tarefas em paralelo de vários nós. Essa variável é definida como o número de nós solicitado para sua tarefa paralela de vários nós.
`AWS_BATCH_JQ_NAME`
Essa variável é definida como o nome da fila de trabalhos para a qual o trabalho foi enviado.
# Repetições de trabalho automatizadas
Você pode aplicar uma estratégia de repetição aos seus trabalhos e a definições de trabalho que permitam que trabalhos com falha sofram novas tentativas automaticamente. Os possíveis cenários de falha incluem os seguintes:
+ Qualquer código de saída diferente de zero de um trabalho de contêiner
+ Falha de instância ou encerramento do Amazon EC2
+ Erro ou interrupção do AWS serviço interno
Quando um trabalho é enviado a uma fila de trabalhos e colocado no estado `RUNNING`, isso é considerado uma tentativa. Por padrão, cada trabalho tem uma tentativa de movimentação para o estado de trabalho `SUCCEEDED` ou `FAILED`. No entanto, tanto a definição de trabalho quanto o fluxo de trabalho do envio de trabalho podem ser utilizados para especificar uma estratégia de repetição entre 1 e 10 tentativas. Se [evaluateOnExit](job_definition_parameters.md#retryStrategy-evaluateOnExit)for especificado, ele pode conter até 5 estratégias de repetição. Se [evaluateOnExit](https://docs.aws.amazon.com/batch/latest/APIReference/API_EvaluateOnExit.html)for especificado, mas nenhuma das estratégias de repetição corresponder, o trabalho será repetido. Para trabalhos que não correspondam à saída, adicione uma entrada final que saia por qualquer motivo. Por exemplo, esse objeto `evaluateOnExit` tem duas entradas com ações de `RETRY` e uma entrada final com uma ação de `EXIT`.
```
"evaluateOnExit": [
{
"action": "RETRY",
"onReason": "AGENT"
},
{
"action": "RETRY",
"onStatusReason": "Task failed to start"
},
{
"action": "EXIT",
"onReason": "*"
}
]
```
No runtime, a variável de ambiente `AWS_BATCH_JOB_ATTEMPT` é definida como o número de tentativas de trabalho correspondentes do contêiner. A primeira tentativa é numerada `1`, e as tentativas subsequentes, em ordem ascendente (por exemplo, 2, 3, 4).
Por exemplo, suponha que uma tentativa de trabalho falhe por algum motivo e o número de tentativas especificado no campo de configuração de nova tentativa seja maior do que o número `AWS_BATCH_JOB_ATTEMPT`. Em seguida, o trabalho será devolvido ao estado `RUNNABLE`. Para obter mais informações, consulte [Estados do trabalho](job_states.md).
**nota**
Os trabalhos cancelados ou encerrados não são repetidos. Além disso, os trabalhos que falham devido a uma definição de trabalho inválida não são repetidos.
Para obter mais informações, consulte [Estratégia de repetição](job_definition_parameters.md#retryStrategy), [Criar uma definição de tarefa de nó único](create-job-definition.md), [Tutorial: enviar um trabalho](submit_job.md) e [Códigos de Erro de Tarefas Interrompidas](https://docs.aws.amazon.com/AmazonECS/latest/userguide/stopped-task-error-codes.html).
# Dependências do trabalho
Ao enviar um AWS Batch trabalho, você pode especificar o trabalho do IDs qual o trabalho depende. Ao fazer isso, o AWS Batch agendador garante que seu trabalho seja executado somente após a conclusão bem-sucedida das dependências especificadas. Depois de concluído com êxito, o trabalho dependente transiciona de `PENDING` para `RUNNABLE` e, em seguida, para `STARTING` e `RUNNING`. Se uma das dependências do trabalho falhar, o trabalho dependente transicionará automaticamente de `PENDING` para `FAILED`.
Por exemplo, o trabalho A pode expressar uma dependência de até 20 outros trabalhos, que devem obter êxito antes que ele possa ser executado. Você pode, então, enviar trabalhos adicionais que dependam do trabalho A e de até 19 outros trabalhos.
Para trabalhos de matriz, você pode especificar uma dependência do tipo `SEQUENTIAL` sem especificar uma ID do trabalho, de forma que cada trabalho de matriz filho seja concluído sequencialmente, a começar pelo índice 0. Você também pode especificar uma dependência do tipo `N_TO_N` com uma ID do trabalho. Deste modo, cada índice filho dessa tarefa precisa aguardar, para que o índice filho correspondente de cada dependência seja concluído antes de começar. Para obter mais informações, consulte [Trabalhos de matriz](array_jobs.md).
Para enviar um AWS Batch trabalho com dependências, consulte[Tutorial: enviar um trabalho](submit_job.md).
O [Agendamento com reconhecimento de recurso](resource-aware-scheduling.md) permite que você agende trabalhos com base nos recursos consumíveis necessários para executar seus trabalhos. Você especifica os recursos consumíveis necessários para a execução de um trabalho e o Batch leva essas dependências de recursos em consideração ao agendar um trabalho. Você pode reduzir a subutilização dos recursos computacionais alocando somente os trabalhos que têm todos os recursos necessários disponíveis. O agendamento com reconhecimento de recursos está disponível para políticas de agendamento FIFO e de compartilhamento justo e pode ser usado com todas as plataformas de computação compatíveis com o Batch, incluindo EKS, ECS e Fargate. Ele pode ser usado com trabalhos de matriz, trabalhos de paralelos de vários nós (MNP) e trabalhos de Batch regulares.
# Tempos limite de trabalho
Você pode configurar uma duração de tempo limite para os seus trabalhos para que, caso uma execução de trabalho seja maior, AWS Batch possa encerrar o trabalho. Por exemplo, caso você tenha um trabalho que sabe que deve demorar apenas 15 minutos para ser concluído. Às vezes, o aplicativo fica preso em um loop e executa para sempre. Nesse caso, você pode definir um tempo limite de 30 minutos para encerrar a tarefa presa.
**Importante**
Por padrão, AWS Batch não tem um tempo limite de trabalho. Se você não definir um tempo limite do trabalho, o mesmo será executado até a saída do contêiner.
Especifique um parâmetro `attemptDurationSeconds`, que deve ser pelo menos 60 segundos, seja na definição de trabalho ou no envio do trabalho. Quando esse número de segundos tiver passado após o registro de `startedAt` data e hora da tentativa de trabalho, o trabalho AWS Batch será encerrado. No recurso de computação, o contêiner de tarefa recebe um sinal `SIGTERM` para que seu aplicativo possa encerrar normalmente. Se o contêiner ainda estiver em execução após 30 segundos, um sinal `SIGKILL` será enviado para encerrar o contêiner.
Os encerramentos por tempo limite são processados com base no melhor esforço. Você não deve esperar pelo encerramento por tempo limite no momento exato em que a tentativa de trabalho expirar (pode demorar alguns segundos adicionais). Se o aplicativo obrigar a execução do tempo limite exato, você deve implementar essa lógica no aplicativo. Caso tenha uma grande quantidade de tarefas atingindo o tempo limite concomitantemente, os encerramentos por tempo limite se comportarão como uma fila por ordem de chegada, na qual os trabalhos são encerrados em lotes.
**nota**
Não há valor máximo de tempo limite para um AWS Batch trabalho.
Se um trabalho for encerrado devido a uma duração de tempo limite excedido, ele não será executado novamente. Se ocorrer uma falha na tentativa de trabalho por si só, ela poderá ser iniciada novamente, caso repetições estejam habilitadas. Além disso, a contagem do tempo limite é reiniciada para a nova tentativa.
**Importante**
Não se pode esperar que trabalhos executados com recursos Fargate sejam executados por um período maior que 14 dias. Se a duração do tempo limite exceder 14 dias, os recursos Fargate podem não estar mais disponíveis, e o trabalho será encerrado.
Em trabalhos de matriz, os trabalhos filho têm a mesma configuração de tempo limite do trabalho pai.
Para obter informações sobre o envio de um AWS Batch trabalho com uma configuração de tempo limite, consulte. [Tutorial: enviar um trabalho](submit_job.md)
# Trabalhos do Amazon EKS
Um emprego é a menor unidade de trabalho em AWS Batch. Um AWS Batch trabalho no Amazon EKS tem um one-to-one mapeamento para um Kubernetes pod. Uma definição de AWS Batch trabalho é um modelo para um AWS Batch trabalho. Ao enviar um AWS Batch trabalho, você faz referência a uma definição de trabalho, direciona uma fila de trabalhos e fornece um nome para um trabalho. Na definição de um AWS Batch trabalho no Amazon EKS, o parâmetro [EKSProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) define o conjunto de parâmetros que um trabalho no AWS Batch Amazon EKS suporta. Em uma [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)solicitação, o [eksPropertiesOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)parâmetro permite a substituição de alguns parâmetros comuns. Dessa forma, você pode usar modelos de definições de trabalhos para vários trabalhos. Quando um trabalho é enviado para seu cluster Amazon EKS, AWS Batch transforma o trabalho em um `podspec` (). `Kind: Pod` O `podspec` usa alguns AWS Batch parâmetros adicionais para garantir que os trabalhos sejam escalados e programados corretamente. AWS Batch combina rótulos e contaminações para garantir que os trabalhos sejam executados somente em nós AWS Batch gerenciados e que outros pods não sejam executados nesses nós.
**Importante**
Se o `hostNetwork` parâmetro não for definido explicitamente em uma definição de trabalho do Amazon EKS, o modo de rede do pod assumirá como AWS Batch padrão o modo host. Mais especificamente, as seguintes configurações serão aplicadas: `hostNetwork=true` e `dnsPolicy=ClusterFirstWithHostNet`.
AWS Batch limpa os pods de trabalho logo após um pod concluir seu trabalho. Para ver os logs do aplicativo do pod, configure um serviço de log para seu cluster. Para obter mais informações, consulte [Use CloudWatch registros para monitorar trabalhos AWS Batch do Amazon EKS](batch-eks-cloudwatch-logs.md).
**Topics**
+ [Tutorial: mapear um trabalho em execução para um pod e um nó](eks-jobs-map-running-job.md)
+ [Tutorial: mapear um pod em execução de volta ao seu trabalho](eks-jobs-map-running-pod-to-job.md)
# Tutorial: mapear um trabalho em execução para um pod e um nó
As `podProperties` de um trabalho em execução têm parâmetros `podName` e `nodeName` definidos para a tentativa de trabalho atual. Use a operação [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)da API para visualizar esses parâmetros.
O seguinte é um exemplo de saída.
```
$ aws batch describe-jobs --job 2d044787-c663-4ce6-a6fe-f2baf7e51b04
{
"jobs": [
{
"status": "RUNNING",
"jobArn": "arn:aws:batch:us-east-1:123456789012:job/2d044787-c663-4ce6-a6fe-f2baf7e51b04",
"jobDefinition": "arn:aws:batch:us-east-1:123456789012:job-definition/MyJobOnEks_SleepWithRequestsOnly:1",
"jobQueue": "arn:aws:batch:us-east-1:123456789012:job-queue/My-Eks-JQ1",
"jobId": "2d044787-c663-4ce6-a6fe-f2baf7e51b04",
"eksProperties": {
"podProperties": {
"nodeName": "ip-192-168-55-175.ec2.internal",
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"resources": {
"requests": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
],
"podName": "aws-batch.b0aca953-ba8f-3791-83e2-ed13af39428c"
}
}
}
]
}
```
Para um trabalho com novas tentativas ativadas, o `podName` final `nodeName` de cada tentativa concluída está no parâmetro de `eksAttempts` lista da operação da [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. O `podName` e `nodeName` da tentativa de execução atual estarão no objeto `podProperties`.
# Tutorial: mapear um pod em execução de volta ao seu trabalho
Um pod tem rótulos que indicam `jobId` a extremidade `uuid` do ambiente computacional ao qual ele pertence. AWS Batch injeta variáveis de ambiente para que o tempo de execução do trabalho possa referenciar as informações do trabalho. Para obter mais informações, consulte [AWS Batch variáveis do ambiente de trabalho](job_env_vars.md). Você pode visualizar isso executando o seguinte comando. A saída é a seguinte:
```
$ kubectl describe pod aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1 -n my-aws-batch-namespace
Name: aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1
Namespace: my-aws-batch-namespace
Priority: 0
Node: ip-192-168-45-88.ec2.internal/192.168.45.88
Start Time: Wed, 26 Oct 2022 00:30:48 +0000
Labels: batch.amazonaws.com/compute-environment-uuid=5c19160b-d450-31c9-8454-86cf5b30548f
batch.amazonaws.com/job-id=f980f2cf-6309-4c77-a2b2-d83fbba0e9f0
batch.amazonaws.com/node-uid=a4be5c1d-9881-4524-b967-587789094647
...
Status: Running
IP: 192.168.45.88
IPs:
IP: 192.168.45.88
Containers:
default:
Image: public.ecr.aws/amazonlinux/amazonlinux:2
...
Environment:
AWS_BATCH_JOB_KUBERNETES_NODE_UID: a4be5c1d-9881-4524-b967-587789094647
AWS_BATCH_JOB_ID: f980f2cf-6309-4c77-a2b2-d83fbba0e9f0
AWS_BATCH_JQ_NAME: My-Eks-JQ1
AWS_BATCH_JOB_ATTEMPT: 1
AWS_BATCH_CE_NAME: My-Eks-CE1
...
```
**Recursos que o AWS Batch Amazon EKS Jobs oferece suporte**
Esses são os recursos AWS Batch específicos que também são comuns aos Kubernetes trabalhos executados no Amazon EKS:
+ [Dependências do trabalho](job_dependencies.md)
+ [Trabalhos de matriz](array_jobs.md)
+ [Tempos limite de trabalho](job_timeouts.md)
+ [Repetições de trabalho automatizadas](job_retries.md)
+ [Usar o agendamento de compartilhamento justo para ajudar a agendar trabalhos](fair-share-scheduling.md)
**`Secrets` e `ServiceAccounts` da Kubernetes**
AWS Batch suporta referências Kubernetes `Secrets` e. `ServiceAccounts` Você pode configurar pods para usar perfis do IAM para contas de serviço do Amazon EKS. Para obter mais informações, consulte [Como Configurar Pods para Utilizar uma Conta de Serviço Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html) no [https://docs.aws.amazon.com/eks/latest/userguide/](https://docs.aws.amazon.com/eks/latest/userguide/).
**Documentação relacionada**
+ [Considerações sobre memória e vCPU para AWS Batch no Amazon EKS](memory-cpu-batch-eks.md)
+ [Executar trabalhos de GPU](gpu-jobs.md)
+ [Trabalhos presos no status `RUNNABLE`](job_stuck_in_runnable.md)
# Trabalhos em paralelo de vários nós
Você pode usar trabalhos paralelos de vários nós para executar trabalhos únicos, que englobem várias instâncias do Amazon EC2. Com trabalhos paralelo de vários nós do AWS Batch (também conhecidos como *programação de grupos*), você pode executar aplicações de computação de alta performance em grande escala e treinamento em modelo de GPU distribuído sem a necessidade de iniciar, configurar e gerenciar diretamente os recursos do Amazon EC2. Uma tarefa paralela de AWS Batch vários nós é compatível com qualquer estrutura que ofereça suporte à comunicação entre nós baseada em IP. Os exemplos incluem Apache MXNet TensorFlow, Caffe2 ou Message Passing Interface (MPI).
Trabalhos paralelos de vários nós de vários nós são enviados como uma única tarefa. No entanto, sua definição de trabalho (ou substituições de nó de envio de trabalho) especifica o número de nós a serem criados para o trabalho e quais grupos de nós criar. Cada trabalho paralelo de vários nós contém um **nó principal** que é executado primeiro. Depois que o nó principal estiver ativo, os nós filhos serão executados e iniciados. O trabalho será concluído somente se o nó principal sair. Nesse caso, todos nós secundários serão terminados. Para obter mais informações, consulte [Grupos de nós](mnp-node-groups.md).
Os nós de trabalho paralelos de vários nós são de locatário único. Isso significa que um único contêiner de trabalho é executado em cada instância do Amazon EC2.
O status final do trabalho (`SUCCEEDED` ou `FAILED`) é determinado pelo status final do trabalho do nó principal. Para obter o status de um trabalho paralelo de vários nós, descreva a tarefa usando a ID da tarefa retornada quando você enviou a tarefa. Se precisar dos detalhes dos nós filhos, você deverá descrever cada nó filho individualmente. Você pode endereçar os nós usando a notação `#N` (começando com 0). Por exemplo, para acessar os detalhes do segundo nó de um trabalho, descreva *aws\$1batch\$1job\$1id* \$11 usando a operação da AWS Batch [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. As informações de `started`, `stoppedAt`, `statusReason` e `exit` para um trabalho paralelo de vários nós são preenchidas a partir do nó principal.
Se você especificar novas repetições de trabalho, uma falha no nó principal fará com que outra tentativa ocorra. Falhas no nó filho não causam a ocorrência de mais tentativas. Cada nova tentativa de um tarefa em paralelo de vários nós atualiza a tentativa correspondente de seus nós filhos associados.
Para executar trabalhos paralelos de vários nós AWS Batch, o código do aplicativo deve conter as estruturas e bibliotecas necessárias para a comunicação distribuída.
**Topics**
+ [Variáveis de ambiente](mnp-env-vars.md)
+ [Grupos de nós](mnp-node-groups.md)
+ [Ciclo de vida do trabalho para trabalhos MNP](job-lifecycle.md)
+ [Considerações sobre o ambiente computacional para MNP com AWS Batch](mnp-ce.md)
# Variáveis de ambiente
Em tempo de execução, cada nó é configurado com as variáveis de ambiente padrão que todos os AWS Batch trabalhos recebem. Além disso, os nós são configurados com as seguintes variáveis de ambiente específicas de trabalhos paralelos de vários nós:
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Essa variável é definida como o número índice do nó principal do trabalho. O código do seu aplicativo pode comparar o `AWS_BATCH_JOB_MAIN_NODE_INDEX` ao `AWS_BATCH_JOB_NODE_INDEX` em um nó individual para determinar se ele é o nó principal.
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Essa variável é definida apenas em nós filhos de trabalhos em paralelo de vários nós. Essa variável não está presente no nó principal. Essa variável é definida como o IPv4 endereço privado do nó principal do trabalho. O código da aplicação do nó filho pode utilizar esse endereço para comunicar-se com o nó principal.
`AWS_BATCH_JOB_NODE_INDEX`
Essa variável é definida como o número do índice de nós do nó. O índice do nó começa em 0, e cada nó filho recebe um número índice exclusivo. Por exemplo, uma tarefa em paralelo de vários nós com 10 filhos possui valores índice de 0-9.
`AWS_BATCH_JOB_NUM_NODES`
Essa variável é definida como o número de nós solicitados por você para seu trabalho paralelo de vários nós.
# Grupos de nós
Um grupo de nós é um grupo idêntico de nós de trabalhos que compartilham as mesmas propriedades do contêiner. Você pode usar AWS Batch para especificar até cinco grupos de nós distintos para cada trabalho.
Cada grupo pode ter suas próprias imagens de contêiner, comandos, variáveis de ambiente e assim por diante. Por exemplo, você pode enviar um trabalho que exija uma instância única `c5.xlarge` para o nó principal e cinco nós filhos da instância `c5.xlarge`. Cada um desses grupos de nós distintos pode especificar diferentes imagens de contêiner ou comandos a serem executados para cada trabalho.
Como alternativa, todos os nós em seu trabalho podem usar um único grupo de nós. Além disso, o código do aplicação pode diferenciar as perfis do nó, como o nó principal e o nó filho. Ele faz isso comparando a variável de ambiente `AWS_BATCH_JOB_MAIN_NODE_INDEX` com seu próprio valor para `AWS_BATCH_JOB_NODE_INDEX`. Você pode ter até 1.000 nós em um único trabalho. Esse é o limite padrão para instâncias em um cluster do Amazon ECS. Você pode [solicitar que esse limite seja aumentado](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**nota**
Atualmente, todos os grupos de nós em um trabalho paralelo de vários nós devem usar o mesmo tipo de instância.
# Ciclo de vida do trabalho para trabalhos MNP
Quando você envia um trabalho paralelo de vários nós, o trabalho entra no status `SUBMITTED`. Em seguida, o trabalho aguarda a conclusão de todas as dependências do trabalho. O trabalho também passa para o status `RUNNABLE`. Por fim, AWS Batch provisiona a capacidade da instância necessária para executar seu trabalho e executa essas instâncias.
Cada tarefa em paralelo de vários nós contém um **nó principal**. O nó principal é uma subtarefa única que AWS Batch monitora para determinar o resultado do trabalho de vários nós enviado. O nó principal é iniciado primeiro e passa para o status de `STARTING`. O valor do tempo limite especificado no campo de parâmetro `attemptDurationSeconds` se aplica a todo o trabalho, não aos nós.
Quando o nó principal atinge o status de `RUNNING` depois que o contêiner do nó estiver em execução, os nós filhos são iniciados e também são movidos para o status de `STARTING`. Os nós filhos são exibidos em uma ordem aleatória. Não há garantias sobre o tempo ou a ordem de execução do nó filho. Para garantir que todos os nós das tarefas estejam no status de `RUNNING` após a execução do contêiner do nó, o código do seu aplicativo pode consultar a API do AWS Batch para obter informações do nó principal e do nó filho. Como alternativa, o código da aplicação pode esperar até que todos os nós estejam online, antes de iniciar qualquer tarefa de processamento distribuído. O endereço IP privado do nó principal está disponível como a variável de ambiente `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` em cada nó filho. Seu código de aplicação pode usar essas informações para coordenar e comunicar dados entre cada tarefa.
À medida que os nós individuais saem, eles são movidos para `SUCCEEDED` ou `FAILED`, a depender do código de saída. Se o nó principal for encerrado, a tarefa será considerada terminada e todos os nós filhos serão parados. Se um nó filho morrer, AWS Batch não executará nenhuma ação nos outros nós do trabalho. Se você não quiser que seu trabalho continue com um número de nós reduzido, você deve incluir isso no código do aplicativo. Isso termina ou cancela o trabalho.
# Considerações sobre o ambiente computacional para MNP com AWS Batch
Há várias coisas a serem consideradas ao criar ambientes de computação para executar trabalhos paralelos de vários nós com o AWS Batch.
+ Trabalhos paralelos de vários nós não são compatíveis com ambientes de computação `UNMANAGED`.
+ Se você deseja enviar trabalhos paralelos de vários nós para um ambiente de computação, crie um grupo com posicionamento em cluster ** em uma Zona de Disponibilidade única e associe-a aos seus recursos de computação. Isso mantém seus trabalhos paralelos de vários nós em um agrupamento lógico de instâncias próximas com alto potencial de fluxo de rede. Para obter mais informações, consulte [Grupos de posicionamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html), no *Guia do usuário do Amazon EC2*.
+ Trabalhos paralelos de vários nós não são compatíveis com ambientes de computação que usam instâncias spot.
+ AWS Batch trabalhos paralelos de vários nós usam o modo de `awsvpc` rede do Amazon ECS, que fornece aos contêineres de trabalhos paralelos de vários nós as mesmas propriedades de rede das instâncias do Amazon EC2. Cada contêiner de trabalho paralelo de vários nós obtém sua própria interface de rede elástica, um endereço IP privado primário e um nome de host DNS interno. A interface de rede é criada na mesma sub-rede VPC que seu recurso de computação do host.
+ Seu ambiente de computação não pode ter mais de cinco grupos de segurança associados a ele. As interfaces de rede elástica criadas e anexadas a uma tarefa do MNP usarão os grupos de segurança especificados em seu ambiente computacional. Se você não especificar um grupo de segurança, o grupo de segurança padrão da VPC será usado.
+ O modo de rede `awsvpc` não fornece as interfaces de rede elásticas para trabalhos paralelos de vários nós com endereços IP públicos. Para acessar a internet, seus recursos de computação devem ser iniciados em uma sub-rede privada configurada para usar um gateway NAT. Para obter mais informações, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. A comunicação entre nós deve usar o endereço IP privado ou o nome do host DNS para o nó. Trabalhoso paralelos de vários nós executads em recursos de computação em sub-redes públicas não têm acesso à rede de saída. Para criar uma VPC com sub-redes privadas e um gateway NAT, consulte [Criar uma nuvem privada virtual](create-public-private-vpc.md).
+ As interfaces de rede elástica criadas e anexadas aos seus recursos de computação não podem ser desassociadas manualmente nem modificadas pela sua conta. Isso visa prevenir a exclusão acidental de uma interface de rede elástica associada a uma tarefa em execução. Para liberar as interfaces de rede elásticas para uma tarefa, encerre a tarefa.
+ Seu ambiente computacional deve ter v máximo suficiente CPUs para suportar sua tarefa paralela de vários nós.
+ Sua cota de instância do Amazon EC2 inclui o número de instâncias exigidas para executar seu trabalho. Por exemplo, suponha que sua tarefa exija 30 instâncias, mas sua conta só pode executar 20 instâncias em uma região. Nesse caso, seu trabalho ficará preso no status `RUNNABLE`.
+ Se você especificar um tipo de instância para um grupo de nós em um trabalhos paralelos de vários nós, seu ambiente de computação deverá executar esse tipo de instância.
# Trabalhos paralelos de vários nós no Amazon EKS
Você pode usar o AWS Batch Amazon Elastic Kubernetes Service para executar trabalhos paralelos de vários nós (MNP) (também conhecidos *como* agendamento de grupos) em seus clusters gerenciados. Kubernetes Essa opção é comumente usada para trabalhos grandes, de acoplamento fiirme e de alto desempenho que não podem ser executados em uma única instância do Amazon Elastic Compute Cloud. Para obter mais informações, consulte [Trabalhos em paralelo de vários nós](multi-node-parallel-jobs.md).
É possível usar esse atributo para executar aplicações de computação de alto desempenho específicos do Kubernetes gerenciado pelo Amazon EKS, treinamento de grandes modelos de linguagem e outros trabalhos de Inteligência Artificial (IA)/machine learning (ML).
**Topics**
+ [Execução de trabalhos de MNP](mnp-eks-running-mnp-jobs.md)
+ [Criar uma definição de trabalho de GPU do Amazon EKS](mnp-eks-create-eks-mnp-job-definition.md)
+ [Enviar um trabalho MNP do Amazon EKS](mnp-eks-submit-eks-mnp-job.md)
+ [Substituir uma definição de trabalho MNP do Amazon EKS](mnp-eks-override-eks-mnp-job-definition.md)
# Execução de trabalhos de MNP
AWS Batch suporta trabalhos de MNP no Amazon Elastic Container Service e no Amazon EKS usando o Amazon EC2. Veja a seguir mais detalhes sobre os parâmetros de instância e contêiner do atributo.
## Cotas de instância para MNP no Amazon EKS
+ Até 1.000 instâncias podem ser usadas para um único trabalho MNP.
+ Até 5.000 instâncias podem participar de um único cluster do Amazon EKS.
+ Até 5 ambientes de computação podem ser agrupados e anexados a uma fila de trabalhos.
Por exemplo, é possível dimensionar até 5 ambientes de computação em cluster em uma fila de trabalhos e 1.000 instâncias em cada ambiente de computação.
Além dos parâmetros de instância, é importante observar que você não pode usar o Fargate para trabalhos MNP por meio de nenhum dos serviços.
É possível usar apenas um tipo de instância em cada trabalho MNP. É possível alterar o tipo de instância ao atualizar o ambiente de computação ou ao definir um novo ambiente de computação. Também é possível especificar o tipo de instância e fornecer requisitos de vCPU e memória ao criar a definição de trabalho.
## Cotas de contêineres para MNP no Amazon EKS
+ Um trabalho paralelo de vários nós aceita um pod por nó.
+ Até 10 contêineres (ou 10 contêineres de inicialização. Para obter mais informações, consulte [Contêineres de inicialização](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) na *documentação do Kubernetes*) em cada pod.
+ Até 5 intervalos de nós em cada trabalho MNP.
+ Até 10 imagens de contêineres distintos em cada intervalo de nós.
Por exemplo, é possível executar até máximo de 10.000 contêineres em um único trabalho MNP com 5 intervalos de nós e um total de 50 imagens exclusivas.
## Execução de trabalhos MNP em uma Amazon VPC privado e em um cluster do Amazon EKS
Os trabalhos MNP podem ser executados em qualquer cluster do Amazon EKS, quer ele tenha Internet pública ou não. Ao usar um cluster do Amazon EKS com apenas acesso à rede privada, certifique-se de que ele AWS Batch possa acessar o plano de controle do Amazon EKS e o servidor de Kubernetes API gerenciado. É possível conceder o acesso necessário por meio dos endpoints da Amazon Virtual Private Cloud. Para obter mais informações, consulte [Configurar um serviço de endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html).
Os pods de cluster do Amazon EKS não podem baixar uma imagem de uma fonte pública, pois a VPC privada não tem acesso à Internet. O cluster do Amazon EKS deve extrair imagens de um registro de contêiner que esteja na Amazon VPC. É possível criar um [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) na sua Amazon VPC e copiar imagens de contêiner para ele para acesso aos seus nós.
Também é possível criar uma regra de cache pull through com o Amazon ECR. Depois que uma regra de cache pull through é criada para um registro público externo, você pode simplesmente extrair uma imagem desse registro público externo usando o URI do registro privado do Amazon ECR. Em seguida, o Amazon ECR cria um repositório e armazena a imagem no cache. Quando uma imagem em cache é extraída usando o URI de registro privado do Amazon ECR, o Amazon ECR verifica o registro remoto para ver se há uma nova versão da imagem e atualizará seu registro privado até uma vez a cada 24 horas. Para obter mais informações, consulte [Criar uma regra de cache de pullthrough no Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html).
## Notificação de erro
Se suas tarefas de MNP estiverem bloqueadas, você poderá receber notificações por meio do Console de gerenciamento da AWS e da Amazon EventBridge. Por exemplo, se um trabalho MNP estiver preso no topo da fila, você poderá receber uma notificação sobre o problema, juntamente com informações sobre o que o causou, para que você possa tomar medidas imediatas para desbloquear a fila de trabalhos. Opcionalmente, é possível encerrar automaticamente o trabalho MNP se nenhuma ação for tomada em um determinado período de tempo, que pode ser definido no modelo de fila de trabalho. Para obter mais informações, consulte [Eventos bloqueados da fila de trabalhos](batch-job-queue-blocked-events.md).
# Criar uma definição de trabalho de GPU do Amazon EKS
Para definir e executar trabalhos MNP no Amazon EKS, há novos parâmetros nas operações de API [https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html) e [https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html).
+ Use [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) na seção [https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html) para configurar sua definição de trabalho MNP.
+ Use [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html) na seção [https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html](https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html) para substituir os parâmetros configurados na definição do trabalho ao enviar um trabalho MNP.
Essas ações podem ser definidas por meio de operações de API e do Console de gerenciamento da AWS.
## Referência: registrar a carga útil da solicitação de definição de trabalho MNP do Amazon EKS
O exemplo a seguir ilustra como é possível registrar uma definição de trabalho MNP do Amazon EKS com dois nós.
```
{
"jobDefinitionName": "MyEksMnpJobDefinition",
"type": "multinode",
"nodeProperties": {
"numNodes": 2,
"mainNode": 0,
"nodeRangeProperties": [
{
"targetNodes" : "0:",
"eksProperties": {
"podProperties": {
"containers": [
{
"name": "test-eks-container-1",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": [
"sleep",
"60"
],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
},
"securityContext":{
"runAsUser":1000,
"runAsGroup":3000,
"privileged":true,
"readOnlyRootFilesystem":true,
"runAsNonRoot":true
}
}
],
"initContainers": [
{
"name":"init-ekscontainer",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": [
"echo",
"helloWorld"
],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
],
"metadata": {
"labels": {
"environment" : "test"
}
}
}
}
}
]
}
}
```
Para registrar a definição de tarefa usando o AWS CLI, copie a definição em um arquivo local chamado *MyEksMnpJobDefinition.json* e execute o comando a seguir.
```
aws batch register-job-definition --cli-input-json file://MyEksMnpJobDefinition.json
```
Você receberá a seguinte resposta JSON.
```
{
"jobDefinitionName": "MyEksMnpJobDefinition",
"jobDefinitionArn": "arn:aws:batch:us-east-1:0123456789:job-definition/MyEksMnpJobDefinition:1",
"revision": 1
}
```
# Enviar um trabalho MNP do Amazon EKS
Para enviar um trabalho usando a definição de trabalho registrada, digite o seguinte comando. Substitua o valor de pelo nome ou ARN de uma fila de trabalho pré-existente associada a um ambiente de computação do Amazon EKS.
```
aws batch submit-job --job-queue \
--job-definition MyEksMnpJobDefinition \
--job-name myFirstEksMnpJob
```
Você receberá a seguinte resposta JSON.
```
{
"jobArn": "arn:aws:batch:region:account:job/9b979cce-9da0-446d-90e2-ffa16d52af68",
"jobName": "myFirstEksMnpJob",
"jobId": ""
}
```
Você pode verificar o status do trabalho usando o jobId retornado com o seguinte comando.
```
aws batch describe-jobs --jobs
```
# Substituir uma definição de trabalho MNP do Amazon EKS
Opcionalmente, é possível substituir os detalhes da definição do trabalho (como alterar o tamanho do trabalho MNP ou os detalhes do trabalho secundário). A seguir, um exemplo de carga útil de solicitação JSON para enviar um trabalho MNP de cinco nós e alterações no comando `test-eks-container-1` do contêiner.
```
{
"numNodes": 5,
"nodePropertyOverrides": [
{
"targetNodes": "0:",
"eksPropertiesOverride": {
"podProperties": {
"containers": [
{
"name": "test-eks-container-1",
"command": [
"sleep",
"150"
]
}
]
}
}
}
]
}
```
Para enviar um trabalho com essas substituições, salve o exemplo em um arquivo local, *eks-mnp-job-nodeoverride.json*, e use o AWS CLI para enviar o trabalho com as substituições.
# Trabalhos de matriz
Um trabalho de matriz é um trabalho que compartilha parâmetros comuns, como a definição do trabalhoCPUs, v e memória. Ele é executado como coleções de tópicos de trabalhos básicos porém separados, que podem ser distribuídos entre vários hosts e executados simultaneamente. Os trabalhos de matriz são a maneira mais eficiente de executar trabalhos extremamente em paralelo, como simulações de Monte Carlo, varreduras paramétricas ou trabalhos grandes de renderização.
AWS Batch os trabalhos de matriz são enviados da mesma forma que os trabalhos normais. No entanto, você especifica o tamanho da matriz (entre 2 e 10.000) para definir quantos trabalhos filho devem ser executados no campo da matriz. Se você enviar um trabalho com tamanho da matriz 1.000, haverá uma única execução de trabalho gerando 1.000 trabalhos filho. O trabalho de matriz é uma referência ou ponteiro para gerenciar todos os trabalhos filho. Você pode enviar grandes workloads com uma única consulta. O tempo limite especificado no campo do parâmetro `attemptDurationSeconds` é aplicado em cada trabalho filho. O trabalho pai da matriz não tem um tempo limite.
Quando você envia um trabalho de matriz, o trabalho de matriz principal recebe uma ID de AWS Batch trabalho normal. Cada trabalho filho tem a mesma ID base. No entanto, o índice da matriz do trabalho filho é anexado até o fim da ID pai, como `example_job_ID:0` para o primeiro trabalho filho da matriz.
O trabalho de matriz pai pode inserir um status `SUBMITTED`, `PENDING`, `FAILED` ou `SUCCEEDED`. Um trabalho de matriz pai é atualizado para `PENDING` quando qualquer trabalho filho é atualizado para `RUNNABLE`. Para obter mais informações sobre dependências do trabalho, consulte [Dependências do trabalho](job_dependencies.md).
Durante o runtime, a variável de ambiente `AWS_BATCH_JOB_ARRAY_INDEX` é definida como o número do índice da matriz do trabalho correspondente do contêiner. O primeiro índice do trabalho de matriz é numerado com `0` e as tentativas subsequentes são numeradas em ordem crescente (por exemplo 1, 2 e 3). Você pode utilizar esse valor de índice para controlar como os filhos do trabalho de matriz serão diferenciados. Para obter mais informações, consulte [Usar o índice de trabalho de matriz para controle de diferenciação de trabalhos](array_index_example.md).
Para dependências do trabalhos de matriz, você pode especificar um tipo para cada dependência, como `SEQUENTIAL` ou `N_TO_N`. Você pode especificar uma dependência do tipo `SEQUENTIAL` (sem especificar ID de trabalho), de forma que cada trabalho de matriz filho seja concluído sequencialmente, começando com o índice 0. Por exemplo, se você enviar um trabalho de matriz com o tamanho da matriz 100 e especificar uma dependência do tipo `SEQUENTIAL`, 100 trabalhos filho serão gerados sequencialmente. O primeiro trabalho filho precisará ter êxito antes que o próximo trabalho filho comece. A figura abaixo mostra o trabalho A, um trabalho de matriz com um tamanho da matriz somando 10. Cada trabalho no índice filho do trabalho A depende do trabalho filho anterior. O trabalho A:1 não pode iniciar até que o trabalho A:0 termine.
![\[Flowchart showing Job-A with sequential child jobs A:0 through A:9, connected by arrows.\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/images/sequential-dep.png)
Você também pode especificar uma dependência do tipo `N_TO_N` com ID do trabalho para trabalhos de matriz. Deste modo, cada índice filho dessa tarefa precisa aguardar, para que o índice filho correspondente de cada dependência seja concluído antes de começar. A figura a seguir mostra o trabalho A e o trabalho B, dois trabalhos de matriz de tamanho 10.000 cada. Cada trabalho no índice filho do trabalho B depende do índice correspondente no trabalho A. O trabalho B:1 não pode iniciar até que o trabalho A:1 termine.
![\[Two array jobs, Job-A and Job-B, with 10,000 indexed tasks each, showing N_TO_N dependency.\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/images/n-to-n-dep.png)
Se você cancelar ou encerrar um trabalho de matriz pai, todos os trabalhos filho serão cancelados ou encerrados com ele. Você pode cancelar ou encerrar trabalhos filho individuais (movendo-os para um status `FAILED`) sem afetar os outros trabalhos filho. No entanto, se um trabalho de matriz filho falhar (sozinho, por ter sido cancelado ou por encerramento manual), o trabalho pai também falhará. Nesse cenário, o trabalho pai faz a transição para `FAILED` quando todos os trabalhos filhos são concluídos.
Para obter mais informações sobre como pesquisar e filtrar trabalhos de matriz, consulte[Pesquisar por trabalhos em uma fila de trabalho](searching-filtering-jobs.md).
**Topics**
+ [Exemplo de um fluxo de trabalho de matriz](example_array_job.md)
+ [Usar o índice de trabalho de matriz para controle de diferenciação de trabalhos](array_index_example.md)
# Exemplo de um fluxo de trabalho de matriz
Um fluxo de trabalho comum para AWS Batch os clientes é executar um trabalho de configuração pré-requisito, executar uma série de comandos em um grande número de tarefas de entrada e, em seguida, concluir com um trabalho que agrega resultados e grava dados resumidos no Amazon S3, DynamoDB, Amazon Redshift ou Aurora.
Por exemplo:
+ `JobA`: um trabalho de não matriz padrão que executa uma rápida listagem e validação de metadados de objetos em um bucket do Amazon S3, `BucketA`. A sintaxe [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON é a seguinte.
```
{
"jobName": "JobA",
"jobQueue": "ProdQueue",
"jobDefinition": "JobA-list-and-validate:1"
}
```
+ `JobB`: um trabalho de matriz com 10 mil cópias que depende do `JobA`, que, por sua vez, executa comandos com uso intensivo de CPU para cada objeto em `BucketA` e carrega resultados para `BucketB`. A sintaxe [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON é a seguinte.
```
{
"jobName": "JobB",
"jobQueue": "ProdQueue",
"jobDefinition": "JobB-CPU-Intensive-Processing:1",
"containerOverrides": {
"resourceRequirements": [
{
"type": "MEMORY",
"value": "4096"
},
{
"type": "VCPU",
"value": "32"
}
]
}
"arrayProperties": {
"size": 10000
},
"dependsOn": [
{
"jobId": "JobA_job_ID"
}
]
}
```
+ `JobC`: outro trabalho de matriz com 10 mil cópias, que depende do `JobB` com um modelo de dependência de `N_TO_N`, que executa comandos com uso intensivo de memória em relação a cada item em`BucketB`, grava metadados no DynamoDB e carrega saída resultante em `BucketC`. A sintaxe [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON é a seguinte.
```
{
"jobName": "JobC",
"jobQueue": "ProdQueue",
"jobDefinition": "JobC-Memory-Intensive-Processing:1",
"containerOverrides": {
"resourceRequirements": [
{
"type": "MEMORY",
"value": "32768"
},
{
"type": "VCPU",
"value": "1"
}
]
}
"arrayProperties": {
"size": 10000
},
"dependsOn": [
{
"jobId": "JobB_job_ID",
"type": "N_TO_N"
}
]
}
```
+ `JobD`: um trabalho de matriz que executa 10 etapas de validação, no qual cada uma precisa consultar o DynamoDB e pode interagir com qualquer um dos buckets do Amazon S3 mencionados acima. Cada uma das etapas no `JobD` executa o mesmo comando. No entanto, o comportamento é diferente baseado no valor da variável de ambiente `AWS_BATCH_JOB_ARRAY_INDEX` dentro do contêiner do trabalho. Essas etapas de validação são executadas sequencialmente (por exemplo, `JobD:0` e, em seguida, `JobD:1`). A sintaxe [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON é a seguinte.
```
{
"jobName": "JobD",
"jobQueue": "ProdQueue",
"jobDefinition": "JobD-Sequential-Validation:1",
"containerOverrides": {
"resourceRequirements": [
{
"type": "MEMORY",
"value": "32768"
},
{
"type": "VCPU",
"value": "1"
}
]
}
"arrayProperties": {
"size": 10
},
"dependsOn": [
{
"jobId": "JobC_job_ID"
},
{
"type": "SEQUENTIAL"
},
]
}
```
+ `JobE`: um trabalho de não matriz final, que executa algumas operações de limpeza simples e envia uma notificação SNS da Amazon, com uma mensagem avisando que o pipeline foi concluído e vinculado a URL de saída. A sintaxe [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON é a seguinte.
```
{
"jobName": "JobE",
"jobQueue": "ProdQueue",
"jobDefinition": "JobE-Cleanup-and-Notification:1",
"parameters": {
"SourceBucket": "s3://amzn-s3-demo-source-bucket",
"Recipient": "pipeline-notifications@mycompany.com"
},
"dependsOn": [
{
"jobId": "JobD_job_ID"
}
]
}
```
# Usar o índice de trabalho de matriz para controle de diferenciação de trabalhos
Este tutorial descreve instruções de uso da variável de ambiente `AWS_BATCH_JOB_ARRAY_INDEX` para diferenciar os trabalhos filho. Cada trabalho filho é atribuído a essa variável. O exemplo utiliza o número de índice do trabalho filho para ler uma linha específica em um arquivo. Em seguida, ele substitui o parâmetro associado a esse número de linha por um comando dentro do contêiner do trabalho. O resultado é que você pode ter vários AWS Batch trabalhos que executam a mesma imagem do Docker e argumentos de comando. No entanto, os resultados serão diferentes porque o índice de trabalho da matriz é usado como um modificador.
Neste tutorial, um arquivo de texto é criado com todas as cores do arco-íris, cada uma em sua própria linha. Em seguida, você cria um script de ponto de entrada para um contêiner do Docker que converte o índice em um valor, que pode ser usado para um número de linha no campo do arquivo de cores. O índice inicia em zero, mas os números da linha iniciam em um. Crie um Dockerfile que copie os arquivos de cores e índice na imagem de contêiner, e defina o `ENTRYPOINT` da imagem como o script de ponto de entrada. O Dockerfile e os recursos são incorporados em uma imagem do Docker, que é enviada para o Amazon ECR. Em seguida, você registra uma definição de tarefa que usa sua nova imagem de contêiner, envia uma tarefa de AWS Batch matriz com essa definição de tarefa e visualiza os resultados.
**Topics**
+ [Pré-requisitos](array-tutorial-prereqs.md)
+ [Criar uma imagem de contêiner](build-index-container.md)
+ [Enviar sua imagem para o Amazon ECR](push-array-image.md)
+ [Criar e registrar uma definição de trabalho](create-array-job-def.md)
+ [Enviar um trabalho AWS Batch de matriz](submit-array-job.md)
+ [Visualizar seus logs de trabalhos de matriz](#array-tutorial-logs)
# Pré-requisitos
Este fluxo de trabalho de tutorial tem os seguintes pré-requisitos:
+ Um ambiente AWS Batch computacional. Para obter mais informações, consulte [Crie um ambiente de computação](create-compute-environment.md).
+ Uma fila AWS Batch de trabalhos e um ambiente computacional associado. Para obter mais informações, consulte [Crie uma fila de trabalhos](create-job-queue.md).
+ O AWS CLI instalado em seu sistema local. Para obter mais informações, consulte [> Instalar a AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) no *Guia do usuário da AWS Command Line Interface *.
+ Docker instalado em seu sistema local. Para obter mais informações, consulte [Sobre o Docker CE](https://docs.docker.com/install/) no campo de documentação do Docker.
# Criar uma imagem de contêiner
Você pode usar o `AWS_BATCH_JOB_ARRAY_INDEX` em uma definição de trabalho no parâmetro de comando. No entanto, recomendamos criar uma imagem de contêiner que use a variável em um script de ponto de entrada. Esta seção descreve instruções para criação essa imagem de contêiner.
**Para criar sua imagem de contêiner do Docker**
1. Crie novo diretório, a ser usado como seu workspace de imagem do Docker, e navegue até ele.
1. Crie um arquivo de nome `colors.txt` em seu diretório do workspace e cole o conteúdo a seguir.
```
red
orange
yellow
green
blue
indigo
violet
```
1. Crie um arquivo de nome `print-color.sh` em seu diretório do workspace e cole o conteúdo a seguir.
**nota**
A variável `LINE` é definida como `AWS_BATCH_JOB_ARRAY_INDEX` \$11, pois o índice de matriz inicia em 0, mas os números de linha iniciam em com 1. A variável `COLOR` é definida como a cor no `colors.txt` associado ao número de linha.
```
#!/bin/sh
LINE=$((AWS_BATCH_JOB_ARRAY_INDEX + 1))
COLOR=$(sed -n ${LINE}p /tmp/colors.txt)
echo My favorite color of the rainbow is $COLOR.
```
1. Crie um arquivo de nome `Dockerfile` em seu diretório do workspace e cole nele o conteúdo a seguir. Esse Dockerfile copia os arquivos anteriores em seu contêiner e define o script de ponto de entrada a ser executado quando o contêiner for iniciado.
```
FROM busybox
COPY print-color.sh /tmp/print-color.sh
COPY colors.txt /tmp/colors.txt
RUN chmod +x /tmp/print-color.sh
ENTRYPOINT /tmp/print-color.sh
```
1. Compile sua imagem do Docker.
```
$ docker build -t print-color .
```
1. Teste seu contêiner com o script a seguir. Esse script define a variável `AWS_BATCH_JOB_ARRAY_INDEX` como 0 localmente e, em seguida, a acrescenta, para simular o que um trabalho de matriz com sete filhos faz.
```
$ AWS_BATCH_JOB_ARRAY_INDEX=0
while [ $AWS_BATCH_JOB_ARRAY_INDEX -le 6 ]
do
docker run -e AWS_BATCH_JOB_ARRAY_INDEX=$AWS_BATCH_JOB_ARRAY_INDEX print-color
AWS_BATCH_JOB_ARRAY_INDEX=$((AWS_BATCH_JOB_ARRAY_INDEX + 1))
done
```
A saída vem a seguir.
```
My favorite color of the rainbow is red.
My favorite color of the rainbow is orange.
My favorite color of the rainbow is yellow.
My favorite color of the rainbow is green.
My favorite color of the rainbow is blue.
My favorite color of the rainbow is indigo.
My favorite color of the rainbow is violet.
```
# Enviar sua imagem para o Amazon ECR
Agora que você criou e testou o contêiner do Docker, envie-o para um repositório de imagens. Este exemplo usa o Amazon ECR, mas você pode usar outro registro, como DockerHub.
1. Crie um repositório de imagens do Amazon ECR para armazenar sua imagem de contêiner. Este exemplo usa somente AWS CLI o. mas você também pode usar Console de gerenciamento da AWS o. Para obter mais informações, consulte [Criando um Repositório](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html) no campo do *Manual do Usuário do Amazon Elastic Container Registry*.
```
$ aws ecr create-repository --repository-name print-color
```
1. Marque sua imagem `print-color` com o URI do repositório do Amazon ECR retornado na etapa anterior.
```
$ docker tag print-color aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
1. Inicie a sessão no seu registro do Amazon ECR. Para obter mais informações, consulte [Autenticação de Registro](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth) no campo do *Manual do Usuário do Amazon Elastic Container Registry*.
```
$ aws ecr get-login-password \
--region region | docker login \
--username AWS \
--password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
```
1. Envie sua imagem para o Amazon ECR.
```
$ docker push aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
# Criar e registrar uma definição de trabalho
Agora que sua imagem do Docker está em um registro de imagem, você pode especificá-la em uma definição de AWS Batch tarefa. Assim, você pode usá-la posteriormente para executar um trabalho de matriz. Este exemplo usa apenas o AWS CLI. No entanto, você também pode usar o Console de gerenciamento da AWS. Para obter mais informações, consulte [Criar uma definição de tarefa de nó único](create-job-definition.md).
**Para criar uma definição de trabalho**
1. Crie um arquivo de nome `print-color-job-def.json` em seu diretório do workspace e cole o conteúdo a seguir. Substitua o URI do repositório de imagem pelo seu próprio URI da imagem.
```
{
"jobDefinitionName": "print-color",
"type": "container",
"containerProperties": {
"image": "aws_account_id.dkr.ecr.region.amazonaws.com/print-color",
"resourceRequirements": [
{
"type": "MEMORY",
"value": "250"
},
{
"type": "VCPU",
"value": "1"
}
]
}
}
```
1. Registre a definição do trabalho com AWS Batch.
```
$ aws batch register-job-definition --cli-input-json file://print-color-job-def.json
```
# Enviar um trabalho AWS Batch de matriz
Depois de registrar sua definição de tarefa, você pode enviar uma tarefa de AWS Batch matriz que usa sua nova imagem de contêiner.
**Para enviar um trabalho AWS Batch de matriz**
1. Crie um arquivo de nome `print-color-job.json` em seu diretório do workspace e cole o conteúdo a seguir.
**nota**
Este exemplo usa a fila de trabalhos mencionada na seção [Pré-requisitos](array-tutorial-prereqs.md).
```
{
"jobName": "print-color",
"jobQueue": "existing-job-queue",
"arrayProperties": {
"size": 7
},
"jobDefinition": "print-color"
}
```
1. Envie o trabalho para sua fila de AWS Batch trabalhos. Anote a ID do trabalho retornado na saída.
```
$ aws batch submit-job --cli-input-json file://print-color-job.json
```
1. Descreva o status do trabalho e espere até que o trabalho seja movido para `SUCCEEDED`.
## Visualizar seus logs de trabalhos de matriz
Depois que seu trabalho atingir o `SUCCEEDED` status, você poderá visualizar os CloudWatch registros no contêiner do trabalho.
**Para ver os registros do seu trabalho em CloudWatch Registros**
1. Abra o AWS Batch console em [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. No painel de navegação à esquerda, escolha **Trabalhos**.
1. Para **Fila de Trabalhos**, selecione uma fila.
1. Na seção **Status**, escolha **bem-sucedido**.
1. Para exibir todas os trabalhos filho de seu trabalho matriz, selecione a ID do trabalho que foi retornado na seção anterior.
1. Para consultar os logs do contêiner do trabalho, selecione um dos trabalhos filho e escolha **Visualizar Logs**.
![\[Logs do contêiner de trabalhos de matriz\]](http://docs.aws.amazon.com/pt_br/batch/latest/userguide/images/array-logs.png)
1. Visualize os outros logs de trabalho filho. Cada trabalho retorna uma cor diferente do arco-íris.
# Executar trabalhos de GPU
Os trabalhos de GPU ajudam você a executar trabalhos que usam os de uma instância. GPUs
Os seguintes tipos de instância do Amazon EC2 baseados em GPU são compatíveis. Para obter mais informações, consulte [Instâncias Amazon EC2 G3](https://aws.amazon.com/ec2/instance-types/g3/), [Instâncias Amazon EC2 G4](https://aws.amazon.com/ec2/instance-types/g4/), [Instâncias Amazon EC2 G5](https://aws.amazon.com/ec2/instance-types/g5/),[Instâncias Amazon EC2 G6](https://aws.amazon.com/ec2/instance-types/g6/), [Instâncias Amazon EC2 P2](https://aws.amazon.com/ec2/instance-types/p2/), [Instâncias Amazon EC2 P3](https://aws.amazon.com/ec2/instance-types/p3/), [Instâncias Amazon EC2 P4d](https://aws.amazon.com/ec2/instance-types/p4/), [Instâncias Amazon EC2 P5](https://aws.amazon.com/ec2/instance-types/p5/), [Instâncias Amazon EC2 P6](https://aws.amazon.com/ec2/instance-types/p6/), [Instâncias Amazon EC2 Trn1](https://aws.amazon.com/ec2/instance-types/trn1/), [Instâncias Amazon EC2 Trn2](https://aws.amazon.com/ec2/instance-types/trn2/), [Instâncias Amazon EC2 Inf1](https://aws.amazon.com/ec2/instance-types/inf1/), [Instâncias Amazon EC2 Inf2](https://aws.amazon.com/ec2/instance-types/inf2/), [Instâncias Amazon EC2 Dl1](https://aws.amazon.com/ec2/instance-types/dl1/) e [Instâncias Amazon EC2 Dl2](https://aws.amazon.com/ec2/instance-types/dl2q/).
| Tipo de instância | GPUs | Memória da GPU | v CPUs | Memória | Largura de banda de rede |
| --- | --- | --- | --- | --- | --- |
| g3s.xlarge | 1 | 8 GiB | 4 | 30,5 GiB | 10 Gbps |
| g3.4xlarge | 1 | 8 GiB | 16 | 122 GiB | Até 10 Gbps |
| g3.8xlarge | 2 | 16 GiB | 32 | 244 GiB | 10 Gbps |
| g3.16xlarge | 4 | 32 GiB | 64 | 488 GiB | 25 Gbps |
| g4dn.xlarge | 1 | 16 GiB | 4 | 16 GiB | Até 25 Gbps |
| g4dn.2xlarge | 1 | 16 GiB | 8 | 32 GiB | Até 25 Gbps |
| g4dn.4xlarge | 1 | 16 GiB | 16 | 64 GiB | Até 25 Gbps |
| g4dn.8xlarge | 1 | 16 GiB | 32 | 128 GiB | 50 Gbps |
| g4dn.12xlarge | 4 | 64 GiB | 48 | 192 GiB | 50 Gbps |
| g4dn.16xlarge | 1 | 16 GiB | 64 | 256 GiB | 50 Gbps |
| g5.xlarge | 1 | 24 GiB | 4 | 16 GiB | Até 10 Gbps |
| g5.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Até 10 Gbps |
| g5.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Até 25 Gbps |
| g5.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbps |
| g5.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbps |
| g5.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gbps |
| g5.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbps |
| g5.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbps |
| g5g.xlarge | 1 | 16 GiB | 4 | 8 GiB | Até 10 Gbps |
| g5g.2xlarge | 1 | 16 GiB | 8 | 16 GiB | Até 10 Gbps |
| g5g.4xlarge | 1 | 16 GiB | 16 | 32 GiB | Até 10 Gbps |
| g5g.8xlarge | 1 | 16 GiB | 32 | 64 GiB | 12 Gbps |
| g5g.16xlarge | 2 | 32 GiB | 64 | 128 GiB | 25 Gbps |
| g5g.metal | 2 | 32 GiB | 64 | 128 GiB | 25 Gbps |
| g6.xlarge | 1 | 24 GiB | 4 | 16 GiB | Até 10 Gbps |
| g6.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Até 10 Gbps |
| g6.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Até 25 Gbps |
| g6.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbps |
| g6.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbps |
| g6.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gbps |
| g6.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbps |
| g6.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbps |
| g6e.xlarge | 1 | 48 GiB | 4 | 32 GiB | Até 20 Gbps |
| g6e.2xlarge | 1 | 48 GiB | 8 | 64 GiB | Até 20 Gbps |
| g6e.4xlarge | 1 | 48 GiB | 16 | 128 GiB | 20 Gbps |
| g6e.8xlarge | 1 | 48 GiB | 32 | 256 GiB | 25 Gbps |
| g6e.16xlarge | 1 | 48 GiB | 64 | 512 GiB | 35 Gbps |
| g6e.12xlarge | 4 | 192 GiB | 48 | 384 GiB | 100 Gbps |
| g6e.24xlarge | 4 | 192 GiB | 96 | 768 GiB | 200 Gbps |
| g6e.48xlarge | 8 | 384 GiB | 192 | 1536 GiB | 400 Gbps |
| gr6.4xlarge | 1 | 24 GiB | 16 | 128 GiB | Até 25 Gbps |
| gr6.8xlarge | 1 | 24 GiB | 32 | 256 GiB | 25 Gbps |
| p2.xlarge | 1 | 12 GiB | 4 | 61 GiB | Alto |
| p2.8xlarge | 8 | 96 GiB | 32 | 488 GiB | 10 Gbps |
| p2.16xlarge | 16 | 192 GiB | 64 | 732 GiB | 20 Gbps |
| p3.2xlarge | 1 | 16 GiB | 8 | 61 GiB | Até 10 Gbps |
| p3.8xlarge | 4 | 64 GiB | 32 | 244 GiB | 10 Gbps |
| p3.16xlarge | 8 | 128 GiB | 64 | 488 GiB | 25 Gbps |
| p3dn.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 100 Gbps |
| p4d.24xlarge | 8 | 320 GiB | 96 | 1152 GiB | 400 Gbps |
| p4de.24xlarge | 8 | 640 GiB | 96 | 1152 GiB | 400 Gbps |
| p5.48xlarge | 8 | 640 GiB | 192 | 2 TiB | 3200 Gbps |
| p5e.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbps |
| p5en.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbps |
| p6-b200.48xlarge | 8 | 1440 GiB | 192 | 2 TiB | 100 Gbps |
| trn1.2xlarge | 1 | 32 GiB | 8 | 32 GiB | Até 12,5 Gbps |
| trn1.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 800 Gbps |
| trn1n.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 1600 Gbps |
| trn2.48xlarge | 16 | 1,5 TiB | 192 | 2 TiB | 3,2 Tbps |
| inf1.xlarge | 1 | 8 GiB | 4 | 8 GiB | Até 25 Gbps |
| inf1.2xlarge | 1 | 8 GiB | 8 | 16 GiB | Até 25 Gbps |
| inf1.6xlarge | 4 | 32 GiB | 24 | 48 GiB | 25 Gbps |
| inf1.24xlarge | 16 | 128 GiB | 96 | 192 GiB | 100 Gbps |
| inf2.xlarge | 1 | 32 GiB | 4 | 16 GiB | Até 15 Gbps |
| inf2.8xlarge | 1 | 32 GiB | 32 | 128 GiB | Até 25 Gbps |
| inf2.24xlarge | 6 | 192 GiB | 96 | 384 GiB | 50 Gbps |
| inf2.48xlarge | 12 | 384 GiB | 192 | 768 GiB | 100 Gbps |
| dl1.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 400 Gbps |
| dl2q.24xlarge | 8 | 128 GiB | 96 | 768 GiB | 100 Gbps |
**nota**
Para trabalhos de GPU, AWS Batch só oferece suporte a tipos de instância que tenham GPUs NVIDIA. Por exemplo, a família [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances) não é compatível com o agendamento de GPU. Você ainda pode usar [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)on AWS Batch definindo somente os requisitos de vcpu e memória na definição do trabalho e, em seguida, acessando as GPUs hospedeiras diretamente por meio da personalização em um [modelo de lançamento do Amazon EC2, dados do usuário com](launch-templates.md#lt-user-data.title) uma AMI otimizada para computação do Amazon ECS ou Amazon EKS, ou uma AMI personalizada para usar a AMD. GPUs
Os tipos de instância que usam uma ARM64 arquitetura são compatíveis com trabalhos de GPU em dados personalizados AMIs fornecidos ao usuário AWS Batch ou no Amazon EC2 para GPUs acessá-los por meio de código e configurações personalizados. Por exemplo, a família de instâncias [https://aws.amazon.com/ec2/instance-types/g5g/](https://aws.amazon.com/ec2/instance-types/g5g/).
O parâmetro [ResourceRequirements](job_definition_parameters.md#ContainerProperties-resourceRequirements) para a definição do trabalho especifica o número de tarefas a GPUs serem fixadas no contêiner. Esse número de GPUs não está disponível para nenhum outro trabalho executado nessa instância durante esse trabalho. Todos os tipos de instâncias em um ambiente computacional que executem trabalhos de GPU devem ser das famílias de instâncias `p6`, `p3`, `p4`, `p5`, `g3`, `g3s`, `g4`, `g5` ou `g6`. Se isso não for feito, um trabalho de GPU poderá ficar preso no status `RUNNABLE`.
Os trabalhos que não usam o GPUs podem ser executados em instâncias de GPU. No entanto, eles podem custar mais para serem executados nas instâncias de GPU do que em instâncias semelhantes sem GPU. A depender da vCPU específica, da memória e do tempo necessário, essas tarefas que não são de GPU podem bloquear a execução de tarefas de GPU.
**Topics**
+ [Criar um cluster do Kubernetes baseado em GPU no Amazon EKS](create-gpu-cluster-eks.md)
+ [Criar uma definição de trabalho de GPU do Amazon EKS](create-eks-gpu-job-definition.md)
+ [Executar um trabalho de GPU em seu Cluster do Amazon EKS](run-gpu-job-eks-cluster.md)
# Criar um cluster do Kubernetes baseado em GPU no Amazon EKS
Antes de criar um cluster do Kubernetes baseado em GPU no Amazon EKS, você deve ter concluído as etapas em [Começando a usar AWS Batch no Amazon EKS](getting-started-eks.md). Além disso, considere também o seguinte:
+ AWS Batch oferece suporte a tipos de instância com a NVIDIA GPUs.
+ Por padrão, AWS Batch seleciona a AMI acelerada do Amazon EKS com a Kubernetes versão que corresponde à versão do plano de controle do cluster do Amazon EKS.
```
$ cat < ./batch-eks-gpu-ce.json
{
"computeEnvironmentName": "My-Eks-GPU-CE1",
"type": "MANAGED",
"state": "ENABLED",
"eksConfiguration": {
"eksClusterArn": "arn:aws:eks:::cluster/",
"kubernetesNamespace": "my-aws-batch-namespace"
},
"computeResources": {
"type": "EC2",
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"minvCpus": 0,
"maxvCpus": 1024,
"instanceTypes": [
"p3dn.24xlarge",
"p4d.24xlarge"
],
"subnets": [
""
],
"securityGroupIds": [
""
],
"instanceRole": ""
}
}
EOF
$ aws batch create-compute-environment --cli-input-json file://./batch-eks-gpu-ce.json
```
AWS Batch não gerencia o plug-in do dispositivo NVIDIA GPU em seu nome. Você deve instalar esse plug-in em seu cluster Amazon EKS e permitir que ele atinja os AWS Batch nós. Para obter mais informações, consulte [Habilitando o GPU Support em Kubernetes](https://github.com/NVIDIA/k8s-device-plugin#enabling-gpu-support-in-kubernetes) on. GitHub
Para configurar o plug-in do NVIDIA dispositivo (`DaemonSet`) para direcionar os AWS Batch nós, execute os comandos a seguir.
```
# pull nvidia daemonset spec
$ curl -O https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.12.2/nvidia-device-plugin.yml
# using your favorite editor, add Batch node toleration
# this will allow the DaemonSet to run on Batch nodes
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
$ kubectl apply -f nvidia-device-plugin.yml
```
Não recomendamos que você misture workloads baseadas em computação (CPU e memória) com workloads baseados em GPU nos mesmos pares de ambiente de computação e fila de trabalhos. Isso ocorre porque os trabalhos de computação podem usar a capacidade da GPU.
Para anexar filas de trabalhos, execute os comandos a seguir.
```
$ cat < ./batch-eks-gpu-jq.json
{
"jobQueueName": "My-Eks-GPU-JQ1",
"priority": 10,
"computeEnvironmentOrder": [
{
"order": 1,
"computeEnvironment": "My-Eks-GPU-CE1"
}
]
}
EOF
$ aws batch create-job-queue --cli-input-json file://./batch-eks-gpu-jq.json
```
# Criar uma definição de trabalho de GPU do Amazon EKS
Somente o `nvidia.com/gpu` é compatível no momento, e o valor do recurso definido deve ser um número inteiro. Não é possível usar frações da GPU. Para obter mais informações, consulte [Programação GPUs](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) na *Kubernetesdocumentação*.
Para registrar uma definição de trabalho de GPU para o Amazon EKS, execute os seguintes comandos.
```
$ cat < ./batch-eks-gpu-jd.json
{
"jobDefinitionName": "MyGPUJobOnEks_Smi",
"type": "container",
"eksProperties": {
"podProperties": {
"hostNetwork": true,
"containers": [
{
"image": "nvcr.io/nvidia/cuda:10.2-runtime-centos7",
"command": ["nvidia-smi"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi",
"nvidia.com/gpu": "1"
}
}
}
]
}
}
}
EOF
$ aws batch register-job-definition --cli-input-json file://./batch-eks-gpu-jd.json
```
# Executar um trabalho de GPU em seu Cluster do Amazon EKS
O recurso de GPU não é compactável. AWS Batch **cria uma especificação de pod para trabalhos de GPU em que o valor da **solicitação** é igual ao valor dos limites.** Isso é um requisito do Kubernetes.
Para enviar um trabalho de GPU, use os comandos a seguir.
```
$ aws batch submit-job --job-queue My-Eks-GPU-JQ1 --job-definition MyGPUJobOnEks_Smi --job-name My-Eks-GPU-Job
# locate information that can help debug or find logs (if using Amazon CloudWatch Logs with Fluent Bit)
$ aws batch describe-jobs --job | jq '.jobs[].eksProperties.podProperties | {podName, nodeName}'
{
"podName": "aws-batch.f3d697c4-3bb5-3955-aa6c-977fcf1cb0ca",
"nodeName": "ip-192-168-59-101.ec2.internal"
}
```
# Exibir AWS Batch trabalhos em uma fila de trabalhos
Você pode visualizar e filtrar seus trabalhos no AWS Batch. Esse atributo oferece uma opção para visualizar uma fila de trabalho existente e filtrar seus trabalhos por uma das três opções.
A pesquisa e o filtro são capazes de recuperar trabalhos que não estão em um estado terminal (`SUCCEEDED` ou `FAILED`). Quando o estado de um trabalho estiver `SUCCEEDED` ou `FAILED` você deverá ser capaz de recuperá-lo por até sete dias. Você ainda pode ver os EventBridge registros de um trabalho CloudWatch ou da Amazon.
Use esse procedimento para listar todos os trabalhos em uma fila de trabalhos no AWS Batch console. Opcionalmente, use o campo **Filtrar resultados** para restringir os resultados com base nos critérios que você especificar.
1. Navegue até o [console do AWS Batch](https://console.aws.amazon.com/batch/home).
1. No painel de navegação, escolha **Tarefas**.
1. Expanda a lista suspensa **Fila de trabalhos** e escolha a fila de trabalhos na qual você deseja pesquisar.
**nota**
É possível pesquisar trabalhos em apenas uma fila de trabalhos por vez.
1. No campo **Filtrar resultados**, insira palavras-chave para incluir nos resultados. Você pode usar esse campo para filtrar por **nome do trabalho**, **status** ou **ID do trabalho**. Dependendo da propriedade, pode haver operadores adicionais, como igual (=) ou contém (:), que você deve definir.
**nota**
SageMaker **As filas de trabalhos de treinamento suportam somente a filtragem por **nome do trabalho e ID do** trabalho**
1. Selecione a opção **Pesquisar**.
# AWS Batch Procure empregos em uma fila de empregos
Você pode pesquisar e filtrar suas vagas AWS Batch usando a Pesquisa de vagas. Esse atributo fornece uma opção para pesquisar em uma fila de trabalhos existente e filtrar seus trabalhos.
A pesquisa e o filtro são capazes de recuperar trabalhos que não estão em um estado terminal (`SUCCEEDED` ou `FAILED`). Quando o estado de um trabalho estiver `SUCCEEDED` ou `FAILED` você deverá ser capaz de recuperá-lo por até sete dias. Você ainda pode ver os EventBridge registros de um trabalho CloudWatch ou da Amazon.
Para pesquisar usando vários critérios simultaneamente, use o atributo **Pesquisa avançada**. Por exemplo, é possível incluir qualquer um ou todos os filtros a seguir: **Status**, **Intervalo de datas** e **Critérios adicionais** (como nome do trabalho, definição do trabalho ou ID do trabalho).
## Pesquisar AWS Batch empregos (AWS Console)
Use esse procedimento para pesquisar os trabalhos em uma fila de trabalhos no AWS Batch console.
1. Navegue até o [console do AWS Batch](https://console.aws.amazon.com/batch/home).
1. No painel de navegação, escolha **Tarefas**.
1. Ative a **Pesquisa avançada**.
1. Expanda a lista suspensa **Fila de trabalhos** e escolha a fila de trabalhos na qual você deseja pesquisar.
**nota**
É possível pesquisar trabalhos em apenas uma fila de trabalhos por vez.
1. Para **Opções de pesquisa**:
1. Na lista suspensa **Status**, você pode escolher um ou mais status para filtrar. Para obter mais informações, consulte [Estados do trabalho](job_states.md) e [Status de serviço do trabalho](service-job-status.md).
**nota**
Os pais dos trabalhos de matriz são atualizados para `PENDING` quando qualquer trabalho secundário é atualizado `RUNNABLE` e permanecem no `PENDING` status enquanto os trabalhos secundários estão em execução. Para visualizar esses trabalhos, filtre por `PENDING` status até que todos os trabalhos secundários atinjam um estado terminal.
1. Escolha o **Intervalo de datas** para filtrar os resultados com base em um intervalo de data e hora.
+ Escolha o **modo Relativo** para pesquisar trabalhos com uma data de criação dentro de um intervalo de tempo contado para trás a partir da data e hora atuais.
+ Escolha o **Modo absoluto** para pesquisar trabalhos com uma data de criação em um intervalo de data e hora especificado por você.
1. No campo **Critérios adicionais**, insira palavras-chave a serem incluídas nos resultados da pesquisa. Por exemplo, você pode usar esse campo para pesquisar por **nome do trabalho**, **definição do trabalho**, **ID do trabalho** ou **identificador de compartilhamento**. Dependendo da propriedade, pode haver operadores adicionais, como igual (=) ou contém (:), que você deve definir.
**nota**
SageMaker **As filas de trabalhos de treinamento suportam somente a filtragem por **nome do trabalho e ID do** trabalho**
**nota**
Ao filtrar por **identificador de compartilhamento**, você também pode especificar o status do trabalho. Essa é uma exceção à restrição em que outros filtros excluem a filtragem do status do trabalho.
1. Selecione a opção **Pesquisar**.
## Pesquisar e filtrar AWS Batch vagas (AWS CLI)
Use esse procedimento para listar todos os trabalhos em uma fila de trabalhos com o AWS CLI. Opcionalmente, use o parâmetro **-filters** para restringir os resultados com base nos critérios que você especificar.
------
#### [ Search job queue (AWS CLI) ]
Você pode usar o comando [list-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-jobs.html) para pesquisar e filtrar uma fila de trabalhos.
Por exemplo, você pode pesquisar uma fila de trabalhos com base no nome do trabalho:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=JOB_NAME,values="my-job"
```
Filtrar trabalhos por identificador de compartilhamento:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Ao filtrar por identificador de compartilhamento, você pode incluir o status do trabalho:
```
aws batch list-jobs \
--job-queue my-job-queue \
--job-status RUNNING \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
No comando anterior, faça as seguintes alterações:
+ *my-job-queue*Substitua pelo nome da sua fila de trabalhos.
+ *my-job*Substitua pelo nome do seu trabalho.
+ *my-share*Substitua pelo identificador de compartilhamento pelo qual você deseja filtrar.
------
#### [ Search service job queue (AWS CLI) ]
Você pode usar o [list-service-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-service-jobs.html)comando para pesquisar e filtrar uma fila de trabalhos de serviço.
Por exemplo, você pode pesquisar uma fila de trabalhos de serviço com base no nome do trabalho:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=JOB_NAME,values="my-sm-job"
```
Filtrar trabalhos de serviço por identificador de compartilhamento:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
No comando anterior, faça as seguintes alterações:
+ *my-sm-queue*Substitua pelo nome da sua fila de trabalhos de serviço.
+ *my-sm-job*Substitua pelo nome do seu trabalho de serviço.
+ *my-share*Substitua pelo identificador de compartilhamento pelo qual você deseja filtrar.
------
# Modos de rede para AWS Batch trabalhos
A tabela a seguir descreve os modos de rede e o uso típico dos tipos de AWS Batch trabalho. Consulte os links na coluna “Tipo de trabalho” para obter mais detalhes sobre considerações e comportamentos.
| Tipo de tarefa | Modos de rede compatíveis | Uso típico |
| --- | --- | --- |
| [Trabalho simples ECS-EC2](jobs.md) | host | Usado para workloads em lote mais escaláveis e embaraçosamente paralelos que exigem apenas a saída para o vpc definido no ambiente de computação. |
| [Trabalho paralelo de vários nós ECS-EC2](multi-node-parallel-jobs.md) | awsvpc | Usado para workloads distribuídos de vários hosts (nós) fortemente acoplados, modelados como um único trabalho com comunicações coordenadas entre os nós de tarefa. |
| [Trabalho simples ECS-Fargate](when-to-use-fargate.md) | awsvpc | Verdadeiramente em tecnologia sem servidor para workloads em lotes embaraçosamente paralelas. Normalmente o menor TCO e o maior modelo de trabalho de isolamento de contêineres. |
| [Trabalho simples EKS-EC2](eks-jobs.md) | host e pod | Usado para workloads em lotes altamente escaláveis e embaraçosamente paralelos que exigem apenas a saída para a vpc definida no ambiente de computação. O padrão é rede de host. |
| [Trabalho paralelo de vários nós EKS-EC2](mnp-eks-jobs.md) | host e pod | Usado para workloads distribuídos de vários hosts (nós) fortemente acoplados, modelados como um único trabalho com comunicações coordenadas entre os nós de pod. O padrão é rede de host. |
# Exibir registros de AWS Batch trabalhos em CloudWatch Registros
Você pode [configurar seus AWS Batch trabalhos](using_cloudwatch_logs.md#using_cloudwatch_logs.title) para enviar informações de registro para o Amazon CloudWatch Logs. Assim, você pode visualizar logs diferentes de trabalhos em um local conveniente. Para obter mais informações, consulte [Usando CloudWatch registros com AWS Batch](using_cloudwatch_logs.md).
Você também pode usar **os registros de trabalhos** no AWS Batch console para monitorar ou solucionar problemas de um AWS Batch trabalho.
1. Abra o [AWS Batch Console](https://console.aws.amazon.com/batch/home).
1. Escolha **Trabalhos**. Para obter informações mais detalhadas sobre como classificar e filtrar trabalhos na fila de trabalhos, consulte [Exibir AWS Batch trabalhos em uma fila de trabalhos](view-jobs.md) e [Pesquisar por trabalhos em uma fila de trabalho](searching-filtering-jobs.md)
1. Em **Fila de Trabalhos**, escolha a fila de trabalhos desejada.
**dica**
Se houver vários trabalhos na fila de trabalhos, você poderá ativar **Pesquisa** e Filtragem para encontrar um trabalho mais rapidamente. Para obter mais informações, consulte [AWS Batch Procure empregos em uma fila de empregos](searching-filtering-jobs.md).
1. Em **Status**, escolha os status do trabalho que você deseja exibir.
1. Escolha o trabalho que você deseja e a página **Detalhes** será aberta.
1. Na página **Detalhes**, role para baixo até **Nome do fluxo de logs** e escolha o link. O link abre a página Amazon CloudWatch Logs do trabalho.
1. (Opcional) Se esta for a primeira vez que você visualiza os logs, poderá ser solicitada uma autorização.
Para **Autorização necessária****OK**, insira e escolha **Autorizar** para aceitar CloudWatch cobranças da Amazon.
**nota**
Para revogar sua autorização para CloudWatch cobranças:
No painel de navegação esquerdo, escolha **Permissões**.
Em **Logs de Trabalho**, escolha **Editar**.
Desmarque a caixa de CloudWatch seleção **Autorizar o uso do Batch**.
Escolha **Salvar alterações**.
# Revise as informações do AWS Batch trabalho
Você pode analisar as informações sobre o trabalho do AWS Batch , como status, definição de trabalho e informações do contêiner.
1. Abra o [AWS Batch Console](https://console.aws.amazon.com/batch/home).
1. Escolha **Trabalhos**.
1. Em **Fila de Trabalhos**, escolha a fila de trabalhos desejada.
**dica**
Se houver vários trabalhos na fila de trabalhos, ative **Pesquisa e filtragem** para encontrar um trabalho mais rapidamente. Para obter mais informações, consulte [AWS Batch Procure empregos em uma fila de empregos](searching-filtering-jobs.md).
1. Escolha o trabalho desejado.
**nota**
Você também pode usar o AWS Command Line Interface (AWS CLI) para ver detalhes sobre um AWS Batch trabalho. Para obter mais informações, consulte [describe-jobs](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/batch/describe-jobs.html) na [Referência de Comandos AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).