Trabalhos em Aplicativos de Contêiner do Azure

Os jobs Azure Container Apps permitem-lhe executar tarefas containerizadas que duram um período finito e depois param. Você pode usar trabalhos para executar tarefas como processamento de dados, aprendizado de máquina ou qualquer cenário em que o processamento sob demanda seja necessário.

Os aplicativos e trabalhos de contêiner são executados no mesmo ambiente, permitindo que eles compartilhem recursos como rede e registro.

Comparar aplicações e tarefas de contêiner

Há dois tipos de recursos de computação nos Aplicativos de Contêiner do Azure: aplicativos e trabalhos.

As aplicações são serviços que são executados continuamente. Se um contêiner em um aplicativo falhar, ele será reiniciado automaticamente. Exemplos de aplicativos incluem APIs HTTP, aplicativos Web e serviços em segundo plano que processam continuamente a entrada.

Jobs são tarefas que começam, têm uma duração finita e param quando são concluídas. Cada execução de um trabalho normalmente executa uma única unidade de trabalho. As execuções de trabalho são iniciadas manualmente, em um cronograma ou em resposta a eventos. Exemplos de trabalhos incluem processos em lote que são executados sob demanda e tarefas agendadas.

Cenários de exemplo

A tabela a seguir compara cenários comuns para aplicativos e trabalhos:

Contentor Recursos computacionais Notas
Um servidor HTTP que serve conteúdo da Web e solicitações de API Aplicação Configure uma regra de escala HTTP.
Um processo que gera relatórios financeiros todas as noites Tarefa Use o tipo de trabalho Schedule e configure uma expressão cron.
Um serviço em execução contínua que processa mensagens de uma fila do Barramento de Serviço do Azure Aplicação Configure uma regra de escala personalizada.
Um trabalho que processa uma única mensagem ou um pequeno lote de mensagens de uma fila Azure e depois para Tarefa Use o tipo de trabalho Evento e configure uma regra de escala personalizada para disparar execuções de trabalho quando houver mensagens na fila.
Uma tarefa em segundo plano que é ativada sob demanda e termina quando concluída Tarefa Use o tipo de trabalho Manual e inicie execuções manual ou programaticamente usando uma API.
Um executor de Ações do GitHub auto-hospedado ou um agente do Azure Pipelines Tarefa Use o tipo de trabalho Evento e configure uma regra de escala do GitHub Actions ou Azure Pipelines.
Um aplicativo do Funções do Azure Aplicação Implante o Funções do Azure em aplicativos de contêiner.
Uma aplicação orientada a eventos que utiliza o Azure WebJobs SDK Aplicação Configure uma regra de escala para cada fonte de evento.

Conceitos

Um ambiente de Aplicações de Contentores é uma fronteira segura em torno de uma ou mais aplicações e tarefas de contentores. Seguem-se alguns conceitos-chave:

  • Job: Um job define a configuração padrão utilizada para cada execução de um job. A configuração inclui a imagem de contêiner a ser usada, os recursos a serem alocados e o comando a ser executado.
  • Execução do trabalho: Uma execução de trabalho é uma única execução de uma tarefa que é acionada manualmente, num calendário ou em resposta a um evento.
  • Réplica de trabalho: uma execução de trabalho típica executa uma réplica definida pela configuração do trabalho. Em cenários avançados, a execução de um trabalho pode executar várias réplicas.

Diagrama que fornece uma visão geral dos jobs do Container Apps.

Permissões

Para iniciar um trabalho de aplicação container, a sua conta de utilizador ou principal de serviço precisa das permissões apropriadas. Considere os seguintes papéis:

  • Contribuidor de Tarefas do Container Apps: Concede permissões para criar e gerir tarefas.
  • Operador de Tarefas das Aplicações em Contentor: Permite ler, iniciar e parar tarefas.
  • Leitor de Monitorização (opcional): Permite visualizar dados de monitorização dos trabalhos.

Tanto as funções de Contribuidor de Tarefas das Aplicações em Contentores como de Operador de Tarefas das Aplicações em Contentores incluem a permissão universal Microsoft.App/jobs/*/action. Este caráter universal corresponde a Microsoft.App/jobs/listSecrets/action, pelo que ambas as funções concedem permissão para ler os valores secretos da tarefa em texto simples.

Se nenhum dos papéis corresponder ao acesso que queres conceder, cria um papel personalizado que liste apenas as ações de que precisas. Por exemplo, as seguintes ações permitem que um utilizador veja, inicie e pare tarefas sem usar o caráter universal Microsoft.App/jobs/*/action. Uma vez que este conjunto de regras inclui Microsoft.App/jobs/start/action, conceda-o apenas a identidades em que confia para utilizar os segredos da tarefa e as identidades geridas configuradas para estarem disponíveis para os respetivos contentores:

  • Microsoft.App/jobs/read
  • Microsoft.App/jobs/start/action
  • Microsoft.App/jobs/stop/action
  • Microsoft.App/jobs/stop/execution/action
  • Microsoft.App/jobs/executions/read
  • Microsoft.App/jobs/execution/read
  • Microsoft.App/managedEnvironments/read

Evite padrões de wildcard, como Microsoft.App/jobs/*/action numa definição de função personalizada. Este coringa concede todas as operações atuais e futuras que correspondam ao padrão, incluindo listSecrets.

Warning

A permissão para iniciar um trabalho pode conceder acesso aos segredos desse trabalho, mesmo que a função não inclua a ação listSecrets. A API REST Jobs - Start aceita um modelo de execução opcional que pode substituir as imagens dos contentores principal e de inicialização, os comandos e as variáveis de ambiente. Um utilizador que detém Microsoft.App/jobs/start/action e conhece o nome de um segredo pode referenciar esse segredo a partir de um contentor à sua escolha e ler o seu valor dentro do contentor. O contentor pode também usar qualquer identidade gerida que esteja configurada para lhe estar disponível. Conceda permissão para iniciar um trabalho apenas a identidades em que confie para usar os segredos do trabalho e as identidades geridas disponíveis.

Para mais informações, consulte Permissões para gestão de segredos e controlo de acesso baseado em funções no Azure.

Tipos de gatilho de trabalho

O tipo de gatilho de um trabalho determina como ele é iniciado. Os seguintes tipos de gatilho estão disponíveis:

  • Manual: Os trabalhos manuais são acionados a pedido.
  • Agenda: Os trabalhos agendados são acionados em horários específicos e podem ser executados repetidamente.
  • Evento: Os trabalhos orientados por eventos são acionados por eventos, como uma mensagem que chega numa fila.

Trabalhos manuais

Os trabalhos manuais são acionados sob demanda através da CLI do Azure, do portal Azure ou de um pedido à API do Azure Resource Manager.

Exemplos de trabalhos manuais incluem:

  • Uma tarefa de processamento único, como migrar dados de um sistema para outro.
  • Um site de comércio eletrónico a funcionar como uma aplicação de contentores inicia uma execução de trabalho para processar inventário quando uma encomenda é efetuada.

Para criar um trabalho manual, use o tipo de trabalho Manual.

Para criar um trabalho manual usando a CLI do Azure, use o az containerapp job create comando. O exemplo a seguir cria um trabalho manual nomeado my-job em um grupo de recursos chamado my-resource-group e um ambiente Container Apps chamado my-environment:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Manual" \
    --replica-timeout 1800 \
    --replica-retry-limit 0 \
    --replica-completion-count 1 \ 
    --parallelism 1 \ 
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi"

A imagem mcr.microsoft.com/k8se/quickstart-jobs:latest é uma imagem pública de um contentor de exemplo que executa uma tarefa: aguarda alguns segundos, imprime uma mensagem na consola e, em seguida, pára. Para informações sobre autenticação e utilização de uma imagem privada de contentor, consulte Containers.

O comando anterior apenas cria o trabalho. Para iniciar uma execução de trabalho, consulte Iniciar uma execução de trabalho sob demanda.

Tarefas agendadas

Para criar um trabalho agendado, use o tipo Schedulede trabalho .

Os trabalhos de aplicativos de contêiner usam expressões cron para definir agendas. Suportam o formato padrão de expressão cron com cinco campos para minuto, hora, dia do mês, mês e dia da semana. Aqui estão alguns exemplos de expressões cron:

Expressão Descrição
*/5 * * * * Funciona a cada 5 minutos.
0 */2 * * * Funciona a cada duas horas.
0 0 * * * Funciona todos os dias à meia-noite.
0 0 * * 0 Funciona todos os domingos à meia-noite.
0 0 1 * * Funciona no primeiro dia de cada mês, à meia-noite.

As expressões Cron em trabalhos agendados são avaliadas em Tempo Universal Coordenado (UTC).

Para criar um trabalho agendado usando a CLI do Azure, use o az containerapp job create comando. O exemplo a seguir cria um trabalho agendado nomeado my-job em um grupo de recursos chamado my-resource-group e um ambiente Container Apps chamado my-environment:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 \
    --replica-retry-limit 0 \ 
    --parallelism 1 \
    --replica-completion-count 1 \
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --cron-expression "*/1 * * * *"

