1. Einleitung

Im Verlauf der Weiterentwicklung des CaaS ist es erforderlich, interne Anpassungen vorzunehmen, die manuelle Änderungen durch den Anwender erfordern.

Dieses Dokument enthält ab Version 2.12 ausschließlich jene Anpassungen, die am FirstSpirit-Modul durchgeführt werden müssen. Änderungen an der Plattform werden im entsprechenden Dokument beschrieben.

Die zudem enthaltenen Informationen zu früheren Versionen können sowohl Modul als auch Plattform betreffen.

Werden bei einem Update eine oder mehrere Versionen übersprungen (z.B. Version 1.1.1 nach 1.3.0), sind die Migrationsschritte dieser Versionen trotzdem zu berücksichtigen.

2. Update auf Version 2.9

Als Voraussetzung für das Update auf Version 2.9 muss der CaaS in Version 2.8.6 installiert sein! Vor der Durchführung des Update empfehlen wir, ein Backup der in der MongoDB gespeicherten Daten anzufertigen.

2.1. Konfiguration der MongoDB featureCompatibilityVersion

Nach dem Update der MongoDB auf Version 4.0, wird nun der Parameter featureCompatibilityVersion ebenfalls auf 4.0 gesetzt. Im Kubernetes-Stack ist die Anpassung automatisch möglich, im Docker-Stack muss sie jedoch manuell durchgeführt werden.

Sobald der CaaS in Version 2.9 läuft, führen Sie bitte das folgende Kommando aus:

docker exec -it docker_caas-mongo_1 mongo \
    -u $MONGO_INITDB_ROOT_USERNAME \
    -p $MONGO_INITDB_ROOT_PASSWORD \
    --authenticationDatabase admin \
    --eval "db.adminCommand( { setFeatureCompatibilityVersion: '4.0' } )"

Hierbei ersetzen Sie bitte die Platzhalter durch die von Ihnen konfigurierten Zugangsdaten.

Weitere Informationen hierzu finden Sie auch in der MongoDB-Dokumentation.

3. Update auf Version 2.8

Die MongoDB wird von Version 3.6 auf 4.0 aktualisiert.

Als Voraussetzung für das Update auf Version 2.8 muss der CaaS in Version 2.7.9 installiert sein! Vor der Durchführung des Update empfehlen wir, ein Backup der in der MongoDB gespeicherten Daten anzufertigen.

3.1. Kompatibilitätsänderungen der MongoDB

Generell sollten Sie prüfen, dass alle auf den CaaS zugreifenden Applikationen mit den Kompatibilitätsänderungen der MongoDB in Version 4.0 umgehen können. Eine detaillierte Auflistung dieser Änderungen finden Sie in der MongoDB-Dokumentation.

3.2. MongoDB featureCompatibilityVersion

Nach dem Update des CaaS auf 2.8 wird die MongoDB in Version 4.0 und mit dem Parameter featureCompatibilityVersion auf dem Wert 3.6 laufen. Das Update auf die neue MongoDB-Version wird bewusst von der Aktualisierung der featureCompatibilityVersion getrennt. Dieser Wert wird erst in einem folgenden Release auf 4.0 gesetzt, um das Update ordnungsgemäß ohne Downtime im Kubernetes-Stack durchführen zu können. Weitere Informationen finden Sie hier:

3.3. Docker Compose

Bitte prüfen Sie vor dem Update, dass der Parameter featureCompatibilityVersion auf den Wert 3.6 gesetzt ist. Weitere Informationen zu diesem Punkt finden Sie in der offiziellen MongoDB-Dokumentation.

4. Update auf Version 2.7

Als Voraussetzung für das Update auf Version 2.7 muss der CaaS in Version 2.6.1 installiert sein! Vor der Durchführung des Update empfehlen wir, ein Backup der in der MongoDB gespeicherten Daten anzufertigen.

4.1. Konfiguration der MongoDB featureCompatibilityVersion

Nach dem Update der MongoDB auf Version 3.6, wird nun der Parameter featureCompatibilityVersion ebenfalls auf 3.6 gesetzt. Im Kubernetes-Stack ist die Anpassung automatisch möglich, im Docker-Stack muss sie jedoch manuell durchgeführt werden.

Sollten Sie den Docker-Stack bereits von Beginn an mit einer MongoDB-Version 3.6 betreiben, dann ist die featureCompatibilityVersion bereits auf 3.6 konfiguriert und dieser Schritt ist nicht notwendig. Falls Sie sich unsicher sind, schauen Sie bitte in die MongoDB-Dokumentation, um die featureCompatibilityVersion abzufragen.

Sobald der CaaS in Version 2.7 läuft, führen Sie bitte das folgende Kommando aus:

docker exec -it docker_caas-mongo_1 mongo \
    -u $MONGO_INITDB_ROOT_USERNAME \
    -p $MONGO_INITDB_ROOT_PASSWORD \
    --authenticationDatabase admin \
    --eval "db.adminCommand( { setFeatureCompatibilityVersion: '3.6' } )"

Hierbei ersetzen Sie bitte die Platzhalter durch die von Ihnen konfigurierten Zugangsdaten.

Weitere Informationen hierzu finden Sie auch in der MongoDB-Dokumentation.

4.2. Anpassung der REST-Schnittstelle

Mit dieser CaaS-Version entfällt der Ping-Endpunkt /_logic/metrics/ping der REST-Schnittstelle.

Falls Sie diesen Endpunkt bisher genutzt haben, können Sie stattdessen den Metrics-Endpunkt /_metrics verwenden.

5. Update auf Version 2.6

Die MongoDB wird von Version 3.4 auf 3.6 aktualisiert.

Als Voraussetzung für das Update auf Version 2.6 muss der CaaS in Version 2.5.7 installiert sein! Vor der Durchführung des Update empfehlen wir, ein Backup der in der MongoDB gespeicherten Daten anzufertigen.

5.1. Kompatibilitätsänderungen der MongoDB

Generell sollten Sie prüfen, dass alle auf den CaaS zugreifenden Applikationen mit den Kompatibilitätsänderungen der MongoDB in Version 3.6 umgehen können. Eine detaillierte Auflistung dieser Änderungen finden Sie in der MongoDB-Dokumentation.

5.2. MongoDB featureCompatibilityVersion

Nach dem Update des CaaS auf 2.6 wird die MongoDB in Version 3.6 und mit dem Parameter featureCompatibilityVersion auf dem Wert 3.4 laufen. Das Update auf die neue MongoDB-Version wird bewusst von der Aktualisierung der featureCompatibilityVersion getrennt. Dieser Wert wird erst in einem folgenden Release auf 3.6 gesetzt, um das Update ordnungsgemäß ohne Downtime im Kubernetes-Stack durchführen zu können. Weitere Informationen finden Sie hier:

5.3. Docker Compose

Bitte prüfen Sie vor dem Update, dass der Parameter featureCompatibilityVersion auf den Wert 3.4 gesetzt ist. Weitere Informationen zu diesem Punkt finden Sie in der offiziellen MongoDB-Dokumentation.

6. Update auf Version 2.4.9

