Betrieb über Proxyserver (HAProxy)

redballoon

Hallo, nun bin ich einen Schritt weitergegangen und wollte nicht mehr über openVPN auf den REI3 Server zugreifen, sondern über DynDNS und HAProxy mit SSL Let's Encrypt Zertifikat in der pfSense Firewall.

Dabei ist mir folgendes Verhalten aufgefallen, was ziemlich suboptimal ist: Man wird ziemlich exakt alle 30s aus dem Server rausgeworfen. Wenn man in der Loginmaske nicht "Angemeldet bleiben" auswählt, muss man sich neu einloggen. Das ganze passiert nur über den Proxy. Über openVPN und interner IP nicht.

In den Einstellungen von HAProxy gibt es eine Einstellung "Client timeout". Erhöhe ich dort von 30000ms auf 60000ms, passiert es nur noch alle 60 Sekunden, bei einem Wert von 10000ms alle 10 Sekunden, wähle ich einen Wert von z.B. 300000ms, bleiben es 60 Sekunden - Es scheint da eine Obergrenze zu geben.

Bei den anderen Servern, die ich über den Proxy anspreche, tritt das Verhalten nicht auf. Es hat wohl was mit REI3 zu tun, evtl. benötigt man dort eine Spezialeinstellung für Betrieb über Proxy?

gabriel

redballoon
REI3 kommuniziert mit Clients über Websockets - also über eine durchgängig offene Datenverbindung. Ich habe HAProxy zuletzt vor 10 Jahren genutzt und damals auch nicht für Webanwendungen; dementsprechend wenig Ahnung habe ich von dem Werkzeug. Aber von der Theorie her, sollte die Datenverbindung zum Client nicht getrennt werden - außer Client oder Server schließen diese selber.

Wie man HAProxy für diesen Fall konfiguriert, kann ich nicht beantworten - eine kurze googlerei nach "HAProxy & Websockets" hat aber einige vielversprechende Artikel geliefert.

redballoon

Problem beseitigt. Die Lösung fand ich hier und hier. Es ist ein Sicherheitsfeature von HAProxy, was das auslöst. (Warum verstehe ich aber nicht) Dort steht:

"As our config only handles HTTP, this setting will be used when upgrading a connection to, say, a WebSocket."

Mit timeout tunnel 10m in den Backend-Einstellungen für die REI3 Instanz loggt sich der Client jetzt nur noch alle 10min aus. Das passt für mich. Das nachfolgende timeout client-fin 1s von dem da noch die Rede ist, wird in meinem Fall nicht benötigt.

gabriel

Freut mich, dass du eine gute Lösung für dich gefunden hast. Für mich persönlich wären eine Neuanmeldung und ein damit möglicher Verlust meiner Eingaben alle 10 Minuten gruselig - aber das bin ich 😉

redballoon

Kann man ja verlängern ;-) Nun habe ich allerdings noch eine andere Eigenheit entdeckt - ist mir bislang nicht aufgefallen, weil ich zuerst lokal die Anwendung erstellt hatte und hinterher auf einen anderen Server übertrug.
Und zwar folgendes:
Lokal werden Änderungen im Builder fast unmittelbar sichtbar. Arbeite ich jedoch über VPN oder Proxy im Builder, dauert es ca. 45 Sek. bis die Änderung sichtbar wird ... Das ganze tritt nur im Builder auf - in der normalen Oberfläche, z.B. bei der Erstellung /Änderung/Löschung eines Datensatzes nicht. Hier findet die aktualisierung unmittelbar statt.
Auf der Gegenseite steht ein kräftiger Server und eine 500 mBit Glasfaser Leitung. Bei mir nur eine 2 mBit Leitung. Hat es vielleicht etwas damit zu tun: "REI3-Anwendungen werden komprimiert und auf Endgeräten zwischengespeichert."? Könnte man da etwas herausnehmen oder verlagern, was nicht jedesmal neu übertragen wierden muss und diese immense Verzögerung verursacht?
Kann man das programmtechnisch irgendwie noch verbessern? Weil ausserhalb des Builders gibt es diese Verzögerung auch nicht. Über den Proxy dauert es nochmal ein Stück länger, habe ich das Gefühl. Ich bin es ja gewohnt über VPN oder Proxy zu arbeiten.
Ein ähnliches Verhalten kenne ich z.B. von Grafana über VPN: Längere erste Ladezeit beim Start - dann aber ganz normale Antwortzeiten. Andere Webapplikationen machen fast gar keinen Unterschied.

gabriel

Du liegst mit deiner Vermutung wahrscheinlich richtig. Wenn du Änderungen im Builder machst, ändert sich das Schema und sowohl Server-Cache, als auch Clients werden dann automatisch aktualisiert. Bei 2mbit kann das, je nach Größe der Anwendungen, entsprechend lange dauern - auch wenn 45 Sek. schon extrem sind. Hast du während der Aktion deine Leitung angeschaut bzgl. Auslastung? Wenn sie durchgängig voll ist, hast du schon die Ursache identifiziert.

Es ist nicht sehr praktikabel über eine langsame Leitung den Builder zu benutzen. Ich arbeite grundsätzlich lokal mit dem Builder (portable oder Docker-Version); dann mach und teste ich meine Änderungen und spiele die fertige Version dann einmalig auf den Server zurück (per Transfer). Das muss man nicht so machen, ist aber rasend schnell (weil lokal) und hilft dabei Fehler im Produktivsystem zu vermeiden.

Das Cache-Verfahren und wie Schemas verwaltet werden, ist eine sehr grundlegende Systematik und hat viele Vorteile für uns. Es ist aktuell nicht geplant, das zu verändern. Um flott zu arbeiten, sollte das Builder-System auf jeden Fall gut angebunden sein - am schnellsten ist natürlich lokal.

redballoon

Ich habe jetzt mal einen Versuch gestartet und bin über Hotspot LTE und VLAN reingegangen. Das sind hier bei mir Zuhause ca. 20mBit im Down und 5mBit im Upload. Mit der Stoppuhr gemessen komme ich auf ca. 8 Sek. die es dauert, wenn man in den Relationen ein Feld hinzufügt bis es erscheint, bzw. beim Löschen wieder verschwindet. Über Proxy sind es etwa 10-12 Sekunden. Im LAN sind es natürlich 1 Gbit ... im Idealfall. Ich denke mit 50 mBit aufwärts kann man dann schon Änderungen im Builder vornehmen, auch ohne direkt vor dem Server zu sitzen.
Es wäre natürlich toll, wenn da noch Potential vorhanden wäre, die Ladezeiten zu optimieren. Aber ich kann mir auch vorstellen, das weiter erst mal lokal zu erstellen. Bei der Befüllung der Datenbank gibt es ja dann kein Hindernis.

gabriel

Im normalen Betriebsmodus ist REI3 sehr effizient. Der Cache wird einmalig von Clients geladen und dann werden nur noch Daten übertragen, die der Client anzeigen oder verändern möchte. Das ist der Zustand für welches das System optimiert worden ist.

In produktiven Instanzen wird der Builder idR. auch nicht verwendet. Produktive Systeme empfangen Änderungen dann nur vereinzelnt per Transfer, nach ausgiebigen Testen. Das ist zumindest der empfohlene Weg.

redballoon

Genau. Das mit dem lokalen Repository (Anwendung R3 Repo) wäre natürlich die Lösung. Manueller Transfer ist mir auf Dauer zu unbequem. In der Beschreibung steht, dass das in lokalen Netzwerken mit R3 Repo stattfinden könnte. Im Prinzip dann doch auch, wenn ich mit VPN verbunden bin. Muss mich da erst einarbeiten:

When running many local or offline REI3 instances, it can be sensible to host your own REI3 application repository. It is also possible to host your own repository in the cloud, accessible to anyone. This is done by setting up a REI3 instance and installing the 'REI3 repository' application; this is the same application we use to host the central REI3 repository.

Once running and reachable on a network, the repository must be added to target REI3 instances as well as the public signing key(s) for corresponding applications. After that the repository meta data will be pulled from connected instances and applications will be available for install/update.!

gabriel

Das ist eigentlich flott erklärt:

Man betreibt eine REI3-Instanz, auf der die Anwendung "R3 Repo" installiert ist. Diese Repo-Instanz dient als zentrale Quelle für Anwendungen und Updates (egal ob lokal oder Cloud).
Produktivsysteme holen dann Anwendungen und Updates von der Repo-Instanz. Hierzu muss man die Verbindungsdetails in den Produktivsystemen eintragen (Repository-URL, Username, Password) - und die Repo-Instanz muss natürlich erreichbar sein.
Der Betreiber der Repo-Instanz lädt dann gewünschte Anwendungen und Updates hoch. Dann können die Produktivsysteme diese empfangen und per Knopfdruck im Admin-Panel auch installieren.

Manueller Transfer ist bei kleinen Instanzen aber meist flotter. Spannend werden Repo-Instanzen, wenn man dutzende Apps in verschiedenen Produktionsstufen hat (Development->Testing->Production). Dann dienen die Repo-Instanzen als offizielle Anwendungsquellen und stellen so einen geregelten Release-Prozess sicher.

redballoon

gabriel
Wo genau findet man die Einstellung, wo man die Verbindungsdetails eintragen kann ... ? Genau das geht mir ab ...

gabriel

Einmal bei den Produktivsystemen (Admin-Panel -> System):

Und dann musst du bei der Repo-Instanz eine Anmeldung anlegen mit Rechten auf die Anwendung "R3 Repo":

Das ist alles nicht großartig dokumentiert - Organisationen, die Repo-Instanzen brauchen, sind normalerweise schon eng mit uns im Kontakt.

redballoon

Ist mir jetzt auch grad eingefallen ... Die Original-Repo überschreiben zu müssen hatte ich nicht auf dem Schirm ... ;-) Bei mir ist es ja so - diese Anwendungen (eigentlich Luxus-Excel-Tabellen) sind so speziell - das kann man als öffentliche App gar nicht anbieten. Das braucht niemand so. Das sind über hundert Homematic-Geräte die ich damit verwalte und einiges anderes mehr.

Das soll von EspoCRM auf REI3 umziehen. Weil mich die ständigen neuen Systemanforderungen nerven. (Höhere PHP-Version) Ausserdem können hier die Relationen auch im Frontend von einem Laien bearbeiten werden.
Dann werde ich mich mal mit lokaler Repo-Bereitstellung befassen. Bin gespannt, ob ich das hinkriege. Ich denke vom ganzen Konzept ist euer REI3 so gut, dass es grossen Zuspruch finden wird. Ist nur noch zu wenig bekannt.

gabriel

Lokale Repos lohnen sich normalerweise, wenn man mehrere Instanzen am Laufen hat. Der Aufwand, Anwendungen/Updates beim Repo hochzuladen ist größer, als die Anwendung direkt in einem einzelnen Zielsystem einzuspielen. Manchmal ist es trotzdem sinnvoll - bspw. aus Prozessgründen.

Danke für die Details zu deiner Anwendung - es freut mich immer zu hören, was Menschen mit REI3 bauen. Mit besseren Excellisten fängts meistens an 😉