Serverless cron-задачи на VPS без голого crontab
Перенесите cron-задачи с сырого crontab на VPS на serverless-пайплайны по расписанию: история запусков, ретраи, изолированные контейнеры и те же секреты и логи, что у HTTP-функций.
Обновлено: 2026-06-28
Кратко
Суть ответа
Serverless cron-задачи на VPS без голого crontab. Это не «ещё один красивый таймер»: каждый запуск — управляемая serverless-функция в изолированном контейнере по правилам cron пайплайна, с теми же маршрутизацией, секретами и наблюдаемостью, что у синхронных HTTP-хендлеров.
Когда подходит и когда нет
- Выросли из голого crontab на VPS и хотите serverless cron с версиями, изоляцией и историей рядом с HTTP.
- Нужен паритет «работа по API» и «работа по часам» в одном продукте.
На что обратить внимание
- Таймеры помогают с надёжностью запуска, но упаковка, формат логов и раздача секретов остаются на вас.
- CronJob в Kubernetes силён, но тяжёл, если кластер не основа стека.
Ситуация: нагрузка и где обычно ломается
Проблемы cron-задач на VPS
- Голый crontab: мало структурированной истории запусков, логи собираются по SSH, одна общая среда для всех задач.
- systemd timers: надёжнее старт, но упаковка, формат логов и раздача секретов остаются на вас.
- Пайплайны Inquir по расписанию: serverless cron с изолированными запусками, ретраями, историей и общими примитивами с HTTP-хендлерами.
Cron-задачи на VPS живут, пока кто-то помнит, какой интерпретатор крутился «в прошлый вторник» и почему вывод пропал после ротации syslog. Перенос повторяющейся работы с машины в serverless-модель для расписаний даёт версионируемые деплои и аудит в продукте вместо grep по сессиям.
Записи crontab к тому же живут вне контроля версий: расписание, версия скрипта и окружение тихо расходятся, пока никто уже не может воспроизвести то, что реально работает в проде.
Когда все задачи делят одного пользователя ОС и один Python, безобидный отчёт может сломать зависимости финансового экспорта.
Компромиссы
Почему ломаются crontab и systemd timers
Таймеры помогают с надёжностью запуска, но упаковка, формат логов и раздача секретов остаются на вас.
CronJob в Kubernetes силён, но тяжёл, если кластер не основа стека.
Как Inquir помогает в этом сценарии
Как устроены serverless cron-задачи в Inquir
Это не «ещё один красивый таймер»: каждый запуск — управляемая serverless-функция в изолированном контейнере по правилам cron пайплайна, с теми же маршрутизацией, секретами и наблюдаемостью, что у синхронных HTTP-хендлеров.
При сохранении пайплайна cron-строка проверяется — опечатки видны сразу, а не как тихий провал. Планировщик помнит следующий запуск на пайплайн и будит вовремя; смена выражения переносится аккуратно.
Планировщик опрашивает каждые 30 секунд и требует минимум 5 минут между запусками — закладывайте задачи раз в несколько минут и реже; срабатывание может отстать на ~30с, в отличие от таймера на уровне ядра ОС.
Что вы получаете на платформе
Плюсы управляемых cron-пайплайнов
Изолированные запуски по задаче
Каждая задача выполняется в своём контейнере, поэтому конфликты зависимостей и эффекты на файловой системе не выходят за её пределы.
Те же секреты и логи, что у HTTP
Задачи по расписанию используют ту же модель секретов и логов, что и HTTP-хендлеры, — без параллельного самодельного стека на VPS.
Составные пайплайны после cron
Цепляйте продолжение, когда задача по расписанию должна разветвиться или уйти в более длинный фон.
Что сделать дальше, по шагам
Как перенести cron-задачи с VPS в Inquir
Каждую бывшую строку crontab оформите как serverless-хендлер и триггер расписания — запуски уходят из shell на VPS в историю выполнения рядом с остальной платформой.
Реализовать хендлер
Опишите логику задачи с явными входами из переменных окружения.
Создать триггер расписания
Укажите тип триггера schedule и cron-выражение, которое принимает API.
Наблюдать за запусками
Следите за длительностью и ошибками, пока они не превратились в тихие провалы в данных.
Пример кода
Crontab → Inquir: пример миграции
Замените строку crontab на версионируемый serverless-хендлер. Функция получает событие пайплайна с метаданными триггера; секреты — те же, что у HTTP-функций.
# VPS crontab — runs as a system user, logs to /var/log, shares one Python env 0 2 * * * node /opt/app/scripts/sync-customers.js >> /var/log/sync.log 2>&1
export async function handler(event) { // event.pipeline, event.step, event.trigger provided by the scheduler const since = process.env.LAST_SYNC_CURSOR ?? new Date(Date.now() - 86_400_000).toISOString(); const batch = await fetchCustomers({ updatedSince: since }); for (const customer of batch) { await syncToDestination(customer); } return { synced: batch.length }; }
Когда подходит и когда нет
Когда переносить cron с VPS
Когда это уместно
- Выросли из голого crontab на VPS и хотите serverless cron с версиями, изоляцией и историей рядом с HTTP.
- Нужен паритет «работа по API» и «работа по часам» в одном продукте.
Когда лучше выбрать другое
- Нужен планировщик с точностью долей секунды по всему миру — это другой класс задач.
Вопросы и ответы
Вопросы и ответы
Это Linux crontab?
Нет — расписание на уровне приложения через пайплайны Inquir; cron в продукте, контейнеры на запуске.
Как разбирать сбой запуска?
Откройте историю вызовов функции, стоящей за шагом пайплайна: там видны payload, логи и тайминги реального запуска — куда проще, чем сверять таймстемпы syslog по SSH.
Могут ли фоновые задачи вызывать HTTP того же продукта?
Да — при необходимости вызывайте шлюз или другие функции.