Einmal bitte Tomcat oder zweimal oder dreimal…

tomcatHeute möchte ich euch ein Puppet-Modul zur Installation und Konfiguration von Tomcat vorstellen. Es verwaltet entweder einen Standalone Tomcat-Server oder aber eine Vielzahl von Server-Instanzen, z.Z. jedoch lediglich auf Red Hat Systemen. Mit einem

# puppet module install lbetz/tomcat

installieren wir das Module auf unserem Puppet-Server, respektive auf unserem Test-System. Mit folgendem Puppet Code wird aus den konfigurierten Repositories eine Tomcat 6 installiert und für den Multi-Instanz-Betrieb konfiguriert.

class { 'tomcat':
   version => '6',
}

Die einzelnen Instanzen bzw. deren Konfiguration sind standardmäßig unter /var/tomcat zu finden. Der Übersichtlichkeit in diesem Blog geschuldet, definieren wir uns einige Variablen, zuerst für die von uns verwendeten Connectors, Listeners und Resources.

$connectors = {
   'http' => {
      port => '8080',
      protocol => 'HTTP/1.1',
   },
   'ajp' => {
      port => '8009',
      protocol => 'AJP/1.3',
   },
}
$listeners = {
   'org.apache.catalina.core.AprLifecycleListener' => { 'ssl_engine' => 'On', },
   'org.apache.catalina.core.JasperListener' => {},
   'org.apache.catalina.core.JreMemoryLeakPreventionListener' => {},
   'org.apache.catalina.mbeans.GlobalResourcesLifecycleListener' => {},
}
$resources = {
  'UserDatabase' => {
     'auth' => 'Container',
     'type'        => 'org.apache.catalina.UserDatabase',
     'extra_attrs' => {
        'description' => 'User database that can be updated and saved',
        'factory'     => 'org.apache.catalina.users.MemoryUserDatabaseFactory',
         'pathname'    => 'conf/tomcat-users.xml',
      },
   },
}

Als nächstes definieren wir uns ein Hostobjekt localhost und mit diesem als Default Host eine Engine der Bezeichnung Catalina.

$hosts = {
   'localhost' => {
      'app_base'            => 'webapps',
      'unpack_wars'         => true,
      'auto_deploy'         => true,
      'xml_validation'      => false,
      'xml_namespace_aware' => false,
   },
}
$engine = {
   'Catalina' => {
      'default_host' => 'localhost',
      'realms'       => {
         'org.apache.catalina.realm.LockOutRealm' => {
         'realms' => {
            'org.apache.catalina.realm.UserDatabaseRealm' => {
               'attrs' => {
                  'resource_name' => 'UserDatabase',
               },
            },
         },
      },
      hosts = $hosts,
   },
}

Die eigentlich Instanz mayapp1 lässt sich nun wie folgt deklarieren:

tomcat::server { 'myapp1':
   ensure   => 'running',
   enable   => false,
   port     => '8005',
   services => {
      'Catalina' => {
         'connectors' => $connectors,
         'engine'     => $engine,
      },
   },
   resources => $resources,
   listeners => $listeners,
}

Mit dem zusätzlichen Parameter java_home ließe sich auch eine alternative Java Engine wählen.
Möchte man nun einen weiteren Host der Engine hinzufügen, kann natürlich der Hash $hosts entsprechend erweitert werden oder wie hier nachträglich deklarieren:

tomcat::host { 'myapp1:Catalina:Catalina:shop.netways.de':
  $app_base            => 'webapps',
  $auto_deploy         => true,
  $unpack_wars         => true,
  $xml_validation      => false,
  $xml_namespace_aware => false,
}

Über den Resource-Titel wird hier der XML-Pfad in der server.xml angegeben. Damit wird in diesem Beispiel der Host shop.netways.de der Instanz myapp1 zugeordnet und dort wiederum der Engine Catalina, die zum Service Catalina gehört. Äquivalent lassen sich auch andere Konfigurationsobjekte wie Services und Realms hinzufügen .
Für den Standalone-Betrieb, wenn man nicht mehrere Instanzen benötigt, reicht folgende Deklaration:

class { 'tomcat':
   version => '6',
   config  => {
      port     => '8005',
      services => {
         'Catalina' => {
            'connectors' => $connectors,
            'engine'     => $engine,
         },
      },
      resources => $resources,
      listeners => $listeners,
   }
}

War-Dateien können nun im Nachgang via File-Resource in die entsprechenden Ordner gelegt werden, danach ist dann nur noch ein notify auf den Tomcat-Service nötig. Im Standalone-Betrieb ist dieses z.Z. jedoch noch an Tomcat::Server[‘tomcat6’] bzw. Tomcat::Server[‘tomcat’] (Version 7) zu senden.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 Entwicklungsstand 2014 – Webinar Reminder

logo_icinga3Morgen früh um 10:30 Uhr beginnt das letzte Webinar vor der CeBIT. Diesmal wollen wir auf das neue Icinga 2 eingehen und alle bisher vorgenommenen Änderungen der Milestones ansprechen.
Im Webinar werden wir einige Grundkonfigurationen kennenlernen, bis hin zur Einrichtung eines Clusters von zwei Nodes. Natürlich wollen wir im selben Schritt auf einige Unterschiede zu Nagios / Icinga eingehen und die Roadmap für Version 0.0.8 präsentieren.
Wer noch daran teilnehmen möchte, kann sich über unsere Webinarseite registrieren.
Eine Aufzeichnung des Webinars und die gezeigte Präsentation wird anschließend in unserem Webinar-Archiv online gestellt.
Cebit BlogWer Icinga 2 näher betrachten möchte, kann sich entweder über unser Kontaktformular bei uns melden oder uns auf der CeBIT im Open Source Park, Halle 6, an Stand E16 (310) besuchen. Um uns schneller zu finden, gibt es natürlich auch eine Wegbeschreibung.
Bis morgen im Webinar!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".