Der Einsatz von Public Cloud-Plattformen wie Amazon Web Services (AWS) für die Implementierung von OpenText Documentum-basierten ECM-Umgebungen wird oft kritisch gesehen. Es gibt jedoch eine ganze Reihe von Punkten, die für ihre Verwendung sprechen. Tatsächlich hängt es vom Umfang der zu erstellenden Umgebung ab, welche Daten dort verarbeitet werden und wie tief AWS in das eigene Netzwerk integriert werden soll. Dieser Blogbeitrag soll helfen, Antworten auf diese Fragen zu finden und eine erste Basisumgebung auf der AWS-Plattform bereitzustellen.

Der erste Schritt besteht darin zu definieren, wie eine OpenText Documentum Basisumgebung aussehen kann. Der obligatorische Content-Server enthält einen Connection Broker, den Java Method Server (JMS) und ein Repository. Dies ist das Standardlayout und wird von uns nicht verändert. Das Repository benötigt eine File-Share und ein Datenbankschema. In den Frontends gehen wir einen Schritt weiter als nötig. Grundsätzlich genügt ein Documentum Administrator (DA) für den Zugriff und die Verwaltung der Umgebung. Um es ein wenig flexibler zu machen, werden wir auch einen Webtop und die Rest Services einbinden. Mit anderen Komponenten wie z.B. der Volltextindizierung werden wir uns im Rahmen dieses Blogeintrags nicht befassen. Alles in allem sieht unser Layout für die Grundinstallation so aus:

Image 1: Basislayout

Man kann versuchen, die Infrastrukturelemente auf EC2-Servern auf herkömmliche Weise zu installieren oder mit Lift & Shift von vorhandener Hardware auf die AWS-Plattform zu übertragen. Dies wäre allerdings für unser Vorhaben ein wenig zu kurzgefasst. Gerade in Hinblick auf die Sicherheit und den Einsatzzweck des Systems sind einige Dinge zu beachten. Zum einen ist die Documentum Umgebung innerhalb von AWS einzubetten und zum anderen die Zugriffe von außen zu kontrollieren. Wir werden der Einfachheit halber mit der Grundstruktur für eine einzelne Stage arbeiten.

Mit dem Release 7.3 wurden Container für die wichtigsten Komponenten eines Documentum Systems offiziell eingeführt und werden seitdem vom Hersteller direkt zur Verfügung gestellt und unterstützt. Für unsere aufzubauende Documentum Umgebung nutzen wir in diesem ersten Schritt keine speziellen Services von AWS wie z.B Elastic Container Service (ECS) oder den Kubernetes Service (EKS). Stattdessen nutzen wir Docker auf Linux EC2 Servern. Diese Konstellation wurde gewählt, da sie deutlich einfacher aufzusetzen ist und wir für unsere Umgebung keine aktiven Cluster- oder Load-Balancing-Mechanismen nutzen wollen. Vom Hersteller selber nutzen wir nur das Docker-Paket für den Content Server im Relase 16.4. Die Docker Container für die anderen drei Produkte Rest-API, Administrator und Webtop lassen sich relativ einfach selber erzeugen und erlauben uns unsere eigene interne Struktur zu nutzen.

Zusätzlich zu den vier Documentum Produkten werden wir auch die Datenbank selber in einem Container bereitstellen. Hierzu nutzen wir PostgreSQL, welche auf einem dedizierten Server betrieben wird. Alternativ kann auch der Relational Database Service (RDS) von AWS genutzt werden, welcher die PostgreSQL als Managed Service zu Verfügung stellt. Aufgrund der geringen Anforderungen an die Datenbank in Bezug auf unsere Umgebung, haben wir uns allerdings für die selbstverwaltete Variante entschieden, da diese deutlich günstiger ist. Zusätzlich zur Datenbank wird eine File-Share benötigt, um die inhaltlichen Dateien im Repository abzulegen. Wir haben uns für AWS S3 entschieden, welches seit Release 16.4 von Documentum unterstützt wird.

AWS Infrastruktur

Für das einfache Testszenario haben wir uns entschieden, einen VPC mit einem privaten Subnetz für die Datenbank und einem öffentlichen für den Content-Server sowie die Frontend-Services zu erstellen. Damit die Datenbankinstanz Updates empfangen kann, haben wir zusätzlich einen NAT-Gateway konfiguriert und das entsprechende Routing in die Routentabelle des privaten Subnetzes aufgenommen. Nach der Erstellung des VPCs haben wir die Security Groups für die Datenbankinstanz so konfiguriert, dass sie von dem VPC ausgehende Verbindungen auf den Ports 22 und 5432 akzeptiert. Die Security Group für den Content-Server lässt alle Verbindungen auf den Ports 22, 1689, 50000 und 9080 sowie den gesamten ICMP-iPv4-Verkehr zu. Die letztgenannte Regel ist wichtig, da der von OpenText bereitgestellte Docker-Container so konfiguriert ist, dass er die IP-Adresse des Host-Rechners durch Ping überprüft und nicht startet, wenn dieser Ping-Check fehlschlägt. Es wurde auch eine Security Group für die Frontend-Komponenten konfiguriert, die die Ports 22 und 8080 freigeben.

