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.
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