2

Puppet is eating up resources on my machine and unfortunately I have to run master alongside other process in a machine.

Now I am plan to stop puppet running as a daemon all the time and instead was thinking about running it:

  1. when the puppet controlled manifests change. My manifests are under revision control in git. Perhaps through a post receive hook.
  2. Run puppet once daily. If someone is to change the configs on the a machine this should replace. E.g. sshd_config should be pristine.

Has anyone ventured into such a strategy?
Can someone help?

Quintin Par
  • 4,293
  • 10
  • 46
  • 72

2 Answers2

4

Yes, this has been done.

See: Puppet: Only allow changes during certain hours?

As far as the Git approach, you've probably seen this link.

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
4

You could add puppet to a cron job as normal (which allows you the option to only run it during working hours or more or less frequently than every half hour) but wrap it in a short script that checks whether the revision number of your source control has been incremented. If so, it fires off the puppet client, if not then there's no need for puppet (and all of the expensive hashing of files it does).

This would mean, however, that if you changed a file on a host puppet would not change it back until the next configuration change. You could avoid this problem by changing the logic of the wrapper script to also run a puppet client if it has been more than 24 hours since the last run.

The "masterless" puppet idea (that ewwhite mentioned) removes the puppet master as being the bottleneck and replaces it with git being the bottleneck, which is vastly preferable in my opinion. Unless you make changes to git quicker than it can push those changes out to all the hosts, this bottleneck won't be a problem. You could arrange the "spokes" in a tree fashion if it ever did become a problem. That should scale to tens of thousands of hosts.

Ladadadada
  • 25,847
  • 7
  • 57
  • 90