Separazione delle configurazioni da WAR / EAR per le distribuzioni di Puppet

Question

Eseguiamo molte distribuzioni di applicazioni web Java su server Weblogic e Jboss. Molto spesso la distribuzione è simile a questa:

1. Copiare il codice e le configurazioni predefinite in una directory di staging sul server delle applicazioni o sul server di amministrazione di Weblogic.

2. Modifica un file delle proprietà per impostare variabili specifiche dell'ambiente (indirizzi IP, nomi utente, ecc.)

3. Esegui ant per creare ear / war e rilascialo nella directory appropriata.

4. Avvia i servizi

Questa si è rivelata una serie di passaggi molto ostili da usare con Puppet come strumento di gestione della configurazione. Preferiremmo un processo che è molto più simile a Pacchetto, File, Servizio trifecta di Puppet, ma dover configurare le proprietà prima di costruire l'orecchio / guerra lo rende difficile perché richiede un passaggio aggiuntivo per costruire la guerra / orecchio sul host dopo che le proprietà sono state popolate.

C'è un modo per costruire una guerra / orecchio che sia indipendente dall'ambiente e mantenere le configurazioni esterne, eliminando il passaggio di costruzione aggiuntivo?

Qualcuno ha lavorato specificatamente con applicazioni web e Puppet e hai qualche consiglio?

Answer 1

Quello che ho fatto con tomcat e .war webapps è stato creare un pacchetto di sistema con un war decompresso e quindi occuparmi dei file di configurazione. Non mi sono occupato molto di Weblogic o di JBoss, quindi non so come gestisca le cose di WAR decompresse.

1) Costruisci un pacchetto (RPM) in cui eseguo tutte le operazioni di costruzione di .war, quindi qualcosa come:

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

(in modo che il file .war decompresso sia nel pacchetto senza alcun file .war effettivo. Con tomcat lascerà quella directory da sola, specialmente se non ha accesso in scrittura perché i file appartengono a root)

2) Cose da marionette un po 'come:

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
}

Questo particolare pacchetto ha 32 file in 8 directory che stiamo modificando o estendendo per configurarlo. Se fossero solo pochi file, utilizzerei un paio di semplici risorse file{} per gestire quei file invece delle cose ricorsive.

Se non si desidera creare un pacchetto del tipo di sistema, è possibile creare una risorsa file{} per la guerra in una directory alternativa, un exec{"unzip ...": creates => '/path/to/unzipped/webapp;} e fare in modo che le risorse file{} per la configurazione richiedano il Exec["unzip ..."].