Bonjour, est-il normal que le site soit hors ligne lors de l’installation/mise à jour de thèmes et de plugins ?
1 « J'aime »
Il est normal que le site soit hors ligne lors d’une reconstruction.
Les solutions consistent à utiliser une installation à deux conteneurs, qui vous permet de construire un nouveau conteneur, de sorte que le temps d’arrêt est inférieur à une minute, ou à faire en sorte qu’une page « nous revenons tout de suite » s’affiche pendant que le site est hors ligne, ce qui ne change pas le temps d’arrêt, mais tout le monde sait alors que vous êtes conscient que votre site est hors ligne.
Tout le monde pense qu’au moins une de ces solutions est trop difficile et ne vaut absolument pas la peine.
4 « J'aime »
Pour ajouter, contrairement aux plugins, l’installation ou la mise à jour de thèmes et de composants de thèmes ne nécessiterait aucun temps d’arrêt. 
4 « J'aime »
Existe-t-il une documentation sur la méthode que vous avez mentionnée ? De plus, cela semble ironique étant donné qu’elle est très adaptée au référencement en termes de discours, mais qu’il y a une interruption lors du chargement et que les robots Google ne peuvent pas explorer le site.
Combien de fois prévoyez-vous d’installer un nouveau plugin ? C’est généralement un événement très rare.
Vous pouvez mettre à jour les plugins en ligne avec une interruption minime du service, car les conteneurs basculent.
2 « J'aime »
Merci pour vos réponses. 
1 « J'aime »
Jetez un coup d’œil à Add an offline page to display when Discourse is rebuilding or starting up quand vous vous sentez courageux.
2 « J'aime »
Bonjour 
Je ne suis pas sûr et peut-être que je me trompe (je n’ai pas encore essayé) mais est-ce que c’est maintenant une fonctionnalité principale ? Il y a un nouveau modèle il y a quelques mois dans discourse/templates appelé offline-page.template.yml et à l’intérieur il déclenche le GitHub - discourse/discourse-offline-page: offline page for discourse. Qui est le site HTML statique pendant le chargement de Discourse. Il y a aussi une PR à ce sujet dans discourse_docker FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
3 « J'aime »
Cela ne toucherait qu’une partie, non ? Cela s’afficherait au démarrage, mais pas lors de la reconstruction, si je comprends bien les reconstructions :
Ajouter un modèle pour récupérer et servir des fichiers HTML statiques depuis GitHub - discourse/discourse-offline-page: offline page for discourse lorsque nginx est disponible, mais pas rails.
^ Le PR github
2 « J'aime »
Mais un pas dans la bonne direction, merci @Don (et @featheredtoast ! )
Oui @Firepup650 Je me demandais pourquoi je ne l’avais pas vu, et je crois que tu as répondu pourquoi !
Il y a de bons 
ici ! 
Je me demande si c’est une étape préalable à une configuration permanente standard à deux conteneurs, où un conteneur nginx est construit séparément ?!??! 
2 « J'aime »
Vous m’avez attrapé - il y a des efforts en cours pour rendre la diffusion de pages hors ligne plus largement possible - les commits et les dépôts mentionnés sont les bases pour qu’elle soit disponible, mais elle n’est pas (encore) en place maintenant.
5 « J'aime »
Pour une raison quelconque, aucun de mes utilisateurs ne voit cela en cours de reconstruction. Eh bien, dans le chat en tout cas, et c’est pourquoi il y a eu des incidents où un utilisateur a perdu juste un message écrit.
Mon opinion est que la situation où nous n’informons pas du tout des temps d’arrêt pour les utilisateurs déjà connectés est le plus grand problème d’UX unique dans Discourse. Bien sûr, je peux comprendre les explications d’où cela vient de la nature même de cette application, et les développeurs se sont un peu peints dans un coin dès le début (situations similaires à celles des brouillons et de quelques autres choses), mais cela n’efface pas le problème lui-même.
Nous avons quelques solutions de contournement. Utiliser Nginx comme proxy inverse devant Discourse affichant une page d’erreur personnalisée en est une. Et quand un administrateur a des problèmes, la réponse sera “nous ne prenons en charge que celui par défaut”. C’est la raison réelle pour laquelle j’ai abandonné celle-ci.
Deux conteneurs différents est une solution. Ou du moins, cela maintient le temps d’arrêt très court. Il y a trop d’avertissements à ce sujet, donc j’ai un peu peur de prendre cette voie.
Ou nous pouvons mettre à niveau seulement parfois, informer les utilisateurs avant que cela ne se produise et arrêter l’accès public. Oui, c’est une solution, mais… nous sommes en 2024 et seul le système bancaire l’utilise dans mon environnement 
Utiliser un serveur de staging est quelque chose qu’il faudrait faire. Eh bien, c’est une solution de niveau entreprise, coûteuse et assez difficile à réaliser correctement, et qui aime sa propre équipe informatique.
Donc, les nouveaux plans divulgués 
sont une réelle amélioration en effet. Eh bien, s’il faut des conteneurs séparés, alors il est temps de plonger dans le grand bain, je suppose.
1 « J'aime »
C’est exactement la même chose, sauf que parfois il faut aussi reconstruire le conteneur de données.
1 « J'aime »
Mais le temps d’arrêt est beaucoup plus court que 20 minutes, n’est-ce pas ?
1 « J'aime »
Le chat peut contenir des éléments différents de la visualisation normale du site, car je pense qu’il s’agit d’un accès plus en temps réel par rapport à la mise en cache des pages.
D’accord. La maintenance annoncée et planifiée est, à mon avis, la meilleure, comme à l’époque des BBS basés sur DOS accessibles par modem. Il y avait une option pour afficher un message système avertissant que la maintenance planifiée arrivait et déconnecterait les utilisateurs à l’heure désignée. À cette époque, c’était généralement pour échanger des paquets de courrier entre BBS connectés.
1 « J'aime »
Oui. Le temps d’arrêt est généralement inférieur à une minute, mais vous aurez besoin de suffisamment de RAM ou d’espace d’échange pour reconstruire un conteneur pendant que l’autre se construit.
1 « J'aime »