Separación de configuraciones de WAR / EAR para implementaciones de Puppet

Question

Realizamos muchas implementaciones de aplicaciones web Java en servidores Weblogic y Jboss. Muy a menudo, la implementación se ve así:

1. Copie el código y las configuraciones predeterminadas en un directorio de ensayo en el servidor de aplicaciones o en el servidor de administración de Weblogic.

2. Edite un archivo de propiedades para establecer variables específicas del entorno (direcciones IP, nombres de usuario, etc.)

3. Ejecute ant para crear el ear / war y colóquelo en el directorio apropiado.

4. Iniciar servicios

Este ha demostrado ser un conjunto de pasos muy poco amigables para usar con Puppet como nuestra herramienta de administración de configuración. Preferiríamos un proceso que sea mucho más similar al paquete, archivo, servicio trifecta de Puppet, pero tener que configurar las propiedades antes de construir el ear / war dificulta esto porque requiere un paso adicional para construir el war / ear en el host después de que se hayan completado las propiedades.

¿Hay alguna forma de construir un war / ear que sea independiente del entorno y mantenga las configuraciones externas, eliminando el paso de compilación adicional?

¿Alguien ha trabajado específicamente con aplicaciones web y Puppet, y tiene alguna recomendación?

Answer 1

Lo que he hecho con tomcat y .war webapps es crear un paquete de sistema con un war descomprimido y luego ocuparme de los archivos conf. No he tratado mucho con Weblogic o JBoss en absoluto, así que no sé cómo se ocupa de las cosas de WAR descomprimidas.

1) Cree un paquete (RPM) en el que hago todas las cosas de construcción de .war, luego algo como:

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

(para que el archivo .war descomprimido esté en el paquete sin ningún archivo .war real allí. Con tomcat dejará ese directorio solo, especialmente si no tiene acceso de escritura porque los archivos pertenecen a la raíz)

2) Cosas de marionetas como:

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
}

Este paquete en particular tiene 32 archivos en 8 directorios que estamos modificando o empujando para configurarlo. Si fueran solo unos pocos archivos, usaría un par de recursos simples de file{} para administrar esos archivos en lugar de las cosas recursivas.

Si no desea construir un paquete de tipo de sistema, puede convertir un recurso file{} para la guerra en un directorio alternativo, un exec{"unzip ...": creates => '/path/to/unzipped/webapp;} y hacer que los recursos file{} para la configuración requieran el Exec["unzip ..."].