To throw a few buzzwords:
- access control
- stored configs
- modules (?)
I haven't tried extlookup, but there may be issues with that as well.
Some of these can be (more or less) easily circumvented (ACL,
extlookup), but the others may be outright impossible to. There's surely
more I'm not thinking of.
Cheers,
Felix
Puppet is about centralizing administration. If you have dozens/hundreds
of client nodes to administer, then you clearly gain by being able to
make changes in one central location (the puppetmaster) without having
to bother with pushing those changes to all your client nodes yourself.
You could devise a mechanism to push/pull your repository to your
various machines automatically, but then you'd be re-inventing the
wheel, not to mention missing out on the functionality that Felix Frank
listed.
I you have even a modest number of nodes (e.g., ten) to administer,
you're probably complicating things unnecessarily by forgoing a
puppetmaster.
Kelly
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
I've not found an explanation of what is lost by using Puppet without a puppetmaster.Does anyone have a link to something like that, or is anyone willing to expound on the topic?
There's quite a bit of functionality in Puppet Master so this is not a
comprehensive list. Puppet Master provides a centralized location for:
managing manifests, modules, and environments
syncing custom facts and types/providers
reports
puppet:/// file service
certificates
filebucket backup
collecting facts from clients (future inventory service)
You can achieve some these functionality without a puppet master, but
you would still have the same hurdles for disconnected networks.
Jordan's slides list several differences so I won't reiterate them
here.
Another key difference is the agent only receives a catalog in
master/agent mode. In masterless mode you must provide the puppet
manifest/templates to each client system. The catalog is system
specific and does not contain any configuration information about
other systems, the manifests and templates would have all the
configuration data for all systems.
It would be non trivial to keep the configuration data isolated in
masterless mode if you have a desire to segment and isolate
configuration data by system, or even system roles (i.e. my website
database system should not contain puppet manifest with my financial
database password).
The rest of the features are mainly trade off between a central
service vs. distributed service, and the ability to isolate access
(i.e. if you use an ENC, puppet master is the only system that needs
access to the LDAP/CMDB/database, if you implement something similar
in a masterless environment, every agent needs an account and access
to that central source of information).
Thanks,
Nan
It would be non trivial to keep the configuration data isolated in
masterless mode if you have a desire to segment and isolate
configuration data by system, or even system roles (i.e. my website
database system should not contain puppet manifest with my financial
database password).
One thing we have is mulitple NFS mounts common to all machines. So
moving to serverless was quite painless and has so far been a HUGE
improvement.
I think it depends on the use case. I much prefer the git method. I'm trying to do it the classic way this week, but there is a lot of decisions to deploy an efficient puppetmaster which add complexity and unwanted software to some setups.
> Another key difference is the agent only receives a catalog in
> master/agent mode. In masterless mode you must provide the puppet
> manifest/templates to each client system. The catalog is system
> specific and does not contain any configuration information about
> other systems, the manifests and templates would have all the
> configuration data for all systems.
>
> It would be non trivial to keep the configuration data isolated in
> masterless mode if you have a desire to segment and isolate
> configuration data by system, or even system roles (i.e. my website
> database system should not contain puppet manifest with my financial
> database password).
This is a very important point that I'd like to reiterate.
In some environments it's simply unacceptable to expose all password
hashes for all services to all machines.
You can work around this in masterless mode with appropriate ACLs and
some custom function work, but you're going to be doing work that a
master does for you.
For certain patterns of usage, a masterless setup may be the way to
go. It's certainly a simpler model for scaling, but you'll probably
want to at least submit reports to a central location.
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> On 02/07/2011 06:59 PM, jblaine wrote:
>> I've not found an explanation of what is lost by using Puppet without a
>> puppetmaster.
>>
>> Does anyone have a link to something like that, or is anyone willing to
>> expound on the topic?
>
> To throw a few buzzwords:
> - access control
> - stored configs
> - modules (?)
Modules apparently worked just fine for me locally without a puppetmaster.
--
Cosimo
Modules work fine with stand-alone Puppet by specifying a --modulepath.
Regards
James
--
James Turnbull
Puppet Labs
1-503-734-8571
In IRC, RI Pienaar noted that, in fact, *all* of the above work in
masterless operation (even though you have to rely on access control
mechanisms other than those found in puppet).
Cheers,
Felix