Separating configurations from WAR / EAR for Puppet deployment

We do many deployments of Java web applications on Weblogic and Jboss servers. Quite often, the deployment is as follows:

  • Copy the default code and configurations to the staging directory on the application server or Weblogic administration server.

  • Edit the properties file to set environment variables (IP addresses, usernames, etc.)

  • Run ant to create an ear / war and drop it into the appropriate directory.

  • Start service

This turned out to be a very unfriendly set of steps to use with Puppet as our configuration management tool. We would prefer a process that is much more like a package, file, trifecta service from Puppet, but it is difficult to set properties before creating an ear / war, because it requires an additional step to build a war / ear on the host after The properties have been filled.

Is there a way to build a war / ear, which is an agnostic of the environment and save external configurations by removing the extra build step?

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

+4
source share
1 answer

What I did with tomcat and .war webapps is to create a system package with an unpacked war, and then process the conf files. I havenโ€™t dealt with Weblogic or JBoss at all, so I donโ€™t know how this relates to the WAR deployable topic.

1) Create a package (RPM) where I make all the building materials .war, and 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 the unzipped .war file is in the package without the actual .war file there. Using tomcat, it will leave this directory separately, especially if it does not have write permission, because the files are owned by root)

2) The doll material is somewhat reminiscent of:

 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 contains 32 files in 8 directories, which we modify or pop to configure it. If it were just a few files, I would use a couple of simple file{} resources to manage these files instead of recursive material.

If you do not want to create a system-type package, you can make the file{} resource for war in an alternative directory, exec{"unzip ...": creates => '/path/to/unzipped/webapp;} and have the resources file{} for configurations requiring Exec["unzip ..."] .

+4
source

Source: https://habr.com/ru/post/1384292/


All Articles