Dalla shell script alla configurazione dichiarativa
Gestire la configurazione di decine o centinaia di server Linux attraverso shell script e file di template manualmente sincronizzati diventa, oltre una certa scala, insostenibile. La comunità di system administration ha cercato risposte a questa esigenza fin dagli anni ‘90 con strumenti come CFEngine (Mark Burgess, 1993), poi evoluto con bcfg2 e con l’emergere del tema Infrastructure as Code.
Puppet — sviluppato da Luke Kanies e dalla sua azienda Reductive Labs (poi rinominata Puppet Labs nel 2010) — ha preso forma dal 2005 come risposta moderna al problema. Scritto in Ruby, Puppet propone un modello dichiarativo: l’amministratore descrive lo stato desiderato della macchina, non i passaggi per arrivarci.
La versione 0.24.6, rilasciata il 3 aprile 2009, consolida un anno di miglioramenti stabilizzando la serie 0.24 come release maturazione di riferimento al 2009. La licenza è GPLv2 (con transizione ad Apache 2.0 nelle release successive).
Il modello dichiarativo
Il DSL di Puppet descrive risorse — unità fondamentali di configurazione — con un modello ensure/state:
package { 'nginx':
ensure => present,
}
file { '/etc/nginx/nginx.conf':
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
content => template('nginx/nginx.conf.erb'),
require => Package['nginx'],
notify => Service['nginx'],
}
service { 'nginx':
ensure => running,
enable => true,
require => Package['nginx'],
}Puppet analizza il manifest, costruisce un catalog con le dipendenze tra risorse, e applica le modifiche necessarie. Se il sistema è già nello stato desiderato, Puppet non fa nulla — idempotenza nativa.
L’architettura agent/master
Al 2009 Puppet usa un’architettura client/server:
- Puppet Master — server centrale che compila i manifest in catalog per ciascun nodo. Tipicamente un’applicazione WEBrick o Passenger/Apache
- Puppet Agent — demone su ogni nodo gestito; ogni 30 minuti (default) contatta il master, scarica il catalog, applica le modifiche, invia un report
- Facter — strumento di introspezione che raccoglie facts del sistema (OS, kernel, interface di rete, RAM, CPU) resi disponibili nei manifest
- Foreman (plugin) — interfaccia web per gestione nodi, dashboard, reporting
I manifest sono versionabili in Git/Subversion, recensibili, testabili. Il concetto di configurazione come codice inizia a consolidarsi.
Moduli e ecosistema
La 0.24 ha stabilito il pattern dei moduli Puppet — pacchetti riutilizzabili che incapsulano la configurazione di un componente specifico (Apache, MySQL, PostgreSQL, PHP, Postfix, BIND, …). L’archivio centrale Puppet Forge sarà lanciato nel 2010-2011, diventando il catalogo ufficiale di moduli condivisi dalla community.
Al 2009 esistono già decine di moduli community disponibili, condivisi via GitHub, blog, mailing list.
Concorrenti emergenti
Nel 2009 il campo IaC è in formazione:
- Puppet — dominante a quel momento, modello agent/master, Ruby DSL dichiarativo
- CFEngine 3 — rilasciata nel 2008-2009, precursore storico con filosofia promise theory
- Chef — in preparazione da Opscode (fondata 2008 da Adam Jacob), prima release pubblica gennaio 2009. Modello Ruby più imperativo di Puppet
- bcfg2 — Argonne National Laboratory, meno diffuso
- Salt — Thomas S. Hatch, primo commit nel 2011 (non ancora esiste al 2009)
- Ansible — Michael DeHaan, primo commit febbraio 2012 (non ancora esiste)
Puppet ha il vantaggio della prima mossa e di una community costruita; Chef arriva con un modello leggermente diverso (ricette Ruby più DSL) e conquisterà rapidamente la comunità DevOps nascente. Salt e Ansible entreranno dopo con filosofie agentless. Il mercato IaC tra 2009 e 2015 sarà dominato dalla competizione Puppet vs. Chef.
Adozione istituzionale
Al 2009 Puppet ha adottatori rilevanti:
- Google — uso interno per configurazione di parti dell’infrastruttura di produzione
- Red Hat — integra Puppet in Satellite (per configuration management di RHEL)
- Stanford University — gestione dei server di campus
- Twitter — primi deployment (crescente poi verso Chef)
- Wikipedia (WMF) — parziale
Nel contesto italiano
Al 2009 l’adozione italiana di Puppet è ancora molto nichée:
- System administrator con cluster di server Linux su larga scala
- Provider di hosting che gestiscono centinaia di VM
- Università e centri di ricerca con parchi server consistenti (INFN, CNR, CNAF)
- Startup con ambienti cloud Amazon EC2 — Puppet risolve il problema di provisioning di istanze nuove
L’adozione crescerà tra 2010 e 2013 con la diffusione del modello DevOps e con Chef come concorrente, portando molti team a adottare strumenti IaC come standard di pratica.
Il messaggio di Puppet
L’eredità concettuale di Puppet — dichiaratività, idempotenza, catalog come rappresentazione dello stato desiderato, Facter come introspezione — rimarrà stabile anche nel passaggio all’epoca container (Kubernetes porta la stessa filosofia su un dominio diverso: pod e service desiderati invece di pacchetti e file). L’idea che la configurazione sia codice versionato e revisionato diventerà pratica universale nel decennio successivo.
Riferimenti: Puppet 0.24.x (2008-2009), Luke Kanies, Reductive Labs / Puppet Labs. Licenza GPLv2. Facter per introspezione. Apache/Passenger, WEBrick come master. CFEngine come precursore storico. Chef (Opscode, gennaio 2009) come concorrente.