Zielgruppe BetriebVersion: GSB10.1Architektur und Komponenten

Hinweis:
Es empfiehlt sich die Installation einer konkreten GSB 10 Version ausschließlich auf Basis und Grundlage der Konfigurationsdateien und Skripte der jeweiligen GSB Version durchzuführen, um Inkompatiblitäten zwischen verschiedenen GSB 10 Versionen auszuschließen. Dies gilt insbesondere für alle Bestandteile des infrastructure-Artefakts des GSB Kerns.

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
• GSB-Applikationen
• Service-Typen
• Service-Instanzen
• Runtime-Konfigurationen

GSB Komponentenaufbau

Service-Typ

Die GSB Komponenten und Applikationen sind als Java Applikation umgesetzt, die je nach Applikation entweder als Webapplikation oder als Standalone-Applikation betrieben werden. Die Webapplikationen werden in einem Tomcat basierten Servlet Container ausgeführt. 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 Instanzen einer GSB Applikation betrieben, die somit die gleichen Dienste bereitstellen. So sind bspw. alle Site-Server von der benötigten GSB Software her gleich aufgebaut. Der GSB stellt mit dem Konzept des Service-Typs einen Mechanismus bereit, um gleichartige Instanzen einfacher handhaben zu können.

Ein Service-Typ stellt somit quasi eine Schablone für eine GSB Applikation dar und umfasst alle GSB spezifischen SW-Komponenten die für den Betrieb eines bestimmten Serverdienstes benötigt werden.

Der GSB nutzt wie skizziert unterschiedliche Arten von GSB Applikationen. Ein Großteil ist als Standalone Java-Applikation umgesetzt, die restl. GSB Java-Applikationen werden in einem Tomcat-Server als Webapplikation betreiben.

Die im GSB eingesetzten Solr-Suchserver sowie der Apache Webserer werden vom Hersteller ausschließlich als Standalone-Applikation bereitgestellt und sind somit als weitere Service-Typ Art zu sehen ist.

Der GSB nutzt somit folgende Arten von Service-Typen:

• APPLICATION: Standalone GSB Applikation
• TOMCAT: Tomcat-Server basierte GSB Webapplikation
• SOLR: Solr-Suchserver
• HTTPD: Apache Httpd-Webserver

Eine Übersicht über die vorhandenen GSB Service-Typen und eine Zuordnung der Art und der jeweils enthaltenen GSB Applkation finden Sie in folgender Tabelle:

Im GSB-Kern definierte Service-Typen

Name	Art	Komponenten
repository	APPLICATION	repository
site	TOMCAT	tomcat, site
solr	SOLR	solr
workflow	APPLICATION	workflow
editor	TOMCAT	tomcat, editor
adminportal	TOMCAT	tomcat, liferay, adminportal
serviceportal	APPLICATION	serviceportal
maildistributor	APPLICATION	maildistributor
cas	APPLICATION	cas
httpd	HTTPD	httpd
userservice	APPLICATION	userservice
eventdispatcher	APPLICATION	eventdispatcher
indexer	APPLICATION	indexer
cmis-server	APPLICATION	cmis-server
cmis-client	APPLICATION	cmis-client
gsbshell	APPLICATION	gsbshell

Im Folgenden werden die vier unterschiedlichen Arten jeweils an exemplarischen Beispielen erläutert.

Service-Typ Repository (Art APPLICATION)

Das GSB Repository wird als Standalone Java-Applikation betrieben und hat somit folgenden schematischen Aufbau.

GSB Service-Typ Repository

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

• bin: Der bin-Ordner enthält das Startskript zum Starten der jeweiligen Applikation. Das Startskript heißt so wie der Service-Typ (repository im skizzierten Beispiel).
• lib: Der lib-Ordner enthält alle benötigten Bibliotheken. Der Datenbanktreiber für die Anbindung einer Datenbank ist in dem applikationsspezifischen lib-Ordner nicht enthalten, da die Datenbank als Beistellung durch den Systembetrieb bereitgestellt werden muss.
• logback-spring.xml: Die Logback-Konfiguration liegt direkt im Wurzelordner der Applikation, um bei Bedarf eine schnelle Änderung zu ermöglichen.

