Come eseguire Cloudflare Durable Objects sui tuoi server usando celld

Ryan Dahl e il team Deno hanno rilasciato discretamente come open source il progetto celld. Se hai mai invidiato gli utenti di Cloudflare per il loro concetto di Durable Objects ma non volevi avere a che fare con il lock-in del vendor, questo potrebbe interessarti.

celld è un runtime demone Rust che può eseguire bundle Cloudflare Workers e istanze isolate di Durable Objects sul tuo hardware. Niente Etcd, niente Raft, e niente servizi di coordinamento pesanti.

Il cuore del concetto

I backend tradizionali sono tipicamente suddivisi in microservizi stateless e un singolo grande database relazionale. Man mano che il carico aumenta, il database diventa inevitabilmente il collo di bottiglia principale.

Cloudflare ha proposto un approccio diverso. Ogni entità attiva dell'applicazione (per esempio, una chat room, un carrello della spesa o una sessione di documento) ottiene il proprio isolate V8 e un database SQLite personale. L'oggetto si attiva quando arriva una richiesta, mantiene lo stato in memoria e in un file SQLite locale, e semplicemente va in sleep quando è inattivo.

Il problema principale era la natura chiusa dell'ecosistema: eseguire una configurazione del genere al di fuori dell'infrastruttura di Cloudflare era praticamente impossibile fino ad ora.

Come funziona internamente celld

Gli sviluppatori di celld hanno puntato su una semplificazione radicale. L'architettura del nodo è composta da quattro componenti:

1. V8 embedded per l'esecuzione di codice JavaScript e TypeScript da bundle Wrangler.
2. SQLite locale per il file di database separato di ogni oggetto.
3. Storage compatibile con S3 (AWS S3, MinIO, Cloudflare R2) come unica fonte di verità.
4. Trasporto inter-server con firma HMAC per lo scambio di dati tra i nodi.

La soluzione più interessante qui è l'abbandono dei protocolli di consenso classici. I nodi del cluster non hanno bisogno di eleggere un leader o eseguire Consul.

Invece, i server comunicano con S3 attraverso un'operazione atomica Compare-And-Swap (CAS). Quando un nodo vuole prendere possesso di un oggetto, scrive un file di proprietà nel bucket S3. Chiunque riesca ad aggiornare il record tramite CAS per primo gestisce il traffico. Se un nodo si blocca, il timeout di scrittura scade e un server vicino raccoglie l'oggetto, scarica il suo database SQLite aggiornato dal bucket e continua a funzionare.

Lancio e deployment

Le build standard di Wrangler funzionano per compilare il progetto, ma avrai bisogno di un server con 5 e il binario stesso 6.

L'installazione viene eseguita con un singolo comando:

0

Il flusso di lavoro è diviso in due passaggi. Prima carica la build del worker nel bucket:

1

Quindi avvia il demone sul server:

2

Ogni nodo nel cluster legge il manifest 7 dal bucket. Se hai bisogno di avviare un server aggiuntivo, lanci un altro processo con lo stesso bucket e specifichi il suo indirizzo di rete in 8.

Riguardo alla sicurezza: il traffico inter-server di celld non crittografa TLS out of the box. Gli autori consigliano di posizionare le porte interne dei nodi dietro una rete overlay sicura come WireGuard o Tailscale. Tutte le richieste tra peer sono automaticamente firmate con una chiave HMAC 9 che il primo nodo crea automaticamente nel bucket.

Diagnostica e gestione del carico

Per il monitoraggio del cluster, c'è l'utility 10. Interroga i vicini e mostra le metriche correnti:

3

Il comando mostrerà il consumo di CPU, la memoria RSS, il numero di connessioni WebSocket attive e il conteggio degli oggetti attivi su ogni nodo.

Se un server inizia a sovraccaricarsi, celld ha un meccanismo di shedding della pressione per gli oggetti attivi. I limiti vengono impostati tramite variabili d'ambiente:

4

Quando la soglia viene superata, celld salva gli oggetti inattivi su S3, rilascia la proprietà e smette di accettare nuove entità fino a quando il carico non scende al valore di 11. Gli oggetti con richieste frequenti o connessioni WebSocket aperte non sono interessati.

Un approccio insolito al contributo

Se vai al repository 12 con l'intenzione di aprire una Pull Request, troverai il pulsante disabilitato. I fork sono permessi, ma le PR su GitHub sono completamente disabilitate.

Ryan Dahl spiega questo come una lotta contro lo spam degli agenti AI: rivedere enormi pull request auto-generate senza contesto richiede troppo tempo ai maintainer. A chi vuole inviare una patch viene chiesto di creare 13 e inviare il file via email all'indirizzo personale 14.

Chi dovrebbe dare un'occhiata a questo progetto

Il progetto è in sviluppo attivo, con le specifiche del protocollo archiviate direttamente nel codice del crate Rust 15. È troppo presto per integrarlo in produzione critica, ma sperimentare vale sicuramente la pena.

Lo strumento sarà utile nei seguenti casi:

1. Sviluppatori di servizi multiplayer, chat e CRM personalizzati.
2. Team che pianificano di allontanarsi dal lock-in di Cloudflare senza riscrivere il codice.
3. Appassionati dell'architettura con un database separato per ogni cliente-utente.
4. Ingegneri che imparano i sistemi distribuiti senza Raft ed Etcd.