Puppet4

Ha, c'est gars de puppetlab ... Ici, on va parler de Puppet 4.

Puppet Server et Agent

Alors, le premier truc à savoir, c'est que la différence est devenue assez mince. Ca devient vite le bordel pour savcoir à qui appartiennent les options. C'est pour ca que je ne recommande pas l'utilisation de la section [main] dans le fichier de conf de puppet. Par ailleurs, si vous avez un agent qui tourne sur votre Puppet Server, il ne faut pas qu'il utilise le meme certificat que le serveur.

Voici une bonne conf de base pour un PuppetServer et son PuppetAgen:
[master]
vardir = /opt/puppetlabs/server/data/puppetserver
logdir = /var/log/puppetlabs/puppetserver
rundir = /var/run/puppetlabs/puppetserver
pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
codedir = /etc/puppetlabs/code
certname = puppet.infra.sflx

log_level = notice
environment = production
#dns_alt_names = puppet.domain.tld
ca_name = Puppet CA: puppet.domain.tld

[agent]
certname = host1.domain.tld
server = puppet.domain.tld
environment = production
runinterval = 1h
Pour avoir la liste des options qui s'appliquent au serveur et à l'agent, et c'est mieux que la doc officielle:
puppet agent --genconfig | less
puppet server --genconfig | less

Puppet Server et Certificats

Pour afficher le certificat d'un client (plus facile que la commande openssl): puppet cert print host3.domain.tld

Hiera

Voici un exemple:
:backends:
  - yaml
:hierarchy:
  - common
  - "nodes/single/%{::trusted.certname}"
  - "nodes/openstack/%{::domain}/%{::hostname}"
  - "nodes/openstack/%{::domain}/_common"
  - "config/openstack/network/network_%{::domain}"
  - "config/openstack/network/vlan_%{::domain}"
  - "config/openstack/config/prj_%{::projet}"
  - "config/openstack/config/user_%{::user}"
  - defaults

Cette hierarchie montre l'organisation de nodes, mais aussi de configurations. Dans l'idée, il vaudrait mieux utiliser les "trusted.facts" plutot que les facts tout court. Mais les "trusted.facts" sont plus diffcile à débugger, car on ne peux pas les utiliser pour intéroger hiera depuis le CLI.

PuppetDB

Bon, y'a un truc a savoir quand la puppetdb est sur le meme serveur que le Puppet Server:
puppetdb ssl-setup

Debug: Hiera

Avec le CLI, pour intérroger la DB:
hiera classes_host -d ::hostname=host3 ::domain=domain.tld environment=production
Pour voir comment Puppet interroge hiera, à partir des manifests:
puppet master --debug --compile host3.domain.tld | grep hiera

Debug: PupperServer et PuppetAgent

Bonnes ressources:

Page last modified on November 09, 2016, at 06:58 AM EST