Service-Typ Site (Art TOMCAT)

Die GSB Site-Application ist für die Generierung von HTML-Seiten zuständig und wird als Webapplikation in einem Tomcat-Server betrieben.

Der Aufbau des Site 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.

Service-Typ Solr (Art SOLR)

Der Solr-Server stellt den eigentlichen Suchdienst zur Verfügung. Der Standard Solr-Server wird durch den Service-Typen um die notwendige GSB spezifische Konfiguration erweitert. Der Service-Typ hat somit folgenden schematischen Aufbau.

GSB Service-Typ Solr

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

• bin: Der bin-Ordner enthält das Startskript `solr.in.sh`zum Starten des Solr-Servers.
• configsets: Der configset-Ordner enthält alle mandantenspezifischen Solr-Konfigurationen.
• master: Der master-Ordner enthält die Solr Master-Server-Konfiguration
• replication: Der replication-Ordner enthält die Solr Replication-Server-Konfiguration
• preview: Der preview-Ordner enthält die Solr Server-Konfiguration für die Redaktionsumgebung

Service-Typ Site (Art HTTPD)

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

GSB Service-Typ httpd

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

• ~gsbos/releases/core/10.1.0-rc4/httpd/conf/include: Der include-Ordner enthält Konfigurationsdateien, welche die zu verwendenden Konfigurationen includiert.
• ~gsbos/releases/core/10.1.0-rc4/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.1.0-rc4/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.

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.

Service-Instanz Repository Redaktionsumgebung

Der prinzipielle Aufbau einer Stanalone Applikation des Repositories skizziert:

GSB Service-Instanz Repository

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

• /opt/gsbos/lib: Beinhaltet die für den Betrieb der GSB Applikation benötitgten Datenbanktreiber. In diesem Ordner können weitere Bibliotheken abgelegt weden, die durch den jeweiligen Plattformbetreiber benötigt werden (bspw. Jolokia). Details zur Installation können dem Kapitel „Standalone-Applikation“ entnommen werden.
• /opt/gsbos/software/repository: Dieser Ordner enthält die Installation des Repository Service-Typs
• /opt/gsbos/runtime/repository-preview: Der Ordner beinhaltet die Runtime-Konfiguration des Repositories der Redaktionsumgebung. 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 der Applikation 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 Site Service-Unit findet sich in der Datei /etc/systemd/system/site@.service und definiert eine Reihe von Umgebungsvariablen die für den Start benötigt werden.

• GSB_SOFTWARE_DIR referenziert auf den Installationsort des Service-Typs
• GSB_LIB_DIR referenziert auf den Ordner in dem die globalen Bibliotheken abgelegt werden (s.o.)
• GSB_RUNTIME_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“.

Service-Instanz Site Redaktionsumgebung

Der Aufbau einer Site 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/site: Dieser Ordner enthält die Installation des Site Service-Typs
• /opt/gsbos/runtime/site1-preview: Der Ordner beinhaltet die Runtime-Konfiguration des ersten Site-Servers der Redaktionsumgebung. Jede Service-Instanz verfügt über eine individuelle Runtime-Konfiguration, so dass die Runtime-Konfiguration weiterer Site 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 Site Service-Unit findet sich in der Datei /etc/systemd/system/site@.service und definiert eine Reihe von Umgebungsvariablen die für den Start benötigt werden.

• CATALINA_BASE referenziert auf den Installationsort des Service-Typs
• CATALINA_HOME referenziert auf den Ordner in dem der Tomcat-Server installiert ist (s.o.)
• 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 site@site1-preview wird bspw. die Service-Instanz site1-preview des Service-Typs site 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
• liferay enthält den Liferay Portalserver, der für den Betrieb des Adminportals benötigt wird.
• documentation enthält die mit dem Release bereitgestellte Html-Dokumentation
• bei den restl. Artefakten handelt es sich jeweils um die gleichnamige GSB Applikation.

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.

nach oben