With a very small edge-case asterisk (the puppet Device support, which I've
never used), yes. The agent is a piece of software that runs (as a daemon,
via cron, manually, or via some other scheduling mechanism like
mcollective) on a host ("node" in Puppet nomenclature) and applies catalogs
to that one node.

There's a good introduction to this at
https://docs.puppetlabs.com/learning/agent_master_basic.html - I'd also
encourage you to look through the rest of the Learning Puppet section on
docs.puppetlabs.com.

On Sat, Sep 27, 2014 at 12:23 PM, Dennis Gearon <[email protected]> wrote:

> Thanks Jason. If I ever get to 1000 nodes, then I guess I'll have
> something to worry about, then. LOL! One final question.
>
> An 'agent' is really a managed server instance, not a Puppet worker
> managing something else, (as the word 'Agent' would suggest). So really,
> Agents only apply catalogs to themselves, right?
>
> On Sat, Sep 27, 2014 at 9:07 AM, Jason Antman <[email protected]>
> wrote:
>
>> Agents never control other agents. Aside from supporting technology
>> (PuppetDB, an ENC if you have one, a database to back PuppetDB), yeah, a
>> master and N agents is the gist of it.
>>
>> There are some docs online (see specifically the "Tuning and Scaling"
>> section of the Puppet Documentation Index,
>> https://docs.puppetlabs.com/puppet/#tuning-and-scaling ) about scaling,
>> and a search of the mailing list archives (as well as Google - there have
>> been quite a few blog posts on this) should help turn up other options and
>> experiences.
>>
>> Off the top of my head, I believe there are generally two paradigms used:
>> either clustering/HA for your masters, generally load-balanced from what I
>> gather, or (what I do) splitting up agents between different masters (by
>> location, or network, or dev/test/prod). My current infrastructure is made
>> up of ~450 nodes which are served by three masters - dev, test/QA and prod.
>> We run every 30 minutes, via mcollective with a set concurrency. The
>> masters are VMs, running on the same physical hosts as PuppetDB and its
>> PostgreSQL instance, so I'm quite confident that I could scale each one to
>> a few thousand nodes before I have to worry about overloading one host. In
>> addition, since we split dev, test/QA and prod masters, we can deploy
>> module changes (and puppet/puppetdb/etc. upgrades) to the dev environment,
>> validate there, promote to test/QA, validate there, and then promote to
>> prod.
>>
>> -Jason
>>
>> On Sat, Sep 27, 2014 at 11:03 AM, Dennis Gearon <[email protected]>
>> wrote:
>>
>>> Been burnnig up the keyboard and spewing packets to search for this
>>> answer, but haven't seen it.
>>>
>>> From what I've read, there is only:
>>>   A/ A Puppet Master
>>>   B/ Infinite number of 'Agent' nodes.
>>>
>>> Is this right?
>>>
>>> Is there any other kinds of nodes?
>>>
>>> Do Agent nodes ever control other nodes?
>>>
>>> What happens when the puppet master gets overloaded, how do you cluster
>>> or use a 'super' master to divide the load?
>>>
>>> Thanks for clearning this up for me :-)
>>>
>>> --
>>> 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 [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/4c6dde8c-d82e-4159-85a0-6fe4cc7aeb04%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/4c6dde8c-d82e-4159-85a0-6fe4cc7aeb04%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Puppet Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/puppet-users/AdEjg1IBGUc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/CAFt4V4%3DkTtL1O8JNeKLidmLpym61q8DYdPmVy4rJTa%2BOJLV_0g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CAFt4V4%3DkTtL1O8JNeKLidmLpym61q8DYdPmVy4rJTa%2BOJLV_0g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAAJay%2BZWWCGneffuK0voo5Ummx8sJxY0GD1q7ioeuE8Wh9ee3Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAAJay%2BZWWCGneffuK0voo5Ummx8sJxY0GD1q7ioeuE8Wh9ee3Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAFt4V4nwUGg%3DA4XQk7AC3psUFuQUQtNug6pLC68Hy6r8s2K7cA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to