Journal Puppet [2] : run puppet et cron

Posté par skhaen (site web personnel) le 20 mai 2017 à 14:14. Licence CC By‑SA.

Étiquettes :

mai

2017

Publié à l'origine sur cyphercat.eu/puppet-partie-2.

Lancer un run puppet avec cron

Lancement automatique du run puppet sur les nodes avec cron toutes les heures :

note : chaque tache cron ajouté nativement par puppet sera mis dans crontab, vous pouvez les lister avec crontab -l sur vos nodes.

  cron { "puppet":
    ensure  => present,
    command => 'puppet agent -t --onetime --http_read_timeout 2m --logdest /var/log/puppetlabs/puppet/puppet`/bin/date +\\%Y\\%m\\%d\\%H\\%M`.log 1>/dev/null 2>&1',
    user    => 'root',
    minute  => fqdn_rand(60),
    require => File['/var/log/puppet'],
  }

Si vous souhaites voir le détail des options, c'est sur configuration.html. Le $fqdn_rand(60) (cf. #fqdnrand, permet d'indiquer aléatoirement une valeur de 0 à 60 (la valeur max étant non inclus selon la documentation) pour la configuration du cron.

Cette méthode permet d'éviter d'avoir tout les runs qui se lancent au meme moment, ce qui pourrait surchager le master.

ATTENTION : Si vous des anciennes versions de Puppet sur vos nodes (2.7 sur Debian wheezy sans les backports par exemple), certaines options peuvent ne pas passer : n'hésitez pas à vérifier ce qui est valide/obsolète et à tester.

On n'oublie pas de vérifier que le dossier /var/log/puppet est bien présent (les logs, c'est la vie) :

  file { "/var/log/puppetlabs/puppet":  
    ensure => directory,
    owner  => puppet, 
    group  => puppet,
    mode   => '0750',
  }

on ajoute une tache planifié pour supprimer automatiquement les logs après 3 jours toutes les nuits à 1h :

cron { "remove-puppet-log":0
  ensure  => present,
  command => "find /var/log/puppetlabs/puppet/ -type f -iname \"puppetd*log\" -mtime +3 -delete",
  user    => 'root',
  hour    => 1,
  minute  => fqdn_rand(60);
    }

puis on vérifie bien que le service puppet est arreté lors de chaque run (on souhaite une gestion des run via cron, et non via le daemon) :

  service { puppet:
    ensure    => stopped, 
    hasstatus => true
  }

Publié à l'origine sur cyphercat.eu/puppet-partie-2.

# Quelques précisions

Posté par ondex2 le 20 mai 2017 à 15:54. Évalué à 3.

puppet agent -t --onetime --logdest /var/…
- onetime est inclus dans -t, donc inutile de le remettre
- pourquoi ne pas utiliser syslog ? ça tombe généralement dans un fichier genre /var/log/messages ou daemons, qui est déjà géré par syslog et logrotate. ça t'évite de devoir créer des dossiers, des commandes de nettoyage, etc…

fqdn_rand() n'est pas aléatoire mais pseudo aléatoire. Il te sort un entier dépendant du fqdn de ta machine (et optionnellement d'un seed). si c'était vraiment aléatoire, ça changerait à chaque run, ce qui ne serait pas souhaitable.

service { … }
- hasstatus vaut true par défaut, donc pas utile de le préciser
- ne pas oublier enable => false pour pas que le démon se relance au démarrage
- [^] # Re: Quelques précisions
  
  Posté par skhaen (site web personnel) le 20 mai 2017 à 16:28. Évalué à 2.
  rha, comme quoi les habitude…
  - Le pire c'est que je m'en doute pour --onetime, mais j'ai "appris" la commande avec, du coup je le met sans y penser…
  - je préfère avoir un dossier avec un run par fichier, c'est plus facile à retrouver, à lire et il n'y a pas de "bruits" en plus :)
  - ah, je pensais que ce serait assez précis >_<
  - perso pour certaine commande je préfère avoir certains détails, même si c'est la valeur par défaut
  - en effet !
  - [^] # Re: Quelques précisions
    
    Posté par Sacha Trémoureux (site web personnel) le 20 mai 2017 à 17:42. Évalué à 2.
    
    Pour le point sur le syslog, la séparation dans un fichier externe n'empêche pas de configurer un peu plus proprement un logrotate. :D
