Lua-resty-auto-ssl: Verlängerungsjob wird aufgrund von Prozessbeendigung nie gefeuert
Hey!
Wir hatten vor kurzem ein Problem, bei dem unsere Zertifikate nicht regeneriert wurden. Der Grund dafür war, dass unsere Openresty-Prozesse nie für das standardmäßige 24-Stunden-Timeout (aufgrund von #136) ausgeführt wurden; also wurde der Erneuerungsjob nie gefeuert. Ich kann das Erneuerungsintervall auf etwas kleineres reduzieren, aber ich muss eine Zahl aus dem Himmel holen, um unsere durchschnittliche Prozessbetriebszeit abzuschätzen, bei der ich mir im Moment nicht sicher bin.
Können wir vielleicht einen der folgenden Schritte ausführen:
- Akzeptieren Sie eine Option
renew_check_time, der Sie ein Zeitformat wiehh:mmz. B. "00:00" führt die Verlängerung immer um Mitternacht durch - im Speicher beibehalten, als das letzte Mal eine erfolgreiche Erneuerung stattgefunden hat. Überprüfen Sie beim Start, ob dies weiter von der aktuellen Zeit entfernt ist als das
renew_check_interval? Dann die Verlängerung auslösen, wenn ja?
Ich denke, in der Zwischenzeit werde ich versuchen, einen anderen Server laufen zu lassen, dessen einziger Zweck es ist, am Laufen zu bleiben! Es wird aus dem Load-Balancer heraus sein, also hoffe ich, dass es ohne Verkehr 24 Stunden lang betriebsbereit sein sollte. Ich werde es überwachen, um zu sehen.
Gerne versuche ich, eine PR für das obige Feature zu schreiben, wenn Sie den Klang eines von beiden als potenzielle Verbesserungen mögen.
domharrington
Alle 7 Kommentare
Danke für deinen Bericht und die Untersuchung! Wir treffen wahrscheinlich auch darauf, obwohl ich noch nicht die Zeit gefunden habe, es richtig zu überprüfen. Für mich klingt die zweite Option besser. Schön zu hören, dass Sie dafür eine PR einreichen möchten! Lassen Sie es mich wissen, wenn Sie Hilfe benötigen.
Was denkst du, @GUI?
luto
am 11. Juni 2018
Außerdem wäre es wirklich hilfreich, wenn wir den Erneuerungsjob irgendwie als Shell-Skript bereitstellen könnten, damit wir den Job manuell starten können, falls er jemals benötigt wird. Auf diese Weise könnten wir dann auch einfach einen Cron-Job einrichten, um alle 24 Stunden die Erneuerung aufzurufen. Glaubst du, das wäre einfach genug?
domharrington
am 12. Juni 2018
Außerdem wäre es wirklich hilfreich, wenn wir den Erneuerungsjob irgendwie als Shell-Skript bereitstellen könnten, damit wir den Job manuell starten können, falls er jemals benötigt wird. Auf diese Weise könnten wir dann auch einfach einen Cron-Job einrichten, um alle 24 Stunden die Erneuerung aufzurufen. Glaubst du, das wäre einfach genug?
Das wäre wirklich nützlich. Im Moment betreibe ich eine separate Instanz ohne Datenverkehr, die nur den Erneuerungsjob (ohne Verzögerung) kurz nach dem Start ausführt.
brianlund
am 6. Juli 2018
@brianlund könnten Sie bitte Ihren manuellen Erneuerungscode teilen? wir stehen vor einem Problem bei der Erneuerung und möchten sehen, was uns fehlt.
Vielen Dank.
nabeel-khan
am 18. Aug. 2018
Ähnlich wie bei @brianlund haben wir eine Instanz, die ohne Datenverkehr ausgeführt wird, sodass der Erneuerungsauftrag immer ausgeführt wird. Dies ist eine gute Lösung für uns im Moment
domharrington
am 20. Aug. 2018
Ja, das ist so ziemlich alles, was wir tun, kein benutzerdefinierter Code.
brianlund
am 20. Aug. 2018
Wir sind gerade darauf gestoßen, als wir unsere Auto-SSL-Konfigurationen für acmev2 aktualisiert haben. Gab es in den letzten Jahren Fortschritte bei der Klärung dieses Problems? 😅
nergdron
am 22. Juni 2020
Verwandte Themen
n11c
·
13Kommentare
kshnurov
·
3Kommentare
prionkor
·
11Kommentare
sahildeliwala
·
16Kommentare
discobean
·
8Kommentare
Hilfreichster Kommentar
Das wäre wirklich nützlich. Im Moment betreibe ich eine separate Instanz ohne Datenverkehr, die nur den Erneuerungsjob (ohne Verzögerung) kurz nach dem Start ausführt.