Puppet - Guida rapida

Puppet è uno strumento di gestione della configurazione sviluppato da Puppet Labs per automatizzare la gestione e la configurazione dell'infrastruttura. Puppet è uno strumento molto potente che aiuta nel concetto di infrastruttura come codice. Questo strumento è scritto in linguaggio Ruby DSL che aiuta a convertire un'infrastruttura completa in formato codice, che può essere facilmente gestito e configurato.

Puppet segue il modello client-server, in cui una macchina in qualsiasi cluster funge da server, nota come burattinaio e l'altra funge da client nota come slave sui nodi. Puppet ha la capacità di gestire qualsiasi sistema da zero, a partire dalla configurazione iniziale fino alla fine del ciclo di vita di una determinata macchina.

Caratteristiche di Puppet System

Di seguito sono riportate le caratteristiche più importanti di Puppet.

Idempotenza

Puppet supporta Idempotency che lo rende unico. Simile a Chef, in Puppet, si può eseguire in sicurezza lo stesso set di configurazione più volte sulla stessa macchina. In questo flusso, Puppet verifica lo stato corrente della macchina di destinazione e apporterà modifiche solo in caso di modifiche specifiche nella configurazione.

Idempotency aiuta nella gestione di qualsiasi macchina particolare durante il suo ciclo di vita a partire dalla creazione della macchina, i cambiamenti di configurazione nella macchina, fino alla fine del suo ciclo di vita. La funzione Puppet Idempotency è molto utile per mantenere la macchina aggiornata per anni piuttosto che ricostruire la stessa macchina più volte, in caso di modifiche alla configurazione.

Cross-platform

In Puppet, con l'aiuto di Resource Abstraction Layer (RAL) che utilizza le risorse Puppet, è possibile indirizzare la configurazione specificata del sistema senza preoccuparsi dei dettagli di implementazione e di come funzionerà il comando di configurazione all'interno del sistema, che sono definiti nella configurazione sottostante file.

Puppet - Flusso di lavoro

Puppet utilizza il seguente flusso di lavoro per applicare la configurazione al sistema.

• In Puppet, la prima cosa che fa il Puppet master è raccogliere i dettagli della macchina di destinazione. Utilizzando il fattore presente su tutti i nodi Puppet (simile a Ohai in Chef) si ottengono tutti i dettagli di configurazione a livello di macchina. Questi dettagli vengono raccolti e rispediti al burattinaio.

• Quindi il burattinaio confronta la configurazione recuperata con i dettagli di configurazione definiti e con la configurazione definita crea un catalogo e lo invia agli agenti Puppet di destinazione.

• L'agente Puppet applica quindi tali configurazioni per portare il sistema in uno stato desiderato.

• Infine, una volta che il nodo di destinazione si trova nello stato desiderato, invia un rapporto al Puppet master, che aiuta il Puppet master a capire dove si trova lo stato corrente del sistema, come definito nel catalogo.

Puppet - Componenti chiave

Di seguito sono riportati i componenti chiave di Puppet.

Risorse dei burattini

Le risorse Puppet sono i componenti chiave per modellare una macchina particolare. Queste risorse hanno il proprio modello di implementazione. Puppet utilizza lo stesso modello per ottenere una particolare risorsa nello stato desiderato.

Fornitori

I provider sono fondamentalmente i soddisfacenti di qualsiasi particolare risorsa utilizzata in Puppet. Ad esempio, il tipo di pacchetto "apt-get" e "yum" sono entrambi validi per la gestione dei pacchetti. A volte, più di un provider sarebbe disponibile su una particolare piattaforma. Sebbene ogni piattaforma abbia sempre un provider predefinito.

Manifesto

Manifest è una raccolta di risorse che vengono accoppiate all'interno della funzione o delle classi per configurare qualsiasi sistema di destinazione. Contengono un set di codice Ruby per configurare un sistema.

Moduli

Il modulo è l'elemento costitutivo chiave di Puppet, che può essere definito come una raccolta di risorse, file, modelli, ecc. Possono essere facilmente distribuiti tra diversi tipi di sistemi operativi essendo definiti che hanno lo stesso sapore. Poiché possono essere facilmente distribuiti, un modulo può essere utilizzato più volte con la stessa configurazione.

Modelli

I modelli utilizzano espressioni Ruby per definire il contenuto personalizzato e l'input delle variabili. Sono utilizzati per sviluppare contenuti personalizzati. I modelli vengono definiti nei manifesti e vengono copiati in una posizione nel sistema. Ad esempio, se si desidera definire httpd con una porta personalizzabile, è possibile farlo utilizzando la seguente espressione.

Listen <% = @httpd_port %>

La variabile httpd_port in questo caso è definita nel manifest che fa riferimento a questo modello.

File statici

I file statici possono essere definiti come file generali che a volte sono necessari per eseguire attività specifiche. Possono essere semplicemente copiati da una posizione all'altra utilizzando Puppet. Tutti i file statici si trovano nella directory dei file di qualsiasi modulo. Qualsiasi manipolazione del file in un manifest viene eseguita utilizzando la risorsa file.

Di seguito è riportata la rappresentazione schematica dell'architettura Puppet.

Burattinaio

Puppet Master è il meccanismo chiave che gestisce tutte le cose relative alla configurazione. Applica la configurazione ai nodi utilizzando l'agente Puppet.

Puppet Agent

Gli agenti burattini sono le vere e proprie macchine da lavoro gestite dal burattinaio. Hanno il servizio daemon dell'agente Puppet in esecuzione al loro interno.

Repository di configurazione

Questo è il repository in cui tutti i nodi e le configurazioni relative al server vengono salvati e estratti quando necessario.

Fatti

Factssono i dettagli relativi al nodo o alla macchina master, che vengono sostanzialmente utilizzati per analizzare lo stato corrente di qualsiasi nodo. Sulla base dei fatti, le modifiche vengono apportate su qualsiasi macchina target. Ci sono fatti predefiniti e personalizzati in Puppet.

Catalogare

Tutti i file manifest o la configurazione scritti in Puppet vengono prima convertiti in un formato compilato chiamato catalog e successivamente quei cataloghi vengono applicati sulla macchina di destinazione.

Puppet funziona sull'architettura del server client, in cui chiamiamo il server come Puppet master e il client come nodo Puppet. Questa configurazione si ottiene installando Puppet sia sul client che su tutte le macchine server.

Per la maggior parte delle piattaforme, Puppet può essere installato tramite il gestore di pacchetti preferito. Tuttavia, per poche piattaforme può essere fatto installando iltarball o RubyGems.

Prerequisiti

Il fattore è l'unico prerequisito che non viene fornito Ohai che è presente in Chef.

Libreria del sistema operativo standard

Abbiamo bisogno di avere un set standard di librerie di qualsiasi sistema operativo sottostante. Rimanendo tutto il sistema arriva con le versioni Ruby 1.8.2 +. Di seguito è riportato l'elenco degli elementi della libreria, di cui dovrebbe essere composto un sistema operativo.

• base64
• cgi
• digest/md5
• etc
• fileutils
• ipaddr
• openssl
• strscan
• syslog
• uri
• webrick
• webrick/https
• xmlrpc

Installazione di Facter

Come discusso, il facternon viene fornito con l'edizione standard di Ruby. Quindi, per ottenere il facter nel sistema di destinazione, è necessario installarlo manualmente dal sorgente poiché la libreria facter è un prerequisito di Puppet.

Questo pacchetto è disponibile per più piattaforme, tuttavia solo per essere più sicuro può essere installato utilizzando tarball, che aiuta a ottenere l'ultima versione.

Innanzitutto, scarica il file tarball dal sito ufficiale di Puppet utilizzando il wget utilità.

$ wget http://puppetlabs.com/downloads/facter/facter-latest.tgz  ------: 1

Successivamente, annulla il tar del file tar. Entra nella directory untarred usando il comando CD. Infine, installa il facter usandoinstall.rb file presente all'interno del facter directory.

$ gzip -d -c facter-latest.tgz | tar xf - -----: 2 
$ cd facter-* ------: 3 $ sudo ruby install.rb # or become root and run install.rb -----:4

Installazione di Puppet dall'origine

Innanzitutto, installa il tarball di Puppet dal sito di Puppet utilizzando wget. Quindi, estrai il tarball in una posizione di destinazione. Spostati all'interno della directory creata utilizzando il fileCDcomando. Utilizzandoinstall.rb file, installa Puppet sul server sottostante.

# get the latest tarball 
$ wget http://puppetlabs.com/downloads/puppet/puppet-latest.tgz -----: 1 # untar and install it $ gzip -d -c puppet-latest.tgz | tar xf - ----: 2 
$ cd puppet-* ------: 3 $ sudo ruby install.rb # or become root and run install.rb -------: 4

Installazione di Puppet e Facter utilizzando Ruby Gem

# Installing Facter 
$ wget http://puppetlabs.com/downloads/gems/facter-1.5.7.gem $ sudo gem install facter-1.5.7.gem

# Installing Puppet 
$ wget http://puppetlabs.com/downloads/gems/puppet-0.25.1.gem $ sudo gem install puppet-0.25.1.gem

Una volta installato Puppet sul sistema, il passaggio successivo è configurarlo per eseguire determinate operazioni iniziali.

Apri porte firewall sui computer

Per fare in modo che il server Puppet gestisca centralmente il server del client, è necessario aprire una porta specificata su tutte le macchine, ad es 8140può essere utilizzato se non è in uso in nessuna delle macchine che stiamo cercando di configurare. Dobbiamo abilitare sia la comunicazione TCP che UDP su tutte le macchine.

File di configurazione

Il file di configurazione principale per Puppet è etc/puppet/puppet.conf. Tutti i file di configurazione vengono creati in una configurazione basata su pacchetti di Puppet. La maggior parte della configurazione richiesta per configurare Puppet è conservata in questi file e una volta eseguita l'esecuzione di Puppet, raccoglie automaticamente tali configurazioni. Tuttavia, per alcune attività specifiche come la configurazione di un server Web o un'autorità di certificazione (CA) esterna, Puppet ha una configurazione separata per file e impostazioni.

I file di configurazione del server si trovano in conf.ddirectory conosciuta anche come Puppet master. Questi file si trovano per impostazione predefinita in/etc/puppetlabs/puppetserver/conf.dsentiero. Questi file di configurazione sono in formato HOCON, che mantiene la struttura di base di JSON ma è più leggibile. Quando ha luogo l'avvio di Puppet, raccoglie tutti i file .cong dalla directory conf.d e li utilizza per apportare eventuali modifiche alla configurazione. Qualsiasi modifica in questi file avviene solo al riavvio del server.

File di elenco e file di impostazioni

• global.conf
• webserver.conf
• web-routes.conf
• puppetserver.conf
• auth.conf
• master.conf (deprecato)
• ca.conf (deprecato)

Esistono diversi file di configurazione in Puppet specifici per ogni componente in Puppet.

Puppet.conf

Il file Puppet.conf è il file di configurazione principale di Puppet. Puppet utilizza lo stesso file di configurazione per configurare tutti i comandi e servizi di Puppet richiesti. Tutte le impostazioni relative a Puppet come la definizione di Puppet master, Puppet agent, Puppet apply e certificati sono definiti in questo file. Puppet può riferirli secondo il requisito.

Il file di configurazione assomiglia a un file ini standard in cui le impostazioni possono entrare nella sezione dell'applicazione specifica della sezione principale.

Sezione Configurazione principale

[main] 
certname = Test1.vipin.com 
server = TestingSrv 
environment = production 
runinterval = 1h

File di configurazione di Puppet Master

[main] 
certname = puppetmaster.vipin.com 
server = MasterSrv 
environment = production 
runinterval = 1h 
strict_variables = true  
[master] 

dns_alt_names = MasterSrv,brcleprod01.vipin.com,puppet,puppet.test.com 
reports = puppetdb 
storeconfigs_backend = puppetdb 
storeconfigs = true 
environment_timeout = unlimited

Panoramica dei dettagli

Nella configurazione di Puppet, il file che verrà utilizzato ha più sezioni di configurazione in cui ogni sezione ha diversi tipi di numero multiplo di impostazioni.

Sezione Config

Il file di configurazione di Puppet consiste principalmente nelle seguenti sezioni di configurazione.

• Main- Questa è nota come la sezione globale che viene utilizzata da tutti i comandi e servizi in Puppet. Uno definisce i valori predefiniti nella sezione principale che possono essere sovrascritti da qualsiasi sezione presente nel file puppet.conf.

• Master - Questa sezione è indicata dal servizio Puppet master e dal comando Puppet cert.

• Agent - Questa sezione è riferita dal servizio agente Puppet.

• User - Viene utilizzato principalmente dal comando Puppet apply e da molti dei comandi meno comuni.

[main] 
certname = PuppetTestmaster1.example.com

Componenti chiave del file di configurazione

Di seguito sono riportati i componenti chiave del file Config.

Righe di commento

