Discourse non serve pagine

Sto riscontrando alcuni problemi nell’esecuzione di Discourse dopo l’installazione.

Secondo la pagina seguente, dopo aver eseguito lo script discourse-setup, dovrei essere in grado di navigare all’URL configurato. A quanto pare, devo anche eseguire il seguente comando:
./launcher start app

Non sono sicuro se si tratti di un errore nella documentazione o di un errore mio. Ho inoltre notato che, dopo aver eseguito il comando sopra, si verificano le seguenti osservazioni:

  1. Riesco a caricare una pagina web quando navigo all’URL configurato.
  2. Viene caricata la pagina ‘Benvenuto in Nginx’ invece della pagina ‘Congratulazioni, hai installato Discourse!’.
  3. Dopo un breve periodo (ad esempio mezzo minuto), la pagina ‘Benvenuto in Nginx’ smette di caricarsi.
  4. Esegui ./launcher stop app seguito da ./launcher start app; noto che riesco a caricare la pagina ‘Benvenuto in Nginx’, ma dopo un breve periodo smette nuovamente di caricarsi.

Questa installazione è stata eseguita su una nuova VM dedicata senza Nginx in esecuzione sulla macchina, quindi la pagina ‘Benvenuto in Nginx’ proviene dal container che esegue Discourse.

Nessuna di queste cose è prevista. Sembra che tu abbia un altro nginx in esecuzione, forse? Qualcos’altro è in esecuzione sulla VM?

Non è possibile perché si tratta di un’installazione CentOS minimale e spartana. Ho verificato eseguendo il seguente comando: non c’è nulla in ascolto sulla porta 80 o 443 senza che il container sia in esecuzione.
lsof -i TCP

La mia migliore ipotesi è che ci sia un problema con CentOS e discourse-setup. La soluzione più semplice sarebbe provare con Ubuntu. In caso contrario, dovrai prestare attenzione a ciò che fa lo script e provare a risolvere il problema.

Se hai seguito la seguente guida all’installazione, raccomandata da qualcuno che non deve essere menzionato :smiley:

Non dovresti avere alcun problema.

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

Sigh, ho effettivamente provato, ma ho riscontrato che sia l’installer LTS 19 che quello 20 si bloccavano a metà. Entrambi segnalavano di non essere in grado di configurare automaticamente l’interfaccia. Se la lascio disabilitata, l’installer funziona correttamente, ma se imposto manualmente l’IP, si bloccano.

Se disabilito l’interfaccia per poter continuare con l’installazione, non riesco a installare gli strumenti di rete per ottenere ifconfig, nemmeno montando l’ISO e utilizzandola come sorgente. Quindi sono un po’ bloccato.

Ciao @titusc

Cosa vedi quando esegui:

docker ps

?

Stai dicendo che il programma di installazione di Ubuntu non funziona?

O stai cercando di usare il solito Discourse con un numero IP invece che con un nome di dominio?

Non sto utilizzando un indirizzo IP per l’installazione di Discourse. Sto usando un nome di dominio corretto che è risolvibile nel DNS pubblico.

Sto dicendo che l’installer di Ubuntu si blocca sempre quando provo a eseguirlo avviando l’immagine ISO di Ubuntu durante la creazione della macchina. Questo accade sia per Ubuntu Server 19.10 che per 20.04 LTS, e in entrambi i casi durante l’installazione viene segnalato che non è possibile configurare l’interfaccia di rete. Se lascio le cose così, l’installazione procede correttamente, ma non ho modo di attivare l’interfaccia per fare qualsiasi cosa. Ho eseguito con successo il seguente comando:
ip address add <ip>/<mask> dev <interface>

Ma poi non riesco ad attivarla eseguendo il seguente comando:
ifup <interface>

Ho poi montato l’ISO come loopback, l’ho configurata come repository e ho provato a eseguire il seguente comando, ma dice che non è stato trovato nell’ISO:
apt install net-tools

Se provo a impostare manualmente l’interfaccia con i dettagli di rete durante l’installazione, entrambe le versioni si bloccano.

Per la cronaca, sto facendo tutto questo su ESXi 7.0 e sto utilizzando le seguenti ISO:
ubuntu-20.04-live-server-amd64.iso
ubuntu-19.10-live-server-amd64.iso

Mostrerebbe che il container Discourse è in esecuzione. Ogni volta che eseguo quanto segue:

  1. ./launcher start app
  2. Controllo nel browser e vedo la pagina ‘Welcome to Nginx’, ma poi non più dopo circa mezzo minuto.
  3. docker ps per confermare che il container Discourse è in esecuzione.
  4. ./launcher stop app e ./launcher start app
  5. Controllo nel browser e vedo la pagina ‘Welcome to Nginx’, ma poi non più dopo circa mezzo minuto.
  6. docker ps per confermare che il container Discourse è in esecuzione.

Ho anche notato che quando eseguo i seguenti comandi non riesco a vedere Nginx in esecuzione, ma potrebbe essere perché è già stato fermato al momento dell’esecuzione.
./launcher enter app
systemctl status nginx

@titusc

Hai provato a ricompilare l’app?

/var/discourse/launcher rebuild app

Normalmente, a seconda di quanto tempo impiega il contenitore per avviarsi completamente, possono volerci dei minuti (in base alle specifiche del tuo sistema) prima che sia pienamente operativo.

Anche sulla nostra macchina Linux da 64 GB con 8 core CPU, aspettiamo circa un minuto intero prima di passare al nuovo contenitore.

Hai provato la 18.04?

