Avatars perdus après restauration. Comment les récupérer ?

Soutien
1

J’ai effectué une installation propre de Discourse et restauré la sauvegarde prise ce même soir (en utilisant l’interface de Discourse pour effectuer la sauvegarde et la restauration).

La sauvegarde comprenait la base de données et les fichiers uploadés.

Après la restauration et le rebuild de l’application Discourse (comme je le suppose nécessaire en raison des changements de configuration suite à l’installation propre), nous rencontrons un problème.

Les avatars de toutes les personnes ayant personnalisé leur image de profil ont été perdus.

Je pense que cela est lié à l’optimisation des images ; peut-être faut-il effectuer une action supplémentaire (au-delà du rebuild de l’application via le launcher) pour les recréer.

Mais je n’ai pas trouvé quelle étape manquante il faut suivre.

J’ai trouvé un sujet de personnes ayant perdu les avatars par défaut (ceux distribués avec Discourse), mais ce n’est pas notre cas : les personnes qui n’ont pas changé leur avatar (et n’ont pas téléchargé d’image) ont toujours leur avatar avec la lettre initiale en place.

MISE À JOUR :

J’ai exécuté :
./launcher enter app
rake posts:rebake

mais cela n’a pas résolu le problème.

Serait-ce que ce n’est pas posts:rebake qu’il faut utiliser ?

2

@arinaf,

Étrangement, la même chose m’est arrivée aujourd’hui sur une configuration avec un proxy inverse nginx vers un socket Unix. Tout était parfait, mais les images d’avatar personnalisées s’affichaient sous forme d’icônes (l’icône de personne), et tous les avatars basés sur les lettres étaient corrects.

Pendant le dépannage, je suis revenu à une configuration standard à deux conteneurs (sans front-end nginx, sans socket Unix) et le problème a disparu.

Ensuite, je suis revenu à la configuration avec proxy inverse nginx vers un socket Unix, et le problème est réapparu.

Je suis à court d’idées… alors je fais une pause pour un moment :slight_smile:

Évidemment, les données sont intactes car tout fonctionne parfaitement sans proxy inverse nginx, ce qui est étrange puisque cela fonctionne bien sans lui. LOL. (Tout fonctionnait sans faille dans les deux cas, et soudainement le problème bizarre d’avatar est apparu…)

3

C’est exactement ma configuration, car j’exécute d’autres logiciels dans un conteneur Docker (un blog Ghost).
J’utilise nginx comme proxy inverse.

Évidemment, la restauration des sauvegardes n’est pas aussi simple qu’il y paraît.

J’ai effectué des rebakes, pensant qu’il s’agissait d’un problème de non-enregistrement des miniatures, sans succès.

Je vais essayer ce que vous proposez pour confirmer si le problème vient du proxy inverse (je ne vois pas pourquoi cela pourrait interférer, mais je n’ai rien à perdre en essayant).

4

Oui… je ne pense pas que le problème soit lié à la base de données backend, à la restauration de la base de données (ou au rake).

Dès que je désactive le proxy inverse et que j’exécute deux conteneurs sans celui-ci, le problème disparaît. Comme la base de données est la même dans tous les cas, il est peu probable qu’il s’agisse d’un problème de base de données.

Je serai hors ligne pendant 12 heures, donc je reviendrai plus tard voir ce qui s’est passé sur votre configuration @ariznaf

5

Effectuez-vous du HTTPS en dehors du conteneur ?

Avez-vous inspecté le code source de la page pour voir quelles URL sont utilisées pour les avatars ?

Il semble que force_https ne soit pas activé.

6

Je ne peux pas le faire pour le moment, car je dois tout recommencer à zéro.

J’ai essayé de copier tous les fichiers (avec Discourse arrêté à l’origine), mais cela n’a pas fonctionné non plus (problèmes avec la base de données).

Je vais essayer de recommencer, installer une instance Discourse propre, puis restaurer la sauvegarde effectuée avec Discourse.

7

Je vais vérifier, merci.

Tenter de restaurer des bases de données ou de migrer d’un hôte à un autre s’avère plus difficile que prévu.

Merci à vous deux.

