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.
