fb
WSO2 9 Minuten

Immer die neueste version von WSO2-produkten mit WSO2 Updates 2.0

Rob Blaauboer
Rob Blaauboer
Integration Consultant & WSO2 Trainer
WSO2 update
Scrollen

WSO2 hat eine neue Art der Updates eingeführt, genannt Updates 2.0, die sich von der Methode, die wir bisher hatten, unterscheidet. Doch warum solltest du überhaupt updaten?

Eine Software, so sagen manche, ist nie vollendet. Nein, ich spreche nicht von den Problemen des Projektmanagements. Ich spreche von der Tatsache, dass Software wie WSO2, sich an neue Funktionalitäten anpasst und, ebenso wichtig, oft Komponenten verwendet, die andere entwickelt haben. Das heißt, dass es viele „bewegliche Teile“ gibt, die ständig Updates benötigen, um Teile des Codes hinzuzufügen, zu reparieren oder zu aktualisieren. 

Anders ausgedrückt: Updates sind notwendig, und du musst sie einplanen. Vielleicht ist es nicht im Voraus bekannt, wann ein Update verfügbar ist, aber es ist wichtig, dass du einen Prozess hast, um den Einsatz der Updates zu verwalten.

WSO2 Produkte aktualisieren oder nicht aktualisieren?

Man könnte sagen, das ist ein No Brainer. Aber du hast gerade gesagt, dass Updates notwendig sind. Und du hast Recht, das habe ich auch gesagt. Aber WSO2 Updates sind nur für zahlende Kunden verfügbar. Die Abo-Gebühren sind eine Einnahmequelle für WSO2 und ermöglichen es dem Unternehmen, seine Produkte weiterzuentwickeln, damit wir sie nutzen können. 

WSO2 Updates beinhalten Verbesserungen, die von WSO2 zusätzlich zu einer bereits veröffentlichten WSO2 Produktversion veröffentlicht werden. Mit Updates brauchst du nicht bis zum Release der nächsten Produktversion zu warten, um die Produkterweiterungen und Sicherheitskorrekturen zu erhalten. Für mich ist es ein Must-Have, wenn du WSO2 in deinem Unternehmen einsetzt. Dies ist keine hinterhältige Art und Weise, um den Produkt-Support zu bewerben, den wir bieten, nein, ich meine es todernst.

Wir entwickeln Software und Systeme nicht als Hobby, sondern um ein Geschäft zu betreiben. Das Geschäft verlässt sich auf die Systeme und eine Betriebsstörung kann ziemlich kostspielig sein. Außerdem stehen Organisationen in der heutigen Zeit unter einem Vergrößerungsglas. Die Medien berichten gerne über Organisationen, die Schwachstellen für alle Arten von Bedrohungen aufweisen. Wenn es um personenbezogene Daten geht, besteht aus Sicht der GDPR die Verpflichtung, eine Aufsichtsbehörde innerhalb von 72 Stunden zu informieren. Insgesamt sind das Dinge, die du wahrscheinlich gerne vermeiden möchtest. 

WUM versus Update 2.0

Bisher hatten wir WUM (WSO2 Update Manager), ein Kommandozeilen-Tool, das es uns ermöglichte, ein Repository zu erstellen und verfügbare Updates auf die Basisversion anzuwenden, um eine neue Version des Produkts mit einem Zeitstempel-Suffix zu erstellen. Wichtig zu wissen ist, dass der WUM mit einer „out of the box“ Version von WSO2 arbeitet, in der KEINE deiner Veränderungen, Parameter und Einstellungen übernommen wurden. Jede aktualisierte Version muss also so konfiguriert werden, dass sie deine Einstellungen widerspiegelt und anschließend getestet werden. 

Was nicht so bekannt ist, in neueren Versionen von WSO2 Produkten gibt es Befehle, um ein In-Place-Update durchzuführen. Mit diesen Tools wie update_linux, das im bin-Verzeichnis zu finden ist (z.B. in der WUM-Version des WSO2 API Manager 3.2.0), werden die Updates auf die jeweilige Version angewendet. 

WSO2 Updates 2.0 arbeiten von dem Verzeichnis aus, in dem sie installiert sind. Ein spezielles Kommando, z.B. wso2update_linux, sorgt dafür, dass für Kunden mit gültigem Product Support die Updates heruntergeladen und angewandt werden. Der Mechanismus ist ganz ähnlich wie bei WUM (Patches herunterladen und anwenden), wie du siehst, wenn du das Update mit -v (verbose) als zusätzlichen Parameter ausführt.

Updates und Hotfixes

Updates können z.B. aus Sicherheitskorrekturen, neuen Funktionen oder Verbesserungen oder Fehlerbehebungen an einem bestehenden Produkt bestehen. Wird ein Update durchgeführt, so wird der Update-Level inkrementiert. In unserem Beispiel ist der WSO2 API Manager Level 26.Updates can consist of, for instance, security fixes, new features or improvements or bug fixes on an existing product. When an update is applied, the update level is incremented. In our example the WSO2 API Manager level is 26.

