Qui dit de mettre à jour toutes les deux semaines, tous les deux mois vous devriez mettre à jour via
Si vous auto-hébergez Discourse, vous devez occasionnellement effectuer une mise à jour manuelle via la ligne de commande pour obtenir les dernières versions de sécurité et les bibliothèques les plus récentes. Ces mises à jour ne sont pas récupérées dans admin/update, c’est pourquoi vous devrez occasionnellement effectuer cette étape supplémentaire.
Il y a quelques autres sujets qui parlent de la mise à jour admin → mise à jour via ssh/console, aucun d’entre eux ne précise quelles mises à jour ne peuvent pas être effectuées dans le navigateur.
Mon expérience a été qu’en 9 mois d’exécution de Discourse, une mise à jour web/admin a échoué, j’ai trouvé l’article ci-dessus, j’ai exécuté les commandes indiquées dans une session ssh.
Existe-t-il une meilleure façon de savoir quelle méthode utiliser que “la méthode la plus simple échoue” ?
Mon habitude maintenant est toujours d’utiliser la ligne de commande. Auparavant, j’utilisais l’interface web, mais comme elle pourrait ne pas fonctionner et comme elle me donne moins de contrôle et de visibilité, je ne m’en soucie plus.
Mais mes forums ont un trafic assez faible et un peu de temps d’arrêt n’est pas un gros problème.
Il est également à noter que je suis à l’aise sur la ligne de commande. Mais alors, chaque administrateur de discourse devra utiliser la ligne de commande à un moment donné.
Merci, c’est utile, j’avais imaginé que la ligne de commande pourrait être plus rapide (moins de temps d’arrêt/surveillance du temps de traitement).
Nous avions considéré une interface web/graphique pour les mises à jour comme un avantage considérable, car, bien que j’aie des décennies d’expérience en codage et administration Unix/Linux, je suis aussi le seul point de défaillance de l’organisation, donc ce fut une déception d’apprendre que certaines mises à jour nécessitent la ligne de commande.
Tout va bien, c’est une excellente plateforme, plus que le prix d’entrée
Il semble judicieux d’être prêt pour une mise à niveau en ligne de commande, même si l’on s’apprête à tenter une mise à niveau web. Personnellement, je consulte ce forum au préalable pour voir si quelqu’un rencontre des difficultés actuellement. Il peut arriver que la base de code soit temporairement cassée. De plus, je fais toujours une sauvegarde et je la télécharge avant de commencer.
Je crois comprendre que la meilleure pratique si un temps d’arrêt minimal est important est l’installation à deux conteneurs.
Je ne comprends pas entièrement Docker (un euphémisme), mais je crois comprendre que si vous vous retrouvez avec un forum à moitié mis à niveau qui ne fonctionne pas, vous pouvez, dans un certain sens, démarrer la version d’avant la mise à niveau en attendant de l’aide. (J’ai cherché “redémarrer l’ancien conteneur” mais je n’ai pas trouvé l’information exacte à ce sujet.)
./launcher start app devrait ramener la version précédente à la reconstruction si une échoue à mi-chemin.
Bien que je mette à jour via l’interface utilisateur la plupart du temps. De cette façon, il n’y a pas de temps d’arrêt. Parfois, vous devrez mettre à jour via la ligne de commande, mais généralement, vous serez invité à le faire après la mise à jour du gestionnaire Docker et avant de tenter de mettre à jour Discourse lui-même.
Généralement, si une reconstruction en ligne de commande est nécessaire, l’interface utilisateur vous avertira et refusera d’effectuer la mise à niveau elle-même. Cela n’arrive cependant pas toujours.
J’ai un dashboard.literatecomputing.com qui effectue des reconstructions en ligne de commande en un clic. Bien que j’espère que les gens me paieront pour l’utiliser (et obtenir mon support), pour une “durée limitée”, vous pouvez rejoindre le groupe d’essai gratuit et l’utiliser gratuitement. Il gère un certain nombre de problèmes, tels que la suppression des plugins qui ont été intégrés au cœur, les mises à niveau de Postgres, le redémarrage de l’ancien conteneur en cas d’échec de la reconstruction, la mise à niveau uniquement du conteneur web s’il s’agit d’une installation à 2 conteneurs, etc.
Point juste, je suis un peu plus paranoïaque, je fais un instantané du système avant et après les mises à niveau, en plus des sauvegardes de l’application Discourse. … Je devrais probablement en apprendre davantage sur la restauration à partir des sauvegardes.
Je n’ai pas encore utilisé d’instantané… J’ai l’impression que c’est une option payante.
Mais je pense qu’il est important de télécharger cette sauvegarde : si l’instance est complètement cassée, si mon compte est annulé et que l’hébergeur supprime tout ce que j’utilisais, j’aurai toujours mon forum, et dans un format que je peux restaurer chez n’importe quel hébergeur de mon choix.
Les instantanés système (je pense) nécessitent une interruption de service pendant leur création et sont largement excessifs. Une copie de votre app.yml et le fichier de sauvegarde suffisent. Si les sauvegardes sont sur S3, tout ce dont vous avez besoin est votre app.yml pour démarrer un tout nouveau serveur et restaurer les données.
Les instantanés nécessitent absolument un temps d’arrêt, et mes instantanés coûtent quelques dollars par mois à conserver.
Je fais aussi des sauvegardes, mais ayant essayé de récupérer un discourse cassé une fois à partir d’une sauvegarde effectuée à un moment connu, je suis en mode sécurité maximale.
