Un environnement de développement Puppet
La semaine passée je vous ai proposé de découvrir les bases de l’écriture de
manifests puppet
. Je vous propose aujourd’hui de
configurer un environnement de développement complet sur votre machine. Cet
environnement est composé d’un serveur et de n nodes. Votre code puppet est
monté directement sur le serveur via un partage NFS. On peut ainsi utiliser son
éditeur de code favori et testé le déploiement sur un ou plusieurs nodes de
tests.
Utilisation de l’environnement de développement puppet
Installation de l’environnement
Il faut au préalable avoir installé Vagrant
mais aussi le plugin hostmanager. Rappel, ce plugin complète les fichiers
/etc/hosts
sur votre machine et sur les VM instanciées, avec les adresses
IP de toutes les VM créés par Vagrant. Très pratique par la suite : on peut se
connecter directement ensuite sur les VM en SSH sans passer par la commande
vagrant login <vm>
.
Pour l’installer :
Autre bénéfice, on peut lancer un playbook ansible directement, à installer
également. D’ailleurs,
c’est comme cela qu’est configuré l’environnement puppet
.
Tout est prêt on clone le projet :
Pour instancier l’environnement, il suffit de lancer, depuis le répertoire où se
trouve le fichier Vagrantfile
, la commande :
Cela va provisionner le master et les n node(s) et configurer la partie SSH pour qu’il accepte les connexions depuis votre machine.
Ensuite pour configurer l’environnement, on lance en local le playbook
init-cluster.yml
. Pour simplifier les choses Vagrant
met à disposition un
provisionner local (local-exec) qui peut être appeler par la commande :
Voilà tout est prêt !
Quand vous terminé vous pouvez détruire l’environnement avec la classique commande vagrant :
Application des manifests sur les nodes
Comme dis plus haut, il suffit de se connecter au noeud en SSH
et de lancer la
commande puppet agent -t
:
Connexion au master puppet
Pour contrôler par exemple que le(s) node(s) sont bien enregistrés sur le master. Comme pour les nodes, on se connecte en SSH, on passe root pour lancer les commandes :
Ecrire et appliquer des manifests
L’utilisation est assez simple : dans le dépôt se trouve un répertoire puppet qui
est monté via un partage NFS sur le master. Dedans, on retrouve, tous les
fichiers du précédent billet, complété par le fichier site.pp
dans lequel on
indique les classes à appliquer sur les noeuds.
Quelques explications sur le Vagrantfile et le playbook
Vagrant
est un outil que j’utilise très souvent pour instancier des
environnements de tests. Cette fois donc je vous propose un Vagrantfile
qui
provisionne un serveur et une ou plusieurs machines clientes. Et comme
ansible
n’a pas besoin d’agent déployé pour fonctionner, c’est lui qui est à
la manœuvre pour installer le serveur Puppet
et configurer les clients.
Résultat, vous avez un environnement de test, prêt à l’emploi : même les nœuds
clients sont déjà enregistrés. J’ai utilisé la dernière version de Puppet
disponible au moment de l’écriture de ce billet. Je vais configurer le dépôt
pour qu’il se mette à jour seul lors des sorties de nouvelles versions de
Puppet
.
Vous pouvez cloner le dépôt source pour l’adapter à votre besoin. Par
exemple pour changer l’image de base des clients. Pour le moment cela ne
fonctionne qu’avec des clients avec des images de base debian
et ses
dérivées. D’ailleurs, je vais l’inclure dans ma liste de todo pour que chaque
client puisse prendre en charge d’autres images de base, comment celle à base de
redhat
.
Le vagrantfile
J’ai déjà pas mal documenté Vagrant et je vous propose ici un
Vagrantfile complet qui se charge de construire l’environnement de développement
en une seule opération. Merci Vagrant
qui fournit un inventaire ansible
dynamique 👍 qui simplifie pas mal l’écriture.
Le code :
Dans la première partie du Vagrantfile, je constitue un tableau de nodes composé
d’un master
et de n clients
. Le nombre de node(s)
est configuré par la
variable number_node = 1
. Dans les paramètres des nodes
on retrouve la
capacité et l’image de base. C’est ici, l’image des clients, si vous voulez
utiliser d’autres images c’est ici qu’il faudra intervenir.
Ensuite vient la partie provisioning
dans lequel je constitue les groupes
d’inventaire ansible: master
et nodes
. Ces groupes sont ensuite utilisés
dans le playbook init-cluster.yml
pour lancer les bonnes actions sur le
serveur et le client.
Le playbook init-cluster
Pour chacun de mes projets, je décide d’écrire plutôt un playbook que d’utiliser des rôles (je les écris ensuite). Voici le code :
Il est décomposé en deux parties :
- La première qui configure le serveur maître puppet
hosts : master
. - La seconde sur les nodes :
hosts: nodes
.
Dans le second stage, celui sur les nodes
j’utilise une tâche asynchrone,
async
et un delegate_to
pour l’enregistrement du certificat du node sur
le master
. Pourquoi ? Tout simplement la commande de l’enregistrement du node
attends qu’en parallèle le master accepte cet enregistrement.