Per utilizzare Puppet in modo più efficiente, devi capire come vengono creati moduli e manifest. Questo tutorial ti guiderà attraverso il funzionamento di questi componenti Puppet impostando uno stack LAMP su un server Ubuntu 14.04.

Requisiti

• Installazione di Puppet (master e agente). Maggiori informazioni -.
• Possibilità di creare almeno un server virtuale Ubuntu 14.04 per servire il nodo agente Puppet.

Nozioni di base sul codice delle marionette

risorse

Il codice del burattino è costituito principalmente da risorse. Una risorsa è una parte di codice che descrive lo stato del sistema e determina le modifiche necessarie. Ad esempio:

utente ("mitchell":
assicurare => presente,
uid => "1000",
gid => "1000",
shell => "/ bin / bash",
home => "/ casa / mitchell"
}

Una dichiarazione di risorsa ha il seguente formato:

tipo_risorsa ("nome_risorsa"
attributo => valore
...
}

Per visualizzare tutti i tipi di risorse Puppet, inserisci il comando:

risorsa fantoccio --types

Imparerai di più sui tipi di risorse in questa guida.

manifesti

Un manifest è uno script di orchestrazione. I programmi fantoccio con estensione .pp sono chiamati manifest. Il manifest predefinito di Puppet è /etc/puppet/manifests/site.pp.

Classi

Come con qualsiasi linguaggio di programmazione convenzionale, le classi sono responsabili dell'organizzazione e del riutilizzo di parti di un'orchestrazione.

La definizione della classe contiene un blocco di codice che descrive come funziona la classe. Una volta definita una classe, puoi usarla nei tuoi manifest.

La definizione della classe ha il seguente formato:

classe classe_esempio (
...
codice
...
}

Questo codice definisce la classe example_class. Il codice Puppet sarà tra parentesi graffe.

Una dichiarazione di classe è il punto in cui viene chiamata una classe particolare nel codice. Dichiarando una classe, Puppet elabora il suo codice.

Una dichiarazione di classe può essere ordinaria e per tipo di risorsa.

Una normale dichiarazione di classe viene aggiunta al codice utilizzando la parola chiave include.

includi classe_esempio

Quando dichiarata per tipo di risorsa, la classe viene dichiarata nel formato risorsa:

classe ("classe_esempio":)

Questa dichiarazione consente di aggiungere parametri di classe al codice che sovrascrivono i valori degli attributi di classe standard. Ad esempio:

nodo "host2" (
class ("apache":) # usa il modulo apache
apache :: vhost ("esempio.com": # definisce la risorsa vhost
porta => "80",
docroot => "/var/www/html"
}
}

Moduli

Un modulo è un gruppo di manifest e altri file organizzati in un modo predefinito che semplifica la condivisione e il riutilizzo di parti separate dell'orchestrazione. I moduli ti aiutano a organizzare il tuo codice Puppet perché puoi usarli per dividere il tuo codice in più manifest.

I moduli pupazzo sono memorizzati nella directory /etc/puppet/modules.

Scrivere un manifesto

Puoi esercitarti a scrivere manifest, moduli e classi Puppet usando l'esempio dell'installazione di uno stack LAMP su un server Ubuntu (di conseguenza).

Quindi, per orchestrare un server Ubuntu 14.04 e installare uno stack LAMP su di esso, hai bisogno di risorse per fare cose come questa:

• installazione del pacchetto apache2.
• avviare il servizio apache2.
• installando il pacchetto del server MySQL, mysql-server.
• avviare il servizio mysql.
• installazione del pacchetto php5
• creazione di uno script di test PHP, info.php.
• aggiornando l'indice apt prima di installare ogni pacchetto.

Di seguito troverai tre esempi di codice Puppet con cui puoi ottenere una tale configurazione dello stack LAMP.

Il primo esempio ti insegnerà come scrivere i manifest di base in un file. Il secondo esempio ti aiuterà a creare e utilizzare una classe e un modulo basati su manifest scritti in precedenza. Nel terzo esempio imparerai come utilizzare i moduli pubblici predefiniti per installare uno stack LAMP.

Nota: Meglio usare un nuovo server virtuale per i test.

Esempio 1: installazione di LAMP con un singolo manifest

Il manifest del puppet può essere scritto sul nodo dell'agente e quindi eseguito utilizzando il comando di applicazione del puppet (non è necessario disporre di una procedura guidata e di un'installazione dell'agente per questo).

In questa sezione imparerai come scrivere manifest che utilizzano questi tipi di dichiarazioni di risorse:

• exec: esegue i comandi.
• pacchetto: installa i pacchetti.
• servizio: gestione del servizio.
• file: gestione dei file.

Creare un manifesto

Crea un nuovo manifesto:

sudo vi /etc/puppet/manifests/lamp.pp

Aggiungi il codice seguente per dichiarare le risorse richieste.

# eseguendo il comando "apt-get update"
exec ("apt-update": # risorsa exec "apt-update"
command => "/ usr / bin / apt-get update" # comando che eseguirà questa risorsa
}
# installazione del pacchetto apache2
pacchetto ("apache2":
require => Exec ["apt-update"], # request "apt-update" prima di installare il pacchetto
garantire => installato,
}
# avvia il servizio apache2
servizio ("apache2":
assicurare => in esecuzione,
}
# installazione di mysql-server
pacchetto ("mysql-server":
require => Exec ["apt-update"], # request "apt-update" prima dell'installazione
garantire => installato,
}
# avvia il servizio mysql
servizio ("mysql":
assicurare => in esecuzione,
}
# installazione del pacchetto php5
pacchetto ("php5":
require => Exec ["apt-update"], # request "apt-update" prima dell'installazione
garantire => installato,
}
# avvia il servizio info.php
file ("/var/www/html/info.php":
assicurati => file,
contenuto => "", # codice phpinfo
require => Pacchetto ["apache2"], # richiesta per il pacchetto "apache2"
}

Applicazione di un manifest

Per utilizzare il nuovo manifest, immetti il ​​comando:

sudo burattino applica --test

Verrà prodotto un risultato volumetrico che mostra tutti i cambiamenti nello stato dell'ambiente. Se non ci sono errori nell'output, dovresti essere in grado di aprire il tuo indirizzo IP esterno o il nome di dominio in un browser. Sullo schermo viene visualizzata una pagina di test PHP con informazioni sullo stack. Ciò significa che Apache e PHP funzionano.

Lo stack LAMP è ora installato sul server utilizzando Puppet.

Questo è un manifest abbastanza semplice in quanto può essere eseguito sull'agente. Se non disponi di un master Puppet, gli altri nodi agente non saranno in grado di utilizzare questo manifest.

Il server master Puppet verifica le modifiche allo stato del server ogni 30 minuti.

Esempio 2: installazione di uno stack LAMP utilizzando un modulo

Ora prova a creare un modulo semplice basato sul manifest LAMP che hai scritto nella sezione precedente.

