Je suis sur le point de mettre à niveau notre serveur Discourse de production (nous l’hébergeons nous-mêmes sur EC2 conformément aux instructions d’installation officielles) et je souhaitais confirmer la méthode recommandée.
Nous n’avons pas activé le bouton de mise à niveau dans l’interface utilisateur, la mise à niveau sera donc effectuée sur l’instance EC2. À ma connaissance, il existe deux méthodes principales pour cela :
Reconstruire notre serveur EC2, ce qui récupérera une copie fraîche du dépôt GitHub discourse_docker et utilisera les modèles qui s’y trouvent, c’est-à-dire que web.template.yml référence actuellement l’image de base discourse/base:2.0.20260209-1300. Cette approche supprimera le serveur en cours d’exécution et démarrera le nouveau.
Se connecter au serveur EC2 existant et exécuter les commandes suivantes pour reconstruire l’image actuelle et redémarrer le conteneur :
./launcher rebuild app
J’ai deux questions :
Quelle approche devrait être utilisée pour la maintenance normale ?
Si nous exécutons la commande rebuild app, cela récupère-t-il toujours la branche main du dépôt discourse_docker ?
J’ai consulté le site https://releases.discourse.org et je constate que la version 2026.3.0 n’est pas encore publiée. Ma compréhension est que nous ne devrions pas utiliser la dernière version de la branche main d’une release en production, car elles sont encore en développement actif.
Si vous souhaitez passer à la dernière version, une mise à jour manuelle via le panneau d’administration suffit.
Si vous souhaitez passer à la version esr, il vous suffit de spécifier esr à la fin du fichier containers/app.yml :
params:
version: esr
Ensuite, reconstruisez simplement l’application.
Assurez-vous que votre connexion réseau fonctionne correctement.
Ainsi, en définissant la version comme esr, cela remplace-t-il l’image de base utilisée dans les modèles ?
Nous ne souhaitons pas que la mise à niveau soit activée dans l’interface d’administration, nous aurons donc besoin d’un moyen de le faire au niveau de l’instance ou simplement en reconstruisant l’instance et en laissant notre AutoScaler la gérer.
Si nous utilisons esr, comment celle-ci est-elle mise à jour lorsqu’une correction critique est déployée ? Encore une fois, devons-nous simplement reconstruire via le lanceur ou une nouvelle instance EC2 sur une base mensuelle pour intégrer toutes les mises à jour de la version esr ?
Avez-vous lu Understanding Discourse release channels et Configure a supported tracking branch to get Discourse software updates ? Je décrirais la différence davantage comme ayant accès aux dernières modifications immédiatement, ou les recevoir un peu plus tard. Ce dernier cas peut être très utile pour les développements personnalisés qui doivent d’abord être adaptés. Sinon, je préférerais avoir accès aux dernières fonctionnalités et corrections. Bien sûr, cela comporte un risque de nouveaux bugs, mais la version figée il y a trois semaines contient également des bugs qui ont peut-être déjà été corrigés dans la version la plus récente, mais généralement pas suffisamment graves pour justifier un backport vers la dernière version.
Gardez également à l’esprit que le downgrade n’est pas pris en charge ; si vous utilisez une version postérieure à l’ESR actuelle, vous devez attendre la publication de la prochaine ESR.