Separating configs from WAR/EAR for Puppet deployments

Question

We do a lot of deployments of Java web applications to Weblogic and Jboss servers. Quite often the deployment looks like this:

1. Copy the code and default configs to a staging directory on the application server or Weblogic admin server.

2. Edit a properties file to set environment-specific variables (IP addresses, usernames, etc.)

3. Run ant to create the ear/war and drop it in the appropriate directory.

4. Start services

This has proven to be a very unfriendly set of steps to use with Puppet as our configuration management tool. We would prefer a process which is much more similar to the Package, File, Service trifecta of Puppet, but having to configure the properties before building the ear/war makes this difficult because it requires an extra step to build the war/ear on the host after the properties have been populated.

Is there a way to build a war/ear which is environment-agnostic and keep the configurations external, removing the extra build step?

Has anyone specifically worked with web applications and Puppet, and do you have any recommendations?

Answer 1

What I've done with tomcat and .war webapps is build a system package with an unzipped war and then deal with the conf files. I haven't dealt with Weblogic much or JBoss at all, so I don't know how it deals with unzipped WAR stuff.

1) Build a package (RPM) where I do all the .war building stuff, then something like:

mkdir -p %{buildroot}/var/lib/tomcat5/webapps/APP
cd %{buildroot}/var/lib/tomcat5/webapps/APP
unzip ../APP.war
rm ../APP.war

(so that the unzipped .war file is in the package with no actual .war file in there. With tomcat it will then leave that directory alone, especially if it doesn't have write access because the files belong to root)

2) Puppet stuff somewhat like:

package {
  "tomcat5":
    require => Package["java-1.6.0-sun"],
    ensure => installed;
  "java-1.6.0-sun":
    ensure => installed;
  "APP":
    ensure => installed,
    notify => Service["tomcat5"],
    require => Package["java-1.6.0-sun"];
}

file {
  "/usr/share/tomcat5/webapps/APP":
    source  => [ "puppet:///MODULE/APP" ],
    ensure  => directory,
    ignore  => [ 'CVS', '.git', '.svn', '*~' ], # ignore revision control and backup files
    purge   => false, # leaves other stuff alone
    replace => true, # replaces stock files with ours
    recurse => true, # gets everything recursively
    require => Package[APP], # install package first
    notify  => Service[tomcat5]; # restart tomcat after
}

This particular package has 32 files in 8 directories that we're modifying or pushing out to configure it. If it was just a few files, I'd use a couple simple file{} resources to manage those files instead of the recursive stuff.

If you didn't want to build a system type package, you could do a file{} resource for the war into an alternate directory, an exec{"unzip ...": creates => '/path/to/unzipped/webapp;} and have the file{} resources for configuration require the Exec["unzip ..."].