Плохая практика - использовать CI-сервер для cron / запланированных задач
Считается ли плохой практикой использование чего-то вроде Jenkins или Gitlab CI Pipelines для замены заданий cron?
Есть Я могу придумать два недостатка: предоставление серверу CI доступа ко всем серверам и наличие единой точки отказа (если сервер CI не работает, запланированные задачи не могут выполняться).
Обычно задания cron, выполняемые на серверах нашего примера, связаны в репозиторий git.
Это сделано с целью избавить разработчиков от необходимости подключаться к серверам для проверки и / или управления сбоями crons и cron, а также для возможности управлять ими из одного центра.
Не лучше ли поместить это в инструмент управления конфигурацией (Puppet / Salt / Chef / ansible)?
Примите собственные проектные решения относительно инструментов для решения проблем. Единого ответа нет, есть только выбор между различными компромиссами.
Никто не должен получать оболочку, но некоторые задания cron необходимо контролировать. Итак, напишите автоматизацию для установки и проверки заданий cron на каждом хосте. Поддерживайте автоматизацию в системе контроля версий и запускайте ее через CI.
Доступность и производительность CI-сервера могут быть проблемой. Решите эту проблему, внедрив высокую доступность и увеличивая масштабирование.
cron — это базовый планировщик, и хотя он надежно запускает задания каждую минуту, его возможности ограничены. Рассмотрите возможность внедрения системы с дополнительными функциями, включая ведение журнала и диагностику.