Discourse liefert keine Seiten aus

Ich habe nach der Installation einige Probleme beim Ausführen von Discourse.

Laut der folgenden Seite sollte ich nach dem Ausführen des Skripts discourse-setup in der Lage sein, die konfigurierte URL aufzurufen. Offenbar muss ich jedoch zusätzlich den folgenden Befehl ausführen:
./launcher start app

Ich bin mir nicht sicher, ob es sich um einen Fehler in der Dokumentation handelt oder ob ich etwas falsch mache? Außerdem habe ich nach dem Ausführen des oben genannten Befehls folgende Beobachtungen gemacht:

  1. Ich kann eine Webseite laden, wenn ich die konfigurierte URL aufrufe.
  2. Statt der Seite „Congratulations, you installed Discourse!

Keines dieser Dinge wird erwartet. Es klingt so, als ob du vielleicht eine andere nginx-Instanz laufen hast? Läuft noch etwas anderes auf der VM?

Das ist nicht möglich, da es sich um eine minimalistische CentOS-Installation ohne zusätzliche Komponenten handelt. Ich habe überprüft, indem ich den folgenden Befehl ausgeführt habe: Ohne laufenden Container lauscht nichts auf Port 80 oder 443.
lsof -i TCP

Meine beste Vermutung ist, dass es ein Problem mit CentOS und discourse-setup gibt. Am einfachsten wäre es, Ubuntu zu versuchen. Andernfalls müssen Sie genau darauf achten, was das Skript tut, und versuchen, das Problem zu debuggen.

Wenn du die folgende Installationsanleitung befolgt hast, die von einer Person empfohlen wurde, die nicht genannt werden soll :smiley:

Solltest du keine Probleme haben.

https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md

Seufz, ich habe es tatsächlich versucht, aber sowohl der 19er als auch der 20er LTS-Installer sind in der Mitte abgestürzt. Beide gaben an, dass sie die Schnittstelle nicht automatisch konfigurieren können. Wenn ich sie deaktiviere, läuft der Installer problemlos, aber sobald ich die IP manuell einstelle, stürzen sie ab.

Wenn ich die Schnittstelle deaktiviere, um die Installation fortzusetzen, kann ich keine Netzwerktools installieren, um ifconfig zu erhalten, selbst wenn ich das ISO eingebunden und als Quelle verwende. Also stecke ich etwas fest.

Hallo @titusc,

was siehst du, wenn du folgendes ausführst:

docker ps

?

Du sagst also, dass der Ubuntu-Installer nicht funktioniert?

Oder versuchst du, das übliche Diskussionsforum mit einer IP-Nummer statt einem Domainnamen zu verwenden?

Ich verwende keine IP-Adresse für die Discourse-Installation, sondern einen gültigen Domainnamen, der im öffentlichen DNS auflösbar ist.

Ich sage damit, dass der Ubuntu-Installer immer abstürzt, wenn ich versuche, ihn beim Erstellen der Maschine durch Booten von der Ubuntu-ISO-Datei auszuführen. Dies tritt sowohl bei Ubuntu Server 19.10 als auch bei 20.04 LTS auf, und in beiden Fällen meldet die Installation, dass die Netzwerkschnittstelle nicht eingerichtet werden kann. Wenn ich es so lasse, läuft die Installation zwar durch, aber ich habe keine Möglichkeit, die Schnittstelle hochzufahren, um irgendetwas zu tun. Ich habe folgenden Befehl erfolgreich ausgeführt:
ip address add <ip>/<mask> dev <interface>

Danach kann ich die Schnittstelle jedoch nicht mit dem folgenden Befehl hochfahren:
ifup <interface>

Ich habe die ISO dann als Loopback-Gerät eingehängt, als Repository eingerichtet und versucht, folgenden Befehl auszuführen, aber es wird gemeldet, dass das Paket nicht auf der ISO gefunden wird:
apt install net-tools

Wenn ich versuche, die Schnittstelle während der Installation manuell mit Netzwerkdaten zu konfigurieren, stürzen beide Versionen ab.

Zur Information: Ich führe dies auf ESXi 7.0 aus und verwende folgende ISO-Dateien:
ubuntu-20.04-live-server-amd64.iso
ubuntu-19.10-live-server-amd64.iso

Das würde zeigen, dass der Discourse-Container läuft. Jedes Mal, wenn ich Folgendes tue:

  1. ./launcher start app
  2. Im Browser prüfen und die Seite „Welcome to Nginx“ sehen, die jedoch nach etwa einer halben Minute nicht mehr angezeigt wird.
  3. docker ps ausführen, um zu bestätigen, dass der Discourse-Container läuft.
  4. ./launcher stop app und ./launcher start app ausführen.
  5. Im Browser prüfen und die Seite „Welcome to Nginx“ sehen, die jedoch nach etwa einer halben Minute nicht mehr angezeigt wird.
  6. docker ps ausführen, um zu bestätigen, dass der Discourse-Container läuft.

