Puppet users - Jan 2010 - Using Git to distribute Puppet configs

Hi,

Stephen would never mention it himself, he''s too modest, but
he''s done
a great write-up of how he uses Git (or other DVCS) to distribute
manifests instead of using a Puppetmaster. It''s quite flexible and
powerful (you can use a post-receive hook on the remote repos to run
Puppet whenever a new config is pushed out, for example). It''s an
approach to Puppet scaling I''ve not seen before - I really like this
idea, so I''d be interested to know if anyone else has done something
similar, and what you think about Stephen''s scheme:

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

Regards,
John
-- 
Bitfield Consulting: we make software that makes things work
http://bitfieldconsulting.com/

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi John, 
I read the blog post and although an interesting approach, I can see several
shortcomings, namely:
- Lack of external node classifier: how do you control/specify which node
applies which modules?
- Anything apart from a DVCS to do deployment (i.e. subversion) would be
madness. And even with git I think it can get out of control really fast
- Each node has a copy of the entire repository of modules and classes which
makes it in my opinion a security risk.

I agree with the fact that puppet''s SSL config/setup can be a real
PITA, especially when dealing with multiple locations/domains.

Cheers,
Atha
On Jan 27, 2010, at 12:21 , John Arundel wrote:
> Hi,
> 
> Stephen would never mention it himself, he''s too modest, but
he''s done
> a great write-up of how he uses Git (or other DVCS) to distribute
> manifests instead of using a Puppetmaster. It''s quite flexible and
> powerful (you can use a post-receive hook on the remote repos to run
> Puppet whenever a new config is pushed out, for example). It''s an
> approach to Puppet scaling I''ve not seen before - I really like
this
> idea, so I''d be interested to know if anyone else has done
something
> similar, and what you think about Stephen''s scheme:
> 
>
http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control
> 
> Regards,
> John
> -- 
> Bitfield Consulting: we make software that makes things work
> http://bitfieldconsulting.com/
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Atha Kouroussis wrote:
> - Lack of external node classifier: how do you control/specify which node
> applies which modules?
You would likely use ''node'' statements in your manifests.

But I think you can use external_nodes from stand-alone puppet as well.
You would of course need to make sure that the external nodes script
and whatever data files it needs are part of the repository you send out
to the nodes.
> - Each node has a copy of the entire repository of modules and classes
> which makes it in my opinion a security risk.
Don''t put passwords and private keys in your manifests.

If you have secrets due to NDAs or other commercial concerns, then it might
be a bad idea to manage such things with Puppet and distribute your manifests
this way.  If it is a secret that you are using product X in department Y,
then you night not want that information on a laptop belonging to department
Z that might be stolen.  But there are many organisations that don''t
need to
keep that information secret (and if they think they do due to security
concerns, they likely have problems anyway).  Some organisations do have
such secrets, though, and they need to evaluate the risks before doing it.


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Jan 27, 2010 at 7:59 AM, Atha Kouroussis
<akouroussis@gmail.com>wrote:
> Hi John,
> I read the blog post and although an interesting approach, I can see
> several shortcomings, namely:
> - Lack of external node classifier: how do you control/specify which node
> applies which modules?
>
We don''t do things this way (although I''ve considered it
often) but at the
same time have only the default node defined.

We use facts to determine what kind of attributes a machine possesses, and
the selectively choose which modules are applied based upon that.

node default { include base }

and then modules/base/manifests/init.pp is where all the logic lives.

I like having my clients be self-organizing as much as possible.

- Anything apart from a DVCS to do deployment (i.e. subversion) would
be
> madness. And even with git I think it can get out of control really fast
> - Each node has a copy of the entire repository of modules and classes
> which makes it in my opinion a security risk.
>
> I agree with the fact that puppet''s SSL config/setup can be a real
PITA,
> especially when dealing with multiple locations/domains.
>
> Cheers,
> Atha
> On Jan 27, 2010, at 12:21 , John Arundel wrote:
>
> > Hi,
> >
> > Stephen would never mention it himself, he''s too modest, but
he''s done
> > a great write-up of how he uses Git (or other DVCS) to distribute
> > manifests instead of using a Puppetmaster. It''s quite
flexible and
> > powerful (you can use a post-receive hook on the remote repos to run
> > Puppet whenever a new config is pushed out, for example).
It''s an
> > approach to Puppet scaling I''ve not seen before - I really
like this
> > idea, so I''d be interested to know if anyone else has done
something
> > similar, and what you think about Stephen''s scheme:
> >
> >
>
http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control
> >
> > Regards,
> > John
> > --
> > Bitfield Consulting: we make software that makes things work
> > http://bitfieldconsulting.com/
> >
> > --
> > You received this message because you are subscribed to the Google
Groups
> "Puppet Users" group.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> > For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.