Mit dieser CaaS-Version wird eine neue Implementierung der URL-Konfigurationen ausgeliefert. Bereits bestehende URL-Konfigurationen werden automatisch migriert. Hierfür müssen nach Modulinstallation auf dem FirstSpirit-Server (und einem Neustart) wie üblich die Projektkomponenten aktualisiert werden. Das Aktualisieren (oder Neuinstallieren) der Projektkomponente nimmt die Migration des alten Datenbestandes vor. Sollte hierbei ein Fehler auftreten, wird der Vorgang abgebrochen.

Kommt es während der Aktualisierung der Komponenten zu einem Fehler, kann die Migration der bestehenden Daten nicht durchgeführt werden. In diesem Falle muss das Modul zurückgerollt werden, da diese Version des Moduls den alten Datenbestand nicht mehr auswertet.

7. Update auf Version 2.4.0

Mit dieser CaaS-Version entfallen die mitgelieferten selbstsignierten SSL-Zertifikate. Bitte schauen Sie sich die entsprechenden Kapitel in unserer Dokumentation an.

Falls Sie die mitgelieferten Zertifikate bisher genutzt haben, müssen Sie diese ab sofort eigenständig einrichten und verwalten. Mehr Informationen dazu finden Sie in der Docker bzw. Kubernetes Dokumentation.

8. Update auf Version 2.3.1

Die Konfiguration der URL-Factory, die zur Mediennutzung verwendet wird, wurde bisher über ein Freitextfeld im Konfigurationsdialog der Projektkomponente über einen vollqualifizierten Klassennamen vorgenommen. Ab CaaS-Version 2.3.1 bietet die Benutzeroberfläche eine Auswahl an verfügbaren URL-Factories, aus denen die zu verwendende ausgewählt werden kann. Die Auswahl verwendet dabei nun die Namen der Komponenten, unter denen diese veröffentlicht wurden.

Bestehende Konfigurationen müssen im Projekt migriert werden, da die Angabe von Klassennamen nun ungültig ist.

Für Konfigurationen, deren Klassennamen eindeutig auf dem Server verfügbaren Komponenten zugeordnet werden können, wird eine automatische Migration durchgeführt, sobald die Projektkomponente aktualisiert wird. Andere URL-Factory-Einträge müssen durch Neuauswahl und Speichern der Projektkomponente korrigiert werden. Bitte beachten Sie, dass Sie hierfür das Modul aktualisieren, den FirstSpirit-Server neustarten und anschließend die Projektkomponenten über den Button "Verwendungen aktualisieren" auf die neue Version aktualisieren müssen.

9. Update auf Version 2.1.6

Diese Version verhält sich im Bezug auf Remote-Medien anders, als dies bei vergangenen CaaS-Versionen der Fall ist. Sofern Sie keine Remote-Medien und/oder Remote-Projekte verwenden, betrifft Sie diese Änderung nicht.

In CaaS-Versionen vor 2.1.6 wurden Medien aus Remote-Projekten mit in der REST-Schnittstelle abgelegt. Ab 2.1.6 ist dies nicht mehr der Fall. Dies betrifft sowohl Konfigurationen mit Remote-Projekten, als auch Konfigurationen die eine Remote-Projekt-Konfiguration auf das eigene Projekt verwenden.

9.1. Warum wurde diese Änderung durchgeführt?

Die Verwendung von Remote-Projekten ermöglicht es Elemente in einem Projekt zu referenzieren, ohne diese mitgenerieren zu müssen. So können beispielweise vorwiegend statische Medien in einem seperaten Projekt gepflegt und über einen eigenen Auftrag generiert werden.

Referenzierende Projekte hingegen können die statischen Inhalte verwenden und wesentlich häufiger generiert werden, da deren Aufträge nun resourcenschonender sind.

In der Vergangenheit war das resourcenschonende Setup mit einer CaaS-Generierung nicht möglich und beispielsweise ein Mediendeployment in ein CDN nicht umsetzbar, da Remote-Inhalte stets mitgeneriert wurden.

Die Auswahl zwischen einem klassischen FirstSpirit-Deployment und dem CaaS-Mediendeployment ermöglicht nun die Umsetzung der oben aufgeführten Szenarien und erfüllt die Anforderungen an Flexibilität und Effizienz, die in einem modernen FirstSpirit-Projekt aufkommen.

Die Verwendung von Remote-Projekten in einer CaaS-Generierung ist darüberhinaus nun identisch zu üblichen FirstSpirit-Projekten.

9.2. Was muss ich im Projekt beachten?

Wenn Sie im Projekt Medien verwenden, die aus einem Remote-Projekt referenziert werden, müssen diese nun durch das Remote-Projekt an einem Ort zur Verfügung gestellt werden, der durch die Applikation erreicht werden kann die den CaaS verwendet. In der Remote-Projekt-Konfiguration muss dann der URL-Creator verwendet werden, der im Remote-Projekt verwendet wird. Das "Präfix für absolute Pfade" muss so eingestellt werden, dass die Applikation die den CaaS verwendet die Medien auflösen kann.

10. Update auf Version 2.0.22

Das CaaS-Modul setzt nun FirstSpirit 2018-07 oder neuer zum Betrieb voraus.

Seit FirstSpirit 5.2.1806 haben CaaS-Deployments die Warnung "Access denied to de.espirit.firstspirit.agency.ConnectionDelegatingSpecialistsBroker$ManagerBrokerImpl" ausgegeben. Bisher war es möglich, diese Warnungen durch Setzen eines Feature-Flags zu unterdrücken. Ab FirstSpirit 2018-09 ist dies nicht mehr möglich, und die Verwendung dieser internen APIs führt zu Fehlern, die eine Installation und den Betrieb eines älteren CaaS-Moduls verhindern.

Das CaaS-Modul ist aktualisiert worden, um auch in FirstSpirit ab 2018-09 lauffähig zu sein. Diese Änderungen haben zur Folge, dass das CaaS-Modul ab dieser Version zwingend FirstSpirit 2018-07 oder neuer voraussetzt.

11. Update CaaS Version 1.3.35 nach 2.0.0

Dieses Upgrade enthält viele Änderungen, die den Betrieb des CaaS vereinfachen und deutlich stabiler machen. Der Umfang dieser Änderungen erfordert einige manuelle Schritte, die im Folgenden erläutert sind. Die Upgrade-Anleitung beschreibt die konkreten Schritte.

11.1. Entfernung der Standalone-Version

Ab dieser Version ist das Standalone-Installationspaket nicht mehr Teil der Auslieferung. Wir empfehlen eine Migration auf den Docker Compose-Stack oder auf Kubernetes.

11.2. Vorankündigung: Kubernetes/Empfehlungen bzgl. des Docker Compose-Stacks

Aktuell besteht die CaaS-Auslieferung zu einem sehr großen Teil aus dem Docker Compose-Stack, der aktuell auch für alle Produktionsempfehlungen empfohlen wird. In den vergangenen Releases gab es bereits zusätzlich die Möglichkeit, den CaaS über Kubernetes zu betreiben. Diese Installationsmöglichkeit befindet sich aktuell im Status Technical Preview, der in naher Zukunft aufgehoben wird.

Ab diesem Moment wird die Verwendung von Kubernetes für alle Neuinstallationen und der Docker Compose-Stack nur noch für kleine Installationen sowie Entwicklungsszenarien empfohlen. Ein genauer Zeitpunkt wird in den kommenden Release Notes noch einmal separat angekündigt. Die Information erfolgt frühzeitig, damit vor allem Nutzer der Standalone-Version die Möglichkeit bekommen, eine informierte Entscheidung bzgl. der Verwendung eines der Stacks sowie hinsichtlich des Migrationszeitpunkts zu treffen.

