OpenWorkers – des Cloudflare Workers auto-hébergés implémentés en Rust
(openworkers.com)- OpenWorkers est un runtime open source qui exécute JavaScript sur V8, permettant de mettre en place de l’edge computing sur sa propre infrastructure
- Prend en charge le stockage KV, PostgreSQL, le stockage compatible S3/R2, les service bindings, ainsi que les variables d’environnement et secrets
- Maintient une forte compatibilité avec Cloudflare Workers, y compris les principales API Web comme fetch, ReadableStream et crypto.subtle
- Permet un auto-hébergement simple grâce à un sandbox V8 Isolate, à la planification cron et à un déploiement basé sur Docker Compose
- Projet développé pendant environ 7 ans, avec pour objectif un environnement d’exécution JavaScript sans dépendance à un fournisseur
Présentation d’OpenWorkers
- OpenWorkers est un runtime compatible Cloudflare Workers écrit en Rust, qui exécute JavaScript à l’aide de V8 Isolate
- Il permet de profiter des avantages de l’edge computing même dans un environnement de serveurs autogéré
- Distribué en open source, il peut être librement déployé et modifié
Fonctionnalités principales
- La fonctionnalité de bindings permet l’intégration avec diverses ressources externes
- Stockage KV : prise en charge de get, put, delete et list
- Intégration avec une base de données PostgreSQL
- Prise en charge du stockage compatible S3/R2
- Inclut les service bindings, ainsi que la gestion des variables d’environnement et des secrets
- Prise en charge des API Web
- Fournit des API standard comme fetch, Request, Response et ReadableStream
- Inclut crypto.subtle, TextEncoder/Decoder, Blob, setTimeout et AbortController
Architecture
- Le système se compose d’un proxy nginx, d’un tableau de bord, d’une API, d’un service de logs, de runners, de PostgreSQL, de NATS et d’un planificateur
- Chaque runner exécute le code dans un V8 Isolate, avec des limites de 100 ms de CPU et 128 Mo de mémoire
- Inclut un planificateur intégré prenant en charge une syntaxe cron à 5 ou 6 champs
- Conserve une compatibilité syntaxique avec Cloudflare Workers
Auto-hébergement
- Le déploiement est possible avec une seule base de données PostgreSQL et un fichier Docker Compose
- Peut être lancé facilement avec les commandes
git clone, la configuration de.envetdocker compose up - Inclut les procédures de migration et de génération de token
- Peut être lancé facilement avec les commandes
Contexte de développement
- Projet abouti après environ 7 ans de développement
- Au départ, il expérimentait le sandboxing JS avec vm2, puis a évolué en s’inspirant du modèle Cloudflare Workers
- Après un passage par Deno-core, il a été réécrit sur la base de rusty_v8
- L’objectif est de fournir une expérience développeur (DX) au niveau de Cloudflare Workers tout en construisant un environnement d’exécution sur serveur propre, sans dépendance à un fournisseur
- À l’avenir, l’ajout d’une fonctionnalité d’enregistrement et de relecture de l’exécution est prévu pour permettre le debug déterministe (deterministic debugging)
1 commentaires
Avis de Hacker News
L’idée d’apporter la puissance de l’edge computing sur sa propre infrastructure est intéressante
Mais l’auto-hébergement semble en partie aller à l’encontre de la nature même de l’edge computing
C’est un modèle rendu possible par de grands fournisseurs comme Cloudflare, qui disposent de plus de 300 PoP (Points of Presence) dans le monde
Bien sûr, on peut recréer une structure similaire en combinant des fournisseurs plus petits et plus éthiques, mais cela demande bien plus d’efforts et comporte davantage de risques
J’ai l’impression qu’une dizaine dans les grandes régions pourrait suffire
Mais j’ai aussi peur que ce soit trop difficile à coordonner de manière sûre et fiable
Le problème des solutions de sandbox, c’est qu’elles doivent offrir une garantie forte que le code ne pourra pas s’échapper de la sandbox
Pour le prouver, il faut des résultats de tests couvrant de nombreux scénarios d’attaque ainsi qu’une documentation détaillée
Mais une documentation de ce niveau est très rare, et il est difficile de trouver de vrais exemples dignes de confiance
Du coup, je vérifie surtout s’il existe des cas d’usage en production dans de grandes entreprises où l’équipe sécurité en assure la maintenance
Ils appliquent parfois même les releases de V8 avant Chrome
Chaque worker s’exécute dans un isolate plutôt que dans un processus séparé, comme dans le modèle Cloudflare
Mais lorsqu’on traite du code tiers totalement non fiable, il vaut mieux ajouter une couche d’isolation supplémentaire avec un conteneur ou une VM
Ce sandboxing vise davantage l’isolation des ressources que la sécurité
Un audit de sécurité du type « nous avons vérifié et c’est sûr, faites-nous confiance » ne suffit pas
mais dans un environnement auto-hébergé, on a déjà accès au système, donc il y a moins lieu de s’inquiéter d’une sortie de sandbox
Je trouve que c’est un super projet
Si workerd est open source, je me demande si la différence d’OpenWorkers est surtout de fournir un environnement complet
J’aimerais aussi savoir s’il y a des différences au niveau du runtime lui-même, ou des plans pour un futur service managé
1️⃣ workerd ne fournit que le runtime, tandis qu’OpenWorkers propose une plateforme complète avec dashboard, API, scheduler, logs et bindings (KV, S3/R2, Postgres)
2️⃣ workerd est basé sur C++, alors qu’OpenWorkers repose sur Rust + rusty_v8, ce qui le rend plus simple et plus facile à bricoler
3️⃣ Il existe déjà une version managée sur dash.openworkers.com, avec un niveau gratuit
Mais l’auto-hébergement est traité comme un citoyen de première classe
Le cœur de Cloudflare Workers, c’est la facturation à la fonction, mais en auto-hébergé il faut au final provisionner le matériel à l’avance
Il n’est pas obligatoire de tout externaliser, et c’est une bonne chose d’avoir des alternatives comparables
Ce genre d’option aide à réduire les barrières à l’adoption
J’ai déjà beaucoup travaillé sur l’extraction de deno_core, donc je comprends le passage au rusty_v8 brut
deno_core contient beaucoup de code legacy, et les tests cassaient souvent lorsqu’on le modifiait
Mais nous sommes passés à rusty_v8 pour avoir un contrôle plus fin sur l’intérieur du runtime,
et nous prévoyons plus tard de réintégrer les fonctionnalités manquantes dans le runtime deno
S’il s’agit d’un projet qui aide à réduire la dépendance aux fournisseurs, je suis forcément pour
J’espère que cela poussera les services cloud à revoir leurs prix à la baisse
Aujourd’hui, même des fonctions de base comme le NAT sont facturées de manière excessive
Bien sûr, le cloud est pratique, mais le problème reste son coût élevé par rapport au DIY
Si les grandes entreprises accaparent les ressources, il pourrait devenir compliqué pour les particuliers d’héberger eux-mêmes
Mais dans la réalité, dans beaucoup de pays, le coût d’exploitation en direct est encore plus élevé
Ce n’est pas juste une question d’installation : il faut aussi payer la maintenance humaine et la supervision
Ce serait bien d’indiquer dans la documentation les fonctionnalités qui ne marchent pas encore ainsi que la feuille de route
La prochaine priorité est une fonction d’enregistrement/relecture pour le débogage, et nous allons ajouter une section roadmap dans la documentation
Le diagramme d’architecture en ASCII s’affiche mal sur Pixel + Firefox
Les diagrammes textuels ont leur charme, mais en pratique, publier aussi une version compilée en image serait plus utile
C’est une excellente idée de produit, aussi bien techniquement que structurellement
J’aime particulièrement le fait de rendre en open source, en retour, le modèle de projets open source des grands fournisseurs
Autrement dit, au lieu qu’ils prennent de l’open source pour le commercialiser, on fait l’inverse en réouvrant leur modèle — à mon avis, c’est exactement la bonne approche
On dirait que l’idée « et si on hébergeait le cloud directement sur nos propres machines ? » revient à la mode
On voit ce genre de tendance à l’auto-hébergement un peu partout en ce moment
Cette vidéo de présentation est aussi intéressante
L’essence du cloud, c’est l’élasticité
Le principe est de pouvoir augmenter ou réduire le nombre d’instances selon les besoins, et de ne payer que ce qu’on utilise
En auto-hébergé, les outils de déploiement sont certes pratiques, mais il faut quand même assumer le coût total des serveurs
Si la charge est stable ou prévisible, cela va, mais sinon c’est inefficace
(Pour prendre une image, c’est la différence entre prendre le bus et posséder un van)
Les développeurs peuvent se concentrer sur l’implémentation des gestionnaires d’événements, et c’est encore plus puissant avec des files d’attente ou une exécution durable
Au fond, le FaaS est un outil de haut niveau qui abstrait le code boilerplate