Was mir außerdem auffällt: Wenn ich die folgenden Befehle ausführe, kann ich Nginx nicht als laufenden Prozess sehen. Das könnte jedoch daran liegen, dass Nginx bis zum Zeitpunkt der Ausführung bereits gestoppt wurde.
./launcher enter app
systemctl status nginx

@titusc

Hast du versucht, die App neu zu erstellen?

/var/discourse/launcher rebuild app

Normalerweise kann es je nach Systemkonfiguration und Zeit, die der Container benötigt, um vollständig hochzufahren, eine Weile dauern, bis er voll einsatzbereit ist.

Selbst auf unserem Linux-Server mit 64 GB RAM und 8 CPU-Kernen warten wir etwa eine ganze Minute, bevor wir auf den neuen Container umschalten.

Hast du 18.04 bereits ausprobiert?

Das klingt nach einem Umgebungsproblem. Wir können hier jedoch keine Unterstützung für Hypervisor und Linux-Distributionen anbieten. Einer der Gründe, warum DigitalOcean empfohlen wird, ist die Konsistenz des darauf installierten Betriebssystems. Wenn du eine VM von Grund auf neu erstellen möchtest, musst du das im Voraus klären.

Sobald du ein funktionierendes Betriebssystem hast, können wir dir bei der Installation des Discourse-Teils helfen.

Hallo @DBHacker, ja, ich habe Folgendes nacheinander ausgeführt:
./launcher rebuild app
./launcher start app

Das geschah, nachdem mir klar wurde, dass ./discourse-setup nur bis zum Rebuild-Teil des Launchers geht.

@Stephen, ja, ich muss zunächst die Probleme mit der Ubuntu-Installation lösen. Um ehrlich zu sein, bin ich kein großer Fan von Ubuntu und nutze seit 15 Jahren CentOS / RH. Was ich jedoch gerne wissen möchte: Erwartest du, dass wir für CentOS / RH etwas Bestimmtes einrichten müssen?

Das discourse-setup-Skript wurde auf Ubuntu getestet und erprobt.

Auf einer anderen Distribution müssen Sie möglicherweise einige oder alle Schritte manuell ausführen. Werfen Sie einen Blick auf den Inhalt der Datei, um zu verstehen, was sie tut.

Hallo @titusc,

es tut mir leid, dass du Probleme hast.

Nur als Info: Du musst nach dem Ausführen von:

./launcher rebuild app

nicht zusätzlich:

./launcher start app

ausführen, denn wenn du die App mit dem Launcher-Skript neu erstellst (siehe unten), startet dieses Skript den Container neu, bevor es beendet wird.

Hier ist ein relevanter Teil des Codes aus dem Launcher:

  rebuild)
      if [ "$(git symbolic-ref --short HEAD)" == "master" ]; then
        echo "Ensuring launcher is up to date"

        git remote update

        LOCAL=$(git rev-parse HEAD)
        REMOTE=$(git rev-parse @{u})
        BASE=$(git merge-base HEAD @{u})

        if [ $LOCAL = $REMOTE ]; then
          echo "Launcher is up-to-date"

        elif [ $LOCAL = $BASE ]; then
          echo "Updating Launcher..."
          git pull || (echo 'failed to update' && exit 1)

          echo "Launcher updated, restarting..."
          exec "$0" "${SAVED_ARGV[@]}"

        elif [ $REMOTE = $BASE ]; then
          echo "Your version of Launcher is ahead of origin"

        else
          echo "Launcher has diverged source, this is only expected in Dev mode"
        fi

      fi

      set_existing_container

      if [ ! -z $existing ]
        then
          echo "Stopping old container"
          (
            set -x
            $docker_path stop -t 60 $config
          )
      fi

      run_bootstrap

      if [ ! -z $existing ]
        then
          echo "Removing old container"
          (
            set -x
            $docker_path rm $config
          )
      fi

      run_start
      exit 0
      ;;

Wie du im Skript sehen kannst, versucht die rebuild-Methode, den Container zu starten, bevor das Skript beendet wird.

Hoffe, das hilft dir weiter.

@neounix, du hast recht. Ich werde es erneut testen und dies überprüfen. Hoffentlich war das die Ursache. Ich bin mir nicht sicher, welches Verhalten eintritt, wenn der Container gestartet wird und ich ihn erneut mit ./launcher start app starte.

