Разумно ли запускать процессы с помощью инструментов CI?

29

В моей компании мы сталкиваемся с множеством разрозненных заданий cron (на нескольких системах) и запускаем вручную процессы, которые поддерживают функционирование нашего бизнеса, что является результатом многолетнего целесообразного развития и последующего игнорирования.

Когда-нибудь нам понадобится найти более централизованное решение по очевидным причинам.

Одна мысль, которую мы обсуждали, - это использовать наше программное обеспечение для непрерывной интеграции (Jenkins) для запуска этих процессов, что кажется логичным.

Мой вопрос: делают ли это другие компании? Это общепринятая практика? Разве это не противоречит определению инструмента CI, неявному в его названии? Есть ли другие варианты?

Примечание: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins.

Дженкинс утверждает, что основное внимание уделяется «Мониторингу выполнения внешних заданий, таких как задания cron и задания procmail». Я не уверен, что это именно то, о чем я говорю.

smp7d
источник
2
Можете ли вы прояснить природу различных задач и процессов, которые вы имеете в виду?
Стивен Гросс
смесь скриптов на разных языках, процессов Java и команд Linux
smp7d
Нам нужно больше деталей. Каков характер задач? Что они делают? Как они управляются?
Стивен Гросс
@StephenGross Сбор данных из внешних систем для локального хранения, отправка уведомлений пользователям на основе бизнес-правил, проверка использования диска, удаление сирот и около тысячи других вещей. Все они управляются cron, если ими вообще управляют на данный момент. Зачем вам эти детали? Вы можете просто предположить, что они выполняют важные для бизнеса функции по расписанию.
smp7d
2
Причина, по которой мне нужны эти детали, заключается в том, что, чтобы помочь вам решить вашу проблему, мне нужно понять проблему. Хотя вы уже много знаете об этих задачах / процессах, я не знаю; Полезно понимать природу задач, которые необходимо выполнить при оценке того, какое техническое решение работает лучше всего.
Стивен Гросс

Ответы:

17

Мы использовали Дженкинса как крона в течение нескольких лет, и вот некоторые плюсы и минусы:

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 и т. Д.) ...

Дилан Кали
источник
8

Я бы сказал, что вы не используете правильный инструмент для этой работы, так как основной смысл инструментов CI заключается в том, что они отслеживают что-то - как правило, ваш исходный код - и когда происходит изменение, они запускают сборку / развертывание / что-либо еще ,

Однако эти инструменты могут запускать запланированные задания (например, TeamCity), поэтому вы можете развернуть веб-сайт (например), когда вокруг никого нет. Так что наличие единого центрального списка всех выполняемых вами задач на самом деле является хорошей идеей. Инструменты также должны позволять вам решать, когда и как часто эти задания выполняются.

Еще одним преимуществом является то, что вы даже можете контролировать систему удаленно (по желанию).

Итак, в целом, я бы сказал, что это разумно.

ChrisF
источник
Ваши чувства по этому вопросу отражают мои. Поскольку общеизвестно, что CI предназначен для сборок и тестов, я считаю его неортодоксальным решением. Другие ответы на этот вопрос определенно показали, что так оно и есть, поскольку многие видят, что это явно не тот инструмент для работы. Поскольку TeamCity может выполнять эти дополнительные задачи, любой инструмент CI, использующий проекты Maven, может выполнять множество задач. Мне все еще неудобно, что это хорошая идея.
smp7d
1
@ smp7d - согласился. Это возможное решение, но не идеальное решение.
ChrisF
6

Похоже, Cron уже является подходящим инструментом для ваших нужд. Я рекомендую вам начать с документирования вашей системы лучше. Проведите аудит различных систем и составьте исчерпывающий список того, какие процессы выполняются на каких машинах.

Затем подумайте о назначении выделенной машины для запуска всех этих процессов cron. Убедитесь, что вы задокументировали, какой это компьютер, и назначьте соответствующие права администратора для управления им. Поместите все cronjobs на эту машину, и тогда у вас будет центральная точка управления для ваших различных автоматизированных процессов.

Стивен Гросс
источник
2

Моя внутренняя реакция такая же, что вы используете инструмент, в котором есть концепция расписания, для выполнения работы планировщика заданий.

