Cloudflare Dynamic Workers : des sandboxes 100x plus rapides

BBetter Stack
Internet TechnologySmall Business/StartupsComputing/Software

Transcript

00:00:00(musique entraînante)
00:00:01Cloudflare a récemment annoncé les "dynamic workers",
00:00:04une primitive de worker de bas niveau
00:00:06qui peut être créée par programmation par un worker existant.
00:00:09Ils sont cent fois plus rapides et plus économes en mémoire
00:00:12qu'un conteneur traditionnel car ils fonctionnent sur des isolats V8.
00:00:16Et parce qu'ils sont si peu coûteux,
00:00:18vous pouvez en générer autant que vous le souhaitez
00:00:20pour exécuter du code généré par IA, des aperçus de développement,
00:00:23des automatisations personnalisées, et bien plus encore.
00:00:25Ils ont même affirmé qu'on pouvait lancer un million de dynamic workers
00:00:29par seconde si on le souhaitait.
00:00:31Mais le fait qu'on ne puisse y exécuter que du JavaScript
00:00:33limite-t-il leur utilisation ?
00:00:36Abonnez-vous et découvrons-le ensemble.
00:00:37(musique entraînante)
00:00:40L'année dernière, j'ai fait une vidéo sur les sandboxes Cloudflare,
00:00:44qui sont essentiellement des conteneurs Linux éphémères
00:00:47tournant sur un objet durable.
00:00:49Si cela ne vous dit rien,
00:00:50n'hésitez pas à aller voir la vidéo.
00:00:52Mais ils sont parfaits si vous voulez un conteneur d'OS complet
00:00:55avec un système de fichiers et la capacité de lancer presque n'importe quel langage
00:00:59et n'importe quel binaire.
00:01:01Mais si vous voulez quelque chose d'un peu plus rapide,
00:01:03en fait beaucoup plus rapide et bien plus léger,
00:01:06avec la possibilité de lancer un nombre illimité de sandboxes simultanées
00:01:09avec les mêmes limites qu'un worker classique,
00:01:12alors vous devriez plutôt opter pour un dynamic worker.
00:01:15Voyons comment en configurer un.
00:01:16Voici un worker de base que je viens de créer avec Wrangler,
00:01:19rempli de quelques erreurs TypeScript,
00:01:21peut-être parce que j'ai oublié de lancer "wrangler types".
00:01:23Mais dans notre fichier de configuration Wrangler,
00:01:26j'ai ajouté ce tableau "worker loaders"
00:01:28avec une liaison nommée "loader".
00:01:30Vous pouvez l'appeler comme vous voulez,
00:01:32mais j'ai choisi "loader" parce que c'est plus conventionnel.
00:01:34Et cette liaison nous permet de créer
00:01:37et de contrôler d'autres workers.
00:01:38Dans le code mis à jour, nous avons une nouvelle constante worker,
00:01:42qui utilise la liaison loader avec ces valeurs.
00:01:45On peut imaginer cela comme un fichier de config Wrangler
00:01:49pour le worker imbriqué,
00:01:50mais ici la date de compatibilité indique au worker
00:01:53quelle version du runtime il doit utiliser.
00:01:55Et voici le code qu'il va exécuter.
00:01:57Comme vous le voyez, le code est très similaire
00:01:59à celui d'un worker lui-même.
00:02:00Il possède une fonction fetch
00:02:02avec les arguments request, env et context.
00:02:05Et tout ce qu'il fait ici, c'est répondre
00:02:06par "hello world from the sandbox".
00:02:08Nous avons ensuite empêché tout accès réseau,
00:02:10exécuté la fonction fetch avec les arguments de requête
00:02:13du worker initial et retourné les résultats.
00:02:16Si on lance notre worker localement puis qu'on fait un curl localhost,
00:02:19on devrait voir "hello from the sandbox".
00:02:21Mais si on relance la même requête curl,
00:02:24on obtiendra une erreur.
00:02:24Et c'est parce qu'en ce moment,
00:02:26nous chargeons un tout nouveau worker.
00:02:28Mais ce qu'on peut faire à la place, c'est récupérer un worker existant,
00:02:31qu'on nommera "worker one",
00:02:33puis exécuter le code comme une fonction asynchrone.
00:02:35Désormais, si on lance curl, on a "hello from the sandbox".
00:02:38Et si on recommence, il récupère les informations
00:02:41de la sandbox existante du worker one.
00:02:43Maintenant, ce que je viens de montrer
00:02:45était bien sûr un exemple très simple,
00:02:47mais on peut faire des choses géniales avec les dynamic workers,
00:02:50comme définir des liaisons personnalisées,
00:02:52comme cette méthode post chatroom pour créer un stub,
00:02:55avec lequel le worker communique via Cap'n Proto sur le Web,
00:02:57sur lequel nous avons déjà fait une vidéo,
00:02:59alors allez la voir si cela vous intéresse.
00:03:00Vous pouvez utiliser des dépendances NPM comme Hono
00:03:03et les packager via la fonction create worker.
00:03:05Et vous pouvez même intercepter les requêtes sortantes
00:03:08pour faire des choses comme injecter des identifiants.
00:03:10Mais l'une des raisons majeures d'utiliser des dynamic workers
00:03:13est d'exécuter du code généré par des agents IA.
00:03:17Alors, essayons de faire ça.
00:03:18Voici du code provenant du cookbook E2B
00:03:21qui utilise le SDK Anthropic pour faire tourner Sonnet 3.5
00:03:25avec ce prompt système et un outil personnalisé
00:03:28pour exécuter du Python dans un notebook Jupyter.
00:03:31Le fonctionnement est le suivant : il détecte
00:03:33quand l'outil personnalisé est utilisé
00:03:34et l'exécute ensuite à l'intérieur de la sandbox E2B,
00:03:38dont on peut voir le code juste ici.
00:03:40Il l'exécute avec ce prompt très spécifique
00:03:42pour calculer la valeur de pi par la méthode de Monte Carlo
00:03:46sur mille itérations.
00:03:47Et comme il a accès au système de fichiers,
00:03:50il peut créer cette image PNG
00:03:52et la sauvegarder pour qu'elle soit téléchargée par l'utilisateur
00:03:54ou tout ce que l'utilisateur souhaite.
00:03:56Malheureusement, les dynamic workers n'ont pas accès
00:03:58à un système de fichiers,
00:04:00même s'ils peuvent en créer un virtuel
00:04:02avec cette bibliothèque de shell.
00:04:04Mais comme ils passent par un worker,
00:04:06on peut lui fournir des éléments comme un bucket R2,
00:04:08qui est la version de Cloudflare de S3,
00:04:11dans lequel l'image peut être sauvegardée.
00:04:12Si on regarde le code,
00:04:14qui est similaire à celui d'E2B,
00:04:16on peut d'abord voir le prompt système utilisé.
00:04:19Et l'outil d'exécution Python personnalisé
00:04:22qui, dans ce cas, n'utilise pas de notebook Jupyter,
00:04:25mais génère un SVG pour les visuels.
00:04:28Et ici nous avons le code pour le worker
00:04:30qui, en plus de JavaScript, peut aussi exécuter du Python.
00:04:33On voit ici qu'il utilise Sonnet 4.6.
00:04:35Voici le prompt utilisé.
00:04:37Ici le code de l'agent est exécuté dans la sandbox.
00:04:41Et la réponse de la sandbox
00:04:43revient au worker principal,
00:04:45qui y cherche le code SVG
00:04:47pour ensuite le sauvegarder dans R2.
00:04:49Si on visite cette URL, cela prend un peu de temps,
00:04:51mais cela génère bien la page
00:04:53avec les informations pertinentes de Claude.
00:04:55Et si on fait défiler vers le bas,
00:04:56on peut voir ce SVG chargé depuis R2.
00:05:01Il semble très différent de celui d'E2B,
00:05:03mais je fais confiance à Claude Sonnet
00:05:04pour avoir produit les informations correctes.
00:05:06Et j'ai bien sûr mentionné qu'il est aussi possible
00:05:09de générer par programmation autant de dynamic workers que voulu,
00:05:13ce qu'on peut faire avec un code comme celui-ci.
00:05:16C'est une boucle for qui crée de nouveaux workers
00:05:19basés sur la valeur de l'API.
00:05:21Et elle vérifie aussi si un worker existe déjà
00:05:23et le réutilise si c'est le cas.
00:05:25Le code exécuté est essentiellement un console log
00:05:27et une réponse du worker
00:05:29avec l'ID spécifique du worker
00:05:31basé sur l'index de la boucle for.
00:05:32Donc avec le code en cours d'exécution,
00:05:34je pourrais lancer 50 tout nouveaux dynamic workers
00:05:36et on voit qu'ils sont tous créés instantanément.
00:05:40C'était extrêmement rapide.
00:05:41Maintenant, essayons avec 10 000,
00:05:43mais je ne vais pas le faire localement
00:05:44car je ne veux pas faire exploser ma machine.
00:05:46J'ai donc déployé mon worker parent sur Cloudflare
00:05:49pour pouvoir utiliser leur infrastructure.
00:05:50Ici, je vais donc lancer 10 000 workers différents.
00:05:53Et si j'appuie sur Entrée, ils sont tous créés à une vitesse folle.
00:05:56On peut voir qu'il y a une page de 30 workers ici,
00:05:59et je peux continuer pour voir tous les différents IDs.
00:06:03Plus j'avance, plus de pages s'affichent.
00:06:05Et je peux communiquer avec un worker spécifique
00:06:07comme le worker 1156,
00:06:09qui répond "hello from worker 1156".
00:06:12C'était donc un rapide aperçu des dynamic workers,
00:06:15qui sont déjà utilisés par Cloudflare pour le mode code
00:06:18et Zite pour faire tourner des applications générées par LLM.
00:06:21Mais je dois préciser que s'ils sont gratuits actuellement,
00:06:24ils ne le resteront pas éternellement.
00:06:25Même si vous pouvez lancer un million de dynamic workers
00:06:28par seconde, vous devriez peut-être vous abstenir
00:06:30à moins d'avoir les reins solides financièrement.
00:06:32Et tant qu'on parle de Cloudflare,
00:06:34si vous voulez en savoir plus sur leur SDK open source VIVE
00:06:38qui permet de créer des générateurs d'apps comme vZero et Lovable,
00:06:42alors regardez la vidéo suivante.

