Puppet - Progetto live

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 testare il funzionamento della 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 [nome utente] - [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 live-module 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 di 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 fa riferimento 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 alcuni host aggiuntivi 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 sono presenti modifiche al file di configurazione. In caso affermativo, 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 la configurazione con successo 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 del file index.html che viene copiato 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

↰ Previous page Next page ↱