// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

clickhousectl: un coding agent costruisce un ClickStack distribuito su tre continenti

Con una sola CLI che risponde in JSON, un agent ha provisionato tre servizi ClickHouse Cloud e una vista globale. La tesi: l’interfaccia decide quanto può automatizzare un agent.

L’esperimento di ClickHouse è meno interessante per il risultato che per la tesi che lo sostiene: l’interfaccia che una piattaforma espone decide quanto lavoro un agent può toglierti dalle mani. L’autore ha dato a un coding agent un solo strumento, la CLI clickhousectl, e un obiettivo: una piattaforma di observability multi-regione con tre servizi ClickHouse Cloud in US, Europa e Giappone, ciascuno con ingestion OpenTelemetry locale e una vista globale in Europa.

L’architettura

L’ingestion è regionale e autocontenuta: in ogni regione l’app manda dati OTel a un collector locale che scrive nel servizio ClickHouse accanto. Nulla attraversa un confine sul write path, un requisito tipico per latenza e compliance. L’Europa fa un lavoro in più: ospita un database otel_global che presenta le tre regioni come un unico set di tabelle. Due feature ordinarie fanno tutto: remoteSecure(), un puntatore sicuro a una tabella su un altro servizio che recupera le righe a query time, e il motore Merge, che espone più tabelle come una sola. Una query sui dati EU resta in Europa; US e Giappone vengono contattati solo quando servono davvero.

Perché la CLI cambia le cose

Per un servizio si poteva cliccare nella console Cloud. Per tre servizi in tre regioni, ciascuno con connessioni e SQL propri, cliccare è lo strumento sbagliato. Un agent con la CLI scrive un loop sulle regioni, chiama service create, fa il parsing del JSON con jq per estrarre id ed endpoint, poi fa polling su service get finché ogni servizio è running prima di procedere. Lo script diventa la documentazione: rieseguilo e ottieni gli stessi tre servizi.

Tre proprietà hanno reso clickhousectl facile da delegare. È sicura di default: da login browser l’agent ha accesso in lettura, ma serve una API key per creare o cancellare. È un unico strumento dal laptop alla produzione, senza cambi di contesto tra locale e cloud. E sparisce dentro l’automazione: i comandi eseguiti a mano sono gli stessi che una pipeline può lanciare alle 3 del mattino. Così l’agent tratta l’infrastruttura come un altro pezzo di codebase: da scriptare, revisionare e rieseguire senza sorprese.

In sintesi

  • Un agent ha provisionato tre servizi ClickHouse Cloud e una vista globale via CLI, in un pomeriggio.
  • remoteSecure() e il motore Merge federano le regioni mantenendo i dati residenti dove nascono.
  • La tesi: una buona CLI che risponde in JSON è spesso una migliore agent experience di una UI curata.

Fonte: Agentic infrastructure with clickhousectl: a distributed ClickStack across three continents — https://clickhouse.com/blog/agentic-infrastructure-clickhousectl-distributed-clickstack

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma