Trabajos de Azure Container Apps

Los trabajos de Azure Container Apps le permiten ejecutar tareas en contenedores que se ejecutan durante una duración finita y salen. Puede usar trabajos para realizar tareas como el procesamiento de datos, el aprendizaje automático o cualquier escenario en el que se requiera procesamiento a petición.

Las aplicaciones y trabajos de contenedor se ejecutan en el mismo entorno, lo que les permite compartir funcionalidades como las redes y el registro.

Comparación de aplicaciones y trabajos de contenedor

Hay dos tipos de recursos de proceso en Azure Container Apps: aplicaciones y trabajos.

Las aplicaciones son servicios que se ejecutan continuamente. Si se produce un error en un contenedor en una aplicación, se reinicia automáticamente. Algunos ejemplos de aplicaciones incluyen las API HTTP, las aplicaciones web y los servicios en segundo plano que procesan continuamente la entrada.

Los trabajos son tareas que se inician, se ejecutan durante un tiempo finito y salen cuando finalizan. Cada ejecución de un trabajo normalmente realiza una sola unidad de trabajo. Las ejecuciones de trabajos se inician manualmente, según una programación o en respuesta a eventos. Algunos ejemplos de trabajos incluyen los procesos por lotes que se ejecutan a petición y las tareas programadas.

Escenarios de ejemplo

En la tabla siguiente se comparan escenarios comunes para aplicaciones y trabajos:

Contenedor Recursos del proceso Notas
Un servidor HTTP que atiende las solicitudes de API y contenido web Aplicación Configurar una regla de escalado HTTP.
Proceso que genera informes financieros por la noche Trabajo Use el tipo de trabajo Programación y configure una expresión cron.
Un servicio de ejecución continua que procesa los mensajes de una cola de Azure Service Bus Aplicación Configure una regla de escalado personalizada.
Un trabajo que procesa un único mensaje o un pequeño lote de mensajes de una cola de Azure y sale Trabajo Use el tipo de trabajo Evento y configure una regla de escalado personalizada para desencadenar ejecuciones de trabajos cuando haya mensajes en la cola.
Una tarea en segundo plano que se desencadena a petición y se cierra cuando finaliza Trabajo Use el tipo de trabajo Manual e iniciar ejecuciones manualmente o mediante programación mediante una API.
Un ejecutor de Acciones de GitHub autohospedado o un agente de Azure Pipelines Trabajo Use el tipo de trabajo Evento y configure una regla de escalado de Acciones de GitHub o de Azure Pipelines.
Una aplicación Azure Functions Aplicación Implementar Azure Functions en Container Apps.
Una aplicación controlada por eventos mediante el SDK de Azure WebJobs Aplicación Configurar una regla de escalado para cada origen de eventos.

Conceptos

Un entorno de Azure Container Apps es un límite seguro alrededor de una o más trabajos y aplicaciones de contenedor. Los trabajos implican algunos conceptos clave:

  • Trabajo: Un trabajo define la configuración predeterminada que se usa para cada ejecución del trabajo. La configuración incluye la imagen de contenedor que se va a usar, los recursos que se van a asignar y el comando que se va a ejecutar.
  • Ejecución del trabajo: Una ejecución de trabajo es una sola ejecución de un trabajo que se desencadena manualmente, según una programación o en respuesta a un evento.
  • Réplica de trabajo: Una ejecución típica del trabajo ejecuta una réplica definida por la configuración del trabajo. En escenarios avanzados, una ejecución de trabajos puede ejecutar varias réplicas.

Información general de trabajos de Azure Container Apps.

Tipos de desencadenador de trabajo

El tipo de desencadenador de un trabajo determina cómo se inicia el trabajo. Están disponibles los siguientes tipos de desencadenador:

  • Manual: los trabajos manuales se desencadenan a petición.
  • Programación: los trabajos programados se desencadenan en momentos específicos y se pueden ejecutar repetidamente.
  • Evento: los trabajos controlados por eventos se desencadenan mediante eventos, como un mensaje que llega a una cola.

Trabajos manuales

Los trabajos manuales se desencadenan a petición mediante la CLI de Azure, Azure Portal o una solicitud a la API de Azure Resource Manager.