Per creare un modulo, crea una nuova directory nella directory dei moduli (il suo nome deve corrispondere al nome del modulo). Questa directory dovrebbe contenere la directory manifests e il file init.pp. Il file init.pp specifica la classe Puppet (il suo nome deve corrispondere anche al nome del modulo).

Creazione del modulo

Vai al server master Puppet e crea una struttura di directory per il modulo:

cd / etc / burattino / moduli
sudo mkdir -p lamp / manifest

Crea e apri il file init.pp nell'editor:

sudo vi lamp / manifests / init.pp

Inserisci la classe della lampada nel file:

lampada di classe (
}

Copia il contenuto del manifest dalla sezione 1 e incollalo nel blocco della classe lamp. Ora hai una definizione per la lampada di classe. Altri manifesti potranno usare questa classe come modulo.

Salva e chiudi il file.

Utilizzo di un modulo nel manifest principale

Ora puoi configurare il manifest principale e utilizzare il modulo lampada per installare lo stack LAMP sul server.

Sul server master Puppet, modifica il seguente file:

sudo vi /etc/puppet/manifests/site.pp

Molto probabilmente, il file è vuoto al momento. Aggiungi le seguenti righe ad esso:

nodo predefinito ()
nodo "lampada-1" (
}

Nota: Sostituisci lamp-1 con il nome host del tuo agente Puppet in cui desideri installare lo stack.

Il blocco del nodo ti consente di specificare il codice Puppet che si applicherà solo ad alcuni nodi.

Il blocco predefinito si applica a tutti i nodi agente che non dispongono di un blocco individuale (lasciarlo vuoto). Il blocco lamp-1 verrà applicato al nodo agent lamp-1.

Aggiungi la seguente riga a questo blocco, che utilizza il modulo lampada:

Salva e chiudi il file.

Il nodo dell'agente Puppet sarà ora in grado di scaricare le impostazioni dal server master e installare lo stack LAMP. Se vuoi apportare modifiche in questo momento, esegui il comando sull'agente:

sudo puppet agent --test

I moduli sono il modo più conveniente per riutilizzare il codice Puppet. Inoltre, i moduli ti aiutano a organizzare il tuo codice in modo logico.

Esempio 3: installazione di LAMP utilizzando moduli disponibili pubblicamente

Il modulo MySQL viene utilizzato in modo simile. Aggiungi le seguenti righe al blocco del nodo:

classe ("mysql :: server":
root_password => "password",
}

Puoi anche passare i parametri a un modulo MySQL.

Aggiungi una risorsa che copierà info.php nella posizione corretta. Usa il parametro di origine. Aggiungi le seguenti righe al blocco del nodo:

file ("info.php": # nome file risorsa
percorso => ​​"/var/www/html/info.php", # percorso di destinazione
assicurati => file,
require => Class ["apache"], # la classe apache da usare
source => "puppet: ///modules/apache/info.php", # dove vuoi copiare il file
}

Questa dichiarazione di classe usa il parametro source invece del parametro content. Questa opzione non solo utilizza il contenuto del file, ma lo copia anche.

File pupazzo: ///modules/apache/info.php Puppet verrà copiato in /etc/puppet/modules/apache/files/info.php.

Salva e chiudi il file.

Crea il file info.php.

sudo sh -c "eco""> /etc/puppet/modules/apache/files/info.php"

Il nodo dell'agente Puppet sarà ora in grado di scaricare le impostazioni dal server master e installare lo stack LAMP. Se desideri apportare modifiche all'ambiente dell'agente in questo momento, esegui il comando su questo nodo:

sudo puppet agent --test

Questo comando scaricherà tutti gli aggiornamenti per il nodo corrente e installerà lo stack su di esso. Per verificare che Apache e PHP funzionino, apri l'indirizzo IP o il dominio del nodo in un browser:

http: //lamp_1_IP_pubblico/info.php

Conclusione

Ora hai una conoscenza di base dei moduli e dei manifesti Puppet. Prova a creare un semplice manifest e un modulo da solo.

Puppet è ottimo per gestire i file di configurazione dell'applicazione.

tag:,

Fantoccioè un framework multipiattaforma che consente agli amministratori di sistema di eseguire attività comuni utilizzando il codice. Il codice consente di eseguire una serie di attività dall'installazione di nuovi programmi alla verifica delle autorizzazioni dei file o all'aggiornamento degli account utente. Fantoccioè eccellente non solo durante la prima installazione del sistema, ma anche durante l'intero ciclo di vita del sistema. Nella maggior parte dei casi fantoccio utilizzato nella configurazione client/server.

Questa sezione mostra l'installazione e la configurazione Fantoccio nella configurazione client/server. Questo semplice esempio mostra come installare Apache usando Fantoccio.

Installazione

Per l'installazione Fantoccio inserisci nel terminale:

Sudo apt-get install puppetmaster

Sul computer (o sui computer) client inserire:

Sudo apt-get install puppet

personalizzazione

Prima di configurare il pupazzo, potresti voler aggiungere una voce DNS CNAME per burattino.esempio.com, dove esempio.comè il tuo dominio Client predefiniti Fantoccio controlla DNS per puppet.example.com come nome del burattino del server ( Burattinaio). Vedere Domain Name Service per maggiori dettagli sull'utilizzo del DNS.

Se non si intende utilizzare il DNS, è possibile aggiungere voci al file /etc/hosts sul server e sul client. Ad esempio, nel file /etc/hosts Fantoccio il server aggiunge:

127.0.0.1 localhost.localdomain localhost pupazzo 192.168.1.17 meercat02.example.com meercat02

Su ciascun Fantoccio client aggiunge una voce per il server:

192.168.1.16 meercat.example.com burattino suricato

Sostituisci gli indirizzi IP e i nomi di dominio dell'esempio con i tuoi indirizzi e nomi di server e client effettivi.

Ora impostiamo alcune risorse per apache2... Crea un file /etc/puppet/manifests/site.pp contenente quanto segue:

Pacchetto ("apache2": garantire => installato) servizio ("apache2": garantire => vero, abilitare => vero, richiedere => Pacchetto ["apache2"])

Nodo "meercat02.example.com" (includere apache2)

Sostituire meercat02.esempio.com al nome effettivo del tuo Fantoccio cliente.

Il passo finale per questo semplice Fantoccio il server sta riavviando il servizio:

Sudo /etc/init.d/puppetmaster restart

Ora su Fantoccio tutto è configurato sul server ed è ora di configurare il client.

Per prima cosa, impostiamo il servizio Fantoccio agente da eseguire. Modifica / etc / default / pupazzo sostituendo il valore INIZIO sul sì:

Sudo /etc/init.d/puppet start

Torna a Fantoccio server per firmare il certificato client utilizzando il comando:

Sudo puppetca --sign meercat02.example.com

Dai un'occhiata /var/log/syslog per eventuali errori di configurazione. Se tutto è andato bene, il pacco apache2 e le sue dipendenze verranno installate su Fantoccio cliente.