Lieber @titusc,

Entschuldige bitte, dass ich nicht ausführlicher antworte, aber ich muss mich auf eine lange Roadtrip vorbereiten.

Viele Leute, die Fehler beim Erstellen, Neuerstellen von Docker-Images und Containern machen, geraten oft in Schwierigkeiten.

Du könntest in Betracht ziehen, deine “angesammelten” Docker-Images und ungenutzten Container irgendwann einmal aufzuräumen (zu bereinigen).

Zum Beispiel (kurz aus dem Kopf):

docker ps -a
docker images
docker system prune -a

Du solltest alle “schurkischen” Container stoppen, sie entfernen und alle alten Docker-Images löschen.

Ich muss los…

HTH

@neounix hat zugestimmt, die Docker-Images zu prüfen. Ich habe das tatsächlich bereits getan, aber lassen Sie mich das im Detail zeigen. Wie Sie unten sehen können, wurde Discourse erfolgreich erstellt und in einem Docker-Container gestartet. Gegen Ende sehen Sie, dass Nginx im Container lief, aber nach nur etwa 5 Sekunden wieder beendet wurde.

Bevor alles beginnt

[root@uat discourse]# pwd
/var/discourse
[root@uat discourse]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root@uat discourse]# docker container ls -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root@uat discourse]# docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
discourse/base      2.0.20200724-1815   6ba1506bf822        9 days ago          2.38GB
centos              latest              831691599b88        6 weeks ago         215MB
alpine              latest              a24bb4013296        2 months ago        5.57MB

Bestätigen, dass kein HTTP-Server auf dem Host läuft

[root@uat discourse]# systemctl status nginx
Unit nginx.service could not be found.
[root@uat discourse]# lsof -i TCP
COMMAND  PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd    1    root  181u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
systemd    1    root  183u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
rpcbind 1070     rpc    4u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
rpcbind 1070     rpc    6u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
sshd    1234    root    5u  IPv4   26444      0t0  TCP *:ssh (LISTEN)
sshd    1234    root    7u  IPv6   26446      0t0  TCP *:ssh (LISTEN)
cupsd   1240    root    9u  IPv6   27746      0t0  TCP localhost:ipp (LISTEN)
cupsd   1240    root   10u  IPv4   27747      0t0  TCP localhost:ipp (LISTEN)
dnsmasq 2094 dnsmasq    6u  IPv4   37419      0t0  TCP uat:domain (LISTEN)
sshd    7102    root    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)
sshd    7156    tech    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)

Discourse neu erstellen

