Seite wählen

Einmal bitte Tomcat oder zweimal oder dreimal…

von | Aug 15, 2014 | Web Services, DevOps, Puppet

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.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Web Services | DevOps | Puppet

Kritischer Fehler in Puppet Version 7.29.0 und 8.5.0

Eine Warnung an alle Nutzer von Puppet, aber auch Foreman oder dem Icinga-Installer, die Version 7.29.0 und 8.5.0 von Puppet enthält einen kritischen Fehler, der die Erstellung eines Katalogs und somit die Anwendung der Konfiguration verhindert. Daher stellt bitte...

CfgMgmtCamp 2024: Unser Rückblick

Vergangene Woche fuhr ein Teil unseres Teams bei NWS bis nach Ghent in Belgien, um am ConfigManagementCamp 2024 teilzunehmen. Hierbei handelt es sich um eine kostenlose Konferenz, direkt im Anschluss an die FOSDEM, was Jahr für Jahr für ein großes Publikum aus Fans...

Effektive Zugriffskontrolle für GitLab Pages

Grundlagen von GitLab Pages GitLab Pages sind eine facettenreiche Funktion, die es ermöglicht, statische Webseiten direkt aus einem GitLab-Repository heraus zu hosten. Diese Funktionalität eröffnet eine breite Palette von Anwendungsmöglichkeiten, von der Erstellung...