Best practices: client/server VS Git

[Julien Deloubes]

Hello there,
i'm actually learning Puppet in order to pass the exam.
I have no professional experience on the product yet, and wanting some feedback from you professional devops.
For the moment i see 2 ways for Puppet to synchronize nodes:
-Puppet client/server way with a puppetmaster node
-Decentralized way, with node pull their configuration from a Git repo and make a puppet apply on their own.

Can you told me what is the pro/cons for this two methods?
And for a large scale of node which is the preferred one?

Thanks for your help.

[Dirk Heinrichs]

Am 20.02.2014 16:15, schrieb Julien Deloubes:

For the moment i see 2 ways for Puppet to synchronize nodes:
-Puppet client/server way with a puppetmaster node
-Decentralized way, with node pull their configuration from a Git repo and make a puppet apply on their own.

Can you told me what is the pro/cons for this two methods?
And for a large scale of node which is the preferred one?

It depends on your use case. We, for example, use a mixture of both in a software development project. All nodes are connected to the master to receive their basic configuration. But we have certain software on certain nodes which should only be updated on demand, so we use the "puppet apply" approach for this in addition to the standard configuration.

HTH...

    Dirk

--

Dirk Heinrichs, Senior Systems Engineer, Engineering Solutions
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Tel: +49 2226 1596666 (Ansage) 1149
Email: d...@recommind.com
Skype: dirk.heinrichs.recommind
www.recommind.com

[Nikola Petrov]

On Thu, Feb 20, 2014 at 07:15:50AM -0800, Julien Deloubes wrote:
> Hello there,
> i'm actually learning Puppet in order to pass the exam.
> I have no professional experience on the product yet, and wanting some
> feedback from you professional devops.
> For the moment i see 2 ways for Puppet to synchronize nodes:
> -Puppet client/server way with a puppetmaster node

This is the approach we are currently taking and it allows you to use
virtual resources. This is the only thing which should drive you to this
setup - the other is much simpler in my opinion. Of course there might
be a way to use a central PuppetDB service in masterless setup but at
least I am unaware of how to do this.

> -Decentralized way, with node pull their configuration from a Git repo and
> make a puppet apply on their own.

This is the thing that we were doing until there were some needs for
hosts to configure them selfs based on configuration on other
hosts(virtual resources)

[Ken Barber]

> This is the approach we are currently taking and it allows you to use
> virtual resources. This is the only thing which should drive you to this
> setup - the other is much simpler in my opinion. Of course there might
> be a way to use a central PuppetDB service in masterless setup but at
> least I am unaware of how to do this.

It is possible:

http://docs.puppetlabs.com/puppetdb/1.6/connect_puppet_apply.html

ken.

[Julien Deloubes]

Very interesting , thanks for your feedbacks.

[Julien Deloubes]

Old topic but i was wondering how secure is the git masterless setup.
Do you have to separate each node configuration in a git branch or sub directory?
I mean if you git clone the whole repo isn't a bit dangerous to have all the configuration on the node?
In a master/agent configuration the configuration code is never locally on the node.
Thanks.

[Trevor Vaughan]

It depends on how you organize/protect your repos.

If you use something like Gitolite, you can restrict branches to specific users which would let you enforce central isolation.

However, a mistake on a branch or permissions could indeed lead to sensitive information leaks.

Trevor

--
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/d7eb43a3-0a17-4192-98e8-4de7ae73b140%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --