Nouvelle installation échoue sur Ubuntu 20.04.3 LTS

Soutien Installation
1

Une nouvelle installation sur une nouvelle instance EC2 avec une configuration standard échoue. J’ai lancé une instance EC2 sur AWS avec Ubuntu 20.04.3 et appliqué toutes les dernières mises à jour d’Ubuntu. J’ai exécuté l’installation standard simple décrite ici :

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse

./discourse-setup

La seule particularité est que lors de l’exécution de la configuration, la connexion au serveur via HTTP(S) a échoué — j’avais oublié d’ouvrir les deux ports entrants sur AWS. J’ai donc configuré manuellement mon fichier app.yml et exécuté ./launcher rebuild app après avoir ouvert les ports dans le groupe de sécurité AWS.

Le navigateur ne parvient pas à se connecter et mon journal de production affiche ceci :

/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)

Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'

J’ai lancé une nouvelle instance EC2 car j’utilisais précédemment un serveur réaffecté, également sous Ubuntu 20.04.3, qui présentait exactement le même problème lors de l’installation de Discourse. Les mêmes erreurs apparaissent dans le journal de production. J’ai donc pensé qu’il valait mieux repartir de zéro et rendre cela simple.

2

Avez-vous essayé de redémarrer ?

3

Oui, j’ai démarré et arrêté l’instance, puis redémarré via la ligne de commande. Cela n’a pas aidé.

4

OK, maintenant je suis assez convaincu qu’il y a un problème avec l’installateur Discourse lorsqu’il s’agit d’utiliser Ubuntu 20.04.3 avec les dernières mises à jour. Je viens de relancer l’installateur et cette fois, j’ai veillé à ce que les ports soient ouverts, de sorte que je n’ai jamais eu besoin de configurer manuellement le fichier app.yml (éliminant ainsi les erreurs humaines). Tout semblait se dérouler sans accroc : l’installation a détecté le domaine, etc. Cependant… aucun site. Le journal de production indique :

/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL)

Erreur de connexion à Redis sur localhost:6379 (Errno::EADDRNOTAVAIL) : l'abonnement a échoué, reconnexion dans 1 seconde. Stack d'appel /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:365:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:117:in `block in connect'

C’est trop simple pour que j’aie pu faire une erreur cette fois ; je n’ai fait qu’exécuter les scripts.

5

Avez-vous une autre instance Redis installée ?

Combien de RAM avez-vous ? A-t-elle créé un fichier d’échange (swap) ?

6

Je n’ai rien installé. Il s’agit d’une nouvelle instance EC2 t2.small avec 2 Go de RAM. Je dois vérifier le fichier d’échange standard qu’elle crée.

7

Voici les informations sur la RAM et l’espace d’échange (swap). Il s’agit d’une instance AWS neuve et standard (vanilla), entièrement mise à jour avec les mises à jour Ubuntu habituelles. C’est une instance EC2 de type t2.small. Rien n’a été modifié, ajouté, configuré ou altéré. Les seules commandes utilisées pour mettre à jour avant l’installation étaient les commandes de base sudo apt update et sudo apt upgrade. C’est la troisième fois que j’essaie d’installer Discourse de manière standard sur deux instances distinctes avec le même système d’exploitation (Ubuntu 20.04.3). C’est pourquoi je pense qu’il pourrait y avoir un problème avec le programme d’installation et la version récente.

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       973Mi       131Mi        36Mi       875Mi       855Mi
Swap:         2.0Gi       0.0Ki       2.0Gi

Espace disque, au cas où cela poserait problème :

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        39G  7.8G   31G  20% /
8

Je viens d’effectuer une installation sur un nouveau droplet Digital Ocean et tout s’est bien passé. Le problème ne vient donc pas de l’installateur.

Mon meilleur scénario, même si cela semble étrange que vous ayez une erreur Redis, est que vous ayez lancé l’installateur suffisamment de fois pour atteindre la limite de taux de Let’s Encrypt, ce qui constituerait le vrai problème.

Réessayez avec un autre nom de domaine (par exemple, forum2.exemple.com).

9

Bingo ! Vous avez encore raison, cela a fonctionné.

Bon, alors, j’ai beaucoup reconstruit parce que j’ai testé le transfert d’un forum depuis un ancien serveur.

Comment diable puis-je contourner ce problème ? Je n’utilise même pas Let’s Encrypt. Après l’installation réussie, j’ai mis à jour le fichier app.yml pour modifier le domaine et j’ai m’assuré que le modèle Let’s Encrypt était commenté dans app.yml, puis j’ai reconstruit, mais cela n’a pas aidé et je rencontre toujours le même problème : échec de Redis. Suis-je coincé parce que l’appel à Let’s Encrypt est intégré dans l’installateur ?

10

À moins que vous n’utilisiez un proxy inverse pour fournir du HTTPS, vous ne pouvez pas faire cela. Vous devez avoir du HTTPS. Et si vous supprimez Let’s Encrypt, vous devez également supprimer le modèle HTTPS (quel que soit son nom).

Je ne comprends pas tout à fait pourquoi vous rencontrez l’erreur Redis ; peut-être avez-vous commenté Redis lorsque vous avez commenté Let’s Encrypt ? C’est ma meilleure hypothèse.

Vous pouvez essayer de suivre Set up Let’s Encrypt with multiple domains / redirects pour ajouter un deuxième nom de domaine, ou attendre une semaine.

11

Eh bien, si vous lisez l’intégralité du fil, il s’agit d’une installation simple sur une toute nouvelle instance, donc je n’aurais pas pu commenter quoi que ce soit, car l’installateur, basé sur les questions posées, est ce qui crée le fichier app.yml. Ainsi, l’échec de Redis est directement lié à la limite de taux de Let’s Encrypt. Si cela peut aider l’équipe de développement d’une quelconque manière.

J’utilise un proxy, ou plutôt Cloudflare, pour servir le certificat SSL et ne connecter/distribuer que du HTTPS.

J’ai testé en commentant le modèle HTTPS « templates/web.ssl.template.yml » et en exécutant launcher rebuild app, bien sûr, tout en ayant également le modèle Let’s Encrypt commenté, et la même chose s’est produite. Erreur Redis. Donc je suppose que je suis coincé, n’est-ce pas ? Quelle décision d’installateur lamentable, de ne pas prévoir de moyen de contourner les appels à Let’s Encrypt. À moins que vous ne puissiez me proposer autre chose à essayer, la patience sera une vertu dans ce cas. J’apprécie vraiment toute votre aide. Je reste humblement frustré.

12

Cela rend les choses beaucoup plus compliquées et vous rencontrerez d’autres problèmes plus tard, à moins de vous renseigner soigneusement sur la façon d’utiliser Cloudflare sans casser Discourse.