Puppet - Projet en direct

Afin d'effectuer les tests en direct de l'application de la configuration et des manifestes sur le nœud Puppet, nous utiliserons une démo de travail en direct. Cela peut être directement copié et collé pour tester le fonctionnement de la configuration. Si l'utilisateur souhaite utiliser le même ensemble de code, il doit avoir la même convention de dénomination que celle indiquée dans les extraits de code comme suit.

Commençons par la création d'un nouveau module.

Créer un nouveau module

La première étape du test et de l'application de la configuration httpd consiste à créer un module. Pour ce faire, l'utilisateur doit changer son répertoire de travail en répertoire de module Puppet et créer une structure de module de base. La création de la structure peut être effectuée manuellement ou en utilisant Puppet pour créer un passe-partout pour le module.

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

Note - La commande de génération du module Puppet nécessite que le nom du module prenne le format [nom d'utilisateur] - [module] pour se conformer aux spécifications de Puppet forge.

Le nouveau module contient quelques fichiers de base, y compris un répertoire manifeste. Le répertoire contient déjà un manifeste nommé init.pp, qui est le fichier manifeste principal des modules. Il s'agit d'une déclaration de classe vide pour le module.

class live-module { 
}

Le module contient également un répertoire de test contenant un manifeste appelé init.pp. Ce manifeste de test contient une référence à la classe live-module dans manifest / init.pp:

include live-module

Puppet utilisera ce module de test pour tester le manifeste. Nous sommes maintenant prêts à ajouter la configuration au module.

Installer un serveur HTTP

Le module Puppet installera les packages nécessaires pour exécuter le serveur http. Cela nécessite une définition de ressource qui définit la configuration des packages httpd.

Dans le répertoire manifest du module, créez un nouveau fichier manifeste appelé httpd.pp

# touch test-module/manifests/httpd.pp

Ce manifeste contiendra toute la configuration HTTP de notre module. À des fins de séparation, nous garderons le fichier httpd.pp séparé du fichier manifeste init.pp

Nous devons mettre le code suivant dans le fichier manifeste httpd.pp.

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

Ce code définit une sous-classe de test-module appelée httpd, puis définit une déclaration de ressource de package pour le package httpd. L'attribut ensure => installed vérifie si le package requis est installé. S'il n'est pas installé, Puppet utilise l'utilitaire yum pour l'installer. Ensuite, il faut inclure cette sous-classe dans notre fichier manifeste principal. Nous devons éditer le manifeste init.pp.

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

Maintenant, c'est le moment de tester le module qui pourrait être fait comme suit

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

La commande puppet apply applique la configuration présente dans le fichier manifeste sur le système cible. Ici, nous utilisons le test init.pp qui fait référence au principal init.pp. –Noop exécute l'exécution à sec de la configuration, qui n'affiche que la sortie mais ne fait rien.

Voici la sortie.

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 ligne en surbrillance est le résultat de l'attribut ensure => installed. La valeur current_value absente signifie que Puppet a détecté que le package httpd est installé. Sans l'option –noop, Puppet installera le package httpd.

Exécution du serveur httpd

Après avoir installé les serveurs httpd, nous devons démarrer le service en utilisant une autre décélération des ressources: Service

Nous devons éditer le fichier manifeste httpd.pp et éditer le contenu suivant.

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

Voici la liste des objectifs que nous avons atteints à partir du code ci-dessus.

le ensure => l'état d'exécution vérifie si le service est en cours d'exécution, sinon il l'active.
le enable => L'attribut true définit le service pour qu'il s'exécute au démarrage du système.
le require => Package["httpd"]L'attribut définit une relation de classement entre une décélération de ressource et une autre. Dans le cas ci-dessus, il garantit que le service httpd démarre après l'installation du package http. Cela crée une dépendance entre le service et le package respectif.

Exécutez la commande d'application de marionnette pour tester à nouveau les modifications.

# 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

Configuration du serveur httpd

Une fois les étapes ci-dessus terminées, nous aurons le serveur HTTP installé et activé. L'étape suivante consiste à fournir une configuration au serveur. Par défaut, httpd fournit des configurations par défaut dans /etc/httpd/conf/httpd.conf qui fournit un port d'hôte Web 80. Nous ajouterons un hôte supplémentaire pour fournir des fonctionnalités spécifiques à l'utilisateur à l'hôte Web.

Un modèle sera utilisé pour fournir un port supplémentaire car il nécessite une entrée variable. Nous allons créer un répertoire appelé template et ajouter un fichier appelé test-server.config.erb dans le nouveau directeur et ajouter le contenu suivant.

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>

Le modèle ci-dessus suit le format de configuration standard du serveur apache-tomcat. La seule différence est l'utilisation du caractère d'échappement Ruby pour injecter des variables à partir du module. Nous avons FQDN qui stocke le nom de domaine complet du système. Ceci est connu comme lesystem fact.

Les faits système sont collectés à partir de chaque système avant de générer le catalogue de marionnettes de chaque système respectif. Puppet utilise la commande facter pour obtenir ces informations et on peut utiliser facter pour obtenir d'autres détails concernant le système. Nous devons ajouter les lignes de surbrillance dans le fichier manifeste 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", 
   } 
}

