Conteneurs de tâches : tâches à exécuter jusqu'à leur achèvement sur Upsun Cloud

La plupart des éléments qui tournent sur une plateforme moderne sont conçus pour fonctionner en continu. Les applications traitent les requêtes, les workers gèrent les files d’attente, et les services gérés assurent la disponibilité des bases de données et des caches 24 h/24. Mais une part non négligeable du travail réel ne correspond pas à ce modèle de fonctionnement permanent. 

Une importation en masse déclenchée quand un utilisateur télécharge un fichier, une correction ponctuelle des données lancée depuis un outil d'administration, un agent IA triant une stack de pull requests, un gestionnaire de webhooks réagissant à un seul événement Stripe : chacun de ces cas a un début, une tâche à accomplir et une fin, et les forcer à s’inscrire dans un processus de longue durée n’est qu’une solution de contournement.

Le conteneur de tâches est la primitive d’infrastructure de Upsun Cloud conçue pour les tâches exécutées jusqu’à leur achèvement.

C’est quoi, un conteneur de tâches ?

Une tâche est une charge de travail à la demande, exécutée jusqu’à son achèvement, définie en parallèle de tes applications et services. Trois éléments la distinguent d’une application ou d’un worker :

• Éphémère. Elle est créée lorsqu’elle est déclenchée et supprimée lorsque sa commande se termine. Rien ne continue à s’exécuter entre deux invocations.
• À la demande. Tu lances une tâche depuis la console, l’interface en ligne de commande (CLI : upsun task:run) ou l’API : depuis l’environnement CI, depuis une tâche cron, depuis un autre service ou depuis l’une de tes applications.
• Exécution jusqu’à la fin. Le conteneur a une tâche bien définie et une fin claire. Les délais d’expiration, les limites de ressources et la journalisation des activités sont intégrés.

Les tâches sont configurées dans le même fichier que le reste de ton projet. Elles disposent de leur propre image de conteneur et de leur propre étape de build, indépendamment de ton application. Elles accèdent au reste de l’environnement, y compris les bases de données, les caches et tout autre service, via le modèle standard de relations d’Upsun Cloud.

Comment les tâches s’intègrent dans un projet

Un projet Upsun cloud repose depuis longtemps sur deux éléments fondamentaux : les applications, qui traitent les requêtes et peuvent inclure des processus d’arrière-plan, et les services, c’est-à-dire les composants gérés comme les bases de données et les caches.

tasks: Rejoins applications: et services: au niveau supérieur de .upsun/config.yaml :

applications:
  api:
    # your long-running API
    
services:
  postgres:
    type: postgresql:18

tasks:
  myagent:
    type: nodejs:24
    run:
      command: node agent.js

Consulte la référence de configuration dans la documentation sur les conteneurs de tâches.

Ce que tu peux y exécuter

Agents IA

Les charges de travail des agents ont une structure spécifique. Elles ont besoin d'un environnement avec accès au code et aux données. Elles ont besoin d'isolation, car elles exécutent des commandes générées par des modèles. Elles ont besoin d'autorisations limitées, car tu ne veux pas qu'un agent accède à tout ce qu'il veut sur la plateforme. Et elles doivent s'arrêter quand le travail est terminé, pour que tu ne paies pas pour un conteneur inactif entre deux exécutions.

C’est justement cette dernière lacune que le conteneur de tâches comble pour l’IA sur Upsun. Le reste existait déjà :

• L’agent s’exécute dans un environnement réel, avec accès au dépôt, à la base de données et à tous les services utilisés par le reste de ton projet.
• L’isolation au niveau du conteneur permet à chaque agent de s’exécuter dans son propre conteneur isolé. Pour un agent LLM qui exécute des commandes générées par un modèle, associe ça à un bac à sable intégré au conteneur, comme bubblewrap, pour restreindre davantage le système de fichiers et les appels système visibles par le processus de l’agent.
• La journalisation des activités enregistre tout ce que l’agent a fait, ce qui permet de garder une trace écrite.
• Les autorisations de charge de travail, décrites ci-dessous, fournissent à l’agent des jetons à durée de vie limitée et à portée restreinte pour effectuer des appels vers l’API Upsun Cloud.

Voici quelques exemples concrets d’agents qui s’intègrent parfaitement :

• Un agent d’assistance qui se déclenche à l’arrivée d’un nouveau ticket, le classe et rédige une première réponse.
• Un agent de performance qui se déclenche lorsqu’une métrique dépasse un seuil.

Il s’agit d’une primitive d’exécution délibérément épurée, de par sa conception. Tu fournis ton propre code d’agent, ton propre fournisseur de LLM et tes propres clés, ainsi que ton propre framework ou SDK ; tu n’es donc jamais lié à un modèle, un langage ou un modèle d’agent spécifique. On te propose un environnement d’exécution flexible ; tu l’utilises comme ton application l’exige.

