Cloudflare Containers repensé pour des bacs à sable d'agents IA à la demande

Cloudflare a fondamentalement restructuré sa plateforme Containers afin de mieux répondre aux besoins dynamiques des agents IA. Publiée le 30 septembre 2026, cette mise à jour introduit une nouvelle politique d'ordonnancement qui permet au code applicatif de sélectionner les images de conteneurs et les types d'instances au moment de l'exécution plutôt qu'au déploiement. Ces changements visent à éliminer les pénalités de latence associées à l'orchestration traditionnelle de conteneurs, permettant aux bacs à sable de démarrer en moins d'une seconde.

Ce qui s'est passé

Auparavant, Cloudflare Containers fonctionnait de manière similaire aux déploiements d'applications traditionnels. Les développeurs devaient définir l'image du conteneur et les ressources de calcul lors du processus de build, déployant chaque configuration comme une application distincte. Ce modèle exigeait des espaces de noms Durable Object distincts pour chaque combinaison d'image et de type d'instance. Si un agent avait besoin à la fois d'un environnement Node.js léger et d'un environnement de build Python lourd, les développeurs devaient gérer deux applications séparées et router manuellement le trafic entre elles. Chaque modification de l'environnement nécessitait un nouveau cycle de déploiement, rendant difficile l'adaptation aux besoins imprévisibles en ressources des agents IA.

La nouvelle architecture déplace ces décisions directement dans la logique de l'application. En introduisant la politique d'ordonnancement durable_object, Cloudflare permet au code de choisir l'image spécifique et la taille de l'instance lorsqu'une tâche arrive. Cela signifie qu'une seule classe Durable Object peut désormais lancer différents types de bacs à sable côte à côte. Par exemple, un agent peut demander un environnement léger pour des requêtes simples et un environnement de build robuste pour des tâches complexes sans aucun pré-approvisionnement. Ce changement transforme la configuration de l'infrastructure d'un artefact de déploiement statique en un code dynamique exécuté au moment de la requête.

En parallèle de cette flexibilité, Cloudflare a traité le problème critique de la latence de démarrage. Les agents IA créent souvent des bacs à sable à la demande pour des tâches individuelles, ce qui signifie que les utilisateurs attendent l'initialisation de l'environnement avant que le travail ne commence. Le modèle précédent de plan de contrôle global introduisait une surcharge significative lors de la résolution des configurations et de la coordination du placement à travers le réseau. Le nouveau système localise ce processus, démarrant les conteneurs sur la même machine que le Durable Object contrôleur chaque fois que possible. Cela réduit le temps de démarrage médian d'un peu plus de quatre secondes à 648 millisecondes, une amélioration de plus de six fois vérifiée par des benchmarks indépendants.

Comment cela fonctionne

Le mécanisme central permettant cette vitesse et cette flexibilité est l'intégration étroite entre Containers et Durable Objects. Chaque instance de conteneur est attachée à un Durable Object, qui agit comme un contrôleur persistant et programmable. Dans le nouveau modèle, le Durable Object ne gère pas seulement le cycle de vie ; il contrôle directement la configuration du conteneur via l'API native ctx.container. Lorsqu'une requête arrive, le code vérifie les exigences de la tâche et sélectionne une image parmi une liste prédéfinie dans le fichier de configuration. L'ordonnanceur recherche ensuite la capacité sur l'hôte local en premier, privilégiant les machines ayant déjà l'image ou l'instantané requis dans le stockage local pour éviter les retards de téléchargement.

Pour réduire davantage les temps de démarrage, l'environnement d'exécution ne démarre plus une machine virtuelle à partir de zéro pour chaque requête. Au lieu de cela, il restaure une machine virtuelle préparée qui est déjà initialisée mais non assignée. Cette approche réutilise les configurations réseau et système de fichiers, regroupant des opérations qui étaient auparavant effectuées séquentiellement. De plus, Cloudflare a introduit une image système prête à l'emploi appelée cloudflare/debian-trixie. Cette image de base inclut Debian Trixie Slim et Node.js 24.20.0 LTS, distribuée à l'avance sur les hôtes. Les agents peuvent démarrer ce bac à sable instantanément puis utiliser des commandes d'exécution pour cloner des dépôts ou installer des paquets, évitant ainsi la nécessité de construire et pousser des images Docker personnalisées pour des tâches simples.