8

À condition que vous n’utilisiez pas de proxy inverse et que la plateforme de destination soit représentative et correctement configurée, c’est généralement extrêmement simple.

9

Sauf si, entre-temps, une mise à niveau a été effectuée sur Discourse lui-même ou sur les plugins que vous utilisez (je n’utilise que quelques plugins officiels, des aperçus de liste de sujets et quelques composants), chaque fois que j’ai essayé de simuler une restauration, il y avait un problème d’un certain type.

Je trouve que le système de sauvegarde est simple et direct, mais pas assez robuste lorsqu’il faut tout transférer vers un autre serveur.
Et il n’est pas assez flexible.

Cela prend également trop de temps pour se terminer (pour un site pas si grand, la sauvegarde complète fait juste 3 Go).

Notre ancien forum contenait plus de 100 Go de données ; il serait impossible de sauvegarder un forum aussi volumineux avec le système actuel.

10

Les différentes versions redimensionnées des avatars ne sont pas incluses dans la sauvegarde, seules les versions originales le sont. Il faudra un certain temps au travail planifié pour parcourir l’ensemble et générer les versions redimensionnées de chaque avatar.

11

AH, OK.
Merci beaucoup.
Je ne savais pas qu’ils étaient reconstruits en arrière-plan.
C’est donc une question d’attente.

Je m’énervais en utilisant rake posts:rebuild et des choses comme ça.

Vous m’avez évité beaucoup de tracas. Merci beaucoup.

12

Vous pouvez accélérer le processus en accédant à /sidekiq/scheduled sur votre forum et en cliquant sur le bouton « Déclencher » à côté de la tâche CreateMissingAvatars.

13

Wow, il y a tout un monde caché là-dedans dans /sidekiq :slight_smile:

J’ai essayé ce que vous avez suggéré.

Mais le job CreateMissingAvatars est planifié et s’exécute, mais il se termine presque immédiatement, il ne faut que quelques millisecondes pour le terminer. J’ai essayé de l’exécuter manuellement (en utilisant Trigger), mais il se termine à nouveau immédiatement avec un résultat OK.

Mais les avatars sont toujours incorrects.
J’utilisais maintenant ma configuration d’origine, avec Discourse écoutant sur un socket et nginx comme proxy inverse.

Je vais maintenant essayer de supprimer nginx et d’exécuter Discourse sur les ports 80 et 443.

14

Salut @ariznaf,

Je me suis réveillé ce matin après être resté hors ligne pendant 12 heures, et j’ai basculé vers notre configuration socket-only.yml. Tout est de nouveau normal.

Donc, au moins de mon côté de l’immense univers Discourse, tout va bien à nouveau dans le monde des « deux conteneurs avec nginx en proxy inverse vers un socket Unix ».

Nous avions basculé vers la configuration frontend nginx environ six heures avant que l’anomalie ne soit remarquée, et tout fonctionnait parfaitement.

Grâce à ce conseil utile de @riking (comme toujours, merci beaucoup, Kane) :

Les différentes versions redimensionnées des avatars ne sont pas incluses dans une sauvegarde, seuls les originaux le sont. Il faudra un certain temps au travail planifié pour parcourir les données et générer les versions redimensionnées de chaque avatar.

Screen Shot 2020-04-17 at 9.06.09 AM

Ma meilleure hypothèse est que, lorsque nous avons effectué le passage à nginx, nous n’avons remarqué aucun problème car les nombreuses images d’avatar étaient déjà mises en cache et le processus de régénération n’était pas encore terminé. Ainsi, au fil du temps, le cache de ces images a expiré et l’anomalie a commencé à apparaître.

Alors, je suis resté hors ligne pendant 12 heures (le conteneur socket-only.yml était toujours en cours d’exécution en arrière-plan, mais inactif), je me suis réveillé le matin, et sidekiq avait accompli sa magie pendant la nuit (ici), comme l’a fait @riking (un excellent support, soit dit en passant, Kane, sur chaque sujet ici sur Meta).

Ce scénario semble confirmer ce que @riking a suggéré.