# pourquoi ne pas faire conviance au daemon ?

Posté par Psychofox (Mastodon) le 22 mai 2017 à 08:15. Évalué à 3.

on souhaite une gestion des run via cron, et non via le daemon

Pourquoi justement ? Autant je vois l'intérêt pour quelqu'un utilisant puppet en "sans serveur", autant ce n'est pas le cas dans la doc publiée sur ta page perso. De mon expérience le daemon est fiable et avec la puppetdb (ou un outil de monitoring) tu es rapidement au courant si un agent est unresponsive.
- [^] # Re: pourquoi ne pas faire conviance au daemon ?
  
  Posté par ondex2 le 22 mai 2017 à 08:27. Évalué à 0.
  
  Ja favorise également un run en cron. Dans le passé, j'ai remarqué qu'en mode daemon, les run avaient tendance à se regrouper. Je me retrouvais donc avec plusieurs millier de run en quelques minutes, le master n'aimait pas trop
  
  De plus, en cron, même si tu le kill (parce que tu kill si le run est pas fini au bout de X minutes, parce que oom, …), tu sais que l'agent sera de nouveau exécuté plus tard. En mode daemon, faut que tu le relance toi même.
  - [^] # Re: pourquoi ne pas faire conviance au daemon ?
    
    Posté par Psychofox (Mastodon) le 22 mai 2017 à 08:41. Évalué à 2.
    
    Ja favorise également un run en cron. Dans le passé, j'ai remarqué qu'en mode daemon, les run avaient tendance à se regrouper. Je me retrouvais donc avec plusieurs millier de run en quelques minutes, le master n'aimait pas trop
    
    J'imagine que c'est le cas si on reboot régulièrement ses vm de façon groupées. J'essaye d'éviter ça en fait.¨
    
    De plus, en cron, même si tu le kill (parce que tu kill si le run est pas fini au bout de X minutes, parce que oom, …), tu sais que l'agent sera de nouveau exécuté plus tard. En mode daemon, faut que tu le relance toi même.
    
    Jamais trop eu ce genre de problèmes, avec 30 minutes d'intervalles entre les runs.
  - [^] # Re: pourquoi ne pas faire conviance au daemon ?
    
    Posté par Anonyme le 23 mai 2017 à 09:16. Évalué à 4.
    
    les run avaient tendance à se regrouper
    
    C’est pour ça que tu as les configurations splay et splaylimit qui permettent d’avoir des run répartit plus ou moins aléatoirement.
    
    (parce que tu kill si le run est pas fini au bout de X minutes, parce que oom, …)
    
    Pour chaque run, le daemon fork (ou spawn un autre processus, je sais pas) il suffit de killer le fils plutôt que le père. Dans tous les cas, même avec une tâche cron, comme l’agent pose un lock pendant le run, si le processus se bloque, les suivants ne se lanceront pas.
    
    Après, à toi de mettre la supervision nécessaire pour vérifier que Puppet fonctionne correctement.
    
    avec plusieurs millier de run en quelques minutes, le master n'aimait pas trop
    
    Plusieurs milliers de machine et un seul master, ça me paraît légèrement sous-dimensionné comme infra non ?
    - [^] # Re: pourquoi ne pas faire conviance au daemon ?
      
      Posté par ondex2 le 31 mai 2017 à 00:24. Évalué à 1.
      
      C’est pour ça que tu as les configurations splay et splaylimit qui permettent
      d’avoir des run répartit plus ou moins aléatoirement.
      
      J'aime pas trop dans le sens ou tu cumule un pseudo-random avec un vrai random (le moment de démarrage du démon). Je suis d'accord que statistiquement ça doit être correctement réparti. Mais si un moment ton master lag un peu, stack des connections, ben les run d'agents vont se décaler, commencer en même temps, et donc ils seront synchroniser. Oui, c'est des choses qui ne devraient pas arriver. Mais d'expérience, ce qui ne doit pas arriver fini toujours par arriver :)
      
      Le cron, c'est pseudo-random, et stable dans le temps. Quoi qu'il arrive, ça démarrera toujours au même moment.
      
      Après, à toi de mettre la supervision nécessaire pour vérifier que Puppet
      fonctionne correctement.
      
      En effet, j'ai de la supervision qui vérifie que Puppet tourne régulièrement, et qu'il fini sans erreur. Et j'avais constaté des blocages en mode agent. Alors là je parle de Puppet 2.7. Ce soucis a peut être été réglé depuis, je ne suis juste pas revenu en arrière. Cron ça marche, je consacre mon temps à d'autres priorités.
      
      Plusieurs milliers de machine et un seul master, ça me paraît légèrement sous
      dimensionné comme infra non ?
      
      Ben en faites non, c'était pas un soucis. Alors évidement, je parle pas d'un master en "process" avec 4 coeurs et 8G de RAM (plutôt passenger, 24 coeurs et 32GB de RAM). A force de faire grandir le catalogue (et le nombre de d'agents), ça commençait à devenir un peu limite, alors on a ajouté un second master. Il parait que le puppet-server ça rox, mais mon catalogue est pas encore complètement "puppet 4 compliant"
      - [^] # Re: pourquoi ne pas faire conviance au daemon ?
        
        Posté par Anonyme le 31 mai 2017 à 09:48. Évalué à 2.
        
        Alors là je parle de Puppet 2.7. Ce soucis a peut être été réglé depuis.
        
        Oui, parce que là, on est en 4.10…
        
        Ben en faites non, c'était pas un soucis.
        
        Par curiosité vous avez combien de machines ?
        
        On a 5 masters pour un peu moins de 10000 machines, et on fait tourner Puppet toutes les 8h (avec un splay de 8h également).
        
        [^] # Re: pourquoi ne pas faire conviance au daemon ?
        
        Posté par ondex2 le 31 mai 2017 à 22:52. Évalué à 2.
        
        Oui, parce que là, on est en 4.10…
        
        J'aurais peut être du préciser que c'est plus en 2.7. C'est en 3.8 maintenant, en train de faire les correctifs pour "sauter" en 4+
        
        Par curiosité vous avez combien de machines ?
        
        5500 machines, run toutes les 30 minutes.
      - [^] # Re: pourquoi ne pas faire conviance au daemon ?
        
        Posté par barmic le 31 mai 2017 à 10:20. Évalué à 3.
        
        C'est marrant parce que c'est typiquement un cas où utiliser un message broker (AMQP, MQTT, Redis au pire) est hyper pertinent. Ils ne s'y sont pas mis ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: pourquoi ne pas faire conviance au daemon ?
        
        Posté par Anonyme le 31 mai 2017 à 13:37. Évalué à 2.
        
        Tu as mcollective pour pousser/réagit à des événements.
        
        Sinon, tu peux regarder du côté de mgmt, salt, etc.
# Explications

Posté par barmic le 22 mai 2017 à 09:06. Évalué à 3.
Je ne comprends pas très bien. Que fais :
```
  cron { "puppet":
    ensure  => present,
    […]
  }
```
C'est un cron géré au sein de puppet ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Explications
  
  Posté par Psychofox (Mastodon) le 22 mai 2017 à 10:14. Évalué à 4.
  
  Oui. La première fois tu lances puppet "à la main" et il ajoute automatiquement son entrée cron.
# Cron ou timer

Posté par barmic le 22 mai 2017 à 09:09. Évalué à 4.

Je me suis récemment mis aux timers systemd pour remplacer cron et j'en suis super content. La principale raison c'est d'avoir la commande systemctl list-timers qui m'indique l'heure du dernier et du prochain lancement de chaque tâches.

Ça n'est pas parfaitement équivalent (si tu n'est pas administrateur de la machine, tu ne pourra pas t'en servir), mais pour moi ça rempli totalement son rôle.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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