Key Takeaway

Les Cloudflare Dynamic Workers offrent une infrastructure ultra-rapide et scalable pour exécuter du code dynamique, particulièrement adaptée aux environnements d'exécution pour l'IA.

Highlights

Les Dynamic Workers sont des isolats V8 capables de démarrer 100 fois plus vite que des conteneurs traditionnels.

L'utilisation d'une liaison "loader" permet de créer et de contrôler des workers enfants de manière programmable.

Contrairement aux sandboxes Cloudflare classiques, ils n'ont pas de système de fichiers natif mais peuvent utiliser R2.

Le système supporte désormais l'exécution de code Python en plus du JavaScript pour des cas d'usage variés.

Une démonstration prouve la capacité de déployer 10 000 workers quasi instantanément sur l'infrastructure Cloudflare.

Cette technologie est idéale pour exécuter du code généré par des agents IA comme Claude 3.5 Sonnet de manière isolée.

Timeline

Introduction aux Dynamic Workers

L'intervenant présente les Dynamic Workers comme une nouvelle primitive de bas niveau chez Cloudflare. Ces outils fonctionnent sur des isolats V8, ce qui les rend 100 fois plus rapides et bien plus économes en mémoire que les conteneurs standards. L'avantage majeur réside dans la possibilité de générer un nombre quasi illimité d'instances pour l'IA ou des automatisations. L'auteur pose néanmoins la question de la limitation potentielle au seul langage JavaScript. Cette section pose les bases techniques de la rapidité d'exécution promise par Cloudflare.

