Travaux dans Azure Container Apps

Article
10/20/2024

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’exemple de modèle Azure Resource Manager 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 :

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "manualTriggerConfig": {
                "parallelism": 1,
                "replicaCompletionCount": 1
            },
            "replicaRetryLimit": 0,
            "replicaTimeout": 1800,
            "triggerType": "Manual"
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "image": "mcr.microsoft.com/k8se/quickstart-jobs:latest",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

Pour créer un travail manuel à l’aide du Portail Microsoft Azure, recherchez les travaux d’application conteneur dans le Portail Microsoft Azure, puis sélectionnez Créer. Spécifiez Manuel comme type de déclencheur.

Pour utiliser un exemple d’image conteneur, entrez les valeurs suivantes sous l’onglet Conteneurs :

Paramètre	Valeur
Nom	main
Source de l’image	Docker Hub ou d’autres registres
Type d’image	///Public
Serveur de connexion au registre	mcr.microsoft.com
Image et étiquette	k8se/quickstart-jobs:latest
Processeur et mémoire	Cœurs de processeur 0,25, mémoire 0,5 Gio ou version ultérieure

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

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "scheduleTriggerConfig": {
                "cronExpression": "*/1 * * * *",
                "parallelism": 1,
                "replicaCompletionCount": 1
            },
            "replicaRetryLimit": 0,
            "replicaTimeout": 1800,
            "triggerType": "Schedule"
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "image": "mcr.microsoft.com/k8se/quickstart-jobs:latest",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

Pour créer un travail planifié à l’aide du Portail Microsoft Azure, recherchez des travaux d’application conteneur dans le Portail Microsoft Azure, puis sélectionnez Créer. Spécifiez Planification comme type de déclencheur et définissez la planification avec une expression cron, par exemple */1 * * * * pour s’exécuter toutes les minutes.

Pour utiliser un exemple d’image conteneur, entrez les valeurs suivantes sous l’onglet Conteneurs :

Paramètre	Valeur
Nom	main
Source de l’image	Docker Hub ou d’autres registres
Type d’image	///Public
Serveur de connexion au registre	mcr.microsoft.com
Image et étiquette	k8se/quickstart-jobs:latest
Processeur et mémoire	Cœurs de processeur 0,25, mémoire 0,5 Gio ou version ultérieure

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

Travaux pilotés par les événements

Les travaux pilotés par les événements sont déclenchés par des événements provenant de scalers personnalisés pris en charge. 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.

L’exemple de modèle Azure Resource Manager 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 :

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "eventTriggerConfig": {
                "scale": {
                    "maxExecutions": 10,
                    "minExecutions": 0,
                    "pollingInterval": 15,
                    "rules": [
                        {
                            "auth": [
                                {
                                    "triggerParameter": "connection",
                                    "secretRef": "connection-string-secret"
                                }
                            ],
                            "metadata": {
                                "accountName": "mystorage",
                                "queueLength": 1,
                                "queueName": "myqueue"
                            },
                            "name": "queue",
                            "type": "azure-queue"
                        }
                    ]
                }
            },
            "replicaRetryLimit": 0,
            "replicaTimeout": 1800,
            "triggerType": "Event",
            "secrets": [
                {
                    "name": "connection-string-secret",
                    "value": "<QUEUE_CONNECTION_STRING>"
                }
            ]
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "image": "docker.io/myuser/my-event-driven-job:latest",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

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"

Pour démarrer une exécution de travail à l’aide de l’API REST Azure Resource Manager, faites une demande POST à l’opération start du travail.

L’exemple suivant démarre l’exécution d’un travail nommé my-job dans un groupe de ressources nommé my-resource-group :

POST https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/jobs/my-job/start?api-version=2023-05-01
Authorization: Bearer <TOKEN>

Remplacez <SUBSCRIPTION_ID> par votre ID d’abonnement.

Pour authentifier la demande, remplacez <TOKEN> dans l’en-tête Authorization par un jeton de porteur valide. L’identité utilisée pour générer le jeton doit avoir Contributor l’autorisation d’accéder à la ressource de travail Container Apps. Pour plus d’informations, consultez les informations de référence sur l’API REST Azure.

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

Pour remplacer la configuration du travail, incluez un modèle dans le corps de la demande. L’exemple suivant remplace la commande de démarrage pour exécuter une autre commande :

POST https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/jobs/my-job/start?api-version=2023-05-01
Content-Type: application/json
Authorization: Bearer <TOKEN>

{
    "template": {
        "containers": [
            {
                "image": "mcr.microsoft.com/k8se/quickstart-jobs:latest",
                "name": "main",
                "resources": {
                    "cpu": 0.25,
                    "memory": "0.5Gi"
                },
                "command": [
                    "echo",
                    "Hello, Azure Container Apps jobs!"
                ]
            }
        ]
    }
}

Remplacez <SUBSCRIPTION_ID> par votre ID d’abonnement et <TOKEN> dans l’en-tête Authorization par un jeton de porteur valide. L’identité utilisée pour générer le jeton doit avoir Contributor l’autorisation d’accéder à la ressource de travail Container Apps. Pour plus d’informations, consultez les informations de référence sur l’API REST Azure.

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"

Pour obtenir l’état des exécutions de travail à l’aide de l’API REST Azure Resource Manager, faites une demande GET à l’opération executions du travail. 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 :

GET https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/jobs/my-job/executions?api-version=2023-05-01

Remplacez <SUBSCRIPTION_ID> par votre ID d’abonnement.

Pour authentifier la demande, ajoutez un en-tête Authorization avec un jeton de porteur valide. Pour plus d’informations, consultez les informations de référence sur l’API REST Azure.

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"

L’exemple de modèle Azure Resource Manager suivant crée un travail avec des options de configuration avancée :

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "scheduleTriggerConfig": {
                "cronExpression": "0 0 * * *",
                "parallelism": 5,
                "replicaCompletionCount": 5
            },
            "replicaRetryLimit": 3,
            "replicaTimeout": 1800,
            "triggerType": "Schedule",
            "secrets": [
                {
                    "name": "registry-password",
                    "value": "myregistrypassword"
                }
            ]
            "registries": [
                {
                    "server": "myregistry.azurecr.io",
                    "username": "myregistry",
                    "passwordSecretRef": "registry-password"
                }
            ]
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "command": [
                        "/startup.sh"
                    ],
                    "cpu": 0.25,
                    "envVars": [
                        {
                            "name": "MY_ENV_VAR",
                            "value": "my-value"
                        }
                    ],
                    "image": "myregistry.azurecr.io/quickstart-jobs:latest",
                    "memory": "0.5Gi",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

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

Créer un travail avec Azure Container Apps

Partager via