Parce qu'avant d'installer puppet, il faut faire un minimum de chose pour qu'il puisse fonctionner, comme par exemple la configuration réseau pour atteindre le puppet master, ou encore sécuriser un minimum la machine quand elle est à poil sur internet.
J'ai donc des scripts ansible pour "bootstrapper" les nouvelles machines. Ces scripts configurent le minimum vital pour que puppet puisse fonctionner et qu'on puisse se connecter en toute sécurité sur la machine (et tout les trucs bas niveau qui sont trop chiant à faire en puppet) : lancent apt-update/upgrade,, installent les paquets de "survie" (comme vim :), configure les interfaces réseaux (en particulier tout ce qui est lan pour le vrack chez ovh etc), le /etc/hosts, resolv.conf, config du serveur ssh, et au final configurent l'agent puppet.
Les scripts puppet se chargent du reste.
On va me demander pourquoi ne pas faire tout en ansible (surtout que je ne suis pas super fan de puppet) : pour des raisons historique, c'est puppet qui avait été choisi au départ (par rapport à chief et quelques autres) et à l'époque ansible n'existait pas (ou alors n'était pas encore très stable/très connu/très fonctionnel). Et puis un jour j'en ai eu marre de préparer les nouvelles machines à la main pour pouvoir les "puppetiser". Et j'ai donc utilisé ansible puisqu'il a le bon gout de ne pas avoir une archi agent-serveur (idéal donc pour bootstraper une machine vierge), et très simple à utiliser dans sa philosophie (il serait encore plus simple si il utilisait autre chose que cette connerie de syntaxe Yaml).
J'aurais pu tout mettre au final en ansible, mais il y a des obstacles à ça :
ansible est lent
trop de modules puppet à migrer, pas le temps de le faire
le système d'agent de puppet, couplé avec un puppet-dashboard, permet de savoir en permanence que tes machines sont toujours configurée comme prévu, et que tu sais quand il y a des trucs qui sont modifiés à ton insu (ce qui peut arriver si il y a une appli qui fait de la merde). Alors qu'avec Ansible, c'est plus compliqué, même si des solutions existent.
Bref, le couple Ansible (pour le bootstrapping) + puppet me va très bien.
PS: ce que j'aime bien dans ansible, c'est la facilité de créé des plugins. On peut en faire aussi dans puppet, mais j'ai horreur de ruby et ça semble plus complexe.
[^] # Re: Agentless, danger
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 6.
C'est mon cas :-)
Parce qu'avant d'installer puppet, il faut faire un minimum de chose pour qu'il puisse fonctionner, comme par exemple la configuration réseau pour atteindre le puppet master, ou encore sécuriser un minimum la machine quand elle est à poil sur internet.
J'ai donc des scripts ansible pour "bootstrapper" les nouvelles machines. Ces scripts configurent le minimum vital pour que puppet puisse fonctionner et qu'on puisse se connecter en toute sécurité sur la machine (et tout les trucs bas niveau qui sont trop chiant à faire en puppet) : lancent apt-update/upgrade,, installent les paquets de "survie" (comme vim :), configure les interfaces réseaux (en particulier tout ce qui est lan pour le vrack chez ovh etc), le /etc/hosts, resolv.conf, config du serveur ssh, et au final configurent l'agent puppet.
Les scripts puppet se chargent du reste.
On va me demander pourquoi ne pas faire tout en ansible (surtout que je ne suis pas super fan de puppet) : pour des raisons historique, c'est puppet qui avait été choisi au départ (par rapport à chief et quelques autres) et à l'époque ansible n'existait pas (ou alors n'était pas encore très stable/très connu/très fonctionnel). Et puis un jour j'en ai eu marre de préparer les nouvelles machines à la main pour pouvoir les "puppetiser". Et j'ai donc utilisé ansible puisqu'il a le bon gout de ne pas avoir une archi agent-serveur (idéal donc pour bootstraper une machine vierge), et très simple à utiliser dans sa philosophie (il serait encore plus simple si il utilisait autre chose que cette connerie de syntaxe Yaml).
J'aurais pu tout mettre au final en ansible, mais il y a des obstacles à ça :
Bref, le couple Ansible (pour le bootstrapping) + puppet me va très bien.
PS: ce que j'aime bien dans ansible, c'est la facilité de créé des plugins. On peut en faire aussi dans puppet, mais j'ai horreur de ruby et ça semble plus complexe.