GSB 7.0 Standardlösung

Springe direkt zu:

Zielgruppe BetriebVersion: GSB10.0Architektur und Komponenten

Dieser Artikel bietet einen allgemeinen Überblick über den Aufbau des GSB und stellt insbesondere Begrifflichkeiten und Komponenten vor, die im späteren Verlauf der Installationsanleitung wieder aufgegriffen werden, wenn die konkrete Installation und Konfiguration einzelner GSB Komponenten beschrieben werden.

Dieser Abschnitt stellt die Komponenten und eingesetzten Begrifflichkeiten eines GSB-Release bzw. –Installation vor.

Die in den folgenden eingeführten Begrifflichkeiten und graphischen Darstellungen stellen eine „vereinfachte“ Infrastruktur dar, die aus folgenden Teilaspekten bestehen:

  • Infrastrukturkomponenten
  • Web-Applikationen
  • Service-Typen
  • Service-Instanzen
  • Runtime-Konfigurationen

serviceInstance serviceInstance GSB Komponentenaufbau

Service-Typ

Die GSB Komponenten bestehen im Wesentlichen aus Webapplikationen, die in einem Tomcat basierten Servlet Container betrieben werden. Als weitere Komponente nutzt der GSB noch einen Webserver, der für das Routing der http-Requests der Nutzer zu den angebundenen Tomcat-Servern verantwortlich ist.

Innerhalb einer GSB Infrastruktur werden verschiedene Tomcat- und Webserver-Instanzen betrieben, die z.T. die gleichen Dienste bereitstellen. So sind bspw. alle Delivery-Server von der benötigten GSB Software her gleich aufgebaut, so dass der GSB einen Mechanismus bereitstellt, um gleichartige Instanzen einfacher handhaben zu können.

Eine solche Vorlage für den Betrieb einer Tomcat- bzw. Webserver-Instanz wird als Service-Typ bezeichnet. Ein Service-Typ umfasst somit alle GSB spezifischen SW-Komponenten die für den Betrieb eines bestimmten Serverdienstes benötigt werden.

Folgende Service-Typen sind aktuell definiert:

  • Service-Tomcat mit Web-Applikationen (indexer, eventdispatcher)
  • Repository-Tomcat mit Web-Applikationen (repository, replication)
  • Delivery-Tomcat mit Web-Applikation (site)
  • Solr-Tomcat mit Web-Applikation (solr)
  • Workflow-Tomcat mit Web-Applikation (workflow)
  • Editor-Tomcat mit Web-Applikation (editor)
  • Adminportal-Tomcat mit Web-Applikation (liferay, adminportal, serviceportal)
  • Maildistributor-Tomcat mit Web-Applikation (maildistributor)
  • Cas-Tomcat mit Web-Applikation (cas)
  • Httpd (Webserver-Konfiguration)

D.h. der Service-Typ Repository enthält die Webapplikationen Repository und Replication. Dieser Service-Typ kann genutzt werden, um alle Repository Tomcat-Instanzen einer Hosting Plattform zu betreiben (Preview-, Master- und Replication-Repository).

Der Service-Typ Delivery enthält nur die Webapplikation Delivery und kann auf einer Hosting Plattform für den Betrieb aller Delivery Tomcat-Instanzen genutzt werden.

Ähnliches gilt für die restlichen Service-Typen der obigen Liste.

Der prinzipielle Aufbau eines Tomcat basierten Service-Typen wird anhand des Repository skizziert:

serviceType serviceType GSB Service-Typ Repository