Honnêtement, plus nous utilisons Discourse, plus nous l’apprécions. Les accrocs et anomalies sont très intéressants, et la configuration à deux conteneurs est vraiment excellente.

Nos conteneurs ressemblent actuellement à ceci :

# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml

Ce que j’aime dans cette configuration, c’est que même lorsque nous rencontrons un problème, par exemple cette anomalie de régénération des avatars, nous pouvons facilement basculer entre socket-only.yml et web-only.yml.

Dans ce cas, nous sommes revenus à web-only (pendant cette régénération), puis nous avons basculé à nouveau une fois le processus terminé (car tous les conteneurs sont toujours en cours d’exécution). Lorsque nous effectuons une reconstruction du conteneur, nous pouvons simplement basculer entre ces conteneurs et configurations très facilement.

Après deux décennies d’exploitation d’un forum LAMP, nous sommes de plus en plus impressionnés par Discourse, du côté de l’administration système.

Sidebar (Éditorial) :

Bien sûr, cela dépasse largement mon niveau de compétence ici sur Meta, mais je pense que la configuration de base à deux conteneurs (sans proxy inverse) devrait être la valeur par défaut, car elle est très facile à configurer et nous en tirons bien plus d’avantages que toute « pénalité » perçue liée à l’existence de deux fichiers yml.

15

De mon côté, j’ai essayé de procéder à la restauration en utilisant uniquement la sauvegarde effectuée via l’interface.

Comme mentionné, nous avons perdu les images d’avatars et quelques autres éléments mineurs.

J’ai tenté de suivre les conseils donnés par @riking, mais sans succès.

J’ai essayé de rafraîchir les images d’avatars en forçant l’exécution du processus. Cependant, celui-ci s’est terminé avec un statut OK après quelques millisecondes, et les avatars n’ont pas été générés.

Comme nous étions pressés de migrer le contenu, j’ai arrêté le forum sur l’ancien serveur, copié tout le contenu des conteneurs et des répertoires partagés en utilisant tar, puis installé Discourse sur le nouveau serveur (sans effectuer de configuration initiale). J’y ai ensuite copié les répertoires partagés et des conteneurs, puis reconstruit l’application.

Maintenant, tout fonctionne sur le nouveau serveur.

La restauration à partir d’une sauvegarde s’avère plus problématique que prévu (alors que cela semblait simple, étant donné les instructions indiquant qu’il suffit de réinstaller et de restaurer via l’interface).

Je dois investiguer ce qui se passe mal lors de la restauration et m’assurer que le système démarrera correctement même si nous restaurons à partir d’une ancienne sauvegarde alors que Discourse a plusieurs versions d’avance par rapport à celle utilisée lors de la sauvegarde.

J’aime beaucoup Discourse.
En venant d’autres forums traditionnels, il arrive parfois qu’il soit difficile de trouver ce que l’on cherche.
L’interface épurée n’aide pas dans ces cas-là.

Mais une fois que vous avez trouvé ce que vous cherchez, tout est bien placé et les choses fonctionnent de manière intelligente.

Nous rencontrons des problèmes uniquement lors de la restauration à partir d’une sauvegarde.
Et parfois, avec l’utilisation intensive de la mise en cache.

Discourse met un certain temps à se charger la première fois dans votre navigateur web, mais ensuite il vole, car la plupart du traitement est effectué sur votre propre machine et il utilise beaucoup de mise en cache (avatars, images, CSS, etc.).
L’application ne récupère pas les informations déjà présentes sur votre ordinateur, ce qui économise beaucoup de travail sur le serveur (du moins, c’est ce que cela semble faire, d’après mon expérience).

Lorsque j’essaie de passer d’un serveur à un autre, ou de réinstaller Discourse à partir de zéro, vous continuez à voir l’ancien contenu même si vous rafraîchissez la vue.

Je n’ai pas pu m’en débarrasser avant de vider l’historique de navigation du navigateur web.
Cela m’a occupé et confondu pendant un certain temps.

AU PASSAGE, ces images d’avatars sont-elles sauvegardées si vous sélectionnez les miniatures sauvegardées dans la sauvegarde ?
Pensez-vous qu’il vaudrait mieux les sauvegarder ?
Notre forum n’est pas trop grand, mais sauvegarder 36 000 images a pris pas mal de temps.