Comparaison avec les Sandboxes Classiques

Cette partie compare les Dynamic Workers aux sandboxes Cloudflare basées sur des conteneurs Linux éphémères. Alors que les sandboxes traditionnelles offrent un système de fichiers complet et supportent n'importe quel binaire, elles sont plus lourdes. Les Dynamic Workers sont présentés comme l'alternative légère pour ceux qui privilégient la vitesse et le nombre d'instances simultanées. L'auteur souligne que ces derniers partagent les mêmes limites qu'un worker classique. C'est un choix architectural crucial entre la compatibilité système totale et la performance brute.

Configuration Technique et Liaisons

L'auteur détaille la mise en œuvre pratique via l'outil Wrangler en utilisant la configuration "worker loaders". Il explique comment définir une liaison nommée "loader" pour instancier et piloter des workers enfants directement depuis le code. Un exemple concret de code "Hello World" est présenté pour illustrer le cycle de vie d'un worker dynamique. On y découvre comment récupérer un worker existant par son nom pour maintenir un état ou une session. Cette manipulation montre la flexibilité de la gestion programmatique de l'infrastructure.

Capacités Avancées et Support NPM

La vidéo explore des fonctionnalités plus complexes comme l'utilisation de liaisons personnalisées pour la communication entre workers. Il est possible d'utiliser le protocole Cap'n Proto ou d'intégrer des dépendances NPM populaires telles que le framework Hono. L'auteur mentionne également la capacité d'intercepter les requêtes sortantes pour injecter des identifiants de sécurité. Ces options permettent de transformer un simple script en une application robuste et modulaire. Cette section démontre que la légèreté des isolats n'empêche pas une grande richesse fonctionnelle.

Exécution de Code IA et Intégration R2

L'un des cas d'usage principaux est l'exécution de code généré par des agents IA comme Claude Sonnet. L'auteur explique que, malgré l'absence de système de fichiers réel, on peut coupler les workers avec Cloudflare R2 pour stocker des fichiers. Un exemple pratique montre un agent générant un graphique SVG sauvegardé directement dans un bucket R2. On note ici le support du langage Python au sein de ces sandboxes, ce qui élargit considérablement les possibilités pour la science des données. L'intégration avec le SDK Anthropic souligne la pertinence de cette solution pour les développeurs d'IA moderne.

Tests de Performance à Grande Échelle

Pour conclure, l'auteur effectue un test de stress impressionnant en déployant 10 000 workers simultanément sur l'infrastructure de production de Cloudflare. Les instances sont créées de façon quasi instantanée, prouvant la scalabilité extrême de la technologie. Il avertit toutefois sur le futur modèle de tarification qui ne restera pas gratuit malgré les performances affichées. La vidéo se termine par une recommandation vers le SDK open source VIVE pour créer des générateurs d'applications. Cette démonstration finale valide la promesse initiale de rapidité et d'efficacité à l'échelle mondiale.

Community Posts

View all posts