Una risposta alla lentezza del CM esistente
Nel 2011 il panorama Infrastructure as Code è dominato da Puppet e Chef, entrambi basati su modelli Ruby e architetture di polling periodico. Thomas S. Hatch, amministratore di sistema, aveva bisogno di uno strumento con una caratteristica specifica: velocità di esecuzione di comandi paralleli su centinaia di server contemporaneamente.
Da questa esigenza nasce Salt (originariamente Salt Stack), progetto Open Source in Python il cui primo commit pubblico è del febbraio 2011. Nei mesi successivi la release 0.8-0.9 (estate-autunno 2011) consolida le funzionalità core. Licenza Apache 2.0.
L’architettura
Salt adotta un modello master/minion simile a Puppet, ma con differenze sostanziali:
- Trasporto via ZeroMQ — pattern pub/sub ad alta performance, invece di HTTP/REST del modello Puppet. Comandi asincroni, risposte aggregate in streaming
- Minion persistent connection — ogni minion mantiene una connessione TCP con il master, eliminando l’overhead di handshake
- Broadcast — il master può emettere un comando a tutti i minion simultaneamente con latenza sub-secondo
- Grains (analogo a Facter di Puppet) — sistema di introspezione del minion, usato per targeting di comandi
- Pillars — data store separato per secrets e configurazioni per-host
Il risultato pratico: eseguire salt '*' cmd.run 'uptime' su 1000 nodi richiede secondi, non minuti.
Due paradigmi: execution modules e states
Salt espone due modalità complementari:
Execution modules — imperativo
Comandi ad-hoc eseguiti su minion target via CLI salt:
salt 'web*' pkg.install nginx
salt 'web*' service.restart nginx
salt '*' cmd.run 'uptime'Centinaia di moduli (pkg, service, file, cmd, user, network, mysql, postgres, apache, selinux, grains, …) coprono task operativi comuni.
States — dichiarativo
Configurazione desiderata descritta in file YAML/Jinja2 (.sls — SaLt State):
nginx:
pkg.installed: []
service.running:
- enable: True
- require:
- pkg: nginx
/etc/nginx/nginx.conf:
file.managed:
- source: salt://nginx/nginx.conf
- require:
- pkg: nginx
- watch_in:
- service: nginxI state sono analoghi ai manifest Puppet o ai ricettari Chef, ma con sintassi YAML invece che DSL. Il vantaggio: familiarità per molti sysadmin già abituati a file YAML.
Orchestration
Salt introduce il concetto di orchestration: stati che coordinano azioni su più minion in sequenza, utile per deployment complessi (es. update rolling con bilanciatore, migrazione database con failover). Orchestration è scritta come state sul master, non sui minion, e usa il modulo salt.state per invocare esecuzioni remote.
Il confronto con Puppet e Chef
Salt vs. Puppet:
- Puppet: Ruby, polling periodico, DSL custom
- Salt: Python, push/pub-sub, YAML
Salt vs. Chef:
- Chef: Ruby, pull model, client/server
- Salt: Python, push/pub-sub
Salt vs. Ansible (Ansible esce a febbraio 2012):
- Ansible: Python, agentless su SSH
- Salt: agent dedicato, più veloce su scala ma più invasivo
Ogni strumento ha trade-off: Salt vince in scalabilità e immediatezza delle operazioni ad-hoc; perde contro Ansible sulla semplicità di setup (no installazione su target).
L’azienda
Thomas Hatch sta costituendo una società dedicata allo sviluppo commerciale di Salt con un modello open core: core Open Source + edizione enterprise con GUI, reporting e compliance.
Adozione
Salt attira rapidamente adozione in contesti con forte esigenza di scala:
- LinkedIn — gestione infrastruttura interna
- Apple — alcune infrastrutture operative
- Cisco — network automation
- VMware stessa (prima dell’acquisizione) — alcune divisioni
- Provider di hosting europei — gestione di flotte massive di VM
Nel contesto italiano
Al 2011 Salt è appena nato; l’adozione italiana è sperimentale. È plausibile trovi spazio in provider di hosting, telco e università con cluster HPC nei prossimi anni.
Puppet e Chef restano più diffusi in generale; Salt punta a ritagliarsi nicchie dove la velocità di esecuzione conta.
Riferimenti: Salt (SaltStack), Thomas S. Hatch, primo commit febbraio 2011. Licenza Apache 2.0. Trasporto ZeroMQ. Grain/Pillar system.