Détails clés

• Configuration au moment de l'exécution : La nouvelle politique d'ordonnancement durable_object permet au code de sélectionner les images de conteneurs et les types d'instances au moment de l'exécution, supprimant le besoin de déploiements séparés pour chaque type d'environnement.
• Performance de démarrage : Le temps de démarrage médian est passé de 4,049 secondes à 648 millisecondes, avec le 95e percentile amélioré de 5,839 secondes à 910 millisecondes.
• Instantanés du système de fichiers : Une fonctionnalité en bêta publique permet de sauvegarder et restaurer les systèmes de fichiers des conteneurs, permettant aux agents de mettre en pause et reprendre des tâches longues sans perdre l'état ni répéter les étapes de configuration.
• Image de base préparée : L'image cloudflare/debian-trixie est pré-distribuée sur les hôtes, permettant aux agents de démarrer immédiatement un environnement Linux sans construire d'images personnalisées.
• Capacité de pointe : Des tests préliminaires ont montré que le système pouvait démarrer 100 000 conteneurs en 5,387 secondes à travers six emplacements, démontrant une haute scalabilité pour les charges de travail en rafale.
• Contrôle du déploiement progressif : Les déploiements sont désormais gérés via le code au sein du Durable Object, permettant des stratégies telles que les releases canari ou l'épinglage de projets actifs à des images spécifiques sans modifications de configuration au niveau de la plateforme.

Pourquoi c'est important

Pour les ingénieurs construisant des plateformes d'agents IA, cette mise à jour supprime un goulot d'étranglement majeur dans l'expérience utilisateur. L'orchestration traditionnelle de conteneurs est conçue pour des services de longue durée, pas pour des tâches éphémères devant démarrer instantanément. En déplaçant la configuration au moment de l'exécution, les développeurs peuvent construire des systèmes plus efficaces qui ne consomment des ressources que lorsque nécessaire. C'est particulièrement important pour les agents de codage, les frameworks d'évaluation et les systèmes d'apprentissage par renforcement qui nécessitent des milliers d'environnements isolés. La capacité de démarrer un bac à sable en moins d'une seconde signifie que les utilisateurs passent moins de temps à attendre l'approvisionnement des environnements et plus de temps à interagir avec l'agent.

L'introduction des instantanés du système de fichiers change également la gestion de l'état dans les environnements serverless. Auparavant, préserver le travail d'un agent nécessitait des solutions de stockage externes complexes ou le maintien des conteneurs en fonctionnement indéfiniment, ce qui augmentait les coûts. Désormais, un agent peut sauvegarder son espace de travail, terminer le conteneur et le restaurer plus tard exactement où il s'était arrêté. Cette capacité soutient les workflows asynchrones et les tâches longues pouvant s'étaler sur plusieurs jours, rendant faisable la construction d'applications d'agents plus sophistiquées sur une infrastructure serverless sans gérer de serveurs persistants.

Ce que vous pouvez faire

• Mettez à jour votre wrangler.jsonc pour inclure la politique d'ordonnancement durable_object et déclarez les images auxquelles votre Durable Object peut accéder.
• Refactorisez la logique existante des conteneurs pour sélectionner les images et les types d'instances en fonction des paramètres de la tâche au sein de la classe Durable Object.
• Testez l'image de base cloudflare/debian-trixie pour les tâches ne nécessitant pas de builds Docker personnalisés afin de tirer parti des assets pré-distribués.
• Implémentez la création d'instantanés du système de fichiers dans votre workflow pour sauvegarder l'état de l'agent après des jalons importants et le restaurer lors de la reprise.
• Utilisez le stockage Durable Object pour gérer les stratégies de déploiement progressif, comme l'épinglage d'IDs spécifiques à des images plus anciennes pendant les périodes de migration.
• Surveillez les métriques de démarrage en utilisant la nouvelle API ctx.container pour garantir que vos agents bénéficient des améliorations d'ordonnancement localisé.