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