Propagating Puppet changes

Deployment of Puppet code on production is a matter of updating the files on the directories served by the Puppet Master (or, in a Masterless setup, distributing these files on each node), but, contrary to other typical application deployments, the process doesn't end here, we need to run Puppet on our nodes in order to apply the changes.

How this is done largely depends on the policy we follow to manage Puppet execution.

We can manage Puppet runs in different ways and this affects how our changes can be propagated:

  • Running Puppet as a service—in this case, any change on the Puppet production environment (or what is configured as default) is propagated to the whole infrastructure in the run interval timeframe.
  • Running Puppet via a cron job has a similar behavior; whatever is pushed to production is automatically propagated in the cron interval we defined. Also in this case, if we want to make controlled executions of Puppet on selected servers, the only approach involves the usage of dedicated environments before the code is promoted to the production environment.
  • We can trigger Puppet runs in a central way, for example via MCollective (check http://www.slideshare.net/PuppetLabs/presentation-16281121 for good presentation on how to do it); once our code has been pushed to production, we still have the possibility to manually run it on single machines before propagating it to the whole infrastructure. The complete rollout can then be further controlled either using canary nodes, where changes are applied and monitored first, or, in large installations, having different clusters of nodes where changes can be propagated in a controlled way.

Whatever are the patterns used, it's very important and useful to keep an eye on the Puppet reports, and quickly spot early signs of failures caused by Puppet's runs.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.152.157