Aktualisiert 2024-11-14
Einführung
Dies ist die Dokumentation zum Bereitstellen und Betreiben der REI3-Anwendungsplattform. Kenntnisse für die Zielinfrastruktur (Windows Server oder Linux) werden vorausgesetzt. Nach der Installation können Administratoren REI3-Anwendungen aus Online- oder lokalen Repositorys in Infrastrukturen mit oder ohne Internetzugang bereitstellen.
Bereitstellungsmodelle
Abhängig von der verfügbaren IT-Infrastruktur und wie REI3 eingesetzt werden soll, existieren verschiedene Bereitstellungsmodelle:
Dediziert | Eigenständig | Portable | Docker | |
---|---|---|---|---|
Entworfen für | Produktion | Produktion | Test & Bau von REI3-Anwendungen | Test & Bau von REI3-Anwendungen |
Integrierte Datenbank | X | X | X | |
Läuft unter Windows | X | X | X | X |
Läuft unter Linux | X | X |
Falls eigene REI3-Anwendungen erstellt werden sollen, ist es ratsam, diese auf einen System zu erstellen und dann auf einen anderen System auszurollen. Hierdurch werden Endbenutzer erst dann betroffen, wenn Anwendungen getestet und bereit sind. Besonders die portablen und Docker-Versionen bieten sich für das Entwickeln von Anwendungen an.
Dediziert
Das häufigste Bereitstellungsmodell. REI3 wird auf einem Anwendungsserver (Windows oder Linux) installiert und mit einem separaten Datenbanksystem verbunden.
Eigenständig
Diese Option ist nur unter Windows Server verfügbar. Die eigenständige Bereitstellung hat fast keine externen Abhängigkeiten und verfügt über eine eigene Datenbank. Es ist das empfohlene Modell für Unternehmen mit kleinen IT-Teams.
Portable
Für Entwicklungs- und Testinstanzen - die portable Version von REI3 kann auf Windows-Clients ohne jegliche Einrichtung gestartet werden. Wie das eigenständige Modell verfügt auch die portable Version über eine eigene Datenbank. Es wird nicht empfohlen, eine portable Instanz produktiv zu nutzen.
Docker
Für Entwicklungs- und Testinstanzen steht eine Docker Compose-Datei zur Verfügung, um schnell eine REI3-Instanz zu starten. Diese Datei ist jedoch nicht für den produktiven Einsatz konfiguriert. Um REI3 produktiv mit Docker zu betreiben, können die bereitgestellten Dateien als Vorlagen verwendet und an die Zielumgebung angepasst werden. Weitere Details finden sich auf der Repository-Seite.
Technische Anforderungen
Server
Um REI3 ausführen zu können, müssen folgende Anforderungen erfüllt sein:
- Betriebssystem (eines davon)
- Linux (getestet unter Debian, NixOS und Ubuntu Server)
- Windows Server 2016 oder höher
- Windows 10 oder höher (portable Version)
- Prozessor
- Intel-, AMD- oder ARM-Prozessor (x64 oder ARM64), mehrere Kerne verbessern die Leistung
- Arbeitsspeicher
- 4+ GB
- Speicherplatz
- 500 MB für REI3 selbst
- 20+ GB für die Datenbank und hochgeladene Dateien (skaliert mit Nutzung)
- Software
- Linux-Server
- Optional: ImageMagick (für Thumbnails)
- Optional: Ghostscript (für PDF-Thumbnails)
- Optional: PostgreSQL-Client-Werkzeuge (für integrierte Backups)
- Windows-Server
- Notwendig: Microsoft Visual C++ 2015 (oder neuer)
- Optional: Ghostscript (Thumbnails für PDF-Dateien)
- Linux-Server
- Datenbank (nur dedizierte Bereitstellung)
- PostgresSQL Datenbank (13.0 oder neuer), UTF8 enkodiert, mit vollen Berechtigungen
Endgeräte
Für den Zugriff auf eine laufende REI3-Instanz kann jeder moderne Browser verwendet werden, wie bspw. Firefox, Chrome oder Safari. Dies schließt mobile Browser ein. REI3 verwendet moderne Webstandards; "Internet Explorer" wird nicht unterstützt.
Installation
Unter Windows Server
REI3 wird mit einem grafischen Installationsprogramm für Windows Server geliefert. Das Installationsprogramm unterstützt sowohl eigenständige als auch dedizierte Bereitstellungsmodelle.
- Eigenständig: Nach Ausführung des Installationsprogrammes kann REI3 sofort gestartet werden.
- Dediziert: Nach der Installation müssen Datenbankverbindungsdetails für eine leere, UTF8-enkodierte PostgreSQL-Datenbank (13.0 oder neuer) in der Konfigurationsdatei
config.json
eingetragen werden. Die Dateiconfig.json
befindet sich im ausgewählten Anwendungsverzeichnis. Der Datenbankbenutzer muss volle Berechtigungen für die gewählte Datenbank haben.
Unabhängig vom Bereitstellungsmodell, wird REI3 unter Windows Server als Windows-Dienst behandelt und kann über den Service-Manager gestartet werden (Befehl: services.msc
). Falls der Dienst nicht starten kann, schreibt REI3 in das Windows-Applikationslog.
Aus lizenzrechtlichen Gründen können wir Ghostscript nicht zusammen mit REI3 ausliefern. Wenn Sie PDF-Thumbnails erstellen möchten, müssen Sie eine aktuelle Version von Ghostscript herunterladen und auf dem REI3-Server installieren.
Auf einem Linux-Server
Für Linux-Server ist REI3 als komprimiertes Archiv mit vorkompilierten Binärdateien verfügbar. Die Installationsschritte sind:
- Extrahieren Sie das REI3-Archiv in ein Verzeichnis Ihrer Wahl (
/opt/rei3/
zum Beispiel). - Machen Sie die Datei
r3
ausführbar (chmod u+x r3
). - Kopieren Sie die Datei
config_template.json
zuconfig.json
- die Datei muss im gleichen Verzeichnis sein wie die ausführbare Dateir3
. - Fügen Sie der Datei
config.json
Verbindungsdetails zu einer leeren, UTF8-enkodierten PostgreSQL-Datenbank (13.0 oder neuer) hinzu. Der Datenbankbenutzer muss volle Berechtigungen für die gewählte Datenbank haben. - Optional: Installieren Sie ImageMagick und Ghostscript falls Thumbnails erwünscht sind (
sudo apt install imagemagick ghostscript
). - Optional: Installieren Sie PostgreSQL-Client-Werkzeuge falls Sie die integrierte Backup-Funktion nutzen möchten (
sudo apt install postgresql-client
). - Registrieren Sie REI3 im Service-Manager (
sudo ./r3 -install
). - Starten Sie den REI3-Dienst (
systemctl start rei3
zum Beispiel).
Sollte der Dienst nicht starten, schreibt REI3 ins syslog
.
Erster Zugriff auf REI3
Während der Ausführung ist REI3 standardmäßig über Port 443 erreichbar. Sie können jeden modernen Browser verwenden, um lokal auf REI3 unter https://localhost/
oder über das Netzwerk mit einer entsprechend konfigurierten Firewall zuzugreifen. Während der Installation wird ein einzelner Administratorbenutzer erstellt. Benutzername und Passwort sind jeweils auf "admin" gesetzt.
Nach der Anmeldung kann auf die Adminoberfläche zugegriffen werden, um Benutzer zu verwalten, Anwendungen zu installieren, auf Systemprotokolle zuzugreifen usw. Das Standardkennwort sollte sofort nach der ersten Anmeldung geändert werden.
Konfiguration
Die Kernkonfiguration von REI3 kann in der Konfigurationsdatei (config.json
) geändert werden, die sich im ausgewählten REI3-Installationsverzeichnis befindet. Das Festlegen von Dateipfaden, Webserver-Port und Datenbankverbindungsdetails ist unkompliziert. Änderungen werden beim Neustart des Anwendungsdienstes angewendet.
SSL-Zertifikate
Während der Installation erstellt REI3 ein selbstsigniertes Zertifikat, um den verschlüsselten Zugriff auf die Anwendung zu ermöglichen. Es wird nicht empfohlen, dieses Zertifikat dauerhaft zu nutzen. Wenn möglich, sollte für REI3 ein ordnungsgemäß signiertes Zertifikat bereitgestellt werden, um eine sichere Kommunikation mit Vertrauen zwischen Endgeräten und Server zu gewährleisten.
Einige allgemeine Überlegungen / Fallstricke:
- REI3 kann mit verschiedenen Zertifikaten arbeiten. Wenn REI3 ein Zertifikat nicht laden kann, startet es nicht und protokolliert in das Betriebssystem (
syslog
für Linux, sonst Windows-Applikationslog). - Stellen Sie sicher, dass der Hostname im Zertifikat, derselbe ist, den die Clients zum Zugriff auf den REI3-Server verwenden. Der Port ist irrelevant.
- Wenn Sie REI3 intern betreiben (nicht über die Cloud erreichbar), müssen die Clients das Zertifikat trotzdem überprüfen können. Stellen Sie sicher, dass Ihre Zertifikatsdatei (*.crt) alle Zertifikate in der Kette bis zu dem Zertifikat enthält, das den Clients bekannt ist - dies ist in der Regel ein vertrauenswürdiges Stamm- oder Zwischenzertifikat.
Proxies
Wenn Clients mit einem REI3-Server kommunizieren, verwenden sie zwei Methoden - beide laufen über den gleichen Port (normalerweise 443) als TCP:
- HTTP(S)-Anfragen, um Dateien, Bilder und andere Webressourcen zu laden.
- Eine kontinuierliche Websocket-Verbindung für den bidirektionalen Datenaustausch zwischen Server und Client. Wenn diese Verbindung unterbrochen wird, versucht der Client, diese wiederherzustellen.
Bei Proxy-Servern (egal ob Forward- oder Reverse-Proxy) können HTTP(s)-Anfragen wie jede andere Webanwendung behandelt werden. Daher sind Good-Practices wie Anfrage-Timeouts sinnvoll.
Websockets hingegen sollen so lange aktiv bleiben, bis eine der beiden Seiten (Server oder Client) die Verbindung absichtlich schließt. Dies kann aufgrund von Ereignissen wie einem Logout oder einem Server, der in den Wartungsmodus geht, geschehen. Bei der Konfiguration eines Proxys sollte das Anfrage-Timeout für Websocket-Verbindungen deaktiviert oder zumindest auf mehrere Stunden eingestellt werden. Einige Proxys (wie HAProxy) nennen diese Verbindungen "Tunnel" statt "Client" oder "Server". Jedes Mal, wenn eine Websocket-Verbindung von einem Proxy zwangsweise geschlossen wird, muss der Client die Verbindung neu aufbauen und es können ungespeicherte Änderungen verloren gehen.
Im Falle von Cluster-Setups muss eine Websocket-Verbindung bei einem bestimmten Server 'hängen bleiben', bis sie geschlossen wird. Auch wenn die ersten Anfragen z.B. über Round-Robin zugewiesen werden, ist ein bestimmter Server für die laufende Websocket-Kommunikation mit einem bestimmten Client zuständig. HTTP(S)-Anfragen können jedoch jederzeit von einem beliebigen Cluster-Server bearbeitet werden.
Allgemeine Administration
Nach der Konfiguration werden grundsätzlich alle administrativen Aufgaben über die Adminoberfläche in der REI3-Hauptwebanwendung ausgeführt. Jeder Benutzer, der als "Administrator" definiert ist, hat vollen Zugriff auf diese Funktionen.
Wartungsmodus
Um tiefgreifende Systemänderungen sicher auszuführen, steht ein separater Betriebsmodus zur Verfügung, der als "Wartungsmodus" bezeichnet wird. Wenn dieser aktiviert ist, werden alle Benutzer, die keine Administratoren sind, vom System abgemeldet. Neue Anmeldungen von Nicht-Administratoren werden abgelehnt.
Im Wartungsmodus können Anwendungen installiert, konfiguriert und gelöscht werden. Bitte beachten Sie, dass durch das Löschen von Anwendungen alle entsprechenden Daten dauerhaft aus dem System gelöscht werden. Dies ist ohne aktuelle, funktionale Backups nicht rückgängig zu machen.
Builder-Modus
Wenn das System im Wartungsmodus ist, kann zusätzlich der Builder-Modus aktiviert werden. Dies ermöglicht Adminbenutzern Zugriff auf das integrierte, grafische Anwendungsentwicklungswerkzeug, kurz 'Builder' genannt.
Der Builder ist ein umfangreiches Werkzeug. Alle REI3-Anwendungen werden ausschließlich über den Builder erstellt und geändert. Bitte beachten Sie, dass das Ändern von Anwendungen dauerhafte Konsequenzen bis hin zum Datenverlust hat. Versuchen Sie nicht, den Builder in einer produktiven Instanz zu verwenden. Zum Testen oder Entwickeln von Anwendungen sollte eine separate Instanz verwendet werden. Die portable Version macht dies für Windows-Endgeräte einfach. Unter Linux dient ein separater Anwendungsdienst, der auf eine separate Datenbank zugreift, demselben Zweck.
Authentifizierung und Autorisierung
Um Benutzern den Zugang zum System zu ermöglichen, müssen diese von einem REI3-Administrator erstellt oder von einem Verzeichnisdienst importiert werden. Benutzernamen können alles sein, von persönlichen Namen über Mitarbeiter-IDs bis hin zu E-Mail-Adressen - sie müssen nur eindeutig innerhalb einer REI3-Instanz sein.
Um auf eine Anwendung oder Daten zugreifen zu können, müssen Benutzern Rollen zugewiesen werden. Dies kann durch einen REI3-Administrator manuell geschehen oder sie können automatisch anhand von Gruppenmitgliedschaften innerhalb eines Verzeichnisdienstes zugewiesen werden. Rollenberechtigungen sind kumulativ - je mehr Rollen ein Benutzer hat, desto umfangreicher ist der Zugriff.
Um die Kontosicherheit zu erhöhen, können REI3-Administratoren in der Admin-Oberfläche Optionen für die Passwortkomplexität auswählen. Darüber hinaus steht den Benutzern MFA (Multi-Faktor-Authentifizierung) in Form von TOTP (zeitbasierte Einmal-Passwörter) zur Verfügung, die von den Administratoren zurückgesetzt werden können. MFA kann auf mehreren Geräten eingerichtet werden und wird von den meisten Authenticator-Apps unterstützt (alles, was TOTP unterstützt).
Authentifizierung und Autorisierung über LDAP
REI3 hostet ein internes Authentifizierungs-Backend. Zur Integration in vorhandene Infrastrukturen kann REI3 LDAP-Dienste nutzen, um folgendes anzubieten:
- LDAP-Authentifizierung: Benutzerkonten werden regelmäßig von LDAP importiert. Anmeldedaten werden dann live während des Anmeldeversuches gegen das LDAP geprüft.
- Bei der Verwendung mehrfacher LDAP-Verbindungen (oder beim Mischen lokaler Benutzer mit Benutzern aus LDAP) können duplikate Benutzernamen existieren. LDAP-Verbindungen können konfiguriert werden, um E-Mail-Adressen oder andere Attribute für Benutzernamen zu nutzen.
- Nur Microsoft-AD: Wenn ein Benutzerkonto deaktiviert wird, werden Sitzungen dieses Benutzers während des nächsten LDAP-Imports automatisch geschlossen.
- LDAP-Autorisierung: Durch das Auslesen von Gruppenmitgliedschaften können Anwendungsrollen automatisch Benutzern zugewiesen werden.
- Nur Microsoft-AD: Verschachtelte Gruppenmitgliedschaften werden automatisch aufgelöst.
Anwendungen verwalten
Um REI3 nutzen zu können, müssen Anwendungen installiert werden. Um Anwendungen zu verwalten, muss zuerst der Wartungsmodus aktiviert werden.
Anwendungen werden über die Adminoberfläche installiert. Sie können aus mehreren Quellen abgerufen werden:
- Offizielles Repository: Vorinstalliertes Repository für offizielle REI3-Anwendungen. Für den Zugriff auf diesen Onlinedienst ist ein Internetzugang erforderlich.
- Lokales Repository: Für Organisationen, die mehrere REI3-Instanzen ausführen und/oder die vollständige Kontrolle über alle Veröffentlichungen benötigen. Ein Repository kann auf jeder REI3-Instanz installiert werden, da es sich auch um eine REI3-Anwendung handelt.
- Manueller Import von Anwendungen: Alle Anwendungen können manuell importiert werden. Dies ist nützlich für Entwicklungsversionen, Tests und für Anwendungen, die in keinem Repository veröffentlicht wurden.
Unternehmen, die mit REI3 beginnen, sollten mit dem offiziellen Repository starten und zu lokalen Repositorys wechseln, wenn sie skalieren oder selbst entwickelte Anwendungen im Fokus stehen.
Sicherung und Wiederherstellung
Um eine REI3-Instanz vollständig wiederherzustellen, müssen diese Komponenten gesichert werden:
- Die REI3-Datenbank
- Die REI3-Konfigurationsdatei (
config.json
) - Verzeichnisse (können umbenannt werden in
config.json
)certificates
(verwendete SSL-Zertifikate)files
(hochgeladene Dateien)transfer
(installierte Anwendungen)
Die integrierte Backup-Funktion sichert automatisch alle erforderlichen Daten, wenn sie in der Admin-Oberfläche aktiviert ist und Abhängigkeiten installiert sind.
Bei größeren Systemen reicht die integrierte Backup-Funktion möglicherweise nicht aus; sie kann nur Vollsicherungen erstellen, die zwar sehr sicher sind, aber mehr Zeit und Speicherplatz benötigen als andere Sicherungsmethoden. Bei wachsenden Datenbeständen sollten Sie auch inkrementelle/differenzielle Sicherungen in Betracht ziehen; diese erfordern mehr Aufwand und möglicherweise Infrastruktur und sind nicht Teil dieser Dokumentation.
Datenbank
In jedem Bereitstellungsmodell wird eine PostgreSQL-Datenbank für REI3 verwendet. Um auf die eigenständige, integrierte Datenbank zuzugreifen, verwenden Sie die Verbindungsdetails aus der REI3-Konfigurationsdatei (config.json
), während der REI3-Dienst ausgeführt wird. Die Datenbank heißt standardmäßig "app".
Für vollständige Sicherungen empfehlen wir die Verwendung interner PostgreSQL-Werkzeuge wie pg_dump
zum Sichern und pg_restore
zum Wiederherstellen der Datenbank. Beispiele:
- Um in ein Zielverzeichnis zu sichern: pg_dump -h HOSTNAME -p 5432 -U USERNAME -Fd -f TARGETDIR
- Um aus einem Verzeichnis wiederherzustellen: pg_restore -h HOSTNAME -p 5432 --no-owner -U USERNAME -d TARGETDBNAME SOURCEDIR
Empfehlungen:
- Sichern Sie immer an einem separaten Netzwerkspeicherort, zur Absicherung gegen einen totalen Systemausfall.
- Wiederherstellungen vollständiger Sicherungen sollten immer in eine leere / neue Datenbank ausgeführt werden, um sicherzustellen, dass alle Daten in den gesicherten Zustand zurückversetzt werden können. Die wiederhergestellte Datenbank kann dann umbenannt oder die REI3-Konfigurationsdatei aktualisiert werden, um auf die wiederhergestellte Datenbank zuzugreifen.
Aktualisierungen
Es gibt zwei Arten von Aktualisierungen: Anwendung- und Plattformaktualisierung. Anwendungsaktualisierungen sind häufiger und dienen dazu, die Funktionalität für REI3-Anwendungen zu erweitern. Diese können direkt von der Adminoberfläche installiert werden, wenn der Wartungsmodus aktiv ist. Wenn die Aktualisierungen über das Repository empfangen werden, handelt es sich um einen Ein-Klick-Vorgang. Manuelle Aktualisierungen müssen über gepackte Anwendungsdateien bereitgestellt werden. Es wird empfohlen, Aktualisierungen zuerst in Testumgebungen zu installieren, da sich Aussehen und Verhalten zwischen Anwendungsversionen ändern können.
Plattformaktualisierungen richten sich an die zugrunde liegende Plattform-Software und sind möglicherweise auch für Anwendungsaktualisierungen erforderlich, wenn für diese neuere Plattformfunktionen erforderlich sind. Da Sicherheits- und Stabilitätsprobleme mit Plattformaktualisierungen behoben werden, ist es immer gut, die Plattform selbst zu aktualisieren.
Plattformaktualisierung
Wenn das grafische Installationsprogramm für Windows verwendet wird, kann durch Ausführen einer neueren Version die Aktualisierung gestartet werden. Der Plattformdienst wird automatisch neu gestartet.
Bei Linux-Servern ist es erforderlich, den Dienst zu stoppen und Dateien im ausgewählten Anwendungsverzeichnis mit dem neuesten extrahierbaren Paket zu überschreiben. Danach kann der Dienst neu gestartet werden.
Um die portable Version zu aktualisieren, stoppen Sie alle laufenden REI3-Instanzen und extrahieren Sie den Inhalt einer neueren, portablen Version in das Anwendungsverzeichnis.
Clusterbetrieb und Systemleistung
REI3-Server können in Clustern betrieben werden, um mehr Anfragen und Benutzer gleichzeitig zu verarbeiten. Bevor Sie ein Clusterbetrieb in Erwägung ziehen, ist es wichtig zu wissen, woher wahrgenommene Leistungsprobleme kommen. REI3 ist für die gleichzeitige Bearbeitung vieler Benutzer ausgelegt und kann auch mehrere Prozessorkerne sowie mehr Arbeitsspeicher nutzen, um die Leistung zu verbessern. Nur wenn die CPU-Last/Speichernutzung des REI3-Dienstes häufig sehr hoch ist, kann der Clusterbetrieb mehrerer REI3-Server sinnvoll sein.
In den meisten Fällen sind die Leistungsprobleme auf andere Ursachen zurückzuführen:
- Hohe Datenbanklast. Beim Betrieb größerer REI3-Instanzen kann die Menge der Anfragen das Datenbanksystem überfordern. Dies lässt sich feststellen, indem man sich mit dem Datenbankserver verbindet und sich seine Statistiken ansieht. In diesem Szenario befindet sich der REI3-Dienst im Leerlauf, während die Datenbank überlastet ist. Um die Leistung zu verbessern, müsste das Datenbanksystem aufgerüstet werden - entweder mit besserer Hardware oder mit Clusterbetrieb des Datenbanksystems selbst. Beachten Sie, dass REI3 nur geclusterte Datenbanken mit dem dedizierten Bereitstellungsmodell unterstützt. Ein Clusterbetrieb von REI3 selbst würde die Leistung in diesem Fall nicht verbessern.
- Fehlende oder schlecht genutzte Indizes auf Datenbankrelationen. Dies lässt sich erkennen, wenn man sich mit dem Datenbankserver verbindet und Benchmarks mit problematischen Anfragen durchführt. Wenn Indizes nicht optimiert sind, kann der Autor der betroffenen Anwendung die Leistung einfach verbessern, indem er sie anpasst. Der Clusterbetrieb von REI3 würde in diesem Fall zu keiner Leistungsverbesserung führen.
- Langsamer Speicher. Entweder das Datenbanksystem oder REI3 selbst greift auf langsame Speichersysteme zu. Dies zeigt sich, wenn sowohl der REI3-Anwendungsdienst als auch das Datenbanksystem nur sehr wenig belastet sind, die Anfragen aber trotzdem lange dauern. In diesem Fall hat die Verbesserung der Latenz/Durchsatzrate des zugrunde liegenden Speichersystems die größten Auswirkungen auf die Leistung. Ein Clusterbetrieb der REI3-Server würde nicht helfen.
Ist der REI3-Dienst tatsächlich der Engpass, kann ein Clusterbetrieb helfen - hierfür müssen folgende Voraussetzungen erfüllt sein:
- REI3 muss im dedizierten Bereitstellungsmodell laufen, d.h. das Datenbanksystem muss von REI3 selbst getrennt sein. Ein Wechsel vom eigenständigen Bereitstellungsmodell zum dedizierten ist jederzeit möglich.
- REI3-Server müssen auf denselben Speicherort für ihre Dateipfade zugreifen.
- REI3-Server müssen auf dieselbe Datenbank zugreifen.
- Es spielt KEINE Rolle, ob die REI3-Server auf unterschiedlichen Betriebssystemen oder Prozessorarchitekturen laufen.
Die Einrichtung des Clusters selbst ist sehr einfach:
- Der erste REI3-Server ist standardmäßig bereits Teil eines Ein-Server-Clusters, mit sich selbst als Clustermaster. Hier muss nichts weiter getan werden.
- Um weitere Serverknoten hinzuzufügen, installieren Sie REI3 auf anderen Servern und verwenden Sie die gleichen Datenbank- und Dateipfadeinstellungen in der REI3-Konfigurationsdatei
config.json
.- Die Dateipfade für den gesamten Cluster müssen auf denselben Speicherort verweisen - normalerweise eignen sich Netzwerkfreigaben gut für diese Anforderung.
- Wählen Sie eine beliebige Konfiguration im "Web"-Teil der Konfigurationsdatei, die zu Ihrer Infrastruktur passt (welcher Port verwendet werden soll, wie die Zertifikatsdateien benannt werden, usw.).
- Die
cluster/nodeId
muss für neue Serverknoten leer gelassen werden.
- Sobald sich ein neuer Serverknoten mit der bestehenden REI3-Datenbank verbindet, registriert er sich als neuer Clusterknoten und weist sich selbst eine eindeutige Knoten-ID zu.
Dies ist die gesamte Einrichtung. Das Cluster konfiguriert sich automatisch und weist auch automatisch die Rolle des Clustermasters und die Aufgaben zu, je nachdem, welche Knoten einchecken.
Vorbereiten einer neuen PostgreSQL-Datenbank
REI3 im dedizierten Bereitstellungsmodell benötigt volle Berechtigungen auf eine UTF8 kodierte PostgreSQL Datenbank. Diese Dokumentation behandelt nicht die Installation von PostgreSQL auf dem gewählten Betriebssystem. Sobald der PostgreSQL-Dienst jedoch verfügbar ist, mit einem PostgreSQL-Client (wie psql
oder pgAdmin
) verbinden und sicherstellen, dass sowohl ein Benutzer als auch eine Datenbank für REI3 existiert. Um beides zu erstellen:
CREATE ROLE my_rei3_user WITH LOGIN PASSWORD 'MY_STRONG_PW!';
CREATE DATABASE my_rei3_db WITH OWNER = my_rei3_user TEMPLATE = template0 ENCODING = 'UTF8';
Cloudbetrieb
REI3 kann im Internet zugänglich gemacht werden, indem entsprechende Firewall-Ports geöffnet werden. Wir, die REI3-Hersteller, sind bestrebt, die Plattform so sicher wie möglich zu gestalten. Wie bei jeder anderen Anwendung ist es immer möglich, dass unentdeckte Sicherheitslücken ausgenutzt und unbefugter Zugriff erreicht wird. Neben der regelmäßigen Aktualisierung von REI3 selbst sind wir der Ansicht, dass zusätzliche Sicherheitsmaßnahmen erforderlich sind, um Webanwendungen in der Cloud sicher auszuführen. Diese sind u. A.:
- Ausführen von Intrusion-Detection-Software auf dem Anwendungsserver oder Firewalls
- Anwenden von Härtungsprinzipien auf dem Anwendungsserver
- Verwenden einer DMZ zum Trennen von Cloud-Diensten von lokalen, geschützten Netzwerken
Die REI3-Plattform enthält einen Bruteforce-Schutz. Dies reicht bei Weitem nicht alleine für einen sicheren Betrieb mit Cloud-Verbindung. In jedem Fall sollten zusätzliche Maßnahmen (wie oben beschrieben) angewendet werden.