Tâches par lots et traitement des données

Le traitement par lots est le cas d’utilisation le plus courant sur la plateforme, et celui vers lequel la plupart des clients d’Upsun Cloud se tourneront en premier.

Exemples :

• Une importation CSV déclenchée lorsqu'un utilisateur télécharge un fichier.
• Une exportation de données client générée lorsqu’un titulaire de compte demande son historique.
• Une réindexation qui reconstruit un index de recherche après une modification du schéma.
• Un pipeline de transformation d’images qui s’exécute après le téléchargement d’un contenu.

Chacune de ces tâches suit le même schéma : elle est déclenchée, s'exécute, puis se termine. La question, c'est de savoir où cette tâche s'exécute.

Par défaut, ça s'exécute directement dans le conteneur de l'application, et ça marche tant que la tâche est légère. Mais comme elle partage les mêmes ressources que celles qui gèrent le trafic de ton application, toute tâche gourmande en ressources entre en concurrence avec les requêtes en temps réel et peut nuire aux performances.

La solution traditionnelle a toujours été de déplacer cette tâche vers un worker. Ça résout le problème de contention des ressources, mais ça en crée un autre : un worker reste inactif entre deux exécutions, donc tu paies pour ce temps d’inactivité, peu importe la fréquence à laquelle la tâche est réellement exécutée.

Les tâches Cron sont confrontées au même dilemme. Elles s’exécutent également dans le conteneur de l’application ; ainsi, une tâche Cron gourmande en ressources entre en concurrence avec le trafic en direct, tout comme le ferait une tâche ad hoc. Le programmer au milieu de la nuit permet souvent de contourner ce problème, puisqu’il n’y a pas de trafic avec lequel entrer en concurrence. Mais si ton application génère un trafic international plus régulier, ou si la tâche doit s’exécuter plus d’une fois par jour, cette plage horaire calme risque de ne pas exister. Une tâche Cron peut alors déclencher une autre tâche, de sorte que le gros du travail se fasse dans son propre conteneur plutôt que de puiser dans les ressources de ton application.

Opérations lourdes sur les données

Les migrations de schéma de routine liées à une modification du code ont leur place dans ton hook de déploiement ; c’est là qu’elles doivent naturellement se trouver, et un conteneur de tâches n’y change rien.

C’est pour les tâches plus lourdes et moins courantes qu’un conteneur de tâches s’avère utile : une migration de données ponctuelle, une transformation de données à grande échelle ou une importation en masse trop gourmande en ressources pour être exécutée en ligne. Avec un conteneur de tâches, cette étape fait partie intégrante de la configuration du projet, et non plus d’un fil de discussion Slack décrivant ce que quelqu’un a fait manuellement.

Webhooks déclenchés par des événements

Les webhooks externes atteignent généralement les conteneurs de tâches de manière indirecte. Stripe envoie un événement de paiement. GitHub envoie un événement de push. Slack envoie une interaction. Le plus souvent, ceux-ci arrivent dans une application toujours active qui valide la charge utile, puis appelle l’API Upsun cloud pour déclencher une tâche. L’application reste légère et réactive ; la tâche effectue le travail de longue durée et se termine une fois terminée.

Si la source du webhook peut elle-même contenir un jeton authentifié, elle peut appeler directement l’API pour déclencher la tâche, sans avoir besoin d’une application intermédiaire.

Ce que tu obtiens dès le départ

Chaque tâche comprend :

• Sa propre image de conteneur et son étape de compilation, indépendantes du reste du projet.
• Une facturation à la seconde pour la durée de chaque exécution : une tâche inactive ne coûte donc rien.
• Des délais d’expiration et des limites de ressources pour empêcher les tâches de s’emballer. Le délai d’expiration par défaut est d’une heure ; le maximum est d’un jour.
• Un journal d’activité, pour que tu puisses voir ce qui a été exécuté, quand et ce que ça a fait.
• L'isolation des conteneurs, avec les mêmes contrôles d'espace de noms et de réseau que pour les applications.
• Accès aux services du projet que tu lies, via le modèle de relations standard.
• Autorisations de charge de travail : le mécanisme de jetons à durée de vie limitée décrit ci-dessous.

Autorisations de charge de travail : des jetons à durée de vie courte pour les appels d'API en exécution

Fournies avec le conteneur de tâches, les autorisations de charge de travail permettent à une application ou à une tâche d’appeler l’API Upsun Cloud pendant l’exécution à l’aide de jetons à durée de vie limitée et à portée restreinte. Il n’y a pas d’identifiants à longue durée de vie à stocker ni de rotation à gérer.

