Problème étrange avec une nouvelle installation de Postgres DB

Soutien Installation
1

Voici un cas que je n’arrive pas à résoudre, malgré de nombreuses installations et migrations Discourse parfaitement réussies.

Contexte :

Nous avions Discourse qui fonctionnait correctement dans un conteneur Docker et nous travaillions sur quelques subtilités de la base de données PostgreSQL.

Le problème est survenu lorsque nous n’étions pas satisfaits des résultats de la régénération des publications brutes ; rien ne fonctionnait comme prévu. Nous avons donc décidé de supprimer la base de données postgres et de la recréer, mais l’application continuait à afficher diverses erreurs de permissions, etc.

Ensuite, nous avons décidé de « passer à la vitesse supérieure » et de tout détruire dans un style « tant pis » ; nous sommes donc allés directement dans postgres (sachant que cela ne se passerait probablement pas bien, mais voulant essayer) et avons supprimé tous les sujets et toutes les publications de la base de données (DELETE FROM topics; DELETE FROM posts;). Cela a fonctionné dans une certaine mesure, mais nous n’étions pas satisfaits des résultats (expérience terminée). Nous avons donc décidé de reconstruire Discourse à partir de zéro, en déplaçant l’ancien répertoire /var/discourse et en effectuant un git pull pour repartir sur de nouvelles bases.

Le problème

Lorsque nous construisons entièrement un nouveau environnement à partir d’un git pull, l’installation fonctionne bien jusqu’à l’étape où nous accédons au site pour créer la connexion administrateur.

Lorsque nous nous sommes rendus sur la page de connexion administrateur pour une nouvelle installation, c’est l’ancien site que nous avions détruit qui s’est affiché ! Cela nous a surpris.

Nous avons donc décidé d’entrer dans cette nouvelle application et de supprimer toutes les tables Discourse de la base de données, ce que nous avons fait. Mais, surprise : lorsque nous avons reconstruit l’application à nouveau, ce n’était pas un site neuf, mais le même site cassé que précédemment.

