Puppet

Resources

Wikipedia

Open Hub

Puppet est un système de gestion de configuration écrit en Ruby. Il peut être utilisé pour automatiser le déploiement de machines.

Installation

Puppet est fourni par le paquet app-admin/puppet. Actuellement, il n'y a pas de distinction entre client et serveur, et l'installation de base est la même pour les deux.

Currently, there is no distinction between server and client, so the basic installation procedure is the same for both.

USE flags

USE flags for app-admin/puppet A system automation and configuration management software

augeas	Enable augeas support
diff	Enable diff support
doc	Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally
emacs	Add support for GNU Emacs
hiera	Enable hiera support
ldap	Add LDAP support (Lightweight Directory Access Protocol)
rrdtool	Enable rrdtool support
selinux	!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
shadow	Enable shadow support
sqlite	Add support for sqlite - embedded sql database
test	Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
vim-syntax	Pulls in related vim syntax scripts

Data provided by the Gentoo Package Database · Last update: 2024-10-26 15:15 More information about USE flags

Emerge

Commencez par installer Puppet avec la commande emerge:

root #emerge --ask puppet

root #emerge --ask app-admin/puppet

Configuration et mise en place

Puppet est configuré principalement via /etc/puppet/puppet.conf dans un format de style INI. Les commentaires sont indiqués avec un signe (#). Le fichier de configuration est divisé en plusieurs sections, ou blocs :

Puppet is mainly configured through /etc/puppet/puppet.conf in an INI-style format. Comments are marked with a hash sign (#).

The configuration file is separated into several sections, or blocks:

• [main] contient les réglages qui agissent comme valeurs par défaut dans toutes les parties de Puppet, sauf si vous les redéfinissez dans l'une des sections suivantes :
  • [master] est utilisée pour les réglages qui s'appliquent à Puppetmaster (puppet master), ou l'outil CA (puppet cert)
  • [agent] est utilisé pour des réglages qui s'appliquent à l'agent Puppet (puppet agent)

Une explication plus approfondie, et une liste des blocs suivants utilisés est disponible dans la documentation officielle de Puppet.

Configuration du serveur (Puppetmaster)

La configuration par défaut placée par l'ebuild dans puppet.conf peut être utilisée en l'état. Pour Puppet 2.7.3, la partie relative au serveur ressemble à ceci :

FILE /etc/puppet/puppet.confServer-related default configuration

[main]
    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet
  
    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet
  
    # Where SSL certificates are kept.
    # The default value is '$confdir/ssl'.
    ssldir = $vardir/ssl

Configuration du serveur de fichiers

Pour pouvoir envoyer des fichiers aux clients, il faut configurer le serveur de fichiers. Ceci est fait dans /etc/puppet/fileserver.conf. Par défaut, il n'y a pas de fichier à servir.

To be able to send files to the clients, the file server has to be configured. This is done in /etc/puppet/fileserver.conf. By default, there are no files being served.

FILE /etc/puppet/fileserver.confSetting the files share

[files]
    path /var/lib/puppet/files
    allow 192.168.0.0/24

L'extrait de code ci-dessus définit un partage appelé files (souvenez-vous de cet identifiant, car il y sera fait référence par la suite), cherchant des fichiers dans /var/lib/puppet/files et seulement disponible pour des hôtes dont l'adresse IP appartient au réseau 192.168.0.0/24. Vous pouvez utiliser des adresses IP, la notation CIDR et des noms d'hôtes (y compris le caractères passe-partout comme *.domain.invalid) ici. La commande deny peut être utilisée pour refuser explicitement l'accès à certains hôtes ou à certaines plages d'adresses IP.

Démarrer le démon Puppetmaster

Remarque
Il est recommandé que Puppetmaster soit accessible par les clients en utilisant le nom d'hôte puppet. Cependant, le nom peut être redéfini, ce qui bien-sûr oblige à des efforts de configuration.

Remarque
It is recommended that the Puppetmaster is reachable from the clients using the host name puppet. However, the name can be overridden, which of course causes configuration effort.

Important
À ce stade, le nom d'hôte vu des clients devrait être identique à celui de la sortie de la commande hostname -f. Il est possible que vous deviez ajuster /etc/hosts pour parvenir à cela, ou créez un nouveau certificat à la main comme expliqué ci-dessous.

Avec la configuration de base, aussi bien qu'avec une configuration initiale du serveur de fichiers, vous pouvez lancer le démon Puppetmaster à l'aide de sont script d'initialisation :

root #/etc/init.d/puppetmaster start

root #rc-service puppetmaster start

Lors du premier démarrage, Puppet génère un certificat SSL pour l'hôte Puppetmaster et le place dans le répertoire ssldir configuré plus haut.

Il écoute sur le port 8140/TCP. Assurez-vous qu'il n'y a pas de règles du pare-feu qui bloquent l'accès des clients.

Un manifeste simple

Les manifestes, dans la terminologie Puppet, sont des fichiers dans lesquels la configuration du client est spécifiée. La documentation contient un

guide exhaustif  sur le langage à balises des manifestes.

Manifests, in Puppet's terminology, are the files in which the client configuration is specified. The documentation contains a comprehensive guide about the manifest markup language.

Comme exemple simple, créez un fichier message du jour(motd) sur le client. Sur Puppetmaster créez un fichier dans le partage files créé précédemment :

FILE /var/lib/puppet/files/motdMOTD file on the server

Welcome to this Puppet-managed machine!
</pre>

Vous devez alors créer le fichier manifeste principal dans le répertoire manifests. Il est appelé site.pp :

FILE /etc/puppet/manifests/site.ppMain manifest on the server

node default {
  file { '/etc/motd':
    source => 'puppet://puppet/files/motd'
  }
}

La définition du node par default (le nom pour un client) est utilisée au cas où il n'y aurait pas d'instruction node spécifique pour l'hôte. Nous utilisons une ressource file et voulons que le fichier /etc/motd sur nos clients contienne la même chose que le fichier motd dans le partage files sur l'hôte puppet. Si votre puppetmaster n'est accessible qu'en utilisant un autre nom d'hôte, vous devez adapter l'URI source en conséquence.

Configuration du client

Important
Le client doit avoir les mêmes versions majeure et mineure que le Puppetmaster. Utiliser Puppetmaster 2.7.1 avec des clients 2.7.2 est correct,mais utiliser 2.6 pour le serveur et 2.7 pour les clients peut créer des problèmes inattendus à tout moment.

Important
The client must have the same major and minor version as the Puppetmaster. Using a 2.7.1 Puppetmaster with 2.7.2 clients is fine, but using 2.6 for the server and 2.7 for clients can cause unexpected issues at any time.

Remarque
Si votre puppetmaster n'est pas accessible via puppet, définissez server=<votre nom d'hôte> avec le nom de l'hôte réel, dans la section [main] du fichier /etc/puppet/puppet.conf.

Lors de la première exécution de l'agent Puppet, vous devez attendre la signature de votre certificat par le puppetmaster. Pour demander un certificat, et lancer votre première configuration, exécutez :

root@client #puppet agent --test --waitforcert 60

info: Creating a new certificate request for client
info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/client.pem
notice: Did not receive certificate

Avant que le client ne puisse se connecter, vous devez autoriser la requête de certificat sur le serveur. Votre client devrait apparaître dans la liste des nœuds requérant un certificat :

root@server #puppet cert --list

client

root@server #puppet cert --list

client

Maintenant vous effectuez la requête :

root@server #puppet cert --sign client

root@server #puppet cert --sign client

Le client va vérifier toutes les 60 secondes si un certificat a déjà été émis. Après cela, il continue avec la première partie de la configuration :

info: Caching catalog for client
info: Applying configuration version '1317317379'
notice: /Stage[main]//Node[default]/File[/etc/motd]/ensure: defined content as '{md5}30ed97991ad6f591b9995ad749b20b00'
notice: Finished catalog run in 0.05 seconds

info: Caching catalog for client
info: Applying configuration version '1317317379'
notice: /Stage[main]//Node[default]/File[/etc/motd]/ensure: defined content as '{md5}30ed97991ad6f591b9995ad749b20b00'
notice: Finished catalog run in 0.05 seconds

Si vous apercevez ce message, tout s'est bien passé. Vous pouvez désormais vérifier le contenu de votre fichier /etc/motd sur le client :

user@client $cat /etc/motd

Welcome to this Puppet-managed machine!

user@client $cat /etc/motd

Welcome to this Puppet-managed machine!

OpenRC

Vous pouvez maintenant démarrer l'agent puppet en tant que démon et faire en sorte qu'il soit lancé au démarrage :

root@client #/etc/init.d/puppet start

root@client #rc-update add puppet default

root@client #rc-service puppet start

root@client #rc-update add puppet default

systemd

Conversely, when running systemd:

root@client #systemctl start puppet

root@client #systemctl enable puppet

Autres rubriques

Génération manuelle de certificats

Pour générer un certificat à la main, vous pouvez utiliser l'utilitaire puppet cert. Il placera tous les certificats générés dans le répertoire ssldir que vous avez défini dans la configuration de puppet et les signera avec la clé de votre autorité locale de certification Puppet (CA).

To manually generate a certificate, use the puppet cert utility. It will place all generated certificates into the ssldir defined directory as set in the puppet configuration and will sign them with the key of the local Puppet Certificate Authority (CA).

Un cas facile est celui de la génération d'un certificat avec seulement un nom commun.

root #puppet cert --generate host1

root #puppet cert --generate host1

Si vous avez besoin d'avoir de multiples noms d'hôte pour lesquels le certificat est valide, utilisez le paramètre --certdnsnames et séparez les noms d'hôte additionnels par un caractère deux-points (:)

root #puppet cert --generate --certdnsnames puppet:puppet.domain.invalid host1.domain.invalid

root #puppet cert --generate --certdnsnames puppet:puppet.domain.invalid host1.domain.invalid

Cet exemple générera un certificat valide pour les trois noms d'hôte listés.

Refreshing agent certificates

This is the process used to manually refresh agent certificates.

1. (on master)
   root #puppet cert clean ${AGENT_HOSTNAME}
2. (on agent)
   root #rm /etc/puppet/ssl/{certs,certificate_requests}/${AGENT_HOSTNAME}.pem
   • This will cause the Puppet agent to regenerate the CSR with the existing SSL key.
   • The old certificate is no longer valid, as it was nuked on the master.
   • When one of the above steps is forgotten, an error will pop up about the certificate mis-matching between agent and master.
   • To replace the SSL keys (optional):
     root #rm /etc/puppet/ssl/{public,private}_keys/${AGENT_HOSTNAME}.pem
3. (on agent)
   root #puppet agent --onetime --no-daemonize --verbose --test --waitforcert 30
   • When using auto-signing, no further steps are needed.
4. (on master)
   root #puppet cert list ${AGENT_HOSTNAME}
5. Verify that the fingerprint listed in the previous two outputs matches
6. (on master)
   root #puppet cert sign ${AGENT_HOSTNAME}
7. (on agent)
   root #puppet agent --onetime --no-daemonize --verbose --test

Gestion des slots avec puppet

Bien que le fournisseur de portage par défaut dans puppet ne prend pas en charge les slots, il y a des modules puppet qui tentent d'ajouter cette fonctionnalité.

• puppet-portage
• PortageGT

While the default portage provider in puppet does support slots there are puppet modules available which also have this functionality.

For instance, with app-admin/puppet version 4.6.0 and higher, and/or app-admin/puppet-agent, the slot functionality is supported like to:

CODE Defining an absent slotted package

package { 'dev-lang/python:3.3': ensure => absent }

Additional modules are:

• puppet-portage
• PortageGT

Voir aussi

• Puppet module for Gentoo

Ressources externes

• Upstream website
• Puppet Wiki

• Upstream website
• Puppet Wiki