Hi Lucian, If you are interested I'll be doing a demo in London next week:
http://pug-london-oct-2011-eorg.eventbrite.com/ ken. On Wed, Oct 12, 2011 at 3:23 PM, Lucian Holland <[email protected]> wrote: > Wow, thanks for this - there's a huge amount in there. It will take me a > while to get unpick it all (I'm still a puppet novice really!) but that > looks like exactly the sort of thing I was talking about. Will have a play > and see how I get on! > Lucian > -- > Lucian Holland > Sent with Sparrow > > On Tuesday, 11 October 2011 at 17:25, Ken Barber wrote: > > I've done some work on creating entire networks using defined > resources or 100% exported resources for the nodes you build. The > following is an example environment with classes included: > > https://github.com/kbarber/puppet-onedemo/tree/master/manifests > > If you take a look at the nodes.pp you can see my use of app_* cases. > The resources are defined in the 'apps' module path ... and they all > use the pattern described in: > > https://github.com/kbarber/puppet-onedemo/blob/master/manifests/solutions.pp > > Here I have a wrapper for launching vm's using an OpenNebula resource, > and I handle exporting configurations for each node. > > Its not perfect and lacks time-based orchestration which is the major > hick-up for such a solution. Not to mention that you would have to > have stored configurations scale very well ... but if you keep the > layer you export down to a minimum little information needs to live in > the stored configurations themselves. So largely this is a proof of > concept. > > The app_stuck example actually is meant to build a complete working > 'pastie' style application - with databases, app servers and load > balancers. > > Generally though - this topic is a hot discussion these days I've been > having with quite a few individuals. > > ken. > > On Tue, Oct 11, 2011 at 10:13 AM, Lucian Holland <[email protected]> > wrote: > > Hi All, > > I've been exploring puppet and mcollective recently and I was > wondering if people here might be able to point me towards some > information on a potential use case. It seems like puppet is primarily > used at the moment as a tool for managing individual machine > configurations ('What do I need for a web server in production?'). At > the same time there is work going into imperative, distributed > solutions for provisioning machines and getting them set up with > puppet, either based on mcollective or custom built with tools like > fog (e.g. the new cloud provisioner). I'm wondering, though, has > anyone gone a step further and used the puppet declarative approach to > define the structure of a whole network? This would be particularly > useful for local CI environments when combined with virtualisation. > > I'm assuming that a start point would either be exported resources or > (better, in my opinion) something vaguely like this - > http://www.devco.net/archives/2010/09/18/puppet_search_engine_with_mcollective.php > - using fact-based discovery to find appropriate services to link up > machines together. But the next logical step would be to go beyond > simply querying the state of existing resources ("what is the ip of > the database?") and say something more like "Ensure there is a > postgres 9.1 database running on my local subnet". I accept that this > could be a bit terrifying for a production environment, but in a local/ > testing environment I could see it being hugely helpful. Clearly it > relies on puppet itself being able to control a variety of > virtualisation options, and perhaps a richer array of network service > controls as well. > > Is this a crazy idea? Has anyone tried it? Or would sticking to e.g. > TheForeman be a better plan (I have only looked briefly at it, not > really tried it yet - at first glance it still seems a bit more > imperative than what I'm suggesting + I get the impression that it > relies on DNS to glue a lot of things together, which isn't > necessarily so appropriate in a heavily virtualised environment. > > Lucian > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