Вы не упомянули, какие у вас задания, но упоминание о CRON заставляет меня догадываться, что это сценарии оболочки и т. Д. Существуют пакеты с открытым исходным кодом и коммерческие планировщики заданий. Иногда их называют планировщиками партий. Некоторые просто закрутят CRON и сделают его более дружелюбным. Некоторые, такие как планировщик Quartz, выполняют мощное управление заданиями, но требуют их реализации в виде классов Java. Вы могли бы потенциально использовать это, и обернуть вызовы времени выполнения к вашим различным сценариям, используя обертку Java. Я верю, что вы найдете множество вариантов, если вы посмотрите дальше.

Герри
источник
Задания представляют собой смесь сценариев на разных языках, процессов Java и команд Linux. Один только Кварц не даст мне управление внешним интерфейсом / сборкой, которое обеспечил бы Дженкинс, и я не хочу строить все это. Я не удивлюсь, если Дженкинс использует Кварц за кулисами. Я проверю этот Кварцевый менеджер, хотя ( terracotta.org/products/quartz-scheduler ).
smp7d
2

Не используйте CI для запуска периодических задач, не связанных со сборкой.

Также избегайте использования cron для задач, не связанных с обслуживанием системы.

Используйте правильные инструменты. Для нужд приложения - попробуйте использовать решения на основе AMQP.

PS Я вижу, что cron подходит для вашего случая. С другой стороны, у вас много задач - поэтому попробуйте написать приложение для них.

Николай Фоминых
источник
1
Спасибо за ответ. Можете ли вы описать, что вы подразумеваете под «приложением супервизора»?
smp7d
В двух словах - это supervisord.org . Мета-программа, которая контролирует состояние и выполнение других процессов. Вы можете легко разработать собственное решение, которое будет соответствовать вашим потребностям. У меня есть группа периодических заданий в моем проекте, и github.com/ask/django-celery помогает мне выбраться из cron.
Николай Фоминых
Спасибо, я посмотрю в Supervisor. Цель использования инструмента CI состояла в том, чтобы помешать нам писать собственный инструмент. Инструмент CI гладкий, как уже может быть.
smp7d
1
Думаю, у меня нет представителя, чтобы проголосовать за это, но это довольно ужасный ответ - позор, он получил награду. Что делает инструмент «правильным инструментом»? Даже если в нем есть все необходимые компоненты, это «неправильный инструмент», потому что он называется системой CI?
DougW
1

Для этого типа задач необходимо использовать служебную служебную шину (ESB).

Теперь мой фон находится в windows / BizTalk, но я уверен, что все эквиваленты существуют и на стороне Unix. Что мы обычно делаем, это настраиваем процессы на блоке BizTalk, которые будут отвечать за запуск элементов на другом блоке, отслеживать ход выполнения / ошибки и сообщать о состоянии на портале SharePoint (или в Интернете) или отправлять электронные письма и такой, если это требует внимания.

Преимущества этого подхода в том, что все настройки и управление различными бизнес-процессами расположены в центре, поэтому вы знаете, с чего начать. Программное обеспечение уже существует, которое позволяет вам абстрагировать часть кода от физического конфига (в BizTalk вы можете программировать для логического «порта», такого как сервер SQL, а затем в Prod, если окно SQL изменяет местоположение или обновляется или что-то еще, вы можете изменить настроенный физический порт, используя инструмент администратора, опять же, я уверен, что эквиваленты существуют на стороне Unix).

Преимущества по сравнению с использованием инструментов CI заключаются в том, что, если в результате процесса вы можете автоматически выполнить физическую отправку сообщений и настроить кластерную среду отработки отказа, имея более подходящую систему записи и ведения журнала; Кроме того, как только система будет установлена, это позволит вам начать разработку архитектуры вашей организации или лучше использовать SOA. Недостатком является то, что в зависимости от размера вашей организации усилия по разработке могут быть высокими, а затраты на лицензирование могут быть чрезмерно высокими.