11.3. Entfernung von CaaS-Bus und CaaS-Adapter aus dem Stack

Mit diesem Release wurden größere Arbeiten an der internen Funktionsweise des CaaS durchgeführt. Die wichtigste Änderung ist die Entfernung der Komponenten CaaS-Adapter und CaaS-Bus. Diese Vereinfachung der Architektur hat positive Auswirkungen auf den Betrieb, die Stabilität, sowie die Performance des CaaS.

Die Auswirkungen für den Betrieb sind unter anderem:

  • die ausschließliche Verwendung von HTTP/HTTPS als Protokoll für die Datenübertragung von FirstSpirit zum CaaS

  • Proxy-Unterstützung im FirstSpirit-Modul

  • Performance-Verbesserung sowie geringerer Ressourcenverbrauch

Dies zieht einige Änderungen nach sich, die im Folgenden beschrieben sind.

11.4. Update der benötigten Versionen von Docker und Docker Compose

Im Gegensatz zum Modul ergeben sich für den CaaS-Stack mit dieser Version Änderungen an den technischen Voraussetzungen. Ab diesem Release ist es notwendig, mindestens folgende Versionen zu verwenden:

CaaS-Stack
  • Docker-Version 17.12.0-ce

  • Docker Compose 1.21.0

11.5. Veränderung der Struktur der Docker Compose-Dateien

Bisher gab es für den Docker Compose-Stack eine einzelne docker-compose.yml-Datei, die dem Starten des CaaS diente. Ab dieser Version werden mehrere Dateien verwendet, die überlagert werden. Diese Struktur vereinfacht vor allem Anpassungen an den Ports und Quellen der Images. Diese Anpassungen waren bislang für jedes Update manuell durchzuführen.

Wenn Sie bisher keine manuellen Anpassungen vorgenommen haben, ändert sich für Sie nichts.

Im aktuellen Release setzt sich der Docker Compose-Stack aus mehreren Dateien zusammen:

Bei einem Aufruf des Befehls docker-compose up ohne die Angabe von Dateinamen wird der Inhalt der docker-compose.yml-Datei mit dem Inhalt der docker-compose.override.yml-Datei überlagert. Das Ergebnis lässt sich mit dem Befehl docker-compose config betrachten.

Besteht der Wunsch, Anpassungen an den Images vorzunehmen, lässt sich wie gewohnt die docker-compose.yml-Datei verändern. Äquivalent können Anpassungen an den Ports über die docker-compose.override.yml-Datei erfolgen.

Detaillierte Informationen über die Vorteile der Aufteilung auf mehrere Dateien sind in der Docker-Dokumentation enthalten.

11.6. Entfernung des Gateways/Load Balancing aus dem Docker Compose-Stack

Das Release enthält Änderungen, die das Gateway aus dem Docker Compose-Stack entfernen. Es diente vor allem dem Load Balancing in den Fällen einer Mehrfach-Instantiierung der REST-Schnittstelle auf einem Server und lieferte darüber hinaus verschiedene Metriken.

Diese Anwendungsfälle werden zukünftig zugunsten der Kubernetes-Installation komplett entfernt.

Kontaktieren Sie bitte unseren Technical Support, wenn Sie auf diesen Betriebsmodus angewiesen sind.

Bis zur Entfernung der Anwendungsfälle, enthält das Release die gateway.override.yml-Datei. Sie erlaubt die Erweiterung des CaaS-Stacks um das Gateway und den Betrieb des bisherigen Stands.

Was ändert sich für Kunden, die vom Load Balancing keinen Gebrauch gemacht haben?

Für diese Kunden ändert sich nichts. Das Verhalten der REST-Schnittstelle ist - bis auf einige Header, die sich auf das Load Balancing bezogen - identisch zu vorher. Abgesehen von einer Verringerung der Hardware-Anforderungen ergeben sich keine Änderungen.

Was ändert sich für Kunden, die das Load Balancing verwendet und auf einem Server mehr als eine REST-Schnittstelle instantiiert haben?

Aktuell enthält die Auslieferung die gateway.override.yml-Datei, die weiterhin die bisherige Funktionalität bereitstellt. Langfristig gesehen empfiehlt sich jedoch die Migration von Docker Compose zu Kubernetes, da dies viele Vorteile im Betrieb hat.

Ohne eine Migration ergeben sich in der Zukunft folgende Einschränkungen:

  • Es wird keine neue Auslieferung des Gateways geben. Die entsprechenden Kunden werden auch in Zukunft die Version des 1.3.35er-Releases verwenden.

  • Aufgrund der Abkündigung dieser Installationsart, wird von der Verwendung des Gateways für zukünftige Installationen abgeraten.

  • Technisch gesehen ergeben sich keine Einschränkungen mit diesem Release im Vergleich zu früheren Releases.

  • Das Gateway ist nur noch in der Dokumentation des Releases 1.3.35 beschrieben.

Zur Verwendung der gateway.override.yml-Datei

Es ändert sich der Aufruf der docker-compose-Datei: Sie wird zusätzlich zu der schon bekannten docker-compose.yml-Datei verwendet und enthält die Änderungen, die für das Starten des Gateways nötig.

Mit dem Aufruf des folgenden Befehls wird der Stack gestartet:
docker-compose -f docker-compose.yml -f gateway.override.yml up

Ein Start im Hintergrund ist über den Parameter -d möglich:
docker-compose -f docker-compose.yml -f gateway.override.yml up -d

Die Skalierung der REST-Schnittstelle auf eine Größe von 3 erfolgt über den Befehl:
docker-compose -f docker-compose.yml -f docker-compose.override.yml -f gateway.override.yml scale caas-rest-api=3

11.7. Umbenennung caas-docker-container-$VERSION.zip in caas-docker-images-$VERSION.zip

Da die Datei caas-docker-container-$VERSION.zip keine Docker-Container enthält, wurde sie in caas-docker-images-$VERSION.zip umbenannt. Dies macht möglicherweise eine Anpassung der Deployment-Pipeline notwendig, wenn die Datei bisher automatisch entpackt wurde.

Mit dem Upgrade auf die nächste Major-Version des CaaS wird ein Backup der in der MongoDB gespeicherten Daten empfohlen.

MongoDB

Ein Backup der im CaaS gespeicherten Informationen muss über die Standardmechanismen erfolgen. Dabei kann entweder eine Kopie der zugrundeliegenden Dateien erstellt oder mongodump verwendet werden.

11.8. Anpassung der bestehenden Aufträge für Voll- und Deltagenerierung

Anders als bisher muss ausschließlich die Aktion Finalize CaaS Generation des Generierunsauftrags auch im Fehlerfall ausgeführt werden.

Wird die Aktion im Fehlerfall nicht ausgeführt, kann ein fehlgeschlagener Auftrag dazu nachführen, dass ein nachfolgendes Deployment nicht ausführbar ist. In diesem Fall ist ein Neustart des FirstSpirit-Servers erforderlich.

11.9. Update der Modul-Konfiguration

