Difference between Puppet agent v. apply

[warron.french]

Can someone please clearly explain why/when to use:
puppet apply versus Puppet agent?

I believe, but I want to be thoroughly corrected, the following:
1.  puppet apply  (with --noop) is for 'smoke' testing a specific manifest .PP-file, but

2. puppet apply will apply a single (specified on cli) module in reality; but,

3.  a puppet agent -t searches the deltas of files tracked by the Puppet Master and applies all changes for all modules wherever the modules are actually appropriate candidates.

[Henrik Lindberg]

On 18/02/16 02:10, warron.french wrote:
> Can someone please clearly explain why/when to use:
> puppet apply versus Puppet agent?
>

puppet agent makes requests to the master - the master compiles the catalog.

puppet apply produces the catalog locally (must have all the manifests
etc on the agent) - a.k.a known as running masterless.

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Jeff Abrahamson]

On Thursday, 18 February 2016 05:18:19 UTC+1, Henrik Lindberg wrote:

On 18/02/16 02:10, warron.french wrote:
> Can someone please clearly explain why/when to use:
> puppet apply versus Puppet agent?
>

puppet agent makes requests to the master - the master compiles the catalog.

puppet apply produces the catalog locally (must have all the manifests
etc on the agent) - a.k.a known as running masterless.

Henrik's answer is perfect.  As a relative newbie, this is a point (and it's follow-on: why?) that I remember was briefly difficult but that becomes so obvious that it's increasingly hard to remember why I thought it was hard.  So let me offer a a bit more (the more experienced will correct me) while I can still remember that it was briefly hard.

In a very old, honest, and maybe small world, you might never need a puppet master.  Each host has access to its configuration information and uses puppet apply to configure itself.  This is really simple to set up, because you don't need a master.  Maybe I have a cron job that periodically does a git pull && puppet apply.

This eventually leads to frustration.  These are some of the things I considered (against the simplicity of "git pull && puppet apply"):

• Maybe some hosts have to know secrets.  There are techniques for this (blackbox, puppet-decrypt, etc.).  I'm not sure if any solution is canonical.  But do you want all hosts to have to know how to access those secrets?
• Is it ok for all of your hosts to have access to your git repo?  Does each host have a separate key or do you have to update all hosts if you need to invalidate that key in a hurry?
  
• Maybe some hosts are more publicly visible than others, and you don't want the more publicly visible hosts to know anything about what's behind the curtain to limit discoverable attack surface
• In case you need to revert, the master makes this a bit easier (I've heard, but I am not convinced)
• Central reporting of client state

While I'm sure you're as facile with google as the rest of us, I found this SO (SU) article quite reasonable.

[jcbollinger]

On Wednesday, February 17, 2016 at 7:10:29 PM UTC-6, Warron French wrote:

Can someone please clearly explain why/when to use:
puppet apply versus Puppet agent?

Responding to your specific (mis)understandings:
 

I believe, but I want to be thoroughly corrected, the following:
1.  puppet apply  (with --noop) is for 'smoke' testing a specific manifest .PP-file, but

Not really, unless you ordinarily use 'puppet apply' (without --noop) to build and apply catalogs.

Your manifests and data need to be present on the host where you build the catalog, but they do not necessarily need to be present on the node to which you apply a catalog.  If your nodes ordinarily obtain their catalogs via the agent, then they probably don't have the manifests and data.  Moreover, some aspects of catalog building can produce different results depending on where they run.

Additionally, the community's conventional choice for testing Puppet modules is Rspec.

 

2. puppet apply will apply a single (specified on cli) module in reality; but,

Not necessarily.  'puppet apply' will build a catalog locally, starting from the manifest file you specify to it, and referencing other manifests and data as necessary.  If successful, it will then apply the catalog to the node on which it is running.  To the best of my knowledge, the only essential difference between the catalog building process performed by the master and the one performed by 'puppet apply' is how the starting-point manifest(s) are chosen.  Note also that the manifest you specify to 'apply' does not have to belong to a module.

 

3.  a puppet agent -t searches the deltas of files tracked by the Puppet Master and applies all changes for all modules wherever the modules are actually appropriate candidates.

No, I think that's a poor characterization.  'puppet agent' requests that the master build a catalog for the local node, and then applies that catalog; together these constitute a "catalog run".  Depending on the options you specify, the agent may do this just once, or it may run as a daemon, performing catalog runs on a configurable schedule.  The second stage, applying the catalog received from the master, is no different when performed by the agent than when performed by 'puppet apply'.  The first stage differs mainly in where it is performed. Where a master is in use, it typically does far more than track files.  For its part, the agent has nothing to do with deciding what to apply; its job is to determine how to apply it.


Overall, I suspect that your misunderstandings are based, in part, on an idea that you would routinely have use for both 'puppet agent' and 'puppet apply'.  Typically, however, a Puppet shop will use either one or the other, not both.


John

[warron.french]

Henrik, that looks like the text straight of the man page, which is what I can't quite wrap my head around.

I thought the purpose of the catalog is for telling the agent what modules it needs to pull to update its files to what is specified in the modules.

--------------------------
Warron French

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/56C53891.4010104%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

[Rich Burroughs]

The agent does not pull modules in a master/agent setup. They are only on the master.

The catalog contains the info that the agent needs to get its managed resources into the desired state. It's not a list of modules.


Rich

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJdJdQnFb0rvuXrtyAhaeC1Vb0B5vdQ9hKbBi4oNxe2CHmy%2Bfg%40mail.gmail.com.

[warron.french]

jcbollinger.... Rspec?  I have never even heard of that, not even during my Puppet Training (in a classroom).  That's interesting.

Jcbollinger, I think your explanation has unclouded my understanding quite a bit - thank you.  Also, my shop uses 'puppet agent -t' on the command line when we want to demand a system be updated and we know it is a good candidate for being updated; otherwise, we do use something in the crontab to update the system every 15 minutes or something like that.

Thank you all, JC, Henrik, and Jeff for trying to explain.

I hope not to be so dense when it comes to these questions and concepts, but I am a sysadmin more than a software developer, and Puppet Administration seems to be directly in the sweetspot that I can't quite reach yet.  I am getting there, but I must keep asking the community for its help and clarification.  Sometimes, RTFM doesn't work.

Thank you all again.

--------------------------
Warron French

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/80c5bf43-87bd-4f89-b5a1-8147c4a86a7e%40googlegroups.com.

[warron.french]

Hi Rich, thank you for the clarification.  The more we discuss this, the more clear (granted slowly) it becomes for me.

--------------------------
Warron French

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPGcbtApFnmH6saptbLjekxQxkdM0Sv_OK%2BA13BeMTxjM4zZJg%40mail.gmail.com.

[Rich Burroughs]

They would not likely have covered Rspec in Puppet Fundamentals, if you took that. Rspec is a Ruby testing framework, and most of the Puppet testing tools out there are based on it.

And I think your challenge you mention isn't uncommon. A lot of sysadmins can write scripts but don't have experience with engineering practices, like writing tests. It's a new way of looking at things.

The upside is that these kinds of skills are in demand, and in demand at the more interesting shops out there to work at. So it's definitely in your benefit to work through this and learn some new things :) Hang in there.


Rich

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJdJdQmuCCFOhKgKY-UYyHxE7pUB-31vkbm9QyHkGW_k%2BxVF-w%40mail.gmail.com.

[warron.french]

Thanks a lot Rich!

I appreciate the chat.

--------------------------
Warron French

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPGcbtCpc1LK%3Deu5GhFVnAfXbuvkafs_mPVBBiRAFDMq3urTUA%40mail.gmail.com.