This looks fascinating and I'm absolutely going to do some experimentation
with it this week as a way to do some of the awkward deploys that exist. I
love the idea. As a recent 2.7 upgrader I look forward to seeing the faces
version you talk about. I guess today I'll finally get mcollective rolled
out in advance of testing with Puppi. Thanks!
(As for the rest of this thread Volcane convinced me that I was being stupid
and my approach to the problem was wrong and to put the build logic in
Jenkins and keep the deploy logic to package{}.
On Mon, Sep 19, 2011 at 5:01 PM, Alessandro Franceschi <a...@lab42.it> wrote:
> You might be interested in Puppi, which is a Puppet module and a bash
> command that i've written exactly for this reason.
> Code: https://github.com/example42/puppi
> More info: http://www.example42.com (now terribly slow) or
>
> http://puppetlabs.com/blog/deploying-applications-and-bringing-puppet-information-to-the-cli-with-puppi/
> It mixes the possibility of defining inside puppet manifests what you
> need to make a deploy with a simple command that is actually used to
> launch the deploy (by hand, via cron, via mcollective or triggered by
> whatever tool).
> The deploy procedure (commands to execute) can be totally customized,
> but there are some ready examples to deploy from a Nexus repository,
> or deploy directly wars, tarballs, zip archives and so on.
>
> In few words, in order to be able to issue a command like:
> puppi deploy supersite
>
> you write Puppet code like this:
> puppi::project::war { "supersite":
> source => "http://repo.example42.com/deploy/prod/
> supersite.war",
> deploy_root => "/store/tomcat/myapp/webapps",
> report_email => "sysadm...@example42.com",
> }
>
> but you can have more complex arguments like:
> puppi::project::maven { "supersite":
> source => "http://nexus.example42.com/nexus/content/
> repositories/releases/it/example42/supersite/",
> deploy_root => "/usr/local/tomcat/supersite/webapps",
> config_suffix => "cfg",
> config_root => "/srv/htdocs/supersite",
> document_suffix => "css",
> document_root => "/srv/htdocs/supersite",
> firewall_src_ip => $site ? {
> dr => "192.168.101.1/30",
> main => "192.168.1.1/30",
> },
> backup_retention => "3",
> init_script => "tomcat",
> report_email => "sysadm...@example42.com",
> enable => "true",
> }
>
> And, if you need it, there's the mcollective agent and relevant mc-
> puppi command.
> Hope it might help,
> al
>
> On Sep 13, 9: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.
>
> --
> 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.
>
>
--
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.
