Ich habe glücklicherweise die vorherigen Docker-Images (hoffe ich), bin mir aber nicht sicher, was ich tun soll, um die Dienste wiederherzustellen. Benutze auch DigitalOcean.
Fehler
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle install --retry 3 --jobs 4' fehlgeschlagen mit Rückgabe #<Process::Status: pid 448 exit 5>
Ort des Fehlers: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fehlgeschlagen mit den Parametern {"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 fehlgeschlagen mit Exit-Code 5
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
e9fead51a802981ae53f85f54dc8bf7bf9fae5c1dab3e06e0d77ea0930ffb261
Während ich die alten Images habe, habe ich das neueste Image entfernt…
docker rmi 51421f454322 -f
Ich habe die alten Container, aber wenn ich versuche, ./launcher start app auszuführen, bevorzugt es anscheinend das gelöschte Image.
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
Gibt es eine Möglichkeit, mit der Image-ID 984f729957df fortzufahren?
Das Einfachste ist, ein neues Droplet zu starten, /var/discourse darauf zu kopieren und dort neu zu erstellen. Das wird das Problem lösen, anstatt es nur zu mildern.
Es gibt einen Launcher-Befehl, der Ihnen den Docker-Befehl liefert, was hilfreich sein könnte. Sie können das Launcher-Skript durchsuchen, um seinen Namen zu finden (aber ich bin gerade am Handy).
Es sieht so aus, als ob Sie vorschlagen: ./launcher start-cmd app
Es gibt ziemlich viel aus, beginnend mit + true run --shm-size=512m -d --restart=always...
Ich habe versucht: docker + true run 984f729957df --shm-size=512m -d --restart=always ... bisher ohne Erfolg.
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".
Jede Hilfe, die Sie geben können, ist willkommen. Danke.
Danke für den Vorschlag. Ich bin kein Fan von ungeplanten Migrationen, aber es scheint, dass dies bevorsteht. Ich gehe davon aus, dass Sie sich auf dies beziehen? Move a Discourse site to another VPS with rsync
Wird es zusätzliche Anweisungen geben, wenn wir DO Spaces (S3-Speicher) aktiviert haben?
Angesichts der Jahreszeit wird es wirklich schwierig (lesen: wahrscheinlich unmöglich) sein, die anderen rechtzeitig für die notwendigen Änderungen zu koordinieren.
Ich würde viel lieber zuerst zum Zustand zurückkehren, in dem es zuletzt funktioniert hat, damit ich eine Migration planen kann.
Der Umzug zu einem neuen Droplet ist mit geringem Risiko verbunden, da Sie einfach die DNS-Einstellungen auf Ihre deaktivierte Website zurücksetzen können. Wenn Sie jedoch keinen Zugriff auf DNS und DigitalOcean haben, stecken Sie fest.
Es klingt, als hätten Sie beim Startbefehl etwas vergessen zu zitieren. Das könnte das sein, was Sie tun möchten.
Ich habe diesen Dienst 2016 konfiguriert, daher scheint es leider, dass wir die Einstellungen in einer Datenbank haben? Es gibt keine S3-Parameter in app.yml.
Gibt es noch andere Fallstricke, auf die ich achten sollte?
Wenn Sie es per rsync übertragen, sollte alles in Ordnung sein. Dann können Sie auf die empfohlene Einrichtung umsteigen. Möglicherweise haben Sie Probleme, wenn Sie eine Datenbankwiederherstellung versuchen.
Vielen Dank nochmals für Ihre Hilfe. Was rsync betrifft, bin ich etwas besorgt über die Art und Weise, wie die Anweisungen so viele Worte sagen:
Richten Sie den neuen Server ein und synchronisieren Sie ihn
Stoppen Sie den Dienst auf dem alten Server
Synchronisieren Sie erneut, aber mit --delete
Das klingt volatil und ist in meinem Szenario auch nicht möglich. Wird das ein Problem sein? Ich glaube, es geht nur darum, sicherzustellen, dass alles, was seit dem letzten rsync im Forum passiert ist, synchronisiert wird, aber ich könnte mich irren.
Update:
Wir sind wieder online mit einem komplett neuen Droplet.
Ich bin froh, dass ich jetzt weiß, dass eine Migration relativ unkompliziert ist. Es wäre viel cooler gewesen, wenn das Update das alte Droplet nicht kaputt gemacht hätte.
Ich weiß, dass es ein Feiertag ist, aber es wäre toll, wenn sich jemand aus dem Entwicklerteam damit beschäftigen könnte. Ich glaube nicht, dass das ein Einzelfall ist. Ich wurde in einem anderen Thread markiert, wo sich eine Sammlung angesammelt hat.