Que souhaitez-vous faire ?
Mon installation Discourse fonctionne à merveille depuis 3 ans. J’ai effectué une mise à jour manuelle vers Docker et tout est maintenant cassé. Je ne peux accéder au serveur qu’en mode de récupération. Je n’arrive pas à démarrer Docker. Lorsque je lance le serveur depuis le disque dur (au lieu du mode de récupération), je ne peux pas me connecter via SSH.
Quand avez-vous besoin que ce soit fait ?
Faites à nouveau fonctionner Discourse !
J’ai un instantané d’il y a 2 mois, bien que je préférerais NE PAS perdre les données des 2 derniers mois. J’ai également un instantané d’immédiatement après que Docker ait cessé de fonctionner.
J’ai embauché un développeur il y a quelques heures et il n’a pas pu terminer le projet car il est tard pour lui, pourtant j’ai besoin que cela soit résolu dès que possible. Il s’agit d’un site de production.
Il a déclaré :
toutes les vérifications standard ont été effectuées, SSH fonctionne, le trafic n’est pas bloqué, nous avons mis à jour la configuration SSH pour utiliser l’authentification par mot de passe. Ce que nous devons faire, c’est enquêter sur les étapes effectuées avant cette panne et examiner les journaux associés.
Quel est votre budget, en dollars USD, que vous pouvez offrir pour cette tâche ?
Je paierai à l’heure pour la tâche, au taux du marché. Partagez simplement votre tarif.
Attacher un lecteur réseau (stockage bloc de volume Digital Ocean)
Compresser (créer une archive tar) les fichiers de /var/discourse
Exfiltrer ces fichiers vers le lecteur réseau
Éteindre l’ancien serveur et détacher le lecteur réseau
Construire une nouvelle organisation Discourse sur un nouveau serveur
Connecter le lecteur réseau
Décompresser les fichiers
Trouver une sauvegarde datant de 7 jours
Restaurer à ce point
Nous avions tenté de simplement déplacer le dossier /var/discourse dans sa totalité vers le nouveau serveur, mais nous avons rencontré des problèmes avec Redis (je ne suis pas sûr que ce soient les problèmes principaux, mais c’est ce qui a été signalé).
Juste par curiosité. Il y a quelques messages récents concernant des mises à niveau cassées liées à Docker et DigitalOcean. Est-ce juste une coïncidence ou y a-t-il une cause commune que d’autres administrateurs Discourse sur DigitalOcean rencontreront s’ils effectuent une mise à niveau ? Je demande parce que j’en suis un.
@waffleslop@jericson bon travail et merci d’avoir partagé les informations sur ce que vous avez fait pour le résoudre - c’est toujours bien d’avoir une ressource comme celle-ci en tant qu’auto-hébergeur, au cas où j’aurais des problèmes !
@icaria36 Je suis sur Digital Ocean pour la plupart de mes instances et j’ai récemment mis à niveau à la fois le système d’exploitation et la base de code Discourse sans aucun problème. (J’espère que poster ceci ne me portera pas malheur !)
Je peux confirmer que toutes les mises à jour ont été un jeu d’enfant jusqu’à hier. J’ai mis à jour Docker depuis l’interface graphique et cela a fonctionné. Ensuite, je suis allé mettre à jour les 3 éléments suivants et j’ai appuyé sur l’un d’eux (je ne me souviens plus lequel) en premier. Rien ne s’est passé. J’ai attendu quelques secondes et j’ai appuyé sur l’autre… puis sur l’autre. Peut-être ai-je agi trop rapidement et tout bloqué ? J’ai fini par me connecter à la console et j’ai trouvé un message suggérant un redémarrage, j’ai donc redémarré la machine. Elle n’est jamais revenue en ligne complètement après cela.
Il est possible que j’aie redémarré pendant une mise à niveau/une mise à jour, ce qui, alors que j’écris ceci, me semble assez stupide à faire !
Nous n’avons pas passé beaucoup de temps à chercher la cause du problème car je voulais que @waffleslop soit opérationnel le plus rapidement possible. J’ai mis à niveau mes serveurs Discourse (hébergés sur DigitalOcean) sans problème. Cependant, j’utilise la ligne de commande plutôt que l’interface graphique car j’ai une installation non standard.
Je peux vous recommander quelques éléments pour minimiser le risque de temps d’arrêt prolongé :
Faites une sauvegarde avant toute chose ! Je me demande s’il ne devrait pas y avoir un avertissement dans l’interface recommandant fortement une sauvegarde avant de pouvoir effectuer une mise à jour. Une sauvegarde récente me donne l’assurance qu’au moins nous pouvons lancer un nouveau Droplet et restaurer les choses dans le pire des cas.
Assurez-vous de pouvoir accéder à votre sauvegarde !@waffleslop et moi avons passé une partie considérable de notre temps à comprendre comment obtenir une copie de /var/discourse sur le nouveau Droplet. Quelque chose de très étrange se passait avec le Droplet d’origine et nous n’avons pas pu simplement scp les fichiers vers le nouveau Droplet. Pour mes propres serveurs, je stocke les sauvegardes sur S3 et je les copie sur ma machine locale tous les soirs. Est-ce excessif ? Probablement. Mais cela me donne beaucoup d’options lorsque les choses cessent de fonctionner pour une raison quelconque.
Testez vos sauvegardes de temps en temps. Lorsque vos serveurs de production sont en panne, vous voulez avoir la certitude que vous savez ce que vous faites. Idéalement, vous testeriez une sauvegarde juste avant d’effectuer une mise à jour afin d’avoir un point de repli si quelque chose tourne mal avec la production. Mais il suffit généralement d’essayer une sauvegarde aussi souvent que nécessaire pour garder le processus frais dans votre esprit.
Deux têtes valent mieux qu’une. C’est peut-être de l’intérêt personnel, mais il peut être beaucoup plus facile de traverser une urgence si vous pouvez partager votre écran lors d’un appel avec quelqu’un qui a de l’expérience dans ce genre de situation. Idéalement, vous voulez quelqu’un qui sait utiliser la ligne de commande.
Tant que vous effectuez une sauvegarde, vous devriez être en sécurité pour effectuer la mise à niveau.