Questo esempio è molto semplice e non mostra molte caratteristiche e vantaggi. Fantoccio... Per ulteriori informazioni, vedere

Gestire un gran numero di sistemi Unix non è conveniente. Per modificare un parametro, l'amministratore deve contattare ciascuna macchina, gli script possono aiutare solo parzialmente e non in tutte le situazioni.

Certo, gli amministratori di rete di Windows sono in una posizione migliore. È sufficiente modificare le impostazioni dei criteri di gruppo e dopo un po' tutti i computer in rete, compresi quelli con un sistema operativo installato di recente, "imparano" all'innovazione, se li riguardano, ovviamente. Guardando indietro alla lunga storia di Unix, noterai che niente di simile ha preso piede. Esistono soluzioni come kickstart che aiutano con l'installazione iniziale del sistema operativo, ma ulteriori modifiche richiederanno molto sforzo. Soluzioni commerciali come BladeLogic e OpsWare risolvono solo parzialmente il problema dell'automazione delle impostazioni, il loro principale vantaggio è la presenza di un'interfaccia grafica e possono essere acquistate solo nelle grandi organizzazioni. Ci sono, ovviamente, progetti che offrono soluzioni gratuite, ma per tutto il tempo della loro esistenza non sono stati in grado di creare una grande comunità. Ad esempio, Cfengine non è molto popolare tra gli amministratori, sebbene oltre a Linux possa essere utilizzato in * BSD, Windows e Mac OS X. Forse ciò è dovuto alla relativa complessità della creazione delle configurazioni. Quando si descrivono le attività, è necessario tenere conto delle peculiarità di ciascun sistema specifico e controllare manualmente la sequenza delle azioni durante l'esecuzione dei comandi. Cioè, l'amministratore dovrebbe ricordare che per alcuni sistemi dovresti scrivere adduser per altri useradd, prendere in considerazione la posizione dei file in diversi sistemi e così via. Ciò complica di un ordine di grandezza il processo di scrittura dei comandi, è molto difficile creare al volo la configurazione corretta ed è praticamente impossibile leggere le configurazioni create dopo un po'. Nonostante la licenza GPL, Cfengine è in realtà un progetto individuale che supervisiona tutti i cambiamenti e non è molto interessato a costruire una società aperta. Di conseguenza, le capacità di cfengine sono abbastanza soddisfacenti per lo sviluppatore, ma per gli altri amministratori è piuttosto un mal di testa inutile. Per migliorare cfengine, sono stati creati vari componenti aggiuntivi da sviluppatori di terze parti, che spesso hanno peggiorato le cose. L'autore di molti di questi moduli per cfengine, Luke Kanies, alla fine ha deciso di sviluppare uno strumento simile, ma senza molti dei difetti di cfengine.

Caratteristiche del burattino

Puppet, come cfengine, è un sistema client-server che utilizza un dichiarativo, ovvero un linguaggio obbligatorio per descrivere le attività e una libreria per la loro implementazione. I client periodicamente (30 minuti per impostazione predefinita) si collegano al server centrale e ricevono l'ultima configurazione. Se le impostazioni ricevute non corrispondono allo stato del sistema, verranno eseguite; se necessario, viene inviato al server un report sulle operazioni eseguite. Il server può salvare i messaggi su syslog o su un file, creare una pianificazione RRD, inviarli all'e-mail specificata. Ulteriori livelli di astrazione Transazionale e Risorsa forniscono la massima compatibilità con le impostazioni e le applicazioni esistenti, consentendo di concentrarsi sugli oggetti di sistema senza preoccuparsi delle differenze nell'implementazione e nella descrizione di comandi dettagliati e formati di file. L'amministratore opera solo con il tipo di oggetto, Puppet si occupa del resto. Quindi il tipo di pacchetti conosce circa 17 sistemi di pacchetti, quello richiesto verrà riconosciuto automaticamente in base alle informazioni sulla versione del kit di distribuzione o del sistema, sebbene se necessario, il gestore dei pacchetti può essere impostato forzatamente.

A differenza degli script, che spesso non è possibile utilizzare su altri sistemi, le configurazioni di Puppet scritte da amministratori di terze parti funzioneranno, per la maggior parte, senza problemi su qualsiasi altra rete. In Puppet CookBook [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] ci sono già tre dozzine di ricette già pronte. Puppet attualmente supporta ufficialmente i seguenti sistemi operativi e servizi: Debian, RedHat / Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo e MySQL, LDAP.

lingua dei burattini

Per andare oltre, devi prima comprendere gli elementi e le capacità di base della lingua. La lingua è uno dei punti di forza di Puppet. Descrive le risorse che l'amministratore prevede di gestire e le azioni. A differenza della maggior parte delle soluzioni simili, in Puppet, il linguaggio consente di semplificare l'accesso a tutte le risorse simili su qualsiasi sistema in un ambiente eterogeneo. La descrizione di una risorsa di solito consiste in un nome, un tipo e attributi. Ad esempio, puntiamo al file /etc/passwd e impostiamo i suoi attributi:

file ("/ etc / passwd":

proprietario => radice,

gruppo => radice,

Ora i client che si connettono al server copieranno il file /etc/passwd e imposteranno gli attributi specificati. È possibile definire più risorse in un'unica regola separandole con punto e virgola. E cosa fare se il file di configurazione utilizzato sul server è diverso da quello del client o non viene utilizzato affatto? Ad esempio, questa situazione può verificarsi durante la configurazione delle connessioni VPN. In questo caso, il file può essere specificato con la direttiva source. Ci sono due opzioni, come al solito per specificare il percorso di un altro file, sono supportati anche due URI di protocollo: file e pupazzo. Nel primo caso viene utilizzato un collegamento a un server NFS esterno, nella seconda versione viene avviato un servizio simile a NFS sul server Puppet, che esporta le risorse. In quest'ultimo caso, per impostazione predefinita, viene specificato il percorso relativo alla directory radice del pupazzo - /etc/puppet. Cioè, il collegamento puppet: //server.domain.com/config/sshd_config corrisponderà al file /etc/puppet/config/sshd_config. È possibile sovrascrivere questa directory utilizzando la direttiva filebucket, sebbene sia più corretto utilizzare la sezione con lo stesso nome nel file /etc/puppet/fileserver.conf. In questo caso è possibile limitare l'accesso al servizio solo da determinati indirizzi. Ad esempio, descriviamo la sezione config.

percorso / var / burattino / config

consenti * .dominio.com

consenti 192.168.0.*

consenti 192.168.1.0/24

nega * .wireless.domain.com

E poi fare riferimento a questa sezione quando si descrive la risorsa.

source => "pupazzo: //server.domain.com/config/sshd_config"

Il nome della risorsa viene visualizzato prima dei due punti. Nei casi più semplici, puoi semplicemente specificare come nome, è meglio usare un alias o delle variabili. L'alias viene impostato utilizzando la direttiva alias. percorso completo del file. In configurazioni più complesse

file ("/ etc / passwd":

alias => passwd

Un'altra opzione per creare un alias è adatta nel caso in cui devi gestire diversi sistemi operativi. Ad esempio, creiamo una risorsa che descriva il file sshd_config:

file (sshdconfig:

nome => $ sistema operativo? (

solaris => "/ usr / local / etc / ssh / sshd_config",

default => "/ etc / ssh / sshd_config"

In questo esempio, ci troviamo di fronte a una scelta. Il file per Solaris è specificato separatamente, per tutti gli altri verrà selezionato il file /etc/ssh/sshd_config. Ora è possibile accedere a questa risorsa come sshdconfig, a seconda del sistema operativo, verrà selezionato il percorso corretto. Ad esempio, indichiamo che se il demone sshd è in esecuzione e viene ricevuto un nuovo file, il servizio deve essere riavviato.

garantire => vero,

iscriviti => File

Le variabili vengono spesso utilizzate quando si lavora con i dati utente. Ad esempio, descriviamo la posizione delle directory home dell'utente:

$ homeroot = "/ home"

Ora è possibile accedere ai file di un utente specifico come

$ (homeroot) / $ nome

Il parametro $ name verrà riempito con il nome dell'account dell'utente. In alcuni casi, è conveniente definire un valore predefinito per un certo tipo. Ad esempio, per il tipo exec, vengono spesso specificate le directory in cui cercare un file eseguibile:

Exec (percorso => ​​"/ usr / bin: / bin: / usr / sbin: / sbin")

In tal caso, se è necessario puntare a diversi file e directory allegati, è possibile utilizzare il parametro recurse.

file ("/etc/apache2/conf.d":

source => "pupazzo: // burattino: //server.domain.com/config/apache/conf.d",

ricorso => ​​"vero"

Diverse risorse possono essere combinate in classi o definizioni. Le classi sono descrizioni complete di un sistema o servizio e vengono utilizzate isolatamente.

"/ Etc / passwd": proprietario => root, gruppo => root, modalità => 644;

"/ Etc / shadow": proprietario => root, gruppo => root, modalità => 440

Come nei linguaggi orientati agli oggetti, le classi possono essere sovrascritte. Ad esempio, su FreeBSD, il gruppo che possiede questi file è wheel. Pertanto, per non riscrivere completamente la risorsa, creeremo una nuova classe freebsd che erediterà dalla classe linux:

classe freebsd eredita linux (

File ["/ etc / passwd"] (gruppo => ruota);

File ["/ etc / shadow"] (gruppo => ruota)

Per comodità, tutte le classi possono essere inserite in un file separato, che può essere incluso con la direttiva include. Le definizioni possono accettare più parametri come argomenti, ma non supportano l'ereditarietà e vengono utilizzate quando è necessario descrivere oggetti riutilizzabili. Ad esempio, definiamo la home directory dell'utente ei comandi necessari per creare un nuovo account.

define user_homedir ($ group, $ fullname, $ ingroups) (

utente ("$ nome":

assicurare => presente,

comment => "$ nome completo",

gid => "$ gruppo",

gruppi => $ ingroup,

abbonamento => minimo,

shell => "/ bin / bash",

home => "/ home / $ nome",

require => Gruppo [$ gruppo],

exec ("$ nome homedir":

comando => “/bin/cp -R/etc/skel/home/$ nome; / bin / chown -R $ nome: $ gruppo / casa / $ nome ",

crea => "/ home / $ nome",

require => Utente [$ nome],

Ora, per creare un nuovo account, vai su user_homedir.

user_homedir ("sergej":

gruppo => "sergej",

nome completo => "Sergej Jaremchuk",

ingroups => ["media", "admin]

Esistono descrizioni separate dei nodi (nodo), che supportano l'ereditarietà e le classi. Quando il client si connette al server Puppet, verrà cercata la sezione del nodo corrispondente e verranno visualizzate le impostazioni specifiche per questo computer. È possibile utilizzare il valore predefinito del nodo per descrivere tutti gli altri sistemi. Una descrizione di tutti i tipi è fornita nel documento "Type Reference", con il quale è necessario familiarizzare in ogni caso, almeno per comprendere tutte le caratteristiche del linguaggio dei burattini. Vari tipi consentono di eseguire i comandi specificati, anche quando vengono soddisfatte determinate condizioni (ad esempio, modifica del file di configurazione), utilizzo di cron, credenziali e gruppi di utenti, computer, montaggio di risorse, avvio e arresto di servizi, installazione, aggiornamento e rimozione pacchetti, lavorare con chiavi SSH, zone Solaris e così via. È così facile ottenere l'elenco dei pacchetti da aggiornare sulle distribuzioni che utilizzano apt, tutti i giorni tra le 2 e le 4.

programma (giornaliero:

periodo => giornaliero,

gamma =>

exec ("/ usr / bin / apt-get update":

programma => tutti i giorni

Durante questo periodo, ogni sistema si aggiornerà una sola volta, dopodiché l'attività si considera completata e verrà eliminata dal computer client. Il linguaggio delle marionette supporta altre strutture familiari: condizioni, funzioni, array, commenti e simili.

Installazione del burattino

Puppet richiede Ruby (> = 1.8.1) con supporto OpenSSL e librerie XMLRPC, nonché la libreria Faster [ http://reductivelabs.com/projects/factor]. Il repository Ubuntu 7.04 utilizzato nell'installazione di prova include già il pacchetto cucciolo.

$ sudo apt-cache search puppet

puppet - gestione centralizzata della configurazione per le reti

puppetmaster - demone di controllo della gestione della configurazione centralizzata

Durante l'installazione, verranno installate tutte le dipendenze del pacchetto necessarie: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install puppet puppetmaster

Puoi controllare le librerie Ruby con il comando.

$ ruby ​​​​-ropenssl -e "mette: sì"

~ $ ruby ​​​​-rxmlrpc / client -e "mette: sì"

Se non vengono ricevuti errori, tutto ciò di cui hai bisogno è già incluso. I file che descrivono la configurazione di sistema desiderata nella terminologia Puppet sono chiamati manifest. All'avvio, il demone prova a leggere il file /etc/puppet/manifests/site.pp; se è assente, emette un messaggio di avviso. Durante il test, puoi dire al demone di lavorare in una modalità autonoma in cui il manifest non è richiesto

$ sudo / usr / bin / puppetmasterd —nonodes

Se necessario, puoi collegare altri file a site.pp, ad esempio con le descrizioni delle classi. Per un'esecuzione di prova, è possibile immettere l'istruzione più semplice in questo file.

file ("/ etc / sudoers":

proprietario => radice,

gruppo => radice,

Tutti i file di configurazione per server e client si trovano in /etc/puppet. Il file fileserver.conf di cui abbiamo parlato sopra è facoltativo e viene utilizzato solo se Puppet funzionerà anche come file server. Su Ubuntu, questo file esporta la sottodirectory /etc/puppet/files. La sottodirectory SSL contiene certificati e chiavi che verranno utilizzati per la crittografia durante le connessioni client. Le chiavi vengono create automaticamente la prima volta che avvii puppetmasterd, puoi crearle manualmente con il comando.

$ sudo / usr / bin / puppetmasterd --mkusers.

I file puppetd.conf e puppetmasterd.conf sono simili. Specificano alcuni parametri del funzionamento dei demoni sul sistema client e sul server. Il file client differisce solo per la presenza del parametro server, che punta al computer su cui è in esecuzione puppetmasterd.

server = grinder.com

logdir = / var / log / burattino

vardir = / var / lib / burattino

rundir = / var / run

# invia un report al server

Per evitare di digitare tutto a mano, puoi creare un modello utilizzando lo stesso puppetd.

$ puppetd --genconfig> /etc/puppet/puppetd.conf

Allo stesso modo, puoi creare site.pp sul server.

$ puppetd --genmanifest> /etc/puppet/manifests/site.pp

Un altro file tagmail.conf, consente di specificare gli indirizzi di posta a cui verranno inviati i report. Nel caso più semplice, puoi usare una riga.

tutto: [e-mail protetta]

Non ci sono file di configurazione sufficienti per consentire al client di connettersi al server. Per fare ciò, devi anche firmare i certificati. Innanzitutto, per informare il server del nuovo computer sul sistema client, immettere il comando:

$ sudo puppetd —server grinder.com —waitforcert 60 —test

info: Richiesta certificato

avviso: il certificato peer non verrà verificato in questa sessione SSL

avviso: non ho ricevuto il certificato

Se viene restituita un'altra stringa, è necessario controllare il funzionamento del server.

$ ps aux | burattino grep

burattino 5779 0,0 1,4 27764 15404? Ssl 21:49 0:00 ruby ​​/ usr / sbin / marionette

Il firewall deve consentire le connessioni sulla porta 8140.

Sul server, otteniamo un elenco di certificati che devono essere firmati.

$ sudo puppetca --list

nomad.grinder.com

E firmiamo il certificato del cliente.

$ sudo puppetca –sign nomad.grinder.com

Ora il client può connettersi liberamente al server e ricevere le impostazioni.

Sfortunatamente, semplicemente non è possibile mostrare tutte le capacità di Puppet entro i limiti dell'articolo. Ma come puoi vedere, questo è uno strumento funzionale e flessibile che ti consente di risolvere la maggior parte dei compiti dell'amministrazione simultanea di un gran numero di sistemi. Se devi configurare più sistemi a causa del tuo lavoro. E, soprattutto, il progetto è riuscito a riunire una comunità piccola ma in costante crescita. Quindi speriamo che una buona idea non possa morire o allontanarsi.

Un po' di testi. Sembrerebbe che l'intero ciclo dovrebbe iniziare con questo articolo, ma il pubblico di destinazione sono gli utenti più esperti dei prodotti Open Source Puppet Labs, che non sono soddisfatti dei singoli moduli poco integrati con Puppet Forge. Come in ogni caso "biblioteca vs framework", il rimborso segue la visione del mondo dell'autore della soluzione integrata.

Un po' di come funziona Puppet

Il burattino è principalmente un linguaggio specifico per definire in modo dichiarativo lo stato finale del sistema. Per fare un confronto, estremamente adatto è il Makefile GNU, dove, oltre a descrivere direttamente le dipendenze, è possibile imbrogliare al massimo.

L'astrazione del burattino è più o meno la seguente ( schemi di rottura: dimentica tutto ciò che sapevi sui termini di programmazione!).

• Nodoè una raccolta di configurazioni per un sistema di destinazione specifico. In realtà, questo è un caso speciale della classe.
• Classeè un insieme di logica dichiarativa inclusa nella configurazione del nodo o in altre classi. La classe non ha istanze o metodi, ma ha parametri e variabili definiti all'interno della logica. In effetti, è più una procedura che può ereditare un'altra procedura con un accumulo di codice banale e un ambito variabile non del tutto banale.
• Tipo (tipo)- ma questa sembra già più una classe classica - dovrebbe avere istanze con un nome e parametri definiti, ma niente di più. Un'implementazione concreta di un tipo può essere scritta come script Puppet tramite define, che crea istanze di altri tipi, o come estensione Ruby con un volo di immaginazione.
• Risorsa- infatti, queste sono istanze denominate di Tipi. Il nome di ogni risorsa è univoco all'interno di un tipo specifico all'interno di una configurazione di nodo (directory).
• Variabili- beh, insomma, queste sono costanti... Prima di Puppet 4, i loro ambiti erano anche peggiori. Ora è adeguato: per l'uso dall'esterno del luogo di definizione, deve essere specificato un identificatore completo, tranne nel caso dell'ereditarietà della classe.

Puppet può essere utilizzato per la distribuzione locale senza rete e infrastruttura associata. Questo può essere usato per creare immagini di contenitori. Esiste persino un'intera linea di sostenitori dell'abbandono di un server centralizzato.

Ideologicamente corretta, l'infrastruttura Puppet consiste in un agente: un servizio privilegiato sul sistema di destinazione e un server che emette preziose istruzioni sotto forma di directory dichiarative delle risorse su richiesta degli agenti. La sicurezza è implementata a livello dell'infrastruttura a chiave pubblica privata (X.509). In poche parole, gli stessi meccanismi di HTTPS, ma con la propria CA e la verifica obbligatoria del certificato client.

In una forma semplificata, la procedura di distribuzione si presenta così:

1. Elaborazione TLS e X.509 (stabilimento connessione, aggiornamento CRL, controllo restrizioni certificato, ecc.)
2. L'agente riceve generatori di fatti dal server con memorizzazione nella cache e tutto (più precisamente, estrae tutto dalle lib / cartelle nei moduli). Non è difficile aggiungere il proprio script Ruby per raccogliere informazioni di interesse.
3. L'agente raccoglie informazioni sul sistema di destinazione e le invia al server. Tutti i fatti sono facili da rivedere a mano attraverso la sfida dei fatti dei burattini. Questi fatti sono disponibili come variabili globali.
4. Il server compila una directory di risorse e la invia all'agente. Al di sotto di questo si trova un intero strato di concetti diversi.
5. L'agente estrae tutto ciò di cui ha bisogno dal server e porta il sistema nel modulo specificato. Allo stesso tempo, l'agente stesso non sa come gestire le risorse, si affida all'implementazione dei "provider" (la traduzione semantica sarà "il traduttore", non il fornitore) di tipi specifici di risorse. Alcuni fornitori sono standard e sono inclusi nei pacchetti Puppet, mentre il resto viene estratto dai moduli.

Per gustare tutte le delizie, ci sono panini aggiuntivi sotto forma di:

• Modulo- una raccolta di script dichiarativi Puppet, estensioni Ruby per Puppet, file, modelli di file, dati Hiera e altro ancora. Un termine più corretto sarebbe "pacchetto".
• Ambiente- una raccolta di script, moduli e dati Hiera. Data la complessità dell'infrastruttura, è stato inevitabilmente necessario suddividere la configurazione oltre la suddivisione standard in nodi. Fondamentalmente, questo è necessario per le innovazioni pilota e il banale controllo degli accessi (quando non tutti gli amministratori hanno accesso a tutti i nodi dell'infrastruttura IT).
• Hiera- un database gerarchico. Questa formulazione può essere molto spaventosa. Questo è probabilmente il motivo per cui è stato modificato nella documentazione delle versioni successive. In effetti, questo è un meccanismo estremamente semplice e conveniente per estrarre la configurazione da file YAML o JSON. La gerarchia consiste nella capacità di specificare l'ordine in cui vengono letti più file di configurazione, ad es. la gerarchia/priorità di questi file.
  • Oltre a estrarre i dati per chiamata di funzione, Puppet estrae i parametri di classe predefiniti, che è il punto culminante principale.
  • Naturalmente, Hiera supporta l'interpolazione dei fatti e persino chiamate di funzioni speciali.
  • Puppet 4.3 ha implementato nuovamente la stessa funzionalità per supportare non solo il database globale, ma anche quello locale per l'Ambiente e il Modulo, sebbene l'autore abbia già riscontrato diversi problemi nella loro implementazione (PUP-5983, PUP-5952 e PUP-5899 ), che sono stati immediatamente corretti da Puppet Labs.
  • Sono supportate diverse strategie per estrarre i valori da tutti i file lungo la gerarchia:
    • first - viene restituito il primo valore che ha la priorità
    • unico: raccoglie tutti i valori in un array unidimensionale e rimuove i duplicati
    • hash - Concatena tutti gli hash YAML trovati. Le chiavi duplicate sono selezionate per priorità.
    • deep - essenzialmente una variante ricorsiva di hash
  • Il bello è che la strategia di recupero può essere specificata come quando si chiama la funzione lookup(), poiché e in qualsiasi file di gerarchia tramite la chiave speciale lookup_options, che viene utilizzata attivamente nel modulo cfnetwork.
• PuppetDB- infatti, uno strato di business logic attorno ad un database relazionale (PostgreSQL), che permette di salvare report di fatti e implementazioni effettuate ed esportare risorse per successiva importazione in cataloghi su altri nodi o selezione tramite apposite funzioni. C'è anche una museruola web sotto forma di Puppet Dashboard.
• X.509 PKI- la già citata infrastruttura dei certificati, estremamente comoda da utilizzare per altri servizi senza la necessità di gestire un'infrastruttura separata.
• MCollettivo- apparentemente una cosa utile per l'avvio di attività basate su eventi su una server farm, ma l'autore ha una certa mancanza di fiducia nella sicurezza di una particolare soluzione.
• fucina di burattini- un'area aperta per la pubblicazione e il download dei Moduli.
• alcune altre funzionalità sotto forma di controllo di dispositivi esterni come apparecchiature Cisco e distribuzione su bare metal, ma questa è un'altra storia

Note di sicurezza e accessibilità

È necessario capire che Puppet Server diventa una vulnerabilità dell'intera infrastruttura IT, perché determina la configurazione finale di tutti i sistemi. In casi speciali, ha senso fare la separazione: un server separato per gli elementi critici dell'infrastruttura con accesso estremamente limitato e aggiornamenti manuali e il secondo per tutto il resto.

La disponibilità di Puppet Server determina la capacità di gestire l'intera infrastruttura. Ha senso ospitare Puppet Server su una macchina virtuale in un cloud di terze parti più affidabile e rapidamente recuperabile rispetto alle tue capacità. In alternativa, è necessario installare più server.

In ogni caso, non dovresti installare altri servizi sul sistema in cui verrà distribuito Puppet Server con campanelli e fischietti. Virtualizzazione e containerizzazione per aiutarti.

Multi-master (più Puppet Server standalone)

• In questo caso, solo un server funge da CA (Autorità di certificazione) - la sua inaccessibilità significa che è impossibile aggiungere nuovi nodi.
  • Puppet consente di utilizzare framework X.509 di terze parti se il built-in non funziona.
• Tutta la configurazione (ambiente) deve essere mantenuta nel controllo del codice sorgente e distribuita su ciascun server contemporaneamente.
• L'unica cosa in comune è il database PostgreSQL, la cui organizzazione dell'alta disponibilità esula dallo scopo di questo articolo.
• Il modulo cfpuppetserver supporta sia l'installazione di server primari (con CA) che secondari.

Qual è il cambiamento significativo rispetto alle versioni precedenti

Il produttore ha una descrizione completa.

• Tutti i servizi sono stati spostati su JVM, JRuby e Jetty. Dietro gli ovvi vantaggi dell'integrazione, ci sono anche degli svantaggi in termini di consumo di memoria.
• Sono state aggiunte le funzioni Lambda per l'elaborazione delle raccolte: ora non è più necessario tagliare le stampelle in Ruby o torcere create_resources ()
• È apparso uno strumento per la creazione di modelli EPP, essenzialmente lo stesso ERB, ma con Puppet DSL invece di Ruby,
• La struttura della directory del file di configurazione predefinita è cambiata molto
• Aggiunto il supporto per i provider di dati per ambienti e moduli (non sono necessari più hack).
• Diminuire il ruolo della Hiera globale. Una nuova ricerca del fantoccio di comando correlato.

Installazione

Questo processo è piuttosto primitivo, ma richiede l'adesione a una certa sequenza di passaggi. Poiché farlo manualmente è un compito ingrato, l'autore ti insegnerà una cosa negativa, ovvero scaricare script incomprensibili da Internet ed eseguire come root sul tuo sistema.

I tre componenti principali del server sono lo stesso Puppet Server, PuppetDB e PostgreSQL. Possono essere tutti stipati in un nodo o divisi in due o tre sistemi. Puppet Server e Puppet DB possono essere avviati molte volte, ma PostgeSQL è un singolo nodo di errore. Esistono vari approcci alla replica e al clustering di PostgeSQL.Un approccio conveniente nel caso di server primari e secondari sarebbe Master + Read-Only Slave, che è supportato nello stesso PuppetDB come nodo di database primario e di sola lettura, ma automatizzando questa configurazione richiede tempo e quindi non è ancora disponibile fa parte del modulo cfpuppetserver.

La configurazione stessa può essere semplicemente memorizzata anche sul file system insieme al Puppet Server, ma è come scrivere script su un server web di produzione. La soluzione più adatta è il repository git. L'utility r10k è in grado di estrarre tutti i rami del repository e distribuirli su Puppet Server come ambienti separati. R10k è piuttosto scarso nell'eliminare le dipendenze, quindi il librarian-puppet viene utilizzato in cima. Va notato subito che il principale Ambiente delle marionette canonico è la "produzione". Pertanto, nel repository di configurazione, dovresti utilizzare il ramo denominato "produzione", non "master".

Requisiti di sistema

L'hardware è descritto dal produttore stesso. Il modulo cfpuppetserver attualmente supporta solo Debian Jessie + e Ubuntu Trusty +.

Configurazione in Git

Per lo stesso r10k, la posizione del repository non ha molta importanza: la cosa principale è la sua disponibilità. Ad esempio, a scopo di test, il repository può essere ospitato sullo stesso sistema con file: // access. Un buon inizio è l'esempio di configurazione codingfuture/puppet-exampleenv.

1. Clona il repository: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
2. Definiamo le impostazioni generali per l'accesso come amministratore, utilizzando i suggerimenti nei commenti:
   • $ EDITOR dati / common.yaml
3. Creiamo una configurazione del nodo:
   • $ MY_DOMAIN - nome del dominio principale (ad esempio, example.org)
   • $ HOST_NAME - nome host del cliente senza dominio
   • mkdir data / $ MY_DOMAIN
   • cp data / example.com / puppet.yaml data / $ (MY_DOMAIN) /puppet.yaml
   • $ EDITOR nano -w data / $ (MY_DOMAIN) /puppet.yaml - configurazione di un nodo con Puppet Server come richiesto nei commenti
   • cp data / example.com / host.yaml data / $ (MY_DOMAIN) / $ (HOST_NAME) .yaml
   • $ EDITOR nano -w data / $ (MY_DOMAIN) / $ (HOST_NAME) .yaml - impostazione di un nodo arbitrario in base ai suggerimenti nei commenti
4. Inviamo al nostro server Git o lo rendiamo disponibile localmente sul nodo con Puppet Server tramite rsync o scp. Il repository locale è conveniente come passaggio intermedio fino a quando il server Git non viene distribuito dallo stesso Puppet. In un certo senso, è simile alla creazione di un compilatore in più fasi.

Installiamo da zero su un sistema pulito

Il modulo cfpuppetserver ti permette di installare tutto usando Puppet stesso, ma per l'installazione iniziale le operazioni di base sono duplicate dallo script Bash.

Sul sistema di destinazione:

1. Scarica lo script di installazione: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. Esaminiamo lo script e ci accigliamo in disparte: less setup_puppetserver.sh
3. Esegui: bash setup_puppetserver.sh pupazzo $ (MY_DOMAIN).
   • Esempio con repository remoto: bash setup_puppetserver.sh ssh: // [e-mail protetta]/ burattino-conf
   • Esempio locale: file bash setup_puppetserver.sh: /// root / puppetconf /
4. Osserviamo come il sistema si gonfia e non installa tutto molto rapidamente.
5. Se il repository remoto:
   • Crea la chiave SSH per la radice "a: ssh-keygen -t rsa -b 2048
   • Registriamo la chiave pubblica /root/.ssh/id_rsa.pub sul server Git remoto...
   • ... e imposta lì un hook Git con il seguente comando: / usr / bin / ssh -T [e-mail protetta]$ (MY_DOMAIN) ./puppetdeploy.sh
6. Iniziamo la distribuzione della configurazione manualmente: /etc/puppetlabs/deploy.sh
7. Provando come funziona sul server stesso: /opt/puppetlabs/bin/puppet agent --test
8. Controlla la rete, il filtro di rete e le impostazioni di accesso SSH

Aggiunta di nodi gestiti

1. Il nome completo del Puppet Server deve essere disponibile tramite DNS sull'host gestito, oppure deve essere codificato in /etc/hosts.
   • Esempio: echo "128.1.1.1 puppet.example.com" >> / etc / hosts
2. Sul nodo Puppet Server, esegui il seguente script /root/genclientinit.sh $ (HOST_NAME). $ (MY_DOMAIN).
3. Copia l'intero risultato e incollalo nella riga di comando sul sistema di destinazione.
4. Stiamo aspettando il completamento dell'esecuzione ed eseguire / opt / puppetlabs / bin / puppet agent --test. Al primo avvio, verrà generata una richiesta di firma del certificato.
5. Vai al nodo Puppet Server per firmare il certificato.
   • elenco di certificati fantoccio - controlla la firma del certificato per ulteriori paranoie.
   • puppet cert sign $ (HOST_NAME). $ (MY_DOMAIN) - infatti, firmiamo il certificato.
6. Torniamo al nodo gestito ed eseguiamo di nuovo: /opt/puppetlabs/bin/puppet agent --test`. Ciò forzerà la procedura di distribuzione.
7. Stiamo aspettando il completamento della distribuzione tramite l'agente Puppet.
8. Ecco fatto, hai pronto un'infrastruttura minima per i burattini!

Esempio di output /root/genclientinit.sh

bash</ etc / cflocation fi if test! -z ""; quindi echo -n> / etc / cflocationpool fi if test! -z "\ $ http_proxy"; quindi esporta http_proxy esporta https_proxy = "\ $ http_proxy" esporta HTTP_PROXY = "\ $ http_proxy" esporta HTTPS_PROXY = "\ $ http_proxy" fi echo host.example.com> / etc / hostname hostname host.example.com if! che lsb-release | leggere; quindi apt-get install lsb-release fi codename = \ $ (lsb_release -cs) if test -z "\ $ codename"; then echo "Impossibile rilevare il nome in codice corretto" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1 - \ $ (codename) .deb mkdir -p /etc/puppetlabs/puppet cat> /etc/puppetlabs/puppet/puppet.conf<puppet cert sign host.example.com "echo" Usa CTRL + C per interrompere il ciclo, se fallisce per diversi motivi "sleep 5 done EOT

Descrizione del modulo

Elenco completo dei parametri per lo script di installazione iniziale di Bash

~ # ./setup_puppetserver.sh Utilizzo: ./setup_puppetserver.sh [ [ [ [] ] ] ]

• r10k_repo_url - URI del repository Git
• certname - nome di dominio completo dell'host
• cflocation - inizializzazione del fatto cf_location
• cflocationpool - inizializzazione del fatto cf_location_pool
• http_proxy - server proxy per richieste HTTP e HTTPS

Elenco completo dei parametri Bash per lo script di inizializzazione del client Puppet

~ # /root/genclientinit.sh Utilizzo: ./genclientinit.sh [ [ []]]
Il significato dei parametri è lo stesso dello script precedente.

classe cfpuppetserver

• deployuser = "deploypuppet" - nome utente per la distribuzione automatica degli aggiornamenti di configurazione
• deployuser_auth_keys = undef - elenco di chiavi per $ deployuser
• repo_url = undef - URI del repository (esempio: ssh: // [e-mail protetta]/ repository o file: /// alcuni / percorso)
• puppetserver = true - se installare il componente Puppet Server su questo nodo
• puppetdb = true - se installare il componente PuppetDB su questo nodo
• puppetdb_port = 8081 - porta per PuppetDB
• setup_postgresql = true - se installare il componente PostgreSQL su questo nodo (solo se l'installazione di PuppetDB è abilitata)
• service_face = "any" - cfnetwork :: nome risorsa iface per accettare connessioni in entrata
• puppetserver_mem = auto - RAM per Puppet Server in megabyte (minimo 192 MB)
• puppetdb_mem = auto - RAM per PuppetDB in megabyte (minimo 192 MB)
• postgresql_mem = auto - RAM per PostgreSQL in megabyte (minimo 128 MB)

cfpuppetserver :: classe puppetdb

• postgresql_host = "localhost" - indirizzo del database
• postgresql_listen = $ postgresql_host - il valore va direttamente alla direttiva listen_addresses di PostgreSQL
• postgresql_port = 5432 - porta del database
• postgresql_user = "puppetdb" - Utente PuppetDB nel database
• postgresql_pass = "puppetdb" - la password dell'utente PuppetDB nel database
• postgresql_ssl = false - abilita la crittografia della connessione basata sui certificati Puppet PKI

cfpuppetserver :: classe puppetserver

• autosign = false - NON DEVE essere utilizzato in un ambiente di produzione, tranne che nella DMZ. Esiste esclusivamente per l'automazione dei test.
• global_hiera_config = "cfpuppetserver / hiera.yaml" - il percorso del file di configurazione di Hiera predefinito secondo i canoni di Puppet (il primo componente è il nome del modulo, il resto è il percorso sotto i file/cartella nel modulo)

Puoi aiutare e trasferire dei fondi per lo sviluppo del sito



Qualche tempo fa, l'elenco dei server nei miei segnalibri superava i 200. Con l'aumento del numero di server, l'implementazione di una nuova configurazione o l'installazione di nuovi pacchetti sta sprecando un'enorme quantità di tempo. Così ho deciso di usare il burattino.
Fantoccio(puppet inglese) è un'applicazione client-server multipiattaforma che consente di gestire in modo centralizzato la configurazione dei sistemi operativi e dei programmi installati su più computer. Puppet è scritto nel linguaggio di programmazione Ruby.

Si dice anche che Puppet sia un sistema di gestione della configurazione remota, in particolare i sistemi open source Cfengine e Puppet.

Dopo aver letto le recensioni, ho deciso di usare il burattino.

Installazione e configurazione del server dei pupazzi:
Installazione del server delle marionette:
Installa il server delle marionette su OpenSuSE 11.4:

zypper nel server delle marionette

Cambia il nome del server in pupazzo:
/ etc / HOSTNAME:

Il record DNS dovrebbe risolversi in 127.0.0.2
gatto / etc / host:

127.0.0.2 burattino.site burattino

Dai diritti all'utente fantoccio:

Avviamo il servizio Burattinaio:

rcpuppetmasterd start

Aggiungiamo l'inizio del demone pupazzo al caricamento automatico:

chkconfig -a puppetmasterd

Configurazione di un server fantoccio:
Definiamo una directory in cui verranno archiviati i file che il puppet-server trasferirà alle macchine client nei manifesti del tipo di file.

vim/etc/puppet/fileserver

percorso / etc / pupazzo / file
permettere *

mkdir / etc / pupazzo / file

chown -R burattino: burattino / etc / burattino / file

Creiamo un file di qualsiasi contenuto per la distribuzione e il test sui client

touch / etc / burattino / file / burattini

Riavvia il server fantoccio:

riavviare rcpuppetmasterd

Fantoccio utilizza il proprio linguaggio per descrivere lo stato finale del sistema operativo, con l'aiuto del quale l'amministratore di sistema specifica a quale tipo di componenti del sistema operativo devono essere portati per raggiungere lo stato desiderato. Lo stato può significare la presenza di uno specifico file, cartella, servizi in esecuzione di pacchetti installati, aggiornamenti e altro. Tutte le impostazioni dello stato sono descritte in file o manifest, che si trovano nella directory: /etc/puppet/manifest. Questi file hanno nomi come * .pp.

Creiamo il più semplice manifesto:
/etc/puppet/manifests/1.file.pp:

file ("/ tmp / burattini":
source => "puppet: /// files / burattini",
}

Per applicare questo manifest:
fantoccio applicare 1.file.pp

Installazione e configurazione del client pupazzo:

zypper in burattino

Diamo i diritti del burattino all'utente:

chown -R puppet.puppet / var / lib / puppet /

Per stabilire la comunicazione con il server puppet, il client puppet invia una richiesta di conferma del certificato, dopo che il server ha confermato questa richiesta, il client puppet inizierà a utilizzare i manifest destinati ad esso. Invieremo una richiesta per confermare il certificato:

Sul server, possiamo vedere quali richieste di conferma sono in sospeso:

"puppet-client.localdomain" (B5: 12: 69: 63: DE: 19: E9: 75: 32: 2B: AA: 74: 06: F6: 8E: 8A)

Confermiamo:

puppetca --sign "puppet-client.localdomain"

È tempo di considerare gli esempi più semplici di creazione di manifest:
crea un file /etc/puppet/manifests/site.pp:

predefinito del nodo (
file ("/ tmp / burattini":
fonte => "pupazzo: /// file / burattini",
}
servizio ("ntp":
assicurare => in esecuzione,
abilita => vero,
}
pacchetto ("htop":
garantire => installato,
}
}

default - si applica a tutti i client
file - questa sezione dice di creare o sovrascrivere il file /tmp/puppettesting che si trova sul server nella directory /etc/puppet/files
servizio: controlla se il servizio è in esecuzione, se non è avviato, quindi avvialo e aggiungilo anche all'avvio
pacchetto: controlla se il pacchetto htop è installato sul client e, in caso contrario, installalo.

Per verificare eseguire sul client:

Come puoi vedere, ntp è stato aggiunto al caricamento automatico sul client, è stato lanciato il demone ntp, è stato installato il pacchetto htop e il file di puppette è stato copiato nella directory / tmp /

info: catalogo cache per puppet-client.localdomain
info: Applicazione della versione di configurazione "1370163660"
avviso: / Stage [principale] // Nodo [predefinito] / Servizio [ntp] / garantire: garantire modificato "fermato" in "in esecuzione"
avviso: / Stage [principale] // Nodo [predefinito] / Pacchetto [htop] / garantire: creato
avviso: / Stage [principale] // Nodo [predefinito] / File [/ tmp/puppettesting] / garantire: contenuto definito come "(md5)"
avviso: catalogo finito eseguito in 3,95 secondi

Nel prossimo articolo descriverò esempi più complessi di creazione di manifest e l'interfaccia web del pannello di controllo delle marionette.

Tipi di risorse per burattini popolari
cron- gestione del lavoro cron
eseguire- avvio di script e comandi
file- gestione dei file
filebucket- backup dei file
gruppo- gestione del gruppo
ospite- gestire le voci nel file / etc / hosts
interfaccia- configurazione delle interfacce di rete
montare- montaggio di file system
notificare- inviare un messaggio al file di registro di Puppet
pacchetto- gestione dei pacchetti
servizio- gestione del servizio
sshkey- Gestione delle chiavi SSH
ordinato- eliminazione di file a seconda delle condizioni
utente- Gestione utenti
zone- Gestione zone Solaris