Durch die Entfernung des CaaS-Busses sind einige Konfigurationen nicht mehr verfügbar und stattdessen neue Einstellungen erforderlich. Die erfolgreiche Durchführung des Updates setzt daher die Anpassung des CaaS-Services im Bereich ServerManager  Server-Eigenschaften  Module voraus. Der Konfigurationsdialog des Service lässt sich nach dem Ausklappen des Ordners CaaS Module über den Button Konfigurieren öffnen.

  • Die Verbindungseinstellungen zum CaaS-Stack haben sich verändert: Anstelle der Verbindung zum CaaS-Bus wird nun die Verbindung zur REST-Schnittstelle angegeben.

  • Wie bisher ist der verwendete API Key einzutragen.

  • Optional ist außerdem ein HTTP-Proxy konfigurierbar.

  • Die Anzahl der parallel aufgebauten Verbindungen zur REST-Schnittstelle ist einstellbar. Der Standardwert ist in den meisten Situationen als ausreichend anzusehen. In spezifischen Situationen kann es jedoch aus Optimierungsgründen ratsam sein, Anpassungen vorzunehmen.

Weitere Informationen sind in der Dokumentation CaaS Module with Docker enthalten.

Aktuell ist eine Überschreibung des HTTP-Proxies in der Projektkomponente nicht möglich.

11.10. Update der Projektkomponente

Die Parameter waitInMillis und maxNumberOfWaits sind nicht mehr verfügbar und müssen entfernt werden.

Der Parameter caasUrl enthielt in der Vergangenheit die URL zum CaaS-Bus. Stattdessen wird für den Parameter nun optional die URL zur REST-Schnittstelle erwartet, sofern sie sich von der Einstellung im Modul unterscheidet. Stimmt die URL überein, kann der Parameter ebenfalls entfernt werden.

Darüber hinaus ist nun der Parameter caasApiKey verfügbar. Er enthält den für die Verbindung zur REST-Schnittstelle zu verwendenden API Key. Auch dieser Wert ist optional und muss nur angegeben werden, wenn er sich von der Einstellung im Modul unterscheidet.

11.11. Upgrade-Anleitung

  • Vor der Installation des neuen Moduls müssen im Bereich ServerManager  Server-Eigenschaften  Module  CaaS Module sowohl der CaaS Preview Service als auch der CaaS Service gestoppt werden. Dafür sind die beiden Buttons Dienst stoppen und Autostart deaktivieren zu klicken.

  • Anschließend ist das neue FirstSpirit-Modul zu installieren und der Stack zu aktualisieren. Das neue Modul ist zu den alten Komponenten kompatibel, verwendet sie jedoch etwas anders. Aus diesem Grund ist die Frage, ob die Dienste automatisch gestartet werden sollen, mit Nein zu beantworten.

  • Danach ist die Anpassung der Modul-Konfiguration erforderlich. Wie zuvor beschrieben, ist dafür über den Button Konfigurieren der Konfigurationsdialog des CaaS Service im Bereich ServerManager  Server-Eigenschaften  Module  CaaS Module zu öffnen. In diesem sind die folgenden Angaben vorzunehmen:

    • Das neue Modul verbindet sich nicht mehr mit dem CaaS-Bus, sondern direkt mit der REST-Schnittstelle.

    • Sofern der Preview Service verwendet wird, muss darüber hinaus die Projekt-Komponente im Bereich ServerManager  Projekt-Eigenschaften  Projekt-Komponenten zu konfigurieren.

  • Nach der erfolgreichen Konfiguration muss sowohl der CaaS Service als auch der CaaS Preview Service wieder aktiviert werden. Äquivalent zur Deaktivierung erfolgt dies über die Buttons Dienst starten und Autostart aktivieren

  • Im Anschluss an die Anpassung der Modul-Konfiguration empfielt sich die Durchführung eines Verbindungstests sowie eines Test-Deployments. Sofern vorhanden, ist ein kleines Testprojekt dafür ausreichend.

  • In der Zeit, bevor der Stack aktualisiert wird, werden CaaS-Adapter und CaaS-Bus nicht werwendet.

  • Nach dem Verbindungstest des neuen Moduls mit dem alten Stack kann der Stack in Abhängigkeit der verwendeten Installationsvariante aktualisiert werden.

Kubernetes

Die vorherigen Releases in Kubernetes enthielten bereits Helm-Charts. An dieser Stelle wird deren Verwendung vorausgesetzt bzw. nachdrücklich empfohlen, da auch die Kubernetes-YAMLs Änderungen enthalten und die neueren Docker-Images ggf. nicht ohne Anpassungen an den YAMLs verwendbar sind.

Ein Upgrade des Stacks mit helm erfolgt über den folgenden Befehl:
helm upgrade $RELEASE_NAME caas-2.0.0.tgz --values $YOUR_VALUES_FILE --namespace $CAAS_NAMESPACE

Dabei ist der $RELEASE_NAME durch den Namen des zuvor verwendeten helm-Releases zu ersetzen, der ebenso wie der $CAAS_NAMESPACE mit helm ls herausfindbar ist.

Kam in der Vergangenheit eine eigene values.yaml-Datei zum Einsatz, lässt sich diese über den Parameter $YOUR_VALUES_FILE angeben.

Das Upgrade wird nach der Eingabe des o.g. Befehls automatisch durchgeführt.

Durch die Verwendung von helm ist es möglich, das Upgrade ohne Downtime durchzuführen.

Docker Compose

Die Aktualisierung des Docker Compose-Stacks ist wie folgt durchzuführen:

  • Über den Aufruf des entsprechenden Installationskripts (install.sh bzw. install.cmd) ist zunächst das Image in das lokale Docker-Repository zu importieren.

  • Im Verzeichnis, in dem der CaaS installiert wurde, ist anschließend der Name der docker-compose.yml-Datei in docker-compose-old.yml zu ändern.

  • Danach sind die Dateien docker-compose.yml, docker-compose.override.yml und (optional) gateway.override.yml aus der neuen Distribution in dieses Verzeichnis zu kopieren.

  • Für die Ordner Configuration und Bootstrap können alle Dateien, die nicht individuell verändert wurden, überschrieben werden. Die orginale Ordnerstruktur muss jedoch erhalten bleiben.

  • Enthält die Datei docker-compose-old.yml spezifische Anpassungen, können diese in die neue Konfiguration übertragen werden.

    Die folgenden Schritte erzeugen eine Downtime von wenigen Augenblicken.

  • Nach der Durchführung der zuvor beschriebenen Schritte, muss der alte, noch laufende CaaS-Stack mittels des folgenden Befehls gestoppt werden: docker-compose -f docker-compose-old.yml down

  • Danach ist der Start des neuen Stacks erforderlich: docker-compose up -d.
    Besteht der Wunsch, weiterhin das Gateway zu verwenden, muss der Befehl entsprechend angepasst werden.
    (siehe auch Kap. Entfernung des Gateways/Load Balancing aus dem Docker Compose-Stack)

  • Im letzten Schritt ist die alte docker-compose-old.yml-Datei zu löschen.

Standalone

Ab dieser Version ist das Standalone-Installationspaket nicht mehr Teil der Auslieferung. Daher wird eine Migration auf den Docker Compose-Stack bzw. auf Kubernetes dringend empfohlen.