Abbildung 2: AWS Infrastruktur

Einrichten von Docker und Docker-Compose

Nach Fertigstellung der benötigen Infrastruktur in AWS haben wir eine t2.small EC2-Instanz mit dem Red Hat Enterprise Linux AMI in das private Subnetz für die Datenbank und eine t2.large EC2-Instanz mit dem gleichen AMI in das öffentliche Subnetz für den Content-Server integriert. Der letzte wurde auch als Jump-Host für den Zugriff auf die Datenbankinstanz verwendet. Docker und Docker-Compose ist mit den folgenden Befehlen zu installieren:

Konfiguration der Datenbank

Damit der “ec2-Benutzer” zur Docker-Gruppe hinzugefügt werden kann, müssen wir die Verbindung zur Instanz einmal trennen und direkt wiederherstellen. Anschließend können kann die Installationsdatei “postgres.yml” mit den folgenden Daten erstellt werden:

In den letzten Schritten haben wir den Container für die Datenbank mit Docker-Compose gestartet und anschließend die vom Content-Server benötigten Ordner angelegt:

Konfiguration des Content Servers

Nun ist die Datenbank fertig und wir können mit der Konfiguration der Content-Server-Instanz und des zugehörigen Containers fortfahren. Nach der in der Dokumentation beschriebenen Installation von Docker und Docker-Compose für die Datenbank, kopieren wir die von OpenText bereitgestellte Datei „contentserver_docker_centos.tar“ in die neue Instanz und extrahieren den Inhalt daraus. Im nächsten Schritt wird die benötigte Tar-Datei “Contentserver_Centos.tar” erstellt und in Docker geladen. Zum Schluss wird die von OpenText bereitgestellte Yaml-Datei “CS-Docker-Compose_Stateless.yml” an die jeweiligen Bedürfnisse der einzurichtenden Umgebung angepasst. Hier werden Passwörter und andere Einstellungen für das Repository gespeichert.

Stolperfallen beim Content-Server-Container
Aufgrund der Komplexität des Content-Servers sowie der Verwendung verschiedener Technologien wie Bash, Java, etc. kann die initiale Konfiguration des Repositories, welches beim ersten Start des Containers durchgeführt wird, an folgenden Ursachen scheitern:

1. Das Fehlen des Ordners db_{docbase}_dat.dat im Datenbank-Container.
2. Der Container für die Datenbank oder der Container für den Content-Server selbst verwendet ein Mapping auf einen vorhandenen Ordner des entsprechenden Hosts wie “opt/dctm/data:/opt/dctm/data”. In diesem Fall führt eine der nicht bash-fähigen Komponenten des Content-Server-Installers die notwendigen Schreiboperationen nicht durch. Dieses Problem tritt nicht auf, wenn alle zum Betrieb benötigten Ordner von Docker-Compose erstellt werden, indem sie im Volume-Bereich der Yaml-Datei aufgelistet werden.
3. Es gibt Dateien, die durch eine fehlgeschlagene Installation im Dateisystem der Datenbank oder des Content-Server-Containers erzeugt wurden. Dieses Problem kann behoben werden, indem Sie nach einem fehlgeschlagenen Installationsversuch einfach alle Volumes löschen und die Datenbank und die Content-Server-Container neu erstellen.

Nachdem die Konfiguration abgeschlossen ist, kann die Funktionalität des Content-Servers durch CURLing einer seiner Komponenten wie ACS über “curl {IP_ADRESS}:9080/ACS/servlet/ACS” überprüft werden.

Konfiguration der Frontend-Komponenten

Wenn das Backend konfiguriert und lauffähig ist, starten wir drei t2.small EC2 Instanzen mit RHEL 7.5 AMIs in das öffentliche Subnetz. Dort wird die Installation von Docker und Docker-Compose durchgeführt. Im nächsten Schritt erstellen und starten wir die entsprechenden Container wie unten am Beispiel von Documentum Administrator beschrieben.

Um den Documentum Administrator vorzubereiten, wird die von OpenText bereitgestellte War-Datei in einen Arbeitsordner entpackt, um die notwendigen Änderungen vorzunehmen. Zunächst wird das obligatorische Connection Pooling in der Web.xml des Tomcat deaktiviert. Anschließend erstellen wir eine neue Docker-Datei und fügen den folgenden Inhalt hinzu:

Diese Befehlsfolge führt dazu, dass der Tomcat 7 Servlet Container aus dem Web heruntergeladen, die Datei „da.war„ in den Container kopiert und anschließend extrahiert wird. Um sicherzustellen, dass OpenText Documentum Administrator die richtigen Parameter für die Verbindung zum Content Server hat, haben wir ein Startskript geschrieben, das die Datei dfc.properties auf Basis der Umgebungsvariablen des Containers schreibt. Diese Datei wurde als “startup.sh” gespeichert:

Nachdem wir alle Dateien vorbereitet haben, erstellen wir den Container mit Docker build. Schließlich müssen Sie eine Yaml-Datei namens “dadmin.yml” erstellen, um die IP-Adresse des Connection Brokers auf dem Container Server, dessen Port und andere erforderliche Parameter anzugeben:

Der Container kann dann mit Docker-Compose gestartet und mit anderen Content-Servern verwendet werden, indem die Docbroker-Anmeldeinformationen, die in der Yaml-Datei als Umgebungsvariablen aufgeführt sind, einfach aktualisiert werden. Die Container für den Webtop- und die REST-Services wurden nach dem gleichen Schema unter Verwendung der von OpenText bereitgestellten War-Dateien erstellt.

Stolperfallen bei den Frontend-Containern

1. Obwohl OpenText vorkonfigurierte Docker-Images für Webtop, Documentum Administrator und REST Services zur Verfügung stellt, funktionierten diese Images in unserer Umgebung leider nicht. Es scheint, dass es einige Fehler in ihrer Konfiguration gibt, die sie daran hindern, richtig zu starten.
2. Wenn die oben beschriebenen Änderungen an web.xml nicht vorgenommen werden, funktionieren Documentum Administrator und Webtop nicht.
3. Sowohl Webtop als auch Documentum Administator werden nicht gestartet, wenn Tomcat als Dienst für systemd konfiguriert ist. Daher wird ein benutzerdefiniertes Startskript benötigt, um den Tomcat als Benutzer (in unserem Fall admin) zu starten.
4. Sowohl Webtop als auch Documentum Administrator funktionieren nicht ordnungsgemäß (zumindest ohne zusätzliche Konfigurationsschritte), wenn sie in anderen Ordnern als /path/to/tomcat/webapps/webtop bzw. /path/to/tomcat/webapps/da bereitgestellt werden.

Konfiguration des S3-basierten Dateispeichers

Eine neue Funktionalität von OpenText Documentum 16.4 ist die native Unterstützung von S3-gestützten Dateiablagen. Um sie zu verwenden, erstellen wir einen neuen S3-Bucket namens fme-showcase-docstore2 sowie einen IAM-Benutzer für Documentum mit programmatischem Zugriff auf AWS und einer Richtlinie, die den Zugriff auf den Bucket und alle seine Objekte erlaubt.

Wir hängen diese Regel an das Documentum Installation Owner-Konto an. Der letzte Schritt ist die Konfiguration des File Stores im Documentum Administrator. Dazu wählen wir “Datei->Neu->S3 Store” im Speichermenü vom DA und geben die URL des Buckets sowie die Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel an.

Stolperfallen bei den S3-Stores

1. ACS sollte aktiv und richtig konfiguriert sein, um S3 Stores nutzen zu können. Dies kann erreicht werden, indem sichergestellt wird, dass http://PUBLIC.IP.OF.CS:9080/ACS/servlet/ACS als ACS-URL bereitgestellt wird.
2. Wenn ein Slash am Ende der S3-Bucket-URL angegeben wird, kann der ACS keine Verbindung zu ihr herstellen.
3. Wenn einige der Parameter zunächst falsch konfiguriert wurden, sollte der ACS-Server neu gestartet werden, um mit der richtigen Konfiguration zu arbeiten.

Zusammenfassung und Ausblick

Abschließend haben wir eine komplette OpenText Documentum Umgebung auf der AWS Plattform installiert. Die Hauptkomponenten der Produkte wie Webtop und RestAPI, Content Server und PostgreSQL laufen vollständig über Docker Container auf der AWS-Infrastruktur.

Abbildung 3: Finales Setup

Das in diesem Blog-Artikel beschriebene Szenario für die Integration von OpenText Documentum auf der AWS-Plattform ist bewusst einfach gehalten, um die grundsätzliche Machbarkeit aufzuzeigen. Dies kann in wenigen Schritten relativ einfach erreicht werden, nachdem die entsprechenden Fallstricke identifiziert wurden. Der Vorteil beim Einsatz der AWS-Plattform liegt in der schnellen und unkomplizierten Bereitstellung der notwendigen Infrastrukturkomponenten.

Wir werden dieses Szenario in weiteren Artikeln auf diesem Blog mit Themen wie Container-Orchestrierung, Sicherheitskonzepte und Integration weiterer OpenText Documentum Produkte vertiefen. Nehmen Sie gerne  Kontakt auf wenn Sie mehr erfahren möchten.