Der Aufbau des Repository Service-Typs im Filesystem ist wie folgt:

  • conf: Der conf-Ordner enthält alle für den Tomcat benötigten Konfigurationsdateien wie server.xml u. web.xml
  • lib: Der lib-Ordner beinhaltet global benötigte Bibliotheken. Hierzu zählt bspw. die Jackrabbit-API
  • webapps: Alle Webapplikationen des Service-Typs werden unterhalb des webapps-Ordners gespeichert Die eigentliche Tomcat-Server Software ist nicht Bestandteil des Service-Typs und wird gesondert auf einem Server bereitgestellt (s.a. Abschnitt "Tomcat-Server“).

Der prinzipielle Aufbau des Service-Typ httpd kann der folgenden Grafik entnommen werden.

serviceTypeHttpd serviceTypeHttpd GSB Service-Typ httpd

Der Aufbau des httpd Service-Typs im Filesystem ist wie folgt:

  • ~gsbos/releases/core/10.0.0-SNAPSHOT/httpd/conf/include: Der include-Ordner enthält Konfigurationsdateien, welche die zu verwendenden Konfigurationen includiert.
  • ~gsbos/releases/core/10.0.0-SNAPSHOT/httpd/conf/macro: Der macro-Ordner enthält GSB spezifische Macro-Definitionen die für die Virtual-Host-Definitionen benötigt werden.
  • ~gsbos/releases/core/10.0.0-SNAPSHOT/httpd/conf/variables: Der variables-Ordner enthält die Variablen-Definitionen die in verschiedenen Konfigurationsdateien (z.B. Balancer) benötigt werden. Diese Variablen können über die Runtime jederzeit überschrieben werden. Somit ist die Apache-Konfiguration sehr flexibel.
  • ~gsbos/releases/customers/<CUSTOMER_NAME>/<CUSTOMER_VERSION>/httpd/conf/vhosts: Der vhosts-Ordner enthält alle Virtual-Hosts-Definitionen der zu betreibenden GSB Mandanten Die eigentliche httpd-Server Software ist nicht Bestandteil des Service-Typs und wird gesondert auf einem Server bereitgestellt (s.a. Abschnitt „Httpd-Server“).

Service-Instanz

Die im vorherigen Kapitel vorgestellten "Service-Typen" stellen wie skizziert eine Art Schablone bzw. Vorlage für den Betrieb einer GSB Prozessinstanz dar. Eine solche Prozessinstanz wird im GSB Kontext als Service-Instanz bezeichnet.

Bei einer Service-Instanz handelt es sich somit um einen lauffähigen bzw. laufenden GSB Prozess. D.h. eine Service-Instanz umfasst sowohl den zugrundeliegenden Service-Typ (GSB Software) als auch die Runtimekonfiguration die für den Betrieb des jeweiligen Serverdienstes benötigt wird.

Der prinzipielle Aufbau eine Tomcat basierten Service-Instanz wird anhand des Repository skizziert:

serviceInstanceRepository serviceInstanceRepository GSB Service-Instanz Repository

Der Aufbau einer Repository Service-Instanz im Filesystem ist wie folgt:

  • /opt/software/tomcat/default: Beinhaltet die für den Betrieb der GSB Tomcat basierten Service-Instanzen benötigten Tomcat-Server sowie globale Bibliotheken. Details zur Tomcat-Installation können dem Kapitel „Tomcat-Server“ entnommen werden.
  • /opt/gsbos/software/respository: Dieser Ordner enthält die Installation des Repository Service-Typs
  • /opt/gsbos/runtime/repository-preview: Der Ordner beinhaltet die Runtime-Konfiguration des Preview-Repositories. Jede Service-Instanz verfügt über eine individuelle Runtime-Konfiguration, so dass die Runtime-Konfiguration weiterer Repository Service- Instanzen jeweils in dedizierten Orndern abgelegt werden.
  • /usr/java/default: Die für den Start des Tomcat-Servers benötigte Java-Runtime

Bei einem Start einer Service-Instanz müssen die oben skizzierten Verzeichnisse „zusammengebracht“ werden, um einen erfolgreichen Start durchführen zu können. Der Start der GSB Service-Instanzen wird mit Hilfe bzw. unter Kontrollen von Systemd durchgeführt, so dass für jeden Service-Typen entsprechende Systemd Service-Units vorhanden sein müssen. Die Repository Service-Unit findet sich in der Datei /etc/systemd/system/repository@.service und definiert eine Reihe von Umgebungsvariablen die für den Start benötigt werden.

  • CATALINA_HOME referenziert auf den Ordner in dem der Tomcat-Server installiert ist (s.o.)
  • CATALINA_BASE referenziert auf den Installationsort des Service-Typs
  • config.prop.dir referenziert die Runtime-Konfiguration der Service-Instanz
  • JAVA_HOME referenziert den Installationsordner der Java-Runtime Der Start einer Service-Instanz wird dann mit dem Systemd-Kommando systemctl durchgeführt.

Mit Hilfe des Kommandos systemctl start repository@repository-preview wird bspw. die Service-Instanz repository-preview des Service-Typs repository gestartet. Details zum Starten und Stoppen finden sich im Kapitel „Starten/Stoppen der Komponenten“.

Kernrelease

Das GSB Kernrelease enthält alle Kernbestandteile die für den Aufbau und Betrieb einer GSB Infrastruktur benötigt werden. Das Kernrelease wird als Sammlung von Artefakten zur Verfügung gestellt, wobei jeweils logisch und funktional zusammengehörige Artefakte in einem Artefaktverzeichnis bereitgestellt werden. Der GSB Kern enthält die folgenden Artefakte:

  • Httpd beinhaltet alle GSB Kernkomponenten die für die Installation u. den Betrieb eines httpd-Webservers benötigt werden.
  • Infrastructure enthält Skripte und Konfigurationsdateien für die Installation der GSB Komponenten (Service-Typen)
  • Tomcat enthält GSB spezifische Konfigurationsdateien u. globale Bibliotheken für den Tomcat-Server
  • Webapplikationen alle anderen Ordner des Kernrelease enthalten jeweils eine gleichnamige GSB Webapplikation

Die Verzeichnis- und Dateistruktur eines Artefaktes ist so aufgebaut, dass eine Installation im Prinzip durch Kopie des Artefakt-Ordners in das gewünschte Installationsverzeichnis durchgeführt werden kann.

Mandantenrelease

Ein Mandantenrelease ist von seiner Struktur her ähnlich aufgebaut wie ein Kernrelease. D.h. ein Mandantenrelease enthält einen Auszug der Kernartefakte. Ein Mandantenrelease enthält nicht alle Kernartefakte, da nicht jeder Mandant mandantenspezifische Implementierungen für die GSB Webapplikationen enthält.

Die Verzeichnis- und Dateistruktur eines Mandanten-Artefaktes ist analog zum Kernartefakt aufgebaut, dass eine Installation im Prinzip durch Kopie des Artefakt-Ordners in das gewünschte Installationsverzeichnis durchgeführt werden kann.

Platform-Bundle

Die in den beiden vorherigen Kapiteln vorgestellten Kern- und Mandanten-Releases müssen zusammengebracht werden, um eine lauffähige GSB Software bereitstellen zu können.

Das Kernrelease enthält die GSB Basisfunktionalitäten und die Mandantenreleases die auf einem Kern aufbauenden mandantenspezifischen Erweiterungen.

Die GSB Installation einer Hosting Plattform umfasst sowohl den GSB Kern als auch die gehosteten Mandanten. Die Zusammenfassung eines GSB Kernstandes mit den auf der Plattform benötigten Mandaten wird als Platformbundle bezeichnet.

Das Platformbundle enthält installationsfähige Artefakte der einzelnen Service-Typen. Details zum Erstellen der Platformbundle finden sich im Abschnitt „Erstellung des Platform-Bundles“. Die Installation der Service-Typen eines Platformbundle wird im Abschnitt „Installation des Platform-Bundles“ beschrieben.