Puppet est utilisé pour automatiser plusieurs tâches de configuration de routine de l'administrateur système.
Marionnette dans un système de gestion de configuration de niveau entreprise.
Il vous permet de définir l'état de votre infrastructure informatique. Une fois défini, Puppet appliquera automatiquement l'état correct de manière continue.
1. Architecture de marionnettes
Puppet a généralement un composant serveur et plusieurs agents. Vous devez désigner un serveur sur votre réseau comme maître de marionnettes, et chaque nœud de votre réseau aura un agent de marionnettes installé dessus.
La manière la plus courante d'appliquer la configuration de marionnettes à un client consiste à utiliser le démon maître de marionnettes (puppetmasterd) et le démon client de marionnettes (puppetd). Vous pouvez également appliquer manuellement les manifestes à l'aide de l'outil marionnette.
La configuration est définie sur le maître de la marionnette, compilée puis transmise automatiquement aux clients de la marionnette lorsqu'ils se connectent.
Puppet prend en charge un large éventail de plates-formes et de systèmes d'exploitation différents, et il exécutera automatiquement les commandes appropriées pour appliquer votre manifeste dans chaque environnement.
Un manifeste n'est rien d'autre que des détails sur les fichiers, les packages, les opérations de configuration écrits dans un langage que la marionnette peut comprendre.
Chaque nœud Puppet contacte le puppet master, par défaut toutes les 30 minutes, pour confirmer que sa configuration est à jour. Si la configuration est différente ou si une nouvelle configuration est disponible, elle est recompilée puis appliquée au nœud marionnette.
Dans ce didacticiel, nous expliquerons comment créer des manifestes de base et les appliquer aux clients à l'aide de l'outil de marionnette.
La plupart de la configuration du système peut être visualisée à l'aide de l'outil de ligne de commande puppet. Tous les composants de configuration sont organisés en ressources. Les ressources sont regroupées en collections. Les ressources sont composées du type, du titre et de la série d'attributs.
2. Exemple de fichier de ressources de marionnettes
Voici un exemple de base sur la façon d'afficher une ressource de marionnette. Dans ce cas, la ressource marionnette que nous visualisons est un fichier (/etc/nsswitch).
# puppet resource file /etc/nsswitch.conf
file { '/etc/nsswitch.conf':
ensure => 'file',
content => '{md5}0d6009cdfd12646d251e86303bc0c48c',
ctime => 'Sun May 18 13:20:02 -0400 2014',
group => '0',
mode => '644',
mtime => 'Tue May 04 15:22:21 -0400 2010',
owner => '0',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
type => 'file',
}
Puppet est livré avec un certain nombre de types de ressources par défaut, y compris des types pour gérer les fichiers, les services, les packages, les tâches cron et les systèmes de fichiers, entre autres.
Dans l'exemple ci-dessus, file est le type de ressource et /etc/nsswitch.conf est le titre de la ressource à gérer.
Tout le reste est composé d'attributs du type de ressource et de valeurs présentes sur les attributs. Vous pouvez également étendre la marionnette pour ajouter vos propres types de ressources.
Pour afficher tous les types de ressources disponibles, utilisez la commande suivante :
# puppet resource --types augeas computer cron exec file filebucket group host nagios_hostdepend .. ..
3. Exemple de fichier manifeste de marionnettes
Voyons comment créer un fichier manifeste simple et exécuter la commande puppet pour appliquer la configuration au serveur.
L'exemple suivant crée un fichier manifeste simple site.pp sous le répertoire /etc/puppet/manifests qui créera un fichier de test sous /var/tmp.
Au départ, comme nous le voyons ci-dessous, nous n'avons pas le fichier de test.
# ls -ld /var/tmp/testfile ls: cannot access /var/tmp/testfile: No such file or directory
Voici la déclaration de ressource dans le fichier manifeste (site.pp) :
# cat site.pp
file { "/var/tmp/testfile":
ensure => "present",
owner => "root",
group => "root",
mode => "664",
content => "This is a test file created using puppet.
Puppet is really cool",
}
À des fins de démonstration, nous exécutons le puppet master et l'agent sur le même nœud.
Lorsque vous exécutez la commande puppet apply pour la première fois avec l'option –noop, cela effectuera une simulation sans réellement appliquer la configuration.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.06 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: current_value absent, should be present (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.03 seconds
Ce qui précède vous permet de voir ce que la nouvelle configuration fera sans apporter de modifications au nœud.
Maintenant, exécutez la commande sans l'option –noop pour vraiment appliquer la configuration comme indiqué ci-dessous.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: created Notice: Finished catalog run in 0.05 seconds
Une fois exécuté avec succès, vous verrez que le nouveau fichier temporaire est créé sous /var/tmp/testfile avec le contenu défini dans site.pp.
# ls -ld /var/tmp/testfile -rw-rw-r--. 1 root root 69 Jun 26 14:25 /var/tmp/testfile # cat /var/tmp/testfile This is a test file created using puppet. Puppet is really cool
4. Contrôler un service sur un nœud distant à l'aide de Puppet
Voici un exemple pour faire passer le service de l'état arrêté à l'état en cours d'exécution sur les nœuds d'agent.
Lorsque ce manifeste de configuration est enregistré sur le serveur maître sous un emplacement spécifique sous le répertoire de configuration de la marionnette, l'agent exécuté sur tous les nœuds contacte le nœud maître et récupère la configuration et l'applique sur tous les nœuds clients afin que le service soit démarré. sur tous les nœuds d'agent après l'exécution réussie de la configuration de la marionnette.
# puppet resource service multipathd
service { 'multipathd':
ensure => 'stopped',
enable => 'false',
}
Dans cet exemple, nous allons contrôler le service multipathd. Vous pouvez utiliser la marionnette pour contrôler tous les services en cours d'exécution sur le système. Par exemple, httpd, mysqld, etc.
# puppet resource service multipathd > site.pp
Assurez-vous que le site.pp a les valeurs suivantes. Sinon, modifiez-le en conséquence.
# vi site.pp
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
Effectuez d'abord un essai pour vous assurer que cela fonctionne comme prévu.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/Service[multipathd]/ensure: current_value stopped, should be running (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.06 seconds
Enfin, appliquez le fichier de configuration, qui démarrera le service (dans cet exemple multipathd), s'il n'est pas déjà en cours d'exécution.
# puppet apply site.pp
Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds
Notice: /Stage[main]/Main/Service[multipathd]/ensure: ensure changed 'stopped' to 'running'
Notice: Finished catalog run in 0.28 seconds
# puppet resource service multipathd
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
# chkconfig --list | grep multipath
multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
5. Installer un package sur un nœud distant à l'aide de Puppet
Vous pouvez effectuer l'installation du package sur tous les nœuds d'agent à distance à l'aide de puppet.
Voici un exemple de fichier manifeste pour l'installation du package.
# cat site.pp
package { 'httpd':
ensure => 'present',
}
Dans cet exemple, il installera le package Apache httpd s'il n'est pas présent sur le site distant. Comme vous le voyez ci-dessous, il a installé le package.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.70 seconds Notice: /Stage[main]/Main/Package[httpd]/ensure: created Notice: Finished catalog run in 79.97 seconds
Vérifiez que le package est correctement installé à l'aide de la commande rpm.
# rpm -qa | grep -i httpd httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
6. Deux types de collections de marionnettes
Les ressources peuvent configurer les caractéristiques d'éléments de configuration uniques sur les nœuds. Mais la plupart des services et des applications sont constitués de plusieurs ressources.
Par exemple, un serveur Web se compose du progiciel, des utilisateurs pour exécuter le logiciel et d'une variété de fichiers de configuration, de journalisation et autres.
Les collections de ressources vous permettent de rassembler les ressources, de les affecter à la collection et d'appliquer la collection aux nœuds d'agent.
Il existe 2 types de collection de ressources :
- Cours
- Définitions
7. Exemple de collection de classes de marionnettes
Une classe est une collection de ressources qui représente un élément de configuration unique sur votre nœud, tandis que la définition est une collection d'éléments de configuration qui ont plusieurs représentations sur votre nœud.
Dans l'exemple précédent, après l'installation du package, les services ne sont pas démarrés par défaut. Nous pouvons créer un manifeste simple avec classe pour installer le package et démarrer le service après l'installation.
Dans l'exemple suivant, nous avons spécifié la relation entre deux ressources à l'aide de l'attribut require.
# cat site.pp
class apache {
package { 'httpd':
ensure => 'present',
}
service {'httpd':
ensure => 'running',
require => Package["httpd"],
}
}
include apache
Cela garantit que la condition est remplie avant que les modifications de ressource ne soient appliquées. Dans ce cas, le service httpd nécessite l'installation préalable du package httpd avant de pouvoir tenter d'activer les services.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.93 seconds Notice: /Stage[main]/Apache/Package[httpd]/ensure: created Notice: /Stage[main]/Apache/Service[httpd]/ensure: ensure changed 'stopped' to 'running' Notice: Finished catalog run in 32.82 seconds # chkconfig --list | grep http httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off # rpm -qa | grep -i http httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
8. Exemple de collection de définitions de marionnettes
Une définition est un type de collection de ressources de marionnettes.
Les définitions doivent être utilisées pour les éléments de configuration qui ont plusieurs instances sur un nœud.
Par exemple, le serveur httpd peut avoir plusieurs hôtes virtuels définis. Vous pouvez créer une définition pour configurer des hôtes virtuels et transmettre les arguments appropriés pour configurer chacun. Tant que chaque ensemble d'arguments était différent, la marionnette configurait le nouvel hôte virtuel chaque fois que la définition était évaluée.
Voici un exemple de manifeste simple avec une classe et une définition.
# cat site1.pp
class testdefine {
define testdefine ($data) {
file {"$title":
ensure => file,
content => $data,
}
}
testdefine {'/var/tmp/puppetfile1':
data => "The name of the file is puppetfile1 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile2':
data => "The name of the file is puppetfile2 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile3':
data => "The name of the file is puppetfile3 and it is created by puppet\n",
}
}
include testdefine
Exécutez la classe de marionnettes ci-dessus et le manifeste de définition comme indiqué ci-dessous.
# puppet apply site1.pp
Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.24 seconds
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile2]/File[/var/tmp/puppetfile2]/ensure: defined content as '{md5}9079bd9c7650ae7d503c7df1a68bb9f0'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile3]/File[/var/tmp/puppetfile3]/ensure: defined content as '{md5}75d495f0d3180b1f2dd052ac208d81fe'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile1]/File[/var/tmp/puppetfile1]/ensure: defined content as '{md5}1fa93f1f2b82f8358866d58b2cb2f0b4'
Notice: Finished catalog run in 0.19 seconds
# ls -l /var/tmp/puppetfile*
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile1
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile2
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile3
# cat /var/tmp/puppetfile*
The name of the file is puppetfile1 and it is created by puppet
The name of the file is puppetfile2 and it is created by puppet
The name of the file is puppetfile3 and it is created by puppet
9. Exemple de fichier de configuration de nœud de marionnette
Jusqu'à présent, nous avons vu définir des ressources et des collections de ressources sous forme de classes et de définitions.
L'étape suivante consiste maintenant à attribuer ces ressources et collections aux clients.
Voici un exemple de définition des nœuds dans node.pp.
Puppet utilise ce fichier pour déterminer quelle classe (contient des ressources) doit aller à quel serveur, par exemple, sur le client 1, vous souhaitez exécuter la classe httpd qui contient des ressources telles que le package httpd, le service httpd et sur le client 2, vous souhaitez exécuter la classe ngnix qui contient des ressources telles que le package ngnix, le service ngnix et d'autres fichiers de configuration ngnix.
L'exemple de fichier nodes.pp suivant explique cela :
node 'puppetclient1.mydomain.net' {
include httpd_class
}
node 'puppetclient2.mydomain.net' {
include ngnix_class
}
node default {
package { "perl":
ensure => present }
}
Dans votre définition de nœud, vous pouvez ajouter des ressources, des classes et des définitions.
Les classes sont ajoutées à l'aide de la fonction include.
Dans puppetclient1.mydomain.net, nous avons inclus httpd_class et dans puppetclient2.mydomain.net, nous avons inclus ngnix_class.
Vous pouvez également inclure plusieurs classes avec une seule fonction d'inclusion. Si aucune définition de nœud ne correspond, alors il prend les valeurs par défaut définies. Dans ce cas, s'il y a d'autres nœuds, il installera simplement les packages perl s'ils ne sont pas présents.
10. Importer des fichiers manifestes de marionnettes
Les ressources, les classes et les définitions sont stockées dans des fichiers manifestes.
Un fichier manifeste spécial, appelé manifeste du site, est au cœur de notre configuration.
Lors du démarrage du démon maître Puppet, le fichier manifeste du site, situé par défaut dans /etc/puppet/manifests/site.pp, doit être présent.
Dans les exemples ci-dessus, nous avons utilisé site.pp uniquement pour expliquer comment appliquer les manifestes.
Dans un véritable environnement de marionnettes, votre site.pp n'aura que le contenu ci-dessous et à partir de ce fichier, les autres fichiers sont importés pour exécution.
# cat site.pp import "templates.pp" import "nodes.pp" import "classes/*" import "groups/*" import "users/*" import "os/*"
Voici la structure du répertoire du manifeste de la marionnette :
- /manifests/classes/ – Répertoire contenant toutes les classes
- /manifests/site.pp – le fichier manifeste principal
- /manifests/templates.pp – Contient des nœuds de modèle
- /manifests/nodes.pp – Contient les définitions de nœuds
- /manifests/definitions/ – Contient toutes les définitions
- /manifests/groups/ – Contient des groupes de configuration de manifestes
- /manifests/os/ – Contient des classes conçues pour configurer des nœuds avec des systèmes d'exploitation particuliers
- /manifests/users/ – Contient des manifestes configurant les utilisateurs
- /manifest/files/ – Contient des modules de serveur de fichiers pour les fichiers distribuables Puppet