туз в рукаве
источник
Возможно, это применимо, но я не уверен, что это больше случай применения неправильного инструмента, как CI. У меня сложилось впечатление, что ESB будет использоваться, когда необходима коммуникация или процессная хореография. В этом случае нам просто нужно централизованное управление массивом автономных процессов. Мы хорошо выполняем пользовательские команды linux через центральное управление, поэтому любой агностицизм в отношении ОС / языка программирования, вероятно, излишний. Это, наверное, стоит посмотреть, спасибо.
smp7d
Если вы работаете в Unix-магазине, определенно соглашайтесь с этим, я знаю, что у IBM есть продукт в своей линейке веб-сфер, а также есть коммерческие веб-методы, и у appache есть предложение с открытым исходным кодом; Вы правы в смысле своего определения ESB, к сожалению, ESB стал несколько неоднозначным в его использовании, но подумайте, хотите ли вы в конечном итоге добавить централизованные отчеты об ошибках или какие-либо виды отчетности, такие как «сработал ли он» в вашем процессе, хореография.
aceinthehole
@ smp7d Я знаю, что у сервера интеграции webMethods есть поддержка планирования первого класса. Работает хорошо.
Роберт Грант
1

Теоретически, для вас имеет смысл иметь единственное место для управления всеми несопоставимыми заданиями, однако, исходя из отраслевого опыта, подобного «Святому Граалю», вам понадобятся задания cron здесь, сценарии bash там и сценарии cli здесь.

Существует также мантра «Если это не сломано, не чините это», поэтому, пока они идут, сначала сосредоточьтесь на документировании того, какие скрипты у вас работают, что они делают и какие системы они касаются, чтобы вы «знали» "Как работает ваш бизнес.

Затем, в качестве долгосрочной стратегии, настройте централизованную систему для выполнения заданий, выбирайте свое решение с умом, потому что вам придется с ним жить. Затем для каждого запроса на изменение, улучшения, обновления, исправления ошибки или нового решения, которое вы добавляете в свою бизнес-архитектуру, убедитесь, что его запланированные и автоматизированные задачи добавлены в ваше «решение для управления предприятием».

Таким образом, вы постепенно переходите от пакета сценариев к более корпоративной среде.

Стивен Сенкомаго Мусоке
источник
Это хорошие мысли. Итак, вы думаете, что то, что я ищу, не существует и что инструмент КИ не является разумной альтернативой?
smp7d
Он может существовать, но прагматизм в отношении того, что вы используете, может привести к тому, что у вас останутся задания cron и сценарии bash. Однако использование вашей среды CI может стать препятствием позже, потому что CI в первую очередь предназначен для рабочих процессов разработки, но по мере развития среды вы ищете решения, связанные с операциями. Позже вы можете решить перенести свой контроль версий / CI в облако, и вы не хотите, чтобы это застопорилось из-за того, что в вашей организации выполняются повседневные операции.
Стивен Сенкомаго Мусоке
Ну, мы думали, что будем использовать отдельный инструмент CI для управления процессами, но я понимаю, что вы говорите.
smp7d
Поскольку вы рассматриваете отдельный CI, почему бы не взглянуть на инструменты, ориентированные на управление процессами, мониторинг и отчетность. Таким образом, вы используете усилия по настройке CI для получения правильного инструмента для работы, если он не работает, у вас есть CI, к
которому можно прибегнуть
Я согласен, что это самый разумный путь. Кварцевый планировщик, supervisord.org и ESB были рекомендованы. Есть ли у вас какие-либо дополнительные рекомендации или мысли по этому поводу? (также: когда я сказал отдельный CI, я просто имел в виду еще одну установку нашего текущего инструмента с, возможно, некоторой новой маркировкой ... настройка не была бы проблемой)
smp7d
0

В крупных корпоративных системах, с которыми я работал, они обычно используют инструмент, предназначенный для планирования. Самый популярный, который я использовал, это CA7. Это позволяет вам централизовать все планирование для всех ваших систем.

Cron обычно используется для одной машины, хотя вы можете «взломать» ее, выполнив удаленные вызовы ssh. Однако у него не будет понятия зависимостей и прочего. Когда дело доходит до рабочих групп, где сфера их применения еще более ограничена, лучше всего использовать инструмент.

Архимед Траяно
источник
Ваша рекомендация привела меня к этому ... en.wikipedia.org/wiki/Job_scheduler - Удивительно, но никто никогда не упоминал это название для такого инструмента. Это может быть то, что я искал, как будто он предназначен для того, чтобы делать то, что я ищу, время, вероятно, покажет, что он делает это лучше, чем инструмент CI. Для подтверждения этого потребуется некоторое исследование.
smp7d