J’aimerais ouvrir une discussion sur les meilleures pratiques pour effectuer les tâches de maintenance essentielles sur une instance Discourse tout en minimisant ou en éliminant les temps d’arrêt.
Les tâches telles que la modification des paramètres de ressources critiques (par exemple, UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) ou l’application de mises à jour majeures nécessitent généralement un launcher rebuild app qui peut prendre un temps considérable, parfois 30 minutes ou plus.
Ma question est : Quelles sont les stratégies recommandées pour les administrateurs système afin d’effectuer ces mises à jour essentielles et ces changements de configuration avec le moins de temps d’arrêt pour les utilisateurs ?
Existe-t-il des techniques avancées, telles que les déploiements bleus/verts ou d’autres stratégies de déploiement sans temps d’arrêt, qui sont prises en charge ou recommandées pour Discourse ? Ou le processus standard de rebuild est-il la seule méthode prise en charge, et l’accent doit-il être mis sur l’optimisation du temps de reconstruction lui-même ?
Je suis intéressé par les retours d’expérience de toute personne ayant géré des instances de grande taille ou à fort trafic et par leur flux de travail pour la maintenance.
Si vous avez une installation à deux conteneurs, le nouveau conteneur se construit pendant que l’ancien s’exécute. Le temps d’arrêt correspond juste au temps nécessaire pour lancer le nouveau conteneur. Le seul problème est que vous avez besoin de suffisamment de RAM pour construire un conteneur pendant que l’autre s’exécute.
Si vous souhaitez un temps d’arrêt nul, vous avez besoin d’un équilibreur de charge qui maintient l’ancien conteneur en cours d’exécution jusqu’à ce que le nouveau ait complètement démarré. Ensuite, vous arrêtez l’ancien conteneur et effectuez les migrations post-mise à jour.
Discourse est tellement stable que c’est plutôt inutile pour la plupart des installations (mais je suppose que vous pourriez l’envisager pour des exigences de très haute disponibilité ou si vous hébergez d’autres personnes ?!)
Je ne pense pas avoir eu une seule interruption en 7 ans due à un « bug » de production…
Les moments les plus risqués dans la vie d’un Discourse sont toujours lors de la reconstruction.
La configuration à deux conteneurs vous donne la possibilité de démarrer une nouvelle construction avant de vous y engager, bien que cela ne détecte pas certaines erreurs d’exécution, bien sûr.
Le problème est que si vos migrations ont été exécutées, vous pourriez devoir vous engager dans la nouvelle construction et vous essaieriez donc généralement de traquer et de corriger la source de ces erreurs plutôt que de revenir en arrière.
En général, les gens n’essaient pas de revenir en arrière…