Ich hatte einige Probleme mit dem Upgrade – das erste Forum schlug beim ersten Versuch (über das Dashboard) fehl und dann erneut beim Rebuild, schien aber beim zweiten Rebuild-Versuch zu funktionieren, obwohl ich danach noch einmal einen zusätzlichen Rebuild durchführen musste. Das hat mich daran erinnert, dass ich beim Upgrade mit dem PG12-Update alle Discourse-Instanzen stoppen muss (auf diesem Server befinden sich drei Discourse-Foren mit separaten Containern). Daher funktionierte Folgendes für die anderen beiden Foren:
Aus irgendeinem Grund ist das erste Forum jedoch nicht mehr erreichbar. Safari meldet, dass die Verbindung vom Server unerwartet getrennt wurde. Ein Rebuild scheint erfolgreich abzulaufen, aber das Forum ist nicht erreichbar. Ich kann zwar in die App und die Rails-Konsole zugreifen, und die Datenbank scheint intakt zu sein.
Die einzigen Warnungen, die ich beim Rebuild sehe und die relevant sein könnten:
168:M 31 Jan 2021 21:39:22.459 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
168:M 31 Jan 2021 21:39:22.459 # Server initialized
168:M 31 Jan 2021 21:39:22.459 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
168:M 31 Jan 2021 21:39:22.459 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled (set to 'madvise' or 'never').
168:M 31 Jan 2021 21:39:22.459 * Loading RDB produced by version 6.0.9
168:M 31 Jan 2021 21:39:22.459 * RDB age 21 seconds
168:M 31 Jan 2021 21:39:22.459 * RDB memory usage when created 4.03 Mb
168:M 31 Jan 2021 21:39:22.466 * DB loaded from disk: 0.006 seconds
168:M 31 Jan 2021 21:39:22.466 * Ready to accept connections
production.log:
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.5/lib/redis/client.rb:367:in `rescue in establish_connection'
Ähnliche Meldungen erscheinen auch in unicorn.stderr.log und unicorn.stdout.log.
Wenn ich in den Container eingehe und redis-cli ping ausführe, erhalte ich eine PONG-Antwort. Redis läuft auf dem Server (aber nicht in den einzelnen Containern – das war meines Wissens nach schon immer so).
Haben Sie eine Idee, was hier los sein könnte?
(Ich habe den Server auch neu gestartet und ein neues letsencrypt-Zertifikat für diese Domain erstellt, um auf der sicheren Seite zu sein – aber es ist immer noch dasselbe.)
Das sieht so aus, als ob alles funktionieren sollte… Hast du es bereits mit einem anderen Browser versucht oder deinen Cache geleert? Falls das nicht hilft, könntest du bitte die Ausgabe von folgendem Befehl posten:
Einige mögliche Ursachen für den Fehler „leere Antwort“:
Der Server befindet sich in einem VPN, und es besteht kein Zugriff auf den Port.
Wenn Sie mehrere Discourse-Instanzen auf demselben Server betreiben, geht man davon aus, dass ein Reverse-Proxy davor steht. Stellen Sie sicher, dass dieser auf den Discourse-Container zeigt (möglicherweise müssen Sie ihn neu starten).
Auf dem Server ist nicht genügend Speicherplatz vorhanden (Sie können df -hT / ausführen).
Ich würde zuerst den verfügbaren Speicherplatz prüfen (3).
Die Festplattennutzung wurde mit 31 % angezeigt, aber ich habe trotzdem ./launcher cleanup ausgeführt:
docker container ls
(um sicherzustellen, dass alle drei Forum-Container laufen)
./launcher cleanup
WARNUNG! Dadurch werden alle gestoppten Container entfernt.
Möchten Sie wirklich fortfahren? [y/N] y
Gesamterfreiter Speicherplatz: 0B
WARNUNG! Dadurch werden alle Images entfernt, die keinem Container zugeordnet sind.
Möchten Sie wirklich fortfahren? [y/N] y
Gelöschte Images:
...
Gesamterfreiter Speicherplatz: 32,56 GB
Wir verwenden HAProxy, das ich überprüft (und neu gestartet) habe. Es läuft wieder (wir leiten auch über HAProxy von HTTP auf HTTPS um, was für die Domain ebenfalls einwandfrei funktioniert, also glaube ich nicht, dass das Problem dort liegt – zudem hat es bis zu diesem Update funktioniert).
Ich kann immer noch in den Container einloggen und auf die Rails-Konsole zugreifen; die Datenbank ist ebenfalls noch vorhanden und mit dem Container verbunden – das ist also einfach extrem seltsam. Hat jemand weitere Ideen oder Schritte zur Fehlerbehebung?
Wenn Sie nicht in der Lage waren, das Problem zu debuggen, besteht eine Option darin, über die Befehlszeile ein Backup zu erstellen und es auf einer neuen, frischen Site unter PG13 wiederherzustellen. Alternativ können Sie, falls Ihre Site schnell wieder verfügbar sein muss, die Version auf PG12 zurücksetzen, das vorhandene Verzeichnis shared/postgres_data_old wieder nach shared/postgres_data verschieben und den Aufbau neu starten. Ich empfehle jedoch, stattdessen die Backup-/Wiederherstellungsmethode zu versuchen, da das Problem nicht mit dem Datenbankupgrade selbst zusammenzuhängen scheint.
Wenn du weitere Ideen hast, um das zu untersuchen, bin ich gerne bereit, sie auszuprobieren, Michael. Zum Glück ist es kein großes Problem, dass dieses Forum offline ist, da es ohnehin im Nur-Lese-Modus war (es wurde durch ein anderes Forum ersetzt).
Wenn du keine weiteren Ideen mehr hast, werde ich versuchen, eine Sicherung wiederherzustellen. Wenn möglich, würde ich jedoch lieber das Problem selbst untersuchen, da ich daran interessiert bin, herauszufinden, warum das passiert ist (was du wahrscheinlich auch bist) – also bin ich definitiv bereit, mich weiter damit zu beschäftigen, wenn du das auch bist.
Um ehrlich zu sein, hat mich das etwas nervös gemacht, einige meiner anderen Foren zu Discourse zu migrieren. Zu wissen, was schiefgelaufen ist, könnte für uns alle nützlich sein.
Es handelt sich um eine standardmäßige Installation mit mehreren Containern, bei der jedes Forum über eine eigene app.yml verfügt und die Container-Setup-Konfiguration auf host: discourse/shared-site-name/standalone und host: discourse/shared-site-name/standalone/log/var-log basiert (wie in meinen gestellten Fragen und Beiträgen in diesem Forum beschrieben).
Wenn ich in jeden Container gehe und psql ausführe (sudo -u postgres psql discourse) sowie \l+ eingebe, wird pro Container nur eine einzige discourse-Datenbank angezeigt (und jede hat eine andere Größe). Daher vermute ich, dass es sich um unabhängige Discourse-Instanzen handelt.
Betreibst du nginx innerhalb des Containers? Als Nächstes würde ich versuchen, nachzuvollziehen, wohin die Anfragen weitergeleitet werden. Soweit ich verstehe, übernimmt HAProxy die SSL-Terminierung und leitet die Anfragen dann in die jeweiligen Container weiter?
Ah, okay. Also solltest du für jedes von ihnen ./launcher rebuild DEIN-APP-NAME zweimal ausführen. Ich glaube nicht, dass dies über die Weboberfläche möglich ist.
Und sind in den yml-Containern die SSL- und LetsEncrypt-Vorlagen auskommentiert (oder entfernt)?
Soweit mir bekannt ist, sind die Container selbst alle „standardmäßig“ konfiguriert (ich gehe also davon aus, dass in jedem nginx läuft), und ja, HAProxy übernimmt die gesamte SSL-Verarbeitung und leitet die Anfragen an die einzelnen Container weiter.
backend main_apache_sites
server server1 127.0.0.1:8080 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker
server server2 127.0.0.1:8888 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker_2
server server2 127.0.0.1:8889 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker_3
server server2 127.0.0.1:8890 cookie A check
cookie JSESSIONID prefix nocache
backend letsencrypt-backend
server letsencrypt 127.0.0.1:54321
Aus irgendeinem Grund hatten alle Discourse-Backends auf der zweiten Zeile server2 stehen – ich habe diese gestern in server2, server3 usw. geändert, aber das hat keinen Unterschied gemacht (und bisher hat es so problemlos funktioniert).
Gibt es spezifische Logdateien, die ich einsehen könnte, um weitere Hinweise zu erhalten? Vielleicht Docker-Logdateien?
Ja, diese sind auskommentiert:
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Diese beiden Zeilen auskommentieren, wenn Sie Lets Encrypt (https) hinzufügen möchten
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
Die Nginx-Protokolle innerhalb der App-Container sollten bestätigen können, ob die Anfragen die Anwendung erreichen. Können Sie diese prüfen? Nginx im Container leitet Anfragen an 127.0.0.1:3000 weiter, was dem Unicorn-Prozess entspricht.
Ich habe in /var/log/nginx und /shared/log/rails nachgesehen, aber nichts Auffälliges gefunden. Tatsächlich wurden heute (der 4.) keine Logs aktualisiert, außer /shared/log/rails/production.log, das nur ein paar Jobs wie diesen enthält:
Ich habe auch den Port in HAProxy geändert und erhielt erwartungsgemäß einen „Server nicht gefunden“-Fehler. Anschließend habe ich den Container auf denselben Port zurückgestellt, und das Verhalten ist wieder dasselbe (ich denke, das schließt ein HAProxy-Problem aus).
Gibt es Docker-Logs, die ich einsehen kann? Oder kann ich diesen Container speichern/exportieren und dir schicken, damit du ihn dir ansehen kannst? Ich schätze, du fragst dich genauso wie ich, was schiefgelaufen ist
Keine der Nginx-Logs wurde heute verändert, obwohl das letzte Log vom 30. Januar einen Fehler vom Typ 7 zeigt: limiting requests by zone “flood” client: my.ip.address, POST /mini-profiler-resources.
Edit: Ich bin mir nicht sicher, ob das hilft, aber beim Ausführen von docker logs APP:
# docker logs f2
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 42
ok: run: redis: (pid 55) 0s
ok: run: postgres: (pid 54) 0s
chgrp: invalid group: 'syslog'
supervisor pid: 51 unicorn pid: 82
(51) Reopening logs
(51) Reopening logs
(51) Reopening logs
(51) Stopping Sidekiq
(51) Reloading unicorn (82)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 22039
(51) Old pid is: 82 New pid is: 22039
(51) Stopping Sidekiq
(51) Reloading unicorn (22039)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 23358
(51) Old pid is: 22039 New pid is: 23358
(51) Reopening logs
(51) Reopening logs
Für Forum drei (funktioniert ebenfalls einwandfrei):
Beim Durchsehen der Logs und beim Zurücklesen Ihrer vorherigen Antworten fällt auf, dass die Anwendung versucht, auf Redis unter localhost:6379 innerhalb des Containers zuzugreifen. Es sieht so aus, als ob Redis ebenfalls ordnungsgemäß startet, doch aus irgendeinem Grund kann keine Verbindung hergestellt werden (rätselhaft). Es ist jedoch möglich, dass diese Fehlermeldungen von dem Zeitpunkt stammen, an dem message_bus versucht, sich zu verbinden, bevor Redis gestartet ist, oder nachdem es bei einem Neustart gestoppt wurde.
Sie haben erwähnt, dass Redis auf dem Server läuft, aber nicht in einzelnen Containern – könnten Sie das bitte näher erläutern?
Mit dieser Konfiguration wird Redis innerhalb des Containers ausgeführt (wie Sie in der Docker-Logausgabe sehen können).
Noch ein Hinweis: Wenn Sie die URL der nicht funktionierenden Website aufrufen, was erscheint dann in Ihren Nginx-Logs? Die error.log sollte leer sein, während die access.log mit verschiedenen HTTP-Anfragen gefüllt sein sollte. Ich versuche nur herauszufinden, an welchem Punkt etwas schiefgeht.
Entschuldigung, ich habe die Dinge durcheinandergebracht. Redis läuft tatsächlich in jedem Container. Das wurde durch die Ausführung folgender Befehle auf dem Server selbst und dann in jedem der drei Discourse-Container bestätigt, wobei für alle der gleiche Output erschien:
$ redis-cli ping
PONG
$ redis-server
# Creating Server TCP listening socket *:6379: bind: Address already in use (bedeutet, dass er bereits gestartet ist)
$ redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get mykey
(nil)
127.0.0.1:6379> set mykey somevalue
OK
127.0.0.1:6379> get mykey
"somevalue"
Das Gleiche gilt für alle drei (bemerkenswert: der erste get mykey-Aufruf gibt immer nil zurück). Daher kann man mit Sicherheit sagen, dass Redis in allen Containern aktiv und unabhängig läuft.
Es ist leer, und in diesem Verzeichnis wurde heute nichts geschrieben:
drwxr-xr-x 2 www-data www-data 4096 Feb 4 21:26 .
drwxrwxr-x 9 root root 4096 Feb 2 08:03 ..
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 access.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 access.log.1
-rw-r--r-- 1 www-data www-data 294 Feb 1 09:43 access.log.2.gz
-rw-r--r-- 1 www-data www-data 37598 Jan 30 23:56 access.log.3.gz
-rw-r--r-- 1 www-data www-data 58059 Jan 30 07:36 access.log.4.gz
-rw-r--r-- 1 www-data www-data 55988 Jan 29 07:34 access.log.5.gz
-rw-r--r-- 1 www-data www-data 73964 Jan 28 07:49 access.log.6.gz
-rw-r--r-- 1 www-data www-data 78069 Jan 27 07:53 access.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 error.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 error.log.1
-rw-r--r-- 1 www-data www-data 20 Feb 1 00:31 error.log.2.gz
-rw-r--r-- 1 www-data www-data 632 Jan 30 23:46 error.log.3.gz
-rw-r--r-- 1 www-data www-data 265 Jan 29 09:07 error.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Jan 28 07:50 error.log.5.gz
-rw-r--r-- 1 www-data www-data 3107 Jan 28 07:41 error.log.6.gz
-rw-r--r-- 1 www-data www-data 20 Jan 26 07:53 error.log.7.gz
Ich habe die Zugriffsprotokolle für einen anderen Container überprüft, und dort ist alles in Ordnung. Es betrifft also nur diesen einen.
Es scheint, als würde HAProxy die Anfrage durchreichen, aber der Container kann sie nicht verarbeiten oder annehmen. Ich frage mich, ob dort etwas zurückgesetzt werden kann? (Was man doch eigentlich denken würde, dass ein Neuaufbau des Containers sowieso erledigt?)
IMAGE COMMAND CREATED STATUS PORTS
local_discourse/1 "/sbin/boot" 20 Stunden her Vor 20 Stunden 0.0.0.0:2225->22/tcp, 0.0.0.0:8892->80/tcp
local_discourse/2 "/sbin/boot" 4 Tage her Vor 4 Tagen 0.0.0.0:2223->22/tcp, 0.0.0.0:8889->80/tcp
local_discourse/3 "/sbin/boot" 4 Tage her Vor 4 Tagen 0.0.0.0:2224->22/tcp, 0.0.0.0:8890->80/tcp
Mein Bauchgefühl sagt mir, dass es mit dem fehlgeschlagenen Versuch über das Dashboard zu tun hat – normalerweise sagt das Dashboard bei PG- oder großen Updates, dass man eine Neuinstallation durchführen muss und dass Updates über das Dashboard deaktiviert sind. Aus irgendeinem Grund war das jedoch nicht der Fall (vielleicht, weil ich dieses Forum schon lange nicht mehr aktualisiert habe – daher dachte ich, ich sollte es zuerst über das Dashboard tun) oder es ist möglich, dass es vor der Neuinstallation nicht ordnungsgemäß heruntergefahren oder gestartet wurde
In der HAProxy-Konfiguration sehe ich, dass die Backends so konfiguriert sind, dass sie an die Ports 8888, 8889 und 8890 weiterleiten:
Die App-Container lauten jedoch auf 8892, 8889 und 8890 – das sieht nach einer Diskrepanz für backend discourse_docker aus. Hast du die Konfiguration seit dem Posting aktualisiert?
Ja, die HAProxy-Ports entsprechen den richtigen Container-Ports Ich bin mir ziemlich sicher, dass das nicht damit zusammenhängt, da alles einwandfrei funktioniert hat – es trat erst nach diesem Upgrade/Neuaufbau auf.
Das Öffnen des Containers, Aufrufen von Top-Statistiken und dann zum Wechseln zur Seite scheint auch keinen Unterschied zu machen. Falls es hilfreich ist, hier ein Screenshot:
Ich bin mir ziemlich sicher, dass das nicht damit zusammenhängt, da alles einwandfrei funktioniert hat – es trat erst nach diesem Upgrade/Neuaufbau auf.