Чи розумно запускати процеси за допомогою інструментів CI?

29

У моїй компанії у нас є трясовина різної роботи з крон (на кількох системах) і вручну розпочали процеси, які підтримують наш бізнес, який є результатом багаторічного розвитку та подальшого нехтування.

Колись нам потрібно буде придумати більш централізоване рішення з очевидних причин.

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

Моє запитання: чи роблять це інші компанії? Це загальноприйнята практика? Чи це не суперечить визначенню інструмента CI, який міститься в його назві? Чи є інші варіанти?

Примітка: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Дженкінс стверджує, що фокусується на "Моніторингу виконання завдань, що виконуються зовні, наприклад, робочих місць під керуванням та прокрутки робочих місць". Я не впевнений, чи саме про це я говорю.

continuous-integration cron

— smp7d
джерело

2

Чи можете ви уточнити природу різних завдань та процесів, які ви маєте на увазі?

— Стівен Гросс

суміш сценаріїв на різних мовах, java-процеси та команди Linux

— smp7d

Нам потрібно детальніше. Яка природа завдань? Що вони роблять? Як їм керувати?

— Стівен Гросс

@StephenGross Зберіть дані із зовнішніх систем для локального зберігання, надсилайте сповіщення користувачам на основі правил бізнесу, перевіряйте використання диска, видаляйте сиріт та близько тисячі інших речей. Всіма ними керує cron, якщо ними взагалі керують у цей момент. Навіщо потрібні ці деталі? Можна просто припустити, що вони виконують важливі для бізнесу функції за графіком.

— smp7d

2

Причина, що мені потрібні ці деталі, полягає в тому, що для того, щоб допомогти вам у вирішенні вашої проблеми, мені потрібно зрозуміти проблему. Хоча ви вже багато знаєте про ці завдання / процеси, я не знаю; корисно зрозуміти природу завдань, які необхідно виконати, оцінюючи, яке технічне рішення найкраще працює.

— Стівен Гросс

17

Ми вже кілька років використовуємо Дженкінса в якості крона, і ось кілька плюсів і мінусів:

Плюси

Якщо ви керуєте великою кількістю процесів на десятках серверів і в декількох середовищах, це полегшує багато речей. Ви отримуєте сповіщення електронною поштою з вікна, загальну інформаційну панель для всього, веб-інтерфейс для журналів та простий спосіб налаштування додаткових вузлів для запуску завдань. Команди підтримки особливо цінують наявність цього центрального місця для перевірки проблем та повторного запуску завдань.
Екосистема плагінів Дженкінса дуже активна і забезпечує безліч додаткових функціональних можливостей ... Я думаю, що це дійсно функція вбивці Дженкінса, оскільки якщо сам Дженкінс не надасть того, що ви шукаєте (часто буває), більше найчастіше є плагін, який є. Деякі з моїх улюблених: Cron Column, Rebuild, NodeLabel Parameter, Log Parser та Email-ext.
Розширена підтримка планування / тригера: синтаксис розкладу в основному є cron, тому у вас є однакова гнучкість, але це доповнюється тригерами, API REST та API Groovy / Java

Мінуси

Центральна точка відмови: Оскільки всі ваші завдання починаються одним сервером, якщо це поле знижується, і ніхто цього не помічає, Велика біда. Таким чином, вам краще мати хороший моніторинг, щоб негайно відключити відключення, а також всі ваші конфігурації, збережені в контролі джерел. Навіть якщо ви не можете створити резервну копію оригінального сервера, доки у вас є конфігурація вашої роботи, тривожно налаштувати їх на інше місце. Якщо час на вирішення проблеми викликає занепокоєння, мабуть, хороша ідея також мати попередньо налаштований режим очікування десь.
Якщо у вас є декілька середовищ (Dev, UAT, Prod), зазвичай у вас є дещо різні версії роботи, що виконуються в кожному середовищі. Отримати всі ці завдання на одному Дженкінсі може бути невміло, і налаштувати їх вручну стає великим болем. У нашому випадку ми запускаємо окремий екземпляр Jenkins 'Cron' для кожного середовища. Екземпляри встановлюються та налаштовуються автоматично за допомогою внутрішнього інструменту розгортання. У вас може не бути подібного, але є інструменти з відкритим кодом, які роблять подібні речі (генерують конфігурації за допомогою шаблонів). Якщо ви можете вирішити проблему з генерацією конфігурацій, це значно спрощує налаштування та розгортання Дженкінса, а також полегшує збереження всіх ваших речей у контролі джерела.
Оновлення Дженкінса іноді порушує функціональність, особливо з плагінами. Не модернізуйте критичний екземпляр Дженкінса, поки ви не спробуєте нову версію десь в іншому місці. Тут дуже зручно мати дзеркальне середовище Dev із власним екземпляром Jenkins.

Можливо, підкреслимо одне: ми дійсно також використовуємо Дженкінса для CI, але це окремий екземпляр ... екземпляри 'cron' призначені для управління роботою, а екземпляр 'CI' призначений для CI. Розділення проблем, схоже, робить речі більш чистими.

В якості побічної записки я вдома використовую Дженкінс замість крона на своїй скриньці Linux :)

До речі, це насправді досить поширений випадок використання Дженкінса. Наприклад, Національна лабораторія Sandia використовує Дженкінса таким чином: 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 взагалі. Тільки тому, що Дженкінс добре підходить для цього, не означає, що інші (TeamCity, buildbot тощо) - це ...

— Ділан Калі
джерело

8

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

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

Ще одна перевага полягає в тому, що ви навіть можете віддалено контролювати систему (якщо хочете).

Отже, я б сказав, що це було розумно робити.

— ChrisF
джерело

Ваші почуття з цього приводу відображають моє. Оскільки CI, як відомо, розробляє і тестує, я вважаю це неортодоксальним рішенням. Інші відповіді на це питання, безумовно, показали, що так і є, тому що багато хто вважає це очевидно неправильним інструментом для роботи. Оскільки TeamCity може виконувати ці додаткові завдання, будь-який інструмент CI, що використовує проекти Maven, може робити будь-яку кількість речей. Мені все ще незручно, що це гарна ідея.

— smp7d

1

@ smp7d - погодився. Це можливе рішення, але не ідеальне рішення.

— ChrisF

6

Здається, що cron - це вже відповідний інструмент для ваших потреб. Рекомендую почати з того, щоб краще документувати систему. Проведіть аудит різних систем і складіть вичерпний перелік процесів, на яких працюють машини.

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

— Стівен Гросс
джерело

2

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

Ви не згадали, якими є ваші робочі місця, але ваша згадка про CRON змушує мене здогадуватися, що це сценарії оболонки і т. Д. Є пакети з відкритим кодом та комерційним планувальником роботи. Іноді їх називають планувальниками пакетів. Деякі просто загортають CRON і роблять це дружнішим. Деякі, як планувальник Quartz, мають потужне управління роботами, але вимагають їх реалізації як класи Java. Ви потенційно можете це використовувати і завершувати дзвінки під час виконання різних сценаріїв, використовуючи обгортку Java. Я вірю, що ви знайдете безліч варіантів, якщо заглянете далі.

— Партизанка
джерело

Завдання - це суміш сценаріїв на різних мовах, java-процеси та команди Linux. Кварц сам по собі не дасть мені управління на передній частині / побудові, яке б забезпечив Дженкінс, і я не хочу все це будувати. Я не був би здивований, якщо Дженкінс використовує кварц за кадром. Я перевіряю цього Кварцевого менеджера ( terracotta.org/products/quartz-scheduler ).

— smp7d

2

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

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

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

PS Я бачу, що цей крон підходить для вашої справи. З іншого боку, у вас дуже багато завдань - тому спробуйте написати для них додаток керівника.

— Миколи Фоминих
джерело

1

Дякую за відповідь. Чи можете ви описати, що ви маєте на увазі під наглядом програми?

— smp7d

У двох словах - це supervisord.org . Мета-програма, яка контролює стан та виконання інших процесів. Ви можете легко розробити власне рішення, яке відповідатиме вашим потребам. Я маю групу періодичних завдань у своєму проекті, і github.com/ask/django-celery допомагає мені вибратися з cron.

— Микола Фоміних

Дякую, я загляну в Супервізор. Метою використання інструмента CI було не допустити, щоб нам потрібно було написати власний інструмент. Інструмент CI гладкий, як це вже можливо.

— smp7d

1

Гадаю, у мене немає представника, щоб проголосувати це, але це дуже жахлива відповідь - ганьба, що це отримало щедрість. Що робить інструмент «правильним інструментом»? Навіть якщо в ньому є саме всі необхідні компоненти, це "неправильний інструмент", оскільки його називають системою CI?

— DougW

1

Для цього типу завдань потрібно використовувати службову шину обслуговування (ESB).

Зараз моя передумова в Windows / BizTalk, але я впевнений, що всі еквіваленти існують і на стороні Unix. Зазвичай ми налаштовуємо процеси на вікні BizTalk, які відповідають за перенесення речей в інше вікно, контроль за ходом / помилками та повідомлення про стан на порталі SharePoint (або веб), або надсилання електронних листів та такі, якщо вона потребує уваги.

Переваги цього підходу полягають у тому, що вся конфігурація та управління вашими різними бізнес-процесами розташовані в центрі міста, тож ви знаєте, з чого почати шукати. Програмне забезпечення вже існує, яке дозволяє абстрагувати частину кодування з фізичної конфігурації (у BizTalk ви можете запрограмувати логічний 'порт', як сервер sql, а потім у prod, якщо поле sql змінює місцеположення або оновлено чи будь-що інше, ви можна змінити налаштований фізичний порт за допомогою інструмента адміністратора, знову ж таки, я впевнений, що еквіваленти існують на стороні Unix).

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

