Trennen von Konfigurationen von WAR / EAR für Puppet-Bereitstellungen

Question

Wir führen viele Bereitstellungen von Java-Webanwendungen auf Weblogic- und Jboss-Servern durch. Sehr oft sieht die Bereitstellung folgendermaßen aus:

1. Kopieren Sie den Code und die Standardkonfigurationen in ein Staging-Verzeichnis auf dem Anwendungsserver oder dem Weblogic-Administrationsserver.

2. Bearbeiten Sie eine Eigenschaftendatei, um umgebungsspezifische Variablen (IP-Adressen, Benutzernamen usw.) festzulegen.

3. Führen Sie ant aus, um das Ohr / den Krieg zu erstellen, und legen Sie es im entsprechenden Verzeichnis ab.

4. Dienste starten

   Dies hat sich als sehr unfreundlich erwiesen, um Puppet als unser Konfigurationsmanagement-Tool zu verwenden. Wir würden einen Prozess bevorzugen, der dem Trifecta Package, File, Service von Puppet viel ähnlicher ist, aber die Eigenschaften vor dem Erstellen des Ohrs / Krieges konfigurieren zu müssen, macht dies schwierig, da ein zusätzlicher Schritt erforderlich ist, um den Krieg / das Ohr auf dem zu erstellen Host, nachdem die Eigenschaften ausgefüllt wurden.

   Gibt es eine Möglichkeit, ein Krieg / Ohr zu erstellen, das umweltunabhängig ist und die Konfigurationen extern hält, wodurch der zusätzliche Build-Schritt entfernt wird?

   Hat jemand speziell mit Webanwendungen und Puppet gearbeitet und haben Sie Empfehlungen?

Answer 1

Was ich mit Tomcat und .war-Webanwendungen gemacht habe, ist, ein Systempaket mit einem entpackten Krieg zu erstellen und dann mit den conf-Dateien umzugehen. Ich habe mich nicht viel mit Weblogic oder JBoss beschäftigt, daher weiß ich nicht, wie es mit entpacktem WAR-Zeug umgeht.

1) Erstellen Sie ein Paket (RPM), in dem ich alle .war-Erstellungsaufgaben erledige, dann etwa:

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

(damit sich die entpackte .war-Datei im Paket befindet und keine tatsächliche .war-Datei darin enthalten ist. Mit tomcat wird dieses Verzeichnis dann in Ruhe gelassen, insbesondere wenn es keinen Schreibzugriff hat, da die Dateien zum Stammverzeichnis gehören)

2) Marionettenmaterial wie:

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
}

Dieses spezielle Paket enthält 32 Dateien in 8 Verzeichnissen, die wir ändern oder veröffentlichen, um es zu konfigurieren. Wenn es nur ein paar Dateien wären, würde ich ein paar einfache file{}-Ressourcen verwenden, um diese Dateien anstelle des rekursiven Materials zu verwalten.

Wenn Sie kein Systemtyp-Paket erstellen möchten, können Sie eine file{}-Ressource für den Krieg in einem alternativen Verzeichnis, einem exec{"unzip ...": creates => '/path/to/unzipped/webapp;}, erstellen und die file{}-Ressourcen für die Konfiguration benötigen den Exec["unzip ..."].