C’est utile bien au-delà des agents. Toute charge de travail qui doit communiquer avec l’API de la plateforme en bénéficie : une application qui déclenche une tâche d’importation de données volumineuse lorsqu’un utilisateur télécharge un fichier, un tableau de bord d’administration interne qui répertorie les environnements actifs et leur état, ou une tâche qui lit les métadonnées d’un environnement pour marquer ses résultats avec le nom de la branche. Le principe est le même : demander un jeton à la plateforme, l’utiliser, puis le laisser expirer.

La section sur les autorisations des charges de travail fournit plus de détails.

Points clés à prendre en compte

• Les déploiements interrompent l’exécution des tâches. La plateforme envoie d’abord un signal d’arrêt, puis force la terminaison après un court délai de grâce. Conçois tes tâches de manière à ce qu’elles enregistrent leur progression au fur et à mesure et puissent être réexécutées en toute sécurité.
• Trois tâches à la fois par projet. C'est la limite par défaut. Tout ce qui est déclenché au-delà est mis en file d'attente et attend qu'un créneau se libère.
• Les tâches ne communiquent pas directement entre elles. Si deux parties de ton projet doivent partager des données, fais-les passer par un service (une base de données, un cache ou un stockage partagé) accessible aux deux.
• Chaque exécution de tâche démarre avec un système de fichiers vierge. Les répertoires de travail par défaut sont effacés entre deux exécutions. Pour conserver tes fichiers d’une exécution à l’autre, monte un volume de stockage ou un volume de service.
• Chaque projet doit comporter au moins une application. Les tâches ne peuvent pas fonctionner seules. Un projet ne comportant que des tâches et des services n’est pas valide.
• Les tâches apparaissent dans une carte « Tâches » sous « Applications et services » dans l’aperçu de ton projet et de ton environnement, avec leur statut, leur dernière exécution, leur allocation et leurs relations.
• Les tâches ne servent pas de serveur HTTP. Elles ne peuvent pas être utilisées comme route en amont. Si tu as besoin de gérer des requêtes et des réponses, ça reste le rôle d’une application.

Prêt à en créer une ? Rends-toi sur la documentation relative aux conteneurs de tâches pour te lancer.

Foire aux questions (FAQ)

Un conteneur de tâches, c’est la même chose qu’une fonction serverless ?
Le modèle d’exécution est similaire : déclenchement, exécution, sortie. La différence, c’est qu’une tâche s’exécute au sein de ton environnement Upsun, avec un accès direct à tes services et à tes données via des relations. Tu n’as pas besoin de passer par une plateforme distincte pour accéder à ta base de données.

Puis-je exécuter des tâches planifiées ?
Une tâche est déclenchée à la demande, via la console, la CLI ou l’API. La planification, tu la mets en place en amont, avec une application cron, un job d’intégration continue (CI) ou un planificateur externe.

Que se passe-t-il si une tâche échoue ou atteint son délai d'expiration ?
L'exécution est enregistrée comme ayant échoué dans le journal d'activité. Il n'y a pas de nouvelle tentative automatique ; c'est ce qui a déclenché la tâche qui est chargé de la relancer si nécessaire. Le délai d'expiration par défaut est d'une heure, avec un maximum d'un jour. Conçois tes tâches pour qu'elles soient idempotentes afin qu'une nouvelle tentative soit sans risque.

Quels environnements d’exécution puis-je utiliser pour une tâche ?
Les mêmes images d’environnement d’exécution que pour les applications. Les tâches déclarent un type: dans .upsun/config.yaml, exactement comme le font les applications : Node.js, Python, PHP, Ruby, Go, Java, .NET. Pour les agents IA, le choix dépend des besoins de ton framework ou de ton SDK.

En quoi une tâche diffère-t-elle d’un worker ?
Un worker est un processus de longue durée qui démarre au moment du déploiement et reste actif pour interroger une file d’attente ou effectuer des tâches en arrière-plan. Une tâche est à la demande : elle démarre lorsqu’elle est déclenchée, s’exécute une seule fois, puis se termine. Si le travail arrive en continu, utilise un worker. Si le travail arrive par rafales ou provient d’événements discrets, utilise une tâche.

Les tâches partagent-elles le stockage avec mon application ? Les
tâches disposent de leur propre image de conteneur et d’un système de fichiers vierge à chaque exécution. Elles partagent l’état persistant avec les applications de la même manière que celles-ci le partagent entre elles : via des services (bases de données, stockage d’objets, caches) utilisant le modèle de relations standard. Pour que les fichiers persistent d’une exécution de tâche à l’autre, monte un volume de stockage ou de service. Les montages par défaut « instance » et « tmp » sont réinitialisés entre les exécutions.

Une tâche peut-elle appeler l’API Upsun Cloud ?
Oui. C’est à ça que servent les autorisations de charge de travail : une tâche demande à la plateforme un jeton à durée de vie courte et à portée restreinte, puis l’utilise pour appeler l’API.