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 (http://www.sparrowmailapp.com/?sig) 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] > (mailto:[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] > > (mailto:[email protected]). > > To unsubscribe from this group, send email to > > [email protected] > > (mailto:[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] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[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.
