Vérification de la dépendance de mise à jour/mise à niveau de Discourse

Fonctionnalité
1

Comme nous l’avons observé au fil des ans, il arrive qu’une mise à jour/mise à niveau échoue en raison de dépendances, par exemple la version de Docker ou le système d’exploitation.

Mon idée est que Discourse exécute une sorte de vérification des dépendances pour s’assurer que les exigences de base sont satisfaites. Si la vérification échoue, elle fournit des détails sur ce qui pourrait être nécessaire et interrompt le processus de mise à jour/mise à niveau.

Cela permettra de réduire les temps d’arrêt du forum en interrompant une mise à jour/mise à niveau du Core Discourse en avortant le processus qui échouera.

2

Ils font de gros efforts pour faire ça. Le nombre de choses qui peuvent mal tourner est assez élevé. La plupart du temps, si vous ne maintenez pas votre système d’exploitation à jour (et probablement Docker), c’est de votre faute.

Ils essaient de vérifier la version de Docker, et les scripts que j’utilise mettent à niveau Docker s’il est connu pour être mauvais (il faudrait probablement toujours mettre à niveau Docker).

Je pense qu’ils pourraient faire mieux en forçant toujours une mise à niveau en ligne de commande si l’image de base change. Personnellement, je ne l’utilise presque jamais car mon tableau de bord effectue une mise à jour en ligne de commande en un clic.

1 « J'aime »
3

deos mettre à jour docker_manager mettre à jour docker ?

1 « J'aime »
4

Je ne cherche absolument pas à rejeter la faute. Le problème avec l’auto-hébergement, plus précisément, n’est pas forcément la compréhension du système d’exploitation du serveur. La plupart des gens installent un système d’exploitation et le maintiennent généralement à jour. Mais souvent, avec les LTS (Long Term Support), ils ne savent peut-être pas ou ne comprennent pas la mise à niveau du système d’exploitation, surtout s’ils sont habitués aux versions “rolling release” (versions continues).

Par exemple, une entreprise que j’aide, après ne pas avoir fait de mises à jour pendant un certain temps, a remarqué qu’une mise à jour était disponible. Ils ont donc mis à jour Docker via l’interface web, ce qui leur a ensuite permis de mettre à jour Discourse.

Étant donné que la version d’Ubuntu LTS n’était pas assez récente, la mise à jour de Docker ne répondait pas à la configuration minimale requise. Pourtant, l’interface web a quand même permis de tenter la mise à jour, qui a bien sûr échoué et a mis le site hors service.

Ils ont donc tenté une reconstruction en ligne de commande, qui a bien sûr échoué en raison du non-respect des exigences minimales.

Si la mise à jour dans le web avait identifié que la version de Docker n’était pas la version minimale, elle aurait pu interrompre le processus de mise à jour en signalant une dépendance non satisfaite, sans que le site ne soit hors service.

J’ai jeté un coup d’œil général pour eux. Comme il semble qu’ils utilisent peut-être d’autres choses sur le serveur, je leur ai demandé de faire en sorte que leur technicien examine la possibilité de mettre à niveau la LTS vers une version plus récente. Je ne voulais pas essayer de mettre à niveau le système d’exploitation au cas où cela casserait d’autres choses qu’ils utilisent.

Existe-t-il un moyen simple de redémarrer le conteneur avant la tentative de reconstruction via le web et la ligne de commande ?

J’ai essayé ./launcher start app

Ce qui a échoué.

Autre chose. Étant donné la façon dont le site Discourse est tombé en panne, est-ce que la mise en place d’un nouveau serveur avec rsync fonctionnerait ? Ils utilisent la version stable au lieu de la version “tests passed” (tests réussis) recommandée.

Si ils exécutent la commande « do-release-upgrade » et mettent à niveau Docker manuellement, cela serait-il efficace pour mettre à niveau postgreq ?

5

Il le fera dans la version Ubuntu LTS prise en charge. Mais uniquement la ou les versions prises en charge par la LTS. Dans ce cas, leur LTS est en fin de vie. Donc, il ne prend pas en charge la version Docker minimale.

Les versions Ubuntu LTS, si je me souviens bien, ont une durée de vie de 4 ans de mises à jour.

1 « J'aime »
6

Pas les gens avec qui je travaille. Ils ne le mettront pas à jour quand je leur dirai qu’il est obsolète.

Je suis à peu près sûr que ce qui s’exécute à l’intérieur du conteneur ne peut pas dire sous quelle version de Docker il s’exécute.

Peut-être que si. Il semble que vous puissiez l’obtenir à partir d’un conteneur pour voir quelle version s’exécute.

https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion

Alors peut-être qu’ils pourraient faire mieux. Ce serait une chose intéressante à ajouter au tableau de bord, si cela fonctionne vraiment.

Cela fonctionne généralement. Une exception est si la base de données a été migrée.

Si le système d’exploitation est obsolète, je trouve généralement plus facile et plus sûr de passer à une nouvelle machine virtuelle. Idéalement, vous le faites pendant que l’ancien serveur fonctionne toujours. Voir Déplacer un site Discourse vers un autre VPS avec rsync

Si vous avez une sauvegarde, vous pouvez omettre la copie de la base de données et omettre la mise à niveau de la base de données, il suffit de la restaurer sur la nouvelle base de données.

1 « J'aime »
7

C’est pourquoi j’ai dit mettre à jour. Dans le cas d’un produit obsolète, cela nécessite une mise à niveau du système d’exploitation. Mais je suis d’accord avec vous sur le fait qu’il existe une grande variété de personnes qui ne suivent pas bien les instructions. :wink:

Lorsque j’ai été promu administrateur de l’entreprise pour laquelle je travaille gratuitement :woman_facepalming:

Je leur avais dit pendant plus d’un mois que leur forum allait planter à un moment donné car ils n’avaient pas l’espace nécessaire pour effectuer la reconstruction de l’application. Ils avaient un serveur de taille minimale (il y a 7 ans). Si je me souviens bien, il avait 25 Go d’espace au total. Bien sûr, ils n’ont pas écouté. Et ont fini par payer quelqu’un ici pour transférer le forum sur un nouveau serveur. Temps d’arrêt total d’environ 2 semaines, peut-être un peu plus.

Ce serait vraiment génial si cela pouvait fonctionner. Pour les gens comme vous et moi qui vivent un peu ici, nous nous tenons assez à jour par rapport à beaucoup de gens qui ne viennent qu’en cas de problème ou à la recherche de modules complémentaires et d’autres problèmes de support mineurs.

Ok, je vais les informer. Cependant, je ne suis pas sûr de l’ancienneté de la sauvegarde. J’imagine donc que dans leur cas, rsync ou la mise à niveau du système d’exploitation devront être explorés.

Sur mon serveur personnel qui approchait de l’obsolescence, j’ai beaucoup lu et j’ai veillé à ne pas mettre à jour via le web/la ligne de commande. Jusqu’à ce que je sois à l’aise avec la procédure rsync. Et j’ai quand même eu quelques petits contretemps que vous et la communauté m’avez aidé à déboguer.

:clinking_beer_mugs::smiling_face_with_sunglasses::+1::sparkles:

1 « J'aime »