Actuellement, lorsque nous effectuons n’importe quel type de maintenance (autre qu’une simple mise à jour) et que nous souhaitons mettre le site hors ligne ou le passer en mode lecture seule, il n’existe aucun moyen d’informer les visiteurs de ce qui se passe ou d’estimer la durée d’inaccessibilité du système.
Il serait souhaitable d’avoir un mode hors ligne complet permettant à l’administration de fournir des mises à jour de statut et des messages aux visiteurs entrants pendant cette période d’indisponibilité, afin de gérer les attentes et de rassurer les visiteurs plutôt que de les laisser se demander ce qui se passe.
Pour la postérité, voici le commentaire original qui a donné lieu à cette séparation, tel que mentionné par @jomaxro :
Ce qui doit vraiment être fait ici, c’est un mode hors ligne / maintenance intégré qui intègre cette méthodologie ainsi que la possibilité de fournir des messages personnalisés aux utilisateurs pendant que le système est en mode hors ligne et/ou maintenance.
Cela pourrait être intégré au gestionnaire de mise à jour (renommer le gestionnaire de mise à jour en « Gestionnaire système Discourse » et regrouper les mises à jour, les journaux, les processus et les sauvegardes dans cette section).
Cela rendrait le système moins fragile, plus convivial et plus utile à la fois pour les administrateurs et les utilisateurs.
Docker Manager, le plugin officiel que nous prenons en charge pour les mises à jour, ne provoque aucune interruption de service. Il ne devrait pas être nécessaire de modifier le plugin, car il prend déjà en charge les mises à jour sans interruption. Le problème abordé dans ce howto concerne les mises à jour (reconstructions) effectuées depuis la ligne de commande. Elles ne sont nécessaires que rarement, quelques fois par an, lorsque nous devons mettre à jour une dépendance sous-jacente, comme la version de Ruby ou Postgres.
Il n’est pas possible de faire en sorte que Docker Manager gère de telles mises à jour, car Docker Manager, comme l’ensemble de Discourse, est arrêté pendant une reconstruction. Toute solution doit se situer en dehors de Discourse, comme la solution de proxy Nginx fournie dans ce sujet.
Hmm, je pense qu’il existe d’autres options ici qui seraient plus cohérentes avec la nature de Discourse… Au lieu de rejeter ce concept, discutons plutôt de moyens d’améliorer l’expérience globale à cet égard, surtout si un administrateur doit, pour une raison ou une autre, mettre le site hors ligne pour maintenance.
Une idée qui me vient à l’esprit : pourquoi ne pas intégrer la solution de proxy Nginx mentionnée par l’auteur du sujet initial dans la configuration Docker ? Cela rendrait le tout plus prévisible, gérable et cohérent à la fois pour les utilisateurs et les administrateurs de Discourse, ainsi que pour le support (des personnes comme vous ici sur le forum), plutôt que de devoir gérer des solutions découplées comme celle proposée ici ?
Je ne compte pas rejeter ce concept, je constate simplement que l’utilisation d’un plugin Discourse pour résoudre ce problème ne fonctionnera pas. Laissez-moi déplacer cette discussion vers un topic #feature dédié pour une discussion appropriée.
@mreach, veuillez modifier le message original (OP) pour détailler ce que vous recherchez et comment vous souhaitez que cela fonctionne. N’hésitez pas à modifier le titre si nécessaire.
Si vous souhaitez minimiser les interruptions lors de ./launcher rebuild app, vous aurez besoin d’une configuration multi-conteneurs.
Ceci est déjà documenté. Il s’agit d’une configuration plus complexe.
Pour que launcher rebuild en mode conteneur unique affiche une page « hors ligne », il faudrait remplacer le conteneur par un conteneur dédié spécial indiquant que le site est hors ligne. Ce n’est pas impossible, mais cela nécessiterait environ deux semaines de développement pour que cela fonctionne parfaitement. Je ne pense pas que nous puissions nous permettre de financer cela pour le moment, étant donné la rareté des reconstructions de conteneurs et le fait que nous disposons déjà d’une méthode documentée pour effectuer des reconstructions sans interruption.
Je suis d’accord avec Sam : si vous avez les moyens de créer une page du type « le site est hors ligne », vous feriez mieux de consacrer votre temps à faire en sorte que le site ne soit tout simplement pas hors ligne. Mais peut-être que vous souhaitez consulter Add an offline page to display when Discourse is rebuilding or starting up.
L’installation en deux conteneurs permet des mises à jour avec un temps d’arrêt minimal dans la plupart des cas. Parfois, la création du nouveau conteneur déclenche une migration qui fait planter le site en cours d’exécution. Il existe une solution, mais elle est assez complexe et ces mises à jour sont assez rares.
Vous pourriez également rediriger votre DNS (ou utiliser une adresse IP élastique, ou ce que Digital Ocean appelle cela) et lancer une instance (ou ce que AWS appelle cela) avec un serveur web contenant votre message de statut.
Au fait @jomaxro, comment as-tu détaché mon message pour le déplacer dans ce nouveau sujet ? Quelles étapes as-tu suivies ? Ce serait plutôt pratique et utile de le savoir… Je ne vois aucune méthode pour cela dans Discourse par défaut.