Puppet viene utilizzato per automatizzare diverse attività di configurazione di routine dell'amministratore di sistema.
Puppet in un sistema di gestione della configurazione di livello aziendale.
Ti permette di definire lo stato della tua infrastruttura IT. Una volta definito, Puppet applicherà automaticamente lo stato corretto su base continuativa.
1. Architettura dei burattini
Puppet ha in genere un componente server e più agenti. Devi designare un server sulla tua rete come burattinaio e ogni nodo sulla tua rete avrà un agente burattino installato su di esso.
Il modo più comune per applicare la configurazione del pupazzo a un client consiste nell'utilizzare il daemon del puppet master (puppetmasterd) e il daemon del client del puppet (puppetd). Puoi anche applicare manualmente i manifest utilizzando lo strumento pupazzo.
La configurazione viene definita sul puppet master, compilata e quindi inviata automaticamente ai client puppet quando si connettono.
Puppet supporta un'ampia gamma di piattaforme e sistemi operativi differenti ed eseguirà automaticamente i comandi appropriati per applicare il tuo manifest in ogni ambiente.
Un manifest non è altro che dettagli su file, pacchetti, operazioni di configurazione scritte in un linguaggio comprensibile a puppet.
Ogni nodo Puppet contatta il burattinaio, per impostazione predefinita ogni 30 minuti, per confermare che la sua configurazione sia aggiornata. Se la configurazione è diversa o è disponibile una nuova configurazione, viene ricompilata e quindi applicata al nodo pupazzo.
In questo tutorial spiegheremo come creare alcuni manifest di base e applicarli ai client utilizzando lo strumento pupazzo.
La maggior parte della configurazione del sistema può essere visualizzata utilizzando lo strumento della riga di comando pupazzo. Tutti i componenti di configurazione sono organizzati in risorse. Le risorse sono raggruppate in raccolte. Le risorse sono costituite da tipo, titolo e serie di attributi.
2. Esempio di file di risorse del pupazzo
Quello che segue è un esempio di base su come visualizzare una risorsa pupazzo. In questo caso, la risorsa pupazzo che stiamo visualizzando è un file (/etc/nsswitch).
# puppet resource file /etc/nsswitch.conf
file { '/etc/nsswitch.conf':
ensure => 'file',
content => '{md5}0d6009cdfd12646d251e86303bc0c48c',
ctime => 'Sun May 18 13:20:02 -0400 2014',
group => '0',
mode => '644',
mtime => 'Tue May 04 15:22:21 -0400 2010',
owner => '0',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
type => 'file',
}
Puppet viene fornito con una serie di tipi di risorse per impostazione predefinita, inclusi tipi per gestire file, servizi, pacchetti, lavori cron e filesystem, tra gli altri.
Nell'esempio precedente, file è il tipo di risorsa e /etc/nsswitch.conf è il titolo della risorsa da gestire.
Tutto il resto sono attributi del tipo di risorsa e valori presenti negli attributi. Puoi anche estendere il pupazzo per aggiungere i tuoi tipi di risorse.
Per visualizzare tutti i tipi di risorse disponibili utilizzare il seguente comando:
# puppet resource --types augeas computer cron exec file filebucket group host nagios_hostdepend .. ..
3. Esempio di file manifest del pupazzo
Diamo un'occhiata a come creare un semplice file manifest ed eseguire il comando puppet per applicare la configurazione al server.
L'esempio seguente crea un semplice file manifest site.pp nella directory /etc/puppet/manifests che creerà un file di test in /var/tmp.
Inizialmente, come vediamo di seguito, non abbiamo il file di prova.
# ls -ld /var/tmp/testfile ls: cannot access /var/tmp/testfile: No such file or directory
Quella che segue è la dichiarazione della risorsa all'interno del file manifest (site.pp):
# cat site.pp
file { "/var/tmp/testfile":
ensure => "present",
owner => "root",
group => "root",
mode => "664",
content => "This is a test file created using puppet.
Puppet is really cool",
}
A scopo dimostrativo, stiamo eseguendo il burattinaio e l'agente sullo stesso nodo.
Quando esegui il comando puppet apply per la prima volta con l'opzione –noop, verrà eseguito un test senza applicare effettivamente la configurazione.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.06 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: current_value absent, should be present (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.03 seconds
Quanto sopra per vedere cosa farà la nuova configurazione senza apportare modifiche al nodo.
Ora, esegui il comando senza l'opzione –noop per applicare davvero la configurazione come mostrato di seguito.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: created Notice: Finished catalog run in 0.05 seconds
Una volta eseguito correttamente, vedrai il nuovo file temporaneo creato in /var/tmp/testfile con i contenuti definiti in site.pp.
# ls -ld /var/tmp/testfile -rw-rw-r--. 1 root root 69 Jun 26 14:25 /var/tmp/testfile # cat /var/tmp/testfile This is a test file created using puppet. Puppet is really cool
4. Controlla un servizio su un nodo remoto usando Puppet
Di seguito è riportato un esempio per modificare il servizio dallo stato interrotto allo stato in esecuzione sui nodi dell'agente.
Quando questo manifesto di configurazione viene salvato nel server master in una posizione specifica nella directory di configurazione del pupazzo, l'agente in esecuzione su tutti i nodi contatta il nodo master e recupera la configurazione e la applica a tutti i nodi client in modo che in questo modo il servizio venga avviato su tutti i nodi agente dopo che la configurazione del pupazzo è stata eseguita correttamente.
# puppet resource service multipathd
service { 'multipathd':
ensure => 'stopped',
enable => 'false',
}
In questo esempio, controlleremo il servizio multipathd. Puoi utilizzare puppet per controllare tutti i servizi in esecuzione sul sistema. Ad esempio, httpd, mysqld, ecc.
# puppet resource service multipathd > site.pp
Assicurati che site.pp abbia i seguenti valori. In caso contrario, modificalo di conseguenza.
# vi site.pp
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
Per prima cosa fai una prova per assicurarti che funzioni come previsto.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/Service[multipathd]/ensure: current_value stopped, should be running (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.06 seconds
Infine, applica il file di configurazione, che avvierà il servizio (in questo esempio multipathd), se non è già in esecuzione.
# puppet apply site.pp
Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds
Notice: /Stage[main]/Main/Service[multipathd]/ensure: ensure changed 'stopped' to 'running'
Notice: Finished catalog run in 0.28 seconds
# puppet resource service multipathd
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
# chkconfig --list | grep multipath
multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
5. Installa un pacchetto su un nodo remoto utilizzando Puppet
È possibile eseguire l'installazione del pacchetto su tutti i nodi dell'agente in remoto utilizzando puppet.
Quello che segue è un file manifest di esempio per l'installazione del pacchetto.
# cat site.pp
package { 'httpd':
ensure => 'present',
}
In questo esempio, installerà il pacchetto Apache httpd se non è presente sul sito remoto. Come vedi sotto, ha installato il pacchetto.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.70 seconds Notice: /Stage[main]/Main/Package[httpd]/ensure: created Notice: Finished catalog run in 79.97 seconds
Verifica che il pacchetto sia installato correttamente utilizzando il comando rpm.
# rpm -qa | grep -i httpd httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
6. Due tipi di raccolte di pupazzi
Le risorse possono configurare le caratteristiche dei singoli elementi di configurazione sui nodi. Tuttavia, la maggior parte dei servizi e delle applicazioni è costituita da più risorse.
Ad esempio, un server Web è costituito dal pacchetto software, dagli utenti che eseguono il software e da una serie di file di configurazione, registrazione e altri file.
Le raccolte di risorse consentono di raccogliere le risorse, assegnarle alla raccolta e applicare la raccolta ai nodi dell'agente.
Esistono 2 tipi di raccolta di risorse:
- Classi
- Definizioni
7. Esempio di raccolta di classi di pupazzi
Una classe è una raccolta di risorse che rappresenta un singolo elemento di configurazione sul tuo nodo mentre la definizione è un insieme di elementi di configurazione che hanno più rappresentazioni sul tuo nodo.
Nell'esempio precedente, dopo l'installazione del pacchetto, i servizi non vengono avviati per impostazione predefinita. Possiamo creare un semplice manifest con classe per installare il pacchetto e avviare il servizio dopo l'installazione.
Nell'esempio seguente abbiamo specificato la relazione tra due risorse utilizzando l'attributo require.
# cat site.pp
class apache {
package { 'httpd':
ensure => 'present',
}
service {'httpd':
ensure => 'running',
require => Package["httpd"],
}
}
include apache
Ciò garantisce che la condizione sia soddisfatta prima che le modifiche alle risorse vengano applicate. In questo caso il servizio httpd richiede che il pacchetto httpd sia installato prima di poter tentare di richiamare i servizi.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.93 seconds Notice: /Stage[main]/Apache/Package[httpd]/ensure: created Notice: /Stage[main]/Apache/Service[httpd]/ensure: ensure changed 'stopped' to 'running' Notice: Finished catalog run in 32.82 seconds # chkconfig --list | grep http httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off # rpm -qa | grep -i http httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
8. Esempio di raccolta di definizioni di pupazzi
Una definizione è un tipo di raccolta di risorse pupazzo.
Le definizioni devono essere utilizzate per elementi di configurazione che hanno più istanze su un nodo.
Ad esempio, il server httpd può avere più host virtuali definiti. È possibile creare una definizione per configurare gli host virtuali e passare argomenti appropriati per configurarli. Finché ogni serie di argomenti era diversa, puppet configurava il nuovo host virtuale ogni volta che veniva valutata la definizione.
Quello che segue è un esempio di un semplice manifest con una classe e una definizione.
# cat site1.pp
class testdefine {
define testdefine ($data) {
file {"$title":
ensure => file,
content => $data,
}
}
testdefine {'/var/tmp/puppetfile1':
data => "The name of the file is puppetfile1 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile2':
data => "The name of the file is puppetfile2 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile3':
data => "The name of the file is puppetfile3 and it is created by puppet\n",
}
}
include testdefine
Esegui la classe del pupazzo sopra e il manifesto della definizione come mostrato di seguito.
# puppet apply site1.pp
Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.24 seconds
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile2]/File[/var/tmp/puppetfile2]/ensure: defined content as '{md5}9079bd9c7650ae7d503c7df1a68bb9f0'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile3]/File[/var/tmp/puppetfile3]/ensure: defined content as '{md5}75d495f0d3180b1f2dd052ac208d81fe'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile1]/File[/var/tmp/puppetfile1]/ensure: defined content as '{md5}1fa93f1f2b82f8358866d58b2cb2f0b4'
Notice: Finished catalog run in 0.19 seconds
# ls -l /var/tmp/puppetfile*
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile1
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile2
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile3
# cat /var/tmp/puppetfile*
The name of the file is puppetfile1 and it is created by puppet
The name of the file is puppetfile2 and it is created by puppet
The name of the file is puppetfile3 and it is created by puppet
9. Esempio di file di configurazione del nodo pupazzo
Finora abbiamo visto definire risorse e raccolte di risorse sotto forma di classi e definizioni.
Ora il passaggio successivo è come assegnare queste risorse e raccolte ai clienti.
Ecco un esempio di come vengono definiti i nodi in node.pp.
Puppet usa questo file per determinare quale classe (contiene risorse) dovrebbe andare a quale server, ad esempio, sul client 1 vuoi eseguire la classe httpd che contiene risorse come il pacchetto httpd, il servizio httpd e sul client 2 vuoi eseguire la classe ngnix che contiene risorse come il pacchetto ngnix, il servizio ngnix e altri file di configurazione di ngnix.
Il seguente file nodes.pp di esempio spiega questo:
node 'puppetclient1.mydomain.net' {
include httpd_class
}
node 'puppetclient2.mydomain.net' {
include ngnix_class
}
node default {
package { "perl":
ensure => present }
}
All'interno della definizione del tuo nodo, puoi aggiungere risorse, classi e definizioni.
Le classi vengono aggiunte utilizzando la funzione include.
In puppetclient1.mydomain.net abbiamo incluso httpd_class e in puppetclient2.mydomain.net abbiamo incluso ngnix_class.
Puoi anche includere più classi con una singola funzione di inclusione. Se nessuna definizione di nodo corrisponde, prende i valori predefiniti definiti. In questo caso, se ci sono altri nodi, installerà semplicemente i pacchetti perl se non è presente.
10. Importa file manifest dei pupazzi
Le risorse, le classi e le definizioni sono archiviate in file manifest.
Uno speciale file manifest, chiamato site manifest, è al centro della nostra configurazione.
Quando si avvia il demone Puppet master, il file manifest del sito, che per impostazione predefinita si trova in /etc/puppet/manifests/site.pp, deve essere presente.
Negli esempi precedenti, abbiamo utilizzato site.pp solo per spiegare come applicare i manifesti.
In un vero e proprio ambiente burattino il tuo site.pp avrà solo i contenuti sottostanti e da questo file gli altri file vengono importati per l'esecuzione.
# cat site.pp import "templates.pp" import "nodes.pp" import "classes/*" import "groups/*" import "users/*" import "os/*"
Quella che segue è la struttura della directory manifest del pupazzo:
- /manifests/classes/ – Directory contenente tutte le classi
- /manifests/site.pp – il file manifest principale
- /manifests/templates.pp – Contiene nodi modello
- /manifests/nodes.pp – Contiene le definizioni dei nodi
- /manifests/definitions/ – Contiene tutte le definizioni
- /manifests/groups/ – Contiene manifest che configurano i gruppi
- /manifests/os/ – Contiene classi progettate per configurare nodi con particolari sistemi operativi
- /manifests/users/ – Contiene manifest per la configurazione degli utenti
- /manifest/files/ – Contiene i moduli del file server per i file distribuibili Puppet