Der Kubernetes-Stack ist aktuell noch im Status Technical Preview und eignet sich aufgrund der bisher sehr knapp gehaltener Dokumentation derzeit nicht für Kubernetes-unerfahrene Benutzer. Der Stack wird mittlerweile jedoch als technisch stabil betrachtet. Bestehen bereits Erfahrungen bzgl. der Arbeit mit Kubernetes und helm, ist eine Migration auf den Kubernetes-Stack sinnvoll. Andernfalls ist der Docker Compose-Stack vorzuziehen.

Für die Datenmigration sind die folgenden Schritte durchzuführen:

  • Im ersten Schritt ist zunächst ein Export der Daten des alten Stacks notwendig. Dieser ist per mongodump durchzführen.

  • Die exportierten Daten müssen anschließend per mongorestore in den neuen Stack importiert werden.

  • Im letzten Schritt ist es wichtig, das DNS so umzusetzen, dass es auf den neuen Stack zeigt.

Aufgrund der Datenmigration ist eine Downtime während des Updates der Standalone-Version schwer vermeidbar.

12. Update CaaS Version 1.3.11 nach 1.3.21

Zur Erweiterung des Speichermanagements wurden in Version 1.3.21 für alle Applikationen Speichergrenzen eingeführt. In diesem Zuge sind die Bus-spezifischen Parameter CAAS_BUS_MIN_MEMORY und CAAS_BUS_MAX_MEMORY aus der Konfigurationsdatei caas-docker.env entfernt worden. Die Angaben zum Ressourcenverbrauch des Bus-Prozesses sind stattdessen in der docker-compose-Konfigurationsdatei vorzunehmen.

Weitere Informationen zur Konfiguration der Speichergrenzen finden Sie in der jeweiligen CaaS Module-Dokumentation für den Betrieb mit Docker.

13. Update CaaS Version 1.3.13 nach 1.3.14

Mit der Version 1.3.14 wurden spezielle Lizenzen für den CaaS eingeführt. Um zu erkennen, ob der CaaS mit der vorliegenden Lizenz betrieben werden kann, kann in der Lizenzdatei nach der Zeile beginnend mit license.SCOPE gesucht werden. Wenn dort der Wert SERVICE eingetragen ist, handelt es sich um eine geeignete Lizenz. Sollte das nicht der Fall sein, kontaktieren Sie bitte den Technical Support.

14. Update CaaS Version 1.3.3 nach 1.3.4

Für die Version 1.3.4 haben sich die verwendeten Benutzer innerhalb der Docker-Container geändert. Des Weiteren wurde ein Update der REST-Schnittstelle durchgeführt. Die sich aus diesen beiden Punkten zu berücksichtigenden Informationen sind in den nachfolgenden Unterkapiteln enthalten.

14.1. SecurityGroups

Die Änderung der Benutzer innerhalb der Docker-Container hat im Normalfall keinen Einfluss auf den Betrieb des CaaS-Stacks. Sollten dennoch Zugriffsprobleme der Docker-Images auf die eingebundenen Volumes existieren, so sind deren Zugriffsrechte zu prüfen. Zugriffsprobleme können auftreten, wenn an den Rechten der Volumes auf dem Hostsystem manuelle Anpassungen vorgenommen wurden.

14.2. Update der REST-Schnittstelle

Mit dem Update der REST-Schnittstelle ändert sich das von ihr zurückgegebene JSON-Format in den folgenden Punkten:

  • Long-Werte in den Feldern fs_date, fs_scheduler_date, fs_revision_id und fs_project_id sind nun mit dem Ausdruck $numberLong gekennzeichnet.

  • Ausschließlich für Medien werden die sogenannten Custom Properties in dem neuen Feld metadata gekapselt. Dies sind alle Felder außer filename, chunkSize, _links, uploadDate, _id, length und md5.

Durch das neue metadata-Feld ändert sich bei der Abfrage von Medien der Field Path der Custom Properties. Sie sind nun per Punkt-Notation über metadata.<fieldname> zu benennen. Bereits bestehende Abfragen sind entsprechend anzupassen.

Die durch das Update bedingten Änderungen des von der REST-Schnittstelle zurückgelieferten JSON-Formats sind nicht rückwärtskompatibel. Dies ist insbesondere bei der Verarbeitung der Abfrageergebnisse zu beachten.

Beispiel

Die folgende Tabelle zeigt das zurückgelieferte JSON-Dokument eines Beispielbilds image02 vor und nach dem Update der REST-Schnittstelle.

JSON-Format (alt) JSON-Format (neu)

{ "fs_date": 1491298663736,
"fs_resolution_width": "100",
"fs_encoding": "png",
"_links": {"rh:data": {"href": "/CaaS/assets.files/image02/binary"}},
"fs_project_id": 0,
"fs_revision_id": 0,
"fs_resolution_height": "100",
"fs_object_type": "asset",
"fs_extension": "png",
"fs_description": "test",
"contentType": "image/png",
"fs_id": "image02",
"fs_language": "DE",
"_etag": {"$oid": "58e36978a6764520f8bcca12"},
"chunkSize": 261120,
"length": 164,
"fs_crc": "1432576898",
"filename": "files/image02.png",
"uploadDate": {"$date": 1491298680331},
"fs_scheduler_date": 1491298663736,
"fs_mimetype": "image",
"_id": "image02",
"md5": "7566e3759f73fdae7254fcde5aa5d9fa"
}

{ "metadata":
{ "fs_date": {"$numberLong": "1491298296281"},
"fs_resolution_width": "100",
"fs_encoding": "png",
"fs_project_id": 0,
"fs_revision_id": 0,
"fs_resolution_height": "100",
"fs_crc": "1432576898",
"fs_object_type": "asset",
"fs_extension": "png",
"filename": "files/image02.png",
"fs_scheduler_date": {"$numberLong": "1491298296281"},
"fs_description": "test",
"fs_mimetype": "image",
"fs_size": "big",
"contentType": "image/png",
"fs_id": "image02",
"fs_language": "DE",
"_etag": {"$oid": "58e36800a6764543bca7fc4d"}
},
"filename": "files/image02.png",
"chunkSize": 261120,
"uploadDate": {"$date": 1491298304166},
"_links": {"rh:data": {"href": "/CaaS/assets.files/image02/binary"}},
"length": {"$numberLong": "164"},
"_id": "image02",
"md5": "7566e3759f73fdae7254fcde5aa5d9fa"
}

15. Update CaaS Version 1.3.1 nach 1.3.2

Mit der Version 1.3.2 wurde der Cluster-Betrieb optimiert und die Möglichkeit geschaffen, mehrere CaaS-Instanzen zu verwenden. Die notwendigen Schritte zur Verwendung der Funktionalitäten werden nachfolgend beschrieben.

15.1. Docker-Update

Im Zuge des in Version 1.3 eingeführten Cluster-Betriebs der MongoDB wurden Funktionalitäten notwendig, die Docker erst mit der Version 1.13 bereitstellt. Aus diesem Grund wird für die Verwendung der CaaS-Version 1.3.2 ein Update der Docker-Version auf 1.13 zwingend vorausgesetzt.

15.2. Verwendung mehrerer CaaS-Instanzen

