Lua-resty-auto-ssl: Продление работы никогда не увольняют из-за выхода из процесса

Созданный на 11 июн. 2018 · 7Комментарии · Источник: auto-ssl/lua-resty-auto-ssl

Привет!

Итак, недавно у нас возникла проблема, когда наши сертификаты не восстанавливались. Причина этого заключалась в том, что наши процессы openresty никогда не работали в течение установленного по умолчанию 24-часового тайм-аута (из-за # 136); так что работа по обновлению никогда не увольнялась. Я могу уменьшить Renewal_interval до меньшего, но мне нужно поднять с неба цифру, чтобы оценить среднее время безотказной работы нашего процесса, в котором я не уверен прямо сейчас.

Можем ли мы сделать одно из следующего:

примите параметр renew_check_time , который вы задаете в формате времени, например hh:mm например, «00:00» всегда будет выполнять обновление в полночь.
сохраняются в хранилище при последнем успешном обновлении. При запуске проверьте, не находится ли оно дальше от текущего времени, чем renew_check_interval ? Тогда активируйте продление, если оно есть?

Я думаю, что тем временем я попытаюсь запустить еще один сервер, единственная цель которого - не спать! Он будет вне балансировщика нагрузки, поэтому я надеюсь, что без трафика он сможет работать в течение 24 часов. Я собираюсь следить за ним, чтобы увидеть.

С радостью попытаюсь написать пиар для вышеупомянутой функции, если вам нравится звучание любой из них в качестве потенциальных улучшений.

Источник

domharrington

Самый полезный комментарий

Также было бы очень полезно, если бы мы могли каким-то образом раскрыть задание обновления как сценарий оболочки, чтобы мы могли вручную запустить задание, если оно когда-либо потребуется. Таким образом, мы могли бы также просто настроить задание cron для вызова обновления каждые 24 часа. Как вы думаете, это будет достаточно просто?

Это было бы действительно полезно. На данный момент я запускаю отдельный экземпляр без трафика, который запускает задание обновления (без задержки) только вскоре после его запуска.

brianlund 6 июл. 2018

👍2

Все 7 Комментарий

Спасибо за ваш отчет и расследование! Вероятно, мы тоже сталкиваемся с этим, хотя я еще не нашел времени, чтобы как следует это проверить. На мой взгляд, второй вариант звучит лучше. Рад слышать, что вы хотите подать PR по этому поводу! Дай мне знать, если тебе понадобится помощь.

Как ты думаешь, @GUI?

luto 11 июн. 2018

Также было бы очень полезно, если бы мы могли каким-то образом раскрыть задание обновления как сценарий оболочки, чтобы мы могли вручную запустить задание, если оно когда-либо потребуется. Таким образом, мы могли бы также просто настроить задание cron для вызова обновления каждые 24 часа. Как вы думаете, это будет достаточно просто?

domharrington 12 июн. 2018

👍2

Также было бы очень полезно, если бы мы могли каким-то образом раскрыть задание обновления как сценарий оболочки, чтобы мы могли вручную запустить задание, если оно когда-либо потребуется. Таким образом, мы могли бы также просто настроить задание cron для вызова обновления каждые 24 часа. Как вы думаете, это будет достаточно просто?

brianlund 6 июл. 2018

👍2

@brianlund, не могли бы вы поделиться своим кодом продления вручную? мы столкнулись с проблемой обновления и хотели бы увидеть, что нам не хватает.

Спасибо.

nabeel-khan 18 авг. 2018

Как и в случае с

domharrington 20 авг. 2018

Да, это почти все, что мы делаем, никакого специального кода.

brianlund 20 авг. 2018

мы только что столкнулись с этим при обновлении наших конфигураций auto-ssl для acmev2. Был ли какой-нибудь прогресс в решении этого вопроса за последние пару лет? 😅