Terminal

Wie du auf dem Bild sehen kannst, erhält das fiktive Unternehmen Acme nicht nur Updates für das WSO2 Produkt, sondern auch Hotfixes für auftretende Probleme, die behoben werden. Ein Hotfix ist eine Zip-Datei, die lokal hinzugefügt wird. ‚Other Corp‘ bekommt die Hotfixes als regelmäßige Updates.  As you can see from the image, the fictional company Acme updates the WSO2 product but also gets hotfixes for issues that occur and are fixed. A hotfix is a zip file that is added locally. ‘Other Corp’ gets the hotfixes as regular updates.  

Updates & Hotfixes

Mit Updates 2.0 arbeiten

Wie du sehen kannst, gibt es drei verschiedene Versionen für die drei Betriebssysteme, auf denen WSO2 laufen wird: 

  • Windows: wso2update_windows.exe
  • Linux: wso2update_linux
  • Mac: wso2update_darwin
Terminal

Es handelt sich hierbei nicht um Skripte, wie z.B. zum Starten von WSO2 (wso2server.sh), sondern um ausführbare Dateien. 

Wenn du ein WSO2-Produkt aktualisieren möchtest, ist der erste Schritt die Aktualisierung des Tools selbst. Dieses Bild zeigt den Ablauf unter Windows. Linux und Mac sind in etwa gleich, was die Schritte und die Funktionalität angeht. Zum Beispiel gibt es unter Windows nicht die Möglichkeit, ein Update rückgängig zu machen. Es ist also egal, welche Plattform du verwendest, ich zeige hier Windows. Im Allgemeinen würden wir empfehlen, eine Linux-Umgebung zu verwenden.  

Terminal

Welche Funktionen bietet das Tool?  

Wenn wir wissen wollen, was wir mit dem Tool tun können, zeigt die Hilfe des Parameters die Optionen an. Die Befehle und Flags können kombiniert werden, wie du an den Beispielen im Screenshot sehen kannst. 

Terminal

Es ist sehr wichtig zu wissen, dass es Befehle und Flags gibt, wie du auf dem Screenshot oben sehen kannst. Einige der Flags haben eine Abkürzung wie zum Beispiel ‚-p‘ für ‚–password‘. 

Das bereits erwähnte –revert ist kein Befehl, es ist ein Flag. Es gibt zwar einen revert-hotfix-Befehl, aber dieser ist speziell für Updates, die als Hotfixes bereitgestellt werden, also eine Zip-Datei, die du lokal zu deinem WSO2-Produkt hinzufügen musst. 

Anders als bei WUM gibt es bei uns keinen Update-Befehl, das Update wird durchgeführt, wenn wir das Tool starten. Wir können dem Tool auch Benutzer- und Passwortinformationen als zusätzliche Parameter zur Verfügung stellen. Dies ermöglicht es, den Prozess zu automatisieren; allerdings müssen Benutzername und Passwort im Klartext hinterlegt werden. Ein kurzer Check in Bezug auf das Passwort zeigt, dass es manchmal mit einem einfachen Anführungszeichen eingegeben werden muss, wie hier: -p ‚myPa55!word‘. Unter Linux werden Zeichen wie ! von der Bash für spezielle Zwecke verwendet. In dem Fall solltest du einfache Anführungszeichen um das Passwort setzen, denn dies zeigt an, dass dieser Teil nicht interpretiert werden soll. 

Mit dem Trockenlauf kannst du das Verfahren testen. Ein Testlauf führt alle Schritte zur Aktualisierung der Distribution aus, nimmt aber keine dauerhaften Änderungen vor. Dadurch können wir testen, ob die Aktualisierungsprozedur voraussichtlich erfolgreich abgeschlossen wird.

Terminal

Current state gibt den Level an, in diesem Fall 25.

Terminal

apply-hotfix erlaubt es dir, einen Hotfix zum Produkt hinzuzufügen. remove-hotfix (nicht gezeigt) entfernt ihn wieder. 

Terminal

Wie sieht der Status aus

Du kannst online die Update-Zusammenfassung für dieses Produkt sehen. Die URL ist https://updates-info.wso2.com. Mit einem Klick auf den türkisfarbenen Button (136 UPDATES) kannst du die einzelnen Updates einsehen.

WSO2 updates

Konflikte lösen

Es kann Situationen geben, in denen es einen Konflikt zwischen der aktuellen Version und dem eingehenden Update gibt. Das kann eine Konfigurationsdatei sein, oder ein Artefakt, das du angepasst hast. Hat eine Datei oder ein Artefakt Konflikte, so versucht das Update-Tool nicht, sie zusammenzuführen. In einer solchen Situation musst du die Anpassungen manuell auf die aktualisierten Dateien anwenden. 

Vor allem, wenn du den Update-Prozess automatisiert hast, kann das Auftreten von Konflikten zu einem Problem werden. In diesen Fällen könntest du in Betracht ziehen, den Update-Prozess auf einer nicht-angepassten Produktdistribution laufen zu lassen und Tools wie Ansible, Chef, Puppet etc. zu verwenden, um deine Anpassungen anzuwenden, sobald die Updates durch das WSO2 Updates Tool angewendet wurden.

Um Konflikte zu vermeiden, kannst du die Best Practices befolgen. Eine davon ist, die Jar-, War- oder Car-Dateien, die mit dem Produkt bereitgestellt werden, nicht zu verändern. Bei einem Update werden diese Dateien überschrieben und deine Änderungen sind verloren. Die War-Dateien (Web Application Resource File) werden aktualisiert, indem sie entarchiviert werden und die Updates laut WSO2 darauf angewendet werden. Wahrscheinlich werden alle War-Anpassungen nach dem Update beibehalten, aber überprüfe es auf jeden Fall!

Die von dir bereitgestellten Autodateien werden durch den Updateprozess nicht verändert, also mach dir keine Sorgen um sie. Für.jag/js und json Dateien ist es wichtig, sich an die ursprüngliche Aufteilung zu halten. Behalte auch die Reihenfolge der Parameter in json-Dateien so weit wie möglich bei und füge neue Schlüssel-Wert-Paare am Ende hinzu.

Falls du doch ein Problem hast, sind dies die drei einfachen Schritte. Wenn wir *.original sagen, steht das * für eine oder mehrere Dateien.

  1. Finde die Dateien, die im Konflikt sind und vom Tool gemeldet werden;
  2. Finde die *.original Datei (was in deinem aktuellen Setup ist) und die *.new (was in deinem Update ist);
  3. Löse die Probleme und speichere sie als *.final. Starte das Update mit –continue und überprüfe das Ergebnis. Alle Konfliktdateien sollten verschwunden sein (original, neu und final).

Arbeiten mit Docker

Docker

Eine der Funktionen, die mir gefällt, ist die Möglichkeit, ein Docker-Image aus dem aktualisierten Produkt zu erstellen, das wir gerade erstellt haben. Das Image wird lokal in Docker gespeichert und du kannst es als Basis-Image für dein neues Produkt verwenden.

Docker

Du kannst sehen, dass wir eine aktualisierte Version zum Docker Repo hinzugefügt haben.

Regelmäßige Updates der WSO2 Produkte

In diesem Blog wird ein Überblick über das WSO2 Updates 2.0 Tool gegeben. Mit diesen Informationen kann man einen Prozess der regelmäßigen Updates einrichten, allerdings bedarf es dazu noch einiges mehr. Ich meine damit das Skripting (Ansible), das Testen, das Deployment und die Automatisierung von allem. 

Das Tool WSO2 Updates 2.0 ermöglicht es den Benutzern, eine bereits vorhandene Konfiguration zu aktualisieren. Das vorherige WUM-Tool ermöglichte es, nur die von WSO2 bereitgestellten Produktversionen zu aktualisieren. Allerdings gab es, wie wir gesehen haben, auch die Möglichkeit, ein In-Place-Update mit dem Update-Befehl (z.B. update_windows.exe) durchzuführen. Beide Methoden haben ihre Vor- und Nachteile. 

Die Anwendung von Updates auf die von WSO2 bereitgestellte Installation, ohne eigene Anpassungen, verhindert, dass es zu Update-Konflikten mit einer bestehenden Installation kommt. Eventuelle Update-Probleme können frühzeitig gelöst werden, bevor sie in einer Live-Umgebung angewendet werden. Diese Vorgehensweise bedeutet jedoch, dass du die Installation und Konfiguration deiner Umgebung automatisieren solltest, denn bei jedem Update musst du das WSO2-Produkt neu in der Umgebung bereitstellen.

Mit dem WSO2 Updates 2.0 Lösungsansatz ist ein solches Re-Deployment nicht mehr erforderlich. Du kannst nun wählen, ob du die Updates auf eine Live-Umgebung anwendest oder auf die von WSO2 zur Verfügung gestellte, nicht-angepasste Installation und den Rollout des Updates durch einen automatisierten Bereitstellungsprozess. 

In jedem Fall ist es empfehlenswert, einen Testzyklus des Updates durchzuführen. So kannst du testen, ob das Update wie erwartet angewendet wird und nichts kaputt geht.

Falls du deine WSO2-Installation selbst managen musst, dann empfehlen wir, die Installation und Konfiguration deiner WSO2-Produkte zu automatisieren, denn das erhöht die Reproduzierbarkeit deiner Installation und erleichtert den Aufwand für die Anwendung von Updates und den Rollout in deiner Umgebung.

Falls dir das alles zu kompliziert erscheint, solltest du einen Blick auf unser Connext Produkt werfen, bei dem wir die WSO2 Produkte für dich hosten, installieren und konfigurieren. So kannst du dich auf dein Hauptgeschäft konzentrieren und uns das API Management, die Integration und das Identity & Access Management mit WSO2 für dich erledigen lassen!