A imagem mcr.microsoft.com/k8se/quickstart-jobs:latest é uma imagem pública de um contentor de exemplo que executa uma tarefa: aguarda alguns segundos, imprime uma mensagem na consola e, em seguida, pára. Para informações sobre autenticação e utilização de uma imagem privada de contentor, consulte Containers.

A expressão */1 * * * * cron executa o trabalho a cada minuto.

Trabalhos orientados a eventos

Eventos de escaladores personalizados suportados acionam trabalhos controlados por eventos. Exemplos de trabalhos orientados para eventos incluem:

Aplicações de contentores e tarefas orientadas a eventos usam escaladores KEDA. Ambos avaliam regras de dimensionamento em um intervalo de sondagem para medir o volume de eventos de uma fonte de eventos, mas a maneira como usam os resultados é diferente.

Numa aplicação, cada réplica processa continuamente eventos, e uma regra de escalonamento determina o número de réplicas a executar para satisfazer a procura. Em trabalhos controlados por eventos, cada execução de trabalho normalmente processa um único evento, e uma regra de dimensionamento determina o número de execuções de trabalho a serem executadas.

Use trabalhos quando cada evento exigir uma nova instância do contentor com recursos dedicados ou precisar ser executado por um longo período de tempo. Os trabalhos orientados a eventos são conceitualmente semelhantes aos trabalhos de dimensionamento do KEDA.

Para criar um trabalho controlado por eventos, use o tipo de trabalho Event.

Para criar um trabalho orientado a eventos usando a CLI do Azure, use o az containerapp job create comando. O exemplo a seguir cria um trabalho controlado por eventos nomeado my-job em um grupo de recursos chamado my-resource-group e um ambiente Container Apps chamado my-environment:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Event" \
    --replica-timeout 1800 \
    --image "docker.io/myuser/my-event-driven-job:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --min-executions "0" \
    --max-executions "10" \
    --scale-rule-name "queue" \
    --scale-rule-type "azure-queue" \
    --scale-rule-metadata "accountName=mystorage" "queueName=myqueue" "queueLength=1" \
    --scale-rule-auth "connection=connection-string-secret" \
    --secrets "connection-string-secret=<QUEUE_CONNECTION_STRING>"

O exemplo configura uma regra de escala de fila do Armazenamento do Azure.

Para obter um tutorial completo, consulte Implantar um trabalho controlado por eventos.

Iniciar uma execução de trabalho sob demanda

Para qualquer tipo de trabalho, você pode iniciar uma execução de trabalho sob demanda.

Para iniciar a execução de um trabalho usando a CLI do Azure, use o az containerapp job start comando. O exemplo a seguir inicia uma execução de um trabalho nomeado my-job em um grupo de recursos chamado my-resource-group:

az containerapp job start --name "my-job" --resource-group "my-resource-group"

Ao iniciar a execução de um trabalho, você pode optar por substituir a configuração do trabalho. Por exemplo, você pode substituir uma variável de ambiente ou o comando de inicialização para executar o mesmo trabalho com entradas diferentes. A configuração substituída é usada apenas para a execução atual e não altera a configuração do trabalho.

Quando sobrescreves uma configuração, toda a configuração do modelo do trabalho é substituída pela nova configuração. Certifique-se de que a nova configuração inclui todas as configurações necessárias.

Warning

Uma identidade que pode iniciar um trabalho pode usar um modelo de execução para referenciar segredos de trabalho cujos nomes conhece e usar identidades geridas configuradas para estarem disponíveis para o contentor. Para obter mais informações, consulte Permissões.

Para substituir a configuração do job ao iniciar uma execução, use o comando az containerapp job start e passe um ficheiro YAML contendo o modelo para usar na execução. O exemplo a seguir inicia uma execução de um trabalho nomeado my-job em um grupo de recursos chamado my-resource-group.

Recupere a configuração atual do trabalho com o az containerapp job show comando e guarde o modelo num ficheiro chamado my-job-template.yaml:

az containerapp job show --name "my-job" --resource-group "my-resource-group" --query "properties.template" --output yaml > my-job-template.yaml

A --query "properties.template" opção retorna apenas a configuração do modelo do trabalho.

Edite o my-job-template.yaml arquivo para substituir a configuração do trabalho. Por exemplo, para substituir as variáveis de ambiente, modifique a env seção:

containers:
- name: print-hello
  image: ubuntu
  resources:
    cpu: 1
    memory: 2Gi
  env:
  - name: MY_NAME
    value: Azure Container Apps jobs
  args:
  - /bin/bash
  - -c
  - echo "Hello, $MY_NAME!"

Inicie o trabalho usando o modelo:

az containerapp job start --name "my-job" --resource-group "my-resource-group" \
    --yaml my-job-template.yaml

Obter histórico de execução de trabalhos

Cada tarefa de Aplicações em Contêiner mantém um histórico das execuções recentes da tarefa.

Para obter os estados das execuções de trabalhos usando a CLI do Azure, use o az containerapp job execution list comando. O exemplo a seguir retorna o status da execução mais recente de um trabalho nomeado my-job em um grupo de recursos chamado my-resource-group:

az containerapp job execution list --name "my-job" --resource-group "my-resource-group"

O histórico de execução de trabalhos agendados e baseados em eventos é limitado às 100 execuções de trabalho bem-sucedidas e com falha mais recentes.

Para listar todas as execuções de um trabalho ou obter uma saída detalhada de um trabalho, consulte o provedor de logs configurado para seu ambiente de Aplicativos de Contêiner.

Configuração avançada de tarefas

Os trabalhos de Aplicativos de Contêiner oferecem suporte a opções de configuração avançadas, como configurações de contêiner, tentativas, tempos limite e paralelismo.

Definições de contentor

As configurações de contêiner definem os contêineres a serem executados em cada réplica de uma execução de trabalho. Eles incluem variáveis de ambiente, segredos e limites de recursos. Para obter mais informações, consulte Contêineres. A execução de vários contêineres em um único trabalho é um cenário avançado. A maioria dos trabalhos executa um único contêiner.

Definições da tarefa

A tabela a seguir inclui as configurações de trabalho que você pode definir:

Configuração Propriedade do Azure Resource Manager Parâmetro CLI Descrição
Tipo de trabalho triggerType --trigger-type O tipo de trabalho (Manual, Schedule, ou Event).
Tempo limite da réplica replicaTimeout --replica-timeout O tempo máximo, em segundos, para aguardar a conclusão de uma réplica.
Intervalo de consulta pollingInterval --polling-interval O tempo em segundos de espera entre as sondagens para eventos. O padrão é 30 segundos.
Limite de tentativas de réplica replicaRetryLimit --replica-retry-limit O número máximo de vezes para repetir tentativas numa réplica com falha. Para falhar uma réplica sem tentar novamente, defina o valor como 0. A replicaTimeout configuração tem prioridade se expirar antes de todas as tentativas ocorrerem.
Paralelismo parallelism --parallelism O número de réplicas a serem executadas por cada execução. Para a maioria dos trabalhos, defina o valor como 1.
Contagem de réplicas concluídas replicaCompletionCount --replica-completion-count O número de réplicas a serem concluídas com êxito para que a execução seja bem-sucedida. A maioria é igual ou menor que o paralelismo. Para a maioria dos trabalhos, defina o valor como 1.

Trabalhos de longa duração

Observação

A manutenção da plataforma, incluindo atualizações de segurança de rotina e melhorias, pode interromper réplicas de tarefas de execução prolongada. Defina o limite de repetições da réplica para, no mínimo, 1, e conceba a sua carga de trabalho para processamento pelo menos uma vez, de modo a que as novas tentativas possam concluir o trabalho em segurança.

Exemplo

O exemplo a seguir cria um trabalho com opções de configuração avançadas:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 --replica-retry-limit 3 --replica-completion-count 5 --parallelism 5 \
    --image "myregistry.azurecr.io/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --command "/startup.sh" \
    --env-vars "MY_ENV_VAR=my-value" \
    --cron-expression "0 0 * * *"  \
    --registry-server "myregistry.azurecr.io" \
    --registry-username "myregistry" \
    --registry-password "myregistrypassword"

Rede de contactos profissionais e comunicação entre aplicações

Quando um pod de trabalho inicia, os contentores sidecar (como o proxy Envoy) estão garantidos de estar prontos antes de o contentor principal começar a ser executado. Isto garante que as chamadas entre apps feitas pelo trabalho no início tenham sucesso sem falhas de ligação.

Observação

Se a sua tarefa faz chamadas para outras aplicações de contêiner no arranque, não precisa adicionar lógica de nova tentativa para a prontidão inicial do sidecar. A plataforma trata disto automaticamente.

Restrições de emprego

As seguintes caraterísticas não são suportadas:

  • Dapr
  • Ingresso e recursos relacionados, como domínios personalizados e certificados SSL

Próximo passo