Bis zur Version 1.3.2 wurde die Verbindung zum CaaS-Bus ausschließlich in der Konfiguration des FirstSpirit-Services CaaS Service festgehalten. Ab Version 1.3.2 besteht darüber hinaus jedoch die Möglichkeit, eine spezifische Konfiguration im Generierungsauftrag zu definieren. Auf diesem Weg lassen sich verschiedene CaaS-Instanzen ansprechen.

Dafür müssen das Passwort und die URL der spezifischen CaaS-Instanz in der Generierung im Auftragsschritt Initialize CaaSGeneration als Parameter caasPassword und caasUrl angegeben werden.

Weitere Informationen zur Konfiguration der Verbindung zum CaaS-Bus finden Sie in der jeweiligen CaaS Module-Dokumentation für den Betrieb mit Linux bzw. Docker.

16. Update CaaS Version 1.2.1 nach 1.3.0

In Version 1.3 wurde der Cluster-Betrieb der MongoDB eingeführt. In der Docker-Variante kann der CaaS sowohl mit einer einzelnen als auch mit einem MongoDB-Cluster betrieben werden.

Zusätzliche zur bestehenden docker-compose.yml befindet sich in der Auslieferung die Datei docker-compose-cluster.yml, über die das Cluster gestartet werden kann.

Wird ein Upgrade von 1.1.x auf 1.3 durchgeführt, muss zusätzlich das Kapitel Update CaaS Version 1.1.3 nach 1.2.0 beachtet werden.

Beenden Sie zunächste Ihren CaaS-Docker-Stack mit docker-compose down.

Vor dem Upgrade empfehlen wir ein Backup ihrer Daten.

16.1. Neuinstallation ohne Übernahme der Daten

Soll ein bestehender CaaS-Docker-Stack ersetzt, also keine Daten übernommen, werden, ist sicherzustellen, dass die neuen Container nicht auf das vorhanden Volume zugreifen. Um dies zu ereichen, haben Sie zwei Möglichkeiten:

Löschen des alten Volumes
Beispiel
docker volume ls
DRIVER          VOLUME NAME
local           caas_mongodatavol1

:: In diesem Beispiel ist das Volume caas_mongodatavol1 zu löschen:

+ docker volume rm caas_mongodatavol1

+ Das Prefix caas ist der Projektname und entspricht im Default dem Verzeichnis, in welchem der Stack gestartet wurde.

+ Danach starten Sie wie gewohnt den Stack über:

+ docker-compose -f docker-compose-cluser.yml up

Verwendung eines anderen Projektnamens

Eine zweite Möglichkeit ist es, beim Starten des CaaS-Docker-Stacks explizit einen Projektnamen zu vergeben:

docker-compose -f docker-compose-cluser.yml -p caas_cluster up

16.2. Update einer bestehenden Installation

In diesem Kapitel gehen wir davon aus, dass eine bestehende CaaS-Docker-Installation aktualisiert und nach dem Upgrade mit einem MongoDB-Cluster gearbeitet werden soll. Das Upgrade wird beim ersten Start der neuen Container automatisch durchgeführt, wenn ein Volume mit bestehenden Daten gefunden wird.

Beispiel
docker volume ls
DRIVER          VOLUME NAME
local           caas_mongodatavol1

In diese Beispiel handelt es sich bei dem Prefix caas um den Projektnamen. Im Default verwendet Docker-Compose den aktuellen Verzeichnisnamen als Projektnamen. Damit die neuen Container das vorhandene Volume verwenden können, müssen diese mit docker-compose entsprechend gestarten werden:

docker-compose -f docker-compose-cluster.yml -p caas up

Beim ersten Start erkennt der Container, dass ein Upgrade durchgeführt werden muss und führt die Migration durch.

Nach dem erfolgreichen Durchführen der Migration auf den MongoDB-Cluster ist eine Rückkehr zum normalen Betrieb nicht ohne manuellen Aufwand möglich. Wenden Sie in diesem Fall bitte an den Technical Support der e-Spirit AG.

16.3. Änderungen in der Konfiguration

Gegenüber der Version 1.2 sind vier neue Konfigurationsparameter hinzugekommen. Je nachdem, ob der CaaS mit einer einzelnen MongoDB-Instanz oder mit einem Cluster betrieben wird, sind unterschiedliche Einstellungen nötig.

In der Standardauslieferung sind die jeweiligen Konfigurationsdateien mit sinnvollen Werte vorbelegt. Sollte Ihre lokale Konfiguration abweichen, passen sie die Werte bitte entsprechend an.

caas-docker.env
CAAS_REPO_SERVER=caas-mongo
CAAS_REPO_ADDITONS=
caas-docker-cluster.env
CAAS_REPO_SERVER=mongo1,mongo2,mongo-master
CAAS_REPO_ADDITONS=&replicaSet=rs
CAAS_CLUSTER_ADMIN_USER=clustermanager
CAAS_CLUSTER_ADMIN_PASSWORD=clustermanager
CAAS_CLUSTER_ADMIN_USER / CAAS_CLUSTER_ADMIN_PASSWORD

Diese Variablen beinhalten die Passwörter für den Administrator-Benutzer für das MongoDB-Cluster.

CAAS_REPO_SERVER

Diese Variable enthält eine kommaseparierte Liste von Hostnames der Knoten Ihres MongoDB-Clusters.

CAAS_REPO_ADDITONS

Diese Variable enthält Optionen für die Connection-URL der REST-Schnittstelle zu der MongoDB-Instanz bzw. den MongoDB-Instanzen des Clusters.

17. Update CaaS Version 1.1.3 nach 1.2.0

In Version 1.2 wurde die zuvor bestehende interne Abhängigkeit zum UX-Bridge-Modul aufgelöst und dessen Funktionalität in das CaaS Module-Modul integriert.

Aufgrund dieser Änderungen ist eine Aktualisierung des CaaS Module-Moduls und die Deinstallation des UX-Bridge-Moduls erforderlich. Darüber hinaus müssen Komponenten des CaaS-Stacks sowie die FirstSpirit-Generierungsaufträge aktualisiert und abschließend eine Vollgenerierung durchgeführt werden.

Die notwendigen Anpassungen betreffen sowohl den Betrieb mit Linux als auch mit Docker und sind in den folgenden Unterkapiteln beschrieben.

17.1. CaaS Module-Modul aktualisieren

Das CaaS Module-Modul ist auf dem FirstSpirit-Server auf Version 1.2 zu aktualisieren.

Öffnen Sie dafür den ServerManager und wählen Sie den Bereich Server-Eigenschaften  Module.

modules
Abbildung 1. Module

Im Hauptpanel ist eine Liste aller auf dem FirstSpirit-Server installierten Module zu sehen. Wählen Sie nach dem Klicken auf Installieren die caas-<Versionsnummer>.fsm-Datei aus und bestätigen Sie die Auswahl mit Öffnen. Die Frage, ob der im Modul enthaltene Dienst automatisch gestartet werden solle, bestätigen Sie mit Ja.

Ist die Verwendung des CaaS nicht lizenziert, erscheint bei der Installation des CaaS Module-Moduls eine Fehlermeldung. Sie weist jedoch lediglich auf die ungültige Lizenz hin, ohne die Installation zu verhindern bzw. abzubrechen.

Nach der erfolgreichen Installation wurde der Liste der Ordner CaaS Module hinzugefügt, der Alle Rechte erhalten muss (vgl. Abbildung Module).

Nach jeder Installation oder Aktualisierung eines Moduls ist ein Neustart des FirstSpirit-Servers notwendig.

Nähere Details zum Modul-Update finden Sie in der jeweiligen CaaS Module-Dokumentation für den Betrieb mit Linux bzw. Docker.

17.1.1. CaaS-Service konfigurieren

Das CaaS Module-Modul enthält den neuen Service CaaS Service, der nun zu konfigurieren ist.

Selektieren Sie nach dem Aufklappen des Ordners CaaS Module im Hauptpanel den Dienst CaaS Service und klicken Sie anschließend auf Konfigurieren. Es öffnet sich der dazugehörige Konfigurationsdialog (vgl. Abbildung Konfigurationsdialog des CaaS Service).

caas service
Abbildung 2. Konfigurationsdialog des CaaS Service
Benutzer

Der Benutzer ist mit dem Wert module vorbelegt. Dieser Wert entspricht dem Wert der Eigenschaft userName aus der Konfiguration des UX-Bridge-Moduls. Sofern Sie im UX-Bridge-Modul einen vom Standard abweichenden Wert gesetzt hatten, übernehmen Sie diesen in dieses Feld. Ansonsten muss die Vorgabe erhalten bleiben.

Passwort

Das hier anzugebende Passwort wird während der Konfiguration der importierten CaaS-Container definiert. Sollte es nicht mehr bekannt sein, ist es in der caas-docker.env-Datei als Wert der CAAS_BUS_MODULE_PASSWORD-Variablen zu finden.

CaaS Bus URL

In der anzugebenen ActiveMQ-Failover-URL mit SSL ist die Variable CAAS-HOST zu ersetzen:
failover:(ssl://CAAS-HOST:62626)?maxReconnectAttempts=2&startupMaxReconnectAttempts=10
Details zum ActiveMQ-Transport finden Sie unter ActiveMQ Failover Transport Reference.

Bei der Eingabe der CaaS Bus URL ist zu beachten, dass sich der Port des CAAS-HOST mit der neuen Version des Moduls geändert hat. Der vorherige Port 61616 ist gegen den Port 62626 zu ersetzen.

Nach der Konfiguration muss der Service gestoppt und erneut gestartet werden.

Nähere Details zur Konfiguration des CaaS-Service finden Sie in der jeweiligen CaaS Module-Dokumentation für den Betrieb mit Linux bzw. Docker.

17.2. UX-Bridge-Modul deinstallieren

Das UX-Bridge-Modul ist für den CaaS nicht mehr erforderlich und muss entfernt werden.

Falls Sie die Weiternutzung des UX-Bridge-Moduls anstreben, beachten Sie bitte das Kapitel Parallelbetrieb des CaaS und der UX-Bridge.

Zum Entfernen des Moduls öffnen Sie den ServerManager und wählen Sie den Bereich Server-Eigenschaften  Module. Im Hauptpanel ist eine Liste aller auf dem FirstSpirit-Server installierten Module zu sehen. Selektieren Sie den Eintrag UX-Bridge und klicken Sie auf Deinstallieren. Durch die Bestätigung der Auswahl mit OK wird das Modul deinstalliert. Der Eintrag ist anschließend nicht mehr in der Liste im Hauptpanel sichtbar.

Nach der Deinstallation ist ein Neustart des FirstSpirit-Servers notwendig.

17.3. CaaS-Stack aktualisieren

Innerhalb einer Linux-Umgebung erfolgt die Aktualisierung des CaaS über das Installationspaket. Bei Einsatz von Docker-Images werden die einzelnen Stack-Komponenten separat ausgetauscht.

Inkompatible Änderungen

Generell muss vor der Aktualisierung darauf geachtet werden, dass alle FirstSpirit-Aufträge fehlerfrei durchgelaufen sind. Alle Nachrichten auf dem CaaS-Bus müssen abgearbeitet und in die REST-Schnittstelle übernommen sein. Die Datenstrukturen und Routen des CaaS-Bus in CaaS 1.2 sind inkompatibel zur vorherigen CaaS-Version, so dass eine Übernahme von gesicherten Daten des CaaS-Bus vor Version 1.2 (KahaDB) hier keinen Sinn ergibt. Aus diesem Grund ist ein Backup der KahaDB des CaaS-Bus, wie in der Hauptdokumentation empfohlen, überflüssig. Dieser in der Haupt-Dokumentation beschriebene Schritt kann bei der Migration ausgelassen werden.

In nachfolgenden Unterkapitel beschreiben das Vorgehen für die jeweilige Umgebung.

17.3.1. Update CaaS-Stack im Linux-Betrieb

Das Update erfolgt über als Neu-Installation aller Komponenten in ein neues Zielverzeichnis. Eine Downtime tritt nur dann auf, wenn die vorherige REST-Schnittstelle des CaaS vor der Neuinstallation heruntergefahren wird. Die Neu-Installation wird das Installationsskript caas_installer-1.2.x.sh ausgeführt.

CaaS-MongoDB

Zur optionalen Übernahme des Datenbestand der REST-Schnittstelle aus der Vorversion ist ein Backup der MongoDB anzufertigen. Nähere Details zum Backup bzw. Update des CaaS-Stacks bzgl. MongoDB finden Sie in der CaaS Module-Dokumentation für den Betrieb mit Linux.

CaaS-Bus

Ein Backup der Daten des CaaS-Bus wird aus oben genannten Gründen (siehe Abschnitt Inkompatible Änderungen) ausgelassen.

17.3.2. Update CaaS-Stack im Docker-Betrieb

Die verschiedenen Komponenten des CaaS-Stacks können unabhängig voneinander aktualisiert werden. Beim Update auf Version 1.2 müssen mindestens die Komponenten Adapter und Bus aktualisiert werden.

Für die Inanspruchnahme von Support müssen jedoch alle Komponenten des CaaS-Stacks auf 1.2 angehoben werden. Nähere Details dazu finden Sie in der CaaS Module-Dokumentation für den Betrieb mit Docker.

Beide Komponenten können im laufenden Betrieb ausgetauscht werden.

Adapter
  • Import des neuen Adapter-Containers
    Der Import der Version 1.2 in das Docker-Repository erfolgt über den Befehl: docker load -i ./caas-adapter-v1.2.tar

  • Anpassung der docker-compose-Konfigurationsdatei
    Damit der CaaS-Stack die Adapter-Version 1.2 verwendet, muss das image: für den Container caas-adapter wie folgt angepasst werden:

    Adapter Version 1.2 - docker-compose.yml
    […]
    caas-adapter:
       […]
       image: e-spirit/caas-adapter:1.2
       links:
          - caas-bus
       […]
  • Update des Adapters im CaaS-Stack
    Der Austausch und Start des neuen Adapters erfolgt über den Befehl: docker-compose up --no-deps caas-adapter

Bus
  • Import des neuen Bus-Containers
    Der Import der Version 1.2 in das Docker-Repository erfolgt über den Befehl: docker load -i ./caas-bus-v1.2.tar

  • Anpassung der docker-compose-Konfigurationsdatei
    Damit der CaaS-Stack die Bus-Version 1.2 verwendet, muss das image für den Container caas-bus wie folgt angepasst werden. Darüber hinaus haben sich die ports auf den Wert 62626 geändert und sind entsprechend anzupassen.

    Bus Version 1.2 - docker-compose.yml
    […]
    caas-bus:
       […]
       image: e-spirit/caas-bus:1.2
       ports:
         - "62626:62626"
       […]
  • Update des Bus im CaaS-Stack
    Der Austausch und Start des neuen Bus erfolgt über den Befehl: docker-compose up --no-deps caas-bus

17.4. Generierungsaufträge in FirstSpirit anpassen

Die Aufträge für die CaaS-Vollgenerierung sowie die CaaS-Deltagenerierung sind anzupassen. Die Schritte sind in den folgenden Unterkapiteln beschrieben.

Alternativ können die vorhandenen Aufträge gelöscht und neu angelegt werden.

Details zur Konfiguration der Aufträge finden Sie in der jeweiligen CaaS Module-Dokumentation für den Betrieb mit Linux bzw. Docker.

17.4.1. Vollgenerierung

Öffnen Sie dazu die Server- und Projektkonfiguration und wählen Sie den Bereich Projekt-Eigenschaften  Auftragsverwaltung. Bearbeiten Sie dort den bereits bestehenden Auftrag für die CaaS-Vollgenerierung.

Der Auftrag muss die folgenden Aktionen in der gezeigten Reihenfolge enthalten:

fullgeneration
Abbildung 3. Vollgenerierung ab Version 1.2

Die Namen der gezeigten Aktionen sind frei konfigurierbar und tragen jene Namen, die in der CaaS Module-Dokumentation verwendet wurden.

Initialize CaaSGeneration

Der in dieser Aktion ehemals verwendete Skriptaufruf muss ersetzt werden durch:
com.espirit.caas.generation.CaaSScheduleInitializer

Activate Generation

Die ehemals an zweiter Position stehende Aktion Activate Generation (mit dem Skriptaufruf com.espirit.moddev.uxbridge.inline.UxbInlineUtil) ist zu löschen. Selektieren Sie die Aktion und klicken Sie auf Löschen.

CaaS Generate

keine Änderung erforderlich.

Result Handler

die ehemals an vierter Position stehende Aktion Result Handler (mit dem Skriptaufruf com.espirit.moddev.uxbridge.inline.UxbResultHandler) ist zu löschen.

Notieren Sie vorher den Wert des Parameters messageTimeout.

Selektieren Sie die Aktion und klicken Sie auf Löschen.

Gehen Sie zurück zu Initialize CaaSGeneration und öffnen Sie anschließend die Eigenschaften des Skripts. Legen Sie über Hinzufügen den Parameter messageTimeout an und tragen Sie hier den Wert ein, der in der gelöschten Aktion Result Handler verwendet wurde.

CleanUp

der in dieser Aktion ehemals verwendete Skriptaufruf muss ersetzt werden durch:
com.espirit.caas.generation.CaaSCleanupExecutable

Finalize CaaS Generation

Die Aktion Finalize CaaS Generation ist an vierter und letzter Position neu zu erstellen. Fügen Sie ein weiteres Skript hinzu, das den folgenden Aufruf enthält:

Finalize CaaS Generation
#! executable-class
com.espirit.caas.generation.CaaSScheduleFinalizer

17.4.2. Deltagenerierung

Öffnen Sie dazu die Server- und Projektkonfiguration und wählen Sie den Bereich Projekt-Eigenschaften  Auftragsverwaltung. Bearbeiten Sie dort den bereits bestehenden Auftrag für die CaaS-Deltagenerierung.

Der Auftrag muss die folgenden Aktionen in der gezeigten Reihenfolge enthalten:

deltageneration
Abbildung 4. Deltagenerierung ab Version 1.2

Die Namen der gezeigten Aktionen sind frei konfigurierbar und tragen jene Namen, die in der CaaS Module-Dokumentation verwendet wurden.

Initialize CaaSGeneration

Der in dieser Aktion ehemals verwendete Skriptaufruf muss ersetzt werden durch:
com.espirit.caas.generation.CaaSScheduleInitializer

Activate Generation

Die ehemals an zweiter Position stehende Aktion Activate Generation (mit dem Skriptaufruf com.espirit.moddev.uxbridge.inline.UxbInlineUtil) ist zu löschen. Selektieren Sie die Aktion und klicken Sie auf Löschen.

Calculate Changes

Der in dieser Aktion ehemals verwendete Skriptaufruf muss ersetzt werden durch:
com.espirit.caas.generation.CaaSDeltaGenerationExecutable
Optional kann die Aktion zudem in CaaS DeltaGeneration umbenannt werden, um eine Übereinstimmung mit der CaaS Module-Dokumentation zu erreichen.

CaaS Generate

keine Änderung erforderlich.

Result Handler

die ehemals an fünfter Position stehende Aktion Result Handler (mit dem Skriptaufruf com.espirit.moddev.uxbridge.inline.UxbResultHandler) ist zu löschen.

Notieren Sie vorher den Wert des Parameters messageTimeout.

Selektieren Sie die Aktion und klicken Sie auf Löschen.

Gehen Sie zurück zu Initialize CaaSGeneration und öffnen Sie anschließend die Eigenschaften des Skripts. Legen Sie über Hinzufügen den Parameter messageTimeout an und tragen Sie hier den Wert ein, der in der gelöschten Aktion Result Handler verwendet wurde.

Finalize CaaS Generation

Die Aktion Finalize CaaS Generation ist an vierter und letzter Position neu zu erstellen. Fügen Sie ein weiteres Skript hinzu, das den folgenden Aufruf enthält:

Finalize CaaS Generation
#! executable-class
com.espirit.caas.generation.CaaSScheduleFinalizer

17.5. Seitenvariable in FirstSpirit anpassen

In Seitenvorlagen kann die Erzeugung der Generierung mit einer Variablen im CaaS-Ausgabekanal unterbunden werden. Dazu war ehemals die Seitenvariable uxbSkipMessage zu verwenden. Alle Vorkommnisse von uxbSkipMessage müssen ab Version 1.2 in caasSkipMessage umbenannt werden.

Verwenden Sie im CaaS-Ausgabekanal nur noch:

caasSkipMessage
$CMS_SET(#global.pageContext["caasSkipMessage"], true)$

17.6. Vollgenerierung durchführen

Es muss abschließend eine Vollgenerierung durchgeführt werden, damit die FirstSpirit-Inhalte wieder vollständig im CaaS vorliegen.

Nähere Details hierzu finden Sie in der jeweiligen CaaS Module-Dokumentation für den Betrieb mit Linux bzw. Docker.

17.7. Parallelbetrieb des CaaS und der UX-Bridge

Wie zuvor beschrieben, ist zum Betrieb des CaaS die UX-Bridge nicht mehr erforderlich. Falls Sie jedoch aufgrund eines anderen Anwendungsfalles die UX-Bridge parallel zum CaaS verwenden möchten, muss das UX-Bridge-Modul in Version 1.7.0 (oder höher) installiert sein.

Details zur Installation finden Sie im Installationshandbuch des UX-Bridge-Moduls.

18. Hilfe

Der Technical Support der e-Spirit AG bietet Kunden und Partnern qualifizierte technische Unterstützung zu allen Themen, die FirstSpirit™ als Produkt betreffen. Weitere Hilfe zu vielen relevanten Themen erhalten und finden Sie in auch in unserer Community.