16

Bonjour @ariznaf,

Notre sauvegarde complète a la même taille, environ 3 Go entièrement compressés en gzip.

Jusqu’à présent, je n’ai rencontré aucun des problèmes que vous avez mentionnés dans votre message (ci-dessus, #13).

Restaurez-vous à partir de la ligne de commande ou depuis l’interface utilisateur ?

Nous ne restaurons qu’à partir de la ligne de commande dans un conteneur. Je suppose que c’est la même chose pour vous ?

C’est une bonne nouvelle. Félicitations.

17

Merci de votre intérêt.

J’ai suivi les instructions des tutoriels en utilisant l’interface. Je ne sais pas comment restaurer depuis la ligne de commande (les sauvegardes étant prises via l’interface Discourse).

Laissez-moi m’expliquer :

J’ai dû déplacer le serveur de a.domain.com vers b.domain.com.
Le forum Discourse est accessible via HTTPS avec un certificat SSL personnalisé (nous utilisons des certificats SSL pour tout le domaine).
Discourse est installé via un socket avec le nom d’hôte a.domain.com.
Nous avons configuré nginx comme proxy inverse pour rediriger définitivement le trafic HTTP (port 80) vers HTTPS (port 443), et HTTPS (port 443) agit comme proxy inverse pour le trafic HTTPS, le redirigeant vers le socket où Discourse écoute.

J’avais une sauvegarde (via l’interface) de a.domain.com dans un bucket S3, contenant la base de données et les fichiers téléchargés, mais pas les vignettes (environ 3 Go).

J’ai installé nginx et copié le fichier de configuration de a.domain.com en modifiant le nom d’hôte de a.domain.com à b.domain.com.

J’ai installé Discourse en clonant depuis GitHub (comme conseillé dans le tutoriel d’installation en 30 minutes).
Ensuite, j’ai exécuté la configuration de Discourse (avec nginx arrêté) et l’ai configuré avec le nom d’hôte b.domain.com.

J’ai accédé à la nouvelle installation sur b.domain.com en me connectant en tant qu’administrateur.
Via l’interface, j’ai configuré les sauvegardes pour accéder au bucket S3, activé les capacités de restauration administrateur, et restauré la dernière sauvegarde.

Ensuite, vous êtes déconnecté de Discourse, car il y a de nouveaux utilisateurs, une nouvelle configuration, etc.

De retour sur la ligne de commande, j’ai édité le fichier app.yml et copié la configuration du serveur d’origine (a.domain.com) en modifiant uniquement le nom d’hôte en b.domain.com.

Ensuite, j’ai exécuté ./launcher rebuild all, et une fois terminé, j’ai redémarré nginx.

J’ai accès au forum Discourse, mais les avatars sont perdus et il y a d’autres problèmes avec les vignettes d’images.

18

Merci pour ces détails si complets, @ariznaf.

Honnêtement, je ne suis pas un grand fan des services de stockage cloud comme S3. Il vaut donc mieux, je pense, que j’écarte toute autre idée, puisque nous ne sommes pas des « utilisateurs de S3 »…

19

Vous dites que les avatars sont perdus, mais avez-vous inspecté le code source de la page pour voir d’où ils sont demandés ?

Sont-ils toujours sur S3 ?

Pourquoi avez-vous dû changer les sous-domaines ?

Pour être clair, vous avez changé à la fois le serveur physique et l’adresse DNS ?

20

Riking indique que le système doit reconstruire les miniatures. Cependant, la tâche semblait être terminée.

Je vais réessayer. Pour l’instant, j’ai résolu le problème d’une autre manière.

Dans S3, seul le bacuos est sauvegardé ; les images et les uploads sont stockés localement.

Mais je dois effectuer des tests de restauration pour identifier le problème.
Je vais vérifier d’où le système tente de récupérer l’image.

Cependant, une image avec une silhouette blanche s’est affichée, ce qui signifie qu’il ne s’agit pas d’un lien brisé. Le système l’a probablement modifiée car la miniature n’existe pas.