Partager via


Travaux dans Azure Container Apps

Les travaux Azure Container Apps vous permettent d’exécuter des tâches conteneurisées qui s’exécutent pendant une durée limitée et s’arrêtent. Vous pouvez utiliser des travaux pour effectuer des tâches telles que le traitement des données, le machine learning ou tout scénario où un traitement à la demande est nécessaire.

Les applications conteneur et les travaux s’exécutent dans le même environnement, ce qui leur permet de partager des fonctionnalités comme la mise en réseau et la journalisation.

Comparer les applications conteneur et les travaux

Il existe deux types de ressources de calcul dans Azure Container Apps : les applications et les travaux.

Les applications sont des services qui s’exécutent en continu. Si un conteneur échoue dans une application, il redémarre automatiquement. Parmi les exemples d’applications, citons les API HTTP, les applications web et les services en arrière-plan qui traitent les entrées en continu.

Les travaux sont des tâches qui démarrent, s’exécutent pendant une durée limitée et s’arrêtent lorsqu’elles ont fini. Chaque exécution d’un travail effectue généralement une seule unité de travail. Les exécutions de travaux démarrent manuellement, selon une planification ou en réponse à des événements. Parmi les exemples de travaux, citons les processus par lots qui s’exécutent à la demande et les tâches planifiées.

Exemple de scénarios

Le tableau suivant compare les scénarios courants pour les applications et les travaux :

Conteneur Ressource de calcul Notes
Serveur HTTP qui fournit du contenu web et des requêtes d’API Application Configurez une règle de mise à l’échelle HTTP.
Processus qui génère des rapports financiers tous les soirs Travail Utilisez le type de travail Planification et configurez une expression cron.
Service en cours d’exécution continu qui traite les messages à partir d’une file d’attente Azure Service Bus Application Configurez une règle de mise à l’échelle personnalisée.
Tâche qui traite un seul message ou un petit lot de messages à partir d’une file d’attente Azure et quitte Travail Utilisez le type de travail Event et configurez une règle de mise à l’échelle personnalisée pour déclencher des exécutions de travaux lorsqu’il existe des messages dans la file d’attente.
Une tâche en arrière-plan qui est déclenchée à la demande et se termine lorsque vous avez terminé Travail Utilisez le type de travail manuel et démarrez les exécutions manuellement ou par programmation à l’aide d’une API.
Un exécuteur GitHub Actions auto-hébergé ou un agent Azure Pipelines Travail Utilisez le type de travail Event et configurez une règle de mise à l’échelle GitHub Actions ou Azure Pipelines .
Une application Azure Functions Application Déploiement d'Azure Functions dans Container Apps.
Application basée sur des événements à l’aide du Kit de développement logiciel (SDK) Azure WebJobs Application Configurez une règle de mise à l’échelle pour chaque source d’événement.

Concepts

Un environnement Container Apps est une limite sécurisée autour d’une ou plusieurs applications et travaux de conteneur. Les travaux impliquent quelques concepts clés :

  • Travail : un travail définit la configuration par défaut utilisée pour chaque exécution du travail. La configuration inclut l’image conteneur à utiliser, les ressources à allouer et la commande à exécuter.
  • Exécution du travail : une exécution de travail est une exécution unique d’un travail déclenché manuellement, selon une planification ou en réponse à un événement.
  • Réplica de travail : une exécution de travail classique exécute un réplica défini par la configuration du travail. Dans les scénarios avancés, une exécution de travail peut exécuter plusieurs réplicas.

Vue d’ensemble des tâches Azure Container Apps.

autorisations

Pour lancer un travail d’application conteneur, les autorisations appropriées sont nécessaires. Vérifiez que votre compte d’utilisateur ou principal de service dispose des rôles suivants :

  • Contributeur Azure Container Apps : accorde les autorisations nécessaires pour créer et gérer les applications et les travaux de conteneurs.
  • Lecteur Azure Monitor (facultatif) : permet la consultation des données de supervision des travaux.
  • Rôle personnalisé : pour disposer d’autorisations plus granulaires, vous pouvez créer un rôle personnalisé à l’aide des actions suivantes :
  • Microsoft.App/containerApps/jobs/start/action
  • Microsoft.App/containerApps/jobs/read
  • Microsoft.App/containerApps/jobs/executions/read

Pour plus d’informations sur l’attribution de rôles et d’autorisations, consultez Contrôle d’accès en fonction du rôle Azure.

Types de déclencheur de travail