Cela aide à réaliser les choses suivantes -

Cela ajoute une déclaration de ressource de fichier pour le fichier de configuration du serveur (/etc/httpd/conf.d/test-server.conf). Le contenu de ce fichier est le modèle test-serverconf.erb créé précédemment. Nous vérifions également le package httpd installé avant d'ajouter ce fichier.
Cela ajoute la deuxième déclaration de ressource de fichier qui crée un répertoire (/ var / www / test-server) pour le serveur Web.
Ensuite, nous ajoutons la relation entre le fichier de configuration et le service https à l'aide du notify => Service["httpd"]attribute. Cela vérifie s'il y a des modifications du fichier de configuration. Si tel est le cas, Puppet redémarre le service.

Il faut ensuite inclure httpd_port dans le fichier manifeste principal. Pour cela, nous devons terminer le fichier manifeste principal init.pp et inclure le contenu suivant.

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

Cela définit le port httpd sur la valeur par défaut de 80. Ensuite, exécutez la commande Puppet apply.

Voici la sortie.

# 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

Configurer le pare-feu

Afin de communiquer avec le serveur, il faut un port ouvert. Le problème ici est que différents types de systèmes d'exploitation utilisent différentes méthodes de contrôle du pare-feu. Dans le cas de Linux, les versions inférieures à 6 utilisent iptables et la version 7 utilise firewalld.

Cette décision d'utiliser un service approprié est quelque peu gérée par Puppet en utilisant les faits du système et sa logique. Pour cela, nous devons d'abord vérifier le système d'exploitation, puis exécuter la commande de pare-feu appropriée.

Pour ce faire, nous devons ajouter l'extrait de code suivant dans la 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'], 
   } 
}

Le code ci-dessus effectue les opérations suivantes -

En utilisant le operatingsystemmajrelease détermine si le système d'exploitation utilisé est la version 6 ou 7.
Si la version est 6, alors il exécute toutes les commandes de configuration requises pour configurer la version Linux 6.
Si la version du système d'exploitation est 7, il exécute toutes les commandes requises pour configurer le pare-feu.
L'extrait de code pour les deux systèmes d'exploitation contient une logique qui garantit que la configuration ne s'exécute qu'après l'installation du package http.

Enfin, exécutez la commande Puppet apply.

# 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

Configurer le SELinux

Comme nous travaillons sur une machine Linux de version 7 et supérieure, nous devons donc la configurer pour établir une communication http. SELinux restreint l'accès non standard au serveur HTTP par défaut. Si nous définissons un port personnalisé, nous devons configurer le SELinux pour fournir l'accès à ce port.

Puppet contient un type de ressource pour gérer les fonctions SELinux, telles que les booléens et les modules. Ici, nous devons exécuter la commande semanage pour gérer les paramètres du port. Cet outil fait partie du package policycoreutils-python, qui n'est pas installé par défaut sur les serveurs red-hat. Afin de réaliser ce qui précède, nous devons ajouter le code suivant dans la 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, 
}

Le code ci-dessus effectue les opérations suivantes -

Le package require => ['policycoreutils-python'] garantit que le module python requis est installé.
Puppet utilise semanage pour ouvrir le port en utilisant httpd_port comme vérifiable.
Le service before => assure l'exécution de cette commande avant le démarrage du service httpd. Si HTTPD démarre avant la commande SELinux, alors SELinux la demande de service et la demande de service échouent.

Enfin, exécutez la commande Puppet apply

# 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 installe d'abord le module python, puis configure l'accès au port et démarre enfin le service httpd.

Copie de fichiers HTML dans l'hôte Web

Avec les étapes ci-dessus, nous avons terminé la configuration du serveur http. Maintenant, nous avons une plate-forme prête à installer une application Web, que Puppet peut également configurer. Pour tester, nous allons copier des exemples de pages Web d'index html sur le serveur.

Créez un fichier index.html dans le répertoire des fichiers.

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

Créez un manifeste app.pp dans le répertoire manifest et ajoutez le contenu suivant.

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"], 
   } 
}

Cette nouvelle classe contient une seule décélération de ressource. Cela copie un fichier du répertoire de fichiers du module sur le serveur Web et définit ses autorisations. L'attribut requis garantit que la classe test-module :: http termine la configuration avec succès avant d'appliquer test-module :: app.

Enfin, nous devons inclure un nouveau manifeste dans notre manifeste principal init.pp.

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

Maintenant, exécutez la commande apply pour tester réellement ce qui se passe. Voici la sortie.

# 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 ligne en surbrillance montre le résultat de la copie du fichier index.html sur l'hôte Web.

Finaliser le module

Avec toutes les étapes ci-dessus, notre nouveau module que nous avons créé est prêt à être utilisé. Si nous voulons créer une archive du module, cela peut être fait à l'aide de la commande suivante.

# puppet module build test-module

↰ Previous page Next page ↱