Algunos ejemplos de trabajos manuales son:

  • Tareas que se procesan una vez, como la migración de datos de un sistema a otro.
  • Un sitio de comercio electrónico que se ejecuta como aplicación de contenedor inicia una ejecución de un trabajo para procesar el inventario cuando se realiza un pedido.

Para crear un trabajo manual, use el tipo de trabajo Manual.

Para crear un trabajo manual mediante la CLI de Azure, use el comando az containerapp job create. En el ejemplo siguiente, se crea un trabajo manual llamado my-job en un grupo de recursos llamado my-resource-group y un entorno de Container Apps llamado my-environment:

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

La imagen mcr.microsoft.com/k8se/quickstart-jobs:latest es una imagen de contenedor público de ejemplo que ejecuta un trabajo que espera unos segundos, imprime un mensaje en la consola y, a continuación, sale. Para autenticar y usar una imagen de contenedor privada, consulte Contenedores.

El comando anterior solo crea el trabajo. Para iniciar la ejecución de un trabajo, consulte Inicio de la ejecución de un trabajo a petición.

Scheduled jobs

Para crear un trabajo programado, use el tipo de trabajo Schedule.

Los trabajos de Container Apps usan expresiones CRON para definir programaciones. Admite el formato de expresión CRON estándar con cinco campos para minuto, hora, día del mes, mes y día de la semana. Los siguientes son algunos ejemplos de expresiones cron:

Expression Descripción
*/5 * * * * Se ejecuta cada 5 minutos.
0 */2 * * * Se ejecuta cada dos horas.
0 0 * * * Se ejecuta todos los días a medianoche.
0 0 * * 0 Se ejecuta todos los domingos a medianoche.
0 0 1 * * Se ejecuta el primer día de cada mes a medianoche.

Las expresiones cron de los trabajos programados se evalúan en Hora universal coordinada (UTC).

Para crear un trabajo programado mediante la CLI de Azure, use el comando az containerapp job create. En el ejemplo siguiente, se crea un trabajo programado llamado my-job en un grupo de recursos llamado my-resource-group y un entorno de Container Apps llamado my-environment:

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

La imagen mcr.microsoft.com/k8se/quickstart-jobs:latest es una imagen de contenedor público de ejemplo que ejecuta un trabajo que espera unos segundos, imprime un mensaje en la consola y, a continuación, sale. Para autenticar y usar una imagen de contenedor privada, consulte Contenedores.

La expresión cron */1 * * * * ejecuta el trabajo cada minuto.

Trabajos controlados por eventos

Los eventos de los escaladores personalizados admitidos desencadenan los trabajos controlados por eventos. Entre los trabajos controlados por eventos, se incluyen:

  • Un trabajo que se ejecuta cuando se agrega un nuevo mensaje a una cola, como Azure Service Bus, Kafka o RabbitMQ.
  • Un ejecutor de Acciones de GitHub autohospedado o un agente de Azure DevOps que se ejecuta cuando se pone en cola un nuevo trabajo en un flujo de trabajo o una canalización.

Las aplicaciones de contenedor y los trabajos controlados por eventos usan escaladores KEDA. Ambos evalúan las reglas de escalado en un intervalo de sondeo para medir el volumen de eventos de un origen de eventos, pero la forma en la que usan los resultados es diferente.

En una aplicación, cada réplica procesa continuamente eventos y una regla de escalado determina el número de réplicas que se ejecutarán para satisfacer la demanda. En los trabajos controlados por eventos, cada ejecución de trabajo normalmente procesa un único evento y una regla de escalado determina el número de ejecuciones de trabajos que se van a ejecutar.

Use trabajos cuando cada evento requiera una nueva instancia del contenedor con recursos dedicados o necesite ejecutarse durante mucho tiempo. Los trabajos controlados por eventos son conceptualmente similares a los trabajos de escalado de KEDA.

Para crear un trabajo controlado por eventos, use el tipo de trabajo Event.

Para crear un trabajo controlado por eventos mediante la CLI de Azure, use el comando az containerapp job create. En el ejemplo siguiente, se crea un trabajo controlado por eventos llamado my-job en un grupo de recursos llamado my-resource-group y un entorno de Container Apps llamado 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>"

En el ejemplo, se configura una regla de escalado de colas de Azure Storage.

Para ver un tutorial completo, consulte Implementación de un trabajo controlado por eventos.

Inicio de la ejecución de un trabajo a petición