Le type de déclencheur d’un travail détermine la façon dont le travail est démarré. Les types de déclencheur suivants sont disponibles :

  • Manuel : Les travaux manuels sont déclenchés à la demande.
  • Planification : Les travaux planifiés sont déclenchés à des moments spécifiques et peuvent s’exécuter à plusieurs reprises.
  • Événement : les événements, à l’instar d’un message qui arrive dans une file d’attente, déclenchent des travaux pilotés par les événements.

Travaux manuels

Les travaux manuels sont déclenchés à la requête en utilisant Azure CLI, le Portail Microsoft Azure ou une requête à l’API Azure Resource Manager.

Voici quelques exemples de travaux manuels :

  • Des tâches de traitement ponctuelles comme la migration de données d’un système vers un autre.
  • Un site marchand s’exécutant en tant qu’application conteneur démarre une exécution de travail pour traiter l’inventaire lorsqu’une commande est passée.

Pour créer un travail manuel, utilisez le type de travail Manual.

Pour créer un travail manuel à l’aide d’Azure CLI, utilisez la commande az containerapp job create. L’exemple suivant crée un travail manuel nommé my-job dans un groupe de ressources nommé my-resource-group et un environnement Container Apps nommé 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"

L’image mcr.microsoft.com/k8se/quickstart-jobs:latest est un exemple d’image conteneur exécutant un travail qui attend quelques secondes, affiche un message sur la console, puis s’arrête. Pour authentifier et utiliser une image conteneur privée, consultez Conteneurs.

La commande ci-dessus crée uniquement le travail. Pour démarrer une exécution de travail, consultez Démarrer une exécution de travail à la demande.

Scheduled jobs

Pour créer un travail planifié, utilisez le type de travail Schedule.

Les travaux Container Apps utilisent des expressions cron pour définir les planifications. Il prend en charge le format d’expression cron standard avec cinq champs pour minute, heure, jour du mois, mois et jour de la semaine. Voici des exemples d’expressions cron :

Expression Description
*/5 * * * * Exécution toutes les 5 minutes.
0 */2 * * * S’exécute toutes les deux heures.
0 0 * * * S’exécute tous les jours à minuit.
0 0 * * 0 S’exécute tous les dimanches à minuit.
0 0 1 * * S’exécute le premier jour de chaque mois à minuit.

Les expressions Cron dans les travaux planifiés sont évaluées en temps universel coordonné (UTC).

Pour créer un travail planifié à l’aide d’Azure CLI, utilisez la commande az containerapp job create. L’exemple suivant crée un travail planifié nommé my-job dans un groupe de ressources nommé my-resource-group et un environnement Container Apps nommé 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 * * * *"

L’image mcr.microsoft.com/k8se/quickstart-jobs:latest est un exemple d’image conteneur exécutant un travail qui attend quelques secondes, affiche un message sur la console, puis s’arrête. Pour authentifier et utiliser une image conteneur privée, consultez Conteneurs.

L’expression */1 * * * * cron exécute le travail toutes les minutes.

Travaux pilotés par les événements

Les événements des mises à l’échelle personnalisées pris en charge déclenchent des tâches basées sur les événements. Voici des exemples de travaux pilotés par les événements :

  • Un travail qui s’exécute lorsqu’un nouveau message est ajouté à une file d’attente comme Azure Service Bus, Kafka ou RabbitMQ.
  • Un exécuteur GitHub Actions auto-hébergé ou un agent Azure DevOps qui s’exécute lorsqu’un nouveau travail est mis en file d’attente dans un workflow ou un pipeline.

Les applications conteneur et les travaux pilotés par les événements utilisent des scalers KEDA. Ils évaluent les règles de mise à l’échelle sur un intervalle d’interrogation pour mesurer le volume d’événements pour une source d’événement, mais la façon dont ils utilisent les résultats est différente.

Dans une application, chaque réplica traite en continu les événements et une règle de mise à l’échelle détermine le nombre de réplicas à exécuter pour répondre à la demande. Dans les travaux pilotés par les événements, chaque travail traite généralement un seul événement, et une règle de mise à l’échelle détermine le nombre de travaux à exécuter.

Utilisez des travaux lorsque chaque événement nécessite une nouvelle instance du conteneur avec des ressources dédiées ou doit s’exécuter pendant une longue période. Les travaux pilotés par les événements sont similaires aux travaux de mise à l’échelle KEDA d’un point de vue conceptuel.

Pour créer un travail piloté par les événements, utilisez le type de travail Event.

Pour créer un travail piloté par les événements à l’aide d’Azure CLI, utilisez la commande az containerapp job create. L’exemple suivant crée un travail piloté par les événements nommé my-job dans un groupe de ressources nommé my-resource-group et un environnement Container Apps nommé 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>"

