Puppet - Modulo

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 denominate.

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 runtime 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 sono 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 per 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 funzionalità 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.

La ricerca nei file modello viene eseguita in modo simile a manifest e file: una menzione di modello ("autofs / auto.master.erb") farà sì che il burattinaio cerchi per prima cosa 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 è chiamato caricamento automatico del modulo. Puppet tenterà di caricare automaticamente classi e definizioni dal modulo.

↰ Previous page Next page ↱