Комментарии 12
Момент протухания сертификата известен сразу после покупки. Можно просто добавлять событие в гуглокалендарь ;) Можно скриптом ;)
Можно просто добавлять событие в гуглокалендарь
Можно сразу планировать автоматический перевыпуск сертификата, сейчас это решается без каких-либо проблем.
С самого начала не собирались ставить нашу платформу в зависимость от каких-либо внешних сервисов.
Решили, что самостоятельный мониторинг будет надежнее.
Что касается автоматического перевыпуска, то даже с Lets Encrypt бывают проблемы. А если сотни сайтов, сертификаты все разные, куплены разными людьми в разных местах, то настроить автоматический перевыпуск нам представляется слишком сложным, и опять же, ненадежным решением.
Касательно проверки сертификатов, можно посмотреть в сторону zabbix_agent2 с ключом web.certificate.get + стандартный шаблон (https://www.zabbix.com/integrations/ssl)
Еще интересно почему была выбрана реализация создания хостов/метрик/триггеров через API, а не через Discovery и host/items/trigger prototypes?
Скрипт можно запускать через external check вместо cron, для мониторинга выполнения и конфигурации расписания из одной точки.
А так, интересная реализация, хотя кажется немного усложненной
Дело в том, что нам нужна проверка доменов через наш биллинг - открыт сайт или закрыт. Если сайт открыт, добавляем в мониторинг, если закрыт - убираем.
Если же я правильно понимаю, то стандартный шаблон дает возможность проверять только один домен, который нужно прописать в макросе:
{$CERT.WEBSITE.HOSTNAME} The website DNS name for the connection. <Put DNS name>
На момент создания этой системы проверки никаких стандартных шаблонов вообще не было, как и zabbix_agent2.
Так сейчас же они есть. И все, что нужно - это на стороне биллинга реализовать эндпоинт, отдающий список доменов, а дальше этот список скормить discovery в заббиксе, возможно, чуть подкрутить стандартный шаблон, чтобы множество доменов/сертификатов нормально проверялись с одного хоста, а дальше заббикс все сделает сам. А если написать ещё и свой скрипт для обработки алерта про истечение срока действия сертификата - то ещё и попытается автоматически обновить его сам. Да, возможно, не для всех провайдеров сертификатов он отработает, но хотя бы какая-то часть из сотен сертификатов будет обновлена автоматически.
Полностью поддерживаю.
Discovery на стороне сервера напрямую Zabbix'ом с CRM + автоматическое создание items.
Опять же автор опубликовал решение на основе старых (и весьма неоптимальных) практик (да еще и крон и пароль админа для доступа в API в тектовом файле - а если крон-задача отвалится или данные авторизации API "протухнут" - будем верить, что items все еще актуальны?).
Скрипт и пароль админа доступен только руту. Что касается отвала, на практике такого ни разу не было за много лет - все работает надежно.
Что касается CRM (биллинга), то нам было проще сделать именно так как сделали, в других ситуациях возможно и другое решение будет лучше. Мы потратили на скрипт всего пару дней, и работает стабильно. Не было ни одного прокола из-за того что забыли продлить домен или сертификат.
С самого начала прорабатывали вопрос автоматической регистрации и продления доменов и сертификатов, там не все просто, в итоге отказались. А сейчас вообще приходится каждый раз думать, продлевать сертификат там где приобретали или покупать в новом месте. В общем, для нас не подошло.
Perl в 2022? Серьёзно? ;)
не, я понимаю, что для вас это "так исторически сложилось", но какова в этом ценность для сообщества? "ещё один велосипед"?
На мой взгляд, ценность в том, что довольно подробно рассмотрено надежно работающее решение. Язык реализации тут не имеет значения - кому нужно, перепишут легко и на другой язык. Хороший системный программист может использовать все основные языки.
Что касается "велосипедов", то реальность такова, что не всегда можно найти готовое решение, подходящее по всем параметрам. Это во-первых. А во-вторых, любое готовое решение когда-то прошло уже стадию велосипеда.
При создании мониторинга и сервиса в целом мы не ставили перед собой целью использование самых новых решений. Основная цель - устойчивая работа сервиса интернет-магазинов и тех сервисов, из которых он состоит, а также легкость сопровождения.
Наш клиент не спросит, какие технологии или языки используются в решении, но он будет очень недоволен, если интернет-магазин прекратит свою работу даже на несколько минут или часов. Думаю это касается не только наших клиентов, но и вообще всех пользователей ИТ.
Ну а если то, что было когда-то создано, работает хорошо и надежно, я не вижу смысла его переписывать только ради новизны используемых инструментов. Особенно если при переписывании не будет получено каких-либо преимуществ, тактических или стратегических.
Мониторинг SSL-сертификатов и доменов с помощью Zabbix