Comments 14
Совет для тех кому предстоит запускать много друг от друга зависящих заданий через crontab посмотреть в сторону luigi, dagster, Apache Airflow.
Отправил техдиру почитать 👍
в случае перезагрузки сервера, прерванные задания должны начать свою работу заново
А если задания неидемпотентны?
Тут сложнее, ваши кейсы могут быть сложнее, чем мой совет ниже.
В нашем случае стараемся делить задачи на такие блоки, которые можно "дернуть ручкой" на предыдущий этап. То есть, задание проверяет входные данные и может выйти на рекурсию на Х шагов назад. Разумеется, что число таких шагов тоже надо считать и разбирать каждый случай.
Все-таки мне странно что ничего готового не нашли.
Как замена крону - https://www.rundeck.com/,
для мониторинга крона я использовал https://deadmanssnitch.com/docs/cron-job-monitoring , https://healthchecks.io/
Все было лет пять назад, так что може быть устарело.
HealthChecks как раз первый в списке, но он observer, а надо было побольше всего.
Второй сервис тоже был, но он тоже про анализ падения, а нам на старте надо было увязать задания друг за дружкой. Алерт успешного выполнения мы уже проходили простым сообщением, человек ручками запускал следующий скрипт. А надо вебхук дернуть, хотя бы.
RunDeck посмотрел сейчас, кажется мощным оркестратором сложных интеграций, который в том числе решает вопросы с cron'ом. В первом приближении кажется, что он так же будет тяжелым для решения узкой задачи.
Бережное отношение к загрузке сервера (CPU, RAM) стояло у нас в критериях высоко. Забыл об этом упомянуть в статье.
Ну и досадный момент — опенсорс нам зарубили в какой-то момент волевым решением, пришлось решать вопросы привычным методом.
А я просто в под каждое задание держу файл с его текущим статусом.
Запущен, работает, выполнено.
И если где-то нужно, то смотрю в файл соседнего задания, чтобы дождаться нужного момента.
Также держу одно задание, независимое от кода проекта, которое контролирует эти файлы и пишет мне в телегу, если, например, в каком-то из них слишком долго "выполняется".
Это я так очень кратко логику постарался объяснить. Не знаю, никто не учил, мне вроде бы работает. Проекты тоже тяжелые достаточно. Парсинги, маркетплейсы
Классический подход, с которого все начинают. Уверен, что у вас все четко работает.
У нас ситуация была и есть гораздо сложнее: скрипты связаны друг сдругом и вариант "смотреть файл" уже не подходит, слишком много файлов, управление нужно не из консоли, а менее квалифицированным человеком и из браузера.
Если не секрет, расскажите, что ваши скрипты делают для маркетплейсов?
У меня не только для маркетплейсов, а очень много всяких разных задач
Если конкретно маркетплейсы, то например, вб - загрузили / обновили товары, через какое-то время загрузили медиа файлы (ведь задержка же), потом отправляю запросы, чтобы связать новые товары (у нас обувь и много вариантов одной модели), потом через опять же некоторое время чекаю черновики, обрабатываю и шлю менеджерам в телегу ошибки, чтобы они к следующему обмену их устранили.
Потом беру заказы из маркетплейса, отправляю в 1с, чтобы там списать остаток и не продать 2 пары.
Всё это сейчас пока на трех МП и достаточно много внутренних заданий. Контролирую всё сам. Но вы правы, уже задумывался серьезно на тем, чтобы систематизировать.
Похожая история на проекте с продуктами для животных.
Плюс минус так)
А как вы решили использовать 128 решений opensource решений и собрать их в конструктор, но при этом сказали бизнесу что не использовали opensource?) )
Или. Бизнес не выкупил разницы)?
Кто отвечает, исправляет ошибки одного из 128 решений, если что-то пошло не так? Хватает ресурсов маленькой веб-студии?
P.S.: Я понимаю что современный мир строится из кусочков наработок других, поэтому в тексте и про opensource решение несколько цепляется, противоречие. Да готовое решение и решение собранное вами это разные вещи не много, но по сути одно и тоже. Можно было форкнуть готовый проект и допилить под себя, как многие и делают.
Ну тут ответ банальный: работаем вокруг composer, который собрал все связанное зависимостями. Так устроен мир.
У бизнеса логика простая: с кого мы будем спрашивать за последствия? Надо прикрыть себя. Потому надо было свое.
А почему не сделать форк? Нам же не нужно вообще все от тех сервисов, а они развивают какую-то свою концепцию, которую мы можем не быстро раскурить. Создавая свое, мы понимаем, что именно заложено, какие идеи можно держать в голове и соломку подстелить на будущее, но на первой стадии не перегружать продукт, решить текущие задачи.
У маленьких студий есть одно важное преимущество — талатливые люди в коллективе! И по мере работы с продуктом, ресурса достаточно. А вот когда на нас свалятся тысячи установок и баг-репортов, то тут уже и расширяться начнем, решать эти новые проблемы.
Ну и просто приятно, что мы первые сделали такой продукт в РФ и засунули в Реестр Минцифры. Кто-то что-то невероятное пилит, а мы сделали одну прикольную штуку, которая решает прикладную задачу.
Как мы устали настраивать Crontab и сделали свой cron-manager