Bei einem Upgrade einer Installation mit zwei Containern ist heute Morgen etwas schiefgelaufen. Beim Bootstrapping eines neuen Containers wurde die Datenbank in einen defekten Zustand migriert (vielleicht wäre das nicht passiert, wenn ich SKIP_POST_DEPLOYMENT_MIGRATIONS=1 verwendet hätte, aber das ist ein anderes Thema), sodass der laufende Container die Meldung „Hoppla, diese Site ist defekt
1 „Gefällt mir“
Wie genau war es kaputt? Können Sie genauer sein? Wie sah die Startseite aus?
Ja, ‘ok’ bedeutet, dass der Unicorn läuft. Du kannst Postgres und Redis herunterfahren, und es zeigt trotzdem ‘ok’ an, wenn ich mich richtig erinnere.
3 „Gefällt mir“
Ich bin mir ziemlich sicher, dass das richtig ist. Es ergibt Sinn, es ist nur nicht das, was ich dachte.
1 „Gefällt mir“
Ich bin mir nicht sicher, wie der aktuelle Stand dazu ist @sam @eviltrout? Ich erinnere mich vage an eine frühere Diskussion darüber.
1 „Gefällt mir“
Ja, es wird weder Redis noch PG geprüft. Ich glaube, wir nutzen ein Plugin, das User.find(1) und $redis.get verwendet. Das erfasst auch den Fall von @pfaffman nicht, aber das könnte etwas übertrieben sein – man kann nicht erwarten, dass hier eine vollständige Datenbankkonsistenzprüfung durchgeführt wird.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub
2 „Gefällt mir“
Der Endpunkt /srv/status prüft nur den lokalen Prozess, nicht aber Abhängigkeiten. „Ist der HTTP-Stack hängengeblieben?" sowie „Bin ich im Lame-Duck-Modus?". In der Kubernetes-Terminologie handelt es sich hierbei um die livenessProbe, nicht um die readinessProbe.
Wenn wir eine readinessProbe einführen möchten, sollte diese unter einer anderen URL liegen.
Wahrscheinlich Discourse.system_user.id statt 1.
5 „Gefällt mir“