Para cualquier tipo de trabajo, puede iniciar la ejecución de un trabajo a petición.

Para iniciar la ejecución de un trabajo mediante la CLI de Azure, use el comando az containerapp job start. En el ejemplo siguiente, se inicia una ejecución de un trabajo llamado my-job en un grupo de recursos llamado my-resource-group:

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

Al iniciar la ejecución de un trabajo, puede optar por invalidar la configuración del trabajo. Por ejemplo, puede invalidar una variable de entorno o el comando de inicio para ejecutar el mismo trabajo con entradas diferentes. La configuración invalidada solo se usa para la ejecución actual y no cambia la configuración del trabajo.

Importante

Al invalidar la configuración, la configuración completa de la plantilla del trabajo se reemplaza por la nueva configuración. Asegúrese de que la nueva configuración incluye todas las opciones necesarias.

Para invalidar la configuración del trabajo al iniciar una ejecución, use el comando az containerapp job start y pase un archivo YAML que contenga la plantilla que se va a usar para la ejecución. En el ejemplo siguiente, se inicia una ejecución de un trabajo llamado my-job en un grupo de recursos llamado my-resource-group.

Recupere la configuración actual del trabajo con el comando az containerapp job show y guarde la plantilla en un archivo denominado 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

La opción --query "properties.template" devuelve solo la configuración de la plantilla del trabajo.

Edite el archivo my-job-template.yaml para invalidar la configuración del trabajo. Por ejemplo, para invalidar las variables de entorno, modifique la sección env:

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 el trabajo mediante la plantilla:

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

Obtención del historial de ejecución de los trabajos

Cada trabajo de Container Apps mantiene un historial de ejecuciones de trabajos recientes.

Para obtener los estados de las ejecuciones de trabajos mediante la CLI de Azure, use el comando az containerapp job execution list. En el ejemplo siguiente, se devuelve el estado de la ejecución más reciente de un trabajo llamado my-job en un grupo de recursos llamado my-resource-group:

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

El historial de ejecución de trabajos programados y basados en eventos se limita a las 100 ejecuciones de trabajos correctas y con errores más recientes.

Para enumerar todas las ejecuciones de un trabajo o para obtener una salida detallada de un trabajo, consulte el proveedor de registros configurado para el entorno de Container Apps.

Configuración avanzada del trabajo

Los trabajos de Container Apps admiten opciones de configuración avanzadas, como la configuración del contenedor, los reintentos, los tiempos de espera y el paralelismo.

Configuración del contenedor

La configuración del contenedor define los contenedores que se van a ejecutar en cada réplica de la ejecución de un trabajo. Incluyen variables de entorno, secretos y límites de recursos. Para obtener más información, consulte Containers. La ejecución de varios contenedores en un solo trabajo es un escenario avanzado. La mayoría de los trabajos ejecutan un único contenedor.

Configuración del trabajo

En la tabla siguiente, se incluyen las opciones del trabajo que puede configurar:

Configuración Propiedad del Administrador de recursos de Azure Parámetro de la CLI Descripción
Tipo de trabajo triggerType --trigger-type Tipo de trabajo. (Manual, Schedule o Event)
Tiempo de espera de la réplica replicaTimeout --replica-timeout Tiempo máximo en segundos que se va a esperar a que finalice una réplica.
Intervalo de sondeo pollingInterval --polling-interval Tiempo en segundos que se espera entre el sondeo de eventos. El valor predeterminado es 30 segundos.
Límite de reintentos de la réplica replicaRetryLimit --replica-retry-limit Número máximo de veces que se reintenta una réplica con errores. Para producir un error en una réplica sin reintentar, establezca el valor en 0.
Paralelismo parallelism --parallelism Número de réplicas que se van a ejecutar por ejecución. Para la mayoría de los trabajos, establezca el valor en 1.
Recuento de finalización de réplicas replicaCompletionCount --replica-completion-count Número de réplicas que se van a completar correctamente para que la ejecución se realice correctamente. La mayoría es igual o menor que el paralelismo. Para la mayoría de los trabajos, establezca el valor en 1.

Ejemplo

En el ejemplo siguiente, se crea un trabajo con opciones de configuración avanzadas:

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"

Restricciones de trabajo

No se admiten las características siguientes:

  • Dapr
  • Entrada y características relacionadas, como dominios personalizados y certificados SSL

Pasos siguientes