Die App würde sich außerhalb des Discourse-Docker-Containers, aber auf demselben Server befinden. Falls ja, könnte jemand bitte einige Details dazu teilen oder mich auf einen Leitfaden oder Anweisungen verweisen?
Gäbe es bei dieser Vorgehensweise im Vergleich zur Nutzung des DE-Plugins bzw. der DE-API auch Nachteile?
Nachteile betreffen vor allem die Tatsache, dass eine solche Verbindung für Schreibzugriffe genutzt werden könnte. Ist das eine Voraussetzung?
Wenn Ihre Integration Schreibzugriff auf die Datenbank benötigt, erwägen Sie die Erstellung eines Plugins, das nur die benötigten Operationen bereitstellt.
Es ist keine Voraussetzung, aber ich nehme diesen Nachteil gerne in Kauf
Ich habe angefangen, dein DE-Plugin zu verwenden, aber leider scheint mein Anwendungsfall eine direkte Verbindung zu erfordern, da ich für einige meiner Seiten zu viele Anfragen über die API sende (und das ist nur mit mir auf der Seite). Es handelt sich größtenteils um benutzerdefinierte Abfragen, daher bin ich mir nicht sicher, ob das einen Einfluss hat. Das DE-Plugin finde ich trotzdem toll!
Weißt du zufällig, wie man am besten direkt außerhalb des Containers auf die Postgres-Datenbank zugreift? Sowohl das Forum als auch die Website befinden sich auf demselben Server, falls das hilft.
Edit: Ich vermute, dass ich beim DE-Plugin ein Rate-Limit erreiche, aber ich bin mir sicher, Sam gesagt zu haben, dass bei Anfragen vom selben Server kein Rate-Limit gilt – gilt das immer noch?
Obwohl möglich, kann die andere App Sperren auf Tabellen erwerben und Discourse daran hindern, wie üblich zu funktionieren.
Entweder Sie entscheiden sich für ein neues Plugin, das die erforderlichen API-Endpunkte hinzufügt, die Sie benötigen, oder Sie gehen vollständig hinein, indem Sie eine weitere PostgreSQL-Instanz erstellen, die Ihr Discourse repliziert und in die Sie Ihre App einbinden können.
Danke für die Info, Rafael. Ich werde ausschließlich SELECT-Anweisungen verwenden, und soweit ich weiß, sperren diese nicht. Daher müsste ich mich nur um Tabellenänderungen auf der Discourse-Seite kümmern (z. B. beim Upgrade) und dafür sorgen, dass ich die andere Anwendung vorübergehend ausschalten kann. Würde das die Sorgen bezüglich Sperren beseitigen?
Bezüglich der Datenbankreplikation klingt das wie eine interessante Option – kann das im laufenden Betrieb erfolgen, sodass die Daten maximal ein paar Minuten veraltet sind? (Ich muss häufig die neuesten Themen abrufen – fast jede Seite der Website enthält sie. Zwar cache ich für zwei Minuten, aber dies variiert je nach Seite/Kriterien, und es wird Hunderte solcher Seiten geben.) Außerdem könnte diese Option wegfallen, sobald die Datenbank wächst? (Auf einem anderen Discourse-Forum ist meine Datenbank bereits mehrere Gigabyte groß.)
(Ich glaube nicht, dass das Erstellen eines Plugins hier eine Option wäre, da ich nicht sehe, wie es besser sein könnte als das Data Explorer-Plugin. Tatsächlich ist das DE-Plugin fast perfekt – abgesehen von diesem Problem.)
Dann habe ich den Container neu erstellt. Im Container habe ich ein Passwort für den postgres-Benutzer festgelegt und kann dann von innerhalb des Containers mit folgendem Befehl verbinden:
psql -h localhost -d discourse -U postgres
Wenn ich jedoch den Container verlasse und den Versuch einer Verbindung von außen mache, erhalte ich folgende Meldung:
# psql -h 127.0.0.2 -p 5432 -d discourse -U postgres
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Ich habe auch versucht, den Port auf einen anderen Wert zu ändern, aber erhalte dasselbe Ergebnis. Die IP 127 habe ich aus docker ps und der Inspektion unter Network Settings erhalten (ich habe drei eigenständige Discourse-Instanzen laufen).
Wenn ich die IP ändere (auf die einer der anderen Discourse-Foren), erhalte ich eine (sofortigere und) andere Antwort/Meldung, was darauf hindeutet, dass das Obige teilweise korrekt ist:
# psql -h 127.0.0.3 -p 5432 -d discourse -U postgres
psql: could not connect to server: Connection refused
Is the server running on host "127.0.0.3" and accepting
TCP/IP connections on port 5432?
Habt ihr eine Idee, was ich falsch mache? Eine Google-Suche nach psql: server closed the connection unexpectedly deutet auf ein Netzwerkproblem hin – muss ich also noch etwas im Container ändern?
Die Methode, mit der ich das von außerhalb des Containers zum Laufen gebracht habe, ist die Verwendung eines SSH-Tunnels. Ich habe tatsächlich einen neuen Benutzer anstelle von postgres erstellt und benutzerdefinierte Ports für SSH und postgres verwendet, aber dies sollte auch für deine Einrichtung funktionieren:
EXTERNAL_VPS_IP ist die IP-Adresse, die du verwendest, um eine Verbindung zu deinem Remote-Server herzustellen.
Wenn es immer noch nicht funktioniert, solltest du versuchen, die freigegebene IP in app.yml auf die docker bridge-IP statt auf die interne Container-IP, die du von docker ps erhalten hast, zu ändern. Ich bin mir nicht sicher, ob dies erforderlich ist, aber so habe ich es eingerichtet:
expose:
- "127.0.0.1:5432:5432"
# oder wenn du einen benutzerdefinierten Port verwendest: - "127.0.0.1:CUSTOM_PORT:5432"
Denke daran, den Container anschließend neu zu erstellen.
Lass mich wissen, wie es läuft. Es hat sehr lange gedauert, bis alles funktionierte (und im Nachhinein war es so einfach), daher helfe ich gerne.
Es scheint, als wären die Ratschläge in deinem (und dem anderen) Thread korrekt gewesen: Du benötigst:
expose:
- "127.17.0.1:5432:5432"
…wie in diesem Link erwähnt, leitet Docker automatisch an die richtige IP für deinen Container weiter (was angesichts der dynamischen IPs sinnvoll ist – etwas, worüber ich mir Gedanken gemacht hatte). Ich denke, das ist für die meisten Setup-Konfigurationen alles, was benötigt wird.
Das hatte ich jedoch bereits versucht – du fragst dich vielleicht, worin mein Problem bestand. Meine Firewall! (Ich dachte, ich hätte den Fehler psql: server closed the connection unexpectedly wiedererkannt!)