L’exemple configure une règle de mise à l’échelle de file d’attente Stockage Azure.

Pour obtenir un tutoriel complet, consultez Déployer un travail piloté par les événements.

Démarrer une exécution de travail à la demande

Vous pouvez démarrer une exécution de travail à la demande pour tout type de travail.

Pour démarrer une exécution de travail à l’aide d’Azure CLI, utilisez la commande az containerapp job start. L’exemple suivant démarre l’exécution d’un travail nommé my-job dans un groupe de ressources nommé my-resource-group :

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

Lorsque vous démarrez une exécution de travail, vous pouvez choisir de remplacer la configuration du travail. Par exemple, vous pouvez remplacer une variable d’environnement ou la commande de démarrage pour exécuter le même travail avec différentes entrées. La configuration substituée est utilisée uniquement pour l’exécution actuelle et ne modifie pas la configuration du travail.

Important

En cas de substitution de la configuration, l’intégralité de la configuration du modèle du travail est remplacée par la nouvelle configuration. Vérifiez que la nouvelle configuration inclut tous les paramètres requis.

Pour remplacer la configuration du travail lors du démarrage d’une exécution, utilisez la az containerapp job start commande et transmettez un fichier YAML contenant le modèle à utiliser pour l’exécution. L’exemple suivant démarre l’exécution d’un travail nommé my-job dans un groupe de ressources nommé my-resource-group.

Récupérez la configuration actuelle du travail avec la az containerapp job show commande et enregistrez le modèle dans un fichier nommé 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

L’option --query "properties.template" retourne uniquement la configuration du modèle du travail.

Modifiez le my-job-template.yaml fichier pour remplacer la configuration du travail. Par exemple, pour remplacer les variables d’environnement, modifiez la env section :

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!"

Démarrez le travail à l’aide du modèle :

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

Obtenir l’historique des exécutions de travail

Chaque travail Container Apps conserve un historique des exécutions de travail récentes.

Pour obtenir les états des exécutions de travail à l’aide d’Azure CLI, utilisez la commande az containerapp job execution list. L’exemple suivant retourne l’état de l’exécution la plus récente d’un travail nommé my-job dans un groupe de ressources nommé my-resource-group :

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

L’historique d’exécution des travaux planifiés et basés sur des événements est limité aux 100 dernières exécutions réussies et ayant échoué.

Pour lister toutes les exécutions d’un travail ou obtenir une sortie détaillée d’un travail, interrogez le fournisseur de journaux configuré pour votre environnement Container Apps.

Configuration avancée des travaux

Les travaux Container Apps prennent en charge des options de configuration avancée telles que les paramètres de conteneur, les nouvelles tentatives, les délais d’expiration et le parallélisme.

Paramètres de conteneur

Les paramètres de conteneur définissent les conteneurs à exécuter dans chaque réplica d’une exécution de travail. Ils comprennent des variables d’environnement, des secrets et des limites de ressources. Pour plus d’informations, consultez Conteneurs. L’exécution de plusieurs conteneurs dans un seul travail est un scénario avancé. La plupart des travaux exécutent un seul conteneur.

Paramètres d’un travail

Le tableau suivant liste les paramètres de travail que vous pouvez configurer :

Setting Propriété d’Azure Resource Manager Paramètre CLI Description
Type de poste triggerType --trigger-type Le type de travail. (Manual, Schedule ou Event)
Délai d’expiration des réplicas replicaTimeout --replica-timeout Temps d’attente maximale en secondes de l’achèvement d’un réplica.
Fréquence d’interrogation pollingInterval --polling-interval Délai d’attente en secondes entre l’interrogation des événements. La valeur par défaut est de 30 secondes.
Limite de nouvelles tentatives des réplicas replicaRetryLimit --replica-retry-limit Nombre maximal de nouvelles tentatives d’exécution d’un réplica en échec. Pour échouer un réplica sans réessayer, définissez la valeur sur 0.
Parallélisme parallelism --parallelism Nombre de réplicas à exécuter par exécution. Pour la plupart des travaux, définissez la valeur sur 1.
Nombre d’achèvements de réplicas replicaCompletionCount --replica-completion-count Nombre de réplicas à exécuter correctement pour que l’exécution réussisse. La plupart d’entre elles sont égales ou inférieures au parallélisme. Pour la plupart des travaux, définissez la valeur sur 1.

Exemple

L’exemple suivant crée un travail avec des options de configuration avancée :

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"

Restrictions de tâches

Les fonctions suivantes ne sont pas prises en charge :

  • Dapr
  • Entrée et fonctionnalités associées telles que les domaines personnalisés et les certificats SSL

Étapes suivantes