Comment exécuter Cloudflare Durable Objects sur vos propres serveurs avec celld

Ryan Dahl et l'équipe Deno ont悄然 open-sourcé le projet celld. Si vous avez déjà envié les utilisateurs de Cloudflare pour leur concept de Durable Objects mais que vous ne vouliez pas gérer le verrouillage fournisseur, ceci pourrait vous intéresse.

celld est un runtime de daemon Rust qui peut exécuter des bundles Cloudflare Workers et des instances isolées de Durable Objects sur votre propre matériel. Pas d'Etcd, pas de Raft, et pas de services de coordination lourds.

Le Cœur du Concept

Les backends traditionnels sont généralement divisés en microservices sans état et une seule grande base de données relationnelle. À mesure que la charge augmente, la base de données devient inévitablement le goulot d'étranglement principal.

Cloudflare a proposé une approche différente. Chaque entité d'application active (par exemple, un salon de chat, un panier d'achat ou une session de document) obtient son propre isolate V8 et une base de données SQLite personnelle. L'objet se réveille lorsqu'une requête arrive, conserve l'état en mémoire et dans un fichier SQLite local, et se met simplement en veille lorsqu'il est inactif.

Le principal problème était la nature fermée de l'écosystème : exécuter une telle configuration en dehors de l'infrastructure de Cloudflare était practically impossible jusqu'à maintenant.

Comment celld Fonctionne en Interne

Les développeurs de celld ont opted for radical simplification. L'architecture du nœud se compose de quatre composants :

1. Embedded V8 pour exécuter du code JavaScript et TypeScript à partir des bundles Wrangler.
2. SQLite local pour le fichier de base de données séparé de chaque objet.
3. Stockage compatible S3 (AWS S3, MinIO, Cloudflare R2) comme seule source de vérité.
4. Transport inter-serveur avec signature HMAC pour l'échange de données entre les nœuds.

La solution la plus intéressante ici est l'abandon des protocoles de consensus classiques. Les nœuds du cluster n'ont pas besoin d'élire un leader ni d'exécuter Consul.

Au lieu de cela, les serveurs communiquent avec S3 via une opération atomique Compare-And-Swap (CAS). Lorsqu'un nœud veut prendre possession d'un objet, il écrit un fichier de propriété dans le bucket S3. Celui qui parvient à mettre à jour l'enregistrement via CAS en premier gère le trafic. Si un nœud tombe en panne, le délai d'écriture expire, et un serveur voisin récupère l'objet, télécharge sa base de données SQLite fraîche depuis le bucket, et continue de fonctionner.

Lancement et Déploiement

Les builds Wrangler standard fonctionnent pour construire le projet, mais vous aurez besoin d'un serveur avec 5 et le binaire lui-même 6.

L'installation se fait avec une seule commande :

0

Le flux de travail se décompose en deux étapes. Tout d'abord, téléchargez le build du worker vers le bucket :

1

Puis lancez le daemon sur le serveur :

2

Chaque nœud du cluster lit le manifest 7 depuis le bucket. Si vous avez besoin de démarrer un serveur supplémentaire, vous lancez un autre processus avec le même bucket et spécifiez son adresse réseau dans 8.

En matière de sécurité : le trafic inter-serveur de celld ne chiffre pas TLS out of the box. Les auteurs recommandent de placer les ports internes des nœuds derrière un réseau superposé sécurisé comme WireGuard ou Tailscale. Toutes les requêtes entre pairs sont automatiquement signées avec une clé HMAC 9 que le premier nœud crée automatiquement dans le bucket.

Diagnostics et Gestion de la Charge

Pour la surveillance du cluster, il y a l'utilitaire 10. Il interroge les voisins et affiche les métriques actuelles :

3

La commande affichera la consommation CPU, la mémoire RSS, le nombre de connexions WebSocket actives et le nombre d'objets vivants sur chaque nœud.

Si un serveur commence à être surchargé, celld dispose d'un mécanisme de décharge de pression pour les objets actifs. Les limites sont définies via des variables d'environnement :

4

Lorsque le seuil est dépassé, celld enregistre les objets inactifs vers S3, libère la propriété et cesse d'accepter de nouvelles entités jusqu'à ce que la charge descende à la valeur de 11. Les objets avec des requêtes fréquentes ou des connexions WebSocket ouvertes ne sont pas affectés.

Une Approche Non Conventionnelle de la Contribution

Si vous allez au dépôt 12 dans l'intention d'ouvrir une Pull Request, vous trouverez le bouton désactivé. Les forks sont autorisés, mais les PR sur GitHub sont complètement désactivées.

Ryan Dahl explique cela comme une lutte contre le spam des agents IA : reviewer des pull requests géantes auto-générées sans contexte prend trop de temps aux mainteneurs. Ceux qui veulent envoyer un correctif sont priés de faire 13 et d'envoyer le fichier par email à l'adresse personnelle 14.

Qui Devrait Jeter un Œil à Ce Projet

Le projet est en développement actif, avec les spécifications du protocole stockées directement dans le code de la crate Rust 15. Il est trop tôt pour l'intégrer en production critique, mais expérimenter vaut definitely la peine.

L'outil sera utile dans les cas suivants :

1. Les développeurs de services multijoueurs, de salons de chat et de CRM personnalisés.
2. Les équipes qui prévoient de s'éloigner du verrouillage Cloudflare sans réécrire le code.
3. Les fans de l'architecture avec une base de données séparée par client-utilisateur.
4. Les ingénieurs qui apprennent les systèmes distribués sans Raft ni Etcd.