Discourse ne sert pas de pages

Soutien Installation
1

Je rencontre des problèmes lors de l’exécution de Discourse après l’installation.

Selon la page suivante, une fois le script discourse-setup exécuté, je devrais pouvoir naviguer vers l’URL configurée. Apparemment, je dois également appeler la commande suivante :
./launcher start app

Je ne sais pas s’il s’agit d’une erreur dans la documentation ou d’une erreur de ma part ? J’ai également remarqué qu’après avoir exécuté la commande ci-dessus, j’observe ce qui suit :

  1. Je peux charger une page Web en naviguant vers l’URL configurée.
  2. La page ‘Welcome to Nginx’ s’affiche au lieu de la page ‘Congratulations, you installed Discourse !’.
  3. Après un court moment (par exemple, une demi-minute), la page ‘Welcome to Nginx’ ne se charge plus.
  4. En exécutant ./launcher stop app suivi de ./launcher start app, je remarque que je peux à nouveau charger la page ‘Welcome to Nginx’, mais pas après un court moment, à nouveau.

Ceci est installé sur une nouvelle machine virtuelle dédiée sans Nginx en cours d’exécution sur la machine, donc la page ‘Welcome to Nginx’ provient du conteneur exécutant Discourse.

2

Aucune de ces choses n’est attendue. On dirait que vous avez un autre nginx en cours d’exécution, peut-être ? Y a-t-il autre chose qui s’exécute sur la VM ?

1 « J'aime »
3

Ce n’est pas possible car il s’agit d’une installation CentOS minimaliste et dépouillée. J’ai vérifié en exécutant la commande suivante : rien n’écoute sur les ports 80 ou 443 sans le conteneur en cours d’exécution.
lsof -i TCP

1 « J'aime »
4

Mon meilleur avis est qu’il y a un problème avec Centos et discourse-setup. Le plus simple serait d’essayer Ubuntu. Sinon, vous devrez prêter attention à ce que fait le script et essayer de déboguer le problème.

5

Si vous avez suivi le guide d’installation ci-dessous, recommandé par quelqu’un que nous ne nommerons pas :smiley:

Vous ne devriez rencontrer aucun problème.

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

1 « J'aime »
6

Soupir J’ai vraiment essayé, mais j’ai constaté que les installateurs LTS 19 et 20 plantaient à mi-parcours. Les deux indiquaient qu’ils ne pouvaient pas configurer automatiquement l’interface. Si je la laisse désactivée, l’installateur fonctionne correctement, mais si je configure l’IP manuellement, ils plantent.

Si je désactive l’interface pour pouvoir poursuivre l’installation, je ne peux pas installer les outils réseau pour obtenir ifconfig, même si j’ai monté l’ISO et l’ai utilisée comme source. Je suis donc un peu coincé.

7

Bonjour @titusc

Que voyez-vous lorsque vous exécutez :

docker ps

?

8

Vous dites que l’installateur Ubuntu ne fonctionne pas ?

Ou essayez-vous d’utiliser Discourse habituellement avec un numéro IP plutôt qu’un nom de domaine ?

1 « J'aime »
9

Je n’utilise pas d’adresse IP pour l’installation de Discourse. J’utilise un nom de domaine valide qui est résoluble via DNS public.

Je signale que l’installateur Ubuntu plante systématiquement lorsque j’essaie de l’exécuter en démarrant sur l’image ISO d’Ubuntu lors de la création de la machine. Cela se produit à la fois avec Ubuntu Server 19.10 et 20.04 LTS. Dans les deux cas, l’installation indique qu’elle ne peut pas configurer l’interface réseau. Si je laisse les paramètres par défaut, l’installation se déroule correctement, mais je n’ai aucun moyen de lever l’interface pour effectuer des actions.

J’ai réussi à exécuter la commande suivante :
ip address add <ip>/<masque> dev <interface>

Cependant, je ne parviens pas à activer l’interface en exécutant :
ifup <interface>

J’ai ensuite monté l’ISO en boucle, configuré un dépôt et tenté d’exécuter la commande suivante, mais le système indique que le paquet n’est pas trouvé dans l’ISO :
apt install net-tools

Si j’essaie de configurer manuellement l’interface avec les détails réseau pendant l’installation, les deux versions plantent.

Pour information, je réalise cette opération sur ESXi 7.0 en utilisant les ISO suivants :
ubuntu-20.04-live-server-amd64.iso
ubuntu-19.10-live-server-amd64.iso

10

Cela devrait montrer que le conteneur Discourse est en cours d’exécution. À chaque fois que je fais ce qui suit :

  1. ./launcher start app
  2. Je vérifie dans le navigateur et je vois la page « Welcome to Nginx », mais plus après environ une demi-minute.
  3. docker ps pour confirmer que le conteneur Discourse est en cours d’exécution.
  4. ./launcher stop app puis ./launcher start app
  5. Je vérifie dans le navigateur et je vois la page « Welcome to Nginx », mais plus après environ une demi-minute.
  6. docker ps pour confirmer que le conteneur Discourse est en cours d’exécution.

Ce que je remarque aussi, c’est que lorsque j’exécute les commandes suivantes, je ne vois pas Nginx en cours d’exécution, mais cela pourrait être dû au fait qu’il a déjà été arrêté au moment où je les lance :
./launcher enter app
systemctl status nginx

11

@titusc

Avez-vous essayé de reconstruire l’application ?

/var/discourse/launcher rebuild app

Généralement, selon le moment où votre conteneur démarre complètement, cela peut prendre du temps (selon les spécifications de votre système) pour être pleinement opérationnel.

Même sur notre machine Linux de 64 Go avec 8 cœurs de processeur, nous attendons environ une minute complète avant de basculer vers le nouveau conteneur.

1 « J'aime »
12

Avez-vous essayé la version 18.04 ?

Cela ressemble à un problème d’environnement, mais nous ne pouvons pas vraiment offrir de support pour les hyperviseurs et les distributions Linux ici. L’une des raisons pour lesquelles DigitalOcean est recommandé est la cohérence du système d’exploitation sur lequel il est installé. Si vous souhaitez créer une machine virtuelle à partir de zéro, vous devrez régler cela au préalable.

Une fois que vous aurez un système d’exploitation fonctionnel, nous pourrons vous aider à installer la partie Discourse.

13

Bonjour @DBHacker, oui, j’ai bien effectué les étapes suivantes dans l’ordre :
./launcher rebuild app
./launcher start app

C’est après avoir réalisé que la commande suivante ne fait que jusqu’à l’étape de reconstruction du lanceur :
./discourse-setup

@Stephen, oui, je dois d’abord résoudre les problèmes liés à l’installation d’Ubuntu. Pour être honnête, je ne suis pas un grand fan d’Ubuntu et j’utilise CentOS / RH depuis les 15 dernières années. Cependant, ce que je voudrais demander, c’est : attendez-vous à ce que nous configurions quelque chose de spécifique pour CentOS / RH ?

14

Le script discourse-setup a été testé et validé sur Ubuntu.

Vous devrez peut-être effectuer tout ou partie des étapes manuellement sur une autre distribution. Jetez un coup d’œil au contenu du fichier pour comprendre ce qu’il fait.

15

Bonjour @titusc,

Désolé d’apprendre que vous rencontrez des problèmes.

Pour information, vous n’avez pas besoin d’exécuter :

./launcher start app

après avoir lancé :

./launcher rebuild app

car lorsque vous reconstruisez l’application avec le script launcher (voir ci-dessous), ce script redémarre le conteneur avant de se terminer.

Voici un extrait pertinent du code du 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
      ;;

Vous pouvez voir dans le script que la méthode rebuild tente de démarrer le conteneur avant de se terminer.

J’espère que cela vous aide.

16

@neounix tu as raison. Je vais retester et vérifier cela. J’espère que c’était la cause. Je ne suis pas sûr du comportement si le conteneur est déjà lancé et que je le relance en exécutant ./launcher start app.

17

Cher @titusc,

Désolé de ne pas répondre plus en détail, mais je dois partir pour un long voyage sur la route.

Beaucoup de personnes qui commettent des erreurs lors de la création, de la reconstruction d’images Docker et de conteneurs finissent par avoir des problèmes.

Vous pourriez envisager de nettoyer (pruner) vos images Docker « accumulées » et vos conteneurs inutilisés à un moment donné.

Par exemple (de mémoire, rapidement) :

docker ps -a

docker images

docker system prune -a

Vous devriez arrêter tous les conteneurs « errants », les supprimer et effacer toutes les anciennes images Docker.

Je dois y aller…

J’espère que cela vous aidera.

1 « J'aime »
18

@neounix a approuvé la vérification des images Docker. Je l’ai en fait déjà faite, mais laissez-moi vous montrer cela en détail. Comme vous pouvez le voir ci-dessous, Discourse a été construit avec succès et a commencé à s’exécuter dans un conteneur Docker. Vers la fin, vous pouvez voir que Nginx était en cours d’exécution dans le conteneur, mais s’est arrêté après seulement environ 5 secondes.

Avant que tout ne commence

[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 jours ago         2.38GB
centos              latest              831691599b88        6 semaines ago      215MB
alpine              latest              a24bb4013296        2 mois ago          5.57MB

Confirmer qu’aucun serveur HTTP n’est en cours d’exécution sur l’hôte

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

Reconstruire 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

Confirmer que l’image est construite et que Docker est en cours d’exécution

[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

Confirmer que rien ne s’exécute toujours sur l’hôte et que Docker écoute sur les ports 80 et 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)

Redémarrer Docker et vérifier Nginx après que Nginx s’est arrêté

[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#
1 « J'aime »
19

Bonjour @titusc,

Merci pour votre excellent article et les informations de dépannage complètes. Très bien fait.

Avez-vous vérifié les fichiers journaux de nginx dans l’application pour trouver des indices ?

20

Quelque chose ne fonctionne pas dans votre configuration. Je parie que ce qui empêche l’installation d’Ubuntu interfère également avec CentOS.

Vous devez régler ce problème avant d’installer Discourse (ou probablement tout autre chose).