In Puppet, qualsiasi riga di commento inizia con (#) cartello. Questo può essere inteso con qualsiasi quantità di spazio. Possiamo anche avere un commento parziale all'interno della stessa riga.

# This is a comment. 
Testing = true #this is also a comment in same line

Impostazioni Linee

La riga delle impostazioni deve essere composta da:

• Qualsiasi quantità di spazio iniziale (opzionale)
• Nome delle impostazioni
• Un segno uguale = a, che può essere circondato da un numero qualsiasi di spazio
• Un valore per l'impostazione

Impostazione delle variabili

Nella maggior parte dei casi, il valore delle impostazioni sarà una singola parola, ma in alcuni casi speciali, ci sono pochi valori speciali.

Sentieri

Nelle impostazioni del file di configurazione, prendi un elenco di directory. Durante la definizione di queste directory, si dovrebbe tenere presente che dovrebbero essere separate dal carattere separatore del percorso di sistema, che è (:) nelle piattaforme * nix e punto e virgola (;) su Windows.

# *nix version: 
environmentpath = $codedir/special_environments:$codedir/environments 
# Windows version: 
environmentpath = $codedir/environments;C:\ProgramData\PuppetLabs\code\environment

Nella definizione, la directory del file che è elencata per prima viene scansionata e poi si sposta nell'altra directory nell'elenco, se non ne trova una.

File e directory

Tutte le impostazioni che accettano un singolo file o directory possono accettare un hash facoltativo di autorizzazioni. Quando il server si avvia, Puppet applicherà quei file o directory nell'elenco.

ssldir = $vardir/ssl {owner = service, mode = 0771}

Nel codice sopra, gli hash consentiti sono proprietario, gruppo e modalità. Esistono solo due valori validi per le chiavi del proprietario e del gruppo.

In Puppet, tutti gli ambienti hanno l'estensione environment.conffile. Questo file può sovrascrivere diverse impostazioni predefinite ogni volta che il master serve uno dei nodi o tutti i nodi assegnati a quel particolare ambiente.

Posizione

In Puppet, per tutti gli ambienti definiti, il file environment.conf si trova al livello più alto del suo ambiente home, molto vicino al manifest e ai direttori dei moduli. Considerando un esempio, se il tuo ambiente è nelle directory predefinite(Vipin/testing/environment), quindi il file di configurazione dell'ambiente di test si trova in Vipin/testing/environments/test/environment.conf.

Esempio

# /etc/testingdir/code/environments/test/environment.conf  
# Puppet Enterprise requires $basemodulepath; see note below under modulepath". modulepath = site:dist:modules:$basemodulepath  
# Use our custom script to get a git commit for the current state of the code: 
config_version = get_environment_commit.sh

Formato

Tutti i file di configurazione in Puppet utilizzano lo stesso formato simile a INI allo stesso modo. environment.confsegue lo stesso formato INI degli altri file puppet.conf. L'unica differenza tra environment.conf epuppet.confIl file environment.conf non può contenere la sezione [main]. Tutte le impostazioni nel file environment.conf devono essere al di fuori di qualsiasi sezione di configurazione.

Percorso relativo nei valori

La maggior parte delle impostazioni consentite accetta il percorso del file o l'elenco di percorsi come valore. Se uno qualsiasi dei percorsi è un percorso pertinente, inizia senza una barra o una lettera di unità iniziale: verranno per lo più risolti in relazione alla directory principale di quell'ambiente.

Interpolazione in valori

Il file delle impostazioni Environment.conf è in grado di utilizzare i valori di altre impostazioni come variabili. Ci sono più variabili utili che possono essere interpolate nel file environment.conf. Ecco un elenco di poche variabili importanti:

• $basemodulepath- Utile per includere directory nelle impostazioni del percorso del modulo. L'utente aziendale Puppet dovrebbe solitamente includere questo valore dimodulepath poiché il motore Puppet utilizza il modulo nel file basemodulepath.

• $environment- Utile come argomento della riga di comando per lo script config_version. Puoi interpolare questa variabile solo nell'impostazione config_version.

• $codedir - Utile per localizzare i file.

Impostazioni consentite

Per impostazione predefinita, il file Puppet environment.conf può sovrascrivere solo quattro impostazioni nella configurazione elencate.

• Modulepath
• Manifest
• Config_version
• Environment_timeout

Modulepath

Questa è una delle impostazioni chiave nel file environment.conf. Tutti i director definiti in modulepath vengono caricati di default da Puppet. Questa è la posizione del percorso da cui Puppet carica i suoi moduli. È necessario impostarlo esplicitamente. Se questa impostazione di cui sopra non è impostata, il percorso del modulo predefinito di qualsiasi ambiente in Puppet sarà:

<MODULES DIRECTORY FROM ENVIRONMENT>:$basemodulepath

Manifesto

Viene utilizzato per definire il file manifest principale, che Puppet master utilizzerà durante l'avvio e la compilazione del catalogo dal manifest definito che verrà utilizzato per configurare l'ambiente. In questo, possiamo definire un singolo file, un elenco di file o anche una directory composta da più file manifest che devono essere valutati e compilati in una sequenza alfabetica definita.

È necessario definire esplicitamente questa impostazione nel file environment.conf. In caso contrario, Puppet utilizzerà la directory manifest predefinita degli ambienti come manifest principale.

Config_version

Config_version può essere definita come una versione definita utilizzata per identificare cataloghi ed eventi. Quando Puppet compila un file manifest per impostazione predefinita, aggiunge una versione di configurazione ai cataloghi generati e ai report che vengono generati quando il master Puppet applica qualsiasi catalogo definito sui nodi Puppet. Puppet esegue uno script per eseguire tutti i passaggi precedenti e utilizza tutto l'output generato come Config_version.

Timeout ambiente

Viene utilizzato per ottenere i dettagli sulla quantità di tempo che Puppet dovrebbe utilizzare per caricare i dati per un determinato ambiente. Se il valore è definito nel file puppet.conf, questi valori sovrascriveranno il valore di timeout predefinito.

File di esempio environment.conf

[master] 
   manifest =  $confdir/environments/$environment/manifests/site.pp 
   modulepath =  $confdir/environments/$environment/modules

Nel codice sopra $confdir è il percorso della directory, in cui si trovano i file di configurazione dell'ambiente. $environment è il nome dell'ambiente per il quale viene eseguita la configurazione.

File di configurazione dell'ambiente pronto per la produzione

# The environment configuration file  
# The main manifest directory or file where Puppet starts to evaluate code  
# This is the default value. Works with just a site.pp file or any other  
manifest = manifests/  
# The directories added to the module path, looked in first match first used order:  
# modules - Directory for external modules, populated by r10k based on Puppetfile  
# $basemodulepath - As from: puppet config print basemodulepath modulepath = site:modules:$basemodulepath  
# Set the cache timeout for this environment.  
# This overrides what is set directly in puppet.conf for the whole Puppet server  
# environment_timeout = unlimited  
# With caching you need to flush the cache whenever new Puppet code is deployed  
# This can also be done manually running: bin/puppet_flush_environment_cache.sh  
# To disable catalog caching:  
environment_timeout = 0  
# Here we pass to one in the control repo the Puppet environment (and git branch)  
# to get title and essential info of the last git commit
config_version = 'bin/config_script.sh $environment'

In Puppet, l'architettura server client di Puppet master è considerata l'autorità di controllo dell'intera configurazione. Il burattinaio funge da server nel setup e controlla tutte le attività su tutti i nodi.

Per qualsiasi server che deve agire come Puppet master, dovrebbe essere in esecuzione il software del server Puppet. Questo software server è il componente chiave per controllare tutte le attività sui nodi. In questa configurazione, un punto chiave da ricordare è avere un accesso super utente a tutte le macchine che si utilizzeranno nella configurazione. Di seguito sono riportati i passaggi per configurare Puppet master.

Prerequisiti

Private Network DNS- Devono essere configurati avanti e indietro, in cui ogni server dovrebbe avere un nome host univoco. Se non si dispone del DNS configurato, è possibile utilizzare una rete privata per la comunicazione con l'infrastruttura.

Firewall Open Port- Il burattinaio dovrebbe essere aperto su una particolare porta in modo che possa ascoltare le richieste in arrivo su una particolare porta. Possiamo usare qualsiasi porta aperta sul firewall.

Creazione di Puppet Master Server

Il burattinaio che stiamo creando sarà su CentOS 7 × 64 utilizzando Puppet come nome host. La configurazione di sistema minima per la creazione di Puppet master è di due core CPU e 1 GB di memoria. Anche la configurazione può avere dimensioni maggiori a seconda del numero di nodi che gestiremo con questo master. Nell'infrastruttura, è più grande di quanto sia configurato utilizzando 2 GB di RAM.

Nome host	Ruolo	FQDN privato
Brcleprod001	Burattinaio	bnrcleprod001.brcl.com

Successivamente, è necessario generare il certificato SSL del master Puppet e il nome della macchina master verrà copiato nel file di configurazione di tutti i nodi.

Installazione di NTP

Poiché Puppet master è l'autorità centrale per i nodi dell'agente in una determinata configurazione, è una delle responsabilità chiave del Puppet master mantenere l'ora di sistema precisa per evitare potenziali problemi di configurazione, che possono sorgere quando emette certificati di agente ai nodi.

Se si verifica un problema di conflitto temporale, i certificati possono sembrare scaduti se sono presenti discrepanze temporali tra il master e il nodo. Il protocollo del tempo di rete è uno dei meccanismi chiave per evitare questo tipo di problemi.

Elenco dei fusi orari disponibili

$ timedatectl list-timezones

Il comando precedente fornirà un intero elenco di fusi orari disponibili. Fornirà alle regioni la disponibilità del fuso orario.

Il seguente comando può essere utilizzato per impostare il fuso orario richiesto sulla macchina.

$ sudo timedatectl set-timezone India/Delhi

Installa NTP sulla macchina server Puppet utilizzando l'utility yum della macchina CentOS.

$ sudo yum -y install ntp

Sincronizza NTP con l'ora di sistema che abbiamo impostato nei comandi precedenti.

$ sudo ntpdate pool.ntp.org

Nella pratica comune, aggiorneremo la configurazione NTP per utilizzare pool comuni disponibili più vicino ai data center della macchina. Per questo, dobbiamo modificare il file ntp.conf sotto/etc.

$ sudo vi /etc/ntp.conf

Aggiungere il server dell'orario dai fusi orari del pool NTP disponibili. Di seguito è riportato l'aspetto del file ntp.conf.

brcleprod001.brcl.pool.ntp.org 
brcleprod002.brcl.pool.ntp.org 
brcleprod003.brcl.pool.ntp.org
brcleprod004.brcl.pool.ntp.org

Salva la configurazione. Avvia il server e abilita il daemon.

$ sudo systemctl restart ntpd $ sudo systemctl enable ntpd

Configurazione del software Puppet Server

Il software del server Puppet è un software che viene eseguito sulla macchina master Puppet. È la macchina che invia le configurazioni ad altre macchine che eseguono il software dell'agente Puppet.

Abilita il repository di raccolta ufficiale di Puppet Labs utilizzando il seguente comando.

$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpm

Installa il pacchetto Puppetserver.

$ sudo yum -y install puppetserver

Configurare l'allocazione della memoria sul server Puppet

Come abbiamo discusso, per impostazione predefinita, il server Puppet viene configurato su una macchina RAM da 2 GB. È possibile personalizzare il setup in base alla memoria libera disponibile sulla macchina e al numero di nodi che il server gestirà.

Modifica la configurazione del server pupazzo in modalità vi

$ sudo vi /etc/sysconfig/puppetserver  
Find the JAVA_ARGS and use the –Xms and –Xms options to set the memory allocation. 
We will allocate 3GB of space  
JAVA_ARGS="-Xms3g -Xmx3g"

Una volta fatto, salva ed esci dalla modalità di modifica.

Dopo che tutte le impostazioni di cui sopra sono state completate, siamo pronti per avviare il server Puppet sulla macchina master con il seguente comando.

$ sudo systemctl start puppetserver

Successivamente, eseguiremo la configurazione in modo che il server pupazzo venga avviato ogni volta che viene avviato il server principale.

$ sudo systemctl enable puppetserver

Sezione Puppet.conf Master

[master] 
autosign = $confdir/autosign.conf { mode = 664 } 
reports = foreman 
external_nodes = /etc/puppet/node.rb 
node_terminus = exec 
ca = true 
ssldir = /var/lib/puppet/ssl 
certname = sat6.example.com 
strict_variables = false 
manifest = 
/etc/puppet/environments/$environment/manifests/site.pp modulepath = /etc/puppet/environments/$environment/modules 
config_version =

L'agente Puppet è un'applicazione software, fornita da Puppet Labs, che viene eseguita su qualsiasi nodo nel cluster Puppet. Se si desidera gestire qualsiasi server utilizzando il Puppet master, il software dell'agente Puppet deve essere installato su quel particolare server. In generale, l'agente Puppet verrà installato su tutte le macchine ad eccezione della macchina master Puppet su qualsiasi infrastruttura data. Il software dell'agente Puppet può essere eseguito sulla maggior parte delle macchine Linux, UNIX e Windows. Nei seguenti esempi, stiamo utilizzando il software dell'agente Puppet per l'installazione su macchina CentOS.

Step 1 - Abilita il repository di raccolta ufficiale di Puppet labs con il seguente comando.

$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpm

Step 2 - Installa il pacchetto dell'agente Puppet.

$ sudo yum -y install puppet-agent

Step 3 - Una volta installato l'agente Puppet, abilitalo con il seguente comando.

$ sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable = true

Una caratteristica chiave dell'agente Puppet è che, per la prima volta, quando l'agente Puppet inizia a funzionare, genera un certificato SSL e lo invia al Puppet master che lo gestirà per la firma e l'approvazione. Una volta che il Puppet master ha approvato la richiesta di firma del certificato dell'agente, sarà in grado di comunicare e gestire il nodo dell'agente.

Note - È necessario ripetere i passaggi precedenti su tutti i nodi che devono essere configurati e gestiti da un determinato Puppet master.

Quando il software dell'agente Puppet viene eseguito per la prima volta su qualsiasi nodo Puppet, genera un certificato e invia la richiesta di firma del certificato al master Puppet. Prima che il server Puppet sia in grado di comunicare e controllare i nodi dell'agente, deve firmare il certificato di quel particolare nodo dell'agente. Nelle sezioni seguenti, descriveremo come firmare e controllare la richiesta di firma.

Elenca le richieste di certificati correnti

In Puppet master, esegui il comando seguente per visualizzare tutte le richieste di certificato non firmate.

$ sudo /opt/puppetlabs/bin/puppet cert list

Poiché abbiamo appena impostato un nuovo nodo agente, vedremo una richiesta di approvazione. Di seguito sarà iloutput.

"Brcleprod004.brcl.com" (SHA259) 
15:90:C2:FB:ED:69:A4:F7:B1:87:0B:BF:F7:ll:
B5:1C:33:F7:76:67:F3:F6:45:AE:07:4B:F 6:E3:ss:04:11:8d

Non contiene alcun segno + (segno) all'inizio, che indica che il certificato non è ancora firmato.

Firma una richiesta

Per firmare la nuova richiesta di certificato che è stata generata quando è avvenuta l'esecuzione dell'agente Puppet sul nuovo nodo, verrebbe utilizzato il comando Puppet cert sign, con il nome host del certificato, che è stato generato dal nodo appena configurato che necessita da firmare. Poiché abbiamo il certificato di Brcleprod004.brcl.com, useremo il seguente comando.

$ sudo /opt/puppetlabs/bin/puppet cert sign Brcleprod004.brcl.com

Di seguito sarà il output.

Notice: Signed certificate request for Brcle004.brcl.com 
Notice: Removing file Puppet::SSL::CertificateRequest Brcle004.brcl.com at 
'/etc/puppetlabs/puppet/ssl/ca/requests/Brcle004.brcl.com.pem'

Il server pupazzo può ora comunicare con il nodo, a cui appartiene il certificato di firma.

$ sudo /opt/puppetlabs/bin/puppet cert sign --all

Revoca dell'host dalla configurazione del pupazzo

Ci sono condizioni sulla configurazione della ricostruzione del kernel quando è necessario rimuovere l'host dal setup e aggiungerlo di nuovo. Queste sono quelle condizioni che non possono essere gestite dal burattino stesso. Potrebbe essere fatto utilizzando il seguente comando.

$ sudo /opt/puppetlabs/bin/puppet cert clean hostname

Visualizzazione di tutte le richieste firmate

Il comando seguente genererà un elenco di certificati firmati con + (segno) che indica che la richiesta è stata approvata.

$ sudo /opt/puppetlabs/bin/puppet cert list --all

Di seguito sarà il suo output.

+ "puppet" (SHA256) 5A:71:E6:06:D8:0F:44:4D:70:F0:
BE:51:72:15:97:68:D9:67:16:41:B0:38:9A:F2:B2:6C:B 
B:33:7E:0F:D4:53 (alt names: "DNS:puppet", "DNS:Brcle004.nyc3.example.com")  

+ "Brcle004.brcl.com" (SHA259) F5:DC:68:24:63:E6:F1:9E:C5:FE:F5:
1A:90:93:DF:19:F2:28:8B:D7:BD:D2:6A:83:07:BA:F E:24:11:24:54:6A 

+ " Brcle004.brcl.com" (SHA259) CB:CB:CA:48:E0:DF:06:6A:7D:75:E6:CB:22:BE:35:5A:9A:B3

Una volta fatto quanto sopra, abbiamo la nostra infrastruttura pronta in cui il Puppet master è ora in grado di gestire i nodi appena aggiunti.

In Puppet, abbiamo uno strumento di gestione del codice noto come r10k che aiuta a gestire le configurazioni dell'ambiente relative a diversi tipi di ambienti che possiamo configurare in Puppet come sviluppo, test e produzione. Ciò aiuta a memorizzare la configurazione relativa all'ambiente nel repository del codice sorgente. Utilizzando i rami del repository di controllo del codice sorgente, r10k crea ambienti sulla macchina master Puppet e installa l'ambiente utilizzando i moduli presenti nel repository.

Il file Gem può essere usato per installare r10k su qualsiasi macchina ma per modularità e per ottenere l'ultima versione, useremo rpm e gestori di pacchetti rpm. Di seguito è riportato un esempio per lo stesso.

$ urlgrabber -o /etc/yum.repos.d/timhughes-r10k-epel-6.repo
https://copr.fedoraproject.org/coprs/timhughes/yum -y install rubygem-r10k

Configura l'ambiente in /etc/puppet/puppet.conf

[main] 
environmentpath = $confdir/environments

Creare un file di configurazione per r10k Config

cat <<EOF >/etc/r10k.yaml 
# The location to use for storing cached Git repos 
:cachedir: '/var/cache/r10k' 
# A list of git repositories to create 
:sources: 
# This will clone the git repository and instantiate an environment per 
# branch in /etc/puppet/environments 
:opstree: 
#remote: 'https://github.com/fullstack-puppet/fullstackpuppet-environment.git' 
remote: '/var/lib/git/fullstackpuppet-environment.git' 
basedir: '/etc/puppet/environments' 
EOF

Installazione di Puppet Manifest e Module

r10k deploy environment -pv

Dato che dobbiamo continuare ad aggiornare l'ambiente ogni 15 minuti, creeremo un cron job per lo stesso.

cat << EOF > /etc/cron.d/r10k.conf 
SHELL = /bin/bash 
PATH = /sbin:/bin:/usr/sbin:/usr/bin 
H/15 * * * * root r10k deploy environment -p 
EOF

Installazione di prova

Per verificare se tutto funziona come accettato, è necessario compilare il manifest di Puppet per il modulo Puppet. Esegui il seguente comando e ottieni un output YAML come risultato.

curl --cert /etc/puppet/ssl/certs/puppet.corp.guest.pem \ 
--key /etc/puppet/ssl/private_keys/puppet.corp.guest.pem \ 
--cacert /etc/puppet/ssl/ca/ca_crt.pem \ 
-H 'Accept: yaml' \ 
https://puppet.corp.guest:8140/production/catalog/puppet.corp.guest

In Puppet, l'installazione può essere testata localmente. Quindi, una volta che abbiamo impostato Puppet master e node, è il momento di convalidare la configurazione localmente. Abbiamo bisogno di installare localmente Vagrant e Vagrant box, il che aiuta a testare la configurazione localmente.

Configurazione della macchina virtuale

Poiché stiamo testando la configurazione in locale, in realtà non è necessario un Puppet master in esecuzione. Ciò significa che senza eseguire effettivamente il Puppet master sul server, possiamo semplicemente utilizzare Puppet per applicare il comando per la convalida dell'installazione di Puppet. Il comando Puppet applica applicherà le modifiche dalocal/etc/puppet a seconda del nome host della macchina virtuale nel file di configurazione.

Il primo passaggio che dobbiamo eseguire per testare la configurazione è creare quanto segue Vagrantfile e avvia una macchina e monta il file /etc/puppetcartella in posizione. Tutti i file necessari verranno inseriti nel sistema di controllo delle versioni con la seguente struttura.

Struttura delle directory

- manifests 
   \- site.pp 
- modules 
   \- your modules  
- test 
   \- update-puppet.sh 
   \- Vagrantfile 
- puppet.conf

File vagabondo

# -*- mode: ruby -*- 
# vi: set ft = ruby : 
Vagrant.configure("2") do |config| 
   config.vm.box = "precise32" 
   config.vm.box_url = "http://files.vagrantup.com/precise64.box" 
   config.vm.provider :virtualbox do |vb| 
      vb.customize ["modifyvm", :id, "--memory", 1028, "--cpus", 2] 
   end 
  
   # Mount our repo onto /etc/puppet 
   config.vm.synced_folder "../", "/etc/puppet"  
   
   # Run our Puppet shell script   
   config.vm.provision "shell" do |s| 
      s.path = "update-puppet.sh" 
   end  
 
   config.vm.hostname = "localdev.example.com" 
end

Nel codice sopra, abbiamo utilizzato Shell provisioner in cui stiamo cercando di eseguire uno script Shell denominato update-puppet.sh. Lo script è presente nella stessa directory in cui si trova il file Vagrant e il contenuto dello script è elencato di seguito.

!/bin/bash 
echo "Puppet version is $(puppet --version)" if [ $( puppet --version) != "3.4.1" ]; then  
   echo "Updating puppet" 
   apt-get install --yes lsb-release 
   DISTRIB_CODENAME = $(lsb_release --codename --short) DEB = "puppetlabs-release-${DISTRIB_CODENAME}.deb" 
   DEB_PROVIDES="/etc/apt/sources.list.d/puppetlabs.list"  
   
   if [ ! -e $DEB_PROVIDES ] then wget -q http://apt.puppetlabs.com/$DEB 
      sudo dpkg -i $DEB 
   fi  
sudo apt-get update 
   sudo apt-get install -o Dpkg::Options:: = "--force-confold" 
   --force-yes -y puppet 
else 
   echo "Puppet is up to date!" 
fi

Ulteriore elaborazione, l'utente deve creare un file manifest all'interno della directory Manifests con il nome site.pp che installerà del software sulla VM.

node 'brclelocal03.brcl.com' { 
   package { ['vim','git'] : 
      ensure => latest 
   } 
} 
echo "Running puppet" 
sudo puppet apply /etc/puppet/manifests/site.pp

Una volta che l'utente ha lo script sopra pronto con la configurazione del file Vagrant richiesta, l'utente può accedere alla directory di test ed eseguire il vagrant up command. Questo avvierà una nuova VM, in seguito installerà Puppet e quindi lo eseguirà utilizzando lo script Shell.

Di seguito sarà l'output.

Notice: Compiled catalog for localdev.example.com in environment production in 0.09 seconds 
Notice: /Stage[main]/Main/Node[brclelocal03.brcl.com]/Package[git]/ensure: created 
Notice: /Stage[main]/Main/Node[brcllocal03.brcl.com]/Package[vim]/ensure: ensure changed 'purged' to 'latest'

Convalida della configurazione di più macchine

Se è necessario testare la configurazione di più macchine in locale, è possibile farlo semplicemente apportando una modifica al file di configurazione di Vagrant.

Nuovo file Vagrant configurato

config.vm.define "brclelocal003" do |brclelocal003| 
   brclelocal03.vm.hostname = "brclelocal003.brcl.com" 
end  

config.vm.define "production" do |production| 
   production.vm.hostname = "brcleprod004.brcl.com" 
end

Supponiamo di avere un nuovo server di produzione, che richiede l'installazione dell'utilità SSL. Abbiamo solo bisogno di estendere il vecchio manifest con la seguente configurazione.

node 'brcleprod004.brcl.com' inherits 'brcleloacl003.brcl.com' { 
   package { ['SSL'] : 
      ensure => latest 
   } 
}

Dopo aver apportato modifiche alla configurazione nel file manifest, dobbiamo solo spostarci nella directory di test ed eseguire il comando di base vagrant up che farà apparire entrambi brclelocal003.brcl.com e brcleprod004.brcl.commacchina. Nel nostro caso, stiamo cercando di richiamare la macchina di produzione che potrebbe essere eseguita eseguendo ilvagrant up production command. Creerà una nuova macchina con il nome production come definito nel file Vagrant e avrà installato il pacchetto SSL.

In Puppet, lo stile di codifica definisce tutti gli standard che è necessario seguire durante il tentativo di convertire l'infrastruttura sulla configurazione della macchina in un codice. Puppet lavora ed esegue tutte le attività definite utilizzando le risorse.

La definizione del linguaggio di Puppet aiuta a specificare tutte le risorse in modo strutturato, necessario per gestire qualsiasi macchina di destinazione che deve essere gestita. Puppet utilizza Ruby come linguaggio di codifica, che ha più funzionalità integrate che rendono molto facile fare le cose con una semplice configurazione sul lato codice.

Unità fondamentali

Puppet utilizza più stili di codifica fondamentali che sono facili da capire e gestire. Di seguito è riportato un elenco di pochi.

Risorse

In Puppet, le risorse sono note come unità di modellazione fondamentali che vengono utilizzate per gestire o modificare qualsiasi sistema di destinazione. Le risorse coprono tutti gli aspetti di un sistema come file, servizio e pacchetto. Puppet viene fornito con una funzionalità incorporata in cui consente agli utenti o agli sviluppatori di sviluppare risorse personalizzate, che aiutano nella gestione di una particolare unità di una macchina

In Puppet, tutte le risorse vengono aggregate insieme utilizzando “define” o “classes”. Queste funzionalità di aggregazione aiutano nell'organizzazione di un modulo. Di seguito è riportata una risorsa di esempio composta da più tipi, un titolo e un elenco di attributi con cui Puppet può supportare più attributi. Ogni risorsa in Puppet ha il proprio valore predefinito, che può essere sovrascritto quando necessario.

Risorsa Puppet di esempio per file

Nel seguente comando, stiamo cercando di specificare un'autorizzazione per un particolare file.

file {  
   '/etc/passwd': 
   owner => superuser, 
   group => superuser, 
   mode => 644, 
}

Ogni volta che il comando precedente viene eseguito su qualsiasi macchina, verificherà che il file passwd nel sistema sia configurato come descritto. Il file prima di: due punti è il titolo della risorsa, che può essere definita risorsa in altre parti della configurazione di Puppet.

Specificare il nome locale oltre al titolo

file { 'sshdconfig': 
   name => $operaSystem ? { 
      solaris => '/usr/local/etc/ssh/sshd_config', 
      default => '/etc/ssh/sshd_config', 
   }, 
   owner => superuser, 
   group => superuser, 
   mode => 644, 
}

Utilizzando il titolo, che è sempre lo stesso, è molto facile fare riferimento alla risorsa del file in configurazione senza dover ripetere la logica relativa al SO.

Un altro esempio potrebbe essere l'utilizzo di un servizio che dipende da un file.

service { 'sshd': 
   subscribe => File[sshdconfig], 
}

Con questa dipendenza, il sshd il servizio verrà sempre riavviato una volta che il sshdconfigmodifiche ai file. Il punto da ricordare qui èFile[sshdconfig] è una dichiarazione come File come in minuscolo ma se la cambiamo in FILE[sshdconfig] allora sarebbe stato un riferimento.

Un punto fondamentale da tenere a mente quando si dichiara una risorsa è che può essere dichiarata solo una volta per file di configurazione. La ripetizione della dichiarazione della stessa risorsa più di una volta causerà un errore. Attraverso questo concetto fondamentale, Puppet si assicura che la configurazione sia ben modellata.

Abbiamo anche la capacità di gestire la dipendenza dalle risorse che aiuta a gestire più relazioni.

service { 'sshd': 
   require => File['sshdconfig', 'sshconfig', 'authorized_keys']
}

Metaparametri

I metaparametri sono noti come parametri globali in Puppet. Una delle caratteristiche chiave di metaparameter è che funziona con qualsiasi tipo di risorsa in Puppet.

Risorsa predefinita

Quando è necessario definire un valore di attributo di risorsa predefinito, Puppet fornisce una serie di sintassi per archiviarlo, utilizzando una specifica di risorsa in maiuscolo che non ha titolo.

Ad esempio, se vogliamo impostare il percorso di default di tutti gli eseguibili lo si può fare con il seguente comando.

Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin' } 
exec { 'echo Testing mataparamaters.': }

Nel comando precedente, la prima istruzione Exec imposterà il valore predefinito per la risorsa exec. La risorsa Exec richiede un percorso completo o un percorso che assomigli a un eseguibile. Con questo, è possibile definire un unico percorso predefinito per l'intera configurazione. I valori predefiniti funzionano con qualsiasi tipo di risorsa in Puppet.

I valori predefiniti non sono valori globali, tuttavia, influenzano solo l'ambito in cui sono definiti o la variabile immediatamente successiva. Se si vuole definiredefault per una configurazione completa, definiamo quindi il file default e la classe nella sezione successiva.

Raccolte di risorse

L'aggregazione è un metodo per raccogliere le cose insieme. Puppet supporta un concetto molto potente di aggregazione. In Puppet, l'aggregazione viene utilizzata per raggruppare la risorsa che è l'unità fondamentale di Puppet insieme. Questo concetto di aggregazione in Puppet si ottiene utilizzando due potenti metodi noti comeclasses e definition.

Classi e definizione

Le classi sono responsabili della modellazione degli aspetti fondamentali di node. Possono dire che il nodo è un server web e questo particolare nodo è uno di loro. In Puppet, le classi di programmazione sono singleton e possono essere valutate una volta per nodo.

La definizione d'altra parte può essere utilizzata molte volte su un singolo nodo. Funzionano in modo simile quando si è creato il proprio tipo di marionetta utilizzando il linguaggio. Sono creati per essere utilizzati più volte con input diversi ogni volta. Ciò significa che si possono passare i valori delle variabili nella definizione.

Differenza tra classe e definizione

L'unica differenza fondamentale tra una classe e una definizione è che durante la definizione della struttura dell'edificio e l'allocazione delle risorse, la classe viene valutata solo una volta per nodo, in cui, d'altra parte, una definizione viene utilizzata più volte sullo stesso singolo nodo.

Classi

Le classi in Puppet vengono introdotte utilizzando la parola chiave class e il contenuto di quella particolare classe viene racchiuso tra parentesi graffe come mostrato nell'esempio seguente.

class unix { 
   file { 
      '/etc/passwd': 
      owner => 'superuser', 
      group => 'superuser', 
      mode => 644; 
      '/etc/shadow': 
      owner => 'vipin', 
      group => 'vipin', 
      mode => 440; 
   } 
}

Nell'esempio seguente, abbiamo usato una mano corta simile a quella sopra.

class unix { 
   file { 
      '/etc/passwd': 
      owner => 'superuser', 
      group => 'superuser', 
      mode => 644; 
   }  
   
   file {'/etc/shadow': 
      owner => 'vipin', 
      group => 'vipin', 
      mode => 440; 
   } 
}

Eredità nelle classi Puppet

In Puppet, il concetto di ereditarietà OOP è supportato per impostazione predefinita in cui le classi possono estendere le funzionalità del precedente senza copiare e incollare nuovamente il bit di codice completo nella classe appena creata. L'ereditarietà consente alla sottoclasse di sovrascrivere le impostazioni delle risorse definite nella classe padre. Una cosa fondamentale da tenere a mente quando si utilizza l'ereditarietà è che una classe può ereditare solo funzionalità da una sola classe genitore, non più di una.

class superclass inherits testsubclass { 
   File['/etc/passwd'] { group => wheel } 
   File['/etc/shadow'] { group => wheel } 
}

Se è necessario annullare una logica specificata in una classe genitore, possiamo usare undef command.

class superclass inherits testsubcalss { 
   File['/etc/passwd'] { group => undef } 
}

Modo alternativo di utilizzare l'ereditarietà

class tomcat { 
   service { 'tomcat': require => Package['httpd'] } 
} 
class open-ssl inherits tomcat { 
   Service[tomcat] { require +> File['tomcat.pem'] } 
}

Classe annidata in Puppet

Puppet supporta il concetto di annidamento delle classi in cui consente di utilizzare classi annidate che significa una classe dentro l'altra. Questo aiuta a raggiungere la modularità e l'ambito.

class testclass { 
   class nested { 
      file {  
         '/etc/passwd': 
         owner => 'superuser', 
         group => 'superuser', 
         mode => 644; 
      } 
   } 
} 
class anotherclass { 
   include myclass::nested 
}

Classi parametrizzate

In Puppet, le classi possono estendere le loro funzionalità per consentire il passaggio di parametri in una classe.

Per passare un parametro in una classe, è possibile utilizzare il seguente costrutto:

class tomcat($version) { 
   ... class contents ... 
}

Un punto chiave da ricordare in Puppet è che le classi con parametri non vengono aggiunte utilizzando la funzione include, ma la classe risultante può essere aggiunta come definizione.

node webserver { 
   class { tomcat: version => "1.2.12" } 
}

Valori predefiniti come parametri nella classe

class tomcat($version = "1.2.12",$home = "/var/www") { 
   ... class contents ... 
}

Esegui fasi

Puppet supporta il concetto di fase di esecuzione, il che significa che l'utente può aggiungere più fasi secondo il requisito al fine di gestire una particolare risorsa o più risorse. Questa funzione è molto utile quando l'utente desidera sviluppare un catalogo complesso. In un catalogo complesso, si ha un gran numero di risorse che devono essere compilate tenendo presente che le dipendenze tra le risorse definite non dovrebbero essere influenzate.

Run Stage è molto utile per gestire le dipendenze delle risorse. Questo può essere fatto aggiungendo classi in fasi definite in cui una particolare classe contiene una raccolta di risorse. Con la fase di esecuzione, Puppet garantisce che le fasi definite verranno eseguite in un ordine prevedibile specificato ogni volta che il catalogo viene eseguito e viene applicato su qualsiasi nodo Puppet.

Per utilizzarlo, è necessario dichiarare fasi aggiuntive oltre le fasi già presenti e quindi Puppet può essere configurato per gestire ciascuna fase in un ordine specificato utilizzando la stessa sintassi della relazione di risorsa prima di richiedere “->” e “+>”. La relazione garantirà quindi l'ordine delle classi associate a ciascuna fase.

Dichiarazione di fasi aggiuntive con la sintassi dichiarativa di Puppet

stage { "first": before => Stage[main] } 
stage { "last": require => Stage[main] }

Una volta dichiarate le tappe, allo stage può essere associata una classe diversa da quella principale che utilizza lo stage.

class { 
   "apt-keys": stage => first; 
   "sendmail": stage => main; 
   "apache": stage => last; 
}

Tutte le risorse associate alla classe apt-key verranno eseguite per prime. Tutte le risorse in Sendmail saranno la classe principale e le risorse associate ad Apache saranno l'ultima fase.

Definizioni

In Puppet, la raccolta di risorse in qualsiasi file manifest viene eseguita da classi o definizioni. Le definizioni sono molto simili a una classe in Puppet, tuttavia vengono introdotte con undefine keyword (not class)e supportano l'argomento non l'ereditarietà. Possono essere eseguiti più volte sullo stesso sistema con parametri diversi.

Ad esempio, se si desidera creare una definizione che controlli i repository del codice sorgente in cui si sta tentando di creare più repository sullo stesso sistema, è possibile utilizzare la definizione e non la classe.

define perforce_repo($path) { 
   exec {  
      "/usr/bin/svnadmin create $path/$title": 
      unless => "/bin/test -d $path", 
   } 
} 
svn_repo { puppet_repo: path => '/var/svn_puppet' } 
svn_repo { other_repo: path => '/var/svn_other' }

Il punto chiave da notare qui è come una variabile può essere utilizzata con una definizione. Noi usiamo ($) variabile del segno del dollaro. In quanto sopra, abbiamo usato$title. Definitions can have both a $titolo e $name with which the name and the title can be represented. By default, $titolo e $name are set to the same value, but one can set a title attribute and pass different name as a parameter. $title e $ name funzionano solo nella definizione, non nella classe o in un'altra risorsa.

Moduli

Un modulo può essere definito come una raccolta di tutte le configurazioni che verrebbero utilizzate dal master Puppet per applicare modifiche alla configurazione su un particolare nodo (agente) di Puppet. Sono anche noti come raccolte portatili di diversi tipi di configurazioni, necessarie per eseguire un'attività specifica. Ad esempio, un modulo potrebbe contenere tutte le risorse necessarie per configurare Postfix e Apache.

Nodi

I nodi sono un passaggio rimanente molto semplice, che è il modo in cui abbiniamo ciò che abbiamo definito ("questo è l'aspetto di un server web") a quali macchine vengono scelte per eseguire quelle istruzioni.

La definizione del nodo assomiglia esattamente alle classi, inclusa l'ereditarietà di supporto, tuttavia sono speciali in modo tale che quando un nodo (un computer gestito che esegue un client puppet) si connette al daemon di Puppet master, il suo nome verrà visualizzato nell'elenco definito di nodi. Le informazioni definite verranno valutate per il nodo, quindi il nodo invierà quella configurazione.

Il nome del nodo può essere un nome host breve o il nome di dominio completo (FQDN).

node 'www.vipin.com' { 
   include common 
   include apache, squid 
}

La definizione precedente crea un nodo chiamato www.vipin.com e include la classe common, Apache e Squid

Possiamo inviare la stessa configurazione a nodi diversi separandoli con una virgola.

node 'www.testing.com', 'www.testing2.com', 'www3.testing.com' { 
   include testing 
   include tomcat, squid 
}

Espressione regolare per i nodi corrispondenti

node /^www\d+$/ { 
   include testing 
}

Ereditarietà dei nodi

Node supporta un modello di ereditarietà limitata. Come le classi, i nodi possono ereditare solo da un altro nodo.

node 'www.testing2.com' inherits 'www.testing.com' { 
   include loadbalancer 
}

Nel codice precedente, www.testing2.com eredita tutte le funzionalità da www.testing.com oltre a un'ulteriore classe di bilanciamento del carico.

Funzionalità avanzate supportate

Quoting- Nella maggior parte dei casi, non è necessario citare una stringa in Puppet. Qualsiasi stringa alfanumerica che inizia con una lettera deve essere lasciata senza virgolette. Tuttavia, è sempre consigliabile citare una stringa per qualsiasi valore non negativo.

Interpolazione variabile con virgolette

Finora abbiamo menzionato la variabile in termini di definizione. Se è necessario utilizzare queste variabili con una stringa, utilizzare virgolette doppie, non virgolette singole. La stringa di virgolette singole non eseguirà alcuna interpolazione variabile, la stringa di virgolette doppie lo farà. La variabile può essere racchiusa tra parentesi{} che li rende più facili da usare insieme e più facili da capire.

$value = "${one}${two}"

Come best practice, è consigliabile utilizzare virgolette singole per tutte le stringhe che non richiedono l'interpolazione di stringhe.

Capitalizzazione

Le maiuscole sono un processo utilizzato per fare riferimento, ereditare e impostare gli attributi predefiniti di una particolare risorsa. Ci sono fondamentalmente due modi fondamentali per usarlo.

• Referencing- È il modo per fare riferimento a una risorsa già creata. Viene utilizzato principalmente per scopi di dipendenza, si deve scrivere in maiuscolo il nome della risorsa. Esempio, require => file [sshdconfig]

• Inheritance- Quando si sovrascrive l'impostazione per la classe genitore dalla sottoclasse, utilizzare la versione in maiuscolo del nome della risorsa. L'uso della versione minuscola provocherà un errore.

• Setting Default Attribute Value - L'utilizzo della risorsa in maiuscolo senza titolo funziona per impostare il valore predefinito della risorsa.

Array

Puppet consente l'uso di array in più aree [Uno, due, tre].

Diversi membri di tipo, come l'alias nella definizione host, accettano array nei loro valori. Una risorsa host con più alias avrà l'aspetto seguente.

host { 'one.vipin.com': 
   alias => [ 'satu', 'dua', 'tiga' ], 
   ip => '192.168.100.1', 
   ensure => present, 
}

Il codice sopra aggiungerà un host ‘one.brcletest.com’ all'elenco degli host con tre alias ‘satu’ ‘dua’ ‘tiga’. Se si desidera aggiungere più risorse a una risorsa, è possibile farlo come mostrato nell'esempio seguente.

resource { 'baz': 
   require => [ Package['rpm'], File['testfile'] ], 
}

Variabili

Puppet supporta più variabili come la maggior parte degli altri linguaggi di programmazione. Le variabili Puppet sono indicate con$.

$content = 'some content\n' file { '/tmp/testing': content => $content }

Come affermato in precedenza, Puppet è un linguaggio dichiarativo, il che significa che il suo ambito e le regole di assegnazione sono diversi dal linguaggio imperativo. La differenza principale è che non è possibile modificare la variabile all'interno di un unico ambito, perché si basano sull'ordine nel file per determinare il valore di una variabile. L'ordine non ha importanza nel linguaggio dichiarativo.

$user = root file { '/etc/passwd': owner => $user, 
} 

$user = bin file { '/bin': owner => $user, 
      recurse => true, 
   }

Ambito variabile

L'ambito delle variabili definisce se tutte le variabili definite sono valide. Come con le ultime funzionalità, Puppet è attualmente con scope dinamico, il che in termini di Puppet significa che tutte le variabili definite vengono valutate in base al loro ambito piuttosto che alla posizione in cui sono definite.

$test = 'top' class Testclass { exec { "/bin/echo $test": logoutput => true } 
} 

class Secondtestclass { 
   $test = 'other' 
   include myclass 
} 

include Secondtestclass

Variabile qualificata

Puppet supporta l'uso di variabili qualificate all'interno di una classe o di una definizione. Ciò è molto utile quando l'utente desidera utilizzare la stessa variabile in altre classi, che ha definito o che definirà.

class testclass { 
   $test = 'content' 
} 

class secondtestclass { 
   $other = $myclass::test 
}

Nel codice precedente, il valore di $ altra variabile valuta il contenuto.

Condizionali

Le condizioni sono situazioni in cui l'utente desidera eseguire una serie di istruzioni o codice quando la condizione definita o la condizione richiesta è soddisfatta. Puppet supporta due tipi di condizioni.

La condizione del selettore che può essere utilizzata solo all'interno delle risorse definite per scegliere il valore corretto della macchina.

Le condizioni dell'istruzione sono condizioni più ampiamente utilizzate in manifest che aiutano a includere classi aggiuntive che l'utente desidera includere nello stesso file manifest. Definisci un insieme distinto di risorse all'interno di una classe o prendi altre decisioni strutturali.

Selettori

I selettori sono utili quando l'utente desidera specificare un attributo di risorsa e variabili che sono diversi dai valori predefiniti in base ai fatti o ad altre variabili. In Puppet, l'indice del selettore funziona come un operatore a tre vie multivalore. I selettori sono anche in grado di definire i valori predefiniti personalizzati in nessun valore, che sono definiti nel file manifest e corrispondono alla condizione.

$owner = $Sysoperenv ? { 
   sunos => 'adm', 
   redhat => 'bin', 
   default => undef, 
}

Nelle versioni successive di Puppet 0.25.0 i selettori possono essere utilizzati come espressioni regolari.

$owner = $Sysoperenv ? { 
   /(Linux|Ubuntu)/ => 'bin', 
   default => undef, 
}

Nell'esempio sopra, il selettore $Sysoperenv il valore corrisponde a Linux o Ubuntu, quindi il cestino sarà il risultato selezionato, altrimenti l'utente verrà impostato come non definito.

Condizione della dichiarazione

La condizione dell'istruzione è un altro tipo di istruzione condizionale in Puppet che è molto simile alla condizione di cambio delle maiuscole nello script Shell. In questo, viene definito un insieme multiplo di istruzioni case e i valori di input forniti vengono confrontati con ciascuna condizione.

L'istruzione case che corrisponde alla condizione di input data viene eseguita. Questa condizione dell'istruzione case non ha alcun valore di ritorno. In Puppet, un caso d'uso molto comune per l'istruzione condition è l'esecuzione di un set di bit di codice basato sul sistema operativo sottostante.

case $ Sysoperenv { 
   sunos: { include solaris }  
   redhat: { include redhat }  
   default: { include generic}  
}

L'istruzione Case può anche specificare più condizioni separandole con una virgola.

case $Sysoperenv { 
   development,testing: { include development } testing,production: { include production }
   default: { include generic }  
}

Istruzione If-Else

Puppet supporta il concetto di operazione basata sulle condizioni. Per ottenerlo, l'istruzione If / else fornisce opzioni di ramificazione basate sul valore di ritorno della condizione. Come mostrato nell'esempio seguente:

if $Filename { 
   file { '/some/file': ensure => present } 
} else { 
   file { '/some/other/file': ensure => present } 
}

L'ultima versione di Puppet supporta l'espressione variabile in cui l'istruzione if può anche ramificarsi in base al valore di un'espressione.

if $machine == 'production' { 
   include ssl 
} else { 
   include nginx 
}

Per ottenere una maggiore diversità nel codice ed eseguire complesse operazioni condizionali, Puppet supporta l'istruzione if / else annidata come mostrato nel codice seguente.

if $ machine == 'production' { include ssl } elsif $ machine == 'testing' { 
   include nginx
} else { 
   include openssl 
}

Risorsa virtuale

Le risorse virtuali sono quelle che non vengono inviate al client se non realizzate.

Di seguito è riportata la sintassi per utilizzare la risorsa virtuale in Puppet.

@user { vipin: ensure => present }

Nell'esempio sopra, l'utente vipin è definito virtualmente per realizzare la definizione che si può usare nella raccolta.

User <| title == vipin |>

Commenti

I commenti vengono utilizzati in qualsiasi bit di codice per creare un nodo aggiuntivo su un insieme di righe di codice e sulla sua funzionalità. In Puppet, ci sono attualmente due tipi di commenti supportati.

• Commenti in stile shell Unix. Possono essere sulla propria riga o sulla riga successiva.
• Commenti in stile c su più righe.

Di seguito è riportato un esempio di commento in stile shell.

# this is a comment

Di seguito è riportato un esempio di commento su più righe.

/* 
This is a comment 
*/

Precedenza operatore

La precedenza degli operatori Puppet è conforme alla precedenza standard nella maggior parte dei sistemi, dalla più alta alla più bassa.

Di seguito è riportato l'elenco delle espressioni

• ! = no
• / = volte e dividere
• - + = meno, più
• << >> = spostamento a sinistra e spostamento a destra
• ==! = = non uguale, uguale
• > = <=> <= maggiore uguale, minore o uguale, maggiore di, minore di

Espressione di confronto

Le espressioni di confronto vengono utilizzate quando l'utente desidera eseguire una serie di istruzioni quando la condizione data è soddisfatta. Le espressioni di confronto includono test di uguaglianza utilizzando l'espressione ==.

if $environment == 'development' { 
   include openssl 
} else { 
   include ssl 
}

Esempio non uguale

if $environment != 'development' { 
   $otherenvironment = 'testing' } else { $otherenvironment = 'production' 
}

Espressione aritmetica

$one = 1 $one_thirty = 1.30 
$two = 2.034e-2 $result = ((( $two + 2) / $one_thirty) + 4 * 5.45) - 
   (6 << ($two + 4)) + (0×800 + -9)

Espressione booleana

Le espressioni booleane sono possibili utilizzando or, and, & not.

$one = 1 
$two = 2 $var = ( $one < $two ) and ( $one + 1 == $two )

Espressione regolare

Puppet supporta la corrispondenza delle espressioni regolari utilizzando = ~ (corrispondenza) e! ~ (Non corrispondenza).

if $website =~ /^www(\d+)\./ { notice('Welcome web server #$1') 
}

Come caso e selettore, la corrispondenza delle espressioni regolari crea una variabile di ambito limitato per ogni espressione regolare.

exec { "Test": 
   command => "/bin/echo now we don’t have openssl installed on machine > /tmp/test.txt", 
   unless => "/bin/which php" 
}

Allo stesso modo, possiamo usare a meno che, a meno che non esegua il comando tutto il tempo, tranne il comando sotto a meno che non esca correttamente.

exec { "Test": 
   command => "/bin/echo now we don’t have openssl installed on machine > /tmp/test.txt", 
   unless => "/bin/which php" 
}

Lavorare con i modelli

I modelli vengono utilizzati quando si desidera avere una struttura predefinita che verrà utilizzata su più moduli in Puppet e quei moduli verranno distribuiti su più macchine. Il primo passaggio per utilizzare il modello è crearne uno che renda il contenuto del modello con i metodi del modello.

file { "/etc/tomcat/sites-available/default.conf": 
   ensure => "present", 
   content => template("tomcat/vhost.erb")  
}

Puppet fa poche ipotesi quando si tratta di file locali al fine di rafforzare l'organizzazione e la modularità. Puppet cerca il template vhost.erb all'interno della cartella apache / templates, all'interno della directory dei moduli.

Definizione e attivazione dei servizi

In Puppet, ha una risorsa chiamata servizio che è in grado di gestire il ciclo di vita di tutti i servizi in esecuzione su qualsiasi macchina o ambiente particolare. Le risorse del servizio vengono utilizzate per assicurarsi che i servizi siano inizializzati e abilitati. Sono utilizzati anche per il riavvio del servizio.

Ad esempio, nel precedente modello di tomcat che abbiamo dove abbiamo impostato l'host virtuale di apache. Se si desidera assicurarsi che apache venga riavviato dopo una modifica dell'host virtuale, è necessario creare una risorsa di servizio per il servizio apache utilizzando il seguente comando.

service { 'tomcat': 
   ensure => running, 
   enable => true 
}

Quando si definiscono le risorse, è necessario includere l'opzione di notifica per attivare il riavvio.

file { "/etc/tomcat/sites-available/default.conf": 
   ensure => "present", 
   content => template("vhost.erb"), 
   notify => Service['tomcat']  
}

In Puppet, tutti i programmi scritti utilizzando il linguaggio di programmazione Ruby e salvati con un'estensione .pp sono chiamati manifests. In termini generali, tutti i programmi Puppet costruiti con l'intenzione di creare o gestire qualsiasi macchina host di destinazione sono chiamati manifest. Tutti i programmi scritti in Puppet seguono lo stile di codifica Puppet.

Il fulcro di Puppet è il modo in cui le risorse vengono dichiarate e come queste rappresentano il loro stato. In qualsiasi manifest, l'utente può avere una raccolta di diversi tipi di risorse che vengono raggruppate insieme utilizzando la classe e la definizione.

In alcuni casi, il file manifest Puppet può anche avere un'istruzione condizionale per ottenere uno stato desiderato. Tuttavia, alla fine tutto si riduce a garantire che tutte le risorse siano definite e utilizzate nel modo giusto e che il manifest definito quando applicato dopo essere stato convertito in un catalogo sia in grado di eseguire l'attività per cui è stato progettato.

Flusso di lavoro del file manifest

Il manifesto delle marionette è costituito dai seguenti componenti:

• Files (questi sono file semplici in cui Puppet non ha nulla a che fare con loro, solo per raccoglierli e posizionarli nella posizione di destinazione)

• Resources

• Templates (questi possono essere usati per costruire file di configurazione sul nodo).

• Nodes (tutta la definizione relativa a un nodo client è definita qui)

• Classes

Punti da notare

• In Puppet, tutti i file manifest utilizzano Ruby come linguaggio di codifica e vengono salvati con .pp estensione.

• L'istruzione "Import" in molti manifest viene utilizzata per caricare i file all'avvio di Puppet.

• Per importare tutti i file contenuti in una directory, puoi usare l'istruzione import in un altro modo come import 'clients / *'. Questo importerà tutto.pp file all'interno di quella directory.

Manifesti di scrittura

Lavorare con le variabili

Durante la scrittura di un manifest, l'utente può definire una nuova variabile o utilizzare una variabile esistente in qualsiasi punto di un manifest. Puppet supporta diversi tipi di variabili, ma poche di esse vengono utilizzate frequentemente come stringhe e array di stringhe. Oltre a questi, sono supportati anche altri formati.

Esempio di variabile stringa

$package = "vim" package { $package: 
   ensure => "installed" 
}

Utilizzo dei loop

I cicli vengono utilizzati quando si desidera eseguire più iterazioni su uno stesso insieme di codice fino a quando non viene soddisfatta una condizione definita. Sono anche utilizzati per eseguire attività ripetitive con diversi set di valori. Creazione di 10 attività per 10 cose diverse. È possibile creare una singola attività e utilizzare un ciclo per ripetere l'attività con diversi pacchetti che si desidera installare.

Più comunemente un array viene utilizzato per ripetere un test con valori diversi.

$packages = ['vim', 'git', 'curl'] package { $packages: 
   ensure => "installed" 
}

Utilizzo di condizionali

Puppet supporta la maggior parte della struttura condizionale che può essere trovata nei linguaggi di programmazione tradizionali. La condizione può essere utilizzata per definire dinamicamente se eseguire una particolare attività o se deve essere eseguito un set di codice. Come if / else e case statement. Inoltre, condizioni come execute supporteranno anche attributi che funzionano come condition, ma accettano solo l'output di un comando come condizione.

if $OperatingSystem != 'Linux' { 
   warning('This manifest is not supported on this other OS apart from linux.') 
} else { 
   notify { 'the OS is Linux. We are good to go!': }
}

In Puppet, un modulo può essere definito come una raccolta di risorse, classi, file, definizioni e modelli. Puppet supporta una facile ridistribuzione dei moduli, il che è molto utile nella modularità del codice in quanto è possibile scrivere un modulo generico specificato e utilizzarlo più volte con pochissime semplici modifiche al codice. Ad esempio, questo abiliterà la configurazione del sito predefinita in / etc / puppet, con i moduli forniti da Puppet in / etc / share / puppet.

Configurazione del modulo

In ogni modulo Puppet, abbiamo due partizioni che aiutano a definire la struttura del codice e controllare le denominazioni.

• Il percorso di ricerca dei moduli viene configurato utilizzando un elenco di directory separato da due punti nel file puppetmasterd o masterd, la sezione successiva del file di configurazione principale di Puppet con l'estensione modulepath parametro.

[puppetmasterd] 
... 
modulepath = /var/lib/puppet/modules:/data/puppet/modules

Il percorso di ricerca può essere aggiunto in fase di esecuzione impostando la variabile d'ambiente PUPPETLAB che deve essere anche un elenco di variabili separato da due punti.

• Impostazioni di controllo dell'accesso per i moduli del file server in fileserver.conf, la configurazione del percorso per quel modulo viene sempre ignorata e la specifica di un percorso produrrà un avviso.

Origine moduli

Puppet supporta una posizione diversa per la memorizzazione dei moduli. Qualsiasi modulo può essere memorizzato in un file system diverso di una macchina particolare. Tuttavia, tutti i percorsi in cui vengono memorizzati i moduli devono essere specificati nella variabile di configurazione nota comemodulepath che è in generale, una variabile di percorso in cui Puppet esegue la scansione di tutte le directory dei moduli e le carica all'avvio.

Un percorso predefinito ragionevole può essere configurato come:

/etc/puppet/modules:/usr/share/puppet:/var/lib/modules.

In alternativa, la directory / etc / puppet potrebbe essere stabilita come uno speciale modulo anonimo, che viene sempre cercato per primo.

Denominazione del modulo

Puppet segue gli stessi standard di denominazione di un particolare modulo in cui il nome del modulo deve essere parole normali, corrispondenti a [- \\ w +] (lettera, parola, numero, trattino basso e trattini) e non contenere il separatore dello spazio dei nomi:: o /. Anche se potrebbe essere consentito per quanto riguarda le gerarchie dei moduli, per i nuovi moduli non può essere annidato.

Organizzazione interna del modulo

Quando l'utente crea un nuovo modulo in Puppet, segue la stessa struttura e contiene manifest, file distribuiti, plug-in e modelli disposti in una struttura di directory specifica come mostrato nel codice seguente.

MODULE_PATH/ 
   downcased_module_name/ 
      files/ 
      manifests/ 
         init.pp 
      lib/ 
         puppet/ 
            parser/ 
               functions 
            provider/ 
            type/ 
         facter/ 
      templates/ 
      README

Ogni volta che viene creato un modulo, contiene init.ppmanifest nella posizione della correzione specificata all'interno della directory manifesti. Questo file manifest è un file predefinito che viene eseguito per primo in un particolare modulo e contiene una raccolta di tutte le classi associate a quel particolare modulo. Aggiuntivo.ppil file può essere aggiunto direttamente nella cartella manifesti. Se stiamo aggiungendo file .pp aggiuntivi, dovrebbero essere denominati dopo la classe.

Una delle caratteristiche chiave ottenute utilizzando i moduli è la condivisione del codice. Un modulo per natura dovrebbe essere autonomo, il che significa che uno dovrebbe essere in grado di includere qualsiasi modulo da qualsiasi luogo e rilasciarlo sul percorso del modulo, che viene caricato all'avvio di Puppet. Con l'aiuto dei moduli, si ottiene la modularità nella codifica dell'infrastruttura Puppet.

Esempio

Considera un modulo autofs che installa una mappa auto.homes fissa e genera auto.master da modelli.

class autofs { 
   package { autofs: ensure => latest } 
   service { autofs: ensure => running } 
   
   file { "/etc/auto.homes": 
      source => "puppet://$servername/modules/autofs/auto.homes" 
   } 
   file { "/etc/auto.master": 
      content => template("autofs/auto.master.erb") 
   } 
}

Il file system avrà i seguenti file.

MODULE_PATH/ 
autofs/ 
manifests/ 
init.pp 
files/ 
auto.homes 
templates/ 
auto.master.erb

Ricerca del modulo

Puppet segue una struttura predefinita in cui contiene più directory e sottodirectory in una struttura definita. Queste directory contengono diversi tipi di file richiesti da un modulo per eseguire determinate azioni. Un po 'di magia dietro le quinte assicura che il file giusto sia associato al contesto giusto. Tutte le ricerche sui moduli sono all'interno di modulepath, un elenco di directory separato da due punti.

Per i riferimenti ai file sul file server, viene utilizzato un riferimento simile in modo che un riferimento a puppet: //$servername/modules/autofs/auto.homes si risolva nel file autofs / files / auto.homes nel percorso del modulo.

Per rendere un modulo utilizzabile sia con il client della riga di comando che con un burattinaio, è possibile utilizzare un URL del percorso from puppet: ///. cioè un URL senza un nome di server esplicito. Tale URL viene trattato in modo leggermente diverso daPuppet e puppetd. Puppet cerca URL senza server nel file system locale.

I file modello vengono cercati in un modo simile a manifest e file: una menzione di modello ("autofs / auto.master.erb") farà sì che il burattinaio cerchi un file in $templatedir/autofs/auto.master.erb e poi autofs/templates/auto.master.erbsul percorso del modulo. Con le versioni Puppet di tutto sotto il Puppet, è disponibile per l'uso. Questo si chiama caricamento automatico del modulo. Puppet tenterà di caricare automaticamente classi e definizioni dal modulo.

Puppet segue il concetto di client e server in cui una macchina in una configurazione funziona come macchina server su cui è in esecuzione il software del server Puppet e la restante funziona come client con il software dell'agente Puppet in esecuzione su di essa. Questa funzione del file server aiuta a copiare i file su più macchine. Questa caratteristica della funzione di file serving in Puppet fa parte del demone centrale di Puppet. Puppetmasterd e la funzione client svolgono un ruolo chiave nell'acquisizione degli attributi di file come oggetto file.

class { 'java':  
   package               => 'jdk-8u25-linux-x64',  
   java_alternative      => 'jdk1.8.0_25',  
   java_alternative_path => '/usr/java/jdk1.8.0_25/jre/bin/java'  
}

Come nel frammento di codice sopra, le funzioni di file serving di Puppet astraggono la topologia del filesystem locale supportando il modulo del servizio file. Specificheremo il modulo di file serving nel modo seguente.

“puppet://server/modules/module_name/sudoers”

Formato del file

Nella struttura della directory Puppet, per impostazione predefinita la configurazione del file server si trova in /etc/puppet/fileserver.config directory, se l'utente desidera modificare il percorso del file di configurazione predefinito, può essere fatto utilizzando il nuovo flag di configurazione in puppetmasterd. Il file di configurazione assomiglia ai file INI ma non è esattamente lo stesso.

[module] 
path /path/to/files 
allow *.domain.com 
deny *.wireless.domain.com

Come mostrato nello snippet di codice sopra, tutte e tre le opzioni sono rappresentate nel file di configurazione. Il nome del modulo va in qualche modo tra parentesi. Il percorso è l'unica opzione richiesta. L'opzione di sicurezza predefinita è negare tutti gli accessi, quindi se non viene specificata alcuna linea di autorizzazione, il modulo che verrà configurato sarà disponibile per chiunque.

Il percorso può contenere uno o tutti i% d,% he% H che vengono sostituiti dinamicamente dal nome di dominio, dal nome host e dal nome host completo. Tutti sono presi dal certificato SSL del client (quindi fai attenzione se uno ha una mancata corrispondenza nel nome host e nel nome del certificato). Questo è utile per creare moduli in cui i file di ogni client sono tenuti completamente separati. Esempio, per chiavi host private.

[private] 
path /data/private/%h 
allow *

Nello snippet di codice sopra, il codice sta cercando di cercare il file /private/file.txt dal client client1.vipin.com. Lo cercherà in /data/private/client1/file.txt, mentre la stessa richiesta per client2.vipin.com proverà a recuperare il file /data/private/client2/file.txt sul file server.

Sicurezza

Puppet supporta i due concetti di base della protezione dei file sul file server Puppet. Ciò si ottiene consentendo l'accesso a file specifici e negando l'accesso a quelli che non sono necessari. Per impostazione predefinita, Puppet non consente l'accesso a nessuno dei file. Deve essere definito in modo esplicito. Il formato che può essere utilizzato nei file per consentire o negare l'accesso è utilizzando l'indirizzo IP, il nome o il consenso globale.

Se il client non è connesso direttamente al file server Puppet, ad esempio utilizzando un proxy inverso e Mongrel, il file server vedrà tutte le connessioni come provenienti dal server proxy e non dal client Puppet. Nei casi precedenti, limitare il nome host sulla base del nome host è la migliore pratica.

Un punto chiave da notare durante la definizione della struttura del file è che tutte le istruzioni deny vengono analizzate prima dell'istruzione allow. Quindi, se un'istruzione di negazione corrisponde a un host, tale host verrà negato e se non viene scritta alcuna istruzione di autorizzazione nei file in arrivo, l'host verrà negato. Questa funzione aiuta a impostare la priorità di un particolare sito.

Nome host

In qualsiasi configurazione del file server, il nome host del file può essere specificato in due modi, utilizzando un nome host completo o specificando un intero nome di dominio utilizzando il carattere jolly * come mostrato nell'esempio seguente.

[export] 
path /usr 
allow brcleprod001.brcl.com 
allow *.brcl.com 
deny brcleprod002.brcl.com

Indirizzo IP

In qualsiasi configurazione del file server, l'indirizzo del file può essere specificato come simile ai nomi host, utilizzando l'indirizzo IP completo o l'indirizzo jolly. Si può anche usare la notazione di sistema CIDR.

[export] 
path /usr 
allow 127.0.0.1 
allow 172.223.30.* 
allow 172.223.30.0/24

Consenti globali

Il consenso globale viene utilizzato quando l'utente desidera che tutti possano accedere a un particolare modulo. Per fare ciò, un singolo carattere jolly aiuta a consentire a tutti di accedere al modulo.

[export] 
path /export 
allow *

Puppet supporta la conservazione di più valori come una variabile di ambiente. Questa funzione è supportata in Puppet utilizzandofacter. In Puppet, facter è uno strumento autonomo che contiene la variabile a livello di ambiente. In può essere considerato simile alla variabile env di Bash o Linux. A volte può esserci una sovrapposizione tra le informazioni memorizzate nei fatti e la variabile d'ambiente della macchina. In Puppet, la coppia chiave-valore è nota come "fatto". Ogni risorsa ha i suoi fatti e in Puppet l'utente ha la leva per costruire i propri fatti personalizzati.

# facter

Facter commandpuò essere utilizzato per elencare tutte le diverse variabili di ambiente e i valori associati. Questa raccolta di fatti viene fornita con facter out-of-the-box e sono indicati come fatti fondamentali. Si possono aggiungere fatti personalizzati alla raccolta.

Se si desidera visualizzare solo una variabile. Può essere fatto usando il seguente comando.

# facter {Variable Name}  

Example 
[root@puppetmaster ~]# facter virtual 
virtualbox

Il motivo per cui facter è importante per Puppet è che facter e fatti sono disponibili in tutto il codice Puppet come “global variable”, il che significa che può essere utilizzato nel codice in qualsiasi momento senza altri riferimenti.

Esempio da testare

[root@puppetmaster modules]# tree brcle_account 
brcle_account 
└── manifests  └── init.pp [root@puppetmaster modules]# cat brcle_account/manifests/init.pp  
class brcle_account {  
   user { 'G01063908': 
      ensure => 'present', 
      uid => '121', 
      shell => '/bin/bash', 
      home => '/home/G01063908', 
   }  
   
   file {'/tmp/userfile.txt': 
      ensure => file, 
      content => "the value for the 'OperatingSystem' fact is: $OperatingSystem \n", 
   } 
}

Testarlo

[root@puppetmaster modules]# puppet agent --test 
Notice: /Stage[main]/Activemq::Service/Service[activemq]/ensure: 
ensure changed 'stopped' to 'running' 
Info: /Stage[main]/Activemq::Service/Service[activemq]: 
Unscheduling refresh on Service[activemq] 

Notice: Finished catalog run in 4.09 seconds  
[root@puppetmaster modules]# cat /tmp/testfile.txt  
the value for the 'OperatingSystem' fact is: Linux   

[root@puppetmaster modules]# facter OperatingSystem 
Linux

Come possiamo notare nello snippet di codice sopra, non abbiamo definito il file OperatingSystem. Abbiamo appena sostituito il valore con un valore soft coded$OperatingSystem come variabile normale.

In Puppet, ci sono tre tipi di fatti che possono essere usati e definiti:

• Fatti fondamentali
• Fatti personalizzati
• Fatti esterni

I fatti principali sono definiti al livello più alto e accessibili a tutti in qualsiasi punto del codice.

Fatti delle marionette

Poco prima che un agente richieda un catalogo al master, l'agente compila un elenco completo di informazioni disponibili in sé sotto forma di una coppia chiave-valore. Le informazioni sull'agente vengono raccolte da uno strumento chiamato facter e ogni coppia chiave-valore viene definita un fatto. Di seguito è riportato un output comune di fatti su un agente.

[root@puppetagent1 ~]# facter
architecture => x86_64 
augeasversion => 1.0.0 
bios_release_date => 13/09/2012 
bios_vendor => innotek GmbH 
bios_version => VirtualBox 
blockdevice_sda_model => VBOX HARDDISK 
blockdevice_sda_size => 22020587520 
blockdevice_sda_vendor => ATA 
blockdevice_sr0_model => CD-ROM 
blockdevice_sr0_size => 1073741312 
blockdevice_sr0_vendor => VBOX 
blockdevices => sda,sr0 
boardmanufacturer => Oracle Corporation 
boardproductname => VirtualBox 
boardserialnumber => 0 

domain => codingbee.dyndns.org  
facterversion => 2.1.0 
filesystems => ext4,iso9660 
fqdn => puppetagent1.codingbee.dyndns.org 
hardwareisa => x86_64 
hardwaremodel => x86_64 
hostname => puppetagent1 
id => root 
interfaces => eth0,lo 
ipaddress => 172.228.24.01 
ipaddress_eth0 => 172.228.24.01 
ipaddress_lo => 127.0.0.1 
is_virtual => true 
kernel => Linux 
kernelmajversion => 2.6 
kernelrelease => 2.6.32-431.23.3.el6.x86_64 
kernelversion => 2.6.32 
lsbdistcodename => Final 
lsbdistdescription => CentOS release 6.5 (Final) 
lsbdistid => CentOS 
lsbdistrelease => 6.5 
lsbmajdistrelease => 6 
lsbrelease => :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0noarch:graphics-4.0-amd64:
graphics-4.0-noarch:printing-4.0-amd64:printing-4.0noarch 
macaddress => 05:00:22:47:H9:77 
macaddress_eth0 => 05:00:22:47:H9:77 
manufacturer => innotek GmbH 
memoryfree => 125.86 GB 
memoryfree_mb => 805.86 
memorysize => 500 GB 
memorysize_mb => 996.14 
mtu_eth0 => 1500 
mtu_lo => 16436 
netmask => 255.255.255.0 
netmask_eth0 => 255.255.255.0  

network_lo => 127.0.0.0 
operatingsystem => CentOS 
operatingsystemmajrelease => 6 
operatingsystemrelease => 6.5 
osfamily => RedHat 
partitions => {"sda1"=>{
"uuid"=>"d74a4fa8-0883-4873-8db0-b09d91e2ee8d", "size" =>"1024000", 
"mount" => "/boot", "filesystem" => "ext4"}, "sda2"=>{"size" => "41981952", 
"filesystem" => "LVM2_member"}
} 
path => /usr/lib64/qt3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin 
physicalprocessorcount => 1 
processor0 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 
processor1 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 
processor2 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 
processorcount => 3 
productname => VirtualBox 
ps => ps -ef 
puppetversion => 3.6.2 
rubysitedir => /usr/lib/ruby/site_ruby/1.8 
rubyversion => 1.8.7
selinux => true 
selinux_config_mode => enforcing 
selinux_config_policy => targeted 
selinux_current_mode => enforcing 
selinux_enforced => true 
selinux_policyversion => 24 
serialnumber => 0 
sshdsakey => AAAAB3NzaC1kc3MAAACBAK5fYwRM3UtOs8zBCtRTjuHLw56p94X/E0UZBZwFR3q7
WH0x5+MNsjfmdCxKvpY/WlIIUcFJzvlfjXm4qDaTYalbzSZJMT266njNbw5WwLJcJ74KdW92ds76pjgm
CsjAh+R9YnyKCEE35GsYjGH7whw0gl/rZVrjvWYKQDOmJA2dAAAAFQCoYABgjpv3EkTWgjLIMnxA0Gfud
QAAAIBM4U6/nerfn6Qvt43FC2iybvwVo8ufixJl5YSEhs92uzsW6jiw68aaZ32q095/gEqYzeF7a2knr
OpASgO9xXqStYKg8ExWQVaVGFTR1NwqhZvz0oRSbrN3h3tHgknoKETRAg/imZQ2P6tppAoQZ8wpuLrXU
CyhgJGZ04Phv8hinAAAAIBN4xaycuK0mdH/YdcgcLiSn8cjgtiETVzDYa+jF 
swapfree => 3.55 GB 
swapfree_mb => 2015.99 
swapsize => 3.55 GB 
swapsize_mb => 2015.99 
timezone => GMT 
type => Other 
uniqueid => a8c0af01 
uptime => 45:012 hours 
uptime_days => 0 
uptime_hours => 6 
uptime_seconds => 21865 
uuid => BD8B9D85-1BFD-4015-A633-BF71D9A6A741 
virtual => virtualbox

Nel codice sopra, possiamo vedere alcuni dei dati sovrapporsi con poche delle informazioni disponibili nella variabile bash "env". Puppet non utilizza direttamente i dati, invece fa uso di dati facter, i dati Facter vengono trattati come variabili globali.

I fatti sono quindi disponibili come variabili di primo livello e il burattinaio può utilizzarli per compilare il catalogo Puppet per l'agente richiedente. I facter vengono chiamati nel manifest come una normale variabile con $ prefisso.

Esempio

if ($OperatingSystem == "Linux") { 
   $message = "This machine OS is of the type $OperatingSystem \n" 
} else { 
   $message = "This machine is unknown \n" } file { "/tmp/machineOperatingSystem.txt": ensure => file, content => "$message" 
}

Il file manifest sopra si preoccupa solo di un singolo file chiamato machineOperatingSystem.txt, dove il contenuto di questo file viene dedotto dal fatto chiamato OperatingSystem.

[root@puppetagent1 /]# facter OperatingSystem 
Linux  

[root@puppetagent1 /]# puppet apply /tmp/ostype.pp 
Notice: Compiled catalog for puppetagent1.codingbee.dyndns.org 
in environment production in 0.07 seconds 
Notice: /Stage[main]/Main/File[/tmp/machineOperatingSystem.txt]/ensure: 
defined content as '{md5}f59dc5797d5402b1122c28c6da54d073' 
Notice: Finished catalog run in 0.04 seconds  

[root@puppetagent1 /]# cat /tmp/machinetype.txt 
This machine OS is of the type Linux

Fatti personalizzati

Tutti i fatti di cui sopra che abbiamo visto sono i fatti centrali della macchina. È possibile aggiungere questi fatti personalizzati al nodo nei seguenti modi:

• Utilizzo di "export FACTER ... Syntax"
• Utilizzando le impostazioni $ LOAD_PATH
• FACTERLIB
• Pluginsync

Utilizzando la sintassi "export FACTER"

È possibile aggiungere manualmente i fatti utilizzando la sintassi di esportazione FACTER_ {nome del fatto}.

Esempio

[root@puppetagent1 facter]# export FACTER_tallest_mountain="Everest" 
[root@puppetagent1 facter]# facter tallest_mountain Everest

Utilizzando le impostazioni $ LOAD_PATH

In Ruby, $LOAD_PATH is equivalent to Bash special parameter. Although it is similar to bash $Variabile PATH, in realtà $ LOAD_PATH non è una variabile d'ambiente, invece è una variabile predefinita.

$ LOAD_PATH ha un sinonimo "$:". Questa variabile è un array per cercare e caricare i valori.

[root@puppetagent1 ~]# ruby -e 'puts $LOAD_PATH'            
# note you have to use single quotes.  
/usr/lib/ruby/site_ruby/1.6 
/usr/lib64/ruby/site_ruby/1.6 
/usr/lib64/ruby/site_ruby/1.6/x86_64-linux 
/usr/lib/ruby/site_ruby 
/usr/lib64/ruby/site_ruby 
/usr/lib64/site_ruby/1.6 
/usr/lib64/site_ruby/1.6/x86_64-linux 
/usr/lib64/site_ruby 
/usr/lib/ruby/1.6 
/usr/lib64/ruby/1.6 
/usr/lib64/ruby/1.6/x86_64-linux

Facciamo un esempio della creazione di un facter di directory e dell'aggiunta di un file .pp file e aggiungervi un contenuto.

[root@puppetagent1 ~]# cd /usr/lib/ruby/site_ruby/ 
[root@puppetagent1 site_ruby]# mkdir facter 
[root@puppetagent1 site_ruby]# cd facter/ 
[root@puppetagent1 facter]# ls 
[root@puppetagent1 facter]# touch newadded_facts.rb

Aggiungi il seguente contenuto al file custom_facts.rb.

[root@puppetagent1 facter]# cat newadded_facts.rb 
Facter.add('tallest_mountain') do 
   setcode "echo Everest" 
end

Facter funziona nel metodo di scansione di tutte le cartelle elencate in $ LOAD_PATH e cerca un regista chiamato facter. Una volta trovata quella particolare cartella, le caricherà ovunque nella struttura delle cartelle. Se trova questa cartella, cerca qualsiasi file Ruby in quella cartella facter e carica tutti i fatti definiti su qualsiasi configurazione particolare nella memoria.

Utilizzando FACTERLIB

In Puppet, FACTERLIB funziona in modo molto simile a $ LOAD_PATH ma con solo una differenza fondamentale che è un parametro di ambiente a livello di sistema operativo piuttosto che una variabile speciale Ruby. Per impostazione predefinita, la variabile di ambiente potrebbe non essere impostata.

[root@puppetagent1 facter]# env | grep "FACTERLIB" 
[root@puppetagent1 facter]#

Per testare FACTERLIB, è necessario eseguire i seguenti passaggi.

Crea una cartella chiamata test_facts nella seguente struttura.

[root@puppetagent1 tmp]# tree /tmp/test_facts/ 
/tmp/some_facts/ 
├── vipin 
│   └── longest_river.rb 
└── testing 
   └── longest_wall.rb

Aggiungere i seguenti contenuti ai file .rb.

[root@puppetagent1 vipin]# cat longest_river.rb 
Facter.add('longest_river') do 
   setcode "echo Nile" 
end 

[root@puppetagent1 testing]# cat longest_wall.rb 
Facter.add('longest_wall') do 
   setcode "echo 'China Wall'" 
end

Usa l'istruzione export.

[root@puppetagent1 /]# export 
FACTERLIB = "/tmp/some_facts/river:/tmp/some_facts/wall" 
[root@puppetagent1 /]# env | grep "FACTERLIB" 
FACTERLIB = /tmp/some_facts/river:/tmp/some_facts/wall

Prova il nuovo facter.

[root@puppetagent1 /]# facter longest_river 
Nile 
[root@puppetagent1 /]# facter longest_wall 
China Wall

Fatti esterni

I fatti esterni sono molto utili quando l'utente desidera applicare alcuni nuovi fatti creati al momento del provisioning. I fatti esterni sono uno dei modi chiave per applicare i metadati a una VM nella sua fase di provisioning (ad esempio utilizzando vSphere, OpenStack, AWS, ecc.)

Tutti i metadati ei relativi dettagli creati possono essere utilizzati da Puppet per determinare quali dettagli dovrebbero essere presenti nel catalogo, che verrà applicato.

Creare un fatto esterno

Sulla macchina dell'agente, dobbiamo creare una directory come indicato di seguito.

$ mkdir -p /etc/facter/facts.d

Crea uno script Shell nella directory con il seguente contenuto.

$ ls -l /etc/facter/facts.d 
total 4 
-rwxrwxrwx. 1 root root 65 Sep 18 13:11 external-factstest.sh 
$ cat /etc/facter/facts.d/external-factstest.sh 
#!/bin/bash 
echo "hostgroup = dev" 
echo "environment = development"

Modifica l'autorizzazione del file di script.

$ chmod u+x /etc/facter/facts.d/external-facts.sh

Una volta fatto, ora possiamo vedere la variabile presente con la coppia chiave / valore.

$ facter hostgroup dev $ facter environment 
development

Si possono scrivere fatti personalizzati in Puppet. Come riferimento, usa il seguente collegamento dal sito Puppet.

https://docs.puppet.com/facter/latest/fact_overview.html#writing-structured-facts

Le risorse sono una delle unità fondamentali fondamentali di Puppet utilizzate per progettare e costruire una particolare infrastruttura o macchina. Sono utilizzati principalmente per modellare e mantenere le configurazioni di sistema. Puppet ha più tipi di risorse, che possono essere utilizzate per definire l'architettura del sistema o l'utente ha la leva per creare e definire una nuova risorsa.

Il blocco di codice Puppet nel file manifest o in qualsiasi altro file è chiamato dichiarazione di risorsa. Il blocco di codice è scritto in un linguaggio chiamato DML (Declarative Modeling Language). Di seguito è riportato un esempio di come appare.

user { 'vipin': 
   ensure => present, 
   uid    => '552', 
   shell  => '/bin/bash', 
   home   => '/home/vipin', 
}

In Puppet, la dichiarazione della risorsa per un particolare tipo di risorsa viene eseguita nel blocco di codice. Nell'esempio seguente, l'utente è composto principalmente da quattro parametri predefiniti.

• Resource Type - Nello snippet di codice sopra, è l'utente.

• Resource Parameter - Nello snippet di codice sopra, è Vipin.

• Attributes - Nello snippet di codice sopra riportato, è secure, uid, shell, home.

• Values - Questi sono i valori che corrispondono a ciascuna proprietà.

Ogni tipo di risorsa ha il proprio modo di definire definizioni e parametri e l'utente ha il privilegio di scegliere il modo in cui desidera che appaia la sua risorsa.

Tipo di risorsa

Ci sono diversi tipi di risorse disponibili in Puppet che hanno il loro modo di funzionalità. Questi tipi di risorse possono essere visualizzati utilizzando il comando "Descrivi" insieme all'opzione "-list".

[root@puppetmaster ~]# puppet describe --list 
These are the types known to puppet: 
augeas          - Apply a change or an array of changes to the  ... 
computer        - Computer object management using DirectorySer ... 
cron            - Installs and manages cron jobs 
exec            - Executes external commands 
file            - Manages files, including their content, owner ... 
filebucket      - A repository for storing and retrieving file  ... 
group           - Manage groups 
host            - Installs and manages host entries 
interface       - This represents a router or switch interface 
k5login         - Manage the ‘.k5login’ file for a user 
macauthorization - Manage the Mac OS X authorization database 
mailalias       - .. no documentation .. 
maillist        - Manage email lists 
mcx             - MCX object management using DirectoryService  ... 
mount           - Manages mounted filesystems, including puttin ... 
nagios_command  - The Nagios type command 
nagios_contact  - The Nagios type contact 
nagios_contactgroup - The Nagios type contactgroup 
nagios_host     - The Nagios type host 
nagios_hostdependency - The Nagios type hostdependency 
nagios_hostescalation - The Nagios type hostescalation 
nagios_hostextinfo - The Nagios type hostextinfo 
nagios_hostgroup - The Nagios type hostgroup 

nagios_service  - The Nagios type service 
nagios_servicedependency - The Nagios type servicedependency 
nagios_serviceescalation - The Nagios type serviceescalation 
nagios_serviceextinfo - The Nagios type serviceextinfo  
nagios_servicegroup - The Nagios type servicegroup 
nagios_timeperiod - The Nagios type timeperiod 
notify          - .. no documentation .. 
package         - Manage packages 
resources       - This is a metatype that can manage other reso ... 
router          - .. no documentation .. 
schedule        - Define schedules for Puppet 
scheduled_task  - Installs and manages Windows Scheduled Tasks 
selboolean      - Manages SELinux booleans on systems with SELi ... 
service         - Manage running services 
ssh_authorized_key - Manages SSH authorized keys 
sshkey          - Installs and manages ssh host keys 
stage           - A resource type for creating new run stages 
tidy            - Remove unwanted files based on specific crite ... 
user            - Manage users 
vlan            - .. no documentation .. 
whit            - Whits are internal artifacts of Puppet's curr ... 
yumrepo         - The client-side description of a yum reposito ... 
zfs             - Manage zfs 
zone            - Manages Solaris zones 
zpool           - Manage zpools

Titolo della risorsa

Nello snippet di codice sopra, abbiamo il titolo della risorsa come vipin che è univoco per ogni risorsa utilizzata nello stesso file del codice. Questo è un titolo univoco per questo tipo di risorsa utente. Non possiamo avere una risorsa con lo stesso nome perché causerà conflitti.

Il comando Risorsa può essere utilizzato per visualizzare l'elenco di tutte le risorse utilizzando il tipo utente.

[root@puppetmaster ~]# puppet resource user 
user { 'abrt': 
   ensure           => 'present', 
   gid              => '173', 
   home             => '/etc/abrt', 
   password         => '!!', 
   password_max_age => '-1', 
   password_min_age => '-1', 
   shell            => '/sbin/nologin', 
   uid              => '173', 
} 

user { 'admin': 
   ensure           => 'present', 
   comment          => 'admin', 
   gid              => '444', 
   groups           => ['sys', 'admin'], 
   home             => '/var/admin', 
   password         => '*', 
   password_max_age => '99999', 
   password_min_age => '0', 
   shell            => '/sbin/nologin', 
   uid              => '55', 
} 

user { 'tomcat': 
   ensure           => 'present', 
   comment          => 'tomcat', 
   gid              => '100', 
   home             => '/var/www', 
   password         => '!!', 
   password_max_age => '-1', 
   password_min_age => '-1', 
   shell            => '/sbin/nologin', 
   uid              => '100', 
}

Elenco delle risorse di un particolare utente

[root@puppetmaster ~]# puppet resource user tomcat 
user { 'apache': 
   ensure           => 'present', 
   comment          => 'tomcat', 
   gid              => '100', 
   home             => '/var/www', 
   password         => '!!', 
   password_max_age => '-1', 
   password_min_age => '-1', 
   shell            => '/sbin/nologin', 
   uid              => '100’, 
}

Attributi e valori

Il corpo principale di ogni risorsa è costituito da una raccolta di coppie attributo-valore. Qui è possibile specificare i valori per la proprietà di una data risorsa. Ogni tipo di risorsa ha il proprio set di attributi che possono essere configurati con le coppie chiave-valore.

Descrivi il sottocomando che può essere utilizzato per ottenere maggiori dettagli su un particolare attributo di risorse. Nell'esempio seguente, abbiamo i dettagli sulla risorsa utente insieme a tutti i suoi attributi configurabili.

[root@puppetmaster ~]# puppet describe user 
user 
==== 
Manage users.  This type is mostly built to manage system users, 
so it is lacking some features useful for managing normal users. 

This resource type uses the prescribed native tools for creating groups 
and generally uses POSIX APIs for retrieving information about them.
It does not directly modify ‘/etc/passwd’ or anything. 

**Autorequires:** If Puppet is managing the user's primary group 
(as provided in the ‘gid’ attribute), 
the user resource will autorequire that group. 
If Puppet is managing any role accounts corresponding to the user's roles, 
the user resource will autorequire those role accounts.  

Parameters 
---------- 
- **allowdupe** 
   Whether to allow duplicate UIDs. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **attribute_membership** 
   Whether specified attribute value pairs should be treated as the 
   **complete list** (‘inclusive’) or the **minimum list** (‘minimum’) of 
   attribute/value pairs for the user. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’.  

- **auths** 
   The auths the user has.  Multiple auths should be 
   specified as an array. 
   Requires features manages_solaris_rbac.  

- **comment** 
   A description of the user.  Generally the user's full name.  

- **ensure** 
   The basic state that the object should be in. 
   Valid values are ‘present’, ‘absent’, ‘role’.  

- **expiry**
   The expiry date for this user. Must be provided in 
   a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19. 
   If you want to make sure the user account does never 
   expire, you can pass the special value ‘absent’. 
   Valid values are ‘absent’. Values can match ‘/^\d{4}-\d{2}-\d{2}$/’. Requires features manages_expiry. - **forcelocal** Forces the mangement of local accounts when accounts are also being managed by some other NSS - **gid** The user's primary group. Can be specified numerically or by name. This attribute is not supported on Windows systems; use the ‘groups’ attribute instead. (On Windows, designating a primary group is only meaningful for domain accounts, which Puppet does not currently manage.) - **groups** The groups to which the user belongs. The primary group should not be listed, and groups should be identified by name rather than by GID. Multiple groups should be specified as an array. - **home** The home directory of the user. The directory must be created separately and is not currently checked for existence. - **ia_load_module** The name of the I&A module to use to manage this user. Requires features manages_aix_lam. - **iterations** This is the number of iterations of a chained computation of the password hash (http://en.wikipedia.org/wiki/PBKDF2). This parameter is used in OS X. This field is required for managing passwords on OS X >= 10.8. Requires features manages_password_salt. - **key_membership** - **managehome** Whether to manage the home directory when managing the user. This will create the home directory when ‘ensure => present’, and delete the home directory when ‘ensure => absent’. Defaults to ‘false’. Valid values are ‘true’, ‘false’, ‘yes’, ‘no’. - **membership** Whether specified groups should be considered the **complete list** (‘inclusive’) or the **minimum list** (‘minimum’) of groups to which the user belongs. Defaults to ‘minimum’. Valid values are ‘inclusive’, ‘minimum’. - **name** The user name. While naming limitations vary by operating system, it is advisable to restrict names to the lowest common denominator, which is a maximum of 8 characters beginning with a letter. Note that Puppet considers user names to be case-sensitive, regardless of the platform's own rules; be sure to always use the same case when referring to a given user. - **password** The user's password, in whatever encrypted format the local system requires. * Most modern Unix-like systems use salted SHA1 password hashes. You can use Puppet's built-in ‘sha1’ function to generate a hash from a password. * Mac OS X 10.5 and 10.6 also use salted SHA1 hashes. Windows API for setting the password hash. [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/ Be sure to enclose any value that includes a dollar sign ($) in single 
   quotes (') to avoid accidental variable interpolation. 
   Requires features manages_passwords.  

- **password_max_age** 
   The maximum number of days a password may be used before it must be changed. 
   Requires features manages_password_age.  

- **password_min_age** 
   The minimum number of days a password must be used before it may be changed. 
   Requires features manages_password_age.  

- **profile_membership** 
   Whether specified roles should be treated as the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles 
   of which the user is a member. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’.  

- **profiles** 
   The profiles the user has.  Multiple profiles should be 
   specified as an array. 
   Requires features manages_solaris_rbac.  

- **project** 
   The name of the project associated with a user. 
   Requires features manages_solaris_rbac.  

- **uid** 
   The user ID; must be specified numerically. If no user ID is 
   specified when creating a new user, then one will be chosen 
   automatically. This will likely result in the same user having 
   different UIDs on different systems, which is not recommended. This is 
   especially noteworthy when managing the same user on both Darwin and 
   other platforms, since Puppet does UID generation on Darwin, but 
   the underlying tools do so on other platforms. 
   On Windows, this property is read-only and will return the user's 
   security identifier (SID).

In Puppet, Resource Abstraction Layer (RAL) può essere considerato come il modello concettualizzato di base su cui funziona l'intera infrastruttura e la configurazione di Puppet. In RAL, ogni alfabeto ha il suo significato significativo che è definito come segue.

Risorsa [R]

Una risorsa può essere considerata come tutte le risorse utilizzate per modellare qualsiasi configurazione in Puppet. Sono fondamentalmente risorse integrate che sono presenti per impostazione predefinita in Puppet. Possono essere considerati come un insieme di risorse appartenenti a un tipo di risorsa predefinito. Sono simili al concetto OOP in qualsiasi altro linguaggio di programmazione in cui l'oggetto è un'istanza di classe. In Puppet, la sua risorsa è un'istanza di un tipo di risorsa.

Astrazione [A]

L'astrazione può essere considerata una caratteristica chiave in cui le risorse sono definite indipendentemente dal sistema operativo di destinazione. In altre parole, durante la scrittura di qualsiasi file manifest l'utente non deve preoccuparsi della macchina di destinazione o del sistema operativo, che è presente su quella particolare macchina. In astrazione, le risorse forniscono informazioni sufficienti su ciò che deve esistere sull'agente Puppet.

Puppet si prenderà cura di tutte le funzionalità o della magia che accade dietro le quinte. Indipendentemente dalle risorse e dal sistema operativo, Puppet si occuperà di implementare la configurazione sulla macchina di destinazione, in cui l'utente non deve preoccuparsi di come si comporta Puppet dietro le quinte.

In astrazione, Puppet separa le risorse dalla sua implementazione. Questa configurazione specifica della piattaforma esiste dai fornitori. Possiamo utilizzare più sottocomandi insieme ai relativi provider.

Strato [L]

È possibile che si definisca un'intera installazione e configurazione della macchina in termini di raccolta di risorse, e può essere visualizzata e gestita tramite l'interfaccia CLI di Puppet.

Esempio per il tipo di risorsa utente

[root@puppetmaster ~]# puppet describe user --providers 
user 
==== 
Manage users.
This type is mostly built to manage systemusers, 
so it is lacking some features useful for managing normalusers. 
This resource type uses the prescribed native tools for 
creating groups and generally uses POSIX APIs for retrieving informationabout them.
It does not directly modify '/etc/passwd' or anything. 

- **comment** 
   A description of the user.  Generally the user's full name.  

- **ensure** 
   The basic state that the object should be in. 
   Valid values are 'present', 'absent', 'role'.  

- **expiry** 
   The expiry date for this user. 
   Must be provided in a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19. 
   If you want to make sure the user account does never expire, 
   you can pass the special value 'absent'. 
   Valid values are 'absent'. 
   Values can match '/^\d{4}-\d{2}-\d{2}$/'. Requires features manages_expiry. - **forcelocal** Forces the management of local accounts when accounts are also being managed by some other NSS Valid values are 'true', 'false', 'yes', 'no'. Requires features libuser. - **gid** The user's primary group. Can be specified numerically or by name. This attribute is not supported on Windows systems; use the ‘groups’ attribute instead. (On Windows, designating a primary group is only meaningful for domain accounts, which Puppet does not currently manage.) - **groups** The groups to which the user belongs. The primary group should not be listed, and groups should be identified by name rather than by GID. Multiple groups should be specified as an array. - **home** The home directory of the user. The directory must be created separately and is not currently checked for existence. - **ia_load_module** The name of the I&A module to use to manage this user. Requires features manages_aix_lam. - **iterations** This is the number of iterations of a chained computation of the password hash (http://en.wikipedia.org/wiki/PBKDF2). This parameter is used in OS X. This field is required for managing passwords on OS X >= 10.8. - **key_membership** Whether specified key/value pairs should be considered the **complete list** ('inclusive') or the **minimum list** ('minimum') of the user's attributes. Defaults to 'minimum'. Valid values are 'inclusive', 'minimum'. - **keys** Specify user attributes in an array of key = value pairs. Requires features manages_solaris_rbac. - **managehome** Whether to manage the home directory when managing the user. This will create the home directory when 'ensure => present', and delete the home directory when ‘ensure => absent’. Defaults to ‘false’. Valid values are ‘true’, ‘false’, ‘yes’, ‘no’. - **membership** Whether specified groups should be considered the **complete list** (‘inclusive’) or the **minimum list** (‘minimum’) of groups to which the user belongs. Defaults to ‘minimum’. Valid values are ‘inclusive’, ‘minimum’. - **name** The user name. While naming limitations vary by operating system, it is advisable to restrict names to the lowest common denominator. - **password** The user's password, in whatever encrypted format the local system requires. * Most modern Unix-like systems use salted SHA1 password hashes. You can use Puppet's built-in ‘sha1’ function to generate a hash from a password. * Mac OS X 10.5 and 10.6 also use salted SHA1 hashes. * Mac OS X 10.7 (Lion) uses salted SHA512 hashes. The Puppet Labs [stdlib][] module contains a ‘str2saltedsha512’ function which can generate password hashes for Lion. * Mac OS X 10.8 and higher use salted SHA512 PBKDF2 hashes. When managing passwords on these systems the salt and iterations properties need to be specified as well as the password. [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/ Be sure to enclose any value that includes a dollar sign ($) in single 
   quotes (') to avoid accidental variable interpolation. 
   Requires features manages_passwords.  

- **password_max_age** 
   The maximum number of days a password may be used before it must be changed. 
Requires features manages_password_age.  

- **password_min_age** 
   The minimum number of days a password must be used before it may be changed. 
Requires features manages_password_age.  

- **profile_membership** 
   Whether specified roles should be treated as the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles 
   of which the user is a member. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’. 

- **profiles** 
   The profiles the user has.  Multiple profiles should be 
   specified as an array. 
Requires features manages_solaris_rbac.  

- **project** 
   The name of the project associated with a user. 
   Requires features manages_solaris_rbac.  

- **purge_ssh_keys** 
   Purge ssh keys authorized for the user 
   if they are not managed via ssh_authorized_keys. 
   When true, looks for keys in .ssh/authorized_keys in the user's home directory. 
   Possible values are true, false, or an array of 
   paths to file to search for authorized keys. 
   If a path starts with ~ or %h, this token is replaced with the user's home directory. 
   Valid values are ‘true’, ‘false’.  

- **role_membership** 
   Whether specified roles should be considered the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles the user has. 
   Defaults to ‘minimum’. 
Valid values are ‘inclusive’, ‘minimum’.  

- **roles** 
   The roles the user has.  Multiple roles should be 
   specified as an array. 
Requires features manages_solaris_rbac.  

- **salt** 
   This is the 32 byte salt used to generate the PBKDF2 password used in 
   OS X. This field is required for managing passwords on OS X >= 10.8. 
   Requires features manages_password_salt. 

- **shell** 
   The user's login shell.  The shell must exist and be 
   executable. 
   This attribute cannot be managed on Windows systems. 
   Requires features manages_shell. 

- **system** 
   Whether the user is a system user, according to the OS's criteria; 
   on most platforms, a UID less than or equal to 500 indicates a system 
   user. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **uid** 
   The user ID; must be specified numerically. If no user ID is 
   specified when creating a new user, then one will be chosen 
   automatically. This will likely result in the same user having 
   different UIDs on different systems, which is not recommended. 
   This is especially noteworthy when managing the same user on both Darwin and 
   other platforms, since Puppet does UID generation on Darwin, but 
   the underlying tools do so on other platforms. 
   On Windows, this property is read-only and will return the user's 
   security identifier (SID).  

Providers 
--------- 

- **aix** 
   User management for AIX. 
   * Required binaries: '/bin/chpasswd', '/usr/bin/chuser', 
   '/usr/bin/mkuser', '/usr/sbin/lsgroup', '/usr/sbin/lsuser', 
   '/usr/sbin/rmuser'. 
   * Default for ‘operatingsystem’ == ‘aix’. 
   * Supported features: ‘manages_aix_lam’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’, 
   ‘manages_shell’. 

- **directoryservice** 
   User management on OS X. 
   * Required binaries: ‘/usr/bin/dscacheutil’, ‘/usr/bin/dscl’, 
   ‘/usr/bin/dsimport’, ‘/usr/bin/plutil’, ‘/usr/bin/uuidgen’. 
   * Default for ‘operatingsystem’ == ‘darwin’. 
   * Supported features: ‘manages_password_salt’, ‘manages_passwords’, 
   ‘manages_shell’.

- **hpuxuseradd** 
   User management for HP-UX. This provider uses the undocumented ‘-F’ 
   switch to HP-UX's special ‘usermod’ binary to work around the fact that 
   its standard ‘usermod’ cannot make changes while the user is logged in. 
   * Required binaries: ‘/usr/sam/lbin/useradd.sam’, 
   ‘/usr/sam/lbin/userdel.sam’, ‘/usr/sam/lbin/usermod.sam’. 
   * Default for ‘operatingsystem’ == ‘hp-ux’. 
   * Supported features: ‘allows_duplicates’, ‘manages_homedir’, 
   ‘manages_passwords’.  

- **ldap** 
   User management via LDAP. 
   This provider requires that you have valid values for all of the 
   LDAP-related settings in ‘puppet.conf’, including ‘ldapbase’.
   You will almost definitely need settings for ‘ldapuser’ and ‘ldappassword’ in order 
   for your clients to write to LDAP. 
* Supported features: ‘manages_passwords’, ‘manages_shell’.  

- **pw** 
   User management via ‘pw’ on FreeBSD and DragonFly BSD. 
   * Required binaries: ‘pw’. 
   * Default for ‘operatingsystem’ == ‘freebsd, dragonfly’. 
   * Supported features: ‘allows_duplicates’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_passwords’, ‘manages_shell’. 

- **user_role_add** 
   User and role management on Solaris, via ‘useradd’ and ‘roleadd’. 
   * Required binaries: ‘passwd’, ‘roleadd’, ‘roledel’, ‘rolemod’, 
   ‘useradd’, ‘userdel’, ‘usermod’. 
   * Default for ‘osfamily’ == ‘solaris’. 
   * Supported features: ‘allows_duplicates’, ‘manages_homedir’, 
   ‘manages_password_age’, ‘manages_passwords’, ‘manages_solaris_rbac’.  

- **useradd** 
   User management via ‘useradd’ and its ilk.  Note that you will need to 
   install Ruby's shadow password library (often known as ‘ruby-libshadow’) 
   if you wish to manage user passwords. 
   * Required binaries: ‘chage’, ‘luseradd’, ‘useradd’, ‘userdel’, ‘usermod’. 
   * Supported features: ‘allows_duplicates’, ‘libuser’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’, 
   ‘manages_shell’, ‘system_users’.  

- **windows_adsi** 
   Local user management for Windows. 
   * Default for 'operatingsystem' == 'windows'. 
   * Supported features: 'manages_homedir', 'manages_passwords'.

Risorsa di prova

In Puppet, testare una risorsa indica direttamente che è necessario prima applicare le risorse che si desidera utilizzare per configurare un nodo di destinazione, in modo che lo stato della macchina cambi di conseguenza.

Per il test applicheremo la risorsa a livello locale. Poiché abbiamo una risorsa predefinita sopra conuser = vipin. Un modo per applicare una risorsa è tramite CLI. Questo può essere fatto riscrivendo la risorsa completa in un singolo comando e quindi passandola a un sottocomando risorsa.

puppet resource user vipin ensure = present uid = '505' 
shell = '/bin/bash' home = '/home/vipin'

Testa la risorsa applicata.

[root@puppetmaster ~]# cat /etc/passwd | grep "vipin" 
vipin:x:505:501::/home/vipin:/bin/bash

L'output sopra mostra che la risorsa è applicata al sistema e abbiamo un nuovo utente creato con il nome di Vipin. È consigliabile testarlo da solo poiché tutti i codici sopra sono testati e funzionano come codici.

Templatingè un metodo per ottenere le cose in un formato standard, che può essere utilizzato in più posizioni. In Puppet, templating e template sono supportati usando erb che fa parte della libreria Ruby standard, che può essere usata su altri progetti oltre a Ruby come nei progetti Ruby on Rails. Come pratica standard, è necessario avere una conoscenza di base di Ruby. La creazione di modelli è molto utile quando l'utente cerca di gestire il contenuto di un file modello. I modelli giocano un ruolo chiave quando le configurazioni non possono essere gestite da un tipo Puppet integrato.

Modelli di valutazione

I modelli vengono valutati utilizzando semplici funzioni.

$value = template ("testtemplate.erb")

Si può specificare il percorso completo di un template oppure si possono estrarre tutti i template nella templatedir di Puppet, che di solito si trova in / var / puppet / templates. È possibile trovare la posizione della directory eseguendo il puppet –-configprint templatedir.

I modelli vengono sempre valutati dal parser, non dal client, il che significa che se si utilizza puppetmasterd, il modello deve essere solo sul server e non è mai necessario scaricarli sul client. Non c'è differenza nel modo in cui il client vede tra l'utilizzo di un modello e la specifica di tutto il contenuto di un file come stringa. Ciò indica chiaramente che le variabili specifiche del cliente vengono apprese per prime da Puppetmasterd durante la fase di avvio del pupazzo.

Utilizzo dei modelli

Di seguito è riportato un esempio di generazione della configurazione Tomcat per i siti di test.

define testingsite($cgidir, $tracdir) { file { "testing-$name": 
   path => "/etc/tomcat/testing/$name.conf", owner => superuser, group => superuser, mode => 644, require => File[tomcatconf], content => template("testsite.erb"), notify => Service[tomcat] } symlink { "testsym-$name": 
      path => "$cgidir/$name.cgi", 
      ensure => "/usr/share/test/cgi-bin/test.cgi" 
   } 
}

Di seguito è riportata la definizione del modello.

<Location "/cgi-bin/ <%= name %>.cgi"> 
   SetEnv TEST_ENV "/export/svn/test/<%= name %>" 
</Location>  

# You need something like this to authenticate users 
<Location "/cgi-bin/<%= name %>.cgi/login"> 
   AuthType Basic 
   AuthName "Test" 
   AuthUserFile /etc/tomcat/auth/svn 
   Require valid-user 
</Location>

Questo spinge ogni file modello in un file separato e quindi basta dire ad Apache di caricare questi file di configurazione.

Include /etc/apache2/trac/[^.#]*

Combinazione di modelli

È possibile combinare facilmente due modelli utilizzando il seguente comando.

template('/path/to/template1','/path/to/template2')

Iterazione nei modelli

Il modello Puppet supporta anche l'iterazione dell'array. Se la variabile a cui si accede è un array, è possibile iterare su di esso.

$values = [val1, val2, otherval]

Possiamo avere modelli come i seguenti.

<% values.each do |val| -%> 
Some stuff with <%= val %> 
<% end -%>

Il comando precedente produrrà il seguente risultato.

Some stuff with val1 
Some stuff with val2 
Some stuff with otherval

Condizioni nei modelli

Il erbla creazione di modelli supporta i condizionali. Il seguente costrutto è un modo semplice e veloce per inserire in modo condizionale un contenuto in un file.

<% if broadcast != "NONE" %> broadcast <%= broadcast %> <% end %>

Modelli e variabili

È possibile utilizzare modelli per inserire variabili oltre a compilare il contenuto del file.

testvariable = template('/var/puppet/template/testvar')

Variabile non definita

Se è necessario verificare se la variabile è definita prima di utilizzarla, il seguente comando funziona.

<% if has_variable?("myvar") then %> 
myvar has <%= myvar %> value 
<% end %>

Variabile fuori ambito

Si può cercare la variabile fuori ambito esplicitamente con la funzione lookupvar.

<%= scope.lookupvar('apache::user') %>

Modello di progetto di esempio

<#Autogenerated by puppet. Do not edit. 
[default] 
#Default priority (lower value means higher priority) 
priority = <%= @priority %> 
#Different types of backup. Will be done in the same order as specified here. 
#Valid options: rdiff-backup, mysql, command 
backups = <% if @backup_rdiff %>rdiff-backup, 
<% end %><% if @backup_mysql %>mysql, 
<% end %><% if @backup_command %>command<% end %> 
<% if @backup_rdiff -%>  

[rdiff-backup]  

<% if @rdiff_global_exclude_file -%> 
   global-exclude-file = <%= @rdiff_global_exclude_file %> 
<% end -%> 
   <% if @rdiff_user -%> 
      user = <%= @rdiff_user %> 
<% end -%> 
<% if @rdiff_path -%> 
   path = <%= @rdiff_path %> 
<% end -%>  

#Optional extra parameters for rdiff-backup  

extra-parameters = <%= @rdiff_extra_parameters %>  

#How long backups are going to be kept 
keep = <%= @rdiff_keep %> 
<% end -%> 
<% if @backup_mysql -%>%= scope.lookupvar('apache::user') %>  

[mysql]  

#ssh user to connect for running the backup 
sshuser =  <%= @mysql_sshuser %>

#ssh private key to be used 
   sshkey = <%= @backup_home %>/<%= @mysql_sshkey %> 
   <% end -%> 
<% if @backup_command -%>  
[command] 

#Run a specific command on the backup server after the backup has finished  

command = <%= @command_to_execute %> 
<% end -%>

Le classi Puppet sono definite come una raccolta di risorse, che vengono raggruppate insieme per ottenere un nodo o una macchina di destinazione in uno stato desiderato. Queste classi sono definite all'interno dei file manifest di Puppet che si trovano all'interno dei moduli di Puppet. Lo scopo principale dell'utilizzo di una classe è ridurre la stessa ripetizione di codice all'interno di qualsiasi file manifest o qualsiasi altro codice Puppet.

Di seguito è riportato un esempio della classe Puppet.

[root@puppetmaster manifests]# cat site.pp  
class f3backup ( 
   $backup_home   = '/backup', 
   $backup_server = 'default', $myname        = $::fqdn, $ensure        = 'directory', 
) { 
   include '::f3backup::common' 
   if ( $myname == '' or $myname == undef ) { 
      fail('myname must not be empty') 
   }  
   @@file { "${backup_home}/f3backup/${myname}": 
      # To support 'absent', though force will be needed 
      ensure => $ensure, owner => 'backup', group => 'backup', mode => '0644', tag => "f3backup-${backup_server}", 
   }
}

Nell'esempio sopra, abbiamo due client in cui l'utente deve esistere. Come si può notare abbiamo ripetuto due volte la stessa risorsa. Un modo per non fare lo stesso compito combinando i due nodi.

[root@puppetmaster manifests]# cat site.pp 
node 'Brcleprod001','Brcleprod002' { 
   user { 'vipin': 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => '/home/homer', 
   } 
}

Unire i nodi in questo modo per eseguire la configurazione non è una buona pratica. Ciò può essere ottenuto semplicemente creando una classe e includendo la classe creata nei nodi che viene mostrato come segue.

class vipin_g01063908 { 
   user { 'g01063908': 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => '/home/g01063908', 
   } 
}  
node 'Brcleprod001' { 
   class {vipin_g01063908:} 
}  
node 'Brcleprod002' { 
   class {vipin_g01063908:} 
}

Il punto da notare è come appare la struttura della classe e come abbiamo aggiunto una nuova risorsa utilizzando la parola chiave class. Ogni sintassi in Puppet ha la sua caratteristica. Quindi, la sintassi che si sceglie dipende dalle condizioni.

Classe parametrizzata

Come nell'esempio precedente, abbiamo visto come creare una classe e includerla in un nodo. Ora ci sono situazioni in cui è necessario avere configurazioni diverse su ogni nodo, ad esempio quando è necessario avere utenti diversi su ogni nodo che utilizzano la stessa classe. Questa funzionalità è fornita in Puppet utilizzando la classe parametrizzata. La configurazione per una nuova classe apparirà come mostrato nell'esempio seguente.

[root@puppetmaster ~]# cat /etc/puppet/manifests/site.pp 
class user_account ($username){ user { $username: 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => "/home/$username", 
   } 
}  
node 'Brcleprod002' { 
   class { user_account: 
      username => "G01063908", 
   } 
} 
node 'Brcleprod002' { 
   class {user_account: 
      username => "G01063909", 
   } 
}

Quando applichiamo il manifesto site.pp sopra ai nodi, l'output per ogni nodo sarà simile al seguente.

Brcleprod001

[root@puppetagent1 ~]# puppet agent --test 
Info: Retrieving pluginfacts 
Info: Retrieving plugin 
Info: Caching catalog for puppetagent1.testing.dyndns.org 
Info: Applying configuration version '1419452655' 

Notice: /Stage[main]/User_account/User[homer]/ensure: created 
Notice: Finished catalog run in 0.15 seconds 
[root@brcleprod001 ~]# cat /etc/passwd | grep "vipin" 
G01063908:x:101:501::/home/G01063909:/bin/bash

Brcleprod002

[root@Brcleprod002 ~]# puppet agent --test 
Info: Retrieving pluginfacts 
Info: Retrieving plugin 
Info: Caching catalog for puppetagent2.testing.dyndns.org 
Info: Applying configuration version '1419452725' 

Notice: /Stage[main]/User_account/User[bart]/ensure: created 
Notice: Finished catalog run in 0.19 seconds 
[root@puppetagent2 ~]# cat /etc/passwd | grep "varsha" 
G01063909:x:101:501::/home/G01063909:/bin/bash

È anche possibile impostare il valore predefinito di un parametro di classe come mostrato nel codice seguente.

[root@puppetmaster ~]# cat /etc/puppet/manifests/site.pp 
class user_account ($username = ‘g01063908'){ 
   user { $username: ensure => present, uid => '101', shell => '/bin/bash', home => "/home/$username", 
   } 
}  
node 'Brcleprod001' { 
   class {user_account:} 
}  
node 'Brcleprod002' { 
   class {user_account: 
      username => "g01063909", 
   } 
}

Puppet supporta funzioni come qualsiasi altro linguaggio di programmazione poiché il linguaggio di sviluppo di base di Puppet è Ruby. Supporta due tipi di funzioni note con il nome distatement e rvalue funzioni.

• Statementsstanno da soli e non hanno alcun tipo di ritorno. Vengono utilizzati per eseguire attività autonome come l'importazione di altri moduli Puppet nel nuovo file manifest.

• Rvalue restituisce valori e può essere utilizzato solo quando l'istruzione richiede un valore, ad esempio un'assegnazione o un'istruzione case.

La chiave dietro l'esecuzione della funzione in Puppet è che viene eseguita solo su Puppet master e non vengono eseguiti sul client o sull'agente Puppet. Pertanto, hanno accesso solo ai comandi e ai dati disponibili sul Puppet master. Esistono diversi tipi di funzioni che sono già presenti e anche l'utente ha il privilegio di creare funzioni personalizzate secondo le proprie esigenze. Di seguito sono elencate poche funzioni integrate.

Funzione file

La funzione file della risorsa file è caricare un modulo in Puppet e restituire l'output desiderato sotto forma di stringa. Gli argomenti che cerca sono, il riferimento <nome modulo> / <file>, che aiuta a caricare il modulo dalla directory dei file del modulo Puppet.

Come script / tesingscript.sh caricherà i file da <nome modulo> /script/files/testingscript.sh. La funzione ha la capacità di leggere e accettare un percorso assoluto, che aiuta a caricare il file da qualsiasi punto del disco.

Includi funzione

In Puppet, la funzione include è molto simile alla funzione include in qualsiasi altro linguaggio di programmazione. Serve per la dichiarazione di una o più classi, che si traduce nel valutare tutte le risorse presenti all'interno di quelle classi e infine aggiungerle ad un catalogo. Il modo in cui funziona è che la funzione include accetta un nome di classe, un elenco di classi o un elenco separato da virgole di nomi di classi.

Una cosa da tenere a mente durante l'utilizzo di un file includeè che può essere utilizzato più volte in una classe ma ha la limitazione di includere una singola classe solo una volta. Se la classe inclusa accetta un parametro, la funzione include cercherà automaticamente i valori utilizzando <nome classe> :: <nome parametro> come chiave di ricerca.

La funzione di inclusione non fa sì che una classe sia contenuta nella classe quando vengono dichiarati, per questo dobbiamo usare una funzione contenuta. Non crea nemmeno una dipendenza nella classe dichiarata e nelle classi che la circondano.

Nella funzione include, è consentito solo il nome completo di una classe, i nomi relativi non sono consentiti.

Funzione definita

In Puppet, la funzione definita aiuta a determinare dove è definita una determinata classe o tipo di risorsa e restituisce un valore booleano o meno. Si può anche usare define per determinare se una risorsa specifica è definita o la variabile definita ha un valore. Il punto chiave da tenere a mente durante l'utilizzo della funzione definita è che questa funzione accetta almeno un argomento stringa, che può essere un nome di classe, un nome di tipo, un riferimento a una risorsa o un riferimento a una variabile nella forma "$ name".

Definire i controlli di funzione per il tipo di funzione sia nativo che definito, inclusi i tipi forniti dai moduli. Tipo e classe vengono abbinati ai loro nomi. La funzione corrisponde alla decelerazione della risorsa utilizzando il riferimento alla risorsa.

Definisci corrispondenze di funzioni

# Matching resource types 
defined("file") 
defined("customtype")  

# Matching defines and classes 
defined("testing") 
defined("testing::java")  

# Matching variables 
defined('$name')  

# Matching declared resources 
defined(File['/tmp/file'])

Come descritto nel capitolo precedente, la funzione fornisce all'utente il privilegio di sviluppare funzioni personalizzate. Puppet può estendere il suo potere di interpretazione utilizzando funzioni personalizzate. La funzione personalizzata aiuta ad aumentare ed estendere la potenza dei moduli Puppet e dei file manifest.

Scrittura di funzioni personalizzate

Ci sono poche cose da tenere a mente prima di scrivere una funzione.

• In Puppet, le funzioni vengono eseguite dai compilatori, il che significa che tutte le funzioni vengono eseguite su Puppet master e non è necessario che abbiano a che fare con nessuno dei client Puppet per lo stesso. Le funzioni possono interagire solo con gli agenti, a condizione che le informazioni siano sotto forma di fatti.

• Il Puppet master cattura le funzioni personalizzate, il che significa che è necessario riavviare il Puppet master, se si apportano alcune modifiche alla funzione Puppet.

• La funzione verrà eseguita sul server, il che significa che qualsiasi file di cui la funzione ha bisogno dovrebbe essere presente sul server e non si può fare nulla se la funzione richiede l'accesso diretto alla macchina client.

• Sono disponibili due tipi completamente diversi di funzioni, una è la funzione Rvalue che restituisce il valore e la funzione di istruzione che non restituisce nulla.

• Il nome del file contenente la funzione dovrebbe essere lo stesso del nome della funzione nel file. In caso contrario, non verrà caricato automaticamente.

Posizione in cui inserire la funzione personalizzata

Tutte le funzioni personalizzate sono implementate come separate .rbfile e sono distribuiti tra i moduli. È necessario inserire funzioni personalizzate in lib / puppet / parser / function. Le funzioni possono essere caricate da.rb file dalle seguenti posizioni.

• $libdir/puppet/parser/functions
• sottodirectory puppet / parser / functions nel tuo $ LOAD_PATH di Ruby

Creazione di una nuova funzione

Nuove funzioni vengono create o definite utilizzando il newfunction metodo all'interno di puppet::parser::Functionsmodulo. È necessario passare il nome della funzione come simbolo anewfunctionmetodo e il codice da eseguire come blocco. L'esempio seguente è una funzione, che viene utilizzata per scrivere una stringa nel file all'interno della directory / user.

module Puppet::Parser::Functions 
   newfunction(:write_line_to_file) do |args| 
      filename = args[0] 
      str = args[1] 
      File.open(filename, 'a') {|fd| fd.puts str } 
   end 
end

Una volta che l'utente ha la funzione dichiarata, può essere utilizzata nel file manifest come mostrato di seguito.

write_line_to_file('/user/vipin.txt, "Hello vipin!")

Nello sviluppo del software e nel modello di consegna, esistono diversi tipi di ambienti di test che vengono utilizzati per testare un particolare prodotto o servizio. Come pratica standard, ci sono principalmente tre tipi di ambienti come sviluppo, test e produzione, in cui ognuno di essi ha la propria configurazione.

Puppet supporta la gestione di più ambienti sulla stessa linea di Ruby on Rails. Il fattore chiave alla base della creazione di questi ambienti è fornire un meccanismo semplice per la gestione a diversi livelli di accordo SLA. In alcuni casi, la macchina deve essere sempre attiva senza alcuna tolleranza e senza l'utilizzo di vecchi software. In cui altri ambienti sono aggiornati e vengono utilizzati a scopo di test. Sono utilizzati per aggiornamenti per macchine più importanti.

Puppet consiglia di attenersi alla configurazione standard dell'ambiente di produzione, test e sviluppo, tuttavia, qui fornisce anche all'utente la possibilità di creare ambienti personalizzati secondo i requisiti.

Obiettivo ambientale

L'obiettivo principale della configurazione suddivisa in un ambiente è che Puppet possa avere sorgenti differenti per moduli e manifesti. È quindi possibile testare le modifiche alla configurazione nell'ambiente di test senza influire sui nodi di produzione. Questi ambienti possono essere utilizzati anche per distribuire l'infrastruttura su diverse fonti di rete.

Utilizzo dell'ambiente su Puppet Master

Lo scopo di un ambiente è testare quale manifest, modulo, template del file deve essere inviato al client. Pertanto, Puppet deve essere configurato per fornire un'origine specifica dell'ambiente per queste informazioni.

Gli ambienti Puppet vengono implementati semplicemente aggiungendo le sezioni pre-ambiente al file puppet.conf del server e scegliendo un'origine di configurazione diversa per ogni ambiente. Queste sezioni pre-ambiente vengono quindi utilizzate di preferenza rispetto alla sezione principale.

[main] 
manifest = /usr/testing/puppet/site.pp 
modulepath = /usr/testing/puppet/modules 
[development] 
manifest = /usr/testing/puppet/development/site.pp 
modulepath = /usr/testing/puppet/development/modules

Nel codice precedente, qualsiasi client nell'ambiente di sviluppo utilizzerà il file manifest site.pp che si trova nella directory /usr/share/puppet/development e Puppet cercherà qualsiasi modulo in /usr/share/puppet/development/modules directory.

L'esecuzione di Puppet con o senza un ambiente imposterà il file site.pp e la directory specificata nei valori manifest e modulepath nella sezione di configurazione principale.

Ci sono solo poche configurazioni che effettivamente ha senso essere configurate prima dell'ambiente, e tutti questi parametri ruotano attorno alla specifica di quali file usare per compilare la configurazione di un client.

Di seguito sono riportati i parametri.

• Modulepath- In Puppet, come modalità standard di base è meglio avere una directory del modulo standard condivisa da tutti gli ambienti e quindi una directory pre-ambiente in cui è possibile memorizzare il modulo personalizzato. Il percorso del modulo è la posizione in cui Puppet cerca tutti i file di configurazione relativi all'ambiente.

• Templatedir- La directory dei modelli è la posizione in cui vengono salvate tutte le versioni dei modelli correlati. Il modulo dovrebbe essere preferito a queste impostazioni, tuttavia consente di avere versioni diverse di un dato modello in ogni ambiente.

• Manifest - Definisce quale configurazione utilizzare come script del punto di ingresso.

Con più moduli, Puppets aiutano a ottenere la modularità per le configurazioni. Si possono usare più ambienti in Puppet che funzionano molto meglio se ci si affida principalmente ai moduli. È più facile migrare le modifiche agli ambienti incapsulando le modifiche nel modulo. Il file server utilizza un percorso del modulo specifico dell'ambiente; se si fa servizio di file dai moduli, invece di directory montate separate, questo ambiente sarà in grado di ottenere file specifici dell'ambiente e infine l'ambiente corrente sarà disponibile anche nella variabile $ environment all'interno del file manifest.

Impostazione dell'ambiente client

Tutte le configurazioni relative alla configurazione dell'ambiente vengono eseguite sul file puppet.conf. Per specificare quale ambiente deve utilizzare il client Puppet, è possibile specificare un valore per la variabile di configurazione dell'ambiente nel file puppet.conf del client.

[puppetd] 
environment = Testing

La definizione di cui sopra nel file di configurazione definisce quale ambiente il file di configurazione è nel nostro caso sta testando.

Si può anche specificarlo sulla riga di comando usando -

#puppetd -–environment = testing

In alternativa, Puppet supporta anche l'uso di valori dinamici nella configurazione dell'ambiente. Piuttosto che definire i valori statici, lo sviluppatore ha la possibilità di creare fatti personalizzati che creano un ambiente client basato su altri attributi del cliente o su un'origine dati esterna. Il modo migliore per farlo è utilizzare uno strumento personalizzato. Questi strumenti sono in grado di specificare l'ambiente di un nodo e generalmente sono molto più bravi a specificare le informazioni sul nodo.

Percorso di ricerca dei burattini

Puppet utilizza un semplice percorso di ricerca per determinare quale configurazione deve essere applicata alla macchina di destinazione. Allo stesso modo, il percorso di ricerca in Puppet è molto utile quando sta cercando di raccogliere valori appropriati che devono essere applicati. Ci sono più posizioni, come elencato di seguito, in cui Puppet cerca i valori che devono essere applicati.

• Valore specificato nella riga di comando
• Valori specificati in una sezione specifica dell'ambiente
• Valori specificati in una sezione specifica dell'eseguibile
• Valori specificati nella sezione principale

I tipi di marionette vengono utilizzati per la gestione della configurazione individuale. Puppet ha diversi tipi come un tipo di servizio, tipo di pacchetto, tipo di fornitore, ecc. In cui ogni tipo ha fornitori. Il provider gestisce la configurazione su diverse piattaforme o strumenti. Ad esempio, il tipo di pacchetto ha aptitude, yum, rpm e provider DGM. Ci sono molti tipi e Puppet copre un buon elemento di gestione della configurazione dello spettro che deve essere gestito.

Puppet usa Ruby come lingua di base. Tutti i tipi e i provider di Puppet presenti sono scritti in linguaggio Ruby. Poiché segue il formato di codifica standard, è possibile crearli semplicemente come mostrato nell'esempio per il repository che gestisce i repository. Qui creeremo repository di tipi e svn e git dei provider. La prima parte del tipo di repo è il tipo stesso. I tipi sono generalmente archiviati in lib / puppet / type. Per questo, creeremo un file chiamatorepo.rb.

$ touch repo.rb

Aggiungi il seguente contenuto nel file.

Puppet::Type.newtype(:repo) do  
@doc = "Manage repos"  
   Ensurable   
   newparam(:source) do 
      desc "The repo source"  
      
      validate do |value| 
         if value =~ /^git/ 
            resource[:provider] = :git 
         else 
            resource[:provider] = :svn 
         end 
      end 
      isnamevar 
   end  

   newparam(:path) do 
      desc "Destination path"  
      validate do |value| 
         unless value =~ /^\/[a-z0-9]+/ 
            raise ArgumentError , "%s is not a valid file path" % value 
         end 
      end 
   end 
end

Nello script precedente, abbiamo creato un blocco "Puppet::Type.newtype(:repo) do", che crea un nuovo tipo con il nome repo. Quindi, abbiamo @doc che aiuta ad aggiungere qualsiasi livello di dettagli si desideri aggiungere. L'istruzione successiva è Ensurable; crea una proprietà di sicurezza di base. Il tipo di Puppet utilizza ensure proprietà per determinare lo stato dell'elemento di configurazione.

Esempio

service { "sshd": 
   ensure => present, 
}

La dichiarazione di sicurezza dice a Puppet di eccetto tre metodi: creare, distruggere ed esistere nel provider. Questi metodi forniscono le seguenti funzionalità:

• Un comando per creare una risorsa
• Un comando per eliminare una risorsa
• Un comando per verificare l'esistenza di una risorsa

Tutto ciò che dobbiamo fare è specificare questi metodi e il loro contenuto. Puppet crea l'infrastruttura di supporto attorno a loro.

Successivamente, definiamo un nuovo parametro chiamato source.

newparam(:source) do 
   desc "The repo source" 
   validate do |value| 
      if value =~ /^git/ 
         resource[:provider] = :git 
      else 
         resource[:provider] = :svn 
      end 
   end 
   isnamevar 
end

La fonte dirà al tipo di repository dove recuperare / clonare / estrarre il repository di origine. In questo, stiamo anche usando un hook chiamato validate. Nella sezione provider, abbiamo definito git e svn che verificano la validità del repository che abbiamo definito.

Infine, nel codice abbiamo definito un ulteriore parametro chiamato path.

newparam(:path) do 
   desc "Destination path" 
   validate do |value| 
      unless value =~ /^\/[a-z0-9]+/ 
         raise ArgumentError , "%s is not a valid file path" % value 
      end

Questo è il tipo di valore che specifica dove inserire il nuovo codice che viene recuperato. Qui, usa di nuovo l'hook validate per creare un blocco che controlla il valore di appropriatezza.

Caso d'uso del provider di Subversion

Cominciamo con il provider di subversion che utilizza il tipo creato sopra.

require 'fileutils' 
Puppet::Type.type(:repo).provide(:svn) do 
   desc "SVN Support"  
   
   commands :svncmd => "svn" 
   commands :svnadmin => "svnadmin"  
   
   def create 
      svncmd "checkout", resource[:name], resource[:path] 
   end  
   
   def destroy 
      FileUtils.rm_rf resource[:path] 
   end  
    
   def exists? 
      File.directory? resource[:path] 
   end 
end

Nel codice sopra, abbiamo definito in anticipo ciò di cui abbiamo bisogno fileutils libreria, richiedono 'fileutils' da cui useremo il metodo.

Successivamente, abbiamo definito il provider come block Puppet :: Type.type (: repo) .provide (: svn) do che dice a Puppet che questo è il provider per il tipo chiamato repo.

Quindi, abbiamo aggiunto descche permette di aggiungere della documentazione al provider. Abbiamo anche definito il comando che questo provider utilizzerà. Nella riga successiva, stiamo controllando le caratteristiche della risorsa come creare, eliminare ed esistere.

Creazione di una risorsa

Una volta fatto tutto quanto sopra, creeremo una risorsa che verrà utilizzata nelle nostre classi e nei file manifest come mostrato nel codice seguente.

repo { "wp": 
   source => "http://g01063908.git.brcl.org/trunk/", 
   path => "/var/www/wp", 
   ensure => present, 
}

Puppet utilizza le API RESTful come canale di comunicazione tra il master di Puppet e gli agenti Puppet. Di seguito è riportato l'URL di base per accedere a questa API RESTful.

https://brcleprod001:8140/{environment}/{resource}/{key} 
https://brcleprod001:8139/{environment}/{resource}/{key}

Sicurezza API REST

Puppet di solito si occupa della sicurezza e della gestione dei certificati SSL. Tuttavia, se si desidera utilizzare l'API RESTful al di fuori del cluster, è necessario gestire il certificato da soli, quando si tenta di connettersi a una macchina. La politica di sicurezza per Puppet può essere configurata tramite il resto del file authconfig.

Test dell'API REST

L'utilità Curl può essere utilizzata come utilità di base per mantenere la connettività API RESTful. Di seguito è riportato un esempio di come possiamo recuperare il catalogo del nodo utilizzando il comando curl API REST.

curl --cert /etc/puppet/ssl/certs/brcleprod001.pem --key 
   /etc/puppet/ssl/private_keys/brcleprod001.pem

Nella seguente serie di comandi stiamo solo impostando il certificato SSL, che sarà diverso a seconda di dove si trova la directory SSL e del nome del nodo utilizzato. Ad esempio, diamo un'occhiata al seguente comando.

curl --insecure -H 'Accept: yaml' 
https://brcleprod002:8140/production/catalog/brcleprod001

Nel comando precedente, inviamo semplicemente un'intestazione che specifica il formato o i formati che vogliamo indietro e un URL RESTful per generare un catalogo di brcleprod001 nell'ambiente di produzione, genererà il seguente output.

--- &id001 !ruby/object:Puppet::Resource::Catalog 
aliases: {} 
applying: false 
classes: [] 
...

Supponiamo un altro esempio, in cui vogliamo recuperare il certificato CA da Puppet master. Non richiede di essere autenticato con il proprio certificato SSL firmato poiché è qualcosa che è richiesto prima di essere autenticato.

curl --insecure -H 'Accept: s' https://brcleprod001:8140/production/certificate/ca  

-----BEGIN CERTIFICATE----- 
MIICHTCCAYagAwIBAgIBATANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDDAxwdXBw

Riferimento API condiviso di Puppet Master e agente

GET /certificate/{ca, other}  

curl -k -H "Accept: s" https://brcelprod001:8140/production/certificate/ca 
curl -k -H "Accept: s" https://brcleprod002:8139/production/certificate/brcleprod002

Riferimento API di Puppet Master

Risorse autenticate (certificato valido e firmato richiesto).

Cataloghi

GET /{environment}/catalog/{node certificate name} 

curl -k -H "Accept: pson" https://brcelprod001:8140/production/catalog/myclient

Elenco di revoche di certificati

GET /certificate_revocation_list/ca 

curl -k -H "Accept: s" https://brcleprod001:8140/production/certificate/ca

Richiesta di certificato

GET /{environment}/certificate_requests/{anything} GET 
/{environment}/certificate_request/{node certificate name}  

curl -k -H "Accept: yaml" https://brcelprod001:8140/production/certificate_requests/all 
curl -k -H "Accept: yaml" https://brcleprod001:8140/production/certificate_request/puppetclient

Rapporti Invia una segnalazione

PUT /{environment}/report/{node certificate name}  
curl -k -X PUT -H "Content-Type: text/yaml" -d "{key:value}" https://brcleprod002:8139/production

Nodo - Fatti riguardanti un nodo specifico

GET /{environment}/node/{node certificate name}  

curl -k -H "Accept: yaml" https://brcleprod002:8140/production/node/puppetclient

Stato: utilizzato per il test

GET /{environment}/status/{anything}  

curl -k -H "Accept: pson" https://brcleprod002:8140/production/certificate_request/puppetclient

Riferimento API dell'agente Puppet

Quando un nuovo agente viene configurato su qualsiasi macchina, per impostazione predefinita l'agente Puppet non ascolta la richiesta HTTP. Deve essere abilitato in Puppet aggiungendo "listen = true" nel file puppet.conf. Ciò consentirà agli agenti Puppet di ascoltare la richiesta HTTP all'avvio dell'agente Puppet.

Fatti

GET /{environment}/facts/{anything}  

curl -k -H "Accept: yaml" https://brcelprod002:8139/production/facts/{anything}

Run - Fa sì che il client si aggiorni come un burattino o un calcio di marionetta.

PUT  /{environment}/run/{node certificate name}  

curl -k -X PUT -H "Content-Type: text/pson" -d "{}" 
https://brcleprod002:8139/production/run/{anything}

Per eseguire il test dal vivo dell'applicazione della configurazione e dei manifesti sul nodo Puppet, utilizzeremo una demo funzionante dal vivo. Questo può essere copiato e incollato direttamente per verificare come funziona la configurazione. Se l'utente desidera utilizzare lo stesso set di codice, deve avere la stessa convenzione di denominazione mostrata negli snippet di codice come segue.

Cominciamo con la creazione di un nuovo modulo.

Creazione di un nuovo modulo

Il primo passo per testare e applicare la configurazione httpd è creare un modulo. Per fare ciò, l'utente deve cambiare la sua directory di lavoro nella directory del modulo Puppet e creare una struttura del modulo di base. La creazione della struttura può essere eseguita manualmente o utilizzando Puppet per creare boilerplate per il modulo.

# cd /etc/puppet/modules 
# puppet module generate Live-module

Note - Il comando di generazione del modulo Puppet richiede che il nome del modulo abbia il formato [nomeutente] - [modulo] per conformarsi alle specifiche di Puppet forge.

Il nuovo modulo contiene alcuni file di base, inclusa una directory manifest. La directory contiene già un manifest denominato init.pp, che è il file manifest principale dei moduli. Questa è una dichiarazione di classe vuota per il modulo.

class live-module { 
}

Il modulo contiene anche una directory di test contenente un manifest chiamato init.pp. Questo manifesto di prova contiene un riferimento alla classe del modulo live all'interno di manifest / init.pp:

include live-module

Puppet utilizzerà questo modulo di test per testare il manifest. Ora siamo pronti per aggiungere la configurazione al modulo.

Installazione di un server HTTP

Il modulo Puppet installerà i pacchetti necessari per eseguire il server http. Ciò richiede una definizione di risorsa che definisca la configurazione dei pacchetti httpd.

Nella directory manifest del modulo, crea un nuovo file manifest chiamato httpd.pp

# touch test-module/manifests/httpd.pp

Questo manifest conterrà tutta la configurazione HTTP per il nostro modulo. A scopo di separazione, manterremo il file httpd.pp separato dal file manifest init.pp

Abbiamo bisogno di mettere il seguente codice nel file manifest httpd.pp.

class test-module::httpd { 
   package { 'httpd': 
      ensure => installed, 
   } 
}

Questo codice definisce una sottoclasse del modulo di test chiamato httpd, quindi definisce una dichiarazione di risorsa del pacchetto per il pacchetto httpd. L'attributo sure => installed controlla se il pacchetto richiesto è installato. Se non è installato, Puppet utilizza l'utilità yum per installarlo. Successivamente, includere questa sottoclasse nel nostro file manifest principale. Dobbiamo modificare il manifest init.pp.

class test-module { 
   include test-module::httpd 
}

Ora è il momento di testare il modulo che potrebbe essere fatto come segue

# puppet apply test-module/tests/init.pp --noop

Il comando di applicazione del pupazzo applica la configurazione presente nel file manifest sul sistema di destinazione. Qui stiamo usando test init.pp che si riferisce a main init.pp. –Noop esegue il dry run della configurazione, che mostra solo l'output ma in realtà non fa nulla.

Di seguito è riportato l'output.

Notice: Compiled catalog for puppet.example.com in environment 
production in 0.59 seconds 

Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 1 
events 

Notice: Stage[main]: Would have triggered 'refresh' from 1 events 
Notice: Finished catalog run in 0.67 seconds

La linea di evidenziazione è il risultato dell'attributo garantire => installed. Current_value assente significa che Puppet ha rilevato che il pacchetto httpd è installato. Senza l'opzione –noop, Puppet installerà il pacchetto httpd.

Esecuzione del server httpd

Dopo aver installato i server httpd, è necessario avviare il servizio utilizzando un'altra decelerazione delle risorse: Service

Dobbiamo modificare il file manifest httpd.pp e modificare il seguente contenuto.

class test-module::httpd { 
   package { 'httpd': 
      ensure => installed, 
   } 
   service { 'httpd': 
      ensure => running, 
      enable => true, 
      require => Package["httpd"], 
   } 
}

Di seguito è riportato l'elenco degli obiettivi che abbiamo raggiunto dal codice precedente.

• Il ensure => lo stato di esecuzione controlla se il servizio è in esecuzione, in caso contrario lo abilita.

• Il enable => L'attributo true imposta il servizio in modo che venga eseguito all'avvio del sistema.

• Il require => Package["httpd"]l'attributo definisce una relazione di ordinamento tra una decelerazione della risorsa e l'altra. Nel caso precedente, garantisce che il servizio httpd venga avviato dopo l'installazione del pacchetto http. Questo crea una dipendenza tra il servizio e il rispettivo pacchetto.

Esegui il comando Applica pupazzo per provare nuovamente le modifiche.

# puppet apply test-module/tests/init.pp --noop 
Notice: Compiled catalog for puppet.example.com in environment 
production in 0.56 seconds 

Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 2 
events 

Notice: Stage[main]: Would have triggered 'refresh' from 1 events 
Notice: Finished catalog run in 0.41 seconds

Configurazione del server httpd

Una volta completati i passaggi precedenti, avremo il server HTTP installato e abilitato. Il passaggio successivo consiste nel fornire alcune configurazioni al server. Per impostazione predefinita, httpd fornisce alcune configurazioni predefinite in /etc/httpd/conf/httpd.conf che fornisce una porta 80 dell'host web. Aggiungeremo qualche host aggiuntivo per fornire alcune funzionalità specifiche dell'utente all'host web.

Verrà utilizzato un modello per fornire una porta aggiuntiva poiché richiede un input variabile. Creeremo una directory chiamata template e aggiungeremo un file chiamato test-server.config.erb nel nuovo director e aggiungeremo il seguente contenuto.

Listen <%= @httpd_port %> 
NameVirtualHost *:<% = @httpd_port %> 

<VirtualHost *:<% = @httpd_port %>> 
   DocumentRoot /var/www/testserver/ 
   ServerName <% = @fqdn %> 
   
   <Directory "/var/www/testserver/"> 
      Options All Indexes FollowSymLinks 
      Order allow,deny 
      Allow from all 
   </Directory> 
</VirtualHost>

Il modello sopra segue il formato di configurazione del server apache-tomcat standard. L'unica differenza è l'uso del carattere di escape di Ruby per iniettare variabili dal modulo. Abbiamo FQDN che memorizza il nome di dominio completo del sistema. Questo è noto comesystem fact.

I dati del sistema vengono raccolti da ogni sistema prima di generare il catalogo dei pupazzi di ciascun sistema. Puppet utilizza il comando facter per ottenere queste informazioni e uno può utilizzare facter per ottenere altri dettagli relativi al sistema. Dobbiamo aggiungere le linee di evidenziazione nel file manifest httpd.pp.

class test-module::httpd { 
   package { 'httpd': 
      ensure => installed, 
   } 
   service { 'httpd': 
      ensure => running, 
      enable => true, 
      require => Package["httpd"], 
   } 
   file {'/etc/httpd/conf.d/testserver.conf': 
      notify => Service["httpd"], 
      ensure => file, 
      require => Package["httpd"], 
      content => template("test-module/testserver.conf.erb"), 
   } 
   file { "/var/www/myserver": 
      ensure => "directory", 
   } 
}

Questo aiuta a ottenere le seguenti cose:

• Questo aggiunge una dichiarazione di risorsa file per il file di configurazione del server (/etc/httpd/conf.d/test-server.conf). Il contenuto di questo file è il modello test-serverconf.erb creato in precedenza. Controlliamo anche il pacchetto httpd installato prima di aggiungere questo file.

• Questo aggiunge la seconda dichiarazione di risorsa file che crea una directory (/ var / www / test-server) per il server web.

• Successivamente, aggiungiamo la relazione tra il file di configurazione e il servizio https utilizzando l'estensione notify => Service["httpd"]attribute. Questo controlla se ci sono modifiche al file di configurazione. Se è presente, Puppet riavvia il servizio.

Il prossimo è includere httpd_port nel file manifest principale. Per questo, dobbiamo terminare il file manifest init.pp principale e includere il seguente contenuto.

class test-module ( 
   $http_port = 80 
) { 
   include test-module::httpd 
}

Questo imposta la porta httpd al valore predefinito di 80. Successivamente è eseguire il comando Puppet apply.

Di seguito sarà l'output.

# puppet apply test-module/tests/init.pp --noop 
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera 
defaults 

Notice: Compiled catalog for puppet.example.com in environment 
production in 0.84 seconds 

Notice: /Stage[main]/test-module::Httpd/File[/var/www/myserver]/ensure: 
current_value absent, should be directory (noop) 

Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: 
/Stage[main]/test-module::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensure: 
current_value absent, should be file (noop) 

Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 4 
events 

Notice: Stage[main]: Would have triggered 'refresh' from 1 events 
Notice: Finished catalog run in 0.51 seconds

Configurazione del firewall

Per poter comunicare con il server è necessaria una porta aperta. Il problema qui è che diversi tipi di sistemi operativi utilizzano metodi diversi per controllare il firewall. In caso di Linux, le versioni precedenti alla 6 usano iptables e la versione 7 usa firewalld.

Questa decisione di utilizzare un servizio appropriato è in qualche modo gestita da Puppet utilizzando i fatti di sistema e la sua logica. Per questo, dobbiamo prima controllare il sistema operativo e quindi eseguire il comando firewall appropriato.

Per ottenere ciò, dobbiamo aggiungere il seguente frammento di codice all'interno della classe testmodule :: http.

if $operatingsystemmajrelease <= 6 { 
   exec { 'iptables': 
      command => "iptables -I INPUT 1 -p tcp -m multiport --ports 
      ${httpd_port} -m comment --comment 'Custom HTTP Web Host' -j ACCEPT && iptables-save > /etc/sysconfig/iptables", path => "/sbin", refreshonly => true, subscribe => Package['httpd'], } service { 'iptables': ensure => running, enable => true, hasrestart => true, subscribe => Exec['iptables'], } } elsif $operatingsystemmajrelease == 7 { 
   exec { 'firewall-cmd': 
      command => "firewall-cmd --zone=public --addport = $ { 
      httpd_port}/tcp --permanent", 
      path => "/usr/bin/", 
      refreshonly => true, 
      subscribe => Package['httpd'], 
   } 
   service { 'firewalld': 
      ensure => running, 
      enable => true, 
      hasrestart => true, 
      subscribe => Exec['firewall-cmd'], 
   } 
}

Il codice sopra esegue quanto segue:

• Usando il operatingsystemmajrelease determina se il sistema operativo utilizzato è la versione 6 o 7.

• Se la versione è 6, esegue tutti i comandi di configurazione richiesti per configurare la versione di Linux 6.

• Se la versione del sistema operativo è 7, esegue tutti i comandi richiesti per configurare il firewall.

• Lo snippet di codice per entrambi i sistemi operativi contiene una logica che garantisce che la configurazione venga eseguita solo dopo l'installazione del pacchetto http.

Infine, esegui il comando Puppet applica.

# puppet apply test-module/tests/init.pp --noop 
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera 
defaults 

Notice: Compiled catalog for puppet.example.com in environment 
production in 0.82 seconds 

Notice: /Stage[main]/test-module::Httpd/Exec[iptables]/returns: 
current_value notrun, should be 0 (noop) 

Notice: /Stage[main]/test-module::Httpd/Service[iptables]: Would have 
triggered 'refresh' from 1 events

Configurazione di SELinux

Dato che stiamo lavorando su una macchina Linux che è la versione 7 e successive, quindi dobbiamo configurarla per effettuare una comunicazione http. SELinux limita l'accesso non standard al server HTTP per impostazione predefinita. Se definiamo una porta personalizzata, dobbiamo configurare SELinux per fornire l'accesso a quella porta.

Puppet contiene alcuni tipi di risorse per gestire le funzioni di SELinux, come booleani e moduli. Qui, dobbiamo eseguire il comando semanage per gestire le impostazioni della porta. Questo strumento fa parte del pacchetto policycoreutils-python, che per impostazione predefinita non è installato sui server Red-Hat. Per ottenere quanto sopra, dobbiamo aggiungere il seguente codice all'interno della classe test-module :: http.

exec { 'semanage-port': 
   command => "semanage port -a -t http_port_t -p tcp ${httpd_port}", 
   path => "/usr/sbin", 
   require => Package['policycoreutils-python'], 
   before => Service ['httpd'], 
   subscribe => Package['httpd'], 
   refreshonly => true, 
} 

package { 'policycoreutils-python': 
   ensure => installed, 
}

Il codice sopra esegue quanto segue:

• Require => Package ['policycoreutils-python'] assicura che sia installato il modulo python richiesto.

• Puppet usa semanage per aprire la porta usando httpd_port come verificabile.

• Il servizio before => assicura di eseguire questo comando prima dell'avvio del servizio httpd. Se HTTPD si avvia prima del comando SELinux, SELinux la richiesta di servizio e la richiesta di servizio falliscono.

Infine, esegui il comando Puppet applica

# puppet apply test-module/tests/init.pp --noop 
... 
Notice: /Stage[main]/test-module::Httpd/Package[policycoreutilspython]/ 
ensure: current_value absent, should be present (noop) 
...
Notice: /Stage[main]/test-module::Httpd/Exec[semanage-port]/returns: 
current_value notrun, should be 0 (noop) 
... 
Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop)

Puppet installa prima il modulo python, quindi configura l'accesso alla porta e infine avvia il servizio httpd.

Copia di file HTML nell'host Web

Con i passaggi precedenti abbiamo completato la configurazione del server http. Ora abbiamo una piattaforma pronta per installare un'applicazione basata sul web, che Puppet può anche configurare. Per testare, copieremo alcune pagine web di indice html di esempio sul server.

Crea un file index.html nella directory dei file.

<html> 
   <head> 
      <title>Congratulations</title> 
   <head> 
   
   <body> 
      <h1>Congratulations</h1> 
      <p>Your puppet module has correctly applied your configuration.</p> 
   </body> 
</html>

Crea un'app.pp manifest all'interno della directory manifest e aggiungi il seguente contenuto.

class test-module::app { 
   file { "/var/www/test-server/index.html": 
      ensure => file, 
      mode => 755, 
      owner => root, 
      group => root, 
      source => "puppet:///modules/test-module/index.html", 
      require => Class["test-module::httpd"], 
   } 
}

Questa nuova classe contiene una sola decelerazione della risorsa. Questo copia un file dalla directory dei file del modulo al server web e ne imposta i permessi. L'attributo richiesto garantisce che la classe test-module :: http completi con successo la configurazione prima di applicare test-module :: app.

Infine, dobbiamo includere un nuovo manifest nel nostro manifest init.pp principale.

class test-module ( 
   $http_port = 80 
) { 
   include test-module::httpd 
   include test-module::app 
}

Ora, esegui il comando apply per testare effettivamente cosa sta succedendo. Di seguito sarà l'output.

# puppet apply test-module/tests/init.pp --noop
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera 
defaults 

Notice: Compiled catalog for brcelprod001.brcle.com in environment 
production in 0.66 seconds 

Notice: /Stage[main]/Test-module::Httpd/Exec[iptables]/returns: 
current_value notrun, should be 0 (noop) 

Notice: /Stage[main]/Test-module::Httpd/Package[policycoreutilspython]/ 
ensure: current_value absent, should be present (noop) 

Notice: /Stage[main]/Test-module::Httpd/Service[iptables]: Would have 
triggered 'refresh' from 1 events 

Notice: /Stage[main]/Test-module::Httpd/File[/var/www/myserver]/ensure: 
current_value absent, should be directory (noop) 

Notice: /Stage[main]/Test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: 
/Stage[main]/Test-module::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensur 
e: current_value absent, should be file (noop) 

Notice: /Stage[main]/Test-module::Httpd/Exec[semanage-port]/returns: 
current_value notrun, should be 0 (noop) 

Notice: /Stage[main]/Test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 8 
Notice: 
/Stage[main]/test-module::App/File[/var/www/myserver/index.html]/ensur: 
current_value absent, should be file (noop) 

Notice: Class[test-module::App]: Would have triggered 'refresh' from 1 
Notice: Stage[main]: Would have triggered 'refresh' from 2 events Notice: 
Finished catalog run in 0.74 seconds

La riga evidenziata mostra il risultato della copia del file index.html nell'host web.

Finalizzazione del modulo

Con tutti i passaggi precedenti, il nostro nuovo modulo che abbiamo creato è pronto per l'uso. Se vogliamo creare un archivio del modulo, può essere fatto utilizzando il seguente comando.

# puppet module build test-module