Forum Linux.général Puppet : Acceptation des changements

Posté par  (site web personnel) . Licence CC By‑SA.
0
2
jan.
2013

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  . É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  . É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  (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  . É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 !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.