[root@uat discourse]# ./launcher rebuild app
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
cd /pups && git pull && /pups/bin/pups --stdin
Already up to date.
......................................................................
I, [2020-08-03T06:54:22.114365 #1]  INFO -- : > echo "Beginning of custom commands"
I, [2020-08-03T06:54:22.116739 #1]  INFO -- : Beginning of custom commands

I, [2020-08-03T06:54:22.116996 #1]  INFO -- : > echo "End of custom commands"
I, [2020-08-03T06:54:22.119862 #1]  INFO -- : End of custom commands

I, [2020-08-03T06:54:22.119983 #1]  INFO -- : Terminating async processes
I, [2020-08-03T06:54:22.120021 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main pid: 49
I, [2020-08-03T06:54:22.120086 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 166
166:signal-handler (1596437662) Received SIGTERM scheduling shutdown...
2020-08-03 06:54:22.120 UTC [49] LOG:  received fast shutdown request
2020-08-03 06:54:22.121 UTC [49] LOG:  aborting any active transactions
2020-08-03 06:54:22.128 UTC [49] LOG:  background worker "logical replication launcher" (PID 58) exited with exit code 1
2020-08-03 06:54:22.128 UTC [53] LOG:  shutting down
2020-08-03 06:54:22.154 UTC [49] LOG:  database system is shut down
166:M 03 Aug 2020 06:54:22.176 # User requested shutdown...
166:M 03 Aug 2020 06:54:22.176 * Saving the final RDB snapshot before exiting.
166:M 03 Aug 2020 06:54:22.184 * DB saved on disk
166:M 03 Aug 2020 06:54:22.184 # Redis is now ready to exit, bye bye...
sha256:7b8e9281c49ba3dc37e0743a765cddc13ab73aae5486bd30722c696c2e1443b1
ce327c6e37246e63331f03b07d64f4882efa68e88cb1516c6343a9dddbbd59df

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_HOSTNAME=uat.xxxxxx.com -e DISCOURSE_DEVELOPER_EMAILS=support@xxxxxx.com -e DISCOURSE_SMTP_ADDRESS=smtp-relay.xxxxxx.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=support@xxxxxx.com -e DISCOURSE_SMTP_PASSWORD=support@xxxxxx.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h uat-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:fe:39:ba:65:e1 local_discourse/app /sbin/boot
44c604ccbda4bfb4d48722e1cbbf70e3b067531acda41175f6bdaaa013cc6d18

Bestätigen, dass das Image erstellt wurde und Docker läuft

[root@uat discourse]# docker container ls -a
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
44c604ccbda4        local_discourse/app   "/sbin/boot"        7 minutes ago       Up 7 minutes        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
[root@uat discourse]# docker ps
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
44c604ccbda4        local_discourse/app   "/sbin/boot"        7 minutes ago       Up 7 minutes        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
[root@uat discourse]# docker image ls
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app   latest              7b8e9281c49b        8 minutes ago       2.66GB
discourse/base        2.0.20200724-1815   6ba1506bf822        9 days ago          2.38GB
centos                latest              831691599b88        6 weeks ago         215MB
alpine                latest              a24bb4013296        2 months ago        5.57MB

Bestätigen, dass nichts mehr auf dem Host läuft und Docker auf den Ports 80 und 443 lauscht

[root@uat discourse]# systemctl status nginx
Unit nginx.service could not be found.
[root@uat discourse]#
[root@uat discourse]# lsof -i TCP
COMMAND     PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd       1    root  181u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
systemd       1    root  183u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
rpcbind    1070     rpc    4u  IPv4   19283      0t0  TCP *:sunrpc (LISTEN)
rpcbind    1070     rpc    6u  IPv6   19285      0t0  TCP *:sunrpc (LISTEN)
sshd       1234    root    5u  IPv4   26444      0t0  TCP *:ssh (LISTEN)
sshd       1234    root    7u  IPv6   26446      0t0  TCP *:ssh (LISTEN)
cupsd      1240    root    9u  IPv6   27746      0t0  TCP localhost:ipp (LISTEN)
cupsd      1240    root   10u  IPv4   27747      0t0  TCP localhost:ipp (LISTEN)
dnsmasq    2094 dnsmasq    6u  IPv4   37419      0t0  TCP uat:domain (LISTEN)
sshd       7102    root    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)
sshd       7156    tech    5u  IPv4 2072827      0t0  TCP uat:ssh->10.1.136.4:52229 (ESTABLISHED)
docker-pr 12991    root    4u  IPv6 2242261      0t0  TCP *:https (LISTEN)
docker-pr 13003    root    4u  IPv6 2242288      0t0  TCP *:http (LISTEN)

Docker neu starten und Nginx prüfen, nachdem Nginx gestoppt wurde

[root@uat discourse]# ./launcher stop app
+ /usr/bin/docker stop -t 10 app
app
[root@uat discourse]# ./launcher start app; ./launcher enter app

starting up existing container
+ /usr/bin/docker start app
app
root@uat-app:/var/www/discourse# date; ps -ef | grep nginx
Mon 03 Aug 2020 07:29:47 AM UTC
root        34     1  0 07:29 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/letsencrypt.conf
www-data    36    34  0 07:29 ?        00:00:00 nginx: worker process
www-data    37    34  0 07:29 ?        00:00:00 nginx: worker process
root      1091   398  0 07:29 pts/1    00:00:00 grep nginx
root@uat-app:/var/www/discourse# date; ps -ef | grep nginx
Mon 03 Aug 2020 07:29:50 AM UTC
root        34     1  0 07:29 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/letsencrypt.conf
www-data    36    34  0 07:29 ?        00:00:00 nginx: worker process
www-data    37    34  0 07:29 ?        00:00:00 nginx: worker process
root      1854   398  0 07:29 pts/1    00:00:00 grep nginx
root@uat-app:/var/www/discourse# date; ps -ef | grep nginx
Mon 03 Aug 2020 07:29:52 AM UTC
root      2043  2038  0 07:29 ?        00:00:00 runsv nginx
root      2080   398  0 07:29 pts/1    00:00:00 grep nginx
root@uat-app:/var/www/discourse#

Hallo @titusc,

danke für den großartigen Beitrag und die umfassenden Fehlerbehebungsinformationen. Sehr gut gemacht.

Hast du die nginx-Protokolldateien in der App auf Hinweise überprüft?

Bei deiner Einrichtung ist etwas kaputt. Meine Vermutung ist, dass das Problem, das die Installation von Ubuntu verhindert, auch CentOS beeinträchtigt.

Du musst das beheben, bevor du Discourse (oder wahrscheinlich irgendetwas anderes) installierst.