Как Juju «сосуществует» с Chef, делая процесс автоматизации «на шаг впереди»?

Из этого поста ясно, что Juju находится на другом уровне, чем Chef Server. Juju находится на уровне оркестровки или обслуживания , а Chef больше на уровне отдельного сервера или конфигурации .

На одной из главных страниц Juju в Canonical говорится, что Juju разработан так, чтобы «сосуществовать» с такими инструментами, как Chef и Puppet, что делает процесс «еще одним шагом вперед». В течение последних нескольких недель я изучал эту тему в Интернете и не могу найти хорошего объяснения того, как такой инструмент, как Chef, будет сосуществовать с Juju.

Итак, чтобы разбить всеобъемлющий вопрос в заголовке: (особый интерес к Juju работает вместе с Chef Server)

• Что является примером очарования "написано в Chef"? Это просто талисман, написанный на bash, который затем вызывает chef-soloкоманду? Если да, может ли шарм вызывать chef-clientкоманду для совместной работы с Chef Server?
• Где пересечение между Джуджу и Шеф-поваром? Например, шарм apache2 имеет свою config-changedловушку, в которой он вносит изменения в конфигурацию, которые в мире Chef будут происходить в рецепте с применением файла шаблона. Если брелок Juju работал вместе с поваренной книгой шеф-повара при развертывании службы apache2 (кластер), то казалось бы, что брелок «apache2-chef» должен быть написан так, чтобы вы могли разделить задачи. В этом случае очарование apache2 в Charm Store будет менее чем полезным.
• Если у вас есть роли Chef, примененные к узлам (сервисным единицам), которые развернуты / управляются Juju, и ваш системный администратор решает изменить правила брандмауэра для определенной роли сервера, и делает ли это в роли Chef, будет ли Juju когда-нибудь перезаписывать эти изменения?
• Проще говоря, может ли Juju быть оболочкой Chef Server, как Ironfan ?

Я рассматриваю Chef Server как « как», тогда как «Juju» может делать « как» , но также и то, что стоит на столе. Это означает, что реальное текущее состояние служб и машин можно запрашивать и реагировать на них. Вы не можете сделать это в Chef Server. Моя цель состоит в том, чтобы внедрить возможности Juju по повышению осведомленности и организации обслуживания в инфраструктуру, управляемую Chef Server.

Похоже, что нужно написать целый набор символов, где не указаны все задачи / настройки, управляемые Chef.

Я хотел бы услышать взвешивания от кого-то в Canonical (например, Хорхе Кастро) и от Opscode (например, A. Jacob или J. Timberman).

классные вопросы!

TL; Dr

Я хотел бы разбить ваш вопрос (ы) на пару комментариев ... во-первых, вот несколько общих подходов к интеграции шеф-повара и дзюдо:

• Крюки Charms могут использовать существующие рецепты шеф-повара, которые работают в сольном стиле на сервисных единицах (рекомендуется)

• сервисные единицы juju регистрируются на существующем chef-сервере, используя подчиненный сервис chef-node

Эти идеи еще не были реализованы / проверены для шеф-повара, но существуют кукольные эквиваленты.

... хм .. не такой короткий ответ

Вот еще немного из двух подходов к интеграции шеф-повара и Джуджу:

Джуджу как топ-пёс

Здесь Джуджу управляет шоу. Самая большая ценность, которую обеспечивает juju, - это координация событий во время управления распределенной конфигурацией ... отсюда и название "оркестровка сервисов". Подвески Juju состоят из крючков, которые называются juju в «нужное время» при координации управления сервисом. Реализация этих хуков в значительной степени открыта. Это сценарии оболочки, исходный код, манифесты кукол или ... рецепты шеф-повара.

Juju разбивает биты любой конфигурации сервиса на:

• "установка" .. биты, которые являются специфическими для установки конкретной службы на узел

• "отношение" .. биты конфигурации, которые необходимы для связи этой службы с какой-либо другой службой

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

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

Повар как топ-пёс

Идея заключается в том, чтобы интегрировать службы juju в существующую инфраструктуру, управляемую chef-сервером. Для этого вам нужно написать подчиненный брелок для chef-узла. Эта подчиненная служба будет привязана к основным службам juju и будет эффективно регистрировать эти службы как узлы (в частности роли) с сервером chef. Subs могут быть присоединены во время запуска службы juju или в любое время позже в течение жизненного цикла каждого сервиса.

Я думаю, что это будет очень похоже на сабвуфер узла. Все необходимые ключи, роли и т. Д. Будут указываться через config для подчиненного шарма chef-узла. Я бы начал там. Более сложный подход заключается в том, что подчиненный узел chef-node запрашивает как первичную службу, к которой он подключен, так и его chef-сервер для динамического определения ролей, но это будет немного сложнее, чем просто указывать их в конфигурации для подчиненной.

мнения

Я определенно рекомендую способ 1 выше, если это возможно. Наличие координационного уровня поверх инструментов конфигурации, вероятно, будет хорошо работать в долгосрочной перспективе. Излишне говорить, что реальные инфраструктуры могут быть неким сочетанием или вариацией обоих подходов в течение определенного периода времени ... особенно во время миграции. Запланированное сосуществование с использованием метода 2, вероятно, будет работать, только если компоненты, управляемые обоими инструментами, будут несколько ортогональны друг другу. Не уверен, что именно это будет выглядеть. Возможно, juju и шеф-повар управляют отдельными относительно отделенными услугами? Я подозреваю, что это может хорошо сработать, чтобы juju управлял первичными услугами, а шеф-повар управлял другими аспектами инфраструктуры. Не знаю. Это немного длиннее обсуждение, хотя :)

Примечание: вы также можете использовать juju для управления самим chef-сервером ... даже для больших сложных многоуровневых установок chef-сервера. В последнее время я не смотрел на прелесть chef-сервера, но если он в настоящее время не обрабатывает разделение на уровни и разделение служб, то это, безусловно, можно сделать.

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

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