J’ai changé le nom car je ne peux pas arrêter le serveur original pendant plusieurs heures, jusqu’à ce que j’aie vérifié que tout fonctionne correctement et que j’aie échangé les serveurs.
Ce n’est pas nécessaire. Si vous disposez d’un certificat générique (wildcard), vous pouvez simplement effectuer des modifications DNS locales via le fichier Hosts pour tout configurer et restaurer la sauvegarde elle-même.
Ensuite, il vous suffit de basculer le DNS publiquement.
Je ne comprends pas ce que vous voulez dire.
Je dois maintenir a.domain.com en fonctionnement pendant que je réalise les tests.
Et j’ai besoin d’accéder à l’interface Discourse de la copie que je restaure pour vérifier que tout est correct.
Donc, j’ai besoin d’une autre URL pour accéder à cette copie, sur l’autre serveur.
Je modifie simplement le nom d’hôte dans Discourse et Nginx après la restauration.
Lorsque tout est correct, je change le nom sur le nouveau serveur pour a.domain.com, j’arrête l’ancien serveur et je pointe le DNS a.domain.com vers le nouveau serveur.
Ce qui précède n’est pas correct. Vous pouvez forcer votre machine locale à se connecter au nouveau serveur en utilisant le même nom DNS, soit en modifiant le fichier HOSTS sur votre ordinateur local, soit en codant en dur une entrée dans votre DNS local.
Je n’ai pas de machine locale.
Les deux serveurs sont sur Internet, ou des serveurs cloud.
J’utilise ssh depuis une machine Windows.
Peut-être que je peux prendre le nom d’hôte local pour définir l’adresse IP de la machine, mais c’est plus complexe que de changer le nom dans les serveurs.
Pensez-vous qu’un changement de nom d’hôte puisse être le problème ?
Ce ne devrait pas être un problème…
Oui, nous avons commencé à remarquer ce problème d’avatar personnalisé bien après que le processus sidekiq ait eu le temps de reconstruire toutes les images d’avatar et de profil annexes, mais uniquement avec la configuration utilisant un proxy inverse nginx vers un socket Unix.
Les petites icônes d’avatar fonctionnent correctement ; mais elles ne s’affichent pas dans la carte de profil ni sur les pages de profil (sauf si elles étaient mises en cache auparavant et que le cache n’a pas expiré).
Dès que nous exécutons :
nginx -s stop; ./launcher start web-only
Le problème des images d’avatar personnalisées disparaît (pour les images qui n’ont pas encore été consultées / mises en cache dans le navigateur).
Et dès que nous exécutons ensuite :
./launcher stop web-only; nginx
Le problème des images d’avatar personnalisées réapparaît pour les images qui n’ont pas encore été consultées / mises en cache.
Il n’y a aucune erreur avec HTTPS et ce problème n’est absolument pas lié à force_https (sans rapport) :
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Nous avons confirmé ce problème sur mobile (iOS, dernière version), sur ordinateur de bureau, dans Chrome (dernière version), dans Safari (dernière version), etc.
Quelque chose d’étrange se produit lors de l’utilisation de nginx comme proxy inverse vers un socket Unix, ce qui affecte les images d’avatar personnalisées.
Pour l’instant, désolé de vous l’annoncer @ariznaf, nous n’avons pas réussi à isoler le problème et nous n’avons pas encore de solution.
On a l’impression que, dans la configuration proxy inverse nginx vers un socket Unix, l’application Discourse (le conteneur) ne reconstruit pas ces images d’avatar personnalisées comme elle le fait dans la configuration sans nginx en tant que proxy inverse vers un socket Unix.
Peut-être que sidekiq n’apprécie pas la configuration proxy inverse nginx vers un socket Unix et refuse de planifier ou d’exécuter ce processus de reconstruction, LOL ? @riking ?
Étrange.
Voici un suivi :
Dans la configuration du proxy inverse utilisant des sockets Unix dont nous discutons :
Cependant, lorsque nous vérifions force_https :
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
Et bien sûr, comme prévu, il n’y a aucune erreur dans le certificat du navigateur (Chrome est satisfait) :
Donc, mon hypothèse peu éclairée est que cette configuration, le paramètre / la méthode force_http manque ces images ; car tout le reste est parfait, sauf ces avatars personnalisés (et l’image de la page de profil).
Voilà ma hypothèse au-dessus de mon niveau de compétence avec Discourse.
Mise à jour :
Après davantage de recherches, il s’avère que toutes nos configurations de proxy inverse nginx vers socket Unix omettaient une grande partie des fichiers /shared/uploads. Cette étape manquait dans les divers tutoriels et documents howto consultés à ce sujet, donc la prochaine fois que je verrai un wiki sur ce sujet sur Meta, je mettrai à jour le tutoriel / wiki / howto pour inclure cette étape.
La seule petite difficulté restante est un problème avec le favicon :
Si quelqu’un a une méthode recommandée pour résoudre cela, ce serait formidable. Merci !
Re-téléchargez-le. C’est la solution la plus rapide.
Les gens oublient souvent, lorsqu’ils utilisent un socket, qu’ils ont désactivé le modèle HTTPS, de sorte que Discourse ne sait pas qu’il est derrière SSL sauf si force_https est activé manuellement, d’où ma suggestion d’hier.
Une fois force_https activé, vous pouvez re-télécharger les assets pour corriger leurs chemins.
Je n’ai répondu à rien de tout cela parce que je supposais qu’une erreur lors du transfert de données du serveur (sans utiliser la fonctionnalité de sauvegarde intégrée) avait omis entièrement le répertoire /uploads/, et je ne savais pas comment l’expliquer d’une manière que vous pourriez comprendre.
Oui… nous avons suivi ce guide pour configurer le proxy inverse nginx, mais cela concernait une configuration autonome et ne mentionnait pas les uploads car cela n’était pas nécessaire à transférer en mode autonome :
Et nous avons suivi ce guide pour deux conteneurs, qui ne mentionnait également aucune restauration de base de données ni transfert de répertoire d’uploads :
Je pense que nous pouvons facilement comprendre les choses. Voici l’indice qui vous manquait pour vous aider à expliquer, à titre de référence :
Les principaux tutoriels sur cette configuration omettent le fait que vous devez soit effectuer une restauration de la base de données, soit transférer manuellement vos uploads vers le nouveau conteneur, car nous n’avons pas inclus cela.
Bien sûr, cela a du sens maintenant après avoir résolu cela à 100 % par nos propres moyens (encore une fois !), car ce n’est pas dans les tutoriels. LOL
Tout est facile une fois que vous savez quel est le problème.
PS : Pour conclure. Merci à tous ceux qui ont écrit divers tutoriels. Ils ont été d’une grande aide ! Très apprécié. De notre côté, cette configuration est terminée et nous n’utiliserons plus aucune configuration autonome sur aucun site Discourse à l’avenir. Notre « défaut » normal sera deux conteneurs avec un proxy inverse vers un socket Unix. Cela fonctionne le mieux pour effectuer des mises à jour et basculer entre les conteneurs en temps réel avec presque aucun temps d’arrêt. Super !
Discourse est GÉNIAL !!
Bien joué Jeff @codinghorror et Sam @sam ! BRAVO !
C’est assez facile à faire fonctionner, mais comme je l’ai mentionné plus tôt, nous n’utilisons pas S3 ni d’autres services de stockage cloud ; et nous préférons garder les choses « simples », donc nos sauvegardes sont simplement rsyncées vers un stockage hors site. Nous préférons cette façon de faire… c’est une chose de moins à déboguer et nous pouvons « vivre » sans S3,
Je ne sais pas si cela est utile ou non. Mais l’optimisation des images a tendance à échouer si le processus d’exécution de l’optimisation ne peut pas atteindre votre serveur via son nom de domaine Internet.
Cela pourrait expliquer pourquoi cela ne fonctionne pas comme prévu dans une configuration de proxy inverse plus complexe.
Merci, Kane.
J’essayais (comme vous le savez probablement) d’autres alternatives à la méthode de sauvegarde standard via l’interface utilisateur de Discourse. Je faisais ces essais car j’ai rencontré des problèmes à chaque tentative de restauration via la méthode de sauvegarde standard, en suivant toujours les instructions données dans les tutoriels officiels de ce site.
Quoi qu’il en soit, j’ai précisé dès le début que je procédais à cette restauration à partir d’une sauvegarde effectuée via l’interface utilisateur, en suivant la procédure de sauvegarde standard et la procédure de restauration recommandée.
La seule différence par rapport à une installation standard de Discourse autonome est que nous utilisons nginx comme proxy inverse, connecté à Discourse via un socket.
Le principal problème que nous avons rencontré concernait les avatars, qui semblaient perdus et remplacés par l’avatar par défaut.
Vous m’avez dit qu’il fallait les reconstruire via le job Sidekiq. Cependant, ce job semble se terminer immédiatement avec succès (statut OK) lorsque vous le lancez, mais les avatars restent inchangés.
Comme les sauvegardes sont très importantes pour nous (qui pourrait les ignorer ?), je vais effectuer davantage de tests, en faisant très attention à suivre les consignes et en essayant d’autres idées proposées ici.
Nous sommes satisfaits de Discourse, nous l’apprécions beaucoup. Nous cherchons simplement à être sûrs d’avoir une procédure de restauration robuste, au cas où nous subirions une attaque (nous en avons récemment subi une) ou une panne de serveur.
Si vous souhaitez que nous effectuions des tests pour tenter de résoudre ce problème ou fournir des informations, je serai heureux de faire de mon mieux et de vous transmettre ces informations.
Il semble que le système ne puisse pas accéder aux miniatures des avatars, c’est certain.
Cependant, le reste du forum est servi correctement : les routes, SSL et tout le reste sont correctement configurés, du moins à ce que je vois.
S’il y avait une sorte de mauvaise configuration, vous ne pourriez pas accéder au forum Discourse et voir le reste du contenu ; vous obtiendriez des erreurs 502 ou quelque chose de similaire.
@neounix
Nous utilisons S3 car c’est la méthode la plus simple via l’interface utilisateur pour avoir les sauvegardes hors site.
Peut-être que S3 n’est pas la meilleure option, je ne sais pas. Sinon, l’endroit où vous sauvegardez les données n’est pas lié au problème, car il ne s’agit pas d’une incapacité à les atteindre et à effectuer la restauration.
La restauration s’effectue correctement.
@stephan
Dans app.yml, j’ai commenté le modèle SSL et le modèle Let’s Encrypt, ainsi que la section expose avec les ports.
La partie SSL est gérée par nginx, donc je n’ai pas besoin que le socket soit chiffré, n’est-ce pas ?
Est-ce incorrect ? Devrais-je utiliser le modèle SSL quand même ?
Je suppose que si c’était le problème, je ne pourrais voir aucune partie du forum après la restauration, pas seulement les avatars, mais qui sait…
Je vais effectuer plus de tests. Merci à tous pour votre aide.
@ariznaf … salut !
La façon dont j’ai résolu ce problème sur deux serveurs différents était de copier manuellement le répertoire /shared/uploads de la configuration originale vers les configurations socket-only, et après cela, ce problème a disparu.
La façon dont j’ai pu vérifier rapidement était de comparer les tailles du répertoire uploads, simplement comme ceci (en supposant que vous soyez dans votre répertoire partagé) :
du -sh uploads
Lorsque je les ai comparés, c’est à ce moment-là que j’ai découvert ce qui clochait
Peut-être pouvez-vous vérifier également ? J’espère que cela vous aidera à isoler votre problème.
PS : Je ne suis pas négatif envers S3. Chacun son goût, comme on dit…
Laissez-moi voir si j’ai bien compris.
Lorsque je fais les sauvegardes, j’ai vérifié que les uploads sont également sauvegardés (pas les miniatures, mais j’ai testé en sauvegardant aussi les miniatures ; maintenant, je sauvegarde les miniatures, donc vous n’aurez pas à attendre une régénération).
Après la restauration, les uploads sont également restaurés.
Voulez-vous dire que la restauration des uploads n’est pas correcte et que vous devez le faire manuellement ?
Comment restaurez-vous les uploads à la main ?
Avez-vous téléchargé la sauvegarde et décompressé shared/standalone/uploads ?
Si c’est le cas (je vais essayer), il me semble clair qu’il y a un bug dans le processus de restauration.
Merci.
Je cherche des alternatives pour faire des sauvegardes et les stocker, mais les personnes de Discourse insistent pour dire que la seule méthode correcte est d’utiliser la sauvegarde standard.
Bonjour @ariznaf,
Nous ne restaurons pas via l’interface d’administration (nous ne faisons que des sauvegardes depuis l’interface web, pas de restauration). Nous transférons le fichier dans le conteneur via sftp (avec les fichiers joints inclus) et nous restaurons de cette manière :
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
Cependant, lorsque j’ai configuré un proxy inverse nginx vers socket Unix l’autre jour, je n’ai pas restauré depuis la base de données car celle-ci était déjà présente dans le conteneur data (comme mentionné dans les sujets de tutoriel).
C’est pourquoi j’ai dû copier manuellement les fichiers joints vers le nouveau conteneur.
Votre situation semble différente de la nôtre.
J’espère que cela vous sera utile.
Merci.
Il semble que vous effectuiez via la ligne de commande la même procédure que nous réalisons via l’interface : activer les restaurations et restaurer à partir des fichiers tgz contenant la base de données et les fichiers uploadés.
Mais ensuite, vous indiquez que pour faire fonctionner les avatars (en utilisant des sockets et un proxy inverse nginx), vous avez besoin d’une deuxième restauration contenant uniquement les fichiers uploadés, est-ce exact ?
Salut @ariznaf… pas tout à fait…
Au début, nous avions une application autonome. J’ai séparé cette application en deux conteneurs différents (données et uniquement web), puis j’ai effectué une restauration à partir du gros fichier de sauvegarde contenant les uploads.
Tout s’est bien passé…
Ensuite, j’ai créé un nouveau conteneur, socket-only, et je l’ai configuré pour utiliser un proxy inverse.
Je n’ai PAS effectué de restauration dans le nouveau conteneur socket-only (car le conteneur de données contenait déjà les données de la base de données intactes), mais j’ai oublié de copier manuellement les uploads (c’était mon erreur). Si j’avais suivi le processus de restauration normal, cela n’aurait pas été nécessaire.
Mais il n’y a aucune raison de procéder à une restauration manuelle de la base de données dans le nouveau conteneur, car c’est précisément pour cela que les données sont dans leur propre petit conteneur. Donc, dans cette situation, les uploads doivent être copiés vers le nouveau conteneur. C’est en fait très bien conçu.
Est-ce que cela vous aide ?
Ce n’est pas ce que j’ai dit. J’ai dit que le backend ne peut pas atteindre lui-même via le front nginx. Ce que vous dites, c’est l’inverse.
Pour optimiser un téléchargement, le travail Sidekiq le récupère via http(s).
Non, vous pouvez désactiver le modèle SSL, mais vous devrez activer manuellement force_https.