Як Джуджу «співіснує» з шеф-кухарем, роблячи процес автоматизації «на крок далі»?

З цього повідомлення видно, що Джуджу сидить на іншому шарі, ніж Chef Server. Джуджу сидить на рівні оркестрації або сервісу , а шеф-кухар сидить більше на окремому рівні сервера або конфігурації .

На одній з головних сторінок компанії Canonical про Джуджу зазначено, що Джуджу створений для «співіснування» з такими інструментами, як «Шеф-кухар» та «Лялька», роблячи процес «на крок далі». Протягом останніх кількох тижнів я блукав в Інтернеті на цю тему і не можу знайти хорошого пояснення, як , однак, такий інструмент, як шеф-кухар, буде співіснувати з Джуджу.

Отже, щоб розбити головне питання в заголовку: (особливий інтерес до Джуджу, що працює разом із шеф-кухарем)

• Який приклад шарму "написано в шеф-кухаря"? Це просто чарівність, написана в баші, яка потім викликає chef-soloкоманду? Якщо так, чи може чарівник викликати chef-clientкоманду працювати в згоді з Chef Server?
• Де перекриття між Джуджу та шеф-кухарем? Наприклад, шарм apache2 має свій config-changedгачок, де він вносить зміни конфігурації, які у світі шеф-кухарів відбудуться у рецепті, застосувавши файл шаблону. Якщо б шарм Джуджу працював разом з кухарською книжкою шеф-кухаря щодо розгортання послуги (кластеру) apache2, то, здавалося б, потрібно було написати «чарівність апаш-2-шеф-кухаря», щоб ви могли відокремити завдання. У цьому випадку шарм apache2 в магазині Charm був би менш корисним.
• Якщо у вас є ролі шеф-кухаря, застосовані до вузлів (сервісних одиниць), які розгортаються / управляються Juju, і ваш sysadmin вирішує змінити правила брандмауера для певної ролі сервера, і чи це в ролі Chef, чи Juju коли-небудь замінить ці зміни?
• Простіше кажучи, чи може Джуджу бути обгорткою сервера шеф-кухарів, як Ironfan ?

Я розглядаю Chef Server як те, як тоді, як Juju може робити як , але також приносить те, що до столу. Це означає, що реальний поточний стан послуг та машин можна запитувати і діяти. Ви не можете цього зробити в Chef Server. Моя мета - залучити можливість обізнаності Джуджу та організацію обслуговування в інфраструктуру, керовану Chef Server.

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

Мені б хотілося почути зважування від когось із Canonical (наприклад, Хорхе Кастро) та з Opscode (наприклад, від А. Якоба чи Дж. Тімбермана).

дивовижні запитання!

дл;

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

• принадні гачки можуть використовувати існуючі рецепти шеф-кухарів, які працюють в соло-стилі на сервісних одиницях (рекомендується)

• Джуджі сервісні підрозділи реєструються на існуючому шеф-сервері, використовуючи підлеглий сервіс шеф-кухаря

Ці ідеї ще не були реалізовані / протестовані для шеф-кухаря, але лялькові еквіваленти існують.

... гм .. не дуже коротка відповідь

Ось ще трохи про розбиття двох підходів до інтеграції шеф-кухаря та жужу:

Джуджу як топ-собака

Тут Джуджу веде шоу. Найбільша цінність, яку надає дзюджу, - це координація подій під час управління розподіленою конфігурацією ... звідси і монітор "оркестрування послуг". Чари дзюджу складаються з гачків, які дзюджу викликають у "потрібний час" при координації управління сервісом. Реалізація цих гачків в значній мірі відкрита. Це сценарії оболонки, вихідний код, маріонеткові маніфести або ... кухарні рецепти.

Juju розбиває біти будь-якої конфігурації служби на:

• "встановлення" .. бітів, специфічних для встановлення певного сервісу на вузол

• "відношення" .. біти конфігурації, необхідні для відновлення цієї служби до якоїсь іншої служби

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

Нам потрібні кілька прикладів цього, але я думаю, що це буде популярний шеф-кухар, який має чудовий dsl, чудовий інструмент для створення шаблонів і його набагато приємніше використовувати, ніж bash при написанні складних конфігурацій. Для простого конфігурації, кухарські рецепти - це трохи непомітний імідж, тому цей метод інтеграції є майже найкращим з обох світів ... і має серйозні ноги вперед.

Шеф-кухар як топ-собака

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

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

Думки

Я, безумовно, рекомендую спосіб 1 вище, якщо це можливо. Маючи координаційний шар поверх інструментів конфігурації, ймовірно, буде працювати довгостроково. Зайве говорити, що інфраструктури реального світу можуть бути комбінацією чи варіацією обох підходів протягом певного періоду часу, особливо під час міграції. Заплановане співіснування за допомогою методу 2, ймовірно, спрацювало б лише в тому випадку, якщо компоненти, якими керуються обидва інструменти, були дещо ортогональними один одному. Не впевнений, як саме це виглядатиме. Можливо, джуджу та шеф-кухар управляють окремими відносно нерозлучними послугами? Я підозрюю, що це може спрацювати, щоб дозволити Джуджу керувати первинними послугами та надати шеф-кухаря керувати іншими аспектами інфраструктури. Данно. Це трохи довше обговорення :)

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

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

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