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 de 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.
Permisos
Para iniciar un trabajo de aplicación de contenedor, se requieren los permisos adecuados. Asegúrese de que su cuenta de usuario o entidad de servicio tenga asignados los siguientes roles:
- Colaborador de Azure Container Apps: Permite permisos para crear y administrar aplicaciones y trabajos de contenedor.
- Lector de Azure Monitor (opcional): Habilita la visualización de datos de supervisión para trabajos.
- Rol personalizado: Para obtener permisos más pormenorizados, puede crear un rol personalizado con las siguientes acciones:
- Microsoft.App/containerApps/jobs/start/action
- Microsoft.App/containerApps/jobs/read
- Microsoft.App/containerApps/jobs/executions/read
Para más información sobre cómo asignar roles y permisos, consulte Control de acceso basado en roles de Azure.
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: Eventos, como un mensaje que llega a una cola, desencadena trabajos controlados por eventos.
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