Puppet è, oramai da diversi anni, uno degli strumenti migliori per definire l’installazione, la configurazione e, più in generale, lo stato di qualsiasi cosa su un server.
Un modulo puppet vi permette di installare, configurare, avviare velocemente il vostro web server (ad esempio), sia esso da configurare su una singola macchina o su 200; estremamente comodo.
In questi anni, però, con la presa di posizione sempre maggiore dei container, molti si sono chiesti come puppet si vada ad incastrare in questo nuovo modus-operandi: se prima era fondamentale per distribuire la stessa applicazione su gruppi di macchine differenti, adesso una volta pronta l’immagine del container è possibile farla girare ovunque, sia esso il proprio pc, il cluster Kubernetes, o un sistema Windows.
Qualche giorno fa, durante l’annuale PuppetConf, sono state presentate due nuove soluzioni che portano puppet in prima linea nella gestione dei containers: la Puppet Docker Image Build ed i Phased Deployments.
Grazie al nuovo modulo image_build sarà possibile, partendo da codice puppet, generare direttamente delle immagini da cui poter eseguire dei container. Anche se non lo abbiamo ancora provato direttamente, viene subito in mente come questo possa permettere di passare rapidamente da un ambiente di deploy normale ad uno su container, semplicemente riutilizzando il codice per generare delle immagini docker, invece che facendogli fare le attività direttamente sui server.
Ad esempio, con un semplice Puppetfile che identifichi le dipendenze:
$ cat Puppetfile
forge 'https://forgeapi.puppetlabs.com'
mod 'jfryman/nginx'
mod 'puppetlabs/stdlib'
mod 'puppetlabs/concat'
mod 'puppetlabs/apt'
mod 'puppetlabs/dummy_service'
un file di metadati in formato yaml (che identifica quei parametri tipici dei container):
cmd: nginx
expose: 80
image_name: puppet/nginx
ed un ancora più semplice file di codice puppet (il classico manifests/init.pp):
include 'dummy_service'
class { 'nginx': }
nginx::resource::vhost { 'default':
www_root => '/var/www/html',
}
file { '/var/www/html/index.html':
ensure => present,
content => 'Hello Puppet and Docker',
}
exec { 'Disable Nginx daemon mode':
path => '/bin',
command => 'echo "daemon off;" >> /etc/nginx/nginx.conf',
unless => 'grep "daemon off" /etc/nginx/nginx.conf',
}
E’ possibile generare rapidamente un’immagine con il comando
$ puppet docker build
E testarlo lanciando immediatamente un container:
$ docker run -d -p 8080:80 garethr/nginx-test
...
$ curl http://localhost:8080
Hello Puppet and Docker
$
Fantastico, personalmente non vedo l’ora di provarlo.
Ovviamente questa è solo la punta dell’iceberg: è possibile interfacciarsi con i comuni software che normalmente si usano in un ambiente puppet, come hiera ed r10k, così come generare più immagini da un singolo manifest ed utilizzare un puppet master per centralizzare la configurazione. Insomma, l’unica limitazione è che al momento non è possibile creare container Windows o creare immagini da macchine Windows, ma ce ne faremo una ragione 🙂
Un’altra feature introdotta, questa volta all’interno di Puppet Enterprise, sono i Phased Deployments. Praticamente, Puppet Enterprise permetterà di segmentare l’infrastruttura e le applicazioni tramite i facts salvati in puppet stesso, e deployare le modifiche alla stessa su solo alcuni di questi segmenti.
You can’t go in and make changes to your infrastructure unless you have a firm grasp of what is happening in your environment. What we allow is a rich set of data within our system, and we are making it really easy for Puppet users to access that data and use that to target deployments.
Non puoi entrare e fare modifiche alla tua infrastruttura fino a che non hai una presa salda su cosa sta succedendo nel tuo ambiente. Quello che forniamo è un ricco gruppo di dati attraverso il nostro sistema, e rendiamo molto semplice per gli utenti Puppet accedere a quei dati ed usarli per indirizzare i rilasci.
Questo quanto affermato da Tim Zonca, vicepresidente del marketing di prodotto per Puppet. Personalmente, già abbiamo visto situazioni simili create tramite l’utilizzo di variabili e facts customizzati sugli host, ma probabilmente le novità saranno accompagnate da una gestione semplificata tramite interfacccia web e la disponibilità out-of-the-box di quanto prima veniva fatto a mano.
Sempre più integrazione tra configuration management e container, dunque, ed amando entrambi quei mondi, non vediamo l’ora di testare le novità a disposizione.
Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.
Lascia un commento