In meinen bisherigen Blog-Beiträgen habe ich mich mit Kundenprojekten und den Vorteilen von b4A Packages beschäftigt. Diesmal ein sehr technisches Thema, das aber meiner Meinung nach mit der zunehmenden Nutzung der Automic REST Schnittstelle immer wichtiger wird.
Die Automic REST Schnittstelle ist in vielen produktiven Umgebungen eine kritische Komponente, die bei einem Ausfall den Betrieb stark beeinträchtigt.
In diesem Blog bescheibe ich auf Basis der aktuellen Version v21 wie die Automic REST Schnittstelle redundant konfiguriert werden kann.
In der Automic Standardinstallation ist eine REST Instanz mit Port 8088 konfiguriert. Jede weitere Instanz muss mit einem anderen Port konfiguriert werden oder auf einer anderen Maschine laufen. Auf jeden Fall gibt es keine eindeutige URL, mit der alle REST Instanzen gemeinsam aufgerufen werden können. Natürlich könnte der Client so erweitert werden, dass mehrere URLs nacheinander aufgerufen werden, aber das wird von den wenigsten Clients unterstützt.
Im zweiten Teil dieses Blogs beschäftige ich mich damit, wie beispielhaft die NGINX Lösung als Loadbalancer vorgeschaltet werden kann.
In der verteilten Architektur der Automic Automation Engine wird die REST-Schnittstelle durch einen eigenständigen REST-Prozess zur Verfügung gestellt. Dieser kann mehrfach instanziiert werden, sofern zuvor der Netzwerk-Port der REST-Instanz geändert wurde.
Wie alle Automation Engine Komponenten wird auch der REST Netzwerk Port in der ucsrv.ini konfiguriert. Sollen mehrere REST Instanzen auf einer Maschine laufen, müssen entsprechend mehrere Kopien der ucsrv.ini angelegt werden, z.B. mit dem Namen ucsrv_8089.ini . In dieser Datei wird der REST-Port auf 8089 konfiguriert.
Dazu gibt es in der Sektion REST die Konfigurationseigenschaft ‚REST‘.:
[REST]
PORT=8089
Bei dem Starten der REST Instanz wird per Kommandozeilenparameter auf die ucsrv_8089.ini referenziert.
java -Xmx2G -jar ucsrvjp.jar -Iucsrv_8089.ini -svc%port% -rest
Ich habe dazu in dem Automic Service Manager REST Eintrag dupliziert und entsprechend geändert. So wird der Automic Service Manager immer zwei REST Instanzen starten.
In der Prozess Liste im AWI unter Administration – Automation Engine Management – Prozesses und Utilizationerscheinen jetzt zwei REST Instanzen.
Jede dieser beiden Instanzen kann für die REST Kommunikation verwendet werden, allerdings sind dazu zwei unterschiedliche URLs erforderlich. Um das zu vermeiden wird ein ‚Loadbalancer‘ benötigt. Dieser leitet alle REST Anfragen jeweils zu einer der beiden REST Instanzen weiter. Dabei können Loadbalancing Strategien konfiguriert werden, eine Einführung in Loadbalancing Strategien würde den Rahmen dieses Blogs sprengen.
Exemplarisch für andere Loadbalancer beschreibe ich die Konfiguration eines NGINX.
Die folgende englische Beschreibung ist schon etwas älter, beschreibt aber den Installationsvorgang verständlich Aaron Kill – How to Use Nginx as an HTTP Load Balancer in Linux. Unter Windows bietet sich der Loadbalancer von Microsoft an, aber ich habe nicht genug Erfahrung, um hier eine Konfiguration auszuarbeiten.
Nach erfolgreicher Installation muss nur noch die
etc/nginx/conf.d./loadbalancer.conf
konfiguriert bzw. erstellt werden. Der Aufbau der Konfigurationsdatei ist eigentlich selbsterklärend.
Dieses Beispiel stellt die ‚loadbalanced‘ REST Interface über den Port 8099 zur Verfügung und erwartet die Automic REST Prozesse auf dem Ports 8088 und 8089.
Da der NGINX auch ein Webserver ist, muss dieser noch abgeschaltet werden. Dies erfolgt in der
etc/nginx/nginx.conf
Im dem die server Sektion mit Hilfe von ‚#‘ Zeichen auskommentiert wird.
Nachdem der NGINX konfiguriert ist, muss er gestartet werden.
systemctl start nginx
Mit Hilfe des Befehls status kann überprüft werden ob NGINX gestartet ist.
systemctl status nginx
NGINX speichert log Informationen im /var/log/nginx Verzeichnis. Die Dateinamen sind selbsterklärend, wobei zu beachten ist, dass die access.log Datei sehr schnell sehr groß werden kann.
Ich hoffe, dass ich Sie als Automic-Anwender mit diesem Beitrag über dieses immer wichtiger werdende Thema detailliert informieren konnte und möchte Sie ermuntern, bei weiteren Fragen, die dieser Blog nicht abdecken konnte, mit mir in Kontakt zu treten.
Kay Koll berät und unterstützt seit über 30 Jahren Geschäftskunden in unterschiedlichen Rollen. In den letzten 15 Jahren lag sein Schwerpunkt auf der Automatisierung von Geschäftsprozessen.
Als Pre-Sales Engineer und Solution Architect war er beim Hersteller der Automic Automation Lösung für den technischen Teil des Verkaufsprozesses verantwortlich.
In seiner Rolle als Business Technology Manager bei best-blu consulting with energy sieht er sich als Trusted Adviser für Automic und Camunda Driven Automation.