Latest revision as of 17:41, 13 March 2018

Préambule Puppet

Serveur Puppet Master. Puppet est un outil d'automatisation et de gestion centralisée de fichier / services / serveurs en général. Il fonctionne sur le principe des "Facts", c'est à dire qu'un serveur client va interroger le serveur puppet master et lui communiquer son catalogue, contenant diverses informations (système de fichiers, utilisateurs, groupes, packages). le master puppet va ensuite définir quelle politique doit être appliquée selon le catalogue correspondant.

Configuration Puppet Master

La version complète de puppet choisie est la version 4.10 (dernière release 4.x). La migration en v5 n'est à l'heure actuelle pas étudiée car trop récente et n'apporte pas d'améliorations utiles à l'environnement dont on a besoin. https://docs.puppet.com/puppet/4.10/ La version 4.10 de Puppet intègre les éléments suivants :

puppet-agent	Puppet		Facter		Hiera		MCollective	Ruby	OpenSSL
1.10.2		4.10.2		3.6.5		3.3.2		2.10.5		2.1.9	1.0.2k

En cas d'installation sur un nouveau serveur : L'installation s'effectue simplement en installant les packages correspondants : puppetserver ; puppet L'installation met des fichiers dans /etc/puppetlabs et /opt/puppetlabs. Il faut importer le projet git https://gitlab/unix/puppetlabs dans /soft/puppet/ puis fair un lien symbolique du dossier pupeptlabs dans /etc Il faut également importer le projet sysdyn-sudo dans /soft/puppet/puppetlabs/code/modules/sysdynsudo pour récupérer les sudoers actuellement configurés.

le serveur possède l'alias dns puppetmaster.domain.fr et les certificats (client et serveur) sont liés à cet alias. En cas de réinstallation, il faudra demander au réseau de modifier l'alias pour pointer sur le nouveau serveur.

Installation Puppet Client

Nouveaux serveurs

Le packages sysdyn-puppet est intégré à easyinstall ainsi qu'aux installations automatisées par le cloud. En cas d'installation manuelle il faut tout simplement faire un yum install sysdyn-puppet. l'installer récupère le paquet puppet agent puis interroge le master pour obtenir un certificat.

Réinstallation de serveur

En cas de réinstallation de puppet sur un serveur :

Côté serveur

puppet cert clean testdomain.fr
find / -name test.domain.fr.pem -delete

Côté client

yum remove puppet
rm -rf /etc/puppetlabs /opt/puppetlabs
yum install -y sysdyn-puppet

Custom Facts

Dans le cadre du déploiement des sudoers sysdyn, nous avons créé des custom facts pour établir un catalogue plus précis sur les serveurs : Ces facts sont envoyés sur chaque serveur grâce au module sysdynenv présent sur le serveur puppet : /etc/puppetlabs/code/modules/sysdynenv/facts.d/

Les différents sysdynfacts sont :

• sysdyndmz --> Définit si un serveur est en DMZ ou non (pas d'utilité pour le moment)
• sysdynenv --> Définit l'environnement du serveur en fonction de son nom (Administration, Non_Production, Production, Développement, Integr_Recette)
• sysdynservices --> Crée un arrow avec le contenu des services dans /etc/init.d/
• sysdyntri --> Crée un arrow avec les différents trigrammes présents sur la machine dans /projets
• sysdyntype --> définit si la machine est un serveur physique ou une VM (pas d'utilité pour le moment)
• sysdynusers --> Crée un arrow avec les utilisateurs, un arrow avec les groupes ainsi qu'un arrow avec les comptes wls (pour les sudoers pilote)

Modules

Une des forces de puppet réside dans l'organisation et la division de modules. Les différents modules sont gérés directement à partir du gitlab. Il est possible de cloner le projet "puppetlabs" afin de travailler indépendamment sur un autre serveur ou à la maison.

URL du projet : https://gitlab/unix/puppetlabs

Afin d'accéder aux modules, il faut se rendre dans :

code --> modules

Module (en cours d'amélioration) servant à maintenir les fichiers de configuration des clients Icinga.

puppetconf

Gestion de la conf puppet du master et des clients

puppetconfmaster

Déploiement des Modules

La gestion du déploiement des modules se fait à l'aide de Hiera. La configuration se trouve dans code --> hieradata

Le fichier common.yaml désigne l'ensemble des modules qui seront appliqués sur l'intégralité de la plateforme. Si un module est défini dans nodes --> nom_du_serveur.yaml, il sera installé sur ce serveur spécifiquement.

Cela permet de tester l'installation de modules sur des serveurs spécifiques, notamment :

test01 --> Serveur de test RH6
test02 --> Serveur de test RH7

MAJ puppet depuis les sources git

update_puppet.sh :

#!/bin/bash

cd /soft/puppet/puppetlabs/
git submodule update --recursive --remote
git pull --recurse-submodules