Nous avons donc supprimé tous les répertoires /var/*discourse* et supprimé toutes les images Docker, pensant que cela garantirait un environnement totalement propre, puis avons recommencé depuis le début en effectuant un git pull vers /var/discourse et en construisant à partir de ce que nous pensions être zéro absolu. Mais surprise : l’ancien site est toujours là.

En nous demandant : « Comment est-ce possible ? »…

Nous avons exécuté ps aux | grep postgres en dehors du conteneur Docker et avons remarqué que postgres existait en dehors du conteneur (ce qui était une surprise, car nous pensions à tort que l’installation Docker de Discourse se trouvait entièrement dans le conteneur). Nous avons ensuite tenté de trouver où effectuer le nettoyage, mais sans succès.

Nous avons cherché jusqu’à ce que les liens Google deviennent violets, avons essayé tellement de choses… mais nous n’arrivons pas à obtenir une installation propre de Discourse.

Pensant qu’il nous manquait quelque chose, nous avons pris un nouveau serveur sur lequel Discourse n'avait jamais été installé, nous y avons installé Discourse à partir de zéro, et cela a fonctionné parfaitement comme d’habitude (sur un autre serveur).

La question

Ma question est donc la suivante : lorsqu’une installation a complètement déraillé (par tous les moyens), comment pouvons-nous remettre le serveur, y compris PostgreSQL, à zéro afin que ce problème disparaisse et que nous puissions procéder à une toute nouvelle installation propre ?

Désolé pour un post aussi long, alors que la question aurait peut-être suffi pour obtenir de l’aide.

Merci.

2

Au lieu de supprimer ou de vider les tables, supprimez simplement la base de données.

3

Merci. Je vais essayer cela et revenir vers vous avec les résultats.

4

J’ai essayé de supprimer la base de données, mais je continue d’obtenir cette erreur de permissions :

/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
postgres=# drop database discourse;
ERROR: database "discourse" is being accessed by other users
DETAIL: There are 3 other sessions using the database.

Des indices ?

5

Ma meilleure hypothèse est que vous n’avez pas supprimé le conteneur Docker en cours d’exécution, mais que vous affirmez avoir supprimé les images. Et il semble que vous auriez reçu une autre indication.

Ou alors, utilisez-vous une base de données PostgreSQL externe plutôt que celle contenue dans le conteneur ?

En général, supprimer le dossier /var/discourse/shared et effectuer une reconstruction résout le problème.

6

Merci.

Nous venons de tuer toutes les sessions de base de données discourse précédentes, ce qui nous a permis de supprimer la base de données discourse.

Nous effectuons à nouveau la manipulation ./launcher rebuild app. Je reviendrai vers vous avec les résultats.

7

./launch rebuild app n’a pas fonctionné ; voici donc ce que nous avons fait ensuite :

Ensuite :

Building app

WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed

Please be patient

Unable to find image ‘discourse/base:2.0.20200220-2221’ locally
2.0.20200220-2221: Pulling from discourse/base
bc51dd8edc1b: Pulling fs layer
27ae5d171719: Pulling fs layer
bc51dd8edc1b: Download complete
bc51dd8edc1b: Pull complete
27ae5d171719: Verifying Checksum
27ae5d171719: Download complete
27ae5d171719: Pull complete
blah blah…
blah blah…
blah blah…


Toujours pas de succès après une reconstruction et un lancement sans erreur.

Nous avons donc réessayé en désactivant l'option LETSENCRYPT :

* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF

Et il est toujours en train de construire l'instance précédente (détruite il y a plusieurs heures), car dans cette instance, nous avions installé plusieurs thèmes, et ils sont toujours présents dans cette nouvelle construction, même après avoir ```supprimé``` la base de données ```discourse``` :

Start compiling CSS: 2020-03-15 10:16:20 UTC
Compiling css for default 2020-03-15 10:16:20 UTC
precompile target: desktop Dark
precompile target: mobile Dark
precompile target: desktop_rtl Dark
precompile target: mobile_rtl Dark
precompile target: desktop_theme Dark
precompile target: mobile_theme Dark
precompile target: admin Dark
precompile target: desktop Light
precompile target: mobile Light
precompile target: desktop_rtl Light
precompile target: mobile_rtl Light
precompile target: desktop_theme Light
precompile target: mobile_theme Light
precompile target: admin Light
precompile target: desktop
precompile target: mobile
precompile target: desktop_rtl
precompile target: mobile_rtl
precompile target: desktop_theme
precompile target: mobile_theme
precompile target: admin
Done compiling CSS: 2020-03-15 10:16:27 UTC


Comment est-il possible qu'après avoir supprimé l'intégralité de la base de données ```discourse```, purgé toutes les images et conteneurs Docker, effacé ```rm -rf /var/discourse``` et reconstruit à partir de zéro, nous voyions toujours tous les thèmes installés provenant de la construction vieille de plusieurs heures que nous tentons de détruire complètement ?

Cela n'a aucun sens dans le cadre d'une installation fraîche.
8

Eh bien, nous avons recommencé depuis le début, avons commenté les modèles LETSENCRYPT et l’option e-mail, et avons réussi à reconstruire correctement le système pour afficher la page de connexion de l’administrateur de célébration.

Des progrès !

Maintenant, nous allons modifier app.yml et essayer de réactiver SSL.

9

Eh bien. C’est intéressant…

Si je reconstruis l’application avec SSL (LETS ENCRYPT) activé, j’obtiens deux sites différents…

  • HTTP : Nouveau site comme prévu
  • HTTPS : Ancien site cassé

Hmmmm. C’est vraiment déroutant !

10

Que montre

 docker ps

?

11

Avant chaque build, nous supprimions tous les anciennes images Docker, etc., comme suit :

docker system prune -a

Donc, ce n’est pas un problème d’image Docker.

Nous pensons que le problème est lié au certificat SSL LETSENCRYPT ; car lorsque nous avons changé le sous-domaine et généré un nouveau certificat SSL lors du processus de build sur la même adresse IP du serveur, tout fonctionne comme prévu ; mais lorsque nous revenons au sous-domaine d’origine, le problème persiste.

Par conséquent, nous avons abandonné l’utilisation du sous-domaine problématique pour le moment (c’était de toute façon un domaine de staging) ; et nous avons poursuivi.

Merci pour vos idées.

Restez en sécurité.

12

Mais cela ne supprime que les images inutilisées. Êtes-vous sûr qu’aucun conteneur n’est en cours d’exécution ?

13

Ça ressemble à une configuration avec plusieurs conteneurs — y a-t-il plus qu’un fichier app.yml dans votre dossier de conteneurs ?

14

La commande docker ps affiche un seul conteneur en cours d’exécution et il n’existe qu’un seul fichier app.yml dans /var/discourse/containers.

Merci pour toutes ces bonnes idées, quand même !

Très apprécié.