— ацеінтехоле
джерело

Можливо, це застосовно, але я не впевнений, що це більше випадки застосування неправильного інструменту, як це було б. Моє враження, що ESB буде використовуватися тоді, коли потрібна комунікація або хореографія процесу. У цьому випадку ми просто хочемо центрального управління для масиву автономних процесів. Ми прекрасно виконуємо власні команди Linux, хоча центральне управління, тому будь-який агностицизм ОС / Мова програмування, ймовірно, є надмірним. Це, мабуть, варто вивчити, хоча, дякую.

— smp7d

Якщо ви є крамницею Unix, безумовно, виходите з цим, я знаю, що IBM має продукт у своїй лінії веб-сфери, а також є веб-методи, котрі є комерційними, а в appache є пропозиція з відкритим кодом; ви маєте рацію в сенсі свого визначення ESB, на жаль, ESB став дещо неоднозначним у своєму використанні, але врахуйте, якщо ви зрештою хочете додати централізовану звітність про помилки або будь-який вид звітів, наприклад, "чи запускався" у ваш процес, тобто хореографія.

— aceinthehole

@ smp7d Я знаю, що сервер інтеграції webMethods має підтримку планування першого класу. Добре працює.

— Роберт Грант

1

Теоретично для вас є сенс мати єдине місце для контролю всіх розрізнених робочих місць, однак, виходячи з галузевого досвіду, подібного до "Священного Грааля", вам знадобляться тут роботи з кроном, скрипт для скриптів та сценарії кліпів.

Існує також мантра "Якщо вона не зламалася, не виправляйте її", тому, поки вони розгортаються, спочатку зосередьтеся на документування того, які сценарії ви запускаєте, що вони роблять і які системи вони торкаються, щоб ви "знали "як ведеться ваш бізнес.

Тоді, як довгострокова стратегія налаштування централізованої системи для виконання завдань, вибирайте рішення з розумом, тому що вам доведеться з цим жити. Потім для кожного запиту на внесення змін, удосконалення, оновлення, виправлення помилок або нового рішення, яке ви додаєте у вашій бізнес-архітектурі, переконайтеся, що його заплановані та автоматизовані завдання додаються до вашого «рішення управління підприємством».

Таким чином ви поступово переходите від партії сценаріїв до більш сприятливого для бізнесу середовища.

— Стівен Сенкомаго Мусоке
джерело

Це кілька хороших думок. Отже, ви вважаєте, що те, що я шукаю, не існує і що інструмент CI не є розумною альтернативою?

— smp7d

Це може існувати, але прагматизм щодо того, що ви використовуєте, може призвести до того, що ви все ще матимете роботу з cron та скриптами. Однак використання CI-середовища може бути перешкодою пізніше, оскільки CI - це насамперед для робочих процесів розвитку, але в міру дозрівання середовища ви шукаєте рішення, пов'язані з операціями. Пізніше ви можете вирішити перенести керування версіями / ІП у хмару, ви не хочете, щоб це було забито, оскільки воно здійснює щоденні операції ваших організацій.

— Стівен Сенкомаго Мусоке

Ну, ми думали, що ми будемо використовувати окремий інструмент CI для управління процесами, але я бачу, що ви говорите.

— smp7d

Оскільки ви дивитесь на окрему ІП, то чому б не подивитися на інструменти, орієнтовані на управління процесами, моніторинг та звітність. Таким чином, ви використовуєте зусилля, щоб створити ІП, щоб отримати потрібний інструмент для роботи, якщо це не вдасться, у вас є CI, щоб відмовитися

— Stephen Senkomago Musoke

Я згоден, що це найбільш розумний шлях. Рекомендовано кварцовий планувальник, supervisord.org та ESB. Чи є у вас якісь додаткові рекомендації чи думки з цього приводу? (також: Коли я сказав окремий CI, я просто мав на увазі чергову інсталяцію нашого поточного інструменту, можливо, з новим брендингом ... налаштування не буде проблемою)

— smp7d

0

У великих корпоративних системах, з якими я працював, вони зазвичай використовують інструмент, призначений для планування. Найпопулярніший з них я - це CA7. Це дозволяє централізувати весь графік для всіх ваших систем.

Cron зазвичай використовується для однієї машини, хоча ви можете "зламати", роблячи віддалені дзвінки ssh. Однак у ньому не буде поняття залежності та іншого. Що стосується операційних команд, де їх обсяг ще більш обмежений, найкраще використовувати інструмент.

— Архімед Траяно
джерело

Ваша рекомендація привела мене до цього ... en.wikipedia.org/wiki/Job_scheduler - Дивно, але ніхто не згадував цю назву для такого інструменту. Це можливо те, що я шукав так, ніби він призначений робити те, що я шукаю, час, ймовірно, покаже, що це робить це краще, ніж інструмент CI. Знадобиться кілька досліджень, щоб перевірити це.

— smp7d