Упавший скрипт меня не пугает. Он падает, крон пишет в лог, в телеграм прилетает ошибка, я иду чинить. Неприятно, но честно.
Пугает другое. Скрипт, который каждое утро бодро отчитывается «статей к проверке: 30», месяцами работает и месяцами обрабатывает не те данные.
Выражение */15 9-17 * * 1-5 компьютер понимает однозначно, а человек читает с трудом. Особенно это мешает, когда расписание задаёт пользователь: в боте‑напоминалке, в админке, в настройках отчётов. Человек хочет написать «каждые 15 минут с 9 до 18 по будням» и увидеть, что его поняли правильно. Писать для этого форму с пятью выпадающими списками не хочется никому.
Готовых решений для русского языка я не нашёл, поэтому написал своё.
Библиотека называется cronsense. Она переводит расписание, записанное обычными словами на русском или английском, в cron‑выражение и обратно:
Читать полностью »
Лёгкий cron, интервалы и очередь фоновых задач для Ruby-приложений на Async — без Redis, без Postgres, без отдельного процесса.
История началась с прозаичного: у меня было Falcon-приложение на Async, и в нём накопились задачи, которые надо было выполнять где-то рядом. Раз в минуту синхронизировать каталог. В 3:00 — отчёт. На действие пользователя — отправить письмо «через 5 минут после регистрации, если он не подтвердил почту».
Классический набор. Классический ответ — Sidekiq. Я открыл Gemfile, набрал gem "sidekiq"Читать полностью »
Но очень быстро оказывается, что настоящая сложность не в самих задачах, а в инфраструктуре вокруг них.
Сначала хочется просто запускать код в фоне. Потом появляются ретраи, таймауты, логирование, контроль выполнения. Ещё чуть позже всплывают совсем неприятные вопросы: что делать с пропущенными запусками после рестарта, как не дублировать задачи и где вообще должна жить логика планирования.
В какой-то момент становится очевидно:
ты уже пишешь не задачи, а pipeline вокруг задач
Именно в этот момент мне перестало хватать привычных инструментов.
Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.
Один сервер использует PostgreSQL, другой — MySQL, третий — MongoDB, и для каждого нужны свои команды (pg_dump, mysqldump, mongodump) и свои скрип��ы.
Проект Dumper решает эту проблему он объединяет все типы баз в один универсальный инструмент.
Dumper написан на Go и работает через CLI, конфигурация задаётся в YAML — поэтому его легко встроить в cron, CI/CD pipelines, GitHub Actions или Docker-окружение.
Хочу поделиться с сообществом простым и полезным шаблоном скрипта-обёртки на bash для запуска заданий по cron (а сейчас и systemd timers), который моя команда повсеместно использует много лет.
Прим. перев.: эту статью, в оригинале состоящую из двух частей, написал Kevin Yang — software engineer из компании Lyft, которая хорошо известна в Kubernetes-сообществе как минимум благодаря созданию Envoy. В новом материале автор делится интересным опытом миграции большого числа традиционных cron-задач из Linux на CronJobs в K8s. Можно в деталях узнать о том, к каким проблемам в масштабах Lyft это привело и как они были решены инженерами компании.
Мы в Lyft решили перевести серверную инфраструктуру на Kubernetes — распределенную систему оркестровки контейнеров, — чтобы воспользоваться преимуществами, которые предлагает автоматизация. Хотели получить прочную и надежную платформу, способную стать фундаментом для дальнейшего развития, а также снизить общие затраты, одновременно повысив эффективность.
Распределенные системы могут быть сложны для понимания и анализа, и в этом смысле Kubernetes — не исключение. Несмотря на его многочисленные преимущества, мы выявили несколько проблемных моментов при переходе на CronJob — встроенную в Kubernetes систему для выполнения повторяющихся задач по расписанию. В этом цикле из двух статей мы обсудим технические и эксплуатационные недостатки Kubernetes CronJob при использовании в крупном проекте и поделимся с вами опытом их преодоления.Читать полностью »