Sembra un problema ambientale; tuttavia, non possiamo offrire supporto per gli hypervisor e le distribuzioni Linux. Uno dei motivi per cui DigitalOcean è consigliato è la coerenza del sistema operativo su cui viene installato. Se desideri creare una VM da zero, dovrai risolvere questa questione in anticipo.

Una volta che avrai un sistema operativo funzionante, potremo aiutarti a installare la parte relativa a Discourse.

Ciao @DBHacker, sì, ho eseguito quanto segue in sequenza:
./launcher rebuild app
./launcher start app

Questo dopo aver capito che quanto segue serve solo fino alla fase di rebuild del launcher:
./discourse-setup

@Stephen, sì, devo prima risolvere i problemi con l’installazione di Ubuntu. A dire il vero, non sono molto favorevole a Ubuntu e negli ultimi 15 anni ho utilizzato CentOS / RH. Tuttavia, vorrei chiederti: ti aspetti che dobbiamo configurare qualcosa di specifico per CentOS / RH?

Lo script discourse-setup è stato testato e funziona su Ubuntu.

Su una distribuzione diversa, potrebbe essere necessario eseguire alcuni o tutti i passaggi manualmente. Esamina il contenuto del file per capire cosa fa.

Ciao @titusc

Mi dispiace che tu stia riscontrando problemi.

Per tua informazione, non è necessario eseguire:

./launcher start app

dopo aver eseguito:

./launcher rebuild app

perché quando ricompili l’app con lo script launcher (vedi sotto), tale script riavvia il contenitore prima di uscire.

Ecco una parte rilevante del codice del launcher:

  rebuild)
      if [ "$(git symbolic-ref --short HEAD)" == "master" ]; then
        echo "Assicurandosi che il launcher sia aggiornato"

        git remote update

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

        if [ $LOCAL = $REMOTE ]; then
          echo "Il launcher è aggiornato"

        elif [ $LOCAL = $BASE ]; then
          echo "Aggiornamento del launcher..."
          git pull || (echo 'aggiornamento fallito' && exit 1)

          echo "Launcher aggiornato, riavvio..."
          exec "$0" "${SAVED_ARGV[@]}"

        elif [ $REMOTE = $BASE ]; then
          echo "La tua versione del launcher è più recente rispetto all'originale"

        else
          echo "Il launcher ha divergenze nel codice sorgente, questo è previsto solo in modalità Dev"
        fi

      fi

      set_existing_container

      if [ ! -z $existing ]
        then
          echo "Arresto del vecchio contenitore"
          (
            set -x
            $docker_path stop -t 60 $config
          )
      fi

      run_bootstrap

      if [ ! -z $existing ]
        then
          echo "Rimozione del vecchio contenitore"
          (
            set -x
            $docker_path rm $config
          )
      fi

      run_start
      exit 0
      ;;

Come puoi vedere dallo script, il metodo rebuild tenta di avviare il contenitore prima di uscire.

Spero ti sia utile.

@neounix hai ragione. Proverò di nuovo e controllerò questo aspetto. Speriamo che questa sia stata la causa. Non sono sicuro di quale sia il comportamento se avvio il contenitore e poi lo riavvio eseguendo ./launcher start app

Ciao @titusc,

Scusa se non rispondo con più dettagli, ma devo partire per un lungo viaggio in auto.

Molte persone che commettono errori nella costruzione, ricostruzione di immagini Docker e container tendono a finire nei guai.

Potresti valutare di pulire (pruning) le tue immagini Docker “accumulate” e i container non utilizzati in un secondo momento.

Ad esempio (a memoria, velocemente)

docker ps -a
docker images
docker system prune -a

Dovresti fermare tutti i container “fuori controllo”, rimuoverli ed eliminare tutte le vecchie immagini Docker.

Devo andare…

Spero ti sia utile.

@neounix concorda sul controllo delle immagini Docker. In realtà l’ho già fatto, ma lasciami mostrartelo in dettaglio. Come puoi vedere di seguito, Discourse è stato costruito con successo ed è iniziato l’avvio in un contenitore Docker. Verso la fine si può vedere che Nginx era in esecuzione nel contenitore, ma si è arrestato dopo soli 5 secondi circa.

Prima dell’avvio di tutto

[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 giorni fa         2.38GB
centos              latest              831691599b88        6 settimane fa      215MB
alpine              latest              a24bb4013296        2 mesi fa           5.57MB

Conferma che nessun server HTTP sia in esecuzione sull’host

[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)

Ricostruisci Discourse

[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

Conferma che l’immagine è stata costruita e che Docker è in esecuzione

[root@uat discourse]# docker container ls -a
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
44c604ccbda4        local_discourse/app   "/sbin/boot"        7 minuti fa         Up 7 minuti         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 minuti fa         Up 7 minuti         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 minuti fa         2.66GB
discourse/base        2.0.20200724-1815   6ba1506bf822        9 giorni fa         2.38GB
centos                latest              831691599b88        6 settimane fa      215MB
alpine                latest              a24bb4013296        2 mesi fa           5.57MB

Conferma che nulla sia ancora in esecuzione sull’host e che Docker stia ascoltando sulle porte 80 e 443

[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)

Riavvia Docker e controlla Nginx dopo che Nginx si è arrestato

[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#

Ciao @titusc

Grazie per il ottimo post e le informazioni complete sulla risoluzione dei problemi. Molto ben fatto.

Hai controllato i file di log di nginx nell’app per cercare indizi?

C’è un problema nella tua configurazione. Secondo me, ciò che impedisce l’installazione di Ubuntu sta interferendo anche con CentOS.

Devi risolvere il problema prima di installare Discourse (o probabilmente qualsiasi altra cosa).