Hello,
je suis occupé a découvrir puppet et la gestion de serveurs centralisée.
J'aime assez bien l'idée de gestion de la config & co sur un serveur distant, reproductible et testable.
Un des trucs que je voulais pour mon infra ( relativement petite) c'était de faire les mises à jours debian via puppet … pour éviter de me connecter à tt les serveurs lancer la mise à jour & co.
J'ai donc implémenter un truc du genre http://www.memonic.com/user/pneff/folder/55756627-f51c-43f0-adfd-777635574108/id/1Z9999x
Qui est déjà un bon pas en avant…
J'aurais voulu une solution plus générique qui pourrait me lancer genre le puppet en mode noop partout, me retourner les opérations a faire par serveurs et si l'opérateur valide, alors paf c'est partit partout (la cerise serais d'avoir en + le résultat de commandes permettant la décistion par l'operateur : genre quel sont les packages à mettre à jour ? - A , b, c ….- alors ok
Avez vous une idée d'un outil / une technique qui pourrait faire ça?
Merci
# Choisir le bon outil
Posté par napster2core . Évalué à 2.
Hello.
Je pense que le problème est plus au niveau du choix de l'outil que d'autre chose. Puppet est un outil de configuration, pas de mise à jour. Il vaut mieux laisser ce boulot à apt. Par contre puppet va être utilisé pour configurer apt afin qu'il fasse le boulot en question. Pour cela le mieux est d'utiliser 2 ou 3 outils en fonction de ce que tu veux faire. Une première manière (simple) est d'utiliser unattended-upgrade ainsi que les apt-preferences pour bloquer une version d'un paquet (faire un hold n'est vraiment pas la meilleurs solution, c'est vraiment crade sous Debian).
Il y a des modules déjà fait (et très bien testés) pour faire ça. Je te recommande chaudement le module suivant: https://github.com/camptocamp/puppet-apt/ (aussi disponible sur la forge puppetlabs: https://forge.puppetlabs.com/camptocamp/apt)
(parce que je travail dans la boite qui le fait et parce qu'il est vraiment bien foutu, on a pas eu un problème de mise à jour sur des centaines de serveurs avec ce module).
Sinon la solution plus complète consiste à utiliser un miroir apt sur lequel tu consolide les paquets importants en mettant un pin priority via apt-preferences (le tout configuré par puppet bien évidement). C'est ce qu'il y a de plus sûr si tu veux une version précise d'un paquet à tout prix. Après pour une petite infrastructure je ne pense pas que ça soit indispensable.
En espérant t'avoir répondu.
Librement
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: Choisir le bon outil
Posté par napster2core . Évalué à 4.
Petite précision (en relisant la question), pour savoir quel sont les machines qui ont des paquets à mettre à jour, je te recommande mcollective. C'est l'équivalent de puppet mais dans l'autre sens, pour parler avec un pull de machines.
C'est aussi développé par puppetlabs. Je te laisse voir la doc pour plus d'informations:
http://puppetlabs.com/mcollective/introduction/
Librement
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: Choisir le bon outil
Posté par eMerzh (site web personnel) . Évalué à 2.
Merci beaucoup Pour cette réponse :-)
en effet je pense que je devrais pouvoir utiliser Mcollective pour mes mise à jour…
Par contre ma question était plus générale … apt n'était ici qu'un example…
J'aurais voulu avoir un workflow genre
Master # tool test_puppet_changes
* 2 hosts with changes
- h1.mondomaine :
notice: /Stage[main]/Ntp/File[/etc/ntp.conf]/content: is {md5}b86c4f22a676ac492e3de5e5fdd90d68, should be {md5}9a2e8866b70f6eab093e7eabc2491087 (noop)
info: /Stage[main]/Ntp/File[/etc/ntp.conf]: Scheduling refresh of Service[ntp]
- h2.mondmaine :
notice: /Stage[main]/Ntp/File[/etc/ntp.conf]/content: is {md5}b86c4f22a676ac492e3de5e5fdd90d68, should be {md5}9a2e8866b70f6eab093e7eabc2491087 (noop)
info: /Stage[main]/Ntp/File[/etc/ntp.conf]: Scheduling refresh of Service[ntp]
notice: /Stage[main]/Apache/Package[httpd]/ensure: is purged, should be present (noop)
info: /Stage[main]/Apache/Package[httpd]: Scheduling refresh of Service[httpd]
Et là j'aurais alors la possibilité de dire, bon ok je pense que le timing est bon (pas d'update pdt les heures de boulot par example & co).
et je lancerai un truc genre
Master # tool apply_puppet_changes *.mondomaine
* Changes applied to 2 hosts
Histoire de gérer moi même quand il fait une mise à jour et de quoi…
[^] # Re: Choisir le bon outil
Posté par napster2core . Évalué à 2.
Ah, ça c'est un peu le graal de Puppet. Il me semble que ça soit pas vraiment possible out of the box pour l'instant. Par contre en utilisant les logs git plus quelques scripts. Sinon une compilation du catalogue sur une machine pourrait te retourner des statistiques par rapport à l'ensemble des machines (j'ai vu ça dans le cadre d'une migration à puppet 2.7, puppet compilait les catalogues sur un serveur dédié, et on remontait toutes les erreurs, quand il n'y avait plus rien on a migré).
Si tu trouve la solution miracle, je suis preneur !
Librement
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: Choisir le bon outil
Posté par eMerzh (site web personnel) . Évalué à 2.
Bon bon , il faut vraiment que je creuse du coté de Mco …
J'ai trouver un truc ici qui semble intéressant
https://github.com/ripienaar/mcollective-plugins/tree/feature/master/15472/agent/puppet#readme
et permettrai d'être un pas plus loin vers la solution
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.