Які правильні питання слід задати, вирішуючи, чи використовувати шеф-кухаря чи лялечку?

Я збираюся розпочати новий проект, який частково вимагатиме розгортання багатьох однакових вузлів приблизно трьох різних класів:

• Вузли даних , які запускатимуть фрагменти екземплярів MongoDB.
• Вузли додатків , в яких будуть запущені екземпляри програми Ruby on Rails та старішої програми ASP.NET MVC.
• Вузоли обробки , які будуть виконувати завдання, запитувані вузлами програми.

Усі вузли будуть працювати в екземплярах Ubuntu 10.04, хоча в них встановлені різні пакети.

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

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

Якщо ви розпочали цей проект сьогодні, які питання ви б задали собі, щоб вирішити, чи слід використовувати шеф-кухаря чи лялечку для управління конфігурацією? (Примітка. Я не хочу відповідати на запитання "Чи слід використовувати шеф-кухаря чи лялечку?")

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

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

Ти знаєш рубін? - Якщо ви не знаєте рубіну, почати роботу з шеф-кухарем може бути складніше або вимагати більших вкладень часу, оскільки вам потрібно вивчити нову мову. Лялька має свою власну мову, з якої легко почати роботу. Починаючи з лялечки 2.6, маніфести можна записати і в рубін .

На мосту з відкритим кодом у 2009 році у них була група авторів та представників шеф-кухаря, маріонетки, bcfg2, cfengine та automateit, яку ви можете спостерігати на bliptv, який має 1,75 години дискусій про утиліти управління конфігурацією.

Opscode / шеф-кухар розповідає про різницю між нею та лялькою у своїх FAQ .

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

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

Як керівник команди, я зробив вибір для Ляльки для своєї команди. Якби я була командою тільки себе, я вибрала б замість цього шефа. Ось чому:

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

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

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

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

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

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

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

• Наскільки легко отримати налаштування екземпляра?
• Яка установка потрібна клієнту, щоб він міг спілкуватися з сервером?

І так далі. Але ви зможете дуже легко відповісти на ці питання: налаштуйте їх! Підготовка зразка - це декілька годин вашого часу для кожного продукту, і враховуючи, що те, що ви використовуєте для цього, швидше за все, буде використовуватися протягом тривалого часу, часу це варто того. Ви не тільки можете відчути, як вони поводяться з конкретними речами, що стосуються платформи (наприклад, на основі Debian і apt, на основі RPM та yum), але це, безумовно, допоможе вам відчути прикладні програми.

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

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

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

Шеф-кухар та лялька досить схожі, і обидва проекти однаково якісні. Якщо у вас є доступ до людей, які вже мають ляльковий досвід, просто використовуйте Лялечку.

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

• Який вік проекту?
• Наскільки активна спільнота (списки розсилки, помилки, irc тощо)?
• Чи забезпечена хороша обґрунтована документація стандартними методами?

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

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

Для мене це тісно пов'язане з традиціями конкретної громади. Історично шеф-кухар був ближче до хлопців RubyOnRails. Також велика популярність шеф-кухаря у спільноті ROR через те, що Engineyard побудував свою інфраструктуру на вершині шеф-кухаря.