Mises à jour sans temps d'arrêt

Dev
2

Nous avons effectué avec succès la mise à niveau il y a quelques mois. Je partage ici notre expérience pour toute personne qui pourrait se poser la même question à l’avenir.

Discourse prend en charge dans une certaine mesure les mises à niveau sans temps d’arrêt grâce aux migrations post-déploiement. Comme nous l’avons compris, le processus global peut être divisé en deux étapes.

ÉTAPE 1 : Mise à niveau vers la nouvelle version et exécution des migrations sûres :

  • Mettez à jour tous vos plugins et thèmes pour qu’ils soient compatibles avec la nouvelle version. (Cela représente en réalité un travail considérable selon votre configuration).
  • Générez votre fichier web_only.yml contenant :
    version: <NOUVELLE_VERSION>
    SKIP_POST_DEPLOYMENT_MIGRATIONS=1
  • Amorçage (./launcher bootstrap web_only)
  • Redémarrez vos serveurs

ÉTAPE 2 : Exécution de la migration post-déploiement (migrations à haut risque telles que la suppression de colonnes et de tables, etc.). À ce stade, cette étape devrait être sûre car tous vos serveurs exécutent la nouvelle version du code et ne devraient plus dépendre des données supprimées :

  • Générez votre fichier web_only.yml avec :
    version: <NOUVELLE_VERSION>
    SKIP_POST_DEPLOYMENT_MIGRATIONS=0
  • Amorçage (./launcher bootstrap web_only)
  • Redémarrez vos serveurs

Complications :
Nous avons décidé d’exécuter l’ÉTAPE 1 et l’ÉTAPE 2 à des dates différentes, ce qui a causé certains problèmes. Il y a eu une importante refonte du modèle des sondages entre les versions 2.1 et 2.3. Il semble qu’initialement, la plupart des données des sondages étaient stockées sous forme d’objet JSON dans la table post_custom_fields. D’ici la version 2.3, elles ont été déplacées vers leur propre table polls. Cela a nécessité une migration de données qui a été effectuée dans le cadre des migrations post-déploiement (ÉTAPE 2).

Notre problème spécifique était que, juste après la migration vers la version 2.3, les sondages créés avant la mise à niveau étaient cassés, probablement parce que le code de rendu supposait le nouveau modèle de données. Certains utilisateurs l’ont remarqué et ont tenté de mettre à jour manuellement les sondages via l’interface utilisateur, ce qui a fini par créer des enregistrements dans la nouvelle table polls. Ces enregistrements, comme nous l’avons malheureusement découvert plus tard, déclenchaient une contrainte d’unicité PostgreSQL lors du processus d’amorçage, le bloquant complètement.

Pour contourner cela, nous avons décidé d’appliquer un correctif qui sautait une migration de sondage particulière si elle existait déjà dans la base de données. Ce n’était pas une solution parfaite, car on pourrait perdre des données de post_custom_fields qui ne seraient jamais migrées pour ces publications. Mais dans notre cas, cela restait un bon compromis car le nombre de cas était très faible dans notre système (2 instances que nous avons pu observer) et nous a permis d’exécuter le processus d’amorçage. Maintenant, tester et appliquer le correctif a soulevé deux nouvelles questions :

  • Comment tester le changement avant de soumettre la PR ?
    Nous voulions tester notre code dans les mêmes conditions que celles où il serait exécuté en réalité, ce qui signifiait le tester contre le processus d’amorçage. Ce n’est pas aussi trivial que de tester des modifications de code en temps d’exécution, que vous pouvez faire en exécutant localement l’application Discourse autonome.

  • Comment intégrer les modifications dans notre système ?
    Nous ne voulions pas attendre que le correctif atteigne une version officielle de Discourse, ce qui pourrait être un processus long et nous obligerait essentiellement à effectuer une autre mise à niveau. Nous avions déjà des clients qui se plaignaient des sondages existants, et plus nous attendions, plus les risques que les clients modifient manuellement les sondages aggravant les problèmes d’intégrité des données étaient élevés.

Nous avons donc trouvé un moyen de tester les modifications que nous introduisions en changeant l’origine du dépôt utilisé par le script d’amorçage. Cela a nécessité quelques essais et erreurs car nous ne sommes pas très familiers avec pups et les autres outils autour de ce processus. Finalement, nous avons fait quelque chose comme cela.

Cela nous a permis de vérifier que notre correctif fonctionnait comme prévu. Nous avons également pu amorcer une nouvelle image en production à partir de notre propre version modifiée de Discourse contenant le correctif, sans avoir à attendre une version officielle de Discourse.