В моей компании мы сталкиваемся с множеством разрозненных заданий cron (на нескольких системах) и запускаем вручную процессы, которые поддерживают функционирование нашего бизнеса, что является результатом многолетнего целесообразного развития и последующего игнорирования.
Когда-нибудь нам понадобится найти более централизованное решение по очевидным причинам.
Одна мысль, которую мы обсуждали, - это использовать наше программное обеспечение для непрерывной интеграции (Jenkins) для запуска этих процессов, что кажется логичным.
Мой вопрос: делают ли это другие компании? Это общепринятая практика? Разве это не противоречит определению инструмента CI, неявному в его названии? Есть ли другие варианты?
Примечание: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins.
Дженкинс утверждает, что основное внимание уделяется «Мониторингу выполнения внешних заданий, таких как задания cron и задания procmail». Я не уверен, что это именно то, о чем я говорю.
Ответы:
Мы использовали Дженкинса как крона в течение нескольких лет, и вот некоторые плюсы и минусы:
Pros
Если вы управляете большим количеством процессов на десятках серверов и в нескольких средах, это облегчает многие вещи. Вы получаете уведомления по электронной почте «из коробки», общую панель для всего, веб-интерфейс для журналов и простой способ настроить дополнительные узлы для выполнения заданий. Служба поддержки особенно ценит это центральное расположение для проверки проблем и повторного запуска работ.
Экосистема плагинов Jenkins очень активна и предоставляет множество дополнительных функций ... Я думаю, что это действительно «убийственная» функция Jenkins, поскольку, если Jenkins сам не обеспечивает то, что вы ищете (часто так), больше часто чем не существует плагин, который делает. Некоторые из моих любимых: Cron Column, Rebuild, NodeLabel Parameter, Log Parser и Email-ext.
Расширенная поддержка планирования / триггера. Синтаксис расписания в основном cron, поэтому у вас есть такая же гибкость, но он дополняется триггерами, REST API и Groovy / Java API
Cons
Центральная точка отказа: потому что все ваши задания запускаются одним сервером, если этот ящик отключается и никто не замечает, большие проблемы. Так что вам лучше иметь хороший мониторинг для немедленного обнаружения перебоев, а также все ваши конфигурации, сохраненные в системе контроля версий. Даже если вы не можете восстановить исходный сервер, пока у вас есть настройки вашей работы, просто настроить их где-то еще. Если время до разрешения является проблемой, вероятно, хорошей идеей будет также то, чтобы где-то предварительно настроить резерв.
Если у вас несколько сред (Dev, UAT, Prod), обычно у вас есть несколько разные версии задания, выполняемые в каждой среде. Наличие всех этих заданий на одном Дженкинсе может стать громоздким, и их ручная настройка становится огромной болью. В нашем случае мы запускаем отдельный экземпляр Jenkins 'Cron' для каждой среды. Экземпляры устанавливаются и настраиваются автоматически с помощью внутреннего инструмента развертывания. Вы можете не иметь ничего подобного, но есть инструменты с открытым исходным кодом, которые делают подобные вещи (генерируют конфиги с помощью шаблонов). Если вы можете решить проблему с генерацией конфигурации, это значительно упростит настройку и развертывание Jenkins, а также упростит управление всеми вашими ресурсами в системе контроля версий.
Обновление Jenkins иногда нарушает функциональность, особенно с помощью плагинов. Не обновляйте критически важный экземпляр Jenkins, пока не попробуете новую версию где-то еще. Именно здесь очень удобна зеркальная среда разработки с собственным экземпляром Jenkins.
Следует подчеркнуть одну вещь: мы действительно используем Jenkins для CI, но это отдельный экземпляр ... экземпляры cron предназначены для управления заданиями, а экземпляр CI - для CI. Разделение проблем, кажется, делает вещи чище.
В качестве примечания, я использую Jenkins вместо cron на своей Linux-машине дома :)
Кстати, это на самом деле довольно распространенный случай использования Jenkins. Например, Sandia National Lab использует Jenkins следующим образом: https://software.sandia.gov/trac/fast/wiki/Hudson
И есть многочисленные сообщения в блоге и учебники, описывающие это. Вот несколько примеров: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/
http://morgajel.net/2011/12/12/1108
Я должен также добавить, что это действительно относится только к Дженкинсу, а не ко всем инструментам CI в целом. Тот факт, что Jenkins хорошо подходит для этого, не означает, что другие (TeamCity, buildbot и т. Д.) ...
источник
Я бы сказал, что вы не используете правильный инструмент для этой работы, так как основной смысл инструментов CI заключается в том, что они отслеживают что-то - как правило, ваш исходный код - и когда происходит изменение, они запускают сборку / развертывание / что-либо еще ,
Однако эти инструменты могут запускать запланированные задания (например, TeamCity), поэтому вы можете развернуть веб-сайт (например), когда вокруг никого нет. Так что наличие единого центрального списка всех выполняемых вами задач на самом деле является хорошей идеей. Инструменты также должны позволять вам решать, когда и как часто эти задания выполняются.
Еще одним преимуществом является то, что вы даже можете контролировать систему удаленно (по желанию).
Итак, в целом, я бы сказал, что это разумно.
источник
Похоже, Cron уже является подходящим инструментом для ваших нужд. Я рекомендую вам начать с документирования вашей системы лучше. Проведите аудит различных систем и составьте исчерпывающий список того, какие процессы выполняются на каких машинах.
Затем подумайте о назначении выделенной машины для запуска всех этих процессов cron. Убедитесь, что вы задокументировали, какой это компьютер, и назначьте соответствующие права администратора для управления им. Поместите все cronjobs на эту машину, и тогда у вас будет центральная точка управления для ваших различных автоматизированных процессов.
источник
Моя внутренняя реакция такая же, что вы используете инструмент, в котором есть концепция расписания, для выполнения работы планировщика заданий.
Вы не упомянули, какие у вас задания, но упоминание о CRON заставляет меня догадываться, что это сценарии оболочки и т. Д. Существуют пакеты с открытым исходным кодом и коммерческие планировщики заданий. Иногда их называют планировщиками партий. Некоторые просто закрутят CRON и сделают его более дружелюбным. Некоторые, такие как планировщик Quartz, выполняют мощное управление заданиями, но требуют их реализации в виде классов Java. Вы могли бы потенциально использовать это, и обернуть вызовы времени выполнения к вашим различным сценариям, используя обертку Java. Я верю, что вы найдете множество вариантов, если вы посмотрите дальше.
источник
Не используйте CI для запуска периодических задач, не связанных со сборкой.
Также избегайте использования cron для задач, не связанных с обслуживанием системы.
Используйте правильные инструменты. Для нужд приложения - попробуйте использовать решения на основе AMQP.
PS Я вижу, что cron подходит для вашего случая. С другой стороны, у вас много задач - поэтому попробуйте написать приложение для них.
источник
Для этого типа задач необходимо использовать служебную служебную шину (ESB).
Теперь мой фон находится в windows / BizTalk, но я уверен, что все эквиваленты существуют и на стороне Unix. Что мы обычно делаем, это настраиваем процессы на блоке BizTalk, которые будут отвечать за запуск элементов на другом блоке, отслеживать ход выполнения / ошибки и сообщать о состоянии на портале SharePoint (или в Интернете) или отправлять электронные письма и такой, если это требует внимания.
Преимущества этого подхода в том, что все настройки и управление различными бизнес-процессами расположены в центре, поэтому вы знаете, с чего начать. Программное обеспечение уже существует, которое позволяет вам абстрагировать часть кода от физического конфига (в BizTalk вы можете программировать для логического «порта», такого как сервер SQL, а затем в Prod, если окно SQL изменяет местоположение или обновляется или что-то еще, вы можете изменить настроенный физический порт, используя инструмент администратора, опять же, я уверен, что эквиваленты существуют на стороне Unix).
Преимущества по сравнению с использованием инструментов CI заключаются в том, что, если в результате процесса вы можете автоматически выполнить физическую отправку сообщений и настроить кластерную среду отработки отказа, имея более подходящую систему записи и ведения журнала; Кроме того, как только система будет установлена, это позволит вам начать разработку архитектуры вашей организации или лучше использовать SOA. Недостатком является то, что в зависимости от размера вашей организации усилия по разработке могут быть высокими, а затраты на лицензирование могут быть чрезмерно высокими.
источник
Теоретически, для вас имеет смысл иметь единственное место для управления всеми несопоставимыми заданиями, однако, исходя из отраслевого опыта, подобного «Святому Граалю», вам понадобятся задания cron здесь, сценарии bash там и сценарии cli здесь.
Существует также мантра «Если это не сломано, не чините это», поэтому, пока они идут, сначала сосредоточьтесь на документировании того, какие скрипты у вас работают, что они делают и какие системы они касаются, чтобы вы «знали» "Как работает ваш бизнес.
Затем, в качестве долгосрочной стратегии, настройте централизованную систему для выполнения заданий, выбирайте свое решение с умом, потому что вам придется с ним жить. Затем для каждого запроса на изменение, улучшения, обновления, исправления ошибки или нового решения, которое вы добавляете в свою бизнес-архитектуру, убедитесь, что его запланированные и автоматизированные задачи добавлены в ваше «решение для управления предприятием».
Таким образом, вы постепенно переходите от пакета сценариев к более корпоративной среде.
источник
В крупных корпоративных системах, с которыми я работал, они обычно используют инструмент, предназначенный для планирования. Самый популярный, который я использовал, это CA7. Это позволяет вам централизовать все планирование для всех ваших систем.
Cron обычно используется для одной машины, хотя вы можете «взломать» ее, выполнив удаленные вызовы ssh. Однако у него не будет понятия зависимостей и прочего. Когда дело доходит до рабочих групп, где сфера их применения еще более ограничена, лучше всего использовать инструмент.
источник