Bonjour la communauté ! Je suis désolé que nous devions nous rencontrer dans ces circonstances. Discourse est hors ligne après une mise à niveau ratée.
J’ai heureusement les images Docker précédentes (j’espère), mais je ne sais pas quoi faire pour rétablir les services. J’utilise également DigitalOcean.
Erreur
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle install --retry 3 --jobs 4' a échoué avec le retour #<Process::Status: pid 448 exit 5>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle config --local deployment true'", "su discourse -c 'bundle config --local without \\\"development test\\\"'", "su discourse -c 'bundle install --retry 3 --jobs 4'"]}
bootstrap a échoué avec le code de sortie 5
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.
e9fead51a802981ae53f85f54dc8bf7bf9fae5c1dab3e06e0d77ea0930ffb261
Bien que j’aie les anciennes images, j’ai supprimé la plus récente…
docker rmi 51421f454322 -f
J’ai les anciens conteneurs, mais lorsque j’essaie d’exécuter ./launcher start app, il semble préférer cette image supprimée.
root@hostname:/var/discourse# ./launcher start app
WARNING: Docker version 17.05.0-ce deprecated, recommend upgrade to 17.06.2 or newer.
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
starting up existing container
+ /usr/bin/docker start app
app
root@hostname:/var/discourse# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
afeec2777503 51421f454322 \"/sbin/boot\" 3 hours ago Up 5 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp app
root@hostname:/var/discourse# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20231218-0429 984f729957df 12 days ago 3.14GB
Y a-t-il un moyen de continuer avec l’ID d’image 984f729957df ?
La chose la plus simple est de créer une nouvelle instance et d’y copier /var/discourse pour reconstruire là-bas. Cela résoudra le problème plutôt que de l’atténuer.
Il existe une commande de lancement qui vous donnera la commande docker, ce qui pourrait aider. Vous pouvez regarder le script de lancement pour trouver son nom (mais je suis sur mon téléphone).
On dirait que vous suggérez : ./launcher start-cmd app
Cela produit pas mal de choses, en commençant par + true run --shm-size=512m -d --restart=always...
Je me lance, j’ai essayé : docker + true run 984f729957df --shm-size=512m -d --restart=always ... sans succès.
container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH"
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH".
Toute aide que vous pourrez apporter sera la bienvenue. Merci.
Merci pour la suggestion. Je ne suis pas fan des migrations non planifiées, mais il semble que ce soit ce qui est prévu. Je vais supposer que vous faites référence à ceci ? Move a Discourse site to another VPS with rsync
Y aura-t-il des instructions supplémentaires si nous avons activé DO Spaces (stockage S3) ?
Compte tenu de la période de l’année, il sera vraiment difficile (lire : probablement impossible) de coordonner les autres pour les changements nécessaires en temps voulu.
Je préférerais plutôt revenir à l’état où cela fonctionnait la dernière fois afin de pouvoir planifier une migration.
Le passage à un nouveau droplet présente peu de risques car vous pouvez simplement rétablir le DNS vers votre site désactivé, mais si vous n’avez pas accès au DNS et à Digital Ocean, vous êtes bloqué.
Il semble que vous ayez peut-être oublié de citer quelque chose avec la commande de démarrage. Il semble que ce soit ce que vous voulez faire.
J’ai configuré ce service en 2016, donc malheureusement, il semble que nous ayons les paramètres dans une base de données ? Il n’y a pas de paramètres S3 dans app.yml
Y a-t-il d’autres pièges dont je devrais être informé ?
Si vous le synchronisez via rsync, tout devrait bien se passer. Vous pourrez ensuite passer à la configuration recommandée. Vous pourriez avoir des problèmes si vous essayez une restauration de base de données.
Merci encore pour votre aide. En ce qui concerne rsync, je suis un peu inquiet de la façon dont les instructions disent en toutes lettres :
configurer le nouveau serveur et synchroniser
arrêter le service sur l’ancien serveur
synchroniser à nouveau mais avec --delete
Cela semble volatil, et aussi impossible dans mon scénario. Sera-ce une préoccupation ? J’ai l’impression qu’il s’agit simplement de s’assurer que tout ce qui s’est passé depuis le dernier rsync sur le forum est synchronisé, mais je pourrais me tromper.
Mise à jour :
Nous sommes de retour en ligne avec un tout nouveau Droplet.
Je suis content de savoir maintenant qu’une migration est relativement simple. Il aurait été beaucoup plus cool si la mise à jour n’avait pas cassé l’ancien Droplet.
Je sais que c’est un jour férié, mais ce serait formidable si quelqu’un de l’équipe de développement pouvait passer du temps à examiner cela. Je ne pense pas que ce soit un cas isolé. J’ai été tagué sur un autre fil où une collection s’est développée.