On Sep 13, 2:53 pm, Ashley Penney <apen...@gmail.com> wrote: > I know this has come up on the list numerous times before but I > thought it would be a good time to see if the state of the art has > advanced for this kind of thing. I wanted to know how people are > handling higher level deployment of applications - things that have to > be done repeatedly but not all the time. An example of this is > checking an application out of svn, building it, creating a package > and then moving it off to a repo. Or even just building/installing > locally for developers. > > It never seems to fit well into Puppet for me and I end up with crazy > complicated manifests to deal with this kind of thing. I recently > moved these jobs into Rundeck (www.rundeck.org) which works pretty > well but doesn't really leverage any of the stuff I have within > Foreman/Puppet. I've seen suggestions to use mcollective but this > doesn't easily integrate our existing scripts (written in many > languages) or processes and would require me to force a lot of > developers to work differently. I could just have classes that > trigger scripts only when some condition is met (like /.buildapp > files) or something along those lines but nothing seems elegant. > > What I'm trying to find out is what other people did to handle this? > I want something I can build up over time and slowly migrate legacy > apps and processes into without having to do a massive up front > development. It should also be relatively simple and not require me > to code anything as anyone on the list who knows me can tell you that > I am absolutely awful at coding.
Do not mistake Puppet for a script engine or a remote job executor. It is a state management system. Crazy complicated manifests for an uncomplicated area should be a sign to you that you are using the wrong tool for the job, or at minimum that you are using the tool wrongly. For the types of tasks you listed as examples, I would just use an ordinary shell script, run manually -- supposing the steps were complicated enough to warrant automating it in any way. Run them via a remote job executor service (such as Puppetlabs's own MCollective) if needed. If you insist on doing this sort of thing with Puppet then you need to start out with a high-level view of the problem. You must answer these two questions right off the bat: 1) What are the *states* that (may) need to be achieved _and maintained_? 2) How will clients' current state be measured and reported? If you have trouble defining the target states, if you can't (or don't want to) plan to maintain them once achieved, or if you don't have a good way to determine the current state, then your task is not well suited to Puppet. If the answers to those questions are complex, then any Puppet manifests that adequately address this area for you must necessarily be complex -- that is the nature of your particular problem. On the other hand, if you have good, reasonably simple answers to those questions then they should lead you to a good, reasonably simple set of manifests. As Brian implied, it may be that Puppet can contribute to your solution even if it is not the primary driver (e.